Aansprakelijkheid en verantwoordelijkheid
Als het misgaat in minuten: wie draagt de last?
Denk aan een time-sensitive strike in West-Iran: een AI-systeem fuseert radar, dronevideo en SIGINT en markeert een voertuigcluster als “mogelijk TEL”. De commandopost ziet een dashboard met een hoge confidence-score, een CDE-indicatie die “groen” lijkt, en een aftellende klok omdat het doel elk moment kan verdwijnen. Een operator klikt door, een jurist is net niet ingehaakt, en de commandant autoriseert onder tijdsdruk.
Stel dat achteraf blijkt dat het cluster geen lanceerinstallatie was maar een civiele logistieke ploeg met vergelijkbare silhouetten en warmtepatronen. Of dat de TEL er wél was, maar de blast-effecten door een modelfout te laag zijn ingeschat waardoor burgerslachtoffers vallen. Op dat moment verschuift de kernvraag van “was het model goed?” naar “wie is verantwoordelijk en wie is aansprakelijk—en op grond waarvan?”
Juist in de Israël/VS–Iran context is dit geen abstract debat. Beslissingen worden genomen in een omgeving van escalatierisico, informatie-oorlog en sterke politieke druk, terwijl AI steeds vaker upstream de kill chain beïnvloedt (target nomination, prioritering, CDE-ondersteuning). Deze les maakt helder hoe verantwoordelijkheid en aansprakelijkheid zich verhouden tot IHL/LOAC-eisen zoals onderscheid, evenredigheid en voorzorgsmaatregelen, en waarom “de mens klikte akkoord” juridisch en moreel zelden genoeg is.
Wat bedoelen we met verantwoordelijkheid, aansprakelijkheid en “control”?
Verantwoordelijkheid gaat over wie in een organisatie de plicht heeft om rechtmatig en zorgvuldig te handelen, besluiten te nemen en risico’s te beheersen. In de militaire praktijk ligt dit primair bij commandanten en besluitvormers in de targeting-keten, maar verantwoordelijkheid kan ook organisatorisch zijn: wie borgt training, procedures, validatie, en stopmomenten? Het raakt dus niet alleen “de schutter”, maar ook de manier waarop een systeem wordt ingebed.
Aansprakelijkheid gaat over wie juridisch kan worden aangesproken als normschendingen plaatsvinden—variërend van staatsaansprakelijkheid tot individuele (strafrechtelijke) aansprakelijkheid. In een conflictcontext lopen die sporen vaak parallel: een staat kan internationaalrechtelijk verantwoordelijk zijn voor onrechtmatige aanvallen, terwijl individuen (onder voorwaarden) strafrechtelijk aansprakelijk kunnen zijn wanneer er bijvoorbeeld roekeloos of opzettelijk in strijd met IHL is gehandeld. Welke route speelt, hangt af van feiten, bewijs, en de rol die iemand werkelijk had.
Een kernbegrip dat AI hier spannend maakt is (meaningful) control: niet als slogan, maar als praktische vraag. Had de beslisser voldoende begrip, overzicht over bronnen en onzekerheid, en mogelijkheid om in te grijpen om IHL-toetsing echt te doen? De vorige les liet zien dat AI-confidence geen juridische zekerheid is, dat proportionaliteit normatief blijft, en dat precautions procesontwerp zijn. Diezelfde punten bepalen nu hoe verantwoordelijkheid en aansprakelijkheid “landen”: hoe sterker AI je besluitvorming stuurt zonder dat je het kunt uitleggen, hoe groter het risico dat accountability vervaagt—maar het recht accepteert zelden “de machine” als eindantwoord.
Drie lagen van accountability in AI-ondersteunde oorlogsvoering
1) Command responsibility: leidinggeven aan een keten, niet aan een knop
In AI-ondersteunde targeting is de grootste valkuil dat verantwoordelijkheid versmalt tot het laatste moment: “wie drukte op fire?” IHL/LOAC kijkt juist naar de redelijkheid van besluitvorming in de omstandigheden: was er voldoende verificatie voor onderscheid, was proportionaliteit zorgvuldig gewogen, en zijn alle haalbare voorzorgsmaatregelen genomen? Dat zijn command decisions die vaak ruim vóór de trigger plaatsvinden, bijvoorbeeld in het accepteren van AI-output als “voldoende bewijs”, of in het overslaan van extra verificatie omdat het systeem “al groen” geeft.
Command responsibility (in brede zin) gaat ook over hoe je een organisatie inricht voor rechtmatige acties. Als een commandant weet (of behoort te weten) dat AI-systemen in een regio slecht gekalibreerd zijn—bijvoorbeeld door andere bouwstijlen, andere voertuigtypen, of adversarial camouflage—dan kan het nalaten van aanvullende checks een voorspelbare route naar fouten worden. De vorige les noemde multi-source corroboration, audit trails en stopmomenten; hier worden dat verantwoordelijkheidsmechanismen: je kunt pas sturen op rechtmatigheid als je proces je dwingt om onzekerheid te zien en te registreren.
Een typische misconceptie is: “Er zat een mens in de loop, dus verantwoordelijkheid ligt altijd bij die mens en is daarmee afgedekt.” Dat klopt niet automatisch. Als “human-in-the-loop” in de praktijk neerkomt op een snelle bevestigingsklik zonder inzicht in bronkwaliteit, failure modes en alternatieven, dan kan die menselijke rol juridisch en moreel te dun zijn. IHL vereist geen perfecte kennis, maar wel een redelijke, geïnformeerde beoordeling onder de omstandigheden—en dat zet druk op commandanten om systemen zo te ontwerpen dat die beoordeling werkelijk mogelijk is.
2) State responsibility en organisatorische plichten: het systeem als oorzaak
Naast individuele verantwoordelijkheid bestaat er staatsaansprakelijkheid voor internationaalrechtelijke schendingen door organen van de staat of door personen/eenheden onder staatsgezag. In AI-context betekent dit: als een aanval (of methode) in strijd met IHL is, ligt de verantwoordelijkheid niet “bij de softwareleverancier”, maar primair bij de staat die het geweld inzet. Dat is belangrijk, omdat het de prikkel creëert om AI niet als extern product te zien, maar als onderdeel van eigen militaire capaciteit die aan IHL moet voldoen.
Organisatorisch vertaalt dit zich naar plichten die vaak onderschat worden: testen in representatieve omgevingen, vastleggen van aannames, training tegen automation bias, en het inbouwen van escalatiepaden. De vorige les benadrukte dat precautions procesmatig zijn en dat AI twijfel zichtbaar moet maken; in accountability-termen betekent dit dat het ontbreken van die processen een voorzienbare risicofactor kan worden. Als je structureel vertrouwt op modellen die onzekerheid wegfilteren of alleen “positieve hits” tonen, maak je het waarschijnlijker dat onderscheid en proportionaliteit in de praktijk eroderen.
Een tweede misconceptie is: “Als we ons aan interne SOP’s houden, zijn we juridisch veilig.” Interne SOP’s kunnen helpen, maar zijn geen schild als ze IHL-eisen onvoldoende operationaliseren. Een SOP die stelt “bij confidence > X mag target nomination” is precies het soort verschuiving waar de vorige les voor waarschuwde: statistische confidence wordt dan behandeld als juridische zekerheid. Organisatorische verantwoordelijkheid betekent dat SOP’s expliciet moeten eisen: brondiversiteit, verificatie, onzekerheidsmarges, en documentatie van de normatieve proportionaliteitsafweging.
3) Professionele verantwoordelijkheid: juristen, analisten, engineers en operators
AI in de kill chain is niet alleen een commandant/trigger-probleem; het is een multi-disciplinair systeem. Analisten bepalen welke data als “grondwaarheid” gelden, engineers bepalen wat het model optimaliseert, operators bepalen hoe outputs worden geïnterpreteerd, en juristen helpen de LOAC-toets in werkbare criteria te vertalen. Verantwoordelijkheid is hier verdeeld, maar dat betekent niet dat ze verdampt: het betekent dat fouten vaak systeemfouten zijn—ontstaan uit kleine beslissingen in verschillende lagen.
Neem dataset bias en contextblindheid uit de vorige les. Als engineers weten dat training coverage laag is in een bepaald Iraans terrein of dat civiele trucks systematisch op militaire lijken, dan is het professioneel onverantwoord om dat niet zichtbaar te maken in de interface en de workflow. Evenzo, als analisten weten dat de vijand decoys gebruikt of civiele objecten mengt met militaire, dan moet dat als onzekerheid in de target package landen. En als operators structureel AI-adviezen overnemen bij tijdsdruk, dan is training tegen automation bias geen “nice to have” maar onderdeel van precautions.
Een veelvoorkomend misverstand is dat accountability pas begint “na het incident”. In werkelijkheid begint het vooraf: bij requirements (“wat moet het systeem kunnen en tonen?”), bij governance (“wie mag overrides doen?”), bij logging (“kunnen we achteraf aantonen welke bronnen en aannames speelden?”), en bij beslisarchitectuur (“waar zitten de stopmomenten?”). Zonder die elementen kun je achteraf nauwelijks reconstrueren of de LOAC-toets zorgvuldig is uitgevoerd—en dat maakt zowel juridische verdediging als interne verbetering zwakker.
Wie doet wat? Een eenvoudige accountability-map voor AI in de kill chain
| Dimensie | Commandant / targeting authority | Juridisch adviseur (LOAC) | ISR/Intel-analist | AI/Systems team |
|---|---|---|---|---|
| Primaire verantwoordelijkheid | Eindbeslissing: onderscheid, proportionaliteit, precautions onder operationele omstandigheden. | Vertaling van LOAC naar werkbare criteria; adviseren bij twijfel en documenteren van juridische weging. | Context en bronkritiek: wat betekent de AI-indicatie in dit theater, met deze tegenstander? | Modelbetrouwbaarheid, beperkingen, training coverage, interface die onzekerheid en failure modes toont. |
| Wat “goede controle” vereist | Begrijpt welke bronnen AI gebruikt, ziet onzekerheid, kan alternatieven afwegen en stopzetten. | Ziet voldoende feitenbasis om te adviseren; krijgt tijd/haakjes in het proces om echt mee te kijken. | Corroboration over meerdere bronnen; expliciete “plausible civilian explanations”. | Monitoring, audit trails, fail-safe gedrag, kalibratie, en waarschuwingen bij contextdrift/adversarial risico. |
| Typische valkuil | “Dashboard is groen, dus door.” Automation bias en tijdsdruk vervangen verificatie. | Wordt te laat betrokken of krijgt alleen de conclusie (“high confidence”), niet de onderbouwing. | Behandelt correlaties als bewijs; onderschat decoys en dual-use context. | Optimaliseert voor detectie of snelheid, maar niet voor uitlegbaarheid en LOAC-relevante onzekerheid. |
| Best practice | Verplichte stopmomenten + vastgelegde proportionaliteitsafweging met aannames en onzekerheidsbanden. | “Red flag” triggers: onvoldoende verificatie = escaleren of pauzeren; standaard LOAC-checklist gekoppeld aan data. | Multi-source checks; expliciet labelen van gaten in coverage; scenario-denken (“wat als dit civiel is?”). | “Human-readable” modelkaarten, logging van inputs/versies, en UI die twijfel even prominent toont als hits. |
Van regels naar ontwerp: best practices die aansprakelijkheid echt maken
Een nuttige manier om aansprakelijkheid te versterken is om AI niet alleen als technologie, maar als beslisarchitectuur te behandelen. De vorige les benadrukte “stops” in de kill chain; voor accountability betekent dit: je definieert expliciet waar een mens moet beoordelen, wat die persoon moet kunnen zien (bronnen, onzekerheid, alternatieven), en hoe dat wordt vastgelegd. Zonder vastlegging verandert “zorgvuldige afweging” in een onbewezen claim, wat zowel intern leren als externe verantwoording ondermijnt.
Een tweede best practice is het verschil serieus nemen tussen confidence en bewijswaarde. Confidence is een modelinterne statistiek; bewijswaarde hangt af van context, bronkwaliteit, vijandelijke misleiding en de kosten van fout-positieven. Daarom hoort een target package niet alleen de AI-score te bevatten, maar ook: training coverage in dit gebied, bekende failure modes (bijv. silhouetverwarring), en welke onafhankelijke bronnen wél/niet bevestigen. Dat operationaliseert de LOAC-eis van verificatie en maakt het achteraf toetsbaar of onderscheid redelijk was.
Ten derde: proportionaliteit vereist een normatieve notitie, niet alleen een CDE-getal. AI kan blast, radius en populatiepatronen schatten, maar “buitensporig” is een oordeel dat rekening houdt met onzekerheidsmarges en alternatieven. Een accountability-robuste workflow dwingt daarom tot het noteren van: verwacht militair voordeel (concreet en direct), belangrijkste onzekerheden, en welke minder schadelijke opties zijn bekeken (andere munities, timing, hoek, wachten op betere verificatie). Dat is niet bureaucratie; het is de kern van aantoonbare precautions.
[[flowchart-placeholder]]
Twee uitgewerkte voorbeelden uit de Israël/VS–Iran dynamiek
Voorbeeld 1: Mobiele lanceerinstallatie, AI-nominatie en de vraag “wie had moeten stoppen?”
Stel dat een AI-systeem een voertuigcluster in West-Iran markeert als “mogelijk TEL” en een routevoorspeller aangeeft dat het cluster binnen 6 minuten dekking bereikt. De commandant krijgt een target card met hoge confidence, maar de analist ziet dat de beelden uit een hoek komen waarin civiele wegwerkvoertuigen vaak op een TEL lijken. Een CDE-tool toont “laag risico” omdat het model uitgaat van open terrein, terwijl er in werkelijkheid een kleine nederzetting net buiten het kaartvenster ligt.
Stap voor stap in verantwoordelijkheid. Bij onderscheid is de eerste accountability-vraag: is de AI-output als indicatie behandeld (multi-source corroboration), of als identificatie? Als er geen onafhankelijke bevestiging is—bijvoorbeeld ontbrekende SIGINT-consistentie, geen passende heat signature, of twijfel over context—dan drukt precautions richting extra verificatie of shadowing in plaats van onmiddellijke engagement. Als het proces geen stopmoment afdwingt om die twijfel te expliciteren, is dat een organisatorische keuze waar verantwoordelijkheid zwaarder op command en staf kan rusten.
Bij proportionaliteit wordt de CDE-groen een bekende valkuil. Als de commandant de CDE als “legaal” leest zonder de aannames te controleren (open terrein, geen secundaire effecten), dan is dat een misinterpretatie van een modeloutput. Accountability vraagt hier: wie moest de aannames zichtbaar maken? Het AI/systems team moet onzekerheidsbanden en blinde vlekken tonen; de analist moet context toevoegen; de jurist moet signaleren dat modelgroen niet gelijkstaat aan “niet-buitensporig”. De commandant blijft eindverantwoordelijk voor het wegen, maar het systeem moet die weging mogelijk maken.
Uitkomstgericht: zelfs als een mens de laatste beslissing neemt, kan de verdeling van verantwoordelijkheid aantonen dat de fout ontstaan is door automation bias + onvoldoende transparantie + ontbrekende procesdrempels. Dat is precies waarom audit trails en expliciete twijfelvelden (wat weten we niet?) niet alleen “compliance” zijn, maar een verdedigingslinie tegen escalatie en onrechtmatige schade.
Voorbeeld 2: Dual-use communicatieknooppunt, AI-netwerkanalyse en “correlatie is geen militair doel”
Neem een scenario waarin AI netwerkanalyse gebruikt om een Iraans communicatieknooppunt te rangschikken als “high centrality” omdat verkeer piekt tijdens luchtverdedigingsactivatie. De operationele druk is groot: verstoring kan een window openen voor luchtoperaties. Het risico: “centrality” wordt behandeld als bewijs dat het object door zijn gebruik effectief bijdraagt aan militaire actie, terwijl het in werkelijkheid ook civiele noodcommunicatie en ziekenhuissystemen draagt.
Stap voor stap in accountability. Bij onderscheid op objectniveau moet iemand expliciet vastleggen: wat is de feitelijke basis dat dit knooppunt een militair doel is (aard, locatie, bestemming of gebruik), en is het voordeel van uitschakeling duidelijk militair en direct? AI kan correlaties geven, maar precautions vereisen verificatie: technische intelligence, segmentering (kan alleen het militaire deel worden geraakt?), en het uitsluiten van plausibele civiele verklaringen voor verkeerspieken. Als die verificatie ontbreekt, is het niet “pech”; het is een procesgap waarvoor command en staf verantwoordelijk zijn.
Bij proportionaliteit zijn de effecten vaak indirect en cascading. AI kan afhankelijkheden modelleren, maar modellen missen geregeld redundantie of onderschatten second-order effecten (bijv. uitval van ziekenhuiscommunicatie, waterpompen, noodmeldingen). Accountability-robuste besluitvorming dwingt daarom tot een expliciete lijst van voorzienbare civiele gevolgen en onzekerheden. Het “strategische” voordeel van druk uitoefenen is juridisch zwakker dan een concreet direct voordeel zoals het direct verhinderen van imminente aanvallen; dat moet in de argumentatie zichtbaar zijn.
In termen van verantwoordelijkheidsverdeling komt hier vaak een patroon naar voren: de AI/engineering laag levert een overtuigende ranking, de intel-laag neemt die ranking over als bewijs, en de besluitlaag behandelt de maatstaf als juridisch criterium. De preventie zit in rolzuiverheid: AI levert indicaties en scenario’s, intel levert context en verificatie, juridisch toetst de norm, commandant weegt en beslist. Pas als die keten expliciet wordt gemaakt, kun je ook eerlijk bepalen waar aansprakelijkheid ontstaat als er toch onrechtmatige schade volgt.
Wat je vandaag moet vasthouden (en wat je niet moet zeggen na een incident)
De kern is simpel maar hard: AI verandert de snelheid en vorm van besluiten, maar niet de plichten onder IHL/LOAC. Verantwoordelijkheid blijft gekoppeld aan onderscheid, proportionaliteit en precautions—en die plichten werken door de hele kill chain, ook upstream waar AI targets “vindt” of “groen” kleurt. Aansprakelijkheid wordt juist waarschijnlijker als organisaties geen transparante workflow hebben die onzekerheid en alternatieven zichtbaar maakt.
Drie zinnen die je beter nooit als verdediging gebruikt:
-
“Het model had hoge confidence.” (Confidence is geen juridische zekerheid.)
-
“We hadden een mens in de loop.” (Een mens zonder inzicht is geen meaningful control.)
-
“De CDE was groen.” (Groen is een intern criterium, geen LOAC-uitspraak.)
Wat wél werkt is aantoonbaar zorgvuldig handelen: multi-source verificatie, vastgelegde normatieve proportionaliteitsweging, en procesdrempels die twijfel laten stoppen in plaats van versnellen.
Next, we'll build on this by exploring Transparantie en escalatiepaden [20 minutes].