AI-verantwoordingschecklist geïnspireerd door Timnit Gebru: documenteer data, beperkingen en mogelijke schade voor gebruikers zodat je kunt beslissen of een functie uitgebracht moet worden.
Het bouwen van een AI-functie was vroeger vooral een technische vraag: kunnen we het model aan de praat krijgen? Nu is de lastigere vraag of je het moet uitrollen, en welke grenzen je nodig hebt.
Zodra echte gebruikers op AI-output vertrouwen, worden kleine problemen echte kosten: foute beslissingen, verwarde klanten, privacylekken of oneerlijke behandeling.
AI-verantwoording is geen gevoel of belofte. Het is geschreven documentatie plus duidelijke beslissingen met een eigenaar. Als je niet kunt aanwijzen welke data je gebruikte, wat het systeem niet kan, en wat je doet als het faalt, heb je geen verantwoording. Je hebt hoop.
Dit is vooral belangrijk vlak voor de lancering, wanneer het verleidelijk is documentatie optioneel te noemen. Zonder documentatie ontstaan later dure verrassingen: supporttickets zonder antwoord, boze gebruikers, terugdraaien van features en intern wijzen van vingers.
Een eenvoudige checklist voor verantwoording dwingt concrete antwoorden af:
Het doel is niet theorie. Het is de basis (data, limieten, risico's) documenteren en daarna een beslissing nemen die je later kunt verdedigen, ook als je snel beweegt.
Timnit Gebru is een van de meest geciteerde stemmen in AI-verantwoording omdat ze een simpel idee naar voren bracht dat veel teams oversloegen: het is niet genoeg te vragen "kunnen we het bouwen?" Je moet ook vragen "moeten we het uitrollen, wie kan erdoor geschaad worden en hoe zouden we dat merken?"
Een groot deel van die verschuiving is AI-systemen begrijpelijk maken voor anderen. Niet alleen voor de engineers die het model trainden, maar voor reviewers, productmanagers, supportteams en gebruikers. Het doel is op te schrijven wat het systeem hoort te doen, welke data het heeft gevormd, waar het faalt en hoe de risico's er in het echte leven uitzien.
Twee praktische artefacten werden populair omdat ze die begrijpelijkheid concreet maken:
Voor productteams is dit geen papieren rompslomp. Documentatie is bewijs. Als iemand vraagt: "Waarom hebben we deze feature uitgebracht?" of "Waarom heb je deze faalmode niet opgemerkt?" moet je iets kunnen aanwijzen: wat je hebt gemeten, wat je bewust niet ondersteunde en welke beschermingen je hebt toegevoegd.
Een concreet voorbeeld: als je een AI-samenvattingsknop toevoegt in een supporttool, moeten de model-notities aangeven of het op gevoelige onderwerpen getest is, hoe het met onzekerheid omgaat en wat de menselijke reviewstap is. Dat verandert een vage zorg in een verdedigbare beslissing die je kunt verbeteren.
Een AI-functie is elk onderdeel van een product waarbij de output van een model kan veranderen wat mensen zien, wat ze kunnen doen of hoe ze behandeld worden. Als de output een besluit beïnvloedt, zelfs een klein besluit, behandel het als een echte feature met echte gevolgen.
Veelvoorkomende typen zijn samenvatting, ranking, aanbevelingen, moderatie en scoring (risico, fraude, kwaliteit, geschiktheid, prioriteit).
Wanneer dingen misgaan, reikt de impact vaak verder dan de persoon die op de knop klikt. Mensen die schade kunnen ondervinden zijn eindgebruikers, niet-gebruikers (personen die genoemd of geprofileerd worden), supportmedewerkers en moderators, aannemers en reviewers, en datapunten van betrokkenen die gebruikt zijn om de feature te trainen of evalueren.
Het helpt fouten te scheiden van schade. Een fout is dat het model het bij het verkeerde eind heeft: een slechte samenvatting, een vals alarm of een irrelevante aanbeveling. Schade is wat die fout in de echte wereld veroorzaakt: verloren geld, oneerlijke toegang, beschadigde reputatie of veiligheidsrisico's. Bijvoorbeeld: een supportassistent die een gefantaseerd restitutiebeleid noemt is een fout. De schade is dat een klant op basis daarvan een aankoop doet en later wordt afgewezen, of dat een supportagent boze tickets moet afhandelen.
Schade is vaak ongelijk verdeeld over groepen en contexten. Een moderatiemodel kan "voor de meeste gebruikers prima werken" maar herhaaldelijk straattaal of dialecten verkeerd lezen, wat leidt tot meer verwijderingen voor één community. Een rankingmodel kan kleine verkopers verbergen tenzij ze patronen volgen die bij grotere merken horen.
Als je AI-functies bouwt via een chat-gedreven builder zoals Koder.ai, is de snelheid echt, maar het accountability-werk blijft hetzelfde. Je moet nog steeds duidelijk zijn over waar het model kan falen en wie de prijs betaalt als dat gebeurt.
Voordat je een AI-functie uitbrengt, heb je een kleine set documenten nodig die één vraag beantwoorden: wat hebben we gebouwd, voor wie is het en wat kan er misgaan? Houd het kort, maar maak elke bewering toetsbaar.
Minimumset die op papier moet staan vóór release:
"Gedocumenteerd" is niet hetzelfde als "begrepen." Een doc die niemand leest is slechts een bestand. Laat één persoon buiten het bouwteam het lezen en in gewone taal akkoord geven: "Ik begrijp de limieten en de impact op gebruikers." Als diegene het niet kort kan samenvatten, ben je niet klaar.
Wijs één eigenaar aan om de docs actueel te houden (meestal de product owner van de feature, niet legal). Zet een cadans (bij elke release of maandelijks), plus een directe update na elk incident.
Houd de toon eerlijk en concreet. Vermijd beweringen als "hoge nauwkeurigheid" tenzij je de testset, metric en de faalcases die je niet hebt opgelost, noemt.
Goede data-notities doen twee dingen: ze helpen je fouten voorspellen voordat gebruikers ze vinden, en ze geven toekomstige collega’s een duidelijker reden om het systeem te vertrouwen (of niet).
Houd het detailniveau "genoeg om lastige vragen in 10 minuten te beantwoorden." Je schrijft geen proefschrift. Je noteert feiten die iemand nodig heeft tijdens een bugrapport, een privacyreview of een klantklacht.
Begin met een eenvoudige datainventaris. Voor elke dataset (inclusief logs, feedback en derde-partij bronnen) noteer de bron en wie het beheert, wanneer het verzameld is en hoe vaak het bijgewerkt wordt, welk productgedrag het ondersteunt, welke privacy- en toestemmingsgrenzen gelden, en hoe het gelabeld of opgeschoond is.
Representativiteit verdient een eigen regel. Noem wat ontbreekt: regio's, talen, apparaten, toegankelijkheidsbehoeften, gebruikerstypen of edge-cases. Schrijf het duidelijk op, zoals "voornamelijk US English mobile users" of "weinig voorbeelden van kleine bedrijven."
Als je menselijke labels gebruikt, documenteer de context van de labelaar (experts vs. crowd), de instructies die ze zagen en waar ze het oneens waren. Onenigheid is geen gebrek om te verbergen. Het is een waarschuwingssignaal om rond te ontwerpen.
Beperkingsdocumenten zijn waar je verschuift van "het werkte in de demo" naar "dit is wat deze feature veilig kan afhandelen." Als je alleen het happy path opschrijft, zullen gebruikers de randen voor je ontdekken.
Begin met het benoemen van de taak van het model in één zin en zeg daarna waarvoor het niet bedoeld is. "Kort antwoorden op veelgestelde vragen opstellen" is heel iets anders dan "beslissen over restituties" of "fraude detecteren." Die grens maakt latere beslissingen (UI-tekst, escalatieregels, supporttraining) veel eenvoudiger.
Leg bekende faalpatronen vast in gewone taal. Een goede sectie over limieten dekt meestal welke inputs het in de war brengen (ambigu verzoeken, ontbrekende context, gemengde talen), welke toon het fout leest (sarcasme, grappen, woede), wat het slecht doet in zeldzame gevallen (nichetermen, ongebruikelijke producten) en wat het opzettelijk kan breken (prompt injection, lokken om privédata te onthullen).
Neem operationele beperkingen op omdat die de gebruikerservaring en veiligheid veranderen. Schrijf latency-doelen, kostengebaren en wat er gebeurt als je die raakt (timeouts, kortere antwoorden, minder retries). Noem contextvenster-limieten (het kan eerdere berichten vergeten) en afhankelijkheidsveranderingen (overschakelen van LLM-provider of model-upgrade kan gedrag veranderen).
Maak daarna één waarschuwing die je in het product kunt hergebruiken:
"AI-generated responses may be incomplete or wrong. Do not use them for legal, medical, or financial decisions. If this concerns billing, refunds, or account access, contact support."
Werk deze notitie bij wanneer het model, prompts of beleid veranderen.
Een harm assessment is geen debat over abstracte ethiek. Het is een kort document dat zegt: als deze feature verkeerd is, wie kan er dan schade ondervinden, hoe en wat doen we voor en na lancering.
Begin met brede categorieën zodat je het voor de hand liggende niet mist: veiligheid, discriminatie, privacy, misleiding en betrouwbaarheid.
Zet vervolgens elke schade om in een echte situatie. Schrijf één of twee concrete verhaaltjes per categorie: wie is de gebruiker, wat vragen ze, wat zou het model kunnen outputten en wat zou de gebruiker daardoor doen. De sleutel is de actieketen. Een fout antwoord is vervelend. Een fout antwoord dat een medische beslissing, een geldtransactie of een beleidswijziging triggert is veel groter.
Om te prioriteren, gebruik simpele schalen. Geef per scenario ernst (laag, medium, hoog) en waarschijnlijkheid (laag, medium, hoog). Je hebt geen perfecte cijfers nodig. Je hebt een gedeelde kijk nodig op wat nu aandacht behoeft.
Wijs tenslotte eigenaren aan. Een mitigatie zonder naam is geen mitigatie. Voor elk scenario noteer je de mitigatie vóór lancering (guardrails, UX-waarschuwingen, geblokkeerde onderwerpen, logging), de mitigatie na lancering (support playbook, monitoring, rollback-trigger) en wie er verantwoordelijk is.
Gating is hoe je verschuift van "we kunnen het bouwen" naar "we moeten het uitbrengen." Behandel het als een set exits: je passeert de volgende exit niet voordat de basisstukken opgeschreven, beoordeeld en getest zijn.
Schrijf de intentie en de beslissing die het beïnvloedt. Wees specifiek over wie het gebruikt, welke beslissing ze nemen en wat er gebeurt als de output fout is.
Stel vroeg je data- en beperkingsnotities op. Doe dit voordat je de UI afmaakt, terwijl de feature nog makkelijk te vormen is.
Test op realistische, edge- en gevoelige cases. Gebruik rommelige tekst, straattaal, verschillende talen, lange threads en ambigu verzoeken. Voeg een paar high-stakes cases toe (betalingsgeschillen, accounttoegang, medische of juridische vragen) ook als de feature daar niet voor bedoeld is, omdat gebruikers het toch zullen proberen.
Voeg user messaging, fallbacks en escalatie toe. Bepaal wat de gebruiker ziet als het model weigert, onzeker is of slecht presteert. Voorzie een veilig fallback (zoals "vraag het een mens"), en maak het makkelijk een slecht antwoord te rapporteren.
Definieer monitoring, incidenten en rollback. Kies de signalen die je bekijkt (klachten, terugdraaiingspercentage, geflagde outputs), wie alerts krijgt en wat "stop de feature" precies betekent.
Als een stap moeilijk voelt, vertelt die wrijving meestal waar het risico zit.
De snelste manier om vertrouwen te ondermijnen is een goede score in het lab als bewijs van veiligheid te zien. Benchmarks helpen, maar ze laten niet zien hoe mensen een feature zullen duwen, verkeerd begrijpen of erop vertrouwen in dagelijks gebruik.
Een andere veelvoorkomende fout is onzekerheid verbergen. Als je systeem altijd met dezelfde zekerheid spreekt, zullen gebruikers aannemen dat het altijd klopt. Zelfs een eenvoudige "weet ik niet"-route of een kort verslag van waar het antwoord op gebaseerd is, kan voorkomen dat mensen een wankele output als feit nemen.
Teams testen ook vaak met hun eigen gewoonten. Interne prompts zijn netjes en voorspelbaar. Echte gebruikers zijn moe, gehaast en creatief. Ze plakken rommelige tekst, stellen opvolgvragen of proberen het model regels te laten breken.
Vijf herhaalde fouten:
Een praktische oplossing is accountability onderdeel van het bouwproces te maken. Houd de checklist in het spec en eis het voor release: welke data je gebruikte, waarop het faalt, wie schade kan ondervinden en wat je doet als het misgaat.
Een concreet voorbeeld: als je een AI-assistent binnen een app-builder inzet, test met vage verzoeken ("maak het zoals Airbnb"), tegenstrijdige eisen en gevoelige inhoud. Stel vervolgens een duidelijk rollback-plan op (snapshots, versioning, snelle uitschakelknop) zodat je snel kunt handelen als gebruikers schade melden.
Plak dit in je productspec en vul het in vóór je uitbrengt. Houd het kort, maar maak elk antwoord specifiek. Benoem een eigenaar voor elk risico.
### 1) Purpose and affected people
- Feature name:
- What decision or action does the AI support (one sentence):
- Who uses it:
- Who is affected even if they never use it (customers, employees, bystanders):
- What a “good” outcome looks like:
### 2) Data used (training, tuning, retrieval, logs)
- Data sources (where it came from and why it’s allowed):
- What you excluded (and why):
- Sensitive data involved (PII, health, finance, kids):
- Data retention period and deletion plan:
- Security and access controls:
### 3) Limits and “do not use” zones
- Known failure modes (give 3-5 concrete examples):
- Languages supported and not supported:
- Inputs it should refuse (or route to a human):
- Cases where it must not be used (legal, medical, hiring, etc.):
### 4) User harm assessment
- Top 5 harms (ranked):
- Mitigation for each harm:
- Who owns each mitigation (name + team):
- What you will tell users (warnings, confidence cues, citations):
### 5) Operations after launch
- Monitoring signals (quality, complaints, bias flags, cost spikes):
- Human review path (when and how escalation happens):
- Rollback trigger (exact threshold or condition):
- Snapshot/version you can revert to:
Voorbeeld: als de feature klantondersteuningsreacties opstelt, noem dan schades zoals "zelfverzekerd onjuist restitutiebeleid" en stel een regel dat drafts met lage zekerheid goedkeuring vereisen voordat ze worden verzonden.
Een supportteam voegt een AI-reply assistant toe in hun customer chattool. De assistent maakt conceptantwoorden, stelt vervolgstappen voor en haalt context uit het huidige ticket. Voor de lancering schrijven ze een korte doc die in de checklist past: wat het systeem ziet, wat het fout kan doen en wie er schade kan ondervinden.
Ze scheiden twee bronnen. Ten eerste trainings- of fine-tuningdata (oude supporttickets, interne helpdocs, productbeleid). Ten tweede live context (het klantbericht, abonnementsstatus, orderstatus en eventuele notities in de agentconsole).
Ze beschrijven privacyverwachtingen voor elke bron. Oude tickets kunnen adressen of betalingsproblemen bevatten, dus ze definiëren regels: gevoelige velden redigeren vóór training, volledige chats niet langer bewaren dan nodig en alleen loggen wat nodig is om fouten te debuggen.
Ze sommen zwakke plekken in gewone taal op: het model kan beleid verzinnen, de boze toon van een klant spiegelen, sarcasme missen of slecht presteren in minder gangbare talen. Ze beslissen ook hoe onzekerheid te tonen, zoals een "Draft reply, needs review"-label, zodat agenten het niet als feit beschouwen.
Ze voegen een regel toe: de assistent moet het interne document of beleidsfragment citeren dat het gebruikte, of moet zeggen "I could not find a source."
Ze brengen waarschijnlijke schade in kaart: klanten kunnen misleid worden door verzonnen restitutieregels, privégegevens kunnen in het antwoord lekken, of bevooroordeelde taal kan tot oneerlijke behandeling leiden.
Mitigaties komen als concrete poorten in het spec:
Dat verandert "zullen we het uitrollen?" in geschreven checks die het team kan testen voordat klanten de schade voelen.
Verantwoording werkt alleen als het verandert wat je op releasedag doet en wat je doet nadat er iets misgaat. Je notities moeten eindigen in een duidelijke beslissing, niet in een map vol goede bedoelingen.
Vertaal je documentatie naar één van drie uitkomsten:
Om dit herhaalbaar te maken, stel een lichte reviewritueel in: één product owner, één engineer en één persoon die voor gebruikers kan spreken (support, research of ops). Zij moeten op dezelfde paar punten tekenen: data-source notes, bekende limieten, waarschijnlijke schades en wat er gebeurt als het model het fout heeft.
Na lancering behandel je verantwoording als operatie. Kies één cadans (wekelijks of per release) en maak updates normaal.
Als je snel prototypeert, houd dezelfde discipline. Tools die snel bewegen kunnen nog steeds goede poorten ondersteunen. Bijvoorbeeld, als je bouwt in Koder.ai (koder.ai), gebruik planning mode om grenzen vroeg vast te leggen en behandel snapshots en rollback als onderdeel van je veiligheidsplan, niet alleen als gemak.
Begin precies voor je live gaat, wanneer echte gebruikers op de output gaan vertrouwen.
Als je wacht tot na de lancering, documenteer je incidenten in plaats van ze te voorkomen, en heb je minder tijd (en minder opties) om beschermingen toe te voegen of de scope te beperken.
Verantwoording betekent dat je naar geschreven beslissingen kunt verwijzen over:
Als je die beslissingen en een verantwoordelijke niet kunt laten zien, heb je geen verantwoording.
Elke functie waarbij de output van een model kan veranderen wat mensen zien, doen of hoe ze behandeld worden.
Dat omvat "kleine" functies zoals samenvattingen of voorgestelde antwoorden als iemand er acties op kan ondernemen (naar klanten sturen, een verzoek weigeren, prioriteit veranderen). Als het een beslissing beïnvloedt, behandel het als een echte productvlak met risico's.
Heb een klein “minimumset” op papier:
Leg genoeg vast zodat iemand lastige vragen snel kan beantwoorden:
Schrijf ontbrekende dekking duidelijk op (bijvoorbeeld: "voornamelijk US English; weinig voorbeelden van kleine verkopers").
Begin met één zin: wat het model doet. Voeg daarna ‘niet voor’ grenzen toe.
Neem een korte lijst op van:
Scheid fout van schade:
Schrijf daarna een paar korte scenario's: wie is de gebruiker, wat vragen ze, wat zou het model kunnen doen en welke actie volgt. Geef per scenario een beoordeling van en , en wijs een eigenaar toe voor elke mitigatie.
Gebruik een gated flow van prototype naar release:
Als een gate lastig voelt, is dat meestal precies waar het risico zit.
Veelvoorkomende fouten:
Een praktische oplossing: houd de checklist in het productspec en eis sign-off voor release.
Snelheid haalt de verantwoordelijkheid niet weg. Als je bouwt met een chat-gestuurde tool zoals Koder.ai, houd dan dezelfde discipline:
Snelle iteratie is prima zolang je kunt uitleggen wat je hebt uitgebracht en hoe je reageert als het breekt.
Houd het kort, maar maak elke bewering toetsbaar.
Voeg 3–5 concrete voorbeelden van slechte outputs toe zodat niet-engineers de randen begrijpen.