Alle artikelenStrategie
De CIO-test voor AI-governance
Een AI-beleid zegt wat agents horen te doen. Hun accounts en tools bepalen wat ze kunnen doen. Een test met drie vragen voor elke regel van het beleid laat een CIO zien welke delen van AI-governance standhouden en welke alleen op papier bestaan.
Een agent bij de klantenservice schrijft concepten van antwoorden en maakt, als een klant gelijk heeft, een creditnota aan. Het AI-beleid van het bedrijf zegt dat agents geen financieel record wijzigen zonder goedkeuring. Tijdens een risicoreview stelt iemand een eenvoudige vraag: wie heeft de creditnota's goedgekeurd die de agent vorige week heeft aangemaakt?
Het antwoord kost een middag. De agent draait op een integratieaccount. Dat account mag creditnota's boeken, omdat degene die het inrichtte de rechten kopieerde van een teamleider klantenservice, en die mag boeken. Niets in het systeem vroeg om goedkeuring. Het beleid klopte. Geen systeem dwong het af.
Het is een van de gaten die we het vaakst vinden, en het hoort niet bij één sector. Slordigheid is het ook niet. Het beleid is geschreven voor mensen, en mensen lezen het. Agents niet.
Drie vragen voor elke beleidsregel
Stel bij elke regel drie vragen:
- Welk systeem dwingt haar af? Niet welk team en niet welk document. Welk systeem zegt nee.
- Wat gebeurt er bij een overtreding? De actie wordt geweigerd, een benoemd persoon krijgt een melding, of er gebeurt niets.
- Welk bewijs laat zien dat ze standhield? Een record dat u kunt laten zien voordat de vergadering voorbij is.
Markeer de regel daarna: afgedwongen, deels afgedwongen of alleen geschreven. In onze ervaring komen bij de eerste ronde veel regels die agents raken terug als deels afgedwongen. Vaak bestaat de controle voor mensen, maar is ze nooit uitgebreid naar de accounts waarmee agents werken.
Vijf regels getest
| Beleidsregel | Afgedwongen door | Bewijs |
|---|---|---|
| Elke agent heeft een benoemde eigenaar in de business | Het identiteitssysteem geeft elke agent een eigen account, en alleen als het agentregister een eigenaar noemt. Vertrekt de eigenaar en neemt niemand het over, dan wordt het account geblokkeerd. | Registerregel, gekoppeld aan het account |
| Agents wijzigen geen financieel record zonder goedkeuring | Het account van de agent kan een concept aanmaken, maar niet boeken. Boeken vraagt de eigen login van een goedkeurder, gekoppeld aan precies dat concept. | Goedkeuringslog: wie welke wijziging wanneer goedkeurde |
| Klantgegevens blijven in goedgekeurde regio's | Agents bereiken AI-modellen alleen via endpoints in die regio's, ook een uitwijkmodel. Andere endpoints zijn op netwerkniveau geblokkeerd. | Endpointconfiguratie en de log van geblokkeerde aanroepen |
| We kunnen elke agent snel stoppen | Eén schakelaar per agent trekt zijn toegangsgegevens in en voorkomt dat acties in de wachtrij nog uitgevoerd worden. Hij wordt elk kwartaal getest. | Datum en uitkomst van de laatste test |
| Een modelwijziging is een systeemwijziging | Prompts, versies van modellen en drempels gaan door het wijzigingsbeheer en worden vóór livegang getest op echte gevallen van de vorige maand. | Wijzigingsrecord met testresultaten |
De controles zelf zijn oud: identiteitsbeheer, functiescheiding, netwerkregels, wijzigingsbeheer. Wat nieuw is, is de actor. Een agent is geen mens en geen klassiek serviceaccount, want hij kiest zelf zijn volgende stap. Daarom moeten de controles zitten waar de agent handelt, in zijn account en zijn tools, niet in zijn instructies.
Twee details bepalen of een regel echt standhoudt. Het eerste is het uitwijkmodel: een dataregel die het hoofdmodel dekt, maar niet het model waarnaar de agent uitwijkt als het hoofdmodel druk is, is maar deels afgedwongen. Het tweede is de stopschakelaar: toegangsgegevens intrekken is niet genoeg als acties in de wachtrij toch nog draaien. Test beide bewust.
Eén eigenaar per regel, van begin tot eind
De test legt meestal een tweede probleem bloot. Juridische zaken of risicomanagement schrijft de regel. IT bouwt de controle. Interne audit controleert het bewijs. Elk team doet zijn deel goed, maar niemand bewaakt of de regel standhoudt.
Geef daarom elke regel één eigenaar voor alle drie de antwoorden, meestal een senior persoon uit IT of risicomanagement. Eens per kwartaal beantwoordt die eigenaar één vraag: houdt deze regel nog stand, en hoe weten we dat? Als een model verandert of er een nieuwe agent bijkomt, beslist de eigenaar of de controle die nog dekt.
Stem de sterkte af op de zwaarste actie
Volledige controles op elke agent maken van governance een wachtrij, en om wachtrijen vinden teams een weg heen. Stem de sterkte daarom af op wat een agent kan doen.
- Leest en vat samen. Een eigenaar en leestoegang tot alleen de gegevens binnen de scope.
- Maakt concepten die een mens verstuurt. Plus een log van wat hij opstelde en wat de mens veranderde.
- Wijzigt records in een leidend systeem. Plus goedkeuring of review van zijn wijzigingen, en een geteste stopschakelaar.
- Verplaatst geld of verbindt het bedrijf aan een klant, leverancier of toezichthouder. Goedkeuring vóór elke actie, en een tweede goedkeurder boven een afgesproken bedrag.
Deel elke agent in naar de zwaarste actie die hij kan uitvoeren, niet naar de actie die hij meestal uitvoert. De creditnota-agent van hierboven hoorde in de laatste groep, ook al schreef hij het grootste deel van de dag concepten. Vaak is het beter het recht weg te halen dan een controle toe te voegen.
Zo zegt een CIO ook sneller ja. Een agent die samenvat, krijgt binnen dagen antwoord; de zorgvuldige review blijft voor de paar agents die echte schade kunnen doen.
Waar de agent ook vandaan komt
Agents komen op drie manieren een bedrijf binnen: IT bouwt ze, afdelingen bouwen ze op low-codeplatforms, en leveranciers leveren ze mee in producten die het bedrijf al gebruikt. De tabel blijft gelijk. Alleen de bron van het bewijs verandert. Voor eigen agents leveren uw teams het. Voor de agent van een leverancier kijkt u naar de instellingen en logs van het product. Waar die dat nog niet kunnen, beperk dan wat die agent mag wijzigen en breng het gat in bij de volgende productreview.
Wat we weigeren, en wat we anders zouden doen
We bouwen geen governancedashboard voordat de controles bestaan. Een dashboard dat de status meldt van beleid dat niets afdwingt, geeft een bestuur valse zekerheid, en dat is erger dan geen dashboard.
Wat we anders zouden doen: vroeger begonnen we de test bij de agents die IT had gebouwd, omdat die gedocumenteerd waren. Nu beginnen we bij de agents die zijn aangezet in producten die het bedrijf al gebruikt. Die staan het minst vaak op iemands lijst.
Waar u begint
Zet het beleid op één pagina. Schrijf voor elke regel de drie antwoorden en de status op. Kies één regel die alleen geschreven is en de agents met de meeste rechten raakt. Dwing die dit kwartaal af. Doe de test volgend kwartaal opnieuw en neem de pagina mee naar het auditcomité, niet het beleid.
Een beleid zegt wat het bedrijf van plan is. Accounts en tools bepalen wat een agent doet. Governance is het werk om dat gat te dichten, regel voor regel.