Op 10 maart berichtte de Financial Times over een interne Amazon-notitie waarin sprake was van een "trend of incidents" op Amazon.com, gekenmerkt door een "high blast radius" en "Gen-AI assisted changes".
Een dag later zette Amazon een correctie op de eigen site. "In fact, only one of the recent incidents involved AI tools in any way, and in that case the cause was unrelated to AI and instead our systems allowed an engineering team user error to have broader impact than it should have." Dat ene geval waar wel AI-gereedschap bij betrokken was, ging over "an engineer following inaccurate advice that an AI tool inferred from an outdated internal wiki, and none involved AI-written code."
Twee partijen met toegang tot interne documenten, over dezelfde week, oneens over de vraag of er een model in het spel was. En het wordt er daarna niet helderder op, want de FT stelde later een deel van de eigen beweringen bij, iets waar Amazon in die correctie zijdelings naar verwijst.
CNBC zag het document ook en meldt er nog iets bij. Er stond eerst in dat "generative AI-assisted production changes were partly to blame for the issues", maar "the reference to GenAI was subsequently deleted." Het verslag van wat er gebeurd was, werd dus nog bijgesteld terwijl de ruzie over de inhoud ervan al liep.
The Register had de vraag al bij Amazon neergelegd op de dag dat het FT-stuk verscheen. Wat er terugkwam, was de lijn die het bedrijf in februari bij een ander incident had getrokken: er was geen overtuigend bewijs dat storingen vaker voorkomen met AI-gereedschap. The Register zette daar één observatie naast: "the company has provided no data that would allow an independent analysis of incident causes."
Daar zit het hele probleem, en het loont de moeite er even bij stil te staan voordat je naar een checklist grijpt.
Let op: de twee partijen bestrijden niet eens dezelfde bewering. De notitie zegt "Gen-AI assisted changes". De correctie zegt "AI-written code". Dat zijn twee verschillende dingen, en ze kunnen allebei kloppen. Niemand had afgesproken wat de term betekende voordat hij nodig was.
Als Amazon met alle telemetrie over de eigen webwinkel er een paar dagen publiek over steggelt of er een agent aan te pas kwam, dan beslecht jouw reconstructie het om drie uur 's nachts ook niet.
Dit is een ander verhaal dan een agent die ontspoort
Een maand geleden schreef ik een draaiboek voor de agent die de fout in gaat: sessie bevriezen, reconstrueren uit het transcript, blast radius bepalen, roteren. Dat draaiboek werkt omdat het bewijs bestaat. Er is een sessie, een .jsonl-transcript, snapshots van bestanden van vlak voor de bewerking.
Productie is het andere geval, en dat is op één punt lastiger.
Als de pager afgaat voor code die een model drie weken geleden schreef, is er niemand meer aan wie je de vraag kunt stellen waar elk incidentproces op leunt. "Vraag het degene die het geschreven heeft" veronderstelt iemand die het geschreven heeft, met kennis die nooit in de diff terechtkwam: wat diegene eerst probeerde, waarvan diegene wist dat het wankel was, welk randgeval diegene bewust liet zitten.
Die kennis heeft niemand. Ze bestond alleen in een sessie, en die sessie is afgelopen.
Dit stuk begint bovendien één stap te laat, namelijk op het moment dat je al weet dat er iets mis is. Waaraan je dat om te beginnen merkt, is een andere vraag en kreeg een eigen post.
De agent is een tweede lezer, geen getuige
Om drie uur 's nachts is de reflex om de stacktrace terug te plakken in het gereedschap dat de code opleverde.
Doen. Het is een snelle second opinion en vaak een goede. Wees alleen helder over wat je krijgt, want dat bepaalt hoeveel gewicht het antwoord kan dragen.
Het model herinnert zich niet dat het die code schreef. Het leest hem nu, voor het eerst, net als jij, alleen zonder alles wat jij weet over wat productie het afgelopen half uur heeft gedaan, en met een stevige neiging om een zelfverzekerde, behulpzaam klinkende oorzaak te produceren. Vraag waarom de code deed wat hij deed en je krijgt een plausibele lezing van die code, ter plekke gegenereerd, gebracht in de toon van een herinnering.
Behandel het als een collega aan wie je een bestand hebt gegeven, en geef het antwoord het gewicht dat daarbij hoort.
Erger nog: de code is sindsdien veranderd. Het onderzoek naar foutlokalisatie laat zien dat modellen juist daar broos worden. Over 750.013 foutlokalisatietaken op tien modellen zorgen betekenisbehoudende wijzigingen, de gewone sporen van een codebase waar een paar keer aan gezeten is, ervoor dat modellen fouten die ze eerder wél vonden in 78% van de gevallen laten liggen.
Vier dingen die er van tevoren moeten zijn
Geen van deze vier is nieuw. Nieuw is dat het nu duurder uitpakt als er één ontbreekt, want de terugvaloptie waar ze allemaal stilzwijgend op leunden, een mens die het zich herinnert, bestaat niet meer.
Eigenaarschap, vastgelegd waar een machine het kan lezen. In een bestand, in plaats van in het gegeven dat Sarah die service kent. CODEOWNERS is de goedkoopste vorm en die overleeft het vertrek van Sarah.
Een rollback waar de database geen veto over heeft. De deploy terugdraaien maakt de code ongedaan. Het draait geen migratie terug die al gelopen heeft, en het haalt verstuurde mails niet terug. Daarom is de feature flag de echte ongedaan-knop, en daarom is een schemawijziging in elke workflow het bijzondere geval.
Een draaiboek per storingssoort, gelinkt vanuit het alarm. Het hoofdstuk over troubleshooting in het SRE-boek van Google beschrijft de vorm beter dan welke productpitch ook: het alarmeringssysteem maakt een ticket aan "with links to the black-box prober's recent results and to the playbook entry for this alert". Het draaiboek is een link die het alarm bij zich draagt.
Herkomst die je echt kunt bevragen. Dit is het punt waar iedereen de fout in gaat, en het verdient een eigen kopje.
Waarom de git-regel het antwoord niet is
De commit is de voor de hand liggende plek om te kijken. De meeste agent-tools kunnen een Co-Authored-By-regel meeschrijven met de naam van het model erin, en dat aanzetten voelt alsof je herkomst in één middag hebt opgelost.
Dat is niet zo, om drie redenen.
Het meet je instellingen, niet het auteurschap. Zo'n regel verschijnt zodra de tool zo staat ingesteld. Dat zegt iets over een configuratiebestand in een bepaalde maand, niet over wie de code schreef. Zet het in het voorjaar aan en in het najaar uit, en je historie beweert dat het model is gestopt met werken aan je codebase.
Het zit op het verkeerde niveau. Het is één vlag op een hele commit, vaak een samengevoegde changeset waar een stuk of tien bestanden in zitten. Welk van die bestanden het model heeft geschreven blijft onzichtbaar, laat staan welke regels.
Het overleeft onderhoud niet. Hernoem het bestand, trek de functie eruit, herformatteer de module, en de regels verhuizen terwijl de attributie achterblijft op een commit die niemand ooit nog terugleest.
Git legt vast wie gecommit heeft. Oncall moet weten hoe een regel is ontstaan, en dat zijn nooit dezelfde vragen geweest. Jij hebt het gemerged, jij bent ervoor verantwoordelijk: dat is de juiste regel. Hij beslecht aansprakelijkheid en verder niets.
Een betere attributieregel lost dit niet op. De reconstructie moet ergens anders vandaan komen dan uit de repository: uit de deployregistratie, de reviewregistratie, het sessiearchief. En dat is een administratieprobleem, beslist ruim voordat de pager afgaat.
Wat er in een bruikbaar incidentverslag hoort
Hier heeft de veiligheidswereld werk verzet dat het stelen waard is, en het eerste wat je steelt, is wat ze zelf toegeven.
De AI Incident Database opent met de luchtvaart, die haar toenemende veiligheid grotendeels dankt aan het stelselmatig analyseren en archiveren van ongelukken en incidenten in een gedeelde database. Daar zijn de definities scherp: bij een ongeluk is er zware schade of verlies van mensenlevens, een incident is een geval "where the risk of an accident substantially increases". Vervolgens geeft de database toe dat ze die lijn voor AI niet kan trekken, en werkt in plaats daarvan met "an adaptive criteria for ingesting 'incidents' where reports are accepted or rejected on the basis of a growing rule set".
De hardnekkigste poging om een AI-incident te definiëren heeft de definitie laten varen en de regelverzameling gehouden. Doe hetzelfde. Probeer niet in abstracto vast te leggen wat bij jullie een "AI-incident" heet, want dat is precies de discussie die Amazon en de FT met elkaar voerden. Benoem in plaats daarvan je storingssoorten, en blijf die lijst aanvullen.
Twee structuren zijn het rechtstreeks overnemen waard.
De incident response van de AIID vraagt vier dingen: wat er gebeurd is, waarom het gebeurd is, wat eraan gedaan is en wat herhaling voorkomt. Dat is je postmortemsjabloon en het past in een tekstbestand.
De AI Incidents and Hazards Monitor van de OESO legt elk voorval vast langs een aantal losse facetten, in plaats van het terug te brengen tot één getal. Filteren kan op schadesoort, getroffen partijen, bedrijfsfunctie, de taak die het AI-systeem uitvoerde, en de autonomie van dat systeem. Het facet dat je moet overnemen is autonomie. "De agent deed het" en "een engineer nam een suggestie over" zijn verschillende incidenten met verschillende oplossingen, en het ene geval bij Amazon waar AI aan te pas kwam, was het tweede soort: een mens die handelde naar advies dat een tool uit een verouderde wiki had opgemaakt.
Over artikel 73, precies geformuleerd
Artikel 73 van de Europese AI-verordening is de meldplicht waar iedereen naar wijst, en wat erover geschreven wordt is meestal te breed of achterhaald.
Het verplicht aanbieders van AI-systemen met een hoog risico die op de Europese markt zijn gebracht om ernstige incidenten te melden bij markttoezichthouders, of bij het AI-bureau voor de systemen die daar nu onder vallen. Gebruiksverantwoordelijken komen er ook niet onderuit. Elke termijn loopt vanaf het moment dat "the provider or, where applicable, the deployer" ervan weet, en artikel 26, lid 5 verklaart artikel 73 mutatis mutandis van toepassing op de gebruiksverantwoordelijke zodra de aanbieder onbereikbaar is.
Alleen: niets daarvan raakt jou. Een webapplicatie uitbrengen waar een agent aan meegeschreven heeft, maakt je geen van beide, en jouw CRUD-app is om te beginnen geen AI-systeem. Wie suggereert dat de plicht de jouwe is, verkoopt iets.
De datums zijn bovendien verschoven, en de berichtgeving loopt achter. De Digital Omnibus on AI, verordening (EU) 2026/1744, verscheen op 24 juli in het Publicatieblad en trad op 27 juli in werking, dagen voor de deadline die hij verzette. De afdelingen 1 tot en met 3 van hoofdstuk III gingen naar 2 december 2027 voor systemen onder bijlage III en 2 augustus 2028 voor bijlage I, met als reden "the delayed availability of standards, common specifications, and alternative guidance and the delayed establishment of national competent authorities". Artikel 73 staat in hoofdstuk IX en behield de algemene datum van 2 augustus 2026.
De stillere helft zit in artikel 111. De AI-verordening liet hoogrisicosystemen die vóór de deadline al op de markt waren sowieso al buiten het grootste deel van de regels vallen, tenzij ze daarna "significant changes in their designs" ondergingen. Wat de Omnibus veranderde, is de datum waar die zin naar wijst: geen vaste 2 augustus 2026 meer, maar het moment waarop hoofdstuk III nu ingaat. De uitgang zat er dus al, en er kwam zestien tot vierentwintig maanden bij om er doorheen te glippen, afhankelijk van de bijlage. De verboden praktijken uit artikel 5 blijven wel gelden, en alles wat voor overheden bedoeld is moet hoe dan ook vóór 2 augustus 2030 in orde zijn.
De meldplicht loopt dus, terwijl voor het grootste deel van de groep waarvoor hij echt iets betekent een uitzondering of uitstel geldt. Dat is iets anders dan wat "van kracht vanaf augustus 2026" op zichzelf suggereert.
Wat je er hoe dan ook uit meeneemt, is de vorm. Melden gebeurt onmiddellijk, met daarachter uiterste termijnen: 15 dagen nadat je ervan op de hoogte raakt, twee dagen bij een wijdverbreide inbreuk, 10 dagen als er iemand is overleden. De ernst bepaalt de klok. Dat is het juiste instinct, en het tegendeel van één uniforme SLA.
En het scherpste stuk is wat die klok in gang zet. Hij begint te lopen zodra de aanbieder "has established a causal link between the AI system and the serious incident or the reasonable likelihood of such a link".
Een causaal verband. Opgeschreven door mensen die ervan uitgingen dat de gegevens om zo'n verband vast te stellen er zouden zijn.
Die zin moet je onthouden, want dat is precies wat Amazon, de FT en jij om drie uur 's nachts alle drie missen. Je kunt geen veld invullen dat je nooit hebt vastgelegd, en een termijn die begint op het moment dat je oorzakelijkheid vaststelt, is voor de meeste teams een termijn die nooit begint.
Wat je vastlegt, te beginnen met wat je al draait
Hier is geen platform voor nodig. Vier velden volstaan, mits ze ergens duurzaam bestaan vanaf het moment van deployen.
- Wat er uitging: de SHA, het tijdstip van de deploy, en wie of wat het heeft goedgekeurd. De meeste deployscripts kennen die SHA al en gooien de rest weg.
- Hoe het tot stand kwam: het autonomieniveau, in één woord. Door een mens geschreven, gesuggereerd en overgenomen, of door een agent geschreven onder review.
- Wie er nu verantwoordelijk voor is, in tegenstelling tot wie het gecommit heeft.
CODEOWNERS, en er hoort een mens in te staan. - Waarvan bekend was dat het wankel was: datgene wat de reviewer heeft doorgelaten. De review is toch al de wachtrij waar de rest achter vaststaat, dus dit veld mag vrijwel niets kosten: één regel, bij het mergen. Het is het veld dat het geval bij Amazon had tegengehouden, want iemand wist dat die wikipagina oud was.
Dat laatste veld is impopulair omdat je er bij het mergen iets voor moet toegeven. Het is ook het enige veld in de lijst dat de kennis draagt die vroeger in het hoofd van een collega zat.
Heb je ze alle vier al staan, dan ben je een uitzondering. Dat het gat blijft bestaan komt niet door onwetendheid. Elk van deze maatregelen kost iets op een doordeweekse dinsdag en betaalt pas uit op een nacht die je nog niet gehad hebt.
Het rapport van Lightrun uit 2026, een enquête onder 200 senior site-reliability- en DevOps-verantwoordelijken, constateerde dat 43% van de door AI gegenereerde wijzigingen in productie handmatig gedebugd moest worden, ook nadat ze door QA en staging waren gekomen, en dat 88% van de teams twee tot drie deploycycli nodig had voordat een door AI voorgestelde fix te verifiëren was. Lightrun verkoopt gereedschap om in productie te debuggen, dus houd dat in gedachten bij hoe ze het presenteren. Die 43% blijft een getal over nachten die je nog niet gehad hebt.
Het detail waar ik op terug blijf komen, is Amazons eigen weergave van het ene geval waar wel degelijk gereedschap bij betrokken was: een engineer die advies opvolgde dat een model had opgemaakt uit een interne wiki die niet meer klopte. Geen agent die op hol sloeg. Een verouderd document, met vertrouwen gelezen, te goeder trouw opgevolgd.
Die faalvorm staat op deze site beschreven als iets wat agents overkomt. Het blijkt ook de mensen te overkomen die lezen wat de agent eruit opmaakte, en het bereikt productie langs precies dezelfde weg.