ms-ai-architect/skills/ms-ai-infrastructure/references/bcdr/rto-rpo-planning-ai-services.md

RTO and RPO Planning for AI Services

Last updated: 2026-06-24 Status: GA Category: Business Continuity & Disaster Recovery Type: reference Source: https://learn.microsoft.com/azure/reliability/concept-business-continuity-high-availability-disaster-recovery

---

Innhold

• Introduksjon
• Business Impact Analysis for RTO-bestemmelse
• Datatap-toleranse og RPO-beregning
• Mapping av krav til Azure-kapabiliteter
• Norske regulatoriske krav
• Dokumentasjons-maler og governance
• Referanser
• For arkitekten

Introduksjon

Recovery Time Objective (RTO) og Recovery Point Objective (RPO) er de to mest kritiske metrikkene i enhver BCDR-strategi for AI-systemer. RTO definerer hvor raskt et system må gjenopprettes etter en forstyrrelse, mens RPO definerer hvor mye datatap som er akseptabelt. For AI-tjenester som Azure OpenAI, Azure AI Search og Azure Machine Learning er disse metrikkene spesielt viktige fordi nedetid direkte påvirker brukeropplevelsen og forretningsbeslutninger.

I norsk offentlig sektor er kravene til tilgjengelighet regulert gjennom flere rammeverk, inkludert Utredningsinstruksen, NSMs grunnprinsipper for IKT-sikkerhet og Digitaliseringsdirektoratets arkitekturprinsipper. Organisasjoner må dokumentere RTO og RPO for alle kritiske systemer som del av sin sikkerhetsstyring og internkontroll.

For AI-løsninger bringer disse kravene unike utfordringer: modelldata, treningsdata, embedding-indekser og konfigurasjoner må alle vurderes separat i en Business Impact Analysis (BIA). En chatbot med RAG-arkitektur har for eksempel separate RPO-krav for selve language model-endpointet, search-indeksen og kunnskapsdokumentene.

Business Impact Analysis for RTO-bestemmelse

En Business Impact Analysis (BIA) er det første steget i å definere RTO for AI-systemer. BIA kartlegger forretningspåvirkningen av nedetid for hvert AI-komponent.

Kritikalitetstier for AI-systemer

Tier	Beskrivelse	RTO-mål	RPO-mål	Eksempel AI-bruk
Tier 0 — Mission Critical	Nedetid er uakseptabelt	< 1 min	0	Sanntids sikkerhetsovervåking med AI
Tier 1 — Business Critical	Kort nedetid tolererbar	< 15 min	< 5 min	Kundeservicebot i produksjon
Tier 2 — Business Operational	Timer akseptabelt	< 4 timer	< 1 time	Intern rapporteringsplattform med AI
Tier 3 — Administrative	Lengre nedetid OK	< 24 timer	< 24 timer	Trenings- og sandbox-miljøer

BIA-prosess for AI-komponenter

1. Identifiser alle AI-avhengigheter: Kartlegg komponentene i AI-løsningen (modell-endpoints, search-indekser, data-pipelines, embedding-stores)
2. Vurder forretningspåvirkning per komponent: Hva skjer hvis Azure OpenAI-endpointet er nede? Hva om AI Search-indeksen er korrupt?
3. Kvantifiser finansiell påvirkning: Beregn kostnad per time med nedetid
4. Kartlegg avhengigheter: Hvilke systemer avhenger av AI-komponentene?
5. Definer akseptabel degradering: Kan systemet tilby begrenset funksjonalitet uten AI?

BIA-mal for AI-tjenester

## Business Impact Analysis — [Tjenestenavn]

### Tjenestebeskrivelse
- **Funksjon:** [Hva gjør AI-tjenesten?]
- **Brukere:** [Antall brukere/systemer som avhenger av tjenesten]
- **Driftstid:** [Forventet tilgjengelighet, f.eks. 24/7 eller kontortid]

### Påvirkningsvurdering
| Nedetid | Finansiell påvirkning | Omdømmepåvirkning | Regulatorisk risiko |
|---------|----------------------|--------------------|--------------------|
| 0–1 time | [Lav/Middels/Høy] | [Lav/Middels/Høy] | [Lav/Middels/Høy] |
| 1–4 timer | [...] | [...] | [...] |
| 4–24 timer | [...] | [...] | [...] |
| > 24 timer | [...] | [...] | [...] |

### Konklusjon
- **Kritikalitetstier:** [0/1/2/3]
- **RTO-krav:** [X minutter/timer]
- **RPO-krav:** [X minutter/timer]

Datatap-toleranse og RPO-beregning

RPO for AI-systemer krever spesiell oppmerksomhet fordi data har forskjellig verdi og regenereringstid.

RPO-kategorier for AI-data

Datatype	Typisk RPO	Regenereringstid	Beskyttelsesmekanisme
Treningsdata (datasett)	24 timer	Dager til uker	Azure Blob Storage GRS/GZRS
Finjusterte modeller	24 timer	Timer til dager	Model registry backup
Search-indekser (embeddings)	1–4 timer	Timer	Dual-region indexing
Brukerdata/konversasjoner	0–15 min	Ikke regenererbar	Cosmos DB multi-region writes
Konfigurasjoner og prompts	0	Minutter via IaC	Git + IaC deployment
Fine-tuning jobb-tilstand	4–24 timer	Timer	Checkpoint-basert backup

Beregningsmodell for RPO

RPO beregnes basert på tre faktorer:

1. Data change rate: Hvor ofte endres dataene?
2. Replication lag: Hva er forsinkelsen mellom primær og sekundær region?
3. Backup frequency: Hvor ofte tas backup?

Effektiv RPO = max(Replication Lag, Backup Interval)

For Azure Storage med Geo Priority Replication er RPO for blobs garantert <= 15 minutter (99.0% av faktureringsperioden).

Azure-tjenester og deres innebygde RPO

Azure-tjeneste	Innebygd RPO	Konfigurasjon	Merknad
Azure OpenAI	Ingen innebygd DR	Manuell multi-region	Stateless — redeploy i ny region
Azure AI Search	Ingen innebygd repl.	Manuell multi-region	Rebuild indeks fra kilde
Azure Cosmos DB	~0 (multi-region writes)	Konfigurerbar	Automatisk geo-replikering
Azure Blob Storage (GRS)	~15 min	Aktivér GRS/GZRS	Async replikering
Azure Blob Storage (GPR)	<= 15 min SLA	Aktivér Geo Priority Repl.	SLA-backed RPO
Azure SQL Database	~5 sek (geo-repl.)	Active geo-replication	Async replikering
Azure Machine Learning	Ingen innebygd DR	Manuell multi-region	Separat storage per region

Mapping av krav til Azure-kapabiliteter

Recovery-konfigurasjoner

Konfigurasjonstype	RTO	RPO	Kostnad	Egnet for
Active-Active	~0	~0	Høyest	Tier 0: Mission Critical
Active-Passive (Warm)	Minutter	Minutter	Middels-Høy	Tier 1: Business Critical
Active-Passive (Cold)	Timer	Timer	Middels	Tier 2: Business Operational
Backup & Restore	Timer–Dager	Timer–Dager	Lavest	Tier 3: Administrative

Azure OpenAI BCDR-konfigurasjon

# Eksempel: Multi-region Azure OpenAI med failover via Azure API Management
import openai
from azure.identity import DefaultAzureCredential

# Primær region
primary_client = openai.AzureOpenAI(
    azure_endpoint="https://aoai-primary-norwayeast.openai.azure.com/",
    api_version="2024-10-21",
    azure_deployment="gpt-4o"
)

# Sekundær region (warm standby)
secondary_client = openai.AzureOpenAI(
    azure_endpoint="https://aoai-secondary-swedencentral.openai.azure.com/",
    api_version="2024-10-21",
    azure_deployment="gpt-4o"
)

def call_with_failover(messages, max_retries=3):
    """Call Azure OpenAI with automatic failover to secondary region."""
    try:
        response = primary_client.chat.completions.create(
            model="gpt-4o",
            messages=messages,
            timeout=30
        )
        return response
    except Exception as e:
        print(f"Primary region failed: {e}")
        # Failover to secondary
        response = secondary_client.chat.completions.create(
            model="gpt-4o",
            messages=messages,
            timeout=30
        )
        return response

Azure AI Search multi-region oppsett

# Deploy identisk search-tjeneste i to regioner
az search service create \
  --name "search-primary-norwayeast" \
  --resource-group "rg-ai-prod" \
  --location "norwayeast" \
  --sku "standard" \
  --replica-count 3 \
  --partition-count 2

az search service create \
  --name "search-secondary-swedencentral" \
  --resource-group "rg-ai-dr" \
  --location "swedencentral" \
  --sku "standard" \
  --replica-count 2 \
  --partition-count 2

# Bruk Azure Traffic Manager for routing
az network traffic-manager profile create \
  --name "tm-search-failover" \
  --resource-group "rg-networking" \
  --routing-method Priority \
  --unique-dns-name "ai-search-global"

Norske regulatoriske krav

Forvaltningsloven og Utredningsinstruksen

Norske offentlige organisasjoner må dokumentere:

• Konsekvensanalyse: Vurdering av konsekvenser ved bortfall av AI-tjenester
• Alternativanalyse: Evaluering av ulike BCDR-strategier med kost/nytte
• Risiko- og sårbarhetsanalyse (ROS): Identifisering av trusler mot AI-systemers tilgjengelighet

NSMs grunnprinsipper

NSM (Nasjonal sikkerhetsmyndighet) krever:

• Klassifisering av systemer etter kritikalitet
• Dokumenterte gjenopprettingsplaner
• Regelmessig testing av beredskapsplaner
• Loggføring og rapportering av hendelser

Data Residency-krav

Krav	Beskrivelse	Påvirkning på BCDR
Schrems II	Data kan ikke overføres til usikre tredjeland	Begrens DR-regioner til EU/EØS
GDPR Art. 32	Tilstrekkelig sikkerhetsnivå inkl. tilgjengelighet	Dokumentér RTO/RPO i DPIA
Forvaltningsloven §13	Taushetsplikt	Kryptering i alle DR-regioner

Dokumentasjons-maler og governance

RTO/RPO-dokumentasjonsmal

# RTO/RPO Dokumentasjon — [Systemnavn]

## Versjon og godkjenning
- **Versjon:** [X.Y]
- **Sist oppdatert:** [Dato]
- **Godkjent av:** [Navn og rolle]
- **Neste revisjon:** [Dato]

## Systembeskrivelse
[Kort beskrivelse av AI-systemet og dets forretningsfunksjon]

## Komponentoversikt med RTO/RPO

| Komponent | Kritikalitet | RTO | RPO | DR-strategi | Ansvarlig |
|-----------|-------------|-----|-----|-------------|-----------|
| Azure OpenAI Endpoint | Høy | 15 min | N/A | Multi-region | Platform team |
| AI Search Index | Høy | 1 time | 4 timer | Dual indexing | Data team |
| Cosmos DB (state) | Kritisk | 0 | 0 | Multi-region writes | Platform team |
| Blob Storage (docs) | Middels | 4 timer | 15 min | GRS | Ops team |

## Testplan
- **Frekvens:** Kvartalsvis
- **Type:** Failover drill + tabletop
- **Suksesskriterier:** [Definer]

## Hendelsesklassifisering
[Ref. til incident response plan]

Governance-prosess

1. Årlig BIA-revisjon: Oppdater kritikalitetsvurderinger
2. Kvartalsvis testing: Verifiser at RTO/RPO-mål oppnås
3. Hendelsesdrevet oppdatering: Revider etter reelle hendelser
4. Endringsbasert vurdering: Nye AI-komponenter trigger ny BIA

Referanser

• Business continuity and disaster recovery overview — Grunnleggende BCDR-konsepter og definisjoner
• Develop a disaster recovery plan for multi-region deployments — WAF-veiledning for DR-planlegging
• Recommendations for defining reliability targets — SLO, RTO og RPO-definisjoner
• BCDR considerations with Azure OpenAI — Azure OpenAI-spesifikk BCDR
• Azure Storage redundancy — GRS, GZRS og replikeringsalternativer
• Azure Storage Geo Priority Replication — SLA-backed RPO for blobs
• Reliability in Azure AI Search — Tilgjengelighet og DR for AI Search

For arkitekten

• Bruk denne referansen når kunden trenger hjelp med å definere RTO og RPO for sine AI-systemer, eller når de planlegger BCDR-strategi.
• Start alltid med en Business Impact Analysis (BIA) før du foreslår tekniske løsninger — RTO/RPO er forretningsbeslutninger, ikke tekniske.
• Utfordre kunder som sier "alt er kritisk" — differensiert kritikalitet er nøkkelen til kostnadseffektiv BCDR.
• For norsk offentlig sektor: Påpek at DPIA (Data Protection Impact Assessment) bør inkludere tilgjengelighetsvurdering med RTO/RPO.
• Husk at Azure OpenAI er stateless — RTO handler om redeployment og DNS-oppdatering, ikke om datavederlag.