En AI-beredskabsplan er en praktisk plan for, hvordan en organisation opdager, begrænser, undersøger og retter fejl eller misbrug i AI-systemer. Den beskriver ansvar, data, nødgreb, kommunikation og genopretning, så AI kan stoppes, ændres eller erstattes, før en hændelse vokser.
En AI-beredskabsplan beskriver, hvordan fejl, misbrug og uventet adfærd i AI-systemer opdages, stoppes og rettes. Den giver overblik over ansvar, logs, nødgreb, manuel fallback, generativ AI-risiko og sammenhængen mellem teknisk drift, governance og relevante EU-krav.
Hvad betyder en AI-beredskabsplan?
En AI-beredskabsplan omsætter AI-risici til konkrete handlinger før, under og efter en hændelse. Den skal ikke kun forklare, hvem der kontaktes, men også hvilke systemer der kan lukkes, hvilke data der skal sikres, hvilke beslutninger der kræver menneskelig godkendelse, og hvordan brugere får en stabil proces, mens AI-løsningen undersøges.
Planen er særlig relevant, når AI indgår i kundeservice, sagsbehandling, rekruttering, dokumentanalyse, sikkerhedsovervågning, softwareudvikling, beslutningsstøtte eller automatiserede arbejdsgange. Jo mere systemet påvirker mennesker, økonomi, data eller drift, desto mere konkret bør beredskabet være.
En god plan hænger sammen med AI-governance, men den har en mere operationel funktion. Governance fastlægger rammer, ansvar og kontrol. Beredskabsplanen beskriver, hvad der sker, når et AI-system faktisk opfører sig forkert, bliver misbrugt eller ikke længere kan stoles på i den konkrete kontekst.
Hvornår har en organisation brug for den?
Behovet opstår, når AI går fra eksperiment til arbejdsproces. En intern chatbot med adgang til personalepolitikker, et værktøj til kundesvar, et system til prisforslag eller en model, der prioriterer henvendelser, kan alle skabe fejl, som almindelig IT-drift ikke alene kan håndtere. Problemet er ikke kun nedetid. Det kan også være forkert output, uventet databrug, skæv behandling, manglende forklarlighed eller for stor automatiseret handlefrihed.
Planen bør være på plads, før systemet får adgang til følsomme data, eksterne værktøjer, integrationsnøgler, produktionsmiljøer eller beslutninger med reel konsekvens. I mindre organisationer kan den være kort og knyttet til eksisterende beredskab. I større miljøer bør den være koblet til risikoregister, leverandørstyring, logning, databeskyttelse, sikkerhedsteam, juridisk funktion og forretningsansvarlige.
Den mest praktiske afgrænsning er at spørge: Hvis AI-systemet giver et forkert svar, lækker data, misforstår sin opgave eller udfører en uønsket handling i dag, hvem kan så stoppe det, forklare hændelsen og få en manuel proces til at fungere?
Hvilke hændelser skal planen kunne håndtere?
AI-hændelser kan være tekniske, organisatoriske eller en blanding. Nogle ligner klassiske sikkerhedshændelser, mens andre handler om modeladfærd, datakvalitet og menneskelig brug. En beredskabsplan bør derfor have en klar taksonomi, så en fejl ikke først skal defineres midt i presset.
- Forkerte eller opdigtede svar, hvor en AI-hallucination bliver brugt som beslutningsgrundlag.
- Uautoriseret adgang til data, systeminstruktioner, dokumenter eller integrationsnøgler.
- Instruktionsinjektion, hvor input fra en bruger, fil, hjemmeside eller e-mail får modellen til at handle uden for sin tiltænkte rolle.
- Modeldrift, hvor præcision, tone, sikkerhed eller relevans ændrer sig efter nye data, ny kontekst eller opdateret model.
- Skæv eller diskriminerende behandling i scoring, prioritering, anbefalinger eller automatiseret sortering.
- For stort handlemandat, hvor en AI-agent kan sende, slette, bestille, ændre eller eskalere uden tilstrækkelig menneskelig kontrol.
- Leverandørfejl, ændrede vilkår, utilgængelige modeller eller ændringer i en ekstern API.
Listen skal tilpasses systemets formål. Et værktøj til idégenerering kræver et andet beredskab end et AI-system, der påvirker ansættelse, kredit, sundhed, undervisning, kritisk infrastruktur eller adgang til offentlige ydelser.
Hvordan adskiller den sig fra almindeligt IT-beredskab?
Almindeligt IT-beredskab fokuserer ofte på tilgængelighed, backup, adgangsstyring, sårbarheder, malware, netværk og gendannelse. En AI-beredskabsplan skal også dække disse forhold, men den skal derudover håndtere fejl i output, datagrundlag, modelvalg, kontekst, menneskelig fortolkning og beslutningsansvar.
NIST beskriver AI-risici som tæt forbundet med både tekniske forhold og den sociale kontekst, systemet bruges i. Det betyder, at en AI-hændelse kan være alvorlig, selv om serveren kører, adgangskontrollen virker, og der ikke er et klassisk databrud. Hvis systemet systematisk giver skæve anbefalinger eller fejlagtigt afviser gyldige sager, er problemet stadig operationelt.
| Område | Klassisk IT-beredskab | AI-beredskab |
|---|---|---|
| Fejltype | Nedetid, adgangsbrud, sårbarhed eller datatab | Forkert output, uventet adfærd, datalækage, bias eller modeldrift |
| Kontrolpunkt | Systemstatus, logs, backup og sikkerhedsalarmer | Input, output, modelversion, datakilder, menneskelig godkendelse og beslutningsspor |
| Genopretning | Gendan service, luk sårbarhed og genåbn adgang | Stop AI-funktionen, skift til manuel proces, korriger output og juster kontrolniveau |
Hvilke roller skal være afklaret på forhånd?
En plan virker først, når rollerne er konkrete. Det er ikke nok, at “IT” eller “ledelsen” har ansvaret. Hver kritisk AI-løsning bør have en systemejer, en dataansvarlig rolle, en sikkerhedsrolle, en forretningsansvarlig, en person med mandat til at stoppe funktionen og en kontakt til leverandøren, hvis systemet afhænger af eksterne modeller eller værktøjer.
Der bør også være klare grænser for menneskelig godkendelse. Hvis AI kun foreslår tekst, kan efterkontrol være nok. Hvis AI kan ændre data, sende beskeder, påvirke prioriteringer eller kalde andre systemer, skal planen beskrive, hvornår handlingen stoppes, hvornår den kræver godkendelse, og hvem der kan ophæve automatiseringen.
Rollerne skal kunne aktiveres uden lange møder. Et brugbart beredskab har navngivne funktioner, kontaktveje, stedfortrædere, tidsfrister og en enkel beslutningsrækkefølge. Den rækkefølge reducerer risikoen for, at en hændelse bliver liggende hos den første medarbejder, der opdager et mistænkeligt AI-svar.
Hvilke data og logs skal kunne findes hurtigt?
En AI-hændelse kan sjældent forstås uden sporbarhed. Beredskabsplanen bør beskrive, hvilke logs der findes, hvor længe de gemmes, hvem der må tilgå dem, og hvordan de sikres, når en hændelse undersøges. Det gælder både tekniske logs og de oplysninger, der forklarer den konkrete AI-kontekst.
Relevante spor kan være modelnavn, modelversion, systeminstruktioner, inputtype, tilknyttede dokumenter, hentede datakilder, brugerrolle, tidsstempel, integrationskald, output, menneskelig godkendelse og efterfølgende handling. For generativ AI bør planen også dække, om input eller output kan indeholde personoplysninger, forretningshemmeligheder, ophavsretligt beskyttet materiale eller fortrolige kundedata.
Logning må ikke blive en ny risiko. Hvis logs gemmer fulde samtaler, filer eller følsomme oplysninger, skal adgangen begrænses, og formålet skal være klart. En plan for forebyggelse af datalækager i AI-applikationer bør derfor hænge sammen med beredskabsplanens krav til bevismateriale.
Hvordan håndteres generativ AI og automatiserede agenter?
Generativ AI og AI-agenter kræver et særskilt beredskab, fordi de ofte arbejder med fritekst, eksterne datakilder, værktøjskald og skiftende brugerintentioner. OWASP beskriver blandt andet risici som instruktionsinjektion, følsom informationsafsløring, utilstrækkelig outputhåndtering, for stort handlemandat, misinformation og ubegrænset forbrug i LLM- og generative AI-applikationer.
Planen bør derfor angive grænser for, hvad AI-systemet må gøre uden menneskelig kontrol. Et system, der kun svarer på spørgsmål, har én risikoprofil. Et agentisk system, der kan søge i dokumenter, kalde API’er, oprette tickets, sende e-mails eller ændre poster, har en højere risikoprofil, fordi fejl kan få direkte effekt i andre systemer.
Praktiske nødgreb kan være at slå værktøjskald fra, begrænse adgang til bestemte datakilder, deaktivere en agentrolle, skifte til en mindre autonom version, sætte manuel godkendelse på alle eksterne handlinger eller midlertidigt erstatte AI-svar med standardsvar. Emnet ligger tæt på bredere sikkerhedsudfordringer ved generativ AI, men beredskabsplanen skal gøre handlingerne operationelle.
Hvordan kan planen kobles til risikostyring og governance?
AI-beredskab bør ikke ligge som et isoleret dokument. Det bør kobles til risikoregister, leverandørstyring, dataklassifikation, adgangsstyring, test, ændringsstyring og løbende monitorering. NIST AI RMF bruger funktionerne Govern, Map, Measure og Manage til at strukturere arbejdet med AI-risici. En beredskabsplan hører især hjemme i overgangen fra kortlagt risiko til konkret håndtering.
Det betyder, at hvert væsentligt AI-system bør have en kendt risikoprofil. Profilen beskriver formål, brugergruppe, data, integrationspunkter, mulige skader, kontrolniveau, testkrav og exitmuligheder. Når systemet ændres, bør beredskabsplanen opdateres sammen med risikovurderingen.
ISO/IEC 42001 bruger en management system-tilgang til AI, hvor politikker, mål, roller, processer og løbende forbedring hænger sammen. For en organisation kan beredskabsplanen være det sted, hvor risikostyring i AI-implementeringer bliver omsat til konkrete stop-, eskalations- og genopretningshandlinger.
Hvilke nødgreb skal være klar før en hændelse?
Nødgreb skal kunne bruges hurtigt og kontrolleret. Hvis de først skal designes under en hændelse, bliver reaktionen langsom og usikker. Beredskabsplanen bør derfor beskrive konkrete handlinger, der kan sænke risikoen uden at skabe større skade for drift, brugere eller data.
- Stop eller begræns AI-funktionen for bestemte brugere, datatyper, opgaver eller integrationer.
- Skift til manuel behandling, et tidligere godkendt workflow eller en enklere regelbaseret proces.
- Frys modelversion, konfiguration, datakilde eller leverandørændring, indtil årsagen er undersøgt.
- Tilbagekald eller marker output, som kan være forkert, følsomt eller misvisende.
- Indfør midlertidig menneskelig godkendelse for handlinger med økonomisk, juridisk, sikkerhedsmæssig eller personlig konsekvens.
- Aktiver kommunikation til berørte brugere, kunder, medarbejdere, leverandører eller myndigheder, hvis hændelsen kræver det.
Et nødgreb bør have ejer, teknisk vej, beslutningskriterier og testet effekt. Hvis en AI-chatbot for eksempel trækker på interne dokumenter, skal organisationen på forhånd vide, om den kan afbryde bestemte datakilder uden at lukke hele tjenesten.
Hvad betyder EU AI Act for beredskabet?
EU AI Act gør AI-beredskab mere relevant for organisationer, der udvikler, leverer eller bruger systemer med højere risiko. Forordningen har trinvise anvendelsesdatoer: nogle regler har været anvendt siden 2025, forordningen anvendes generelt fra 2. august 2026, og enkelte bestemmelser har senere datoer. Den konkrete betydning afhænger af systemets rolle, risikokategori og anvendelse.
For højrisiko-AI-systemer stiller forordningen krav om blandt andet risikostyring, teknisk dokumentation, logning, menneskeligt tilsyn, post-market monitoring og rapportering af alvorlige hændelser, når reglerne gælder for det konkrete system. Artikel 73 beskriver rapportering af serious incidents, og artikel 3 definerer blandt andet alvorlig skade på helbred, kritisk infrastruktur, grundlæggende rettigheder, ejendom eller miljø.
En beredskabsplan bør derfor ikke love compliance alene. Den bør sikre, at organisationen kan identificere, dokumentere og eskalere hændelser hurtigt nok til, at relevante forpligtelser kan vurderes. For organisationer i Danmark kan det betyde tæt kobling mellem AI-ejer, databeskyttelse, informationssikkerhed, juridisk funktion og eventuelle sektorregler.
Hvordan testes og vedligeholdes planen?
En AI-beredskabsplan bliver forældet, hvis den ikke testes. Modeller opdateres, leverandører ændrer funktioner, datakilder flyttes, brugere finder nye arbejdsmåder, og organisationens risikotolerance kan ændre sig. Testen skal derfor både handle om teknisk funktion og menneskelig reaktion.
En enkel øvelse kan starte med et realistisk scenarie: en kundevendt AI giver fejlagtige svar med fortrolige oplysninger, en agent sender e-mails uden godkendelse, et rekrutteringsværktøj prioriterer skævt, eller en modelopdatering ændrer outputkvalitet. Teamet gennemgår derefter opdagelse, stop, logbevaring, vurdering, intern eskalation, ekstern kommunikation, genopretning og beslutning om genåbning.
Planen bør opdateres efter større modelskift, nye integrationer, nye datakilder, nye brugergrupper, ændrede leverandørvilkår, interne hændelser og relevante myndigheds- eller standardkrav. Det er bedre med en kort plan, der faktisk testes, end en omfattende plan, som ingen kan bruge under tidspres.
Hvordan kan en enkel plan se ud i praksis?
En praktisk AI-beredskabsplan kan være bygget op omkring få sider og et bilag pr. kritisk AI-system. Hovedplanen beskriver fælles principper, roller, hændelsestyper og eskalation. Bilaget beskriver det enkelte systems formål, data, model, leverandør, integrationer, kontaktpersoner, nødgreb og kontrolpunkter.
| Del | Spørgsmål planen skal besvare | Praktisk output |
|---|---|---|
| Systemoversigt | Hvilke AI-systemer er kritiske, og hvad bruges de til? | Register med ejer, formål, datatyper, model og integrationer |
| Hændelsesniveauer | Hvornår er en fejl lav, middel, høj eller kritisk? | Kriterier for eskalation, stop og kommunikation |
| Nødgreb | Hvordan begrænses skade hurtigt? | Testede handlinger for afkobling, manuel proces og adgangsbegrænsning |
| Dokumentation | Hvilke spor skal sikres, og hvem må se dem? | Logliste, adgangsregler, tidslinje og beslutningsjournal |
Den enkle plan bør også beskrive, hvornår brugere skal informeres om fejl, og hvornår output skal korrigeres. Hvis et AI-system har givet fejlagtige instruktioner, ufuldstændige svar eller skæve anbefalinger, er genopretning ikke kun teknisk. Den kan også kræve rettelse af beslutninger, notifikation til berørte personer og ændret kontrolniveau fremover.
Hvilke kilder ligger til grund?
Artiklen bygger især på NIST AI Risk Management Framework, NISTs Generative AI Profile, EU AI Act, OWASP Top 10 for LLM Applications 2025 og ISO/IEC 42001:2023.