Een enterprise AI-agent is niet langer een eenvoudige interface wanneer deze gegevens kan opvragen, API's kan aanroepen, records kan maken, berichten kan verzenden, statussen kan wijzigen of acties kan uitvoeren. Op dat moment is het niet meer voldoende om te vragen of ‘hij goed reageert’. Je moet ontwerpen wat ze kan doen, met welke middelen, onder welke omstandigheden en hoe de organisatie herstelt als ze een fout maakt.
Governance is geen bureaucratische laag die later wordt toegevoegd. Het maakt deel uit van de architectuur. Het AI RMF-framework van NIST is precies ontworpen om organisaties te helpen de risico's van AI-systemen te beheren tijdens ontwerp, ontwikkeling, gebruik en evaluatie, en het profiel voor generatieve AI breidt die aanpak uit naar specifieke generatieve systeemrisico's.
1. Modelleer risico’s op basis van actie, niet op basis van ‘intelligentieniveau’
Het risico van een agent hangt niet alleen af van het gebruikte model. Het hangt af van de beschikbare acties en de gevolgen van een fout. Een middelmatig model met toestemming om gegevens te verwijderen kan gevaarlijker zijn dan een uitstekend model dat zich beperkt tot het samenvatten van documenten.
Evalueer voor elke capaciteit minstens vier dimensies: impacto, reversibilidad, gegevensgevoeligheid y frecuencia. Het versturen van een intern concept is iets anders dan het versturen van een offerte naar een klant. Het raadplegen van een bestand is iets anders dan het wijzigen ervan. Het voorbereiden van een betaling is iets anders dan het uitvoeren ervan.
- Laag risico: intern zoeken naar niet-gevoelige informatie, samenvatting, voorlopige classificatie.
- Gemiddeld risico: maak taken, werk niet-kritieke velden bij, bereid antwoorden voor ter beoordeling.
- Hoog risico: externe communicatie verzenden, kritieke gegevens wijzigen, bewerkingen goedkeuren, actie ondernemen op betalingen of vergunningen.
2. Definieer autonomie in stappen
Er bestaat niet één ‘autonoom of niet-autonoom’ besluit. Je kunt niveaus ontwerpen.
- Hulp: de agent doet een voorstel, een persoon voert uit.
- Uitvoering met goedkeuring: De agent bereidt de actie voor en wacht op menselijke bevestiging.
- Beperkte uitvoering: kan automatisch handelen binnen gedefinieerde regels en drempels.
- Begeleide autonomie: beheert een volledige stroom, maar registreert acties, past limieten toe en escaleert uitzonderingen.
Het niveau moet afhangen van het risico, niet van de wens om te automatiseren. Een omkeerbare, frequente en goed gedefinieerde actie kan meer autonomie krijgen. Een onomkeerbaar kostbaar besluit moet door de mens worden beoordeeld, ook al is het model zeer goed.
3. Pas de minste privileges toe
De agent mag alleen de machtigingen hebben die nodig zijn voor zijn taak. Gebruik geen globale beheerdersreferenties omdat dit “eenvoudiger is.” Maak afzonderlijke serviceaccounts of scopes wanneer het platform dit toestaat.
Als een agent alleen de agenda hoeft te lezen, mag hij of zij geen evenementen kunnen verwijderen. Als u concepten moet maken, heeft u geen toestemming nodig om deze te verzenden. Als u een database bevraagt, scheidt u het lezen van het schrijven. Als u moet schrijven, beperk dan tabellen, bewerkingen of eindpunten.
Scheid geheimen op functie
Combineer niet alle inloggegevens in één toegankelijke context. Een agent hoeft het geheim niet te kennen dat een andere dienst gebruikt. Beheer geheimen buiten de prompt en lever ze alleen af aan de connector die ze nodig heeft.
De beste oplossing voor een gevaarlijke actie is om het model niet te vragen ‘voorzichtig te zijn’. Het punt is dat de architectuur niet toestaat dat het buiten de regels om wordt uitgevoerd.
4. Ontwerp echt menselijk toezicht
‘Mens op de hoogte’ betekent niet dat er een scherm met een goedkeuringsknop wordt getoond. De persoon heeft voldoende context nodig om een fout te kunnen detecteren.
Uit een goedkeuring moet blijken welke actie wordt voorgesteld, met betrekking tot welk object, welke gegevens dit rechtvaardigen, welke gevolgen dit heeft en welke velden door AI zijn gegenereerd of afgeleid. Als de recensent alles opnieuw moet onderzoeken, verdwijnen de veronderstelde besparingen.
Voorkom automatisering van goedkeuring
Als iemand honderden identieke voorstellen goedkeurt zonder ze te lezen, bestaat er alleen formeel controle. Wanneer het volume het onhaalbaar maakt om elk geval te beoordelen, herontwerp dan de controle: beoordeling op basis van steekproeven, drempels, deterministische regels of scheiding van risicogevallen.
5. Evalueer het systeem met echte taken
Een demo valideert een agent niet. Bouw een reeks representatieve cases en moeilijke cases: onvolledige gegevens, tegenstrijdigheden, tegenstrijdige input, verzoeken die buiten de scope vallen en toolfouten.
Definieer statistieken met betrekking tot het resultaat: extractienauwkeurigheid, correcte escalatiesnelheid, valse acties, omissies, oplossingstijd, kosten per case en kritieke fouten. Voor generatieve taken is menselijke evaluatie nog steeds nodig in dimensies waar geen voldoende deterministische maatstaf bestaat.
Testen voor en na elke wijziging
Het veranderen van model, prompt, tool of versie kan het gedrag veranderen. Houd een regressieset bij. Als een update gemiddeld verbetert, maar een kritiek geval doorbreekt, moet u deze vóór productie detecteren.
6. Beschermt de agent tegen niet-vertrouwde instructies
Wanneer een agent e-mails, webpagina's, documenten of berichten leest, moet die inhoud worden behandeld als gegevens en niet als geautoriseerde instructies. Een document kan tekst bevatten die probeert het gedrag van de agent te manipuleren.
Scheid systeeminstructies, beleid en externe inhoud duidelijk van elkaar. Beperkt welke tools kunnen worden aangeroepen vanuit niet-vertrouwde invoer en vereist bevestiging voor gevoelige acties.
7. Ontwerp veilige mislukkingen
Systemen falen: API's reageren niet, inloggegevens verlopen, gegevens komen onvolledig aan en modellen retourneren ongeldige formaten. De belangrijke vraag is wat er daarna gebeurt.
Voor acties met een grote impact moet een mislukking de stroom veilig sluiten in plaats van te improviseren. Als een verplicht stukje informatie ontbreekt, verzin het dan niet. Als een API een dubbelzinnige status retourneert na het uitvoeren van een actie, moet u eerst afstemmen voordat u het opnieuw probeert. Indien het risico bestaat dat een publicatie, betaling of bestelling wordt gedupliceerd, is er sprake van idempotence.
Classificeer fouten
- Transiënten: time-out, tijdslimiet, downtime van leveranciers. Ze kunnen gecontroleerde nieuwe pogingen ondersteunen.
- Gegevens: ontbrekende velden, ongeldige formaten. Ze vereisen correctie of schaalvergroting.
- Over politiek: actie buiten machtigingen of drempel. Ze moeten geblokkeerd worden.
- Dubbelzinnig: We weten niet of de actie is uitgevoerd. Ze vereisen verzoening voordat ze worden herhaald.
8. Waarneembaarheid: weten wat je hebt gedaan en waarom
Registreert voldoende gebeurtenissen om een beslissing te reconstrueren: casusidentificatie, stroomversie, model indien relevant, aangeroepen tools, niet-gevoelige parameters, resultaat, fouten en goedkeuringen. Bewaar geen geheimen of onnodige gegevens in logs.
Waarneembaarheid dient voor werking en verbetering. Als het uitzonderingspercentage toeneemt, moet u weten in welk stadium. Als de kwaliteit na een update verandert, moet je versies kunnen vergelijken.
9. Afhankelijkheid van leveranciers en continuïteit
Een AI-systeem is doorgaans afhankelijk van meerdere services. Documenteer wat er gebeurt als een leverancier de prijs, het model, de limieten of de beschikbaarheid wijzigt. Het betekent niet dat je overal vervangers voor moet bouwen; Het betekent dat u de kritische afhankelijkheden kent en waar nodig degradatiepaden ontwerpt.
Het behoudt stabiele interne formaten, abstraheert belangrijke integraties en voorkomt dat bedrijfslogica onnodig afhankelijk is van een eigen functie die moeilijk te vervangen is.
10. Gegevens en privacy
Minimaliseert gegevens die naar het model worden verzonden. Als een taak kan worden opgelost met gedeeltelijke velden, stuur dan niet het volledige bestand. Beoordeel contracten, verwerkingsregio's, retentie en leverancierscontroles op basis van toepasselijke gevoeligheid en verplichtingen.
Technisch bestuur is geen vervanging voor juridisch advies. Wanneer er sprake is van persoonsgegevens, gereguleerde sectoren of besluiten met relevante gevolgen, is er sprake van specifieke juridische en compliance toetsing.
11. Gebruik referentiekaders zonder er lege checklists van te maken
El NIST AI-risicobeheerkader stelt een gestructureerde aanpak voor voor het beheren van risico's en vertrouwen in AI-systemen. Het generatieve AI-profiel voegt specifieke overwegingen van generatieve systemen toe. Deze raamwerken zijn nuttig als referentie, maar moeten worden vertaald naar concrete beheersing van het daadwerkelijke proces.
De vraag is niet “voldoen we aan een raamwerk?” Het is “welk risico bestaat er in dit geval, wie is de eigenaar ervan, welke controle vermindert het, en hoe weten we dat de controle werkt?”
12. Checklist voordat u autonomie aan een agent geeft
- Geeft een overzicht van alle beschikbare tools en acties.
- Classificeer elke actie op impact en omkeerbaarheid.
- Beperk de machtigingen tot het noodzakelijke minimum.
- Definieert welke acties goedkeuring vereisen.
- Ontwerp de behandeling van niet-vertrouwde invoer.
- Creëer een evaluatieset met echte en tegenstrijdige cases.
- Definieer uitgaven-, volume- en frequentielimieten.
- Implementeert idempotence voor herhaalbare acties.
- Classificeer fouten en probeer beleid opnieuw.
- Ontwerp logs zonder geheimen.
- Definieert menselijke escalatie en operationele verantwoordelijkheid.
- Test herstel bij falen van de leverancier.
- Documenteert hoe u de agent snel kunt uitschakelen.
- Wat is de slechtste actie die u kunt ondernemen met uw huidige machtigingen?
- Kan externe input u ertoe aanzetten een gevoelig instrument te gebruiken?
- Wat gebeurt er als de API een actie te laat bevestigt?
- Kunnen we een besluit na een incident reconstrueren?
- Wie kan het systeem tegenhouden?
- Hoe weten we dat een update een kritiek geval niet verergert?
Conclusie
Nuttige autonomie gaat niet over het geven van meer hulpmiddelen aan een agent. Het bestaat eruit dat u binnen een bepaalde perimeter kunt handelen: minimale rechten, voldoende gegevens, duidelijke grenzen, waarneembaarheid, evaluatie en een veilige uitweg als u niet weet wat u moet doen.
Hoe groter de potentiële impact van een actie, hoe minder vertrouwen afhankelijk zou moeten zijn van het model dat zich “goed gedraagt” en meer van deterministische controles rondom het model.
En hoe wij werken We leggen uit hoe ProjectCore processen, controles en architectuur ontwerpt voordat de autonomie van een systeem wordt vergroot.