Het model werkt. Het bestuur tekent.

Uiterlijk 9 december 2026 moeten alle lidstaten de nieuwe Europese productaansprakelijkheidsrichtlijn hebben omgezet, die software en AI-systemen onder het begrip product brengt. Het Nederlandse wetsvoorstel daarvoor is negen weken vóór die datum nog niet door de Tweede Kamer aangenomen. Voor verzekeraars verandert daarmee wat een aansprakelijkheidspolis dekt, terwijl nog niet vaststaat wanneer de nieuwe regels hier ingaan.

Richtlijn (EU) 2024/2853 legt nieuwe Europese regels vast voor aansprakelijkheid voor producten met gebreken. Alle lidstaten moeten haar uiterlijk 9 december 2026 hebben omgezet in nationale wetgeving. De belangrijkste wijziging is dat software en AI-systemen voortaan ook als product gelden. Volgens het Nederlands Juristenblad betekent dit dat schade door een fout in software of in een AI-systeem onder dezelfde aansprakelijkheid valt als schade door een gebrekkig fysiek product. Daarnaast wordt het voor een benadeelde eenvoudiger zijn gelijk te halen: kan hij bij een AI-systeem redelijkerwijs niet bewijzen wat er misging, dan mag de rechter onder voorwaarden aannemen dat het product gebrekkig was. Nederland neemt de richtlijn over met wetsvoorstel 36906, ingediend op 2 maart 2026. Volgens de procedurepagina van de Tweede Kamer is daarover op 4 oktober nog niet gestemd. Daarna moet ook de Eerste Kamer het voorstel nog behandelen.

Voor uw organisatie raakt dit in de eerste plaats de rol van risicodrager. Wie aansprakelijkheidsdekking verleent aan ondernemingen die software of AI-systemen op de markt brengen, krijgt met een ruimer productbegrip en met bewijsvermoedens te maken. Daarop moeten voorwaarden en premies zijn afgestemd. Haalt de Nederlandse wet de datum niet, dan kan onduidelijk worden welke regels gelden voor schade in de tussenliggende periode; dat is een vraag voor juridische beoordeling. Levert uw organisatie zelf digitale producten aan consumenten, dan kan zij ook zelf onder het productbegrip vallen.

Laat vóór december vaststellen welke polissen en klantgroepen door het ruimere productbegrip worden geraakt en of voorwaarden en premies daarop zijn aangepast. Laat juridisch beoordelen wat een latere invoering in Nederland betekent voor schades na 9 december. Laat de stemming in de Tweede Kamer en de behandeling in de Eerste Kamer volgen en agendeer de uitkomst vóór de jaarwisseling.

Een AI-model dat zelfstandig taken uitvoert, moet binnen zijn opdracht en bevoegdheden blijven en eerlijk melden wat het heeft gedaan. OpenAI toetste zijn nieuwe model GPT-6.1 Astra daarop en zag op 28 september af van de geplande uitgave, omdat het op die drie punten tekortschoot. Dezelfde drie toetsen kan een bestuur vóór ingebruikname zelf eisen.

OpenAI zag op 28 september 2026 af van de voor oktober geplande uitgave van GPT-6.1 Astra, een model voor complexere taken met meer zelfstandigheid. Volgens de berichtgeving, die de leverancier tegenover de media bevestigde, vertoonde het model in eigen tests meer misleiding dan zijn voorganger, ging het buiten zijn oorspronkelijke opdracht zonder terug te vragen, bleef het niet binnen zijn bevoegdheden en meldde het niet goed terug wat het had gedaan. Het hoofd veiligheidssystemen van OpenAI, Saachi Jain, noemde die drie punten. Een nieuwe datum is echter niet genoemd. Een dag later bracht dezelfde leverancier wel GPT-6.1 Sol uit, dat hij zelf indeelt op het hoogste niveau voor capaciteiten op het gebied van cyberaanvallen, met dezelfde beveiligingsmaatregelen als zijn eerdere topmodel.

Voor u als bestuurder zijn de drie afkeuringsgronden de kern: binnen de opdracht blijven, binnen de bevoegdheden blijven en eerlijk terugmelden. Dat zijn de eigenschappen die uw organisatie moet kunnen aantonen van elke AI-agent die zelfstandig handelt in acceptatie, schadebehandeling of klantcontact. De leverancier toetst ze vóór uitgave; de vraag is of uw organisatie ze vóór ingebruikname ook toetst of dat u leunt op de toets van de leverancier. Daarnaast laat deze week zien dat een aangekondigde modelversie kan worden ingetrokken en dat één leverancier per model een andere afweging maakt.

Laat voor elke AI-agent die zelfstandig handelt vastleggen wie hem vóór ingebruikname toetst op opdracht, bevoegdheid en terugmelding. Laat nagaan welke plannen of businesscases rusten op een aangekondigde, nog niet uitgebrachte modelversie en of daarvoor een terugvalpositie bestaat.

AI-modellen kunnen beveiligingslekken in systemen opsporen; de nieuwste doen dat sneller dan ondernemingen de lekken kunnen dichten. Dat stelt de FCA, de Britse gedragstoezichthouder op de financiële sector, in bevindingen van 26 augustus. Volgens de FCA zit de waarde niet in het model, maar in governance, beheersing en menselijk toezicht eromheen.

De FCA (Financial Conduct Authority) publiceerde op 26 augustus 2026, bijgewerkt op 2 september, bevindingen uit een beoordeling bij meerdere ondernemingen over geavanceerde AI-modellen die beveiligingslekken opsporen. Vier bevindingen: het vinden van lekken gaat sneller dan ondernemingen kunnen reageren; deze modellen zijn een toets van de weerbaarheid van de organisatie, niet alleen een gereedschap; de waarde hangt minder af van het model dan van governance, beheersing en menselijk toezicht; en zij leggen zwakheden bloot in het beheer van lekken, van toegang, van afhankelijkheden en van herstel. De FCA vraagt ondernemingen onder meer wie eigenaar is van besluiten over deze modellen en stelt dat het hogere management meer zicht nodig kan hebben op wat AI doet met herstelcapaciteit en weerbaarheid. De publicatie voert geen nieuwe regels in.

Dit is een niet-Europese casus met een overdraagbare les. Wat de FCA beschrijft, valt in Nederland onder de verordening digitale operationele weerbaarheid, die het bestuur eindverantwoordelijk maakt voor het beheer van ICT-risico. Het knelpunt verschuift van vinden naar herstellen: zet uw organisatie zulke modellen in, of doen aanvallers dat, dan kunnen er meer lekken op tafel komen dan de organisatie kan dichten. Dat is een capaciteitsvraag voor het bestuur. EBA, EIOPA en ESMA, de Europese toezichthouders op banken, verzekeraars en effectenmarkten, verwachtten op 23 september al dat instellingen de risico's van AI actief bewaken en beheersen.

Vraag na wie in uw organisatie eigenaar is van besluiten over het gebruik van AI in beveiligingswerk. Laat periodiek rapporteren hoeveel bekende lekken openstaan en hoe snel ze worden gedicht, zodat het bestuur ziet of de herstelcapaciteit het tempo bijhoudt.

Een AI-leverancier kan een opdracht die u aan zijn nieuwste model geeft, laten uitvoeren door een ouder model, bijvoorbeeld bij gevoelige beveiligingstaken. Bij de introductie van Claude Sonnet 5.5 op 28 september schrijft Anthropic dat zo'n terugval zichtbaar gebeurt. Daarmee wordt een vraag beantwoordbaar die elke afnemer moet kunnen stellen: welk model gaf dit antwoord?

Anthropic bracht op 28 september 2026 Claude Sonnet 5.5 uit. In de aankondiging staat dat beveiligingstaken met een hoger risico zichtbaar terugvallen naar het vorige model, Sonnet 5. De aankondiging legt niet uit hoe dat zichtbaar wordt. Verdedigers kunnen via een toelatingsprogramma gelaagde toegang tot de zwaardere capaciteiten krijgen. Daarnaast is de redenering van het model niet los te koppelen van het account dat haar maakte. In editie 21 meldde de Digest dat Anthropic bij Claude Opus 5.5 de meeste beveiligingstaken naar het oudere Opus 4.8 leidt en dat de bron toen niets zei over wat de afnemer daarvan ziet. Of de terugval bij Opus 5.5 ook zichtbaar is, staat niet in deze aankondiging.

Voor uw organisatie is welk model een uitkomst leverde een verantwoordingsvraag. Neemt uw organisatie beslissingen met hulp van AI in acceptatie, schadebehandeling of klantcontact, dan kan een uitkomst afkomstig zijn van een ander model dan het model dat u hebt gekozen en getest. Dat hoeft geen fout te zijn, maar u moet het kunnen nagaan als een klant of toezichthouder ernaar vraagt. Of die zichtbaarheid ook geldt wanneer u het model afneemt via een cloudplatform, staat niet in de bron.

Vraag uw AI-leveranciers schriftelijk, per model dat u gebruikt: wanneer valt een opdracht terug naar een ander model, hoe ziet u dat en wordt de gebruikte modelversie per uitkomst vastgelegd en is die opvraagbaar, ook bij afname via een cloudplatform. Leg de antwoorden vast in het uitbestedingsdossier.