Wat de integratie van AI-agents moet beheersen
Een AI-agent die is gekoppeld aan bedrijfssystemen is een actor, geen functie. Hij leest gegevens, beslist wat de volgende stap is en schrijft – indien daartoe gemachtigd – gegevens terug. Een conventionele integratie doet wat hij geconfigureerd is om te doen. Een agent neemt beslissingen.
Het beheersen van een actor betekent dat vooraf moet worden vastgelegd wat hij mag bereiken en wat hij mag wijzigen. Dit zijn dezelfde beslissingen die een bedrijf neemt voor een werknemer of een service-account. Het verschil zit in de snelheid: een impliciete aanname wordt honderden keren getoetst voordat iemand deze controleert.
Vijf zaken moeten expliciet worden vastgelegd:
- Toegangsbereik: welke systemen en welke gegevens, aangezien een agent die klantvragen beantwoordt geen reden heeft om inkoopprijzen van leveranciers in te zien
- Toegestane acties: het onderscheid tussen het inzien van een order, het wijzigen ervan en het annuleren ervan; dit zijn stuk voor stuk afzonderlijke beslissingen
- Drempelwaarden en escalatie: de waarde of het risiconiveau waarboven een menselijke bevestiging vereist is, in plaats van een algemene toestemming of weigering
- Identiteit en toeschrijving: welke agent handelt namens welke gebruiker of welk proces, zodat elke actie een eigenaar heeft
- Een volledig logboek: wat er is ingezien, wat er is gewijzigd en op basis waarvan, in een vorm die antwoord geeft aan een auditor of een klagende klant
Dit zijn geen nieuwe vereisten. Het zijn de controles die al gelden voor integraties en interfaces, nu toegepast op een actor die zijn eigen volgende stap bepaalt. Ze zijn nu belangrijker omdat een agent die actie onderneemt een ander vraagstuk vormt dan een agent die alleen gegevens leest.
Waarom verschilt een uitvoerende agent van een lezende agent?
Een lezende agent die een fout maakt, geeft een onjuist antwoord dat vervolgens door iemand wordt gecorrigeerd. Een uitvoerende agent die een fout maakt, verstrekt een onterechte terugbetaling, past een voorraadcijfer aan dat al correct was, of annuleert een bestelling die de klant nog steeds wil ontvangen. Het ongedaan maken van dergelijke acties is een tweede operatie met eigen gevolgen.
Het tweede verschil is minder zichtbaar. Een normale integratie voert bij elke uitvoering dezelfde handeling uit, waardoor een test precies laat zien wat er in productie zal gebeuren. Een agent kiest echter zijn eigen route naar het doel, en hetzelfde verzoek kan elke keer tot een andere reeks stappen leiden. Testen biedt daarom minder zekerheid. De enige betrouwbare controle is het beperken van de acties die de agent überhaupt kan uitvoeren.
Snelheid is het derde verschil. Een agent voltooit in minuten waar een persoon dagen over zou doen. Als de logica klopt, is dat precies de bedoeling. Als de logica echter fout is, zijn er al vierhonderd records aangepast voordat iemand het opmerkt.
AI-governance heeft betrekking op wat een model leest en hoe het tot een conclusie komt, wat een datavraagstukis. Het beheren van wat een agent in het ERP schrijft, is een toegangsbeheervraagstuk, en voor beide zijn verschillende controles nodig.
De kosten van ongecontroleerde AI-agenttoegang
De meeste hiervan zijn oude integratieproblemen die zich in een hoger tempo voordoen. Het verschil is dat een agent deze bereikt zonder dat iemand heeft besloten dat dit zou moeten gebeuren:
- Inloggegevens worden te ruim gedeeld: de agent krijgt een serviceaccount met lees- en schrijfrechten voor het gehele ERP, omdat het beperken tot vier specifieke acties een week zou hebben gekost
- Acties kunnen niet worden toegewezen: de bestelling werd om 02:14 uur geannuleerd door “integration_user”, en niemand kan achterhalen welke agent dit deed, welke prompt dit activeerde of wie het verzoek indiende
- Fouten stapelen zich op voordat iemand ingrijpt: de agent past 's nachts dezelfde foutieve regel toe op zeshonderd bestellingen, en het patroon komt pas 's ochtends in de wachtrij naar boven
- Gereguleerde gegevens belanden op een niet-gecontroleerde plek: klantgegevens bereiken een model of een externe dienst die door niemand is getoetst op persoonsgegevens
- De actie kan niet worden teruggedraaid: er is geen registratie van de waarden van vóór de wijziging door de agent, waardoor herstel puur giswerk wordt
Het laatste punt verandert een incident in een definitief verlies. Alle vijf zijn varianten van een vereiste waar bedrijven al jaren mee werken zonder deze strikt te handhaven.
Waarom AI-agentintegratie een oude vereiste urgent maakt
Bedrijven koppelen al jaren systemen aan elkaar zonder precies te definiëren wat elke verbinding mag doen. Een nachtelijke taak haalt bestellingen uit de webshop naar het ERP met een databaseaccount dat ook naar het grootboek kan schrijven. Een prijsfeed vanuit het PIM heeft toestemming om elk veld van een product bij te werken, terwijl het er in de praktijk slechts drie aanraakt. Niemand maakt zich daar druk om, omdat die integraties elke nacht hetzelfde doen.
Een agent doorbreekt die afspraak. Hij bepaalt zelf zijn volgende stap, dus vertrouwen op wat hij zal kiezen is geen vorm van controle. De beperking van rechten die voor een nachtelijke taak een goede gewoonte was, wordt voor een agent een randvoorwaarde.
De vraag bij het verbinden van een agent is dus niet wat hij kan bereiken. Het is wat hij kan worden belet te doen, en of iemand zijn acties een maand later nog kan reconstrueren. Bedrijven die al databeveiliging over hun AI-integraties heen afhandelen, hebben het meeste voorbereidende werk al gedaan.
De meeste teams beginnen door de agent rechtstreeks te verbinden met de API van elk systeem. Dat is de snelste route, maar het plaatst de inloggegevens en de regels over wat de agent mag doen binnen de agent zelf. Sommigen gebruiken in plaats daarvan een agentplatform, dat de verbindingen beheert maar die regels gescheiden houdt van al het andere dat het bedrijf draait. Anderen bouwen middleware voor elke agent; dat werkt, maar moet voor elke volgende agent opnieuw worden gebouwd.
Alle drie delen ze hetzelfde probleem. Het bedrijf heeft al een plek waar systemen met elkaar verbonden zijn en waar regels over wat er tussen die systemen mag passeren worden afgedwongen. De besturing van de agent ergens anders onderbrengen betekent dat je twee sets regels voor dezelfde systemen moet onderhouden.
Hoe een integratieplatform AI-agentintegratie beheert
Een Integration Platform-as-a-Service (iPaaS) is de centrale plek waar elk systeem één keer verbinding maakt in plaats van rechtstreeks met elkaar te koppelen; het verplaatst en transformeert de data tussen die systemen. Bedrijven gebruiken dit al voor precies dit soort werk: 's nachts webshopbestellingen in het ERP laden, productdata van het PIM naar de webshop pushen en voorraadgegevens terugsturen. Elk van deze processen is geconfigureerd in plaats van geprogrammeerd. Er is al gedefinieerd wat het mag lezen, wat het mag schrijven en wat er wordt vastgelegd wanneer het wordt uitgevoerd.
Een agent maakt op dezelfde manier verbinding. Hij ontvangt geen inloggegevens voor het ERP. Hij krijgt toegang tot de specifieke operaties die voor hem zijn geconfigureerd, en die operaties bevatten de regels en de logging die elke andere integratie op het platform al heeft.
Dat brengt de volgende governance-controles binnen handbereik zonder dat er iets nieuws gebouwd hoeft te worden. Het Alumio-integratieplatform kan worden geconfigureerd om:
- Toegang per verbinding afbakenen: op rollen gebaseerde toegangscontrole en isolatie per omgeving zorgen ervoor dat een agent alleen de specifieke data en operaties bereikt waarvoor hij toestemming heeft, in plaats van dat hij over systeem-inloggegevens beschikt
- Acties uitdrukken als beheerde flows: een agent activeert een Route binnen Alumio die een gedefinieerde operatie uitvoert, waardoor het bereik van mogelijke acties wordt begrensd door configuratie in plaats van door het oordeel van de agent
- Valideren voordat er iets wordt geschreven: een Transformer past dezelfde regels toe als elke andere integratie, waardoor een waarde buiten het bereik wordt geweigerd, ongeacht wie erom vroeg
- Registreer elke actie: het Alumio iPaaS logt wat er werd aangevraagd, wat er werd uitgevoerd en wat het ontvangende systeem teruggaf. Hierdoor is governance voor AI-agents controleerbaar in plaats van gebaseerd op aannames
Omdat die governance al de systemen dekt waar de agent mee werkt, betekent het toevoegen van een agent niet dat er een parallel controlemodel moet worden gebouwd. De volgende agent sluit aan op wat de eerste heeft opgezet.
Wat integratie met AI-agents onder governance mogelijk maakt
De meeste bedrijven zitten op hetzelfde punt vast. IT wil geen agent koppelen aan het ERP zonder te weten wat deze kan aanrichten op een slechte dag. Het operatieteam haalt weinig waarde uit een agent die alleen kan lezen. Dus schrijft de agent e-mails en vat tickets samen, terwijl de processen waar het echt geld zou besparen handmatig blijven.
De uitweg is niet beslissen of agents te vertrouwen zijn. Het is beslissen welke acties veilig zijn om te delegeren onder welke voorwaarden, wat specifieke antwoorden heeft die per proces verschillen. Lezen en opstellen is bijna overal een laag risico. Een betaling uitvoeren niet. De meeste nuttige toepassingen zitten daartussenin, waarbij de agent het werk voorbereidt en een persoon het goedkeurt.
Een integratieplatform maakt die splitsing afdwingbaar in plaats van een beleid dat niemand kan controleren. Het begrenst wat de agent kan doen, valideert wat deze produceert en legt vast wat er is gebeurd.
Het bedrijf kan dan vaker ja zeggen. Agents gaan aan de slag met orderafhandeling, retouren en communicatie met leveranciers, in plaats van alleen bij samenvattingen en concepten te blijven.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
