AI-waarborgen voor bedrijven zijn mogelijk belangrijker dan de AI-voorhoede

Vergeet de AI-voorhoede. Klanten dringen er bij bedrijven op aan meer waarborgen in te voeren voor AI die al wordt gebruikt, en de ervaring met PCI DSS biedt een bruikbaar model.

De wittebroodsweken van AI-regulering zijn voorbij. Recente onthullingen hebben geleid tot gesprekken over het afremmen van de AI-voorhoede en het verplicht stellen van beheersmaatregelen. Een van de weinige punten van overeenstemming is dat deze maatregelen buiten de modellen moeten worden toegepast en onafhankelijk moeten worden geverifieerd.

Er wordt nog gedebatteerd over wat er hierna gebeurt, maar toezichthouders komen in beweging. De AI-verordening van de Europese Unie voert beveiligingsverplichtingen gefaseerd in, waaronder aansprakelijkheid voor afnemers. In de Verenigde Staten wordt het NIST-raamwerk voor AI-risicobeheer als norm voor passende zorgvuldigheid ingevoerd. Wereldwijd is de OWASP Top 10 voor LLM-toepassingen een gangbaar referentiekader geworden bij beveiligingsbeoordelingen, en duikt de ISO/IEC 42001-certificering op in aanbestedingsdocumenten.

Dat betekent dat niet alleen modelontwikkelaars verantwoordelijk zijn. Ook bedrijven die reeds uitgebrachte modellen gebruiken, krijgen te maken met beveiligingsverplichtingen en -risico’s, vooral bij toepassingen met een hoog risico. Onjuiste antwoorden op een beveiligingsvragenlijst van een klant of in een reactie op een offerteaanvraag (RFP) kunnen een zakelijke B2B-deal vertragen.

PCI DSS wijst de weg

Gelukkig hebben we dit al eens meegemaakt. Twintig jaar geleden berustte de beveiliging van webapplicaties vooral op periodieke code-audits, statische scans en de discipline van ontwikkelaars. Vervolgens bepaalde PCI DSS-vereiste 6.6, uitgebracht in 2006 en van kracht vanaf 2008, dat organisaties die kaarthoudergegevens verwerken alle applicatiecode op kwetsbaarheden moesten controleren óf geautomatiseerde technische maatregelen moesten installeren. Later verviel de mogelijkheid om code te laten controleren en werden technische maatregelen verplicht.

PCI DSS begon echter niet als wet. Het begon als een contractuele norm die de markt ingrijpend veranderde, waarschijnlijk sneller dan wetgeving dat zou hebben gedaan, omdat contracten sneller tot stand komen dan overheidswetten.

Ook voelen organisaties nu druk om waarborgen in te voeren voor AI die al in gebruik is, niet van toezichthouders maar van klanten en partners, via beveiligingsvragenlijsten, bepalingen in offerteaanvragen en eisen in verzekeringspolissen.

Los het operationele probleem op en naleving volgt vanzelf

Die druk kan lastig aan te pakken zijn, omdat AI-governance niet alleen over beleid gaat. Het draait ook om doorlopend technisch bewijs.

Veel bedrijven waarmee ik praat, gebruiken zes of meer modellen in productie. Ze koppelen of orkestreren die modellen vaak zo dat de uitvoer van het ene model als invoer voor een ander dient. Stel dat u onder deze omstandigheden moet aantonen dat één bepaald beleid overal in het systeem wordt gehandhaafd, bijvoorbeeld dat modeluitvoer geen persoonsgegevens (PII) bevat. Meerdere afzonderlijk geconfigureerde modellen handmatig controleren zou ontwikkelaars veel tijd kosten. Bovendien hebben de meeste organisaties moeite met ongeoorloofd en risicovol AI-gebruik, zoals werknemers die gevoelige gegevens in AI-hulpmiddelen voor consumenten plakken, of SaaS-aanbieders die stilzwijgend nieuwe AI-functies inschakelen. Toch ligt de aansprakelijkheid volledig bij het bedrijf.

In zulke uitdagende situaties zijn de vereisten terug te brengen tot één eenvoudige taak: aantonen dat u de invoer en uitvoer van modellen voortdurend kunt begrenzen en die activiteit kunt registreren ter verificatie. Wanneer applicaties modellen aanroepen, agents hulpmiddelen inschakelen en modellen acties uitvoeren of workflows starten, moet de actie worden beheerst: de aanroep van een hulpmiddel, het API-verzoek of de start van een workflow.

Verplaats beveiliging naar het inferentiepad

Die actie is het handhavingspunt dat experts op het gebied van applicatiebeveiliging al 20 jaar voor applicatieverkeer ontwikkelen. Vooral wanneer inferentie via gedeelde infrastructuur wordt geleid, vormt dat inferentiepad het ideale controlepunt voor verschillende modellen en zelfs voor ongeoorloofd AI-gebruik. AI-inferentieverkeer moet worden afgeleverd, geïnspecteerd, geauthenticeerd en beheerd zoals elke andere belangrijke interactie met een applicatie, op basis van de herkomst van het verkeer en wat het probeert te doen. In tegenstelling tot handmatige controles is het beheer van inferentieverkeer schaalbaar.

Zo gaat u van start

Gezien de richting waarin de regelgeving zich ontwikkelt, moeten organisaties nu met drie dingen beginnen:

1. Breng uw blootstelling aan aansprakelijkheid in kaart, van SaaS-API’s en gehoste eindpunten tot schaduw-AI.
2. Maak het beveiligingsbeleid en de handhaving ervan onafhankelijk van de modellen en plaats ze in het inferentiepad.
3. Zorg ervoor dat audittrails worden gegenereerd buiten de invloedssfeer van modellen en agents, waarvan is aangetoond dat ze proberen registraties van hun eigen acties te wijzigen.

Wat als toereikende monitoring en handhaving geldt, wordt nog bepaald. Uw operationele en beveiligingsteams weten echter wat daadwerkelijk kan worden afgedwongen, welke gevolgen beheersmaatregelen hebben voor de latentie en complexiteit, en waar een goedbedoelde regel onbedoeld het verkeerde resultaat kan opleveren. Betrek hen er nu bij. De beveiligingsrisico’s en -verplichtingen die met AI-gebruik gepaard gaan, zijn reëel, en uw klanten en leidinggevenden maken zich ongetwijfeld meer zorgen over de risico’s waarmee ze vandaag te maken hebben dan over de dreigingen van de frontier-modellen van morgen.