AI-fout in productie of output: wat u vastlegt nu aanbieders aansprakelijk worden en verzekeraars uitsluiten

U moet per workflow vastleggen welk AI-model een uitkomst bepaalde, welke invoergegevens het gebruikte, welke menselijke controle plaatsvond, en hoe u die stappen kunt reconstrueren. Dit is nu geen optie meer, maar een vereiste voor aansprakelijkheid en verzekeringsdekking.

An analysis of 7 September 2026 of how courts now hold AI providers liable for model outputs while insurers exclude generative AI damage from standard policies argues that organisations using AI in sensitive workflows must document their processes per task to establish liability and maintain insurance cover. The Munich Regional Court ruled in GEMA v. Suno that an AI music service bears primary liability for copyright infringement through training, memorisation, distribution and output generation. In our assessment, this shift means you cannot treat AI as a neutral tool operated by someone else: your organisation now carries the burden of proof that you controlled the model, the data it touched, and the human review that preceded any decision or output.

Welke aansprakelijkheidsrisico's ontstaan door deze rechtspraak?

De Landgericht München I kwalificeerde meerdere stappen in de AI-keten als inbreuk: het trainen op beschermde werken, het opslaan van die werken in het model zelf (memorisatie), het beschikbaar stellen van het getrainde model, en het genereren van outputs die inbreuken bevatten. De rechtbank plaatste de AI-aanbieder als primaire inbreukmaker, niet de gebruiker die een prompt intikt. Dit patroon strekt zich uit over de hele keten: zowel de training in het buitenland als het gebruik en de output in uw jurisdictie vallen onder dezelfde aansprakelijkheid.

De rechtspraak betekent dat u niet kunt volstaan met contractuele vrijstellingen van de leverancier. U moet aantonen dat u wist welk model u gebruikte, welke gegevens het bevatte, en welke menselijke controle u toepaste. Zonder die documentatie kunt u niet bewijzen dat u redelijke zorg hebt betracht.

Welke risicofalen moet u per workflow identificeren?

• Onbekende trainingsgegevens — u weet niet op welke werken of gegevens het model is getraind en kunt dus niet beoordelen welke inbreuken mogelijk zijn.
• Memorisatie in het model — het model herhaalt of reconstrueert beschermde werken uit zijn trainingsgegevens in plaats van nieuwe outputs te genereren.
• Ongecontroleerde output — gegenereerde tekst, afbeeldingen of code verlaten uw organisatie zonder menselijke review op juistheid, legaliteit of naleving.
• Onvolledig auditspoor — u kunt niet reconstrueren welk model, welke invoer en welke menselijke stappen een specifieke output bepaalden.
• Gebroken ketens in de toeleveringsketen — u kunt niet aantonen dat de leverancier zelf controle uitoefende op trainingsgegevens of output.
• Geen vastlegging van bron en context — u hebt niet gedocumenteerd waarom u dit model voor deze taak koos en welke alternatieven u overwoog.

Welke concrete controles moet u per workflow kunnen aantonen?

1. Documenteer het model en zijn doel — leg vast welk model, welke versie en welke leverancier u per workflow gebruikt, en wat de wettelijke grondslag is voor de gegevens die het model aanraakt.
2. Leg de invoergegevens vast — registreer welke gegevens u aan het model voerde, waar die gegevens vandaan kwamen, en of u toestemming had om ze te gebruiken.
3. Registreer de menselijke review — documenteer wie de output controleerde, wat zij controleerden, welke fouten zij vonden, en welke correcties zij aanbrachten voordat de output werd gebruikt.
4. Bewaar het auditspoor — zorg dat u maanden later kunt reconstrueren welk model, welke invoer, welke review en welke output samen een specifieke beslissing of publicatie bepaalden.
5. Leg contractuele rechten vast — zorg dat uw contract met de leverancier u het recht geeft om audits uit te voeren en bewijsstukken op te vragen als er een claim ontstaat.
6. Definieer escalatiepunten — bepaal vooraf wanneer menselijke review verplicht is, wanneer u het model niet mag gebruiken, en wie die beslissing neemt.

Hoe verandert verzekeringsdekking door de ISO-exclusies?

Verzekeraars voeren vanaf januari 2026 endorsements in die generatieve-AI-schade uit standaard aansprakelijkheidspolissen halen. Dit betekent dat schade door een AI-fout — hallucinaties, inbreuken, discriminatie, gegevenslekken — niet meer onder uw bestaande polis valt, tenzij u aparte AI-dekking hebt gesloten.

Gespecialiseerde AI-dekking wordt gekoppeld aan aantoonbaar risicobeheer. Verzekeraars zullen vragen: kunt u aantonen dat u wist welk model u gebruikte? Kunt u het auditspoor tonen? Kunt u bewijzen dat menselijke review plaatsvond? Zonder die documentatie weigert de verzekeraar de claim.

Dit betekent dat de bewijslast nu bij u ligt. U bent niet langer afhankelijk van wat de leverancier zegt; u moet zelf kunnen aantonen wat er gebeurde.

Wat kunnen verificatietools doen en wat niet?

Een verificatielaag kan een taak door onafhankelijke AI-modellen routeren en de stappen, correcties, meningsverschillen en bronnen zichtbaar maken voor inspectie. Dit ondersteunt controle en maakt het reconstrueerbaar maken van bewijsstukken per AI-taak mogelijk. Het garandeert echter geen juistheid en elimineert geen hallucinaties.

Wat een verificatieconsole toevoegt, is een zichtlaag over de keten: u kunt high-trust workflows herleiden en incidenten reconstrueren in lijn met de nieuwe rechts- en verzekeringspraktijk. Het professionele eindoordeel — en de eindverantwoordelijkheid — blijft bij u. De rechtsontwikkeling komt van de rechtbank, de verzekeringswijziging van ISO en de verzekeraars. Uw taak is om die eisen in uw processen in te bouwen en die processen te kunnen bewijzen.