Governance voor AI agents: welke beslissingen u moet nemen voordat een agent toegang krijgt tot uw systemen

Kort samengevat. Governance voor AI agents bestaat uit een beperkte set beslissingen die bepalen wat een agent mag doen, wie ervoor verantwoordelijk is en wat er wordt vastgelegd terwijl de agent werkt. Zes beslissingen dekken het grootste deel: wie verantwoordelijk is, welke systemen de agent mag benaderen, wat wordt vastgelegd, wie wijzigingen mag doorvoeren, wat er gebeurt als er iets misgaat en wanneer de agent wordt uitgeschakeld. Neem deze beslissingen voordat de agent voor het eerst wordt uitgevoerd. Daarna moet elke wijziging als een wijzigingsverzoek worden behandeld.

Veel teams beginnen met het opstellen van een AI-beleid. Daarin staat dat de organisatie AI op een verantwoorde manier zal gebruiken. Iedereen ondertekent het beleid en zes weken later draait er een agent in productie, maar niemand kan zeggen wie toestemming heeft gegeven voor de systemen waartoe de agent toegang heeft. Een beleid beschrijft een voornemen. Governance bestaat uit minder opvallende, concrete beslissingen die achteraf kunnen worden gecontroleerd.

Bij agents is dat lastiger dan bij gewone software, en wel om één reden. Een script voert elke keer dezelfde handelingen uit. Door de code te lezen, kunt u zien wat het doet. Een agent kiest tijdens de uitvoering zelf welke stappen hij neemt. De nuttige vraag is daarom niet alleen wat de agent zal doen, maar vooral waartoe hij in staat is en wat hij afgelopen dinsdag daadwerkelijk heeft gedaan.

De zes onderstaande beslissingen zijn precies de vragen die een verantwoordelijke voor risico's of een inkoper zal stellen. En ze zijn allemaal eenvoudiger te nemen voordat de eerste agent wordt uitgevoerd.

Leg voor elke agent één persoon bij naam vast. Geen team of afdeling, maar iemand die kan uitleggen waarvoor de agent dient, welke systemen hij mag benaderen en wie om de agent heeft gevraagd. Verantwoordelijkheid lijkt misschien administratief totdat er iets onverwachts gebeurt en drie teams ervan uitgaan dat een ander team toezicht houdt.

Geef de verantwoordelijke twee taken die elk maar een paar minuten kosten: controleer elk kwartaal of de agent nog nodig is en of de lijst met toegestane tools nog klopt. Een agent die een jaar lang door niemand is gecontroleerd, is een probleem dat vroeg of laat aan het licht komt.

Leg vast welke tools de agent mag gebruiken en welke beperkingen voor elke tool gelden. Via tools kan een agent daadwerkelijk iets veranderen. Zonder tools kan hij alleen tekst produceren.

Begin met niets toestaan en voeg vervolgens alleen toe wat nodig is voor de taak. Leg voor elke tool precies vast wat is toegestaan: welke map, welk account, welke gegevens en of de toegang alleen-lezen is. 'Toegang tot het documentenarchief' is geen concrete beslissing. 'Leesrechten voor de aanbestedingsmap van dit jaar' is dat wel.

De kostbaarste fout is zelden een verkeerde zin van het model. Het is een tool die daadwerkelijk iets doet wat niet de bedoeling was.

Bepaal voordat u begint wat er van elke run moet worden vastgelegd: de stappen, de invoer, de uitvoer, de tijdstippen en welke tool met welke gegevens is aangeroepen. De samenvatting die het model zelf van zijn werk maakt, is niet hetzelfde als een registratie. Een model kan een tekst schrijven die op een verslag lijkt, maar die tekst komt uit hetzelfde systeem dat u juist wilt controleren.

Leg ook twee andere zaken vast. Ten eerste, hoelang u de gegevens bewaart. Dat moet aansluiten op uw eigen bewaartermijnen en niet automatisch op de standaardinstellingen van de leverancier. Ten tweede, wie de gegevens mag inzien. Een registratie van elke run bevat namelijk ook informatie over de mensen en zaken die de agent heeft behandeld.

Een agent heeft meer onderdelen die zijn gedrag beïnvloeden dan een script: de instructies die hij krijgt, het model waarop hij draait, de lijst met tools en de documenten waarin hij kan zoeken. Elke wijziging aan een van deze vier onderdelen kan het gedrag veranderen. Bovendien kunnen drie van die onderdelen worden gewijzigd door iemand die geen ontwikkelaar is.

Leg daarom vast wie elk onderdeel mag wijzigen en welke procedure bepaalt of een wijziging is goedgekeurd. Bewaar de oude versie. Een team dat niet kan achterhalen welke versie van een agent de uitvoer van vorige maand heeft geproduceerd, krijgt het lastig wanneer het moet uitleggen wat er is gebeurd.

Leg de afspraken vast zolang iedereen rustig is. Wie kan de agent stoppen en hoe snel kan dat? Wat wordt teruggedraaid en door wie? Wie wordt geïnformeerd, binnen en buiten de organisatie? Waar wordt het bewijsmateriaal bewaard zolang het incident wordt onderzocht?

Dit onderdeel slaan teams vaak over omdat de kans op problemen klein lijkt. Maar juist deze afspraken bepalen of een slecht uur uitgroeit tot een slecht kwartaal.

Geef elke agent een einddatum of een datum voor een evaluatie. Leg vast wat er gebeurt met de registraties, de geïndexeerde documenten en de toegangsgegevens wanneer de agent wordt stopgezet.

Organisaties zijn vaak goed in het starten van pilots, maar minder goed in het beëindigen ervan. Een vergeten agent behoudt zo mogelijk toegang tot systemen, lang nadat het project is afgesloten.

Er is een terugkerend patroon dat het waard is om expliciet te benoemen, omdat het goede bedoelingen ondermijnt. Teams beginnen met een medewerker die elk resultaat controleert. De agent heeft meestal gelijk, het controleren wordt saai en uiteindelijk stopt de medewerker ermee. Er gaat niets zichtbaar mis en er verschijnt geen waarschuwing. Op papier bestaat de controle nog, maar in de praktijk is die al weken verdwenen.

Kies daarom bij voorkeur voor controles die onderdeel zijn van de werking van het systeem, in plaats van controles die afhankelijk zijn van iemands voortdurende oplettendheid. Een beperkte lijst met tools en een volledige registratie blijven ook op een drukke vrijdag bestaan.

Governance bestaat uit beslissingen die u zelf neemt. Het platform moet die beslissingen ondersteunen, niet tegenwerken. Drie zaken maken daarbij het verschil:

• Één overzicht van de volledige agent. De instructies, tools en kennis op één plek, zodat iemand de agent kan beoordelen voordat deze in productie gaat.
• Een registratie die tijdens de uitvoering wordt opgebouwd. De stappen, invoer, tool-aanroepen en resultaten, in een formaat dat u kunt exporteren naar uw eigen systemen.
• Een licentie waarmee uw eigen medewerkers de broncode mogen inzien. Alleen de licentievoorwaarden geven hierover uitsluitsel. Lees ze vóór de demo, niet erna.

Ontbreekt een van deze onderdelen, dan moet uw team die later zelf bouwen, meestal pas nadat zich het eerste incident heeft voorgedaan.

De keuze waar u de software uitvoert, hangt nauw samen met governance: op wiens infrastructuur draait de agent, welk model roept hij aan en wie beheert de registratie wanneer iemand vraagt wat er is gebeurd?

Staat de registratie in de cloud van een leverancier, dan hangt uw reconstructie van wat er afgelopen dinsdag is gebeurd af van de medewerking en bewaartermijnen van die leverancier. Draait de agent in uw eigen omgeving, dan kunt u de zes bovenstaande beslissingen zelf nemen en aantonen hoe u ze hebt uitgevoerd.

In wie auditeert de agent-harness leest u meer over de technische laag die de registratie vastlegt.