Överlämningsprotokollet vi rekommenderar för en privat AI-tjänst

NIST:s ramverk för AI-riskhantering behandlar tillförlitlighet genom design, utveckling, användning och utvärdering av AI-system.[1] Driftsperioden förtjänar egen dokumentation. För en privat AI-pilot som går över i rutinmässig användning rekommenderar vi ett överlämningsprotokoll som gör det möjligt för mottagande team att identifiera installationen, förstå dess begränsningar och agera när något slutar fungera.

Detta är vårt föreslagna överlämningsformat, inte en rapport från en granskad kundinstallation. Det kompletterar den tekniska och datagränsrelaterade informationen i Software Tailor trust centre. Varje organisation bör tilldela ansvarsområden enligt sin egen driftsmodell.

Namnge mottagande ägare och tillåtet arbete

Börja med en namngiven roll som accepterar ansvar för tjänsten. Dokumentera kontaktväg och alternativ lösning när ordinarie ägare inte är tillgänglig. En leverantörs supportadress är användbar, men organisationen behöver också någon som kan besluta om tjänsten ska fortsätta köras vid en incident.

Beskriv de uppgifter som godkänts för rutinmässig användning och de uppgifter som fortfarande är begränsade till piloten. Inkludera de grupper som får använda tjänsten och förväntade driftstider. En obesvarad pilotfråga ska förbli synlig med en ägare och planerat beslutdatum; den ska inte försvinna bara för att installationen ändrat status.

Fortsätt med de kapacitets- och tidsantaganden som användes vid inköpsbeslutet. Det ger mottagande team anledning att undersöka när arbetsbelastningen förändras.

Bevara den konfiguration som faktiskt kontrollerades

Dokumentera applikations- och serverversioner, runtime och exakt modellreferens. Behåll installationskällan och relevant konfiguration genom organisationens normala process för kontrollerade dokument. Spara inloggningsuppgifter via dess hantering av behörigheter, med referenser i överlämningen istället för kopierade hemliga värden.

Hugging Face model cards tillhandahåller dokumentation för modellens användningsområden, begränsningar och utvärdering.[2] Länka relevant kort och revision, och lägg sedan till lokala fynd från piloten. Utgivarens beskrivning och organisationens testresultat svarar på olika frågor; mottagande team ska kunna hitta båda.

Där systemet har valfria externa leverantörer, dokumentera vilka vägar som är aktiverade. Beskriv avsedd datagräns för varje väg och vem som kan godkänna en ändring. Undvik en bred etikett som “lokal” när driftskonfigurationen kräver en mer precis förklaring.

Tilldela ansvar för åtgärder och behörigheter

För en agentintegration, bifoga den överenskomna verktygslistan och identiteten som används av varje anslutning. OWASP rekommenderar att begränsa agentens kapabiliteter och behörigheter samt att genomdriva auktorisation i nedströms system.[3] Vårt överlämningsförslag omvandlar denna vägledning till en ägarfråga: vem kan granska eller återkalla varje beviljande?

Inkludera resultatet av verktygsanropsintegrationskontrollerna, med eventuella kvarvarande begränsningar. Skilj på behörighet att föreslå en operation och behörighet att utföra den. Om en person måste godkänna en åtgärd, identifiera var detta godkännande sker och hur ett misslyckat eller övergivet godkännande hanteras.

Den mottagande ägaren bör också känna till vilka diagnostiska register som finns, vem som kan komma åt dem och hur länge de sparas. Använd den konfigurerade policyn och ett verifierat exempel. Dra inte slutsatsen att prompts saknas i varje ansluten komponent bara för att en komponent har en revisionsdesign utan innehåll.

Öva en avbrottshantering före överlämning

Välj ett överenskommet, icke-destruktivt avbrott i en testmiljö. Låt det mottagande teamet följa återställningsinstruktionerna medan den ursprungliga implementeraren observerar. Dokumentera den saknade information de stöter på och uppdatera instruktionerna innan godkännande.

Övningen bör fastställa hur problemet känns igen, vem som kan stoppa det påverkade arbetet och hur den återställda tjänsten kontrolleras. Om rollback ingår i planen, identifiera den behållna versionen och tidpunkten då rollback är lämplig. Märk otestade återställningsantaganden som otestade.

För en Software Tailor-tjänstdiskussion, är en redigerad konfigurationspost och en tydlig redogörelse för det misslyckade steget mer användbara än ett obekräftat påstående om att hela systemet är trasigt. Överlämningen bör förklara hur man samlar in den informationen via organisationens godkända supportväg.

Gör godkännandet till en användbar dokumentation

Avsluta med den mottagande ägarens godkännande, datum och olösta punkter. Namnge de förändringar som bör utlösa en granskning, såsom en annan modell, en ny anslutning eller en bredare tillåten uppgift. Detta är en föreslagen driftprincip snarare än ett certifieringssystem.

Dokumentationen är klar när det mottagande teamet kan använda den för att fatta beslut utan att behöva återskapa piloten ur minnet.

Referenser

[1] NIST. AI Risk Management Framework. Ramverk 1.0 släppt 2023; bakgrundsvägledning. Hämtad 2026-09-26.

[2] Hugging Face. Modellkort. Riktlinjer för löpande modell-dokumentation. Hämtad 2026-09-26.

[3] OWASP Gen AI Security Project. LLM06:2025 Överdriven agentur. 2025 års upplaga. Hämtad 2026-09-26.