Compliance op control-niveau: de EU AI Act als geïnstrumenteerd systeem

Er zijn twee manieren om aan de EU AI Act te voldoen, en op papier zien ze er bijna identiek uit. De eerste is om voor elke verplichting een beleid te schrijven: een AI-governance-beleid, een menselijk-toezicht-protocol, een datagovernance-beleid, een incidentresponse-procedure. De ordner is dik, elk artikel heeft een bijbehorend document, en een organisatie kan ernaar wijzen en zeggen dat ze compliant is. De tweede is om de verplichtingen in het systeem zelf in te bouwen, als controls die automatisch werken, bewijs produceren, en op verzoek kunnen worden gedemonstreerd. De ordner is dunner, omdat de meeste compliance in het systeem leeft in plaats van op papier.

Het verschil tussen de twee komt niet naar voren in een inkoopreview. Het komt naar voren wanneer een toezichthouder niet vraagt "heb je hier beleid voor" maar "laat me zien dat het werkte". Een beleid beschrijft wat zou moeten gebeuren. Een control is wat gebeurt, en de log is het bewijs dat het gebeurde. De technische artikelen van de EU AI Act zijn, in toenemende mate, geschreven om door de tweede soort compliance te worden vervuld. Ze beschrijven controls, geen aspiraties, en ze op control-niveau lezen onthult hoe een geïnstrumenteerd compliance-systeem er uitziet.

Wat de artikelen vragen, gelezen als controls

De technische verplichtingen van de EU AI Act vertalen, vrijwel één-op-één, naar systeem-controls. Zo gelezen houdt de verordening op een lijst dingen te zijn om over te schrijven, en wordt ze een specificatie voor dingen om te bouwen.

Onveranderlijke auditlogs (Art. 12 en Art. 19). Het systeem moet automatisch logs genereren die fraudebestendig zijn, minimaal zes maanden bewaard, en gedetailleerd genoeg om de werking te reconstrueren. De control-niveau-lezing is precies: databaselogs die een beheerder kan bewerken kwalificeren niet, omdat een verslag dat kan worden gewijzigd geen bewijs is. De control is automatische generatie plus immutability plus bewaring, en het bewijs is de log zelf.

Menselijk toezicht met een noodstop (Art. 14(4)(e)). Het systeem moet een mens in staat stellen het in één handeling naar een veilige staat te brengen, en de handeling van het ingrijpen moet zelf worden gelogd. Dit is geen beleid dat stelt dat mensen de leiding hebben. Het is een mechanisme dat de control reëel maakt en een verslag dat bewijst dat het beschikbaar was en, indien gebruikt, gebruikt is.

Real-time gegevensbescherming (Art. 10). Gevoelige data wordt gemaskeerd of geredigeerd op inputniveau, vóór die het model bereikt. De control werkt bij de prompt, niet in een retrospectieve review, omdat het punt is de blootstelling te voorkomen in plaats van die achteraf te documenteren.

Configureerbaar blokkeerbeleid (Art. 26 en de verboden van Art. 5). Bepaalde gebruikscategorieën worden volledig geblokkeerd, afgedwongen door het systeem in plaats van ontmoedigd door een richtlijn. Dit is beleid als code, niet beleid als PDF: de regel wordt automatisch uitgevoerd, elke keer, in plaats van te vertrouwen op een persoon die het onthoudt en toepast.

Risicoscoring en incidentmelding (Art. 9 en Art. 73). Risico's worden doorlopend gescoord via het risicobeheerssysteem, en ernstige incidenten worden binnen de termijn aan de bevoegde toezichthouder gemeld. De control is de geïnstrumenteerde pijplijn die detecteert, scoort en escaleert, met de meldingstermijn ingebouwd in plaats van overgelaten aan iemand om te onthouden.

Workspace-isolatie en rolgebaseerde toegang (Art. 14 en Art. 26). Verschillende dataclassificaties vereisen verschillende oppervlakken, afgedwongen door isolatie en toegangscontrole. Een gebruiker ziet en kan handelen op alleen wat zijn rol toestaat, en de grens is structureel in plaats van procedureel.

Samen gelezen zijn dit geen zes beleidsstukken. Het zijn zes controls, elk ingebouwd in het systeem, elk bewijs producerend, elk demonstreerbaar. Dat is hoe compliance er op control-niveau uitziet: geen beleidsdocument, maar een geïnstrumenteerd systeem.

Waarom het control-niveau het niveau is dat ertoe doet

Het pleidooi voor compliance op control-niveau is niet esthetisch. Het rust op drie eigenschappen die compliance op beleidsniveau mist.

De eerste is bewijsbaarheid. Een beleid beweert dat iets zou moeten gebeuren; een control, met zijn log, bewijst dat het gebeurde. Wanneer een toezichthouder onderzoekt, is de vraag altijd bewijsmatig. Een organisatie die de onveranderlijke log kan overleggen, het verslag dat het stopmechanisme beschikbaar was, de tijdstempel van de incidentmelding, beantwoordt de vraag. Een organisatie die alleen het beleid kan overleggen dat deze dingen beschrijft, heeft haar voornemens beschreven, niet haar gedrag.

De tweede is betrouwbaarheid. Een beleid hangt af van mensen die het onthouden en toepassen, elke keer, onder druk. Een control wordt automatisch uitgevoerd, elke keer, ongeacht wie er dienst heeft of hoe druk het is. Het als code afgedwongen blokkeerbeleid blokkeert de verboden categorie op de slechtste dag even betrouwbaar als op de beste. Het beleid als PDF is slechts zo betrouwbaar als de minst zorgvuldige persoon die het had moeten volgen.

De derde is schaalbaarheid. Een groeiende organisatie kan niet elke AI-interactie met de hand controleren. Controls schalen omdat ze deel van het systeem zijn; beleid doet dat niet, omdat het afhangt van menselijke aandacht die niet vermenigvuldigt. De organisatie die haar compliance instrumenteert, kan haar AI-gebruik laten groeien zonder haar compliance-risico evenredig te laten groeien. De organisatie die op beleid vertrouwt, merkt dat elk nieuw systeem, elke nieuwe gebruiker, elk nieuw gebruiksgeval de kloof verbreedt tussen wat het beleid zegt en wat er gebeurt.

De relatie met de GovCompass-7

Compliance op control-niveau is de operationele uitdrukking van hetzelfde idee dat onder het GovCompass-7-kader ligt: verantwoorde AI is een control-probleem, geen verklaring van waarden. Waar de GovCompass-7 de controls ordent rond zeven elementen van verantwoorde AI, ordent de control-niveau-lezing van de EU AI Act ze rond de specifieke artikelen. Het zijn twee views op hetzelfde systeem. Een onveranderlijke auditlog dient het accountabilityaccountabilityThe principle that a named human or organization answers for an AI system's outcomes, through ownership, documentation, audit trails and redress — never the system itself.Open full entry →-element en voldoet aan Art. 12; een noodstop dient het menselijk-toezicht-element en voldoet aan Art. 14(4)(e); datamaskering dient het privacy-element en voldoet aan Art. 10. Het kader en de verordening convergeren op dezelfde controls, wat het sterkst mogelijke teken is dat die controls de juiste zijn.

Wat dit in de praktijk betekent

Voor een organisatie die beslist hoe ze de EU AI Act aanpakt, is de keuze tussen de twee soorten compliance eigenlijk een keuze over waar het werk leeft. Compliance op beleidsniveau zet het schrijven vooraan en het risico achteraan: de ordner wordt snel geproduceerd, en de kloof tussen de ordner en de werkelijkheid wordt later ontdekt, meestal door een incident of een audit. Compliance op control-niveau zet de engineering vooraan en het vertrouwen achteraan: de controls kosten meer tijd om te bouwen, maar eenmaal gebouwd werken ze, bewijzen ze zichzelf, en schalen ze.

Dit is geen betoog dat beleid waardeloos is. De EU AI Act vereist documentatie, en beleid heeft een rol in het bepalen van richting en het toewijzen van verantwoordelijkheid. Het betoog gaat over waar het zwaartepunt ligt. In een compliance-programma gebouwd op beleid zijn de documenten de compliance en is het systeem een bijzaak. In een programma gebouwd op controls is het systeem de compliance en beschrijven de documenten het. Het eerste oogt compleet en faalt stilletjes. Het tweede oogt bescheiden en houdt stand.

Dat is hoe compliance er op control-niveau uitziet. Geen beleidsdocument. Een geïnstrumenteerd systeem.