Het overdrachtsrecord dat wij aanbevelen voor een private AI-dienst

Het AI Risk Management Framework van NIST behandelt betrouwbaarheid gedurende het ontwerp, de ontwikkeling, het gebruik en de evaluatie van AI-systemen.[1] De operationele periode verdient eigen bewijsvoering. Voor een private AI-pilot die overgaat naar routinematig gebruik, bevelen wij een overdrachtsrecord aan waarmee het ontvangende team de installatie kan identificeren, de grenzen kan begrijpen en kan reageren wanneer iets niet meer werkt.

Dit is ons voorgesteld overdrachtsformat, geen verslag van een geauditete klantimplementatie. Het vult de technische en databoundary-informatie aan in het Software Tailor trust centre. Elke organisatie dient de verantwoordelijkheden toe te wijzen aan haar eigen operationele model.

Benoem de ontvangende eigenaar en het toegestane werk

Begin met een benoemde rol die verantwoordelijkheid voor de dienst aanvaardt. Noteer het contactkanaal en de alternatieve regeling wanneer de gebruikelijke eigenaar niet beschikbaar is. Het supportadres van een leverancier is nuttig, maar de organisatie heeft ook iemand nodig die kan beslissen of de dienst tijdens een incident moet blijven draaien.

Beschrijf de taken die zijn goedgekeurd voor routinematig gebruik en de taken die nog beperkt zijn tot de pilot. Vermeld de groepen die de dienst mogen gebruiken en de verwachte operationele uren. Een onopgeloste pilotbevinding moet zichtbaar blijven met een eigenaar en een geplande beslisdatum; deze mag niet verdwijnen omdat de installatie van status is veranderd.

Neem de capaciteits- en deadlineveronderstellingen mee die zijn gebruikt bij de aankoopbeslissing. Dat geeft het ontvangende team een reden om te onderzoeken wanneer de werklast verandert.

Behoud de configuratie die daadwerkelijk is gecontroleerd

Noteer de applicatie- en serverbuilds, de runtime en de exacte modelreferentie. Bewaar de installatiesource en de relevante configuratie via het normale gecontroleerde documentatieproces van de organisatie. Sla inloggegevens op via het credential-managementproces, met verwijzingen in de overdracht in plaats van gekopieerde geheime waarden.

Hugging Face modelkaarten bieden documentatie over modelgebruik, beperkingen en evaluatie.[2] Koppel de relevante kaart en revisie, en voeg vervolgens de lokale bevindingen uit de pilot toe. De beschrijving van de uitgever en de testresultaten van de organisatie beantwoorden verschillende vragen; het ontvangende team moet beide kunnen terugvinden.

Waar het systeem optionele externe providers heeft, noteer welke routes zijn ingeschakeld. Beschrijf de beoogde databoundary voor elke route en wie een wijziging mag goedkeuren. Vermijd een brede aanduiding zoals “lokaal” wanneer de operationele configuratie een preciezere uitleg vereist.

Verantwoordelijkheid toewijzen voor acties en permissies

Voor een agentintegratie, voeg de afgesproken lijst met tools en de identiteit die door elke verbinding wordt gebruikt toe. OWASP raadt aan om de mogelijkheden en permissies van agents te beperken en autorisatie af te dwingen in downstream-systemen.[3] Ons overdrachtsvoorstel vertaalt die richtlijn naar een eigendomsvraag: wie kan elke toekenning beoordelen of intrekken?

Neem de uitkomst van de tool-call integratiecontrolesop, met eventuele resterende beperkingen. Maak onderscheid tussen toestemming om een operatie voor te stellen en toestemming om deze uit te voeren. Als een persoon een actie moet goedkeuren, geef dan aan waar die goedkeuring plaatsvindt en hoe een mislukte of afgebroken goedkeuring wordt afgehandeld.

De ontvangende eigenaar moet ook weten welke diagnostische gegevens bestaan, wie er toegang toe heeft en hoe lang ze worden bewaard. Gebruik het geconfigureerde beleid en een geverifieerd voorbeeld. Trek niet de conclusie dat prompts afwezig zijn in elk verbonden onderdeel alleen omdat één onderdeel een content-vrije auditopzet heeft.

Oefen één onderbreking voorafgaand aan de overdracht

Kies een afgesproken, niet-destructieve onderbreking in een testomgeving. Laat het ontvangende team de herstelinstructies volgen terwijl de oorspronkelijke implementator observeert. Leg de ontbrekende informatie vast die zij tegenkomen en werk de instructies bij vóór goedkeuring.

De oefening moet vaststellen hoe het probleem te herkennen, wie het getroffen werk mag stoppen en hoe de herstelde dienst te controleren. Als rollback deel uitmaakt van het plan, identificeer dan de bewaarde versie en het moment waarop rollback passend is. Houd ongeteste herstelveronderstellingen als ongetest gelabeld.

Voor een Software Tailor dienstbesprekingzijn een geanonimiseerd configuratiebestand en een duidelijke beschrijving van de mislukte stap nuttiger dan een ongefundeerde bewering dat het hele systeem kapot is. De overdracht moet uitleggen hoe die informatie via de goedgekeurde ondersteuningsroute van de organisatie wordt verzameld.

Maak van de goedkeuring een bruikbaar document

Sluit af met de acceptatie door de ontvangende eigenaar, de datum en de onopgeloste punten. Noem de wijzigingen die een herziening moeten triggeren, zoals een ander model, een nieuwe connector of een bredere toegestane taak. Dit is een voorgestelde operationele discipline en geen certificeringsschema.

Het document is gereed wanneer het ontvangende team het kan gebruiken om een beslissing te nemen zonder de pilot uit het geheugen te hoeven reconstrueren.

Referenties

[1] NIST. AI Risk Management Framework. Framework 1.0 uitgebracht 2023; achtergrondrichtlijnen. Geraadpleegd 2026-09-26.

[2] Hugging Face. Modelkaarten. Standaard richtlijnen voor modeldocumentatie. Geraadpleegd op 26-09-2026.

[3] OWASP Gen AI Security Project. LLM06:2025 Overmatige autonomie. Editie 2025. Geraadpleegd op 26-09-2026.