feat(ultraplan-local): v1.6.0 — /ultraresearch-local deep research command

Add /ultraresearch-local for structured research combining local codebase analysis with external knowledge via parallel agent swarms. Produces research briefs with triangulation, confidence ratings, and source quality assessment. New command: /ultraresearch-local with modes --quick, --local, --external, --fg. New agents: research-orchestrator (opus), docs-researcher, community-researcher, security-researcher, contrarian-researcher, gemini-bridge (all sonnet). New template: research-brief-template.md. Integration: --research flag in /ultraplan-local accepts pre-built research briefs (up to 3), enriches the interview and exploration phases. Planning orchestrator cross-references brief findings during synthesis. Design principle: Context Engineering — right information to right agent at right time. Research briefs are structured artifacts in the pipeline: ultraresearch → brief → ultraplan --research → plan → ultraexecute. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-04-08 08:58:35 +02:00 · 2026-04-08 08:58:35 +02:00 · baa2d0220b
commit baa2d0220b
488 changed files with 213221 additions and 0 deletions
--- a/skills/ms-ai-engineering/references/azure-ai-services/ai-services-enterprise-architecture.md
+++ b/skills/ms-ai-engineering/references/azure-ai-services/ai-services-enterprise-architecture.md
@ -0,0 +1,566 @@
+# Azure AI Services - Enterprise Architecture Patterns
+**Last updated:** 2026-02
+**Status:** GA
+**Category:** Azure AI Services (Foundry Tools)
+
+---
+
+## Introduksjon
+
+Azure AI Services (tidligere Cognitive Services) krever robuste enterprise-arkitekturmønstre for å sikre høy tilgjengelighet, disaster recovery og effektiv skalering i produksjonsmiljøer. Dette dokumentet dekker arkitekturmønstre for multi-region deployment, load balancing, failover og infrastrukturdesign for AI-tjenester i Microsoft-stakken.
+
+**Sentrale utfordringer:**
+- Regional failover og business continuity
+- Load balancing mellom flere Azure OpenAI-instanser
+- Kostnadsoptimalisering vs. tilgjengelighet
+- Network isolation og security perimeter
+- Kvotestyring og throttling-håndtering
+
+**Scope:** Dette dokumentet fokuserer på arkitekturmønstre for Azure OpenAI (del av Foundry Models), Azure AI Search, og støttetjenester som Azure API Management og Azure Front Door. Mønstrene gjelder både Foundry-baserte løsninger og standalone AI Services.
+
+---
+
+## Kjernekomponenter
+
+### 1. Azure AI Services (Foundry Models)
+
+**Deployment-typer:**
+| Type | Beskrivelse | Bruksområde |
+|------|-------------|-------------|
+| **Global Standard** | Automatisk routing til regioner med kapasitet | Høyeste resilience, ingen data residency-krav |
+| **Data Zone Standard** | Processing innenfor geografisk sone (US/EU) | Data residency-krav, god resilience |
+| **Regional Standard** | Én spesifikk region | Lav latency, manuell failover |
+| **Provisioned (PTU)** | Dedikert kapasitet, SLA på latency | Mission-critical workloads, predictable load |
+
+**Multi-region strategi:**
+- Minimum 2 regioner for produksjon (active-active eller active-passive)
+- Data Zone deployments deler kapasitetspool på tvers av regioner i samme sone
+- Separat subscription per region unngår kvote-konflikter
+- Full quota allocation per endpoint gir høyest throughput
+
+### 2. Generative AI Gateway (Azure API Management)
+
+**Funksjonalitet:**
+- **Load balancing:** Round-robin, weighted, priority-based, session-aware
+- **Circuit breaker:** Automatisk deteksjon av 429-errors, dynamisk trip duration basert på `Retry-After`-header
+- **Spillover:** Automatic failover til sekundære backends ved throttling
+- **Managed identity:** Eliminerer API key management
+
+**Backend pool configuration:**
+- Inntil 30 backends per pool
+- Priority groups: PTU som Priority 1, standard deployments som Priority 2+
+- Session affinity for conversational agents
+- Health probes og automatic retry uten client-side delay
+
+**VIKTIG:** APIM circuit breaker for Azure OpenAI må håndtere `429 Too Many Requests` og respektere `Retry-After`-headeren (kan være opptil 24 timer).
+
+### 3. Azure AI Search
+
+**Zone redundancy:**
+- Standard tier eller høyere + minimum 3 replicas
+- Automatisk distribusjon på tvers av availability zones
+- Ingen built-in disaster recovery — krever manuell gjenoppbygging eller support-kontakt
+- Semantic ranker og advanced features øker kostnad
+
+**Multi-region:**
+- Separat service per region (ingen native multi-region replication)
+- Geo-replication strategy må implementeres selv
+- Index rebuilding fra separate source of truth ved data loss
+
+### 4. Global Load Balancers
+
+**Azure Front Door:**
+- Global HTTP(S) load balancing og failover
+- Latency-based routing
+- Web Application Firewall (WAF) integration
+- Health probes på application-nivå
+
+**Azure Traffic Manager:**
+- DNS-basert global routing
+- Performance, priority, weighted, geographic routing
+- Health endpoint monitoring
+- Brukes ofte foran search-enabled clients (ikke direkte til AI Search)
+
+---
+
+## Arkitekturmønstre
+
+### Mønster 1: Active-Active med Priority-Based Load Balancing
+
+**Scenario:** Enterprise med PTU-deployment + standard deployments som fallback.
+
+```
+┌─────────────────────────────────────────────────────────┐
+│ Azure API Management (Multi-region eller Frontend)      │
+│ - Backend pool med circuit breaker                      │
+│ - Session affinity for chat                             │
+└─────────┬───────────────────────────────────────────────┘
+          │
+    ┌─────┴─────┐
+    │  Priority │
+    │  Routing  │
+    └─────┬─────┘
+          │
+    ┌─────┴──────────────────────────────────────┐
+    │                                             │
+┌───▼─────────────────┐              ┌───────────▼──────────┐
+│ Priority 1: PTU     │              │ Priority 2: Standard │
+│ Region A            │              │ Multi-region (US/EU) │
+│ - Dedicated capacity│              │ - Data Zone          │
+│ - Fixed cost        │              │ - Pay-per-token      │
+│ - SLA latency       │              │ - Spillover          │
+└─────────────────────┘              └──────────────────────┘
+```
+
+**Fordeler:**
+- Maksimal utnyttelse av PTU (fast kostnad)
+- Automatisk spillover til standard ved PTU-overload
+- Ingen client-side retry logic nødvendig
+
+**Ulemper:**
+- Kompleks konfigurasjon
+- APIM koster ekstra
+- Ikke transparent failover ved regional outage (krever DNS/Front Door)
+
+---
+
+### Mønster 2: Multi-Region med Azure Front Door
+
+**Scenario:** Global applikasjon med latency-sensitive workloads.
+
+```
+                    ┌──────────────────┐
+                    │ Azure Front Door │
+                    │ + WAF            │
+                    └────────┬─────────┘
+                             │
+                ┌────────────┴────────────┐
+                │                         │
+        ┌───────▼────────┐      ┌────────▼───────┐
+        │ Region 1 (US)  │      │ Region 2 (EU)  │
+        │ - APIM         │      │ - APIM         │
+        │ - OpenAI       │      │ - OpenAI       │
+        │ - AI Search    │      │ - AI Search    │
+        │ - Cosmos DB    │      │ - Cosmos DB    │
+        └────────────────┘      └────────────────┘
+```
+
+**Komponenter:**
+- **Front Door:** Global routing, instant failover, health probes
+- **Per-region:** Komplett stack (APIM, AI Services, data)
+- **Data replication:** Cosmos DB global distribution, Storage GRS/GZRS
+
+**Fordeler:**
+- Minimal latency for globale brukere
+- Transparent failover ved regional outage
+- Høy SLA (multi-region SLA composite)
+
+**Ulemper:**
+- Høy kostnad (dobbel infrastruktur minimum)
+- Data consistency-utfordringer
+- Kompleks deployment og drift
+
+---
+
+### Mønster 3: Hot/Warm med Data Zone Deployments
+
+**Scenario:** Compliance-krav (data residency i EU/US) med cost optimization.
+
+```
+Primary Region (Hot)          Secondary Region (Warm)
+┌──────────────────┐         ┌──────────────────┐
+│ Full capacity    │         │ Reduced capacity │
+│ - OpenAI (PTU)   │         │ - OpenAI (Std)   │
+│ - AI Search (3x) │ ──────> │ - AI Search (1x) │
+│ - Cosmos DB      │ replica │ - Cosmos DB      │
+│ - Active traffic │         │ - Standby        │
+└──────────────────┘         └──────────────────┘
+        │                              ▲
+        └──────────────────────────────┘
+           Manual DNS failover
+```
+
+**Failover-strategi:**
+1. Detekter outage via health monitoring
+2. Scale up secondary region capacity
+3. DNS cutover (eller APIM backend pool update)
+4. Validate service restoration
+
+**RTO/RPO:**
+- RTO: 5-15 minutter (avhenger av scaling speed)
+- RPO: Nær null (Cosmos DB continuous backup, AI Search rebuild required)
+
+**Fordeler:**
+- 50-70% kostnadssparing vs. full hot/hot
+- Data residency compliance
+- Raskere failover enn cold standby
+
+**Ulemper:**
+- Ikke transparent failover
+- Capacity scaling under outage er risikabelt
+- Manual intervention required
+
+---
+
+### Mønster 4: Foundry Agent Service med Standard Setup
+
+**Scenario:** Enterprise chat application med network isolation.
+
+```
+┌────────────────────────────────────────────────────┐
+│ Virtual Network                                     │
+│ ┌────────────────────────────────────────────────┐ │
+│ │ App Service (Web UI)                           │ │
+│ │ - VNet integration                             │ │
+│ │ - Managed identity                             │ │
+│ └─────────┬──────────────────────────────────────┘ │
+│           │ Private Endpoint                        │
+│ ┌─────────▼──────────────────────────────────────┐ │
+│ │ Foundry Agent Service                          │ │
+│ │ - Agent runtime                                │ │
+│ │ - Private endpoint access only                 │ │
+│ └─────────┬──────────────────────────────────────┘ │
+│           │ Delegated subnet                        │
+│ ┌─────────▼──────────────────────────────────────┐ │
+│ │ Private Endpoints:                             │ │
+│ │ - Azure OpenAI                                 │ │
+│ │ - AI Search                                    │ │
+│ │ - Cosmos DB (conversation state)               │ │
+│ │ - Storage (file uploads)                       │ │
+│ └────────────────────────────────────────────────┘ │
+│                      │                              │
+│           ┌──────────▼─────────┐                    │
+│           │ Azure Firewall     │                    │
+│           │ - FQDN filtering   │                    │
+│           │ - Egress control   │                    │
+│           └────────────────────┘                    │
+└────────────────────────────────────────────────────┘
+```
+
+**Zone redundancy:**
+- **Cosmos DB:** Zone-redundant (ZRS) eller global distribution
+- **Storage:** ZRS eller GZRS
+- **AI Search:** 3+ replicas med automatic zone distribution
+- **App Service:** Zone-redundant (minimum 3 instances)
+
+**Disaster recovery:**
+- Cosmos DB: Continuous backup (7-day PITR)
+- AI Search: Ingen native backup — rebuild fra source of truth
+- Storage: Customer-managed failover for geo-redundant accounts
+- Agent definitions: Infrastructure as Code (deploy from source control)
+
+**Fordeler:**
+- Enterprise-grade security (zero trust network)
+- Full audit trail via NSG flow logs og Firewall logs
+- Managed identity eliminerer secrets
+- Foundry Agent Service håndterer orchestration og state
+
+**Ulemper:**
+- Høyere kompleksitet
+- Ikke multi-region (krever separate deployments)
+- Foundry portal krever jump box eller VPN-tilgang
+
+---
+
+## Beslutningsveiledning
+
+### 1. Velge Deployment Type
+
+| Krav | Anbefaling |
+|------|------------|
+| Høyeste resilience, ingen data residency-krav | **Global Standard** |
+| EU/US data residency | **Data Zone Standard** |
+| Lavest latency, eksisterende regional infra | **Regional Standard** (+ manuell multi-region) |
+| Predictable latency SLA, mission-critical | **Provisioned (PTU)** |
+| Kostnadsoptimalisering, variabel load | **Standard** med APIM spillover til PTU |
+
+### 2. Velge Load Balancing Strategy
+
+| Scenario | Løsning |
+|----------|---------|
+| Single region, multiple Azure OpenAI instances | **Azure API Management** (backend pool + circuit breaker) |
+| Multi-region global routing | **Azure Front Door** + regional APIM |
+| Latency-sensitive, DNS-based | **Traffic Manager** + health probes |
+| DIY, containerized | **YARP** (C# reverse proxy) på Azure Container Apps |
+
+### 3. Velge RTO/RPO Strategi
+
+| RTO/RPO Mål | Mønster | Relative Cost |
+|-------------|---------|---------------|
+| RTO < 1 min, RPO = 0 | Active-active (hot/hot) | 2.0x |
+| RTO < 15 min, RPO < 5 min | Active-warm | 1.4x |
+| RTO < 1 hour, RPO < 1 hour | Active-cold | 1.1x |
+
+**Konfidensgradering:** 🟢 **Høy** — Basert på Microsoft Learn offisiell dokumentasjon (2026-02).
+
+---
+
+## Integrasjon med Microsoft-stakken
+
+### Azure AI Foundry Integration
+
+**Foundry Agent Service Dependencies (Standard Setup):**
+- **Cosmos DB for NoSQL:** Agent state og conversation history (krever zone redundancy)
+- **Azure Storage:** File uploads og static files (krever ZRS/GZRS)
+- **Azure AI Search:** Chunked index av filer (krever 3+ replicas)
+
+**Multi-project isolation:**
+- Separate Foundry project per agent med distinct access patterns
+- Project-level connections (ikke account-level) for least privilege
+- User-assigned managed identity for project identity (survival ved accidental deletion)
+
+**Disaster recovery:**
+- Agent definitions som Infrastructure as Code
+- Continuous backup på Cosmos DB (7-day PITR)
+- Transactional consistency: Restore alle dependencies til samme point-in-time
+
+### Power Platform Integration
+
+**Copilot Studio:**
+- Uses Azure OpenAI via Foundry Models
+- Separate per-environment deployments anbefales
+- Gateway-pattern mulig via custom connectors
+
+**Power Automate:**
+- AI Builder actions bruker dedikerte AI Services
+- Premium connectors kan kalle APIM-fronted Azure OpenAI
+- Regional availability varierer (sjekk [Products by Region](https://azure.microsoft.com/global-infrastructure/services/))
+
+### M365 Copilot
+
+**Ikke direkte integrasjon med custom Azure OpenAI:**
+- M365 Copilot bruker Microsoft-managed AI infrastructure
+- Grounding via Microsoft Graph, SharePoint, OneDrive
+- Copilot Studio kan utvide med custom skills som kaller Azure OpenAI via gateway
+
+---
+
+## Offentlig sektor (Norge)
+
+### Compliance og Data Residency
+
+**Azure OpenAI i Norge:**
+- Ingen Azure OpenAI-region i Norge per 2026-02
+- **Nærmeste regioner:** Sweden Central, West Europe
+- **Data residency:** Bruk **Data Zone EU** for GDPR-compliance
+- **Schrems II:** Data Zone deployments prosesserer data innenfor EU
+
+**Network Isolation:**
+- Private endpoints + Azure Firewall (FQDN-filtering)
+- NSG per subnet med deny-all default
+- Jump box + Azure Bastion for admin-tilgang
+- ExpressRoute for hybrid connectivity (ikke required for cloud-only workloads)
+
+### Anbefalte Patterns for Norsk Offentlig Sektor
+
+**Konfidensialitet Normal (N):**
+- Data Zone EU Standard deployments
+- Hot/warm multi-region (West Europe + Sweden Central)
+- Azure API Management for load balancing
+- Zone-redundant støttetjenester
+
+**Konfidensialitet Høy (H):**
+- Som Normal + Private endpoints på alt
+- Azure Firewall med strict egress rules
+- Customer-managed keys (CMK) for encryption
+- Audit logging til Log Analytics Workspace (Norge-region hvis tilgjengelig, ellers EU)
+
+**Konfidensialitet Særlig Høy (SH):**
+- Vurder on-premises AI Services containers (begrenset funksjonalitet)
+- Eller: Data Zone EU + customer-managed VNet med zero internet egress
+- Dedikert subscription per sensitivity zone
+- Enhanced monitoring og Security Operations Center (SOC) integration
+
+**Kostnadsoversikt (estimat, NOK per måned):**
+
+| Komponent | Normal (N) | Høy (H) | Særlig Høy (SH) |
+|-----------|-----------|---------|-----------------|
+| Azure OpenAI (50K tokens/dag) | ~1 500 | ~3 000 (2x regions) | ~6 000 (PTU dedicated) |
+| Azure API Management (Standard) | ~6 000 | ~6 000 | ~12 000 (2x regions) |
+| AI Search (Standard, 3 replicas) | ~9 000 | ~18 000 (2x regions) | ~18 000 |
+| Cosmos DB (zone-redundant) | ~3 000 | ~6 000 (global) | ~6 000 |
+| **Total (ca.)** | **~19 500** | **~33 000** | **~42 000** |
+
+*Disclaimer: Priser er estimater basert på moderate workloads. Faktiske kostnader avhenger av trafikk, data volume og konkrete konfigurasjon.*
+
+---
+
+## Kostnad og lisensiering
+
+### Azure OpenAI Pricing Model
+
+**Standard Deployments (Pay-per-token):**
+- **Input tokens:** ~0.003 USD per 1K tokens (GPT-4o)
+- **Output tokens:** ~0.006 USD per 1K tokens (GPT-4o)
+- **Image input:** Per image (varierer med resolution)
+- **Ingen minimum commitment**
+
+**Provisioned (PTU):**
+- **Fixed monthly cost:** ~2 500 USD per 100 PTU
+- **Inkluderer:** Dedikert kapasitet, latency SLA, priority access
+- **Optimalt for:** >10M tokens/måned med forutsigbar load
+
+**Cost Optimization Strategies:**
+- **Prompt optimization:** Reducer input tokens (concise prompts, efficient context)
+- **Model selection:** Bruk GPT-4o-mini for enklere tasks (10x billigere)
+- **Caching:** (Planlagt feature) Reduserer repeterende context-tokens
+- **APIM rate limiting:** Forhindre abuse og kostnadsoverskridelse
+- **Spillover strategy:** PTU for baseline, standard for peaks
+
+### Azure API Management Pricing
+
+| Tier | Kostnad (ca. NOK/måned) | Max requests | Features |
+|------|------------------------|--------------|----------|
+| Developer | ~500 | 1M calls | Ingen SLA, dev/test |
+| Basic | ~1 500 | 1M calls | SLA, 1 unit max |
+| Standard | ~6 000 | 10M calls | Multi-region, 4 units |
+| Premium | ~30 000+ | Unlimited | Multi-region, VNet, 10+ units |
+
+**For AI Gateway:** Standard tier minimum (circuit breaker ikke i Consumption tier).
+
+### Azure AI Search Pricing
+
+**Standard Tier (anbefalt for prod):**
+- **S1:** ~3 000 NOK/måned per search unit
+- **Zone redundancy:** Requires 3+ replicas = ~9 000 NOK/måned minimum
+- **Semantic ranker:** +~1 000 NOK/månd per search unit
+
+### Total Cost of Ownership (TCO) Example
+
+**Scenario:** Enterprise chat application, 100 users, 50 queries/dag per user.
+
+**Forutsetninger:**
+- 5 000 queries/dag total
+- Average 1 000 input tokens + 500 output tokens per query
+- 2 regioner (active-warm)
+
+**Månedlig kostnad (NOK):**
+```
+Azure OpenAI: ~15 000 (2.5M in + 1.25M out tokens)
+APIM Standard: ~6 000 (single region)
+AI Search S1 (3 replicas): ~9 000
+Cosmos DB (zone-redundant): ~3 000
+Storage ZRS: ~200
+Front Door: ~1 500
+──────────────────────────────────────────────────────
+TOTAL: ~34 700 NOK/måned
+```
+
+**Med PTU optimization (100 PTU i primary region):**
+```
+Azure OpenAI PTU: ~25 000 (fixed)
+Azure OpenAI Standard (spillover): ~3 000
+[Andre komponenter samme]
+──────────────────────────────────────────────────────
+TOTAL: ~46 700 NOK/måned (høyere cost, men forutsigbar)
+```
+
+**Konfidensgradering:** 🟡 **Medium** — Prisene er estimater basert på publiserte prislister (2026-02). Faktiske kostnader avhenger av detaljert bruksmønster.
+
+---
+
+## For arkitekten (Cosmo)
+
+### Når bruke hvilke mønstre
+
+**Velg Active-Active (Hot/Hot) hvis:**
+- RTO < 1 minutt er strengt krav
+- Global user base med latency-følsomhet
+- Budsjett tillater 2x infrastructure cost
+- Datakonsistens kan håndteres (eventual consistency OK)
+
+**Velg Active-Warm hvis:**
+- RTO < 15 minutter er akseptabelt
+- Primært regional user base
+- Kostnadsoptimalisering er prioritet
+- Manual failover-prosess er akseptabel
+
+**Velg Regional + APIM hvis:**
+- Single-region deployment er OK
+- Throttling-håndtering viktigere enn regional failover
+- Lavere kostnad og kompleksitet prioriteres
+
+### Kritiske spørsmål å stille kunden
+
+1. **RTO/RPO requirements:** Hva er maksimal akseptabel downtime? Data loss?
+2. **Data residency:** Er det juridiske krav til hvor data prosesseres? (GDPR, Schrems II)
+3. **Budget:** Hva er månedlig budsjett for AI infrastructure? (Påvirker hot/warm/cold valg)
+4. **User distribution:** Global eller regional? (Påvirker multi-region strategi)
+5. **Load pattern:** Forutsigbar eller spiky? (PTU vs. standard)
+6. **Security posture:** Network isolation required? (Påvirker VNet/private endpoint design)
+7. **Existing footprint:** Azure landing zone existing? ExpressRoute? (Påvirker integration)
+
+### Røde flagg å unngå
+
+❌ **Single region uten throttling-håndtering** — Garantert 429-errors under peak load
+❌ **Shared APIM backend pool på tvers av environments** — Dev throttling påvirker prod
+❌ **Account-level Foundry connections** — Overprivileged access på tvers av prosjekter
+❌ **Ingen disaster recovery plan for AI Search** — Index-tap er ikke-recoverable uten backup strategy
+❌ **PTU-deployment uten fallback** — Fast cost uten elasticity ved overload
+❌ **Client-side retry uten exponential backoff** — Amplified load under throttling
+❌ **Colocating workload data i Foundry Agent Service dependencies** — Reliability og security risk
+
+### Anbefalte Deployment Sequence
+
+1. **Fase 1 - Single Region MVP:**
+   - Regional Azure OpenAI (Standard)
+   - APIM Basic tier (gateway pattern proof)
+   - AI Search Standard (1 replica)
+   - Cost: ~10K NOK/måned
+
+2. **Fase 2 - Production Hardening:**
+   - Upgrade til APIM Standard (circuit breaker)
+   - AI Search 3 replicas (zone redundancy)
+   - Add secondary region (warm standby)
+   - Cost: ~35K NOK/måned
+
+3. **Fase 3 - Enterprise Scale:**
+   - Azure Front Door (global routing)
+   - PTU deployment i primary region
+   - Full hot/hot multi-region
+   - Cost: ~70K+ NOK/måned
+
+### Monitoring og Alerting
+
+**Kritiske metrics:**
+- **Azure OpenAI:** `TotalTokens`, `GeneratedTokens`, `HTTP 429 count`, `Latency P95`
+- **APIM:** `Backend response time`, `Failed requests`, `Circuit breaker trips`
+- **AI Search:** `Search latency`, `Throttled requests`, `Query volume`
+- **Cosmos DB:** `Request units consumed`, `Availability`, `Latency P99`
+
+**Alert thresholds (forslag):**
+- HTTP 429 count > 1% av requests → Øk quota eller add fallback region
+- APIM backend latency P95 > 5s → Investigate backend health
+- AI Search throttled requests > 0 → Scale up replicas/partitions
+- Cosmos DB RU utilization > 80% → Scale up RU/s eller enable autoscale
+
+**Application Insights integration:**
+- Foundry Agent Service sender automatisk metrics til linked App Insights
+- Custom telemetry via SDK for client-side latency tracking
+- Correlation ID på tvers av alle komponenter for distributed tracing
+
+---
+
+## Kilder og verifisering
+
+**Microsoft Learn Documentation (offisiell, 2026-02):**
+1. [AI Ready - Cloud Adoption Framework](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/ai/ready)
+2. [BCDR for Azure OpenAI](https://learn.microsoft.com/en-us/azure/ai-foundry/openai/how-to/business-continuity-disaster-recovery)
+3. [Baseline Foundry Chat Architecture](https://learn.microsoft.com/en-us/azure/architecture/ai-ml/architecture/baseline-microsoft-foundry-chat)
+4. [Azure API Management - AI Gateway Capabilities](https://learn.microsoft.com/en-us/azure/api-management/genai-gateway-capabilities)
+5. [Reliability in Azure AI Search](https://learn.microsoft.com/en-us/azure/reliability/reliability-ai-search)
+6. [Multi-Backend Gateway Guide](https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/azure-openai-gateway-multi-backend)
+7. [Load Balancing Options - Azure Architecture](https://learn.microsoft.com/en-us/azure/architecture/guide/technology-choices/load-balancing-overview)
+
+**GitHub Samples (Microsoft-verified):**
+8. [Smart Load Balancing for Azure OpenAI (APIM)](https://github.com/Azure-Samples/openai-apim-lb)
+9. [Smart Load Balancing (Container Apps/YARP)](https://github.com/Azure-Samples/openai-aca-lb)
+10. [Foundry Baseline Reference Implementation](https://github.com/Azure-Samples/microsoft-foundry-baseline)
+
+**Verifikasjon:**
+- ✅ Alle arkitekturdiagrammer basert på Microsoft offisiell dokumentasjon
+- ✅ Deployment-typer (Global/Data Zone/Regional/PTU) verifisert mot [Deployment Types](https://learn.microsoft.com/en-us/azure/ai-foundry/foundry-models/concepts/deployment-types)
+- ✅ APIM circuit breaker pattern bekreftet i [Backends Documentation](https://learn.microsoft.com/en-us/azure/api-management/backends)
+- ✅ Zone redundancy requirements verifisert mot [Availability Zones Overview](https://learn.microsoft.com/en-us/azure/reliability/availability-zones-overview)
+
+**Konfidensgradering - Samlet:** 🟢 **Høy** — Arkitekturmønstre og teknisk implementasjon er basert på Microsoft offisiell dokumentasjon (sist oppdatert januar-februar 2026). Kostestimater er indikative og bør verifiseres mot Azure Pricing Calculator for spesifikke konfigurasjoner.