De mentaliteit dat ‘AI magie is’ doorbreken: waarom inzicht in de werking van AI-modellen een bedrijfsbrede prioriteit moet zijn

Te midden van waarschuwingen voor ontspoorde AI-agenten gaf een ontwikkelaar onlangs een programmeeragent vrij spel op een machine zonder back-up op afstand. De agent verwijderde 48.000 bestanden in minder dan twee minuten.

Dit soort voorvallen herinnert ons er op indringende wijze aan dat de inzet van AI-agenten risico’s met zich meebrengt; het is niet genoeg om ergens in een complex proces een menselijke beoordelaar toe te voegen en ervan uit te gaan dat het veilig is. Sommige processen vereisen geen tussenkomst, terwijl andere veel strengere controles nodig hebben. Een typefout herstellen en duizenden bestanden verwijderen brengen duidelijk niet hetzelfde risiconiveau met zich mee. Het toezicht moet dus aansluiten bij wat er daadwerkelijk op het spel staat.

Organisaties moeten beter leren herkennen wanneer menselijk oordeel er echt toe doet, vooral wanneer een handeling grote gevolgen heeft of moeilijk terug te draaien is. En als agenten fouten maken, moet de omgeving de omvang van de schade beperken.

AI is niet deterministisch, maar probabilistisch

Allereerst is het essentieel dat iedere medewerker die direct of indirect betrokken is bij softwareontwikkeling, een basisbegrip krijgt van de manier waarop AI-modellen informatie verwerken. Dat is geen geringe opgave: het vereist dat teams zich inzetten voor scholing, die uiteindelijk een bedrijfsbrede doelstelling moet worden.

Wanneer iemand voor het eerst met AI aan de slag gaat, voelt het als magie. Je typt een zin en plotseling voer je een gesprek. Een basisbegrip van de manier waarop modellen en training achter de schermen echt werken, is belangrijk voor het bepalen van bedrijfsbreed AI-beleid op het gebied van beveiliging en productiviteit. Het neurale netwerk, de tokenisatie en de statistische analyse die daarachter plaatsvinden, en de manier waarop die vervolgens tot uitvoer leiden, bieden alle medewerkers in het bedrijf een belangrijke kans om meer te leren.

Grote taalmodellen zullen nooit deterministische resultaten opleveren. De uitvoer is probabilistisch. Bij gewone software heb je, wanneer je invoer geeft, bepaalde verwachtingen over de mogelijke uitvoer, bijvoorbeeld A, B of C. Maar bij AI kun je F krijgen, een & of een beschrijving van een kat met een zonnebril.

Wanneer iets probabilistisch is, kun je het niet op de gebruikelijke manier testen. Je hebt een manier van testen nodig waarmee je snel kunt bijsturen, redeneren, begrijpen en context kunt ophalen, om de probabilistische elementen op te merken en de problemen te herkennen die ze kunnen veroorzaken. Afhankelijk van de omvang en de risico’s kan AI deze tests uitvoeren, of kan een mens met de juiste expertise dat doen. Een mens in het proces opnemen is vooral in het begin nuttig: zo kun je het probleem dat moet worden opgelost duidelijk afbakenen en de resultaten vervolgens aan het einde beoordelen.

Omdat ontwikkelaars het beste zicht hebben op de variabelen en gangbare werkwijzen die bepalen hoe de interne AI van hun organisatie op basis van invoer tot antwoorden komt, kunnen zij goed bijdragen aan de AI-scholing binnen hun bedrijven. Ook kunnen ze ervoor zorgen dat iedereen het verschil begrijpt tussen determinisme en probabilisme in AI, en waarom dat ertoe doet. Het doel is af te komen van de opvatting dat AI gebruiken hetzelfde is als magie en dat je tevreden bent met welke uitvoer er ook uitkomt. In plaats daarvan moeten organisaties ernaar streven de modellen die het bedrijf gebruikt, de manier waarop ze worden ingezet, de problemen die zich kunnen voordoen, de controles die erop worden uitgevoerd en de resultaten van dat proces inzichtelijk te maken.

Waarborgen horen thuis in de infrastructuur, niet in het model

Zodra de ‘magie’ van AI is ontkracht en een AI-project van start is gegaan, is het van cruciaal belang om een transparant auditbeleid op te stellen. Zo kan worden gecontroleerd of alles volgens verwachting verloopt. Levert het project ‘slechte’ resultaten op of blijven die onder de maat, dan kan de verantwoordelijke de uitgevoerde stappen controleren en voorkomen dat het probleem zich opnieuw voordoet. Dit beleid biedt ook voordelen wanneer de resultaten beter zijn dan verwacht: de stappen kunnen dan worden herhaald en met andere projecten of groepen worden gedeeld.

Het is vooral belangrijk om dit proces systematisch in te richten bij grotere bedrijven, waar elk team uit tientallen ontwikkelaars kan bestaan en honderden ontwikkelaars gedurende de dag code kunnen aanpassen. AI kan veel dingen heel snel doen en als er iets misgaat, moet er een systeem zijn om precies vast te stellen in welke stap het probleem is ontstaan. Kijk naar de agenten van OpenAI die deze zomer bij Hugging Face inbraken. OpenAI testte hoe goed zijn modellen softwarekwetsbaarheden konden misbruiken met behulp van een benchmark genaamd ExploitGym. Voor de test versoepelde het bedrijf bewust de weigeringen van de modellen om offensieve cyberactiviteiten uit te voeren. De enige uitweg uit de sandbox was een pakketproxy. De modellen ontdekten een onbekende kwetsbaarheid in die proxy, ontsnapten en brachten meer dan twee dagen door in de productieomgeving van Hugging Face, op zoek naar de testantwoorden.

Krantenkoppen noemden het ontspoorde AI. Ik zou het een deterministische opzet rond een probabilistisch systeem noemen. OpenAI gaf de modellen de opdracht om te hacken en vertrouwde er vervolgens op dat ze het verwachte pad zouden volgen. Volgens de maker van de benchmark hadden modellen eerder al valsgespeeld tijdens de test, maar altijd binnen de sandbox. Deze keer bleef één model daar niet binnen. Standaardwaarborgen gaan uit van standaardgedrag, maar AI hoeft zich niet aan standaarden te houden.

Daarom draait AI-beveiliging om toegang en beheersmaatregelen die door de omgeving worden afgedwongen, en niet om de aanname dat het model zich goed zal gedragen. Ga ervan uit dat de agent elke deur zal proberen en laat alleen de deuren open die hij nodig heeft. De agent die 48.000 bestanden verwijderde, had de opdracht gekregen om met kopieën te werken en de originelen ongemoeid te laten. Toch verwijderde hij de originelen. Instructies zijn geen beheersmaatregelen.

Het beheren van agentmachtigingen is vergelijkbaar met het inwerken van een nieuwe juniorontwikkelaar. Je zou diegene op de eerste dag geen roottoegang tot de productieomgeving geven. Als je dat wel deed en diegene je database verwijderde, zou je dat niet afdoen als het werk van een geniale hacker. Bij beveiligingsincidenten van welke omvang dan ook is het essentieel om de hoofdoorzaak vast te stellen. Ligt het aan het model? Aan het bedrijf dat het model heeft gemaakt? Aan het bedrijf dat het model toegang heeft verleend? Wat de oorzaak ook is, uiteindelijk is een mens verantwoordelijk.

Een belangrijk punt dat we vandaag moeten aanpakken, is ten slotte wat zich buiten het zicht afspeelt op de laptop van een ontwikkelaar. Vroeger was de workflow eenvoudiger te traceren. Ontwikkelaars schreven code, beoordeelden die en leverden die op, waardoor er een duidelijk spoor terug was naar het moment waarop het misging. Nu kan een ontwikkelaar een agent een ticket geven met de opdracht: ‘los dit op’. Als dat werk buiten het zicht plaatsvindt, valt er niets te traceren. Elke stap moet volledig worden vastgelegd: welke agent actief was, welk model die gebruikte, welke prompts die kreeg, welke tools die aanriep en over welke machtigingen die op dat moment beschikte. Agents centraal uitvoeren in plaats van op afzonderlijke laptops is één manier om dat te bereiken. Het belangrijkste is dat het spoor er is.

Uiteindelijk moet elk bedrijf zichzelf beschermen als zich een incident voordoet. Dat spoor moet voldoende informatie bevatten om een hoofdoorzaakanalyse uit te voeren en vast te stellen welke stap en welke code het probleem hebben veroorzaakt.

AI heeft de wereld ingrijpend veranderd en bedrijfsprocessen moeten daarin meegaan. Om de juiste waarborgen vast te stellen, is een beter begrip nodig van AI-processen, tests, beoordelingscycli en auditcycli, zowel binnen ontwikkelaarsteams als in het hele bedrijf.