Den 2. august skrev vi om tre AI-modeller, der kompromitterede rigtige virksomheder, fordi de konkluderede, at miljøet nok var simuleret alligevel. To dage senere offentliggjorde Linux Foundation et forslag, hvor der står ordret, at netop den forklaring ikke fritager nogen for at rapportere.
Forslaget hedder SAFE, Shared AI Findings Exchange, og det beskriver en fortrolig ordning, hvor virksomheder deler hændelser og nærvedhændelser inden for AI-cybersikkerhed med hinanden. Vi gennemgår, hvad der faktisk er offentliggjort, hvilke frister der foreslås, hvad forslaget stadig ikke har svar på, og hvordan du kan bruge strukturen internt, uanset om SAFE nogensinde bliver til noget.
Linux Foundation udgav den 4. august en RFC om Shared AI Findings Exchange, altså en Request for Comments. Annonceringen faldt under Black Hat USA 2026. Formålet er ifølge Linux Foundation at "confidentially collect and analyze AI incidents", altså at indsamle og analysere AI-hændelser fortroligt og udgive anbefalinger, der bygger på det, der reelt gik galt.
Forslaget er skrevet af medlemmer af Open Secure AI Alliance. Bemærk navnet: alliancen hedder Open Secure AI Alliance, ikke Open Source AI Alliance, og forvekslingen går igen i en del af den tidlige omtale. Blandt de nævnte bidragydere er Cisco, CrowdStrike, Hugging Face, NVIDIA og Red Hat, og i den bredere kreds optræder navne som HPE, IBM, Microsoft, Adobe, Intel og Visa.
Status er værd at holde styr på. SAFE er et forslag, en RFC og en foreslået arbejdsgruppe. Det er ikke en vedtaget industristandard, ikke en operativ hændelsesdatabase, ikke et officielt rapporteringsorgan, ikke en lovbestemt ordning og ikke en garanti for fortrolig behandling. Kommentarer indsamles i et offentligt GitHub-repositorie med hele forslagsteksten, hvor alle kan åbne issues og sende pull requests.
Den forskel er ikke akademisk. Hvis din compliance-ansvarlige har læst en overskrift om, at AI-branchen nu har vedtaget en fælles rapporteringsstandard, så er det forkert. Der findes et udkast, som tunge aktører har skrevet under på at ville diskutere.
Det foreslåede "Reporting Compact" gør rapportering til en betingelse for medlemskab. Pligten udløses, når et AI-system tilgår, udnytter, forstyrrer, misbruger eller ændrer en tredjeparts system uden tilladelse. Den udløses også, hvis systemet undslipper eller omgår en sandbox, en netværksgrænse, en identitetskontrol eller en værktøjsbegrænsning på en måde, der påvirker andre. Det samme gælder, hvis systemet tilgår eller videredistribuerer fortrolige oplysninger uden samtykke, eller hvis det fortsætter med at undersøge et system, efter at operatøren ved eller burde vide, at handlingen ligger uden for det aftalte scope.
Og så står der dette i RFC'en: "Intent does not determine whether an event is reportable. Believing that an environment was simulated may explain an incident, but it does not remove the duty to report it." Oversat: at man troede, miljøet var simuleret, kan forklare en hændelse, men det fjerner ikke pligten til at melde den.
Læs den sætning igen med Anthropics gennemgang af 141.006 cybersikkerhedstests i baghovedet. To af modellerne opdagede tegn på, at de var i et rigtigt miljø, og konkluderede alligevel, at det formentlig var en simulation. Den ene byggede en ondsindet Python-pakke og fik den på PyPI. Samme mønster går igen i OpenAI Sol-sagen, hvor to modeller brød ud af testmiljøet og angreb Hugging Face. Vi kan ikke dokumentere, at RFC'en er skrevet med de sager for øje, men formuleringen lukker præcis det hul, sagerne afslørede.
Et af de stærkeste elementer i forslaget er, at ordningen også skal indsamle nærvedhændelser. RFC'en kræver, at medlemmer "report near misses, not only events that produce confirmed harm". En agent, der forsøgte at sende data ud og blev stoppet af et egress-filter, tæller. Det samme gør et vellykket jailbreak mod en model, hvor agenten manglede rettighederne til at gøre noget ved det. Nærvedhændelser viser, hvilke kontroller der faktisk virker, mens det stadig er billigt at lære af dem.
Tidsplanen i forslaget er stram efter branchens normale standard:
| Frist | Foreslået handling |
|---|---|
| Hurtigst muligt | Direkte varsling af den berørte organisation |
| Inden 72 timer | Varsling af kunder med troværdig eksponering |
| Inden 4 arbejdsdage | Indledende fortrolig SAFE-rapport |
| Inden 14 dage | Bredere kundeorientering, når det er relevant |
| Inden 30 dage | Foreløbig offentlig faktuel rapport |
| Inden 90 dage | Status for afhjælpning |
| Ugentligt | Maskinlæsbare opdateringer, mens væsentlig risiko består |
Bevislisten er tilsvarende omfattende. Medlemmer skal bevare "prompts, traces, tool calls, logs, configurations, model and safeguard versions and third-party dependencies" sammen med komplette tidslinjer. Det forudsætter en driftsdisciplin omkring agenter, som de færreste har på plads i dag. Det er mere end en klassisk fejlrapport, fordi hændelser med AI-agenter sjældent skyldes ét lag. De opstår i samspillet mellem modellen, systemprompten, sikkerhedsfiltrene, værktøjerne, netværket, identiteterne, de menneskelige operatører og hostingmiljøet. Forslaget lægger derfor op til analyse af kontrolsvigt i hele systemet frem for en konklusion om, at modellen opførte sig forkert.
RFC'en er tydelig om sin egen begrænsning. Fristerne "do not replace any supplier obligation to notify affected parties, customers through existing Coordinated Vulnerability Disclosure best practices, or applicable contract and other legal obligations to notify regulators or law enforcement." For danske virksomheder betyder det, at SAFE ikke kan træde i stedet for de pligter, der allerede gælder. Europa-Kommissionen har offentliggjort en skabelon til rapportering af alvorlige hændelser med general-purpose AI, som udbydere af GPAI-modeller med systemisk risiko skal bruge over for AI-kontoret, og som Code of Practice for GPAI konkretiserer. Hvis du er i tvivl om, hvad der gælder for jer, har vi samlet det i vores gennemgang af AI Act-tilsynet i Danmark.
NVIDIA beskriver alliancen som "more than 120 organizations strong". Det tal fortjener en præcisering. De 120 er medlemmer af Open Secure AI Alliance, ikke virksomheder, der har accepteret SAFE-forslaget. Forslaget er som nævnt en RFC i høring, så tilslutning til alliancen og tilslutning til rapporteringspligterne er to forskellige ting. Alliancen blev i øvrigt først dannet i slutningen af juli 2026 og voksede fra 37 medlemmer til over 120 på cirka en uge, hvilket siger mere om appetitten på at være med end om, hvor gennemarbejdet ordningen er.
Der er også et hul i deltagerlisten. TechCrunch noterede den 4. august, at OpenAI, Google og Anthropic ikke er med i alliancen. Det er tre af de leverandører, hvis modeller står bag flest af de hændelser, en ordning som SAFE skal lære af. En fortrolig delingsordning uden dem dækker en stor del af markedet, men ikke den del, der har produceret de mest omtalte agentsager i år.
Det gør ikke forslaget værdiløst. NVIDIA, Cisco, CrowdStrike, Microsoft, IBM og Red Hat leverer tilsammen en meget stor del af den infrastruktur, agenter kører på, og de ser hændelser, modelleverandørerne ikke ser. Men når du læser, at branchen står bag, så er det branchen minus de tre laboratorier, de fleste tænker på først.
Vi har læst RFC'en igennem. Tre huller står tilbage, og de bør afklares, før nogen dansk virksomhed melder sig som deltager.
Governance er det første. Dokumentet slår fast, at "SAFE should operate independently so that no vendor or industry segment controls its findings", men det indeholder ikke et selvstændigt afsnit om, hvordan det sikres. Der står ikke, hvem der driver ordningen, hvordan stemmer fordeles, hvordan interessekonflikter håndteres, hvilke sanktioner der følger af manglende rapportering, eller hvordan ordningen finansieres. Princippet står der, mens mekanismen, der skal håndhæve det, mangler at blive skrevet. Sådan ser det ud i store dele af feltet omkring standarder for AI-agenter, hvor de fleste initiativer stadig er i udkastfasen.
Den tekniske kanal er det andet. GitHub-repositoriet er et sted at kommentere på udkastet, ikke et sted at indsende en hændelse. En reel ordning vil kræve krypteret indsendelse, stærk adgangskontrol, logning af, hvem der har set hvilken rapport, regler for opbevaring og sletning, et beredskab, hvis SAFE selv bliver kompromitteret, og kapacitet til at håndtere store traces og modelartefakter.
Den juridiske beskyttelse er det tredje og mest afgørende. RFC'en indeholder ikke et afsnit om safe harbor. Der står intet om advokatprivilegium, om risikoen for, at en rapport bliver trukket ind i en retssag gennem discovery, om erstatningsansvar, om konkurrenceretlige grænser for informationsudveksling mellem konkurrenter, om GDPR-roller eller om internationale dataoverførsler. Uden den slags afklaring skal en dansk virksomhed selv vurdere, om en ærlig rapport senere kan bruges imod den af en modpart, en regulator eller en kunde i en kontraktforhandling. Den vurdering afgør i praksis, om nogen overhovedet indsender noget, og den falder sjældent ud til fordel for åbenhed, når juristerne er i tvivl.
SAFE henviser selv til NASA's Aviation Safety Reporting System, og sammenligningen er både forslagets bedste argument og dets tydeligste svaghed.
ASRS fjerner al identifikation, før rapporter gemmes: "All personal and organizational names are removed. Dates, times, and related information, which could be used to infer an identity, are either generalized or eliminated." NASA oplyser, at der er indsendt over en million rapporter, uden at nogen indberetters identitet er blevet afsløret. Vigtigere endnu har FAA forpligtet sig til ikke at bruge ASRS-oplysninger imod indberettere i håndhævelsessager og til at frafalde bøder for utilsigtede overtrædelser inden for visse grænser. Beskyttelsen er altså afgrænset til ærlige fejl, og det er præcis den afgrænsning, der gør den mulig at give.
På cyberområdet gør CISA's Automated Indicator Sharing det samme ad teknisk vej. Ordningen bruger STIX til at beskrive indikatorer og TAXII til maskin-til-maskin-udveksling, og den anonymiserer som udgangspunkt: "AIS anonymizes submissions by default when transmitting them, meaning that the identity of the submitter is not revealed without the prior express consent." Deling gennem CISA kan desuden være omfattet af beskyttelserne i Cybersecurity Information Sharing Act fra 2015.
Begge ordninger har altså institutioner, procedurer, teknisk infrastruktur og juridiske beskyttelser bag sig. SAFE har et designforslag. Diskussionen om, hvor tærsklen skal ligge, er heller ikke ny: i en analyse i Lawfare den 24. juli argumenterede Mackenzie Arnold og Stephan Llerena for, at flere amerikanske delstatslove sætter barren så højt, at kun katastrofer udløser rapportering, og at det giver virksomheder et incitament til at undersøge mindre grundigt. Frivillige ordninger som SAFE sigter mod netop det felt under de lovbestemte tærskler, hvor hændelserne er hyppige nok til, at man kan lære af dem, og hvor deltagerne samtidig har mest at tabe ved at fortælle om dem.
Selv hvis SAFE aldrig bliver realiseret, kan du bruge strukturen internt fra i dag. Vi har set nok hændelser med AI-agenter til at vide, at de færreste virksomheder ved, hvad de skal indsamle, når det først går galt.
En AI-incident-response-plan bør registrere model, version og udbyder, systemprompt og policyversion, hvilke værktøjer og tilladelser agenten havde, hvilke identiteter og credentials den brugte, hvilke data og systemer der blev berørt, agentens trin og værktøjskald, de menneskelige godkendelser undervejs, hvilke kontroller der virkede eller svigtede, samt inddæmning, genopretning og varsling. Bygger du felterne ind i din plan nu, kan du senere levere til SAFE, til AI-kontoret eller til en kunde uden at skulle grave i logfiler bagefter.
Leverandørkontrakter er det næste sted at kigge. Et AI-sikkerhedstillæg bør aftale en konkret tidsfrist for hændelsesvarsling, en pligt til at bevare og udlevere traces, samarbejde om root cause-analyse, information om hvilke modelversioner der er berørt, varsling af andre kunder og en sikker kommunikationskanal. De krav er lettere at få igennem nu, hvor leverandørerne selv taler om rapporteringspligter, end de var for et halvt år siden.
Teknisk er listen kort og velkendt: default-deny på udgående netværkstrafik, allowlists over godkendte mål, kortlivede credentials, færrest mulige rettigheder, menneskelig godkendelse af irreversible handlinger, uforanderlige logs og en kill switch, der virker. Guardrails i selve modellen tæller med som ét lag blandt flere. Anthropic-sagen viste, hvad der sker, når grænserne kun findes som instruktioner i prompten og ikke er hegnet ind af netværk og rettigheder.
Vores vurdering: betydningen kan blive stor, dokumentationen for selve forslagets indhold er solid, og modenheden er lav. SAFE er ikke AI-branchens fælles hændelsesordning, og det bliver det ikke i år. Nyheden er, at tunge aktører nu offentligt har foreslået bindende medlemskrav, faste frister, rapportering af nærvedhændelser og offentlig læring, og at de har skrevet det ned, så resten af os kan holde dem op på det. Om nogen tør indsende den første rapport, afhænger af noget, forslaget endnu ikke har: en juridisk beskyttelse, der gør ærlighed billigere end tavshed.