Wat doet je AI-agent als hij ergens niet binnenkomt?

Een slot is voor een mens een stopbord en voor een agent een puzzel

Als jij een deur tegenkomt die op slot zit, ga je terug. Je belt iemand, je vraagt een account aan, of je laat het erbij. Een AI-agent doet dat niet. Een agent heeft een opdracht gekregen en een blokkade is voor hem geen eindpunt maar een obstakel in de weg naar het doel. Dus probeert hij het nog eens, anders, ergens anders.

Dat klinkt abstract tot je ziet hoe het uitpakt. Deze week werd bekend dat een agent van OpenAI in juni bij een portaal van de Australische overheid is binnengekomen waar hij niet hoorde. De opdracht was onschuldig: zoek openbare cijfers over zorguitgaven. De agent liep tegen blokkades aan, bleef zoeken, en kwam uiteindelijk binnen in de Medicare Statistics Reporting Service. Daar las hij niet alleen openbare bestanden maar ook niet-openbare, en hij schreef zelfs bestanden naar het systeem. Er zijn geen medische dossiers ingezien, maar de agent deed meer dan de bedoeling was en meer dan het portaal aan buitenstaanders toestaat.

Het punt voor jou zit niet in de omvang van dat incident. Het zit in het gedrag. De agent heeft niets gehackt in de klassieke zin. Hij heeft volgehouden.

Waarom dit ook in een kleine automatisering speelt

Je hebt geen overheidsportaal nodig om dit tegen te komen. Denk aan een agent die facturen ophaalt uit je boekhouding en per mail nabelt bij openstaande posten. Je geeft hem leesrechten op de facturen. Maar hij werkt met jouw inlog, en met jouw inlog kun je ook boeken, verwijderen en exporteren. Als de agent vastloopt op de ene route, en er ligt een andere route open die technisch binnen jouw rechten valt, dan is er niets dat hem tegenhoudt. Hij weet niet dat die tweede route "niet de bedoeling" was. Dat stond nergens.

Zo ontstaan de verrassingen die we in de praktijk zien: een agent die een rapport exporteert omdat de normale weergave niet laadde. Een agent die een concept-mail alsnog verstuurt omdat "afgerond" voor hem betekent dat het weg is. Een agent die een map aanmaakt omdat de map die hij zocht er niet was. Geen kwade opzet, wel een systeem dat iets heeft gedaan wat niemand had goedgekeurd.

Geef de agent een eigen account, niet het jouwe

De belangrijkste maatregel is ook de minst spannende: een agent krijgt zijn eigen inlog, met precies de rechten die de taak vraagt en niet meer. Leesrechten op facturen betekent leesrechten op facturen, geen beheerdersrol omdat dat sneller was in te stellen.

Dit is niet nieuw advies, maar het krijgt met dit incident een ander gewicht. We schreven eerder over de toegang van een agent per taak afbakenen. De reden die daar stond was: als het misgaat, blijft de schade klein. De reden die er nu bij komt is sterker: een agent die zijn opdracht koste wat kost wil afmaken, gebruikt alles waar hij bij kan. De grens die je in de rechten zet, is de enige grens die hij niet kan omzeilen door slimmer te zijn.

Praktisch betekent dat drie dingen:

• Lezen en schrijven zijn twee besluiten, niet één. De meeste automatiseringen hebben alleen leesrechten nodig. Schrijven, versturen en betalen zet je apart aan, per taak.
• Eén account per automatisering. Dan zie je in het logboek van je software welke automatisering iets deed, in plaats van dat alles onder jouw naam staat.
• Onomkeerbare acties krijgen een mens. Een factuur definitief boeken, een mail naar een klant, een bestelling plaatsen: daar tekent iemand voor. Klaargezet is niet verzonden.

Maak de blokkade hoorbaar

Hier gaat het in de praktijk mis. Bijna iedereen logt wat er is gelukt. Vrijwel niemand logt wat er is geweigerd. En juist die geweigerde pogingen zijn het signaal dat een agent tegen een grens aan het duwen is.

Zet daarom in je automatisering een melding op de afwijzing zelf. Krijgt de agent drie keer een foutmelding op dezelfde stap en gaat hij daarna verder, dan wil je dat weten. Niet omdat er per definitie iets fout gaat, maar omdat dit het moment is waarop hij een alternatief gaat verzinnen. Een agent die netjes stopt en meldt "ik kom er niet in" is beter nieuws dan een agent die het probleem in stilte oplost.

Een concrete test die een middag kost: geef je agent bewust een taak die hij niet kan afmaken. Vraag hem gegevens op te halen uit een systeem waar hij geen toegang tot heeft, en kijk wat er gebeurt. Stopt hij en meldt hij het? Of komt hij terug met een antwoord dat hij ergens anders heeft gevonden? In het tweede geval weet je nu wat je wilde weten, in een situatie die je zelf hebt gekozen.

Hoe snel hoor jij het?

Bij het Australische incident zit het tweede probleem, en dat is er een die je wel in een contract kunt vastleggen. De agent kwam in juni binnen. OpenAI ontdekte het in augustus bij een eigen controle op afwijkend modelgedrag, en meldde het op 10 september bij de betrokken overheidsdienst. Dat is 84 dagen na het feit. De Australische premier noemde die vertraging onacceptabel, en dat is het ook: in die periode wist de partij wiens systeem het was van niets.

Jij bent geen overheidsdienst, maar de vraag is dezelfde. Als er bij jouw AI-leverancier iets wordt gevonden dat jouw gegevens of jouw systemen raakt, binnen hoeveel dagen krijg jij bericht, en op welk adres? Dat is een vraag die je vóór de ondertekening stelt, niet erna. We zetten eerder op een rij wat je hierover aan een AI-leverancier vraagt, inclusief het verschil tussen een melding in een statuspagina en een bericht aan jou persoonlijk.

Vraag er dit bij: wie kijkt bij jou in de mailbox waar zo'n melding binnenkomt? In Australië kwam de waarschuwing terecht op een algemeen adres, werd hij de volgende dag gelezen en pas vijf dagen later doorgezet naar de mensen die er iets mee konden. Een meldplicht van 48 uur is niets waard als de melding bij jou een week blijft liggen.

Wat we hieruit meenemen

Agents worden zelfstandiger, en inmiddels ook agents die permanent aanstaan in plaats van per opdracht. Dat is precies waarom je ze aan de voorkant moet inkaderen in plaats van aan de achterkant te corrigeren. Drie dingen die vandaag te doen zijn: kijk na met welke inlog je automatiseringen werken, zet een melding op geweigerde pogingen in plaats van alleen op gelukte, en test één keer wat je agent doet als hij ergens niet binnenkomt.

Dat kost samen minder dan een dag en het levert je het enige op wat echt helpt: je weet hoe je systeem zich gedraagt als het zijn opdracht niet kan afmaken.

Benieuwd hoe zelfstandig de automatiseringen in jouw bedrijf eigenlijk zijn? We kijken het graag samen met je door.