Harvard: AI-governance verschuift van principes naar concrete controleplichten

U moet kunnen aantonen wie eigenaar is van elk AI-systeem in uw organisatie, welk bedrijfsdoel het dient, welke gegevens het verwerkt, en wie goedkeuring geeft voordat het een risicovolle beslissing neemt. Dit is niet langer een technische vraag — het is een bestuurlijke plicht.

Een analyse van 4 september 2026 van eigenaarschap, logging, privacy en menselijke goedkeuring in AI-governance stelt dat organisaties AI niet langer als generiek hulpmiddel mogen behandelen, maar governance moeten inrichten met duidelijk eigenaarschap, adoptie vanuit een concreet bedrijfsdoel, gegevensbescherming, leveranciersonderzoek, klantbescherming, continue monitoring, menselijke goedkeuring voor risicovolle acties en incidentrespons. De analyse gebruikt AI-toepassing in bedrijfsprocessen als uitgangspunt en beschrijft hoe verantwoording in het ontwerp, de documentatie en het toezicht van een systeem moet zitten, niet achteraf toegevoegd. In onze inschatting markeert dit een verschuiving van 'mogen we AI gebruiken' naar 'kunnen we aantonen hoe het gebruikt is en wie verantwoordelijk was' — een vraag die gereguleerde professionals en bestuurders niet meer kunnen ontwijken.

Wat verandert in uw governance-structuur?

De plicht naar eigenaarschap betekent dat u niet langer kunt werken met AI als anoniem gereedschap. Iemand in uw organisatie moet aanwijsbaar verantwoordelijk zijn voor elk systeem: voor de keuze ervan, de gegevens die het krijgt, en de beslissingen die het ondersteunt. Die verantwoordelijkheid begint niet wanneer het systeem live gaat, maar in het ontwerp. U moet kunnen zeggen welk bedrijfsdoel het systeem dient en waarom dat doel rechtvaardigt dat u bepaalde gegevens verwerkt. Dit sluit aan bij het idee dat menselijke controle een ontwerpeis wordt en geen handtekening achteraf.

Die eigenaar moet ook zichtbaarheid hebben in wat het systeem doet. Continue monitoring is niet optioneel — u moet kunnen rapporteren hoe het systeem zich gedraagt, welke invoer het krijgt, en welke output het produceert. Voor autonome systemen verschuift dit naar een reconstructieplicht: u moet een verifieerbare tijdlijn kunnen tonen van wat het systeem heeft gedaan en waarom.

Welke risico's moet u expliciet adresseren?

• Ongecontroleerde gegevensverwerking — persoonlijke of bedrijfsgevoelige gegevens die het systeem verwerkt zonder dat u weet wie daar toegang tot heeft.
• Leveranciersafhankelijkheid zonder onderzoek — u bent afhankelijk van een externe AI-leverancier zonder dat u hun veiligheid, privacy of stabiliteit hebt gecontroleerd.
• Risicovolle beslissingen zonder goedkeuring — het systeem neemt of ondersteunt besluiten die klanten, werknemers of compliance raken, zonder dat een mens dit eerst heeft gezien.
• Geen incidentrespons — wanneer iets misgaat, weet u niet wat er gebeurd is, wie het kan herstellen, of hoe u klanten moet informeren.
• Onvolledig toezicht — u kunt niet reconstrueren welke versie van het systeem wanneer actief was, wie het heeft gewijzigd, of wat de gevolgen waren.

Welke controles moet u kunnen demonstreren?

1. Benaam de eigenaar en het doel — documenteer wie verantwoordelijk is voor elk AI-systeem, welk bedrijfsdoel het dient, en welke gegevens het mag verwerken.
2. Onderzoek leveranciers en modellen — controleer de veiligheid, privacy-praktijken en stabiliteit van elke externe AI-leverancier of model voordat u het inzet.
3. Zet goedkeuringsstappen in voor risicovolle acties — zorg dat een mens risicovolle output van het systeem ziet en goedkeurt voordat het effect heeft.
4. Log of reconstructie alle activiteit — houd vast welke versie van het systeem wanneer actief was, wie het heeft gewijzigd, welke invoer het kreeg, en welke output het gaf.
5. Definieer incidentrespons — beschrijf wie wat doet wanneer het systeem faalt, wie klanten informeert, en hoe u het probleem herstelt.

Hoe vertaalt u deze plichten naar werkende processen?

De Harvard-bronnen benoemen de plichten, maar niet hoe u ze technisch invult. Vanuit de logica van die plichten zijn een paar ontwerpkeuzes bruikbaar. U kunt bijvoorbeeld een verificatielaag inbouwen die gevoelige taken door meerdere onafhankelijke AI-modellen routeert en verschillen, correcties en bronnen zichtbaar maakt voor menselijke review. Dit garandeert geen juistheid en elimineert geen hallucinaties, maar het maakt review beter mogelijk. U kunt ook gevoelige gegevens vóór AI-verwerking vervangen door synthetische equivalenten die alleen voor die sessie geldig zijn; mislukt de privacycontrole, dan wordt het gegeven niet doorgestuurd. Het professionele eindoordeel blijft bij u.

Wat kan tooling doen en wat niet?

Tooling kan u helpen goedkeuring in te bouwen, logging te automatiseren en verificatie zichtbaar te maken. Wat tooling niet kan doen: bepalen welke risico's voor uw organisatie acceptabel zijn, wie eigenaar moet zijn, of welke bedrijfsdoelen rechtvaardigen welke gegevensverwerking. Die keuzes zijn uw professionele verantwoordelijkheid en blijven dat, ongeacht welke systemen u inzet. Tooling ondersteunt toezicht; het vervangt het niet.