ktg-plugin-marketplace/plugins/ms-ai-architect/skills/ms-ai-infrastructure/references/bcdr/incident-response-ai-systems.md
Kjell Tore Guttormsen 6a7632146e feat(ms-ai-architect): add plugin to open marketplace (v1.5.0 baseline)
Initial addition of ms-ai-architect plugin to the open-source marketplace.
Private content excluded: orchestrator/ (Linear tooling), docs/utredning/
(client investigation), generated test reports and PDF export script.
skill-gen tooling moved from orchestrator/ to scripts/skill-gen/.

Security scan: WARNING (risk 20/100) — no secrets, no injection found.
False positive fixed: added gitleaks:allow to Python variable reference
in output-validation-grounding-verification.md line 109.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-04-07 17:17:17 +02:00

12 KiB
Raw Blame History

Incident Response for AI Systems

Last updated: 2026-02 Status: GA Category: Business Continuity & Disaster Recovery


Introduksjon

Incident response for AI-systemer krever spesialiserte prosedyrer som adresserer unike feilmodi som ikke finnes i tradisjonelle IT-systemer. AI-spesifikke hendelser inkluderer modell-degradering, prompt injection-angrep, hallusinasjonsspikes, embedding-drift, og utilgjengelige inference-endepunkter. Disse hendelsene kan ha subtile symptomer som er vanskelige å oppdage med tradisjonell overvåking.

Azure tilbyr flere verktøy for AI-spesifikk overvåking og hendelseshåndtering: Microsoft Defender for AI Services for trusseloppdaging, Azure Monitor for metrikk og alerting, Microsoft Sentinel for SIEM/SOAR-kapabiliteter, og Application Insights for applikasjonslagsovervåking. Disse verktøyene må konfigureres spesifikt for AI-arbeidsbelastninger.

For norsk offentlig sektor er hendelseshåndtering regulert gjennom NSMs grunnprinsipper, og mange organisasjoner har ITIL-baserte prosesser. AI-hendelser krever utvidelse av eksisterende incident management-prosesser med AI-spesifikke klassifiseringer, eskaleringsregler og kommunikasjonsplaner.

AI-spesifikke hendelsesklassifiseringer

Hendelseskategorier for AI-systemer

Kategori Beskrivelse Eksempler Alvorlighetsgrad
Modellutilgjengelighet Inference-endepunkt svarer ikke Azure OpenAI regional outage, quota exceeded Kritisk
Modelldegraddering Redusert kvalitet på modellresponser Økt hallusinasjonsrate, inkonsistente svar Høy
Datapipeline-feil Indeksering eller dataflyt stoppet Search indexer failed, embedding pipeline stoppet Høy
Sikkerhetsbrudd AI-spesifikke angrep Prompt injection, jailbreak, data exfiltration Kritisk
Ytelsesdegraddering Økt latens eller redusert throughput Token rate limiting, høy p99 latens Middels
Kostnadsanomali Uventet økning i AI-forbruk Token-forbruk spike, uautoriserte API-kall Middels
Datakvalitetsproblem Korrupt eller utdatert data Embedding drift, stale indeks, poison data Høy
Compliance-brudd Brudd på regulatoriske krav PII i modellresponser, uautorisert datatilgang Kritisk

Alvorlighetsnivåer og responstider

Nivå Beskrivelse Responstid Eskalering Eksempel
P0 — Kritisk Total tjenestebortfall eller sikkerhetshendelse < 15 min Umiddelbar til CISO/CTO Regional outage, aktiv data breach
P1 — Høy Betydelig degradering av funksjonalitet < 1 time Til teamlead innen 30 min Modell gir feil svar konsistent
P2 — Middels Delvis degradering, workaround eksisterer < 4 timer Til teamlead innen 2 timer Økt latens på search-spørringer
P3 — Lav Minimal påvirkning Neste virkedag Standard kanal Ikke-kritisk indexer-feil

Deteksjon og alerting-strategier

Microsoft Defender for AI Services

# Aktiver Defender for AI Services
az security pricing create \
  --name "AI" \
  --tier "standard"

# Se aktive sikkerhetsvarsler for AI
az security alert list \
  --query "[?contains(alertType, 'AI')]" \
  --output table

Azure Monitor alerting for AI-metrikker

// KQL: Detect increased error rate for Azure OpenAI
AzureDiagnostics
| where ResourceProvider == "MICROSOFT.COGNITIVESERVICES"
| where Category == "RequestResponse"
| where TimeGenerated > ago(15m)
| summarize
    TotalRequests = count(),
    FailedRequests = countif(resultCode_d >= 400),
    ErrorRate = round(countif(resultCode_d >= 400) * 100.0 / count(), 2)
    by bin(TimeGenerated, 5m)
| where ErrorRate > 5.0
| project TimeGenerated, TotalRequests, FailedRequests, ErrorRate
// KQL: Detect abnormal token consumption (potential abuse)
AzureDiagnostics
| where ResourceProvider == "MICROSOFT.COGNITIVESERVICES"
| where Category == "RequestResponse"
| where TimeGenerated > ago(1h)
| extend
    promptTokens = toint(properties_s.promptTokens),
    completionTokens = toint(properties_s.completionTokens)
| summarize
    TotalTokens = sum(promptTokens + completionTokens),
    AvgTokensPerRequest = avg(promptTokens + completionTokens)
    by bin(TimeGenerated, 5m), callerIpAddress_s
| where TotalTokens > 100000  // Anomali-terskel
// KQL: AI Search indexer failure detection
AzureDiagnostics
| where ResourceProvider == "MICROSOFT.SEARCH"
| where OperationName == "Indexers.Status"
| where resultSignature_d != 200
| project TimeGenerated, resource_s, OperationName, resultSignature_d, resultDescription_s
| order by TimeGenerated desc

Alert-konfigurasjoner

# Azure OpenAI error rate alert
az monitor metrics alert create \
  --name "aoai-error-rate-critical" \
  --resource-group "rg-ai-prod" \
  --scopes "/subscriptions/{sub}/resourceGroups/rg-ai-prod/providers/Microsoft.CognitiveServices/accounts/aoai-prod" \
  --condition "avg ServerErrors > 10" \
  --window-size 5m \
  --evaluation-frequency 1m \
  --severity 0 \
  --action-group "ag-ai-oncall"

# Azure OpenAI latency alert
az monitor metrics alert create \
  --name "aoai-latency-warning" \
  --resource-group "rg-ai-prod" \
  --scopes "/subscriptions/{sub}/resourceGroups/rg-ai-prod/providers/Microsoft.CognitiveServices/accounts/aoai-prod" \
  --condition "avg Latency > 5000" \
  --window-size 5m \
  --evaluation-frequency 1m \
  --severity 2 \
  --action-group "ag-ai-team"

# Token consumption anomaly
az monitor metrics alert create \
  --name "aoai-token-anomaly" \
  --resource-group "rg-ai-prod" \
  --scopes "/subscriptions/{sub}/resourceGroups/rg-ai-prod/providers/Microsoft.CognitiveServices/accounts/aoai-prod" \
  --condition "total ProcessedPromptTokens > 500000" \
  --window-size 1h \
  --evaluation-frequency 15m \
  --severity 2 \
  --action-group "ag-ai-team"

Eskalerings-prosedyrer og runbooks

Eskalerings-matrise

## Eskaleringsmatrise for AI-hendelser

### Nivå 1: AI Platform Team (L1)
- **Ansvar:** Første respons, triage, kjente problemer
- **Verktøy:** Azure Monitor dashboards, Runbook for kjente feil
- **Eskaleringstid:** 15 min (P0), 30 min (P1), 2 timer (P2)

### Nivå 2: AI Engineering Team (L2)
- **Ansvar:** Teknisk feilsøking, workaround-implementering
- **Verktøy:** Log Analytics, Application Insights, Azure CLI
- **Eskaleringstid:** 30 min (P0), 1 time (P1)

### Nivå 3: Architecture/Security Team (L3)
- **Ansvar:** Arkitekturelle beslutninger, sikkerhetsrespons
- **Verktøy:** Microsoft Sentinel, Defender for Cloud
- **Eskaleringstid:** 1 time (P0), involveres alltid for sikkerhet

### Nivå 4: Microsoft Support (L4)
- **Ansvar:** Platform-nivå feil, Azure-tjenestefeil
- **Verktøy:** Azure Support ticket (Severity A for P0)
- **Kontakt:** Azure Support portal, TAM for Enterprise

Runbook: Azure OpenAI Regional Outage

## Runbook: Azure OpenAI Regional Outage

### Trigger
- Azure Service Health alert for Cognitive Services i primær region
- Error rate > 50% vedvarende over 5 minutter
- Alle requests returnerer 5xx

### Umiddelbare handlinger (05 min)
1. Verifiser at det er en regional hendelse (sjekk Azure Status)
2. Aktiver incident i PagerDuty/Opsgenie
3. Send umiddelbar varsling til interessenter

### Failover-prosedyre (515 min)
1. Aktiver failover via Traffic Manager/APIM:
   ```bash
   # Oppdater Traffic Manager priority
   az network traffic-manager endpoint update \
     --resource-group rg-networking \
     --profile-name tm-aoai \
     --name secondary-swedencentral \
     --type azureEndpoints \
     --priority 1
  1. Verifiser at sekundært endpoint responderer
  2. Sjekk at applikasjoner bruker ny rute
  3. Overvåk error rate i sekundær region

Kommunikasjon (løpende)

  1. Oppdater status-side
  2. Varsle forretningsbrukere via Teams/epost
  3. Logg alle handlinger i incident management system

Gjenoppretting

  1. Overvåk Azure Service Health for løsning
  2. Verifiser at primær region fungerer (test med syntetisk trafikk)
  3. Planlegg kontrollert failback i lavtrafikkperiode
  4. Utfør failback og verifiser

## Kommunikasjonsplaner for interessenter

### Kommunikasjonsmal

| Tidspunkt | Mottaker | Kanal | Innhold |
|-----------|---------|-------|---------|
| T+0 min | Ops-team | PagerDuty | Automatisk alert |
| T+5 min | Teamlead | Teams/Slack | Triage-oppsummering |
| T+15 min | Management | Epost | Statusoppdatering med ETA |
| T+30 min | Alle brukere | Statusside | Offentlig statusmelding |
| T+60 min | Ledelse | Epost | Oppdatert ETA, påvirkning |
| Hver time | Alle | Statusside + epost | Løpende oppdatering |
| Etter løsning | Alle | Epost | Hendelse løst, kort oppsummering |
| T+48 timer | Internt | Møte + doc | Post-mortem rapport |

### Statusmeldings-maler

```markdown
## Statusmelding — Mal

### Hendelse oppdaget
[Tidspunkt]: Vi har identifisert et problem med [tjenestenavn].
Påvirkning: [Beskrivelse av påvirkning for brukere]
Status: Vi undersøker og vil gi oppdatering innen [tid].

### Under arbeid
[Tidspunkt]: Vi har identifisert årsaken som [kort beskrivelse].
Tiltak: [Hva gjøres?]
Forventet løsning: [ETA]
Workaround: [Eventuell midlertidig løsning]

### Løst
[Tidspunkt]: Hendelsen er løst. [Tjenestenavn] fungerer normalt.
Varighet: [Fratil]
Rotårsak: [Kort beskrivelse]
Tiltak: [Hva gjøres for å forhindre gjentakelse]

Post-incident review og forbedring

Post-mortem prosess

  1. Samle data (innen 24 timer):

    • Tidslinje med alle handlinger
    • Alle relevante logger og metrikker
    • Kommunikasjonslogg
  2. Gjennomfør blameless post-mortem (innen 5 virkedager):

    • Tidslinje-gjennomgang
    • Rotårsaksanalyse (5 Whys eller Fishbone)
    • Identifiser forbedringstiltak
    • Definer action items med eiere og tidsfrister
  3. Dokumenter og distribuer (innen 7 virkedager):

    • Post-mortem rapport
    • Oppdaterte runbooks
    • Nye/justerte alerts
    • Lessons learned

Post-mortem mal

# Post-Mortem Report — [Hendelsesnavn]

## Oppsummering
- **Dato:** [Dato]
- **Varighet:** [Timer:Minutter]
- **Alvorlighetsgrad:** [P0/P1/P2/P3]
- **Påvirkede tjenester:** [Liste]
- **Påvirkede brukere:** [Antall/beskrivelse]

## Tidslinje
| Tidspunkt | Hendelse | Aksjon |
|-----------|---------|--------|
| HH:MM | [Hva skjedde] | [Hva ble gjort] |

## Rotårsak
[Detaljert beskrivelse av rotårsak]

## Hva gikk bra
- [Punkt 1]
- [Punkt 2]

## Hva kan forbedres
- [Punkt 1]
- [Punkt 2]

## Action Items
| # | Beskrivelse | Eier | Frist | Status |
|---|-------------|------|-------|--------|
| 1 | [Tiltak] | [Navn] | [Dato] | Open |

Referanser

For Cosmo

  • Bruk denne referansen når kunden etablerer eller forbedrer sine incident response-prosedyrer for AI-systemer.
  • AI-hendelser krever utvidelse av eksisterende ITIL/incident-prosesser — ikke separate prosesser, men tilpassede kategorier og runbooks.
  • Anbefal alltid blameless post-mortems — fokuser på systemer og prosesser, ikke personer.
  • For norsk offentlig sektor: Hendelseshåndtering bør integreres med NSMs rapporteringskrav og organisasjonens ROS-analyse.
  • Kritisk: Sørg for at AI-teamet har direkte eskaleringsmulighet til Microsoft Support med Severity A for produksjonskritiske hendelser.