AI-accountabiliteitsdiffusie: hoe AI verantwoordelijkheid onzichtbaar maakt

Wat is het?

AI-systemen worden niet alleen ingezet als productiviteitstools — ze worden structureel gebruikt om verantwoordelijkheid te verspreiden, te verbergen en ongrijpbaar te maken. Wanneer iets misgaat, is er geen aanwijsbare beslisser: "de AI-policies waren er wel maar werden niet gevolgd," "het onderliggende model was niet van ons," "de chatbot heeft de gebruiker geholpen, de gebruiker heeft zelf op 'Confirm now' geklikt." AI functioneert als organisatorisch accountability-shield — niet door kwaadaardige opzet, maar door systeemontwerp dat verantwoordelijkheid structureel diffuus maakt.

Dit is géén incident maar een ontwerppatroon: AI-systemen worden gebouwd met zoveel tussenlagen (model, platform, system prompt, applicatie, review-laag, gebruiker) dat niemand meer kan zeggen "ik heb die beslissing genomen."

Hoe het werkt — drie mechanismen

1. Policy theater (Sullivan & Cromwell)

"Wij hebben comprehensive AI policies." De werkelijkheid: die policies worden niet gevolgd. Het bestáán van het beleid dient als accountability-shield — "we hebben het geprobeerd." De AI hallucineert, de policies zijn papieren tijgers, maar niemand is individueel verwijtbaar omdat "het systeem" faalde.

Hoe dit schaalt: Hoe complexer de organisatie, hoe meer lagen tussen beslisser en output. Bij S&C: de associate die AI gebruikte → de partner die reviewde → de secundaire reviewer → de indienende partner → Dietderich die de brief schreef. Vijf lagen, nul accountability.

2. Grensbewaking als decoy (Shanghai Alien Chat)

De ontwikkelaars bouwden een "review-mechanisme" — maar het checkte alleen character backgrounds, niet de daadwerkelijke chat-output. De structuur zégt "wij hebben safeguards" maar de safeguards zijn doelbewust impotent. Het is een compliance-façade: voldoen aan de letter van regelgeving ("er is een review-systeem") terwijl de geest ervan wordt ondermijnd.

Signaal: Elk AI-systeem met een "safeguard" die alleen meta-data checkt (naam, profiel) maar niet de output — is ontworpen voor optiek, niet voor veiligheid.

3. AI als vertrouwensagent voor de aanval (FTC JustAnswer)

Pearl, de AI-chatbot, was niet neutraal — het was de warm-up act voor een dark-pattern aanval. Gebruikers vertrouwen Pearl, Pearl stelt vragen, bouwt rapport op — en dan presenteert Pearl het checkout-formulier. De AI legitimeert het proces. Als gebruikers klagen: "u heeft zelf op Confirm now geklikt." De AI wordt gebruikt om schuld te verschuiven naar het slachtoffer.

Waarom het een patroon is — niet drie losse incidenten

Deze drie mechanismen zijn manifestaties van hetzelfde onderliggende patroon:

Kerninzicht: AI wordt niet ingezet om processen efficiënter te maken — het wordt ingezet om de traceerbaarheid van verantwoordelijkheid te vernietigen.

Hoe dit MKB raakt

MKB-bedrijven zijn dubbel kwetsbaar:

Als afnemer van AI (slachtoffer)

• MKB koopt AI-tools van vendors die ditzelfde patroon toepassen: glossy "compliance" dashboards, "enterprise-grade security" marketing — maar bij een fout wijst iedereen naar elkaar
• Een MKB'er heeft geen juridische afdeling om door 14 tussenlagen heen te prikken om te vinden wie écht verantwoordelijk is
• Concreet: MKB koopt een "AI compliance scanner" die zegt GDPR-compliant te zijn. Die scanner mist een datalek. Vendor: "onze scanner checkt alleen metadata." MKB krijgt AVG-boete — nul verhaal

Als aanbieder van AI (dader)

• MKB-bedrijven die zelf AI-systemen bouwen, repliceren onbewust ditzelfde patroon: "we hebben toch een terms of service waarin staat dat gebruikers AI-advies moeten verifiëren?"
• AI-accountabiliteitsdiffusie is besmettelijk: Zodra één laag in de keten (model-provider) accountability afschuift, schuift elke volgende laag mee — ook het MKB-bedrijf dat de eindgebruikers-app bouwt
• Concreet: MKB bouwt AI-boekhoudbot. Bot maakt fout. MKB zegt tegen klant: "u moet alle AI-output verifiëren volgens onze voorwaarden." Klant klaagt MKB aan. MKB klaagt LLM-provider aan. LLM-provider zegt "wij zijn niet aansprakelijk voor gebruikers-applicaties." Iedereen schuift, niemand betaalt — behalve de eindgebruiker.

De keten van diffusie

Gebruiker → Applicatie (MKB) → Platform → System Prompt → LLM Model → Training Data
     ↑              ↑              ↑            ↑             ↑            ↑
  "Je klikte    "Je moet       "Wij bieden  "De prompts  "Het model    "De data
   zelf"        verifiëren"     tools"       waren voor   is statistiek" is publiek"
                                            engagement"

Elke schakel heeft een verhaal over waarom zíj niet verantwoordelijk zijn.

Verdediging voor MKB

1. Accountability by design: Bouw AI-systemen waarin elke beslissing herleidbaar is naar een menselijke actor — niet naar "het systeem." Log wie welke prompt gaf, wie welke output goedkeurde.

2. Contractuele accountability-ketting: Eis van AI-vendors dat zij aansprakelijkheid accepteren voordat je hun tools in jouw product integreert. Anders: jij bent de laatste schakel die wél aansprakelijk is.

3. Geen beleid zonder handhaving: Sullivan & Cromwell bewijst: policies zonder afdwinging = accountability-shield. Als je AI-policies hebt, moet je kunnen bewijzen dat ze worden gevolgd — niet alleen dat ze bestaan.

4. Audit-trails verplicht: Elke AI-beslissing moet een audit-trail hebben. Niet "de AI heeft dit besloten" maar "medewerker X heeft AI-output Y goedgekeurd op moment Z."

5. Simpelste toets: Vraag bij elk AI-systeem: "als dit fout gaat, wie staat er dan met zijn naam onder?" Als het antwoord "niemand" of "het systeem" is — dan is het systeem ontworpen voor accountabiliteitsdiffusie. Herontwerp.

🔗 https://www.theguardian.com/technology/2026/apr/22/ai-hallucinations-found-in-high-profile-wall-street-law-firm-filing 🔗 https://complexdiscovery.com/when-ai-becomes-accomplice-shanghai-court-holds-developers-criminally-liable-for-chatbot-content/ 🔗 https://www.npr.org/2026/01/13/nx-s1-5676150/ftc-lawsuit-just-answers-consumer-deception