ms-ai-architect/skills/ms-ai-advisor/references/prompt-engineering/error-handling-and-fallback-prompting.md

# Error Handling and Fallback Prompting Strategies

**Last updated:** 2026-06-19 | Verified: MCP 2026-06-19
**Status:** GA
**Category:** Prompt Engineering & LLM Optimization

---

## Introduksjon

Error handling og fallback-strategier er kritiske komponenter i produksjonsklare LLM-applikasjoner. Når AI-modeller møter feil, uventede tilstander eller usikkerhet i responsene sine, kan robuste error handling-mekanismer sikre at applikasjonen fortsetter å levere verdi selv under degraderte forhold.

Denne kunnskapsreferansen dekker arkitekturmønstre for å håndtere feil fra Azure OpenAI, strategier for graceful degradation, retry-logikk og fallback prompting-teknikker som sikrer applikasjonen din forblir pålitelig i møte med usikkerhet og tekniske feil.

**Nøkkelscenarier:**
- Håndtering av 429 Rate Limit og 5xx-feil fra Azure OpenAI
- Retry-logikk med exponential backoff
- Fallback-prompts når modellen returnerer usikre eller ufullstendige svar
- Graceful degradation når AI-komponenter feiler
- Load balancing mellom flere Azure OpenAI-endepunkter

**Confidence:** Høy – basert på offisiell Microsoft-dokumentasjon og etablerte mønstre fra Azure Well-Architected Framework.

---

## Kjernekomponenter / Nøkkelegenskaper

### 1. HTTP Error Codes og Betydning

Azure OpenAI returnerer standard HTTP-statuskoder som indikerer ulike feiltyper:

| Status Code | Error Type | Betydning | Retry? |
|-------------|------------|-----------|--------|
| 400 | Bad Request Error | Ugyldig request (feil format, content filter treff) | Nei |
| 401 | Authentication Error | Autentiseringsfeil | Nei |
| 403 | Permission Denied Error | Manglende tilgang | Nei |
| 404 | Not Found Error | Ressurs ikke funnet | Nei |
| 408 | Request Timeout | Timeout i request | Ja |
| 422 | Unprocessable Entity Error | Ugyldige data | Nei |
| 429 | Rate Limit Error | Quotagrense nådd (TPM/RPM) | Ja |
| 500 | Internal Server Error | Serverfeil | Ja |
| 502 | Bad Gateway | Gateway-feil | Ja |
| 503 | Service Unavailable | Tjeneste utilgjengelig | Ja |
| 504 | Gateway Timeout | Gateway timeout | Ja |

**Viktig:** 400-feil pga. content filtering genererer kostnader selv om requesten ikke fullføres. Implementer pre-filtering for å unngå unødvendige kostnader.

### 2. Retry-Mekanismer i Offisielle SDKer

Alle offisielle Azure OpenAI SDK-er har innebygd retry-logikk:

**Python (openai-python):**
```python
from openai import OpenAI

# Global retry-config
client = OpenAI(
    base_url="https://RESOURCE.openai.azure.com/openai/v1/",
    api_key="YOUR_KEY",
    max_retries=5  # Default: 2
)

# Per-request override
client.with_options(max_retries=3).chat.completions.create(
    messages=[{"role": "user", "content": "Query"}],
    model="gpt-4o"
)
```

**TypeScript/JavaScript (openai-node):**
```typescript
import { OpenAI } from "openai";

const client = new OpenAI({
    baseURL: "https://RESOURCE.openai.azure.com/openai/v1/",
    apiKey: process.env.OPENAI_API_KEY,
    maxRetries: 5  // Default: 2
});

// Per-request override
await client.chat.completions.create(
    { messages: [...], model: "gpt-4o" },
    { maxRetries: 3 }
);
```

**.NET (openai-dotnet):**
```csharp
// Automatisk retry (opp til 3 ganger) for:
// - 408 Request Timeout
// - 429 Too Many Requests
// - 500, 502, 503, 504 Server Errors
// Ingen manuell konfigurasjon nødvendig
```

**Automatisk retry gjelder for:**
- 408 Request Timeout
- 429 Rate Limit
- ≥500 Internal Server Errors

**Exponential backoff:** SDK-ene bruker exponential backoff med jitter for å unngå thundering herd-problemer.

### 3. Retry-After Header

Azure OpenAI inkluderer `Retry-After` HTTP-header ved 429-feil, som indikerer hvor lenge (i sekunder) klienten bør vente før neste forsøk.

**Beste praksis:**
- Respekter alltid `Retry-After` header
- Bruk denne som minimum ventetid før retry
- Kombiner med exponential backoff for robusthet

### 4. Fallback Prompting-Strategier

Når modellen returnerer usikre, ufullstendige eller uventede svar, kan fallback-prompting hjelpe:

**Strategi 1: Forenklet prompt**
```python
primary_prompt = "Analyze this contract and extract all clauses related to liability, indemnification, and force majeure."

fallback_prompt = "List the main topics in this contract."
```

**Strategi 2: Lavere temperature**
```python
# Primær forsøk
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": query}],
    temperature=1.0
)

# Fallback: reduser temperature for mer deterministisk output
if not is_valid_response(response):
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": query}],
        temperature=0.3
    )
```

**Strategi 3: Fallback til enklere modell**
```python
models = ["gpt-4o", "gpt-4o-mini", "gpt-35-turbo"]

for model in models:
    try:
        response = client.chat.completions.create(
            model=model,
            messages=[{"role": "user", "content": query}]
        )
        if is_valid_response(response):
            break
    except Exception:
        continue
```

**Strategi 4: Chunking ved token limit-feil**
```python
try:
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": large_document}]
    )
except openai.BadRequestError as e:
    if "maximum context length" in str(e):
        # Split dokument i chunks og prosesser hver del
        chunks = split_document(large_document, chunk_size=2000)
        results = [process_chunk(chunk) for chunk in chunks]
        response = aggregate_results(results)
```

### 5. Content Safety og Output Handling

Azure AI Content Safety kan filtrere både input-prompts og LLM-output. Insecure output handling er en av OWASP Top 10 for LLM-risikoer.

**Anbefalinger:**
- Valider og sanitize alle LLM-output før bruk i downstream-systemer
- Bruk Azure AI Content Safety for filtrering
- Encode output før presentasjon (unngå XSS, code injection)
- Implementer zero-trust: behandle LLM som usikkert eksternt system

---

## Arkitekturmønstre

### 1. Smart Load Balancing med Priority-Based Failover

For production-workloads anbefales det å distribuere trafikk over flere Azure OpenAI-instanser basert på prioritet og tilgjengelighet.

**Mønster:**
```
Priority 1: PTU (Provisioned Throughput) – forhåndsbetalt kapasitet
Priority 2: S0 (Pay-as-you-go) i primærregion
Priority 3: S0 i sekundærregioner
```

**Implementering med Azure Container Apps / API Management:**
- Overvåk `Retry-After` header fra Azure OpenAI
- Marker throttlede endepunkter som "unhealthy" i perioden angitt av `Retry-After`
- Route trafikk til neste prioritet mens høyeste prioritet er throttlet
- **Ingen ventetid** mellom failover-forsøk på server-side (immediate failover)

**Referanse:** [Azure OpenAI Priority-Based Load Balancer (GitHub)](https://github.com/Azure-Samples/openai-aca-lb)

### 2. Graceful Degradation Mode

Basert på Azure Well-Architected Framework reliability-anbefalinger:

**Design-prinsipper:**
1. **Failure detection og automated initiation:** Monitoring-systemer detekterer degraderte komponenter og aktiverer automatisk graceful degradation-modus.
2. **Degradert brukeropplevelse:** Notifiser brukere om redusert funksjonalitet (f.eks. "AI-anbefalinger midlertidig utilgjengelig").
3. **Alternative paths:** Oppretthold kritiske flows selv når AI-komponenter feiler:
   - Cached responses for vanlige queries
   - Fallback til regelbasert logikk
   - Read-only mode med tidligere genererte data

**Eksempel:**
```python
def get_ai_recommendation(user_query):
    try:
        response = openai_client.chat.completions.create(...)
        return response.choices[0].message.content
    except openai.RateLimitError:
        # Fallback: hent fra cache eller returner standard-anbefaling
        return get_cached_recommendation(user_query)
    except openai.APIError:
        # Graceful degradation: informer bruker
        return {
            "status": "degraded",
            "message": "AI-tjeneste midlertidig utilgjengelig. Prøv igjen om noen minutter."
        }
```

### 3. Circuit Breaker Pattern

Forhindrer at applikasjonen kontinuerlig prøver å nå en failende tjeneste.

**States:**
- **Closed:** Normal drift, requests går til Azure OpenAI
- **Open:** Tjeneste ansett som failende, requests blokkeres umiddelbart
- **Half-Open:** Test om tjeneste er tilbake, tillat begrenset trafikk

**Implementering:**
```python
from pybreaker import CircuitBreaker

breaker = CircuitBreaker(fail_max=5, timeout_duration=60)

@breaker
def call_openai(prompt):
    return client.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": prompt}]
    )

try:
    response = call_openai("User query")
except CircuitBreakerError:
    # Fallback: bruk cached response eller default
    response = get_fallback_response()
```

### 4. Bulkhead Pattern

Isolerer feil ved å partisjonere tjeneste-instanser i separate pools. Hvis én pool feiler, påvirkes ikke andre pools.

**Eksempel:**
- Pool A: AI-generert content for marketing
- Pool B: AI-generert content for kundesupport
- Pool C: AI-analyse for rapporter

Hvis Pool A throttles, fortsetter Pool B og C å fungere normalt.

### 5. Checkpoint Pattern for Long-Running Operations

For langvarige LLM-operasjoner (f.eks. batch-prosessering av dokumenter):

**Implementering:**
```python
def process_documents_with_checkpoints(documents, checkpoint_file):
    checkpoint = load_checkpoint(checkpoint_file)
    start_index = checkpoint.get("last_processed_index", 0)

    for i, doc in enumerate(documents[start_index:]):
        try:
            result = process_with_llm(doc)
            save_result(result)

            # Lagre checkpoint hvert 10. dokument
            if (i + start_index) % 10 == 0:
                save_checkpoint(checkpoint_file, {"last_processed_index": i + start_index})
        except Exception as e:
            log_error(e)
            save_checkpoint(checkpoint_file, {"last_processed_index": i + start_index})
            raise
```

---

## Beslutningsveiledning

### Når skal du bruke hvilken strategi?

| Scenario | Anbefalt Strategi | Alternativ |
|----------|-------------------|------------|
| 429 Rate Limit | Respect `Retry-After`, exponential backoff, load balancing | Circuit breaker + fallback |
| 500-feil (transient) | Automatisk retry med SDK (2-3 forsøk) | Circuit breaker |
| Content filter block (400) | Pre-filter input med Azure AI Content Safety | Fallback til regelbasert output |
| Usikre/ufullstendige svar | Lavere temperature, forenklet prompt | Fallback til enklere modell |
| Token limit overskredet | Chunking + aggregering | Oppsummer input før sending |
| Persistent service unavailable | Graceful degradation + cached responses | Fallback til regelbasert logikk |
| Multi-tenant med ulik prioritet | Priority-based load balancing | Bulkhead pattern |
| Long-running batch jobs | Checkpoint pattern | Background jobs med queue |

### Sikkerhets- og Compliance-Hensyn

**Offentlig sektor (Norge):**
- **Logging:** Logg alle feil, men IKKE logg personopplysninger i error messages
- **Retry-limits:** Begrens antall retries for å unngå unødvendig kostnad og ressursbruk
- **Fallback-data:** Sikre at fallback-responses ikke eksponerer sensitiv informasjon
- **Content Safety:** Alltid bruk Azure AI Content Safety for både input og output i offentlige tjenester

---

## Integrasjon med Microsoft-stakken

### Azure OpenAI + Azure AI Content Safety

**Pre-filtering av input:**
```python
from azure.ai.contentsafety import ContentSafetyClient
from azure.core.credentials import AzureKeyCredential

content_safety_client = ContentSafetyClient(
    endpoint="https://YOUR-RESOURCE.cognitiveservices.azure.com",
    credential=AzureKeyCredential("YOUR_KEY")
)

def safe_openai_call(user_input):
    # Pre-filter input
    analysis = content_safety_client.analyze_text(text=user_input)
    if analysis.hate_result.severity > 2:
        return {"error": "Input blocked by content filter"}

    # Call OpenAI
    response = openai_client.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": user_input}]
    )

    # Post-filter output
    output_text = response.choices[0].message.content
    output_analysis = content_safety_client.analyze_text(text=output_text)
    if output_analysis.violence_result.severity > 2:
        return {"error": "Output blocked by content filter"}

    return {"response": output_text}
```

### Azure API Management (APIM) med llm-content-safety Policy

APIM kan enforces content safety checks automatisk:

```xml
<policies>
    <inbound>
        <llm-content-safety backend-id="content-safety-backend" shield-prompt="true">
            <categories output-type="EightSeverityLevels">
                <category name="Hate" threshold="4" />
                <category name="Violence" threshold="4" />
            </categories>
        </llm-content-safety>
    </inbound>
</policies>
```

**Policy-attributter (Verified MCP 2026-06-19):**
- `backend-id`: Azure AI Content Safety backend i APIM
- `shield-prompt`: Sjekk for brukerangrep/adversarial prompts (true/false)
- `enforce-on-completions`: Aktiver content safety på responser i tillegg til requests
- `window-size`: Tegn per vindu for evaluering (default/maks 10 000 tegn; konfigurerbart kun for responser — for requests brukes alltid default)
- `window-overlap-size`: Overlapp i tegn mellom vinduer når innhold splittes etter `window-size` (ingen overlapp hvis uoppgitt)
- `output-type`: FourSeverityLevels (0,2,4,6) eller EightSeverityLevels (0-7)
- Threshold 0 = mest restriktivt, 7 = minst restriktivt. Threshold 4 blokkerer nivå 4-7, tillater 0-3.
- Støtter også `blocklists` for tilpassede ord/uttrykk

**Fordeler:**
- Sentralisert content safety enforcement på API-lag
- Automatisk blokkering (HTTP 403) av requester som matcher attack patterns
- Ingen endringer nødvendig i applikasjonskode
- Fungerer for streaming responses (buffer-basert sliding window)

### Azure Monitor + Action Groups for Automated Healing

**Setup:**
1. Azure Monitor overvåker Azure OpenAI metrics (rate limit errors, 5xx errors)
2. Alert rule triggers ved definert terskel (f.eks. >10 429-feil per minutt)
3. Action Group starter automated healing:
   - Azure Function som scaler opp quota
   - Automation Runbook som switcher til backup-region
   - Logic App som sender varsling til on-call team

**Eksempel alert rule:**
```json
{
  "condition": {
    "allOf": [
      {
        "metricName": "TooManyRequests",
        "operator": "GreaterThan",
        "threshold": 10,
        "timeAggregation": "Total",
        "dimensions": []
      }
    ]
  },
  "actions": {
    "actionGroups": [
      "/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Insights/actionGroups/OpenAI-AutoHealing"
    ]
  }
}
```

### Azure AI Foundry Safety Evaluations

For systematisk testing av error handling før produksjon:

```python
from azure.ai.evaluation import evaluate

result = evaluate(
    evaluation_name="error_handling_evaluation",
    data="test_data.jsonl",
    model="gpt-4o",
    evaluators={
        "robustness": robustness_evaluator,
        "safety": safety_evaluator
    }
)
```

**Evalueringsscenarier:**
- Hvordan håndterer modellen injected adversarial prompts?
- Returnerer modellen sikre fallback-responses ved usikkerhet?
- Er retry-logikken effektiv under simulert rate limiting?

---

## Offentlig sektor (Norge)

### Spesifikke Krav og Anbefalinger

**1. Personvern (GDPR/DPIA):**
- **Problem:** Feilmeldinger kan utilsiktet eksponere personopplysninger
- **Løsning:**
  - Sanitize alle error messages før logging
  - Bruk generic error messages til brukere
  - Logg detaljert informasjon i secure audit trail

**2. Tilgjengelighet og Redundans:**
- **Krav:** Offentlige tjenester må være tilgjengelige 24/7 (eller i henhold til SLA)
- **Løsning:**
  - Multi-region deployment med automated failover
  - Graceful degradation som opprettholder kritiske funksjoner
  - Cached responses for vanlige queries

**3. Kostnadsbevissthet:**
- **Problem:** Ukontrollerte retries kan generere høye kostnader
- **Løsning:**
  - Sett max retry limits (f.eks. 3 forsøk)
  - Implementer cost budgets i Azure Cost Management
  - Alert ved unormal kostnadsøkning

**4. Norsk språk og kulturell kontekst:**
- **Problem:** Fallback-prompts må være kulturelt og språklig relevante
- **Løsning:**
  - Test fallback-prompts på norsk innhold
  - Bruk norske eksempler i system prompts
  - Valider at fallback-responses er forståelige for norske brukere

**5. Compliance og Audit Trail:**
- **Krav:** Dokumentasjon av alle feil og recovery-actions
- **Løsning:**
  - Log alle error events med timestamps og correlation IDs
  - Implementer distributed tracing (Azure Application Insights)
  - Monthly reporting av error rates og recovery success

---

## Kostnad og lisensiering

### Kostnadsimplikasjoner av Error Handling

**1. Retry-kostnader:**
- **400-feil (content filter):** Du betaler for prompt tokens selv om requesten blokkeres
- **429/5xx-feil:** Ingen kostnad for failede requests
- **Retry-forsøk:** Hver retry koster som en ny request

**Estimat (gpt-4o, NOK, februar 2026):**
- Prompt: 5000 tokens × 0,0035 NOK = 17,50 NOK
- Completion: 1000 tokens × 0,014 NOK = 14,00 NOK
- **Total per request:** ~31,50 NOK

**Med 3 retries:** 4 × 31,50 NOK = 126 NOK for én user query (hvis alle forsøk bruker full context)

**Kostnadsoptimalisering:**
- Reducer context size i retry-forsøk
- Bruk billigere modeller for fallback (gpt-4o-mini, gpt-35-turbo)
- Implementer aggressive caching
- Bruk PTU (Provisioned Throughput) for forutsigbare kostnader

**PTU vs. Pay-as-you-go for high-availability:**

| Deployment | Kapasitet | Måndedskostnad (NOK) | Egnet for |
|------------|-----------|----------------------|-----------|
| PTU 100K TPM | 100 000 tokens/min | ~25 000 – 35 000 | Production med høy trafikk |
| S0 (fallback) | Variabel (quota-basert) | Kun usage | Burst capacity, failover |

**Anbefaling for offentlig sektor:**
- PTU for kritiske tjenester (Priority 1)
- S0 i multiple regioner som fallback (Priority 2-3)
- Estimert total kostnad: 30 000 – 50 000 NOK/måned for medium-sized løsning med high availability

### Lisensiering

**Azure OpenAI:**
- Ingen spesifikke lisenskrav utover Azure-abonnement
- PTU krever commitment (minimum 1 måned)
- S0 er pay-as-you-go uten commitment

**Azure AI Content Safety:**
- Gratis tier: 5000 transactions/måned
- Standard: ~0,008 NOK per transaction
- For production: estimér 10 000 – 50 000 transactions/måned = 80 – 400 NOK/måned

**Azure Monitor / Application Insights:**
- Inkludert i de fleste Azure-planer
- Pay-as-you-go for høy logging-volumm

---

## For arkitekten (Cosmo)

### Spørsmål å stille kunden

**Reliability:**
1. Hva er akseptabel downtime for AI-funksjonaliteten? (99%, 99.9%, 99.99%)
2. Kan applikasjonen fungere i degradert modus uten AI?
3. Hvilke kritiske flows er avhengige av AI-responses?

**Performance:**
4. Hva er forventet query-volum per minutt/time?
5. Hva er akseptabel latency ved normal drift? Ved failover?
6. Hvor mange concurrent users forventes?

**Cost:**
7. Hva er budsjettet for AI-infrastruktur per måned?
8. Er PTU (forutsigbar kostnad) foretrukket over pay-as-you-go?
9. Hvor mye kan en enkelt feilet request koste (retry-limits)?

**Security:**
10. Hvilke typer innhold må filtreres (hate, violence, sexual, self-harm)?
11. Må dere logge alle AI-interaksjoner for compliance?
12. Finnes det PII i prompts eller responses som må håndteres spesielt?

**Operations:**
13. Har dere on-call team for incident response?
14. Hvilke monitoring-verktøy brukes allerede?
15. Skal recovery-actions være automatiske eller manuelt godkjente?

### Decision Tree for Error Handling-Arkitektur

```
START: Velg error handling-strategi
│
├─ Forventet query-volum?
│  ├─ Lav (<100/min) → SDK retry (default) + graceful degradation
│  ├─ Medium (100-1000/min) → Multi-instance + circuit breaker
│  └─ Høy (>1000/min) → Priority-based load balancing + bulkhead
│
├─ Kritikalitet av AI-responses?
│  ├─ Nice-to-have → Graceful degradation med cached fallback
│  ├─ Viktig → Circuit breaker + fallback prompting
│  └─ Kritisk → Multi-region + automated failover + PTU
│
├─ Compliance-krav?
│  ├─ Offentlig sektor → Content Safety + audit logging + GDPR-compliant error messages
│  ├─ Finansiell → PCI-DSS + encrypted logging + incident reporting
│  └─ Generell → Standard logging + monitoring
│
└─ Budsjett?
   ├─ Begrenset → S0 + SDK retry + cached fallback
   ├─ Medium → S0 multi-region + circuit breaker + selective PTU
   └─ Høyt → PTU primary + S0 fallback + full automation
```

### Vanlige Antipatterns (unngå disse)

❌ **Infinite retries uten backoff**
- Resultat: Thundering herd, continued cost accumulation
- Fix: Maks 3-5 retries med exponential backoff

❌ **Ignorering av `Retry-After` header**
- Resultat: Fortsatt throttling, waste of resources
- Fix: Respekter alltid `Retry-After`, eller wait lenger

❌ **Manglende fallback ved persistent failure**
- Resultat: Total service unavailability
- Fix: Graceful degradation med cached/default responses

❌ **Logging av PII i error messages**
- Resultat: GDPR-brudd, security incident
- Fix: Sanitize alle logs, bruk correlation IDs

❌ **Ukontrollert retry uten cost limits**
- Resultat: Budget overrun
- Fix: Sett Azure Cost Management budgets + alerts

### Referansearkitektur for High-Availability AI-Applikasjon

```
User Request
     │
     ↓
[Azure Front Door] ← Global load balancing
     │
     ↓
[Azure API Management] ← llm-content-safety policy, rate limiting
     │
     ├─ Priority 1: [Azure OpenAI PTU - Region 1]
     │                   ↑
     │                   └─ Health probe (429 detection)
     │
     ├─ Priority 2: [Azure OpenAI S0 - Region 1]
     │                   ↑
     │                   └─ Health probe (429 detection)
     │
     └─ Priority 3: [Azure OpenAI S0 - Region 2]
                         ↑
                         └─ Health probe (429 detection)
     │
     ↓
[Circuit Breaker in App Logic]
     │
     ├─ Success → Return response
     │
     ├─ Rate Limit → Failover to next priority
     │
     └─ Total Failure → Graceful Degradation
                             │
                             ├─ [Azure Cache for Redis] ← Cached responses
                             └─ [Fallback Logic] ← Rule-based / default responses
     │
     ↓
[Azure Monitor + Application Insights] ← Logging, alerting, automated healing
```

### Implementeringsrekkefølge (anbefalt)

**Fase 1: Grunnleggende (MVP):**
1. Bruk SDK retry defaults (2 forsøk)
2. Implementer basic error handling (try-catch)
3. Logg alle feil til Application Insights
4. Graceful degradation med generic error messages

**Fase 2: Production-Ready:**
5. Implementer circuit breaker pattern
6. Setup Azure AI Content Safety pre/post-filtering
7. Multi-instance deployment i samme region
8. Cached fallback-responses

**Fase 3: High Availability:**
9. Multi-region deployment
10. Priority-based load balancing
11. Automated failover
12. PTU for kritiske workloads

**Fase 4: Advanced:**
13. Bulkhead pattern for multi-tenant
14. Checkpoint pattern for long-running jobs
15. Advanced fallback prompting (temperature, model switching)
16. Automated healing med Azure Monitor action groups

---

## Kilder og verifisering

**Primærkilder (Microsoft Learn):**
1. [Azure OpenAI supported programming languages - Error handling](https://learn.microsoft.com/en-us/azure/foundry/openai/supported-languages) – Offisiell dokumentasjon for retry-mekanismer i alle SDK-er
2. [Architecture strategies for self-preservation](https://learn.microsoft.com/en-us/azure/well-architected/reliability/self-preservation) – Azure Well-Architected Framework reliability-mønstre
3. [Azure OpenAI Priority-Based Load Balancer (GitHub)](https://github.com/Azure-Samples/openai-aca-lb) – Referanseimplementasjon av smart load balancing
4. [Troubleshooting Azure OpenAI On Your Data](https://learn.microsoft.com/en-us/azure/foundry-classic/openai/how-to/on-your-data-best-practices) – Best practices for debugging og error handling
5. [llm-content-safety policy (APIM)](https://learn.microsoft.com/en-us/azure/api-management/llm-content-safety-policy) (Re-verified MCP 2026-06-19) – Content safety enforcement i API Management. Policy-attributter: backend-id, shield-prompt, enforce-on-completions, window-size, window-overlap-size, output-type, threshold (0-7), blocklists.

**Sekundærkilder:**
6. [Azure OpenAI FAQ](https://learn.microsoft.com/en-us/azure/foundry-classic/openai/faq) – Vanlige feilsituasjoner og workarounds
7. [OWASP Top 10 for LLM - Improper Output Handling](https://genai.owasp.org/llmrisk/llm052025-improper-output-handling/) – Sikkerhetshensyn ved output validation
8. [Reliability Maturity Model](https://learn.microsoft.com/en-us/azure/well-architected/reliability/maturity-model) – Graceful degradation og testing

**Verifisert:** Alle tekniske detaljer er hentet fra offisielle Microsoft-kilder (learn.microsoft.com, GitHub samples). Kodeeksempler er basert på offisielle SDK-dokumentasjon (januar 2026).

**Confidence markers:**
- **Høy confidence:** HTTP error codes, SDK retry defaults, `Retry-After` header, content safety policies (re-verified MCP 2026-06-19)
- **Medium confidence:** Kostnadsestimater (prisene kan variere), spesifikke PTU-priser for norske kunder
- **Lav confidence:** N/A – alle anbefalinger er basert på etablerte mønstre

---

**For Cosmo Skyberg:**
Bruk denne referansen når kunden spør om:
- "Hvordan håndterer vi feil fra Azure OpenAI?"
- "Hva gjør vi hvis vi får 429 rate limit errors?"
- "Kan AI-applikasjonen vår fortsette å fungere hvis Azure OpenAI er nede?"
- "Hvordan unngår vi at usikre AI-responses ødelegger brukeropplevelsen?"
- "Hva koster det å ha high availability for AI-tjenesten?"

Kombiner denne kunnskapen med andre referanser om RAG, sikkerhet og kostnadsoptimalisering for helhetlige anbefalinger.