Betrouwbaarheid is de echte test voor agentische AI

De afgelopen twee jaar heeft de industrie één vraag gesteld: zijn AI‑agenten capabel genoeg om echt werk aan te kunnen? We kunnen die vraag laten rusten. We weten dat ze dat kunnen, maar we moeten ons laser‑gericht richten op of we kunnen identificeren wanneer een agent op het punt staat een kostbare fout te maken – en of we die kunnen stoppen voordat deze gebeurt.

De ergste fouten in productie lijken meestal niet op een nette model‑fout. Een agent kan elke API‑aanroep succesvol voltooien en toch werken vanuit verouderde context, een defecte tool opnieuw proberen, of op weg gaan naar een actie die een regel schendt. Betrouwbaarheid bepaalt of een agentisch AI‑programma de pilotfase overleeft.

Volgens “De staat van AI in 2025: Agenten, innovatie en transformatie,” een McKinsey onderzoek, experimenteert 62 % van de organisaties met AI‑agenten, maar slechts ongeveer tien procent schaalt niet op een van deze functies. Het is gemakkelijk om collega’s te laten zien dat een agent werkt. Het veilig laten draaien van een agent, met echte data en verbonden systemen, is dat niet.

Waarom agentische AI risico’s vergroot

Agenten combineren probabilistisch redeneren, toolgebruik en een zekere mate van autonomie. Hoewel dit hen nuttig maakt, stelt het bedrijven ook bloot aan fouten die sneller opstapelen dan in een meer traditionele toepassing.

Context

Agenten kunnen alleen werken met de verstrekte context. Daarom, als die context onvolledig, verouderd of onjuist is, draagt een slechte interpretatie in een vroeg stadium zich voort naar elke volgende stap. Een foutieve chatbot‑reactie is irritant. Een foutieve interpretatie die een toegangs‑recht wijzigt of infrastructuur aanraakt, is een incident. Het is belangrijk om te weten of de agent het juiste bewijs heeft gebruikt, het beleid heeft gevolgd en binnen een acceptabele impactzone is gebleven als er iets misgaat.

Kennisbanken

Agenten sluiten ook aan op kennisbanken, ticketingsystemen en betaalplatformen; elke verbinding vergroot het aanvalsoppervlak. Een agent kan de verkeerde tool aanroepen, de juiste tool in de verkeerde volgorde aanroepen, of handelen op instructies die verborgen zitten in opgehaalde inhoud. Dit zijn erkende faalmodi, en ze omvatten verzinsel en beveiligingskwetsbaarheden die voortkomen uit het proces waarbij agenten tools en context aan elkaar schakelen.

Een groen dashboard kan je misleiden: de infrastructuur lijkt in orde terwijl een agent stilletjes dezelfde tool steeds opnieuw raadpleegt. Dit is een vroeg teken van drift in plaats van een normale storing.

Niet‑determinisme

Niet‑determinisme maakt incidentrespons ook moeilijker. Een traditionele service‑fout kan meestal worden gereproduceerd met een request‑ID en een bekende software‑versie. Een agent‑run hangt af van de modelversie, de documenten die hij heeft opgehaald, de tool‑outputs die hij heeft ontvangen, en een keten van tussenbeslissingen. Zonder een registratie van wat de agent heeft ontvangen en geprobeerd, worden zowel root‑cause‑analyse als governance veel moeilijker.

Kosten en latentie

Kosten en latentie vertellen hetzelfde verhaal vanuit een ander perspectief. Een plotselinge stijging in token‑gebruik of retries kan wijzen op een slecht plan of een lus, zelfs als de gebruiker uiteindelijk een antwoord krijgt. Inference‑kosten zijn sterk gedaald de afgelopen paar jaar, en goedkopere inference maakt het makkelijker om inefficiënt gedrag te negeren totdat dat gedrag zich herhaalt in duizenden workflows. Beschouw kosten, latentie en retries als betrouwbaarheids‑signalementen – niet alleen als financiële metriek.

Gedecentraliseerde AI heeft nog steeds gecentraliseerde zichtbaarheid nodig

Decentralisatie faalt zonder duidelijke richtlijnen. Leg de eigendom van workflows en escalaties bij de front‑line teams, maar houd identiteit, toegang en incidentrespons op ondernemingsniveau. Een finance‑team kan het verschil zien tussen een legitieme factuur‑uitzondering en een onjuiste betalingsbeslissing op een manier die een generieke benchmark nooit kan. In dezelfde enquête vond McKinsey dat organisaties die een reëel AI‑effect rapporteerden bijna drie keer vaker hun workflows hadden herontworpen, in plaats van AI simpelweg toe te voegen aan wat al bestond.

Dat gezegd hebbende, de afweging is reëel: eigenaarschap wordt snel vaag wanneer een incident systemen overspant. De oplossing is een gedeeld operationeel overzicht van elke agent, zijn tools, zijn data‑toegang en zijn incidentgeschiedenis.

Gedecentraliseerde architecturen maken het gemakkelijk om het volledige overzicht te verliezen wanneer er iets kapot gaat. Veel teams kunnen token‑volume en kosten zien, maar ze kunnen niet zien of een agent het beoogde resultaat veilig heeft behaald. Wanneer records binnen een workflow op verschillende locaties staan, eindigen teams met het achtervolgen van symptomen in plaats van oorzaken.

Gestandaardiseerde telemetriesignalen, zoals model‑identiteit en tool‑aanroepen, kunnen helpen. Gedragsbaselines, zoals het normale aantal stappen in een workflow, zijn ook nodig om nuttige persistentie van een vastgelopen systeem te identificeren. Evaluatie is geen eenmalige poort vóór de lancering. Het is een continue lus.

Hoe betrouwbare AI er in de praktijk uitziet

Betrouwbare AI gaat over het beheren van fouten, niet over het vermijden ervan. Teams hebben zichtbaarheid op gedrag nodig; waarschuwingen wanneer de prestaties afwijken; en een containment‑plan voor wanneer er iets misgaat. Het belangrijkste is dat elke agent duidelijke grenzen heeft rond toegang en autonome acties. Ze hebben ook menselijke goedkeuring nodig. 

Begin met laag‑risicowaarnemingen die ongedaan gemaakt kunnen worden. Houd de consequentiale acties, zoals productie‑wijzigingen en financiële transacties, achter echte controles. Consequentiale workflows moeten achteraf kunnen worden gereconstrueerd, inclusief de context die de agent heeft opgehaald, de tools die hij heeft aangeroepen, de goedkeuringen die hij heeft verkregen, en of het resultaat daadwerkelijk correct was.

Traditionele service‑leveldoelstellingen moeten zich ook uitbreiden tot agentkwaliteit en -veiligheid; ze omvatten een gevalideerd taak‑succespercentage, een nalevingspercentage van beleid, een escalatieratio voor menselijk ingrijpen, de kosten per geslaagde taak, en hoe vaak ongewenste uitkomsten voorkomen. Drempels moeten per use‑case variëren. Een interne kennisassistent kan een ander foutprofiel tolereren dan een agent die met gereguleerde data werkt.

De meest bruikbare betrouwbaarheidssystemen leren de omstandigheden te herkennen die vaak voorafgaan aan een fout, zoals een abnormale sprong in retries of een pad dat historisch heeft geleid tot handmatige overrides. Een laag‑risicoworkflow kan een automatische correctie activeren. Een hoger‑risicoworkflow moet pauzeren en de beslissing doorsturen naar een geautoriseerde persoon. Het doel is niet autonome actie omwille van de actie zelf. Het doel is snellere, veiligere actie wanneer het bewijs dit ondersteunt.

AI SRE sluit de lus

Hier komt AI‑SRE in beeld. Een AI‑SRE‑agent kan een incidenttijdlijn samenstellen, het huidige gedrag vergelijken met eerdere incidenten, en een aanbevolen actie voorbereiden, terwijl de organisatie gecontroleerde herstelacties behoudt voor omkeerbare taken en menselijke goedkeuring voor alles wat consequential is.

AI‑adoptie gaat snel. Maar adoptie is niet hetzelfde als operationele volwassenheid. De ondernemingen die agent‑AI succesvol opschalen, zullen niet per se degenen zijn die het meest capabele model in isolatie draaien. Het zullen degenen zijn die kunnen zien hoe hun agents zich gedragen binnen het hele bedrijf, vroege signalen van drift opvangen, en ingrijpen voordat een kleine fout uitgroeit tot een klant‑, beveiligings‑ of compliance‑incident. 

Dat is de rol die AI‑SRE vervult: gedecentraliseerde innovatie verbinden met gecentraliseerde zichtbaarheid en agent‑AI omvormen tot een systeem dat de onderneming kan vertrouwen.