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):

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):

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):

// 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

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

# 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

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

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)

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:

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:

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:

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:

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:

<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:

{
  "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:

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 – Offisiell dokumentasjon for retry-mekanismer i alle SDK-er
2. Architecture strategies for self-preservation – Azure Well-Architected Framework reliability-mønstre
3. Azure OpenAI Priority-Based Load Balancer (GitHub) – Referanseimplementasjon av smart load balancing
4. Troubleshooting Azure OpenAI On Your Data – Best practices for debugging og error handling
5. llm-content-safety policy (APIM) (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 – Vanlige feilsituasjoner og workarounds 7. OWASP Top 10 for LLM - Improper Output Handling – Sikkerhetshensyn ved output validation 8. 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.