Wat als het model morgen niet meer bereikbaar is?

Zodra AI-agenten echt werk gaan doen in een organisatie, hangt dat werk aan iets dat je niet zelf beheert: een model bij een aanbieder, via een internetverbinding, tegen een prijs en onder voorwaarden die de aanbieder bepaalt.

Dat is op zichzelf niets bijzonders. Elke organisatie hangt aan leveranciers van stroom, internet, betaalsystemen en software. Het verschil is dat AI zich snel in veel processen tegelijk nestelt, en dat een model niet zomaar vervangbaar is door een ander: het gedraagt zich anders, kost anders en valt onder andere regels.

In dit stuk loop ik door de dingen die kunnen veranderen, en daarna door wat je kunt inrichten zodat een verandering een gebeurtenis wordt en geen crisis. Het is geen standpunt over de wereld, maar een ontwerpvraag.

Een deel van de ideeën komt uit mijn boek AI-agenten die het werk doen. Een ander deel komt uit de omgeving waarin ik zelf agents laat werken, waar meerdere AI-aanbieders in een vaste volgorde klaarstaan, waar budgetten en plafonds gelden en waar ik controles pas vertrouw als ik ze heb zien falen.

Eerst de scenario's, nuchter

Er zijn vijf soorten verandering die ertoe doen. Ze vragen elk iets anders van je ontwerp. Geen ervan is een voorspelling. Het zijn soorten verandering die in de techniek, of in de wereld eromheen, al eerder zijn voorgekomen.

1. Een model of aanbieder is niet meer bereikbaar. De oorzaak kan klein of groot zijn: een storing van een uur, een account dat wordt stilgelegd, een sleutel die verloopt, een aanbieder die een regio niet meer bedient, of handelsmaatregelen en sancties die het aanbod voor bepaalde landen of klanten veranderen. Voor je agent is het resultaat hetzelfde: een deur die dichtgaat. Wat verschilt is de duur. Een storing van een uur los je op met opnieuw proberen. Een uitval van weken vraagt om een andere weg en om besluiten van mensen.

2. Nieuwe of strengere regels. Regelgeving rond AI is in beweging. In Europa is de AI-verordening gefaseerd van kracht geworden. Ze deelt toepassingen in naar risico: sommige zijn verboden, voor andere gelden strenge eisen, voor weer andere vooral transparantieplichten, en voor de rest vrijwel niets. Welke termijnen voor jouw toepassing gelden, hangt af van de categorie en kan verschuiven. Controleer de actuele stand en vraag het aan wie er verstand van heeft. Daarnaast zijn er regels over persoonsgegevens en het doorgeven daarvan buiten Europa, en sectorregels. Voor financiële instellingen bestaan bijvoorbeeld al eisen over het beheersen van ICT-leveranciers, waaronder een plan om weg te kunnen bij een leverancier. Een regel kan een proces beperken, een andere plek voor je gegevens eisen, of vragen dat je kunt aantonen wat een agent deed.

3. Een aanbieder verandert het model. Aanbieders verbeteren modellen, vervangen ze door opvolgers en nemen oude uit gebruik. Meestal met een aankondiging, soms met weinig tijd. Zelfs bij een verbetering kan jouw proces raken: een antwoord dat altijd drie regels was, wordt er vijf, een datum komt in een andere notatie, een voorzichtigheid die er eerst niet was, is er nu wel. Dit heet drift. Het is vervelend omdat er niets stuk is, en niemand een melding krijgt. Het werk gaat door, alleen net anders.

4. Prijzen stijgen of limieten krimpen. Een proces dat gisteren loonde, loont vandaag niet meer, of een limiet die ruim was, blijkt ineens krap. Ook een agent in een lus die zichzelf blijft herhalen, kan de rekening opblazen zonder dat er iets aan de buitenkant verandert. Deze kun je deels zelf voorkomen.

5. Spanning in de keten eromheen. Een AI-model draait op chips, in datacenters, via cloudplatformen en netwerken. Elke schakel kent concentratie: er zijn weinig fabrikanten van de meest gebruikte chips, een beperkt aantal grote cloudaanbieders, en handel in rekenkracht kan te maken krijgen met exportregels of handelsmaatregelen. Voor jouw ontwerp betekent het vooral dat een afhankelijkheid van één aanbieder vaak ook een afhankelijkheid van één land, één cloud of één type chip is.

Deze vijf vragen elk een andere reactie. De eerste vraagt om een tweede weg. De tweede om aantoonbaarheid en flexibiliteit in waar dingen staan. De derde om een manier om gedrag te meten. De vierde om grenzen. De vijfde om spreiding.

Het uitgangspunt: afhankelijkheid is geen probleem, verstopte afhankelijkheid wel

Maak eerst een lijst: welke processen draaien op AI, via welke aanbieder, met welke sleutel, en wie merkt het als het stopt? Je kunt pas een afhankelijkheid beheren die je kent.

Het doel is niet om onafhankelijk te worden van alle aanbieders. Dat lukt niemand en het is ook niet nodig. Elke leverancier mag onmisbaar zijn voor wat hij levert. Geen enkele mag onmisbaar zijn voor wat van jou is.

Wat van jou is: de opdrachten die je agents krijgen, de voorbeelden waarmee je weet of ze het goed doen, de logboeken van wat ze deden, de sjablonen en gegevens van je klanten, en de beslisregels wie wat mag. Het model zelf is het enige onderdeel dat echt van de aanbieder is. Een ontwerp waarin alles wat van jou is, in jouw handen blijft, maakt het model een verwisselbaar onderdeel.

De laag tussen je werk en het model

Het belangrijkste ontwerpprincipe is ook het simpelste: laat geen proces rechtstreeks met een model praten. Zet er een eigen laag tussen.

In de praktijk is dat een klein stuk eigen software of configuratie met één taak: een verzoek aannemen, het naar een model sturen, het antwoord teruggeven en opschrijven wat er gebeurde. De processen praten met jouw laag, de laag praat met de aanbieder.

Wat dat oplevert:

• Wisselen kost één plek. Als je van aanbieder of model verandert, pas je het op één plek aan, niet in elk proces.
• Je ziet alles op één punt. Verbruik, fouten, tijden en kosten komen langs dezelfde plek.
• Je kunt regels afdwingen. Wat nooit naar een externe aanbieder mag, zoals bepaalde gegevens, houd je hier tegen, ongeacht wat een proces vraagt.
• Je kunt terugvallen. De laag weet wat de volgende keuze is als de eerste niet werkt.

Meer dan één aanbieder, met een volgorde

Een tweede aanbieder is de meest directe reactie op het eerste scenario, en ook de meest onderschatte. Er zijn drie dingen waar het vaak misgaat.

Het eerste is dat de reserve nooit is getest. Een tweede aanbieder die je ooit instelde en daarna nooit liet werken, is een aanname. Pas als er regelmatig echt werk of een geplande proef doorheen gaat, weet je dat de sleutel nog geldt, de limiet ruim genoeg is en het resultaat bruikbaar.

Het tweede is dat de overgang niet wordt gemeld. Als het werk stilletjes naar een andere aanbieder gaat, merkt niemand dat de kwaliteit of de kosten veranderden. Wie dat wil weten, moet een bericht krijgen: er is omgeschakeld, hier staan de gevolgen.

Het derde is dat een opdracht die op het ene model goed werkt, op een ander slordig kan uitpakken. Schrijf opdrachten zo neutraal mogelijk en test ze op beide.

In de omgeving waarin ik zelf werk, staat een volgorde van aanbieders vast: als de eerste niet antwoordt, gaat het werk naar de volgende. Het is niet ingewikkeld: een lijst met een vaste regel erboven.

Een trap van terugval, niet een schakelaar

Terugvallen is zelden alles of niets. Een nuttig beeld is een trap met vier treden:

1. Het beste model, zoals je het normaal gebruikt.
2. Een goedkoper of kleiner model, bij dezelfde of een andere aanbieder: korter, minder diep, soms met meer fouten.
3. Een klein model op eigen apparatuur, in Europa of op je eigen computer: eenvoudig werk, zonder internet en zonder sleutel van een ander.
4. Een vaste regel: geen model, maar een sjabloon of tabel. Het kan weinig, en het is het enige wat altijd werkt.

Bij elke trede schrijf je op wat je inlevert en wat je houdt. Een goedkoper model schrijft een kortere maar correcte mail. Een klein lokaal model sorteert binnenkomende post. Een vaste regel stuurt een ontvangstbevestiging, zodat een klant weet dat iemand ermee bezig is. Een deel van het werk blijft doorlopen, en een mens hoeft alleen het lastige stuk te doen.

Niet elke taak hoort op elke trede. Drie vragen helpen. Wat kost een fout? Een verkeerde datum in een bevestiging is duur, een stijve openingszin niet. Gaat het werk naar buiten zonder dat een mens het ziet? Dan blijft het op de hoogste trede of het wacht. Is het uitstelbaar? Een taak die een dag kan wachten, hoeft niet terug te vallen: hij wacht op het beste model. Zo'n taak valt niet terug. Ook dat is een keuze, en die hoort ergens te staan.

Voor een kritiek proces is een model dat je zelf kunt draaien, op eigen apparatuur of bij een Europese aanbieder, een ondergrens die niemand van buiten kan uitzetten. Niet omdat het beter is, maar omdat het van jou is.

Drift zien voordat een klant het ziet

Als een aanbieder een model verandert, wil je dat weten voor je klant het merkt. De manier is saai en betrouwbaar: een vaste toetsset.

Maak een lijst van een paar tientallen vragen die voor jouw proces typisch zijn, en schrijf bij elke vraag wat een goed antwoord moet bevatten en wat het niet mag bevatten. Laat die set periodiek langs het model lopen, en altijd voor en na een wissel. Tel de afwijkingen in plaats van ze te voelen. Het gaat niet om perfectie, maar om verschil: wat anders is dan vorige keer, kijk je na.

Drie gewoonten maken dit werkbaar:

• Versie vastzetten waar het kan. Sommige aanbieders laten je een bepaalde modelversie kiezen. Doe dat, en noteer wanneer de aanbieder die versie uit gebruik neemt, zodat jij het moment van wisselen kiest.
• De set hoort bij jou, niet bij de aanbieder. Zo kun je dezelfde set op een tweede model loslaten en vergelijken wat je kunt verwachten voor je overstapt.

Kosten: een plafond met een gevolg

Voor het vierde scenario, prijzen en limieten, zijn grenzen de eerste verdediging. Zet budgetten per taak en per dag, niet één voor het geheel. Eén uitschieter in één proces moet de rest niet meenemen.

Het onderscheid dat ertoe doet: wat gebeurt er als het plafond wordt bereikt? Een plafond zonder gevolg is een alarm dat niemand hoort. Een plafond dat het werk stillegt zonder melding is zelf een uitval, nu met een nette verklaring. Beide komen voor. Wat je wilt, is dat bij een bereikte grens duidelijk is wie er bericht krijgt, wat er blijft liggen en wat doorgaat.

Daarnaast is de rekening zelf een vroege waarschuwing. Vergelijk het verbruik van vandaag met dat van gisteren, per taak. Een sprong is een reden om te kijken, ook als alles werkt. En maak een rekensom per proces: wat kost een uitkomst, en bij welke prijs loont het niet meer? Dan weet je van tevoren welke processen een prijsstijging kunnen dragen en welke naar trede 2 of 3 moeten.

Eigen beheer van wat telt

Met het tweede scenario, regels, komt een andere vraag op: kun je laten zien wat een agent deed, en kun je je gegevens verplaatsen?

• Opdrachten en voorbeelden als bestanden. De opdrachten van je agents, met geschiedenis, en de voorbeeldsets met goede antwoorden staan bij jou, niet alleen in de interface van een aanbieder. Controles zoals "een bedrag boven een grens gaat naar een mens" zitten in je eigen laag, niet in een zin die het model moet onthouden.
• Logboeken in eigen beheer. Wat een agent zag, besloot en deed, staat op een plek die jij beheert. Niet alleen in het dashboard van de aanbieder. Zo kun je achteraf reconstrueren wat er gebeurde, ook als er iets uitvalt of verandert.
• Gegevens en sjablonen met een kopie buiten de dienst. Dat is ook je uitweg als je moet overstappen.
• Weet waar je gegevens heen gaan. Welke gegevens gaan naar welke aanbieder, in welk werelddeel, en wat gebeurt er mee? Zes vragen aan elke aanbieder zijn genoeg om te beginnen: waar mijn gegevens heen mogen, wat er met mijn invoer gebeurt, hoe veranderingen worden aangekondigd, wat er gebeurt als een model uit gebruik gaat, wat ik kan exporteren en wat er gebeurt bij een betalingsprobleem. Schrijf de datum op waarop je de antwoorden las, want voorwaarden veranderen.

Het proces blijft ook met de hand uitvoerbaar

Techniek vangt de korte uitval, voor de lange is organisatie nodig. Als de agent een week niet werkt, kunnen mensen het werk dan doen?

Daarom hoort bij elk proces dat op AI draait een beschrijving van de handmatige variant: welke stappen, wie, met welke hulpmiddelen, en hoe lang kun je het volhouden. Het vraagt dat je het proces ook zonder AI doorloopt, juist als het goed draait. Dat voelt als een stap terug. Het is wat je nodig hebt op de dag dat het moet.

Denk in drie standen:

• Volledig: de agents doen het werk, mensen kijken aan de rand mee.
• Beperkt: de agents doen het deel dat op de lagere treden past; mensen doen wat niet kan.
• Handmatig: mensen doen het hele proces, met de lijsten en sjablonen die de agents ook gebruikten.

Beschrijf bij elke stand wie dat besluit, hoe iedereen het hoort, en hoe je terugkeert. Dat laatste wordt vaak vergeten: terugkeren is werk. Wat tijdens de uitval halverwege was, moet worden afgemaakt, en een melding mag niet blijven doorgaan als alles weer werkt.

Wie besluit, en wat staat er op één pagina

Bij een incident is het gebrek aan besluiten het grootste risico, niet het gebrek aan techniek. Wie mag zeggen dat het werk naar de handmatige stand gaat? Wie spreekt met klanten? Wie belt de aanbieder?

Een draaiboek op één pagina is genoeg om te beginnen. Zet erop:

• de tijdgrenzen: na hoeveel tijd gaat er een melding, en na hoeveel tijd gaat een proces naar de volgende stand
• wie bij welke stand besluit, met een vervanger
• wat jullie tegen klanten zeggen
• waar de lijsten, sjablonen en kopieën staan
• wie de aanbieder benadert, en via welk kanaal

De tijdgrenzen zijn van jou. Bij elke organisatie loopt de klok anders: een vertrekdatum, een sluitingstijd van een pakketdepot, een aangiftedatum. Kies de grens aan de hand van de klok van het proces.

Oefenen: trek de stekker eruit

Een controle die je nooit hebt zien falen, weet je niet dat hij werkt. Dat geldt voor je reserve, je melding en je draaiboek. Oefen daarom met opzet.

Er zijn vier manieren om uitval na te spelen, in een omgeving waar dat veilig kan: een sleutel weghalen of onjuist zetten, het plafond op een laag getal zetten, de verbinding naar een aanbieder dichtdoen, of in de instellingen een modelnaam kiezen die niet bestaat. Elk speelt een van de scenario's na.

Bij elke oefening stel je drie vragen en schrijf je een antwoord op, met een tijd erin:

1. Merkt iemand het? Na hoeveel minuten komt er een melding, bij wie, met welke tekst?
2. Gaat de reserve werken? En is het resultaat bruikbaar?
3. Komt het werk terug? Als je de stekker terugzet, gaat het systeem dan weer naar boven, zonder dubbel of onaf werk?

Een oefening levert een korte lijst op. Geef elk punt een eigenaar en een datum, anders blijft het een verslag, en herhaal het na elke grote wijziging.

Een checklist per fase

Bij het introduceren van een agent

• Praat het proces via een eigen laag, en niet rechtstreeks met een model?
• Staat de opdracht als bestand, met geschiedenis, in jouw beheer?
• Is er een voorbeeldset met goede antwoorden voor dit proces?
• Staat er een plafond, en weet je wie bericht krijgt als het wordt bereikt?
• Is beschreven hoe het proces met de hand gaat?
• Is vastgelegd welke gegevens naar welke aanbieder gaan?

Bij het opschalen

• Is er een tweede aanbieder of model, en heb je het echt laten werken?
• Is de terugvaltrap voor dit proces ingevuld, met per trede wat je inlevert?
• Komt er een melding bij elke stap omlaag?
• Zijn de logboeken in eigen beheer en terug te lezen?

Bij het onderhouden

• Loopt de voorbeeldset periodiek en voor en na elke wissel?
• Is de modelversie vastgezet waar het kan, en weet je wanneer die verdwijnt?
• Zijn de voorwaarden van aanbieders opnieuw gelezen na een wijziging?
• Is de uitvalsoefening dit kwartaal gedaan, en zijn de punten opgelost?
• Zijn de kopieën van je eigen gegevens niet te oud?

Vragen voor het management

Dit zijn vragen die je kunt stellen zonder zelf technisch te zijn, en waarvan het antwoord veel zegt.

1. Welke processen draaien op AI, en welke daarvan zijn kritiek voor de klant of voor de omzet?
2. Welke aanbieders zitten erachter, en wat is er voor elk kritiek proces als terugval?
3. Hoe lang kunnen we zonder AI doorwerken, en met welke handelingen?
4. Wie besluit bij een uitval, en weten ze dat?
5. Wat is het maximale verbruik per proces per dag, en wat gebeurt er als het wordt bereikt?
6. Wanneer hebben we voor het laatst geoefend, en wat ging mis?
7. Welke gegevens en opdrachten van ons staan alleen bij een aanbieder?

Je hoeft niet alle vragen morgen te beantwoorden. Begin met de eerste. De rest volgt uit wat je dan ontdekt.

Wat het kost, en wat het oplevert

Dit kost werk, maar je hoeft het niet tegelijk te doen. Een lijst van je afhankelijkheden en een plafond met een melding zijn in een dag te regelen. De rest bouw je per proces op, beginnend bij het proces dat het meest kost als het stilvalt.

Wat het oplevert, is lastig te meten, en dat is eerlijk. Het werkt als een verzekering: je merkt het op de dag dat er iets gebeurt. Wat je wel nu al merkt, is overzicht. Je weet wat er van jou is, en wat bij een ander staat. Een verandering wordt een punt op de lijst in plaats van een verrassing.

Het antwoord op de vraag in de titel is dus niet dat het niet kan gebeuren. Het antwoord is: zo richt je het in, zodat je erop voorbereid bent.

#AI #AIagents #Werkprocessen #Risicobeheersing

Alle stukken