ms-ai-architect/skills/ms-ai-infrastructure/references/bcdr/incident-response-ai-systems.md
Kjell Tore Guttormsen ddce43d8b2 feat(ms-ai-architect): Spor 1 — Port-1-substrat migrert på 4 ikke-advisor-skills (243 Source + 327 Type + 325 TOC + stale-verified poison fjernet) [skip-docs]
Steg 9 (R4): unified migrate-corpus.mjs --write over engineering/governance/
infrastructure/security. 327 filer mutert, verified=null, prosa byte-identisk
(fra første ## seksjon), advisor urørt (0 endringer).

To applier-fixes oppdaget under kjøring (TDD, RED→GREEN):
- insertHeaderFields: anker faller nå tilbake når en meta-linje selv passerer
  500B (2 filer pakket et avsnitt i **Status:** → Type/Source landet utenfor
  scan-vinduet, applierens post-write-assertion fanget + restaurerte).
- normalizeStaleVerified: fjerner nå ALLE stale non-date **Verified:** i
  500B-vinduet, inkl. stray body-dup rett under --- (9 mlops-genaiops-filer var
  ellers falskt "verified"/fresh, droppet fra worklist). Operatør-godkjent
  utvidelse av carve-out; kun stray metadata-linjer, aldri prosa.

test-transform-criterion: precondition oppdatert til post-migrasjons-sannhet
(fila bærer nå Source). Suite 728/728 grønn.
2026-07-04 10:19:11 +02:00

329 lines
13 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Incident Response for AI Systems
**Last updated:** 2026-06-24
**Status:** GA
**Category:** Business Continuity & Disaster Recovery
**Type:** reference
**Source:** https://learn.microsoft.com/azure/azure-monitor/alerts/alerts-overview
---
## Innhold
- [Introduksjon](#introduksjon)
- [AI-spesifikke hendelsesklassifiseringer](#ai-spesifikke-hendelsesklassifiseringer)
- [Deteksjon og alerting-strategier](#deteksjon-og-alerting-strategier)
- [Eskalerings-prosedyrer og runbooks](#eskalerings-prosedyrer-og-runbooks)
- [Kommunikasjonsplaner for interessenter](#kommunikasjonsplaner-for-interessenter)
- [Post-incident review og forbedring](#post-incident-review-og-forbedring)
- [Referanser](#referanser)
- [For Cosmo](#for-cosmo)
## 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
```bash
# 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
```kusto
// 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
```
```kusto
// 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
```
```kusto
// 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
```bash
# 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
```markdown
## 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
```markdown
## 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
```
2. Verifiser at sekundært endpoint responderer
3. Sjekk at applikasjoner bruker ny rute
4. 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
```markdown
# 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
- [Secure AI — Detect AI security threats](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/ai/secure) — CAF AI-sikkerhet
- [AI-6: Establish monitoring and detection](https://learn.microsoft.com/en-us/security/benchmark/azure/mcsb-v2-artificial-intelligence-security) — MCSB AI-overvåking
- [Create an effective incident management plan](https://learn.microsoft.com/en-us/azure/well-architected/design-guides/incident-management) — WAF incident management
- [Microsoft Defender for AI Services](https://learn.microsoft.com/en-us/azure/defender-for-cloud/ai-threat-protection) — AI-spesifikk trusseloppdaging
- [Azure Monitor alerts overview](https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-overview) — Alert-rammeverk
- [Microsoft Sentinel overview](https://learn.microsoft.com/en-us/azure/sentinel/overview) — SIEM/SOAR for sikkerhetshendelser
- [Monitor Azure OpenAI](https://learn.microsoft.com/en-us/azure/foundry-classic/openai/how-to/monitor-openai) — OpenAI-spesifikk monitoring
## 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.