Ordre 20260912T193441Z-7358817909. Steg 1 var ikke transformen, men å rette
roadmapens R13-gate og få den ratifisert. Gaten `grep -rl "Cosmo"
skills/*/references -> 0` var usann på to uavhengige måter:
1. Ordren fanget den første: 451 av forekomstene er Azure Cosmos DB, ekte
produktinnhold. Diskriminatoren er ikke bokstaven «s» — `Cosmos <norsk
substantiv>` er genitiv av personaen (`### Cosmos tonalitet`), mens
`Cosmos DB`/`CosmosClient`/`cosmos_ru` er produkt.
2. Denne økten fant den andre: 132 persona-forekomster ligger i prosa,
tabeller, dialog-replikker og proveniens-linjer. Heading-nøytralisering
kan ikke nå dem, så «0 persona» er uoppnåelig også under den ratifiserte
formen. Operatøren ratifiserte alternativ A: gaten speiler formen, og de
132 bokføres til R13b/R14.
Tre korreksjoner av premisser som sto i ordren og STATE:
«ca 320 produkt» -> 451 (case-sensitivt nett manglet 327 lowercase
TOC-ankre + 99 identifikatorer; sann nevner 1 638)
«169 headinger» -> 401. 169 var `^## For Cosmo`-prefikset (168) og var
internt inkonsistent med sin egen topp-variant (204)
«417 matcher ingen
populasjon» -> 417 er cosmo-headinger utenfor kodefences; briefens
nevner var reell hele tiden
Fence-bevissthet er målt skadelig, ikke nødvendig: begge toggle-regler er
gale på dette korpuset (naiv toggle skjuler en ekte heading i
chain-of-thought-prompting.md, CommonMark-regelen ubalanserer
service-level-documentation-dr.md). Fence-agnostisk deteksjon finner 401
heading-linjer i nøyaktig de samme 40 variantene som fence-bevisst finner
400 i — ingen kodeblokk-linje er byte-identisk til en persona-heading. Derfor
nøkles transformen på 40 enumererte heading-tekster og ignorerer fences. En
ukjent variant kaster; en slug-kollisjon kaster. Ingenting auto-fikses.
TOC-en regenereres ikke, den rettes kirurgisk: alle 327 persona-lenker hadde
lenketekst lik én av de 40 heading-tekstene og anker lik slugify av den
(327/327, 0 avvik), så heading og TOC-entry skrives i samme operasjon og
ingen mellomtilstand etterlater en død lenke.
Ratifisert målform: `For Cosmo`, `For Cosmo Skyberg` og `For arkitekten
(Cosmo)` konvergerer på `For arkitekten`. To filer kolliderte og er adjudisert
ved å lese dem, ikke ved regel.
Verifisering (alle 7 kriterier fra ordren):
G1 persona på heading-linjer 401 -> 0
G2 døde fragmentlenker 1 -> 1 (pre-eksisterende, unntatt)
G3 produkt-forekomster 451 -> 451; `Cosmos DB|Azure Cosmos` 308 = 308
de 3 kun-produkt-filene byte-identiske
nettet validert begge veier injisert persona feller G1; genitiv feller G1;
produkt-heading og de 3 filene passerer
hele diffen 802 heading-linjer + 654 TOC-linjer, ANNET = 0
linjeantall 728 lagt til = 728 slettet
suite 1120/1120 (1097 + 23 nye)
validate-plugin 250 PASS / 0 FAIL
stikkprøve 10 filer, alle 5 skills, inkl. de 3 mest
produkt-tunge (26/20/19) — kun heading+TOC
Utenfor scope, urørt: de 4 SKILL.md, de 23 commands, CLAUDE.md, README.md,
NOTICE.md, docs/ (alt R14).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
329 lines
13 KiB
Markdown
329 lines
13 KiB
Markdown
# 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 arkitekten](#for-arkitekten)
|
||
|
||
## 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 (0–5 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 (5–15 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: [Fra–til]
|
||
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 arkitekten
|
||
|
||
- **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.
|