ktg-plugin-marketplace/plugins/ms-ai-architect/skills/ms-ai-security/references/cost-optimization/azure-ai-foundry-cost-governance.md

Azure AI Foundry Cost Governance and Controls

Last updated: 2026-02 Status: GA Category: Cost Optimization & FinOps for AI

---

Introduksjon

Cost governance i Azure AI Foundry representerer det strukturelle rammeverket som forhindrer ukontrollert AI-forbruk og sikrer at AI-investeringer forblir innenfor budsjetterte rammer. I motsetning til tradisjonell cloud-kostnadsstyring, krever AI-arbeidsbelastninger spesialiserte kontroller som håndterer både infrastrukturkostnader (compute, storage) og forbruksbaserte kostnader (tokens, API-kall, modelldeployments).

Uten solid cost governance risikerer organisasjoner å oppleve "quota exhaustion" midt i kritiske arbeidsbelastninger, uforutsigbare månedlige regninger fra eksperimentering som ikke blir ryddet opp, og produktive team som blokkeres av for restriktive policies. Det fundamentale dilemmaet er å balansere innovasjonsfrihet med økonomisk kontroll.

Azure AI Foundry tilbyr tre komplementære kontrollmekanismer: quotas (tekniske grenser for ressursallokering), budgets (økonomiske terskler med alerting), og policies (governanceregler som begrenser hvilke modeller og ressurstyper som kan deployes). Sammen utgjør disse et komplett governance-system som lar organisasjoner skalere AI-bruk uten å miste økonomisk oversikt.

Kjernekomponenter

1. Quota Management

Quotas er tekniske grenser som kontrollerer hvor mye av en gitt ressurs en subscription eller region kan konsumere. For AI Foundry gjelder dette både infrastruktur (VM families, compute instances) og modellbruk (tokens per minute, requests per minute).

Quota Type	Scope	Default Limit	Adjustable?
Model Quota (TPM)	Per subscription, per region, per model	Varies by tier (150K-30M TPM)	Yes, via quota request
VM Family Quota	Per subscription, per region	24-300 cores (depends on subscription type)	Yes, via support request
Compute Instances	Per region	500 total compute limit	Yes, up to 2500 via quota UI, beyond via support
Serverless API Quota	Per deployment	200K TPM, 1K RPM	Yes, one deployment per model per project by default
Provisioned Throughput (PTU)	Per region, per subscription	Model-dependent	Yes, via capacity calculator and request

Quota vs. Rate Limit: Quota er total kapasitet allokert til en subscription, mens rate limit er per-deployment begrensning. Eksempel: En subscription kan ha 10M TPM quota for gpt-4o, men fordele dette på 5 deployments med 2M TPM hver.

2. Budget Controls

Budgets er økonomiske terskler konfigurert i Azure Cost Management som trigger varsler når kostnader nærmer seg eller overskrider definerte grenser.

Budget Alerting Thresholds (anbefalt struktur):

Threshold	Action	Owner	Response Time
50% av budsjett	Informational email	Team lead	Review within 48h
75% av budsjett	Alert + resource usage review	Cost owner	Review within 24h
90% av budsjett	Critical alert + freeze non-production	Finance + IT	Immediate action
100% av budsjett	Automation trigger (optional)	Platform team	Immediate

Viktig: Azure OpenAI har IKKE hard limit enforcement som OpenAI API. Budgets sender kun varsler, de stopper ikke forbruk automatisk. For å stoppe forbruk må organisasjonen enten:

• Implementere custom automation via Action Groups
• Bruke Azure Policy til å blokkere nye deployments
• Manuelt disable API keys eller deployments

3. Azure Policy for Model Governance

Azure Policy enforcer governanceregler på platform-nivå. For AI Foundry kan policies kontrollere:

Policy Type	Purpose	Example Use Case
Allowed Model Families	Restrict which models can be deployed	Block preview models in production subscriptions
Allowed Deployment Types	Control standard vs. provisioned throughput	Require PTU for production, allow pay-as-you-go for dev
Required Tags	Enforce cost center tagging	All deployments must have "CostCenter" and "Environment" tags
Network Controls	Enforce private endpoints	Block public internet access to AI endpoints
Region Restrictions	Limit deployment regions	EU data residency requirements

Built-in Policies for AI Foundry:

• Microsoft.CognitiveServices/accounts/deployments policies for model restrictions
• Microsoft.MachineLearningServices policies for compute governance
• Integration with Azure landing zone AI policies (OpenAI, Machine Learning, AI Search)

4. Cost Monitoring and Allocation

Cost visibility mechanisms:

1. Consolidated View (Azure Portal): Dashboard showing costs, quota utilization, model usage across all Foundry resources
2. Management Center (AI Foundry Portal): Hub-level quota view with interactive charts
3. Cost Analysis (Cost Management): Granular filtering by resource type, tag, region, time period
4. Cost Export: Daily/weekly/monthly automated export to storage account for deeper analysis

Tagging Strategy for Cost Allocation:

Mandatory tags:
- CostCenter: [department code]
- Environment: production | staging | development | sandbox
- Project: [project identifier]
- Owner: [responsible team/individual]

Optional tags:
- Application: [application name]
- Workload: [specific AI use case]
- BudgetYear: [fiscal year]

5. Dynamic Quota (Preview)

Dynamic quota lar deployments opportunistisk bruke ubrukt kapasitet utover sin baseline quota når tilgjengelig. Dette er nyttig for:

• Bulk processing workloads
• RAG indexing
• Utviklingsmiljøer med variabel trafikk

Når bruke Dynamic Quota:

• ✅ Workloads som kan håndtere variabel throughput
• ✅ Non-critical eller batch-orienterte oppgaver
• ❌ Produksjonsapplikasjoner som krever forutsigbar ytelse
• ❌ Når du må enforce hard spending cap (dynamic quota har ingen takgrense)

Arkitekturmønstre

Mønster 1: Strict Quota Governance (High Control)

Profil: Offentlig sektor, regulerte industrier, organisasjoner med strenge budsjettkrav.

Structure:
└── Management Group: Organization Root
    ├── Policy Assignment: "Require PTU for production AI workloads"
    ├── Policy Assignment: "Block preview models"
    └── Subscription: Production
        ├── Budget: 150 000 NOK/month (alerts at 50%, 75%, 90%)
        ├── Resource Group: AI-Production-WestEurope
        │   ├── AI Foundry Hub (West Europe)
        │   │   └── Quota Allocation:
        │   │       • gpt-4o: 2M TPM (fixed, no dynamic quota)
        │   │       • gpt-4o-mini: 5M TPM
        │   │       • text-embedding-ada-002: 10M TPM
        │   └── RBAC: Only AI Platform Team has Contributor
        └── Resource Group: AI-Development-NorthEurope
            ├── AI Foundry Hub (North Europe)
            └── Quota Allocation: Shared regional quota

Governance Rules:

• All deployments require approval (ITSM integration)
• Monthly quota reviews by finance controller
• Zero tolerance for quota overruns (alerts escalate to CTO)
• Mandatory cost justification for new projects

Pros: Maksimal økonomisk kontroll, ingen overraskelser i budsjettet Cons: Kan bremse innovasjonstakt, krever overhead for godkjenningsprosesser

---

Mønster 2: Flexible with Alerts (Balanced Approach)

Profil: Enterprise med balanse mellom innovasjon og kontroll, typisk private organisasjoner med moderat risikotoleranse.

Structure:
└── Subscription: AI Platform
    ├── Budget: 300 000 NOK/month (alerts at 75%, 90%, 100%)
    ├── Policy: Allow GA models + approved preview models
    ├── Resource Group per Business Unit
    │   └── AI Foundry Hub per BU
    │       ├── Quota per BU (allocated from subscription total)
    │       └── Project-level quota subdivision
    └── Cost Management:
        • Weekly usage reports to BU leads
        • Monthly chargeback to business units
        • Quarterly optimization reviews

Governance Rules:

• Teams self-service quotas up to allocated limit
• Dynamic quota enabled for non-production environments
• Automatic shutdown of idle compute instances (>7 days)
• Monthly cost reviews with showback per business unit

Quota Allocation Example:

Subscription Total: 20M TPM (gpt-4o)
├── BU Sales & Marketing: 6M TPM (30%)
├── BU Customer Support: 8M TPM (40%)
├── BU Product Development: 5M TPM (25%)
└── Platform Team Reserve: 1M TPM (5%)

Pros: Balanserer autonomi med kontroll, rask innovasjon med økonomisk synlighet Cons: Krever aktiv cost monitoring, risiko for overforbruk i månedslutt

---

Mønster 3: Self-Service with Guardrails (High Autonomy)

Profil: Tech-forward organisasjoner, startups, R&D-avdelinger hvor innovasjonshastighet er kritisk.

Structure:
└── Subscription per Team/Squad
    ├── Budget: Team-controlled (e.g., 50 000 NOK/month)
    ├── Policy: Minimal restrictions (allow all GA models)
    ├── Teams manage own quota allocation
    ├── Platform provides:
    │   • FinOps dashboard (self-service cost visibility)
    │   • Quota request automation (instant approval up to limit)
    │   • Cost anomaly detection (ML-based alerts)
    └── Governance via incentives:
        • Teams keep 50% of savings for other initiatives
        • Public leaderboard: "most cost-efficient AI team"

Guardrails:

• Hard limit on subscription level (platform team enforces max spend)
• Automated cleanup of unused deployments (>14 days idle)
• Quota request approval required only for >5M TPM
• Mandatory tagging (enforced via Azure Policy deny effect)

Cost Optimization Automation:

# Pseudo-code: Auto-scale quotas based on usage
if deployment.usage_last_7d < 0.5 * deployment.quota:
    reduce_quota(deployment, target=usage_last_7d * 1.2)
    notify_team("Quota reduced due to low utilization")

Pros: Maksimal innovasjonshastighet, team ownership av kostnader Cons: Høyere risiko for kostnadssprekk, krever moden FinOps-kultur

---

Beslutningsveiledning

Velge riktig billing model

Scenario	Anbefaling	Begrunnelse
Stable, predictable workload (e.g., 24/7 chatbot)	Provisioned Throughput (PTU)	Lavere kostnad per token, forutsigbar månedlig kostnad
Variable traffic with spikes	Pay-as-you-go + PTU hybrid	PTU for baseline, overflow til consumption
Development/testing	Pay-as-you-go with quotas	Kun betale for faktisk bruk, quotas forhindrer uventede kostnader
Batch processing (periodic)	Pay-as-you-go with dynamic quota	Opportunistisk kapasitet reduserer kostnad
Budget-constrained project	Shared quota pool + strict budget alerts	Maksimal kontroll, delt ressurs på tvers av prosjekter

Quota Allocation Decision Tree

Start: Team requests additional quota
│
├─ Is this for production workload?
│  ├─ Yes → Require capacity planning document
│  │        • Expected TPM/RPM
│  │        • Growth forecast (3 months)
│  │        • Business justification
│  │        → Approve if within budget
│  │
│  └─ No (dev/test) → Approve immediately if:
│                     • Total < 500K TPM
│                     • Time-limited (auto-expire after 30d)
│                     • Tagged with project & owner
│
├─ Does request exceed regional capacity?
│  ├─ Yes → Suggest alternative region or wait for capacity
│  └─ No → Proceed to cost approval
│
└─ Is there budget remaining?
   ├─ Yes → Approve and update tracking
   └─ No → Escalate to finance for budget increase or deny

Common Cost Overrun Scenarios

Red Flag	Root Cause	Prevention
Sudden 10x cost spike in one week	Forgotten high-quota deployment running continuously	Implement idle deployment detection (usage < 5% of quota for 7d → alert)
Gradual cost creep (+20% month-over-month)	Accumulation of "temporary" test deployments	Enforce deployment expiry dates, automated cleanup policies
Quota exhaustion in production	Inadequate capacity planning	Implement quota utilization alerts (>80% = warning, >95% = critical)
Unexpected invoice from Azure Marketplace model	Team deployed third-party model without approval	Azure Policy: Require approval for Marketplace model deployments
High cost for rarely-used model	Wrong billing model selection	Monthly review: PTU models with <50% utilization → migrate to pay-as-you-go

Cost Optimization Checklist

Monthly Review:

• Identify deployments with <50% quota utilization → reduce quota
• Check for deployments with zero usage in 30 days → delete
• Review models in use → can cheaper models suffice? (e.g., gpt-4o-mini vs. gpt-4o)
• Verify tagging compliance (100% of resources tagged)
• Compare actual spend vs. budget forecast (variance analysis)

Quarterly Review:

• Reassess PTU vs. pay-as-you-go for each workload
• Negotiate commitment tiers if usage is stable
• Review quota allocation across business units (rebalance if needed)
• Audit policy compliance (any governance violations?)
• Capacity planning for next quarter

Annual Review:

• Benchmark costs against industry standards
• Evaluate new pricing models (e.g., new PTU tiers)
• Update governance policies based on learnings
• Total Cost of Ownership (TCO) analysis: AI Foundry vs. alternatives

Integrasjon med Microsoft-stakken

Azure Policy Integration

Custom Policy Example: Enforce Cost Center Tagging

{
  "mode": "Indexed",
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.CognitiveServices/accounts"
        },
        {
          "field": "tags['CostCenter']",
          "exists": "false"
        }
      ]
    },
    "then": {
      "effect": "deny"
    }
  }
}

Built-in Policies (examples):

• Cognitive Services accounts should enable data encryption: Påkrevd for compliance, ingen kostnadspåvirkning
• Cognitive Services accounts should restrict network access: Reduserer sikkerhetskostnader (datalekkasje)
• Custom policies for model restrictions (se Microsoft Learn for latest)

Azure Monitor Integration

Recommended Metrics and Alerts:

Metric	Threshold	Alert Severity	Action
QuotaUtilization	>80%	Warning	Request additional quota
QuotaUtilization	>95%	Critical	Emergency quota increase + investigate
TokensUsed (daily)	>1.5x average	Warning	Investigate spike cause
HTTP429Count (rate limit errors)	>100/hour	Critical	Insufficient quota → immediate scale
TotalCost (daily)	>1.2x budget/30	Warning	Cost anomaly detection

Cost Anomaly Detection: Bruk Azure Monitor + Log Analytics til å detektere avvik fra normale forbruksmønstre. Eksempel-query:

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.COGNITIVESERVICES"
| summarize DailyCost = sum(Quantity * UnitPrice) by bin(TimeGenerated, 1d)
| extend BaselineCost = avg(DailyCost) over (StartOfWeek(TimeGenerated), 7d)
| where DailyCost > BaselineCost * 1.5  // 50% deviation
| project TimeGenerated, DailyCost, BaselineCost, Anomaly = (DailyCost - BaselineCost) / BaselineCost

Azure API Management (APIM) Gateway

Generative AI Gateway for cost control:

APIM kan fungere som proxy foran AI Foundry endpoints og tilby:

1. Token-level rate limiting: Begrens tokens per bruker/app per dag (granularitet Azure-quota ikke har)
2. Circuit breaker: Stopp trafikk til endpoint hvis kostnad overskrider terskel
3. Request routing: Send billige requests til gpt-4o-mini, komplekse til gpt-4o (smart routing)
4. Cost tracking per consumer: Chargeback til individuelle teams/applikasjoner

Example APIM Policy (cost-based throttling):

<policies>
  <inbound>
    <quota-by-key calls="100000"
                  bandwidth="0"
                  renewal-period="86400"
                  counter-key="@(context.Request.Headers.GetValueOrDefault("api-key",""))" />

    <set-variable name="estimatedTokens"
                  value="@(context.Request.Body.As<JObject>(true)["max_tokens"])" />

    <choose>
      <when condition="@(int.Parse((string)context.Variables["estimatedTokens"]) > 4000)">
        <set-backend-service base-url="https://expensive-endpoint.openai.azure.com/" />
      </when>
      <otherwise>
        <set-backend-service base-url="https://cost-effective-endpoint.openai.azure.com/" />
      </otherwise>
    </choose>
  </inbound>
</policies>

Management Groups for Multi-Subscription Governance

For organisasjoner med mange subscriptions:

Management Group Hierarchy:
└── Root Management Group
    ├── Policy: Corporate baseline (network, tagging, compliance)
    ├── Production Management Group
    │   ├── Policy: Require PTU for OpenAI deployments
    │   ├── Policy: Block preview models
    │   └── Subscriptions: Prod-EU, Prod-US
    │
    ├── Non-Production Management Group
    │   ├── Policy: Allow all models
    │   ├── Policy: Auto-shutdown idle resources
    │   └── Subscriptions: Dev, Test, Staging
    │
    └── Sandbox Management Group
        ├── Policy: Spending cap = 10 000 NOK/month per sub
        └── Subscriptions: Sandbox-Team-A, Sandbox-Team-B

Offentlig sektor (Norge)

Budsjettprosesser og statlig økonomistyring

Offentlige virksomheter i Norge opererer under ettårlige budsjetter (statsbudsjettet) med strenge krav til budsjettstyring og periodisering. AI-kostnader må håndteres innenfor dette rammeverket:

Utfordringer for AI-kostnadsstyring i offentlig sektor:

1. Uforutsigbarhet: AI-forbruk kan variere kraftig (spesielt consumption-based), vanskelig å budsjettere nøyaktig
2. Årsavgrensning: Kostnader må periodiseres korrekt (påløpt kostnad i riktig regnskapsår)
3. Bindingsregler: Ikke lov å overskride bevilgning uten Stortingets godkjenning
4. Detaljert rapportering: Krav om presise kapittel/post-fordelinger

Anbefalt approach:

Fase	Tiltak
Budsjettplanlegging	Bruk PTU-modeller for forutsigbarhet, inkluder 20% buffer for uforutsett vekst
Løpende styring	Månedlige avstemminger mot budsjett, eskalering ved 80% forbruk
Årsavslutning	Freeze på nye deployments siste 2 uker av året for å sikre korrekt periodisering
Rapportering	Automatisert cost export → integrasjon med økonomisystem (e.g., Agresso, SAP)

Budsjettpost-struktur (eksempel):

Kapittel: Drift av IT-systemer
├── Post 01: Driftsutgifter, lønn og sosiale utgifter
│   └── (ikke AI-relatert)
├── Post 21: Spesielle driftsutgifter
│   ├── Azure AI Foundry - PTU (fast månedlig kostnad)
│   └── Azure AI Foundry - consumption (variabel kostnad)
└── Post 45: Større utstyrsanskaffelser og vedlikehold
    └── (ikke relevant for cloud AI)

Internkontroll (IKS) og kostnadsstyring

Offentlige virksomheter må ha internkontroll for økonomistyring (jf. økonomiregelverket). For AI-kostnader innebærer dette:

IKS-krav som påvirker cost governance:

1. Rolleseparering: Person som deployer AI-tjeneste skal ikke være samme som godkjenner kostnad
2. Dokumentasjon: Alle quota-forhøyelser må dokumenteres med saksnummer og begrunnelse
3. Etterfølgende kontroll: Månedlig kontroll av faktisk vs. budsjettert forbruk
4. Avviksrapportering: Kostnadsavvik >10% skal rapporteres til leder og økonomiavdeling

Implementering i Azure AI Foundry:

• Rolleseparering: Utviklere får kun "Reader" rolle på subscription, må be Platform Team (Contributor) om quota-endringer
• Dokumentasjon: Quota requests integreres med ITSM (ServiceNow/Jira) → saksnummer required
• Kontroll: Automated monthly cost report → sendes økonomiansvarlig for review
• Avviksrapportering: Azure Monitor alert ved >110% av månedlig budsjett → eskaleres til IT-leder

Riksrevisjonen og kontrollspor

Riksrevisjonen kan kreve dokumentasjon på offentlige IT-kostnader. For AI-forbruk betyr dette:

Hva Riksrevisjonen kan be om:

• Fullstendig kostnadsspor: Hvilke prosjekter konsumerte AI-ressurser?
• Anskaffelsesgrunnlag: Hvorfor ble Azure AI Foundry valgt? (konkurransegrunnlag, vurdering av alternativer)
• Kostnadseffektivitet: Dokumentasjon på at man har optimalisert kostnader
• Sikkerhet og personvern: Inkl. kostnader knyttet til disse tiltakene

Beredskapstiltak for AI Foundry:

1. Tagging for revisjon: Alle ressurser skal tagges med:

   • Prosjektnummer: [prosjekt-ID]
   • Anskaffelse: [anskaffelsessak-ID]
   • Formål: [kort beskrivelse]

2. Cost allocation reports: Eksporteres månedlig til arkiv (minimum 5 år oppbevaringstid)

3. Beslutningsdokumentasjon: ADR (Architecture Decision Records) for:

   • Valg av modeller (hvorfor gpt-4o vs. alternativer?)
   • Valg av PTU vs. consumption
   • Quota-nivåer (begrunnelse for valgt størrelse)

4. Optimeringstiltak dokumenteres:

   • Quarterly review-rapporter som viser kostnadstrender og tiltak
   • Eksempel: "Migrerte 3 workloads fra gpt-4o til gpt-4o-mini → besparelse 40%"

DFØ (Direktoratet for forvaltning og økonomistyring)

DFØ gir veiledning for økonomistyring i staten. Relevant for AI-kostnadsstyring:

DFØ-prinsipper tilpasset AI Foundry:

1. Kostnadsbevissthet: Teams skal ha synlighet i egne kostnader (→ implementer self-service dashboards)
2. Ansvarliggjøring: Tydelig eierskap til hver AI-deployment (→ enforce Owner-tag)
3. Effektivitet: Kontinuerlig optimering av ressursbruk (→ quarterly optimization reviews)
4. Sammenlignbarhet: Benchmark mot andre virksomheter (→ deltakelse i DFØ-nettverk for AI-kostnader)

Rapportering til DFØ (hvis påkrevd):

Noen sektorer må rapportere IT-kostnader til DFØ. Forbered data:

• Total AI-kostnad per år (splittet consumption vs. PTU)
• Kostnadsutvikling (år-over-år sammenligning)
• Ressursutnyttelse (quotas allokert vs. faktisk brukt)

Eksempel-rapport til DFØ:

Virksomhet: Statens vegvesen
Periode: 2025

Azure AI Foundry:
- Total kostnad: 2 400 000 NOK
  • PTU (fast): 1 800 000 NOK (75%)
  • Consumption: 600 000 NOK (25%)
- Antall produksjonsworkloads: 12
- Gjennomsnittlig quota-utnyttelse: 73%
- Optimeringstiltak gjennomført: 8
- Estimert besparelse fra optimering: 320 000 NOK (11.8%)

Kostnad og lisensiering

Governance Tool Costs

Selve governance-verktøyene i Azure AI Foundry er stort sett inkludert uten ekstra kostnad:

Tool	Cost	Notes
Quota Management UI	Free	Built into AI Foundry portal
Azure Cost Management	Free	For supported account types (EA, MCA, etc.)
Azure Policy	Free	No charge for policy evaluation
Azure Monitor alerts	~0.10 USD per alert rule per month	Minimal cost for typical setup
Log Analytics	Pay-as-you-go (data ingestion)	~2.30 USD per GB ingested
Cost Exports to Storage	Storage costs only	Minimal (~few KB per day)
Azure APIM (optional)	From ~40 EUR/month (Consumption tier)	Only if using gateway pattern

Typisk governance-kostnad for medium organization (100-500 brukere):

Monthly governance overhead:
• Azure Monitor alerts (10 rules): ~1 EUR
• Log Analytics (5 GB/month ingestion): ~10 EUR
• Storage for cost exports: <1 EUR
• APIM Consumption tier (if used): ~40 EUR
────────────────────────────────────────
Total: ~52 EUR/month (~550 NOK/måned)

Dvs. governance-overhead er typisk <1% av total AI-kostnad

Savings Potential

Potensial besparelse fra god cost governance:

Tiltak	Typisk besparelse	Effort
Cleanup av ubrukte deployments	15-25%	Low (automated)
Migrering til riktig billing model (PTU vs. consumption)	20-40%	Medium (requires workload analysis)
Right-sizing quotas (eliminere over-provisioning)	10-15%	Low (monthly review)
Model optimization (bruk billigere modeller hvor mulig)	30-50%	High (requires testing)
Smart routing via APIM gateway	25-35%	High (infrastructure change)
Dynamic quota for batch workloads	10-20%	Low (enable feature)

Real-world eksempel (norsk offentlig virksomhet):

Utgangspunkt (Q1 2025):
• Total AI-kostnad: 150 000 NOK/måned
• 12 gpt-4o deployments, alle pay-as-you-go
• Ingen quotas, ingen tagging, minimal monitoring

Etter 6 måneders governance-implementering (Q3 2025):
• Total AI-kostnad: 95 000 NOK/måned
• 8 gpt-4o deployments (4 konsolidert), 4 migrert til gpt-4o-mini
• 5 workloads flyttet til PTU (stable baseline)
• Automated cleanup → 3 "glemte" test-deployments fjernet

Besparelse: 55 000 NOK/måned (37% reduksjon)
ROI på governance-implementering: <3 måneder

Cost Optimization Tips (Konkrete Tips)

1. Batch Processing Optimization:

For workloads som ikke er latency-sensitive (e.g., nattlige rapporter, bulk email-generering):

• Bruk dynamic quota for å opportunistisk bruke ledig kapasitet
• Kjør batch jobs utenfor business hours (mindre konkurranse om quota)
• Vurder Batch API (når tilgjengelig) som ofte har lavere pricing

2. Model Selection Matrix:

Use Case	Avoid	Prefer	Savings
Simple classification	gpt-4o	gpt-4o-mini	80% lower cost
JSON extraction	gpt-4o	gpt-4o-mini	80% lower cost
Semantic search embeddings	text-embedding-ada-002 (if overkill)	Check if smaller embedding models available	Varies
Complex reasoning	gpt-4o-mini	gpt-4o	(don't downgrade here)

3. Quota Right-Sizing Formula:

Optimal Quota = (Peak TPM observed * 1.2) + Buffer for growth

Example:
• Observed peak over 30 days: 1.2M TPM
• Safety margin (20%): 1.2M * 1.2 = 1.44M TPM
• Recommended quota: 1.5M TPM (round up)

Current allocation: 3M TPM
→ Reduce quota by 50% → frees up quota for other projects

4. PTU Break-Even Calculator:

Break-even point = Fixed PTU cost / (consumption cost per million tokens * expected monthly tokens)

Example (gpt-4o):
• PTU cost: 15 000 NOK/month (1 PTU, hypothetical)
• Consumption cost: 0.60 NOK per 1K tokens = 600 NOK per 1M tokens
• Expected usage: 30M tokens/month

Consumption cost if pay-as-you-go: 30M * 0.60 / 1000 = 18 000 NOK/month
PTU cost: 15 000 NOK/month

Savings with PTU: 3 000 NOK/month (17% reduction)

Tommelfingerregel: PTU lønner seg når forbruk er >80% av quota capacity, konsistent over tid.

For arkitekten (Cosmo)

Spørsmål å stille klienten

1. Økonomisk modenhet:

   • "Har dere eksisterende FinOps-praksis for cloud-kostnader, eller er dette første gang dere skal håndtere consumption-based AI-kostnader?"
   • "Hva er organisasjonens risikotoleranse for budsjettsprekksprekk? (Hvor kritisk er det med forutsigbare månedlige kostnader?)"

2. Organisasjonsstruktur:

   • "Hvordan er ansvaret for AI-kostnader fordelt? (Sentralt IT-budsjett vs. chargeback til forretningsenheter?)"
   • "Hvem skal ha ansvar for å godkjenne quota-forhøyelser? (IT, finans, eller forretningseier?)"

3. Workload-karakteristikk:

   • "Kan dere beskrive topp 3 AI-workloads deres?" (→ identifiser PTU-kandidater)
   • "Hvor kritisk er forutsigbar ytelse vs. kostnadskontroll for hver workload?"

4. Compliance og regulering:

   • "Er dere underlagt spesifikke regulatoriske krav for kostnadsstyring?" (Offentlig sektor, børsnotert, etc.)
   • "Trenger dere revisjonsspor for AI-kostnader?" (→ påvirker tagging og logging strategy)

5. Teknisk kapasitet:

   • "Har dere folk med kompetanse på Azure Policy, ARM templates, eller Infrastructure as Code?" (→ avgjør hvor mye automation som er realistisk)
   • "Bruker dere allerede Azure landing zones eller management groups?" (→ kan leverage eksisterende governance struktur)

6. Fremtidig vekst:

   • "Hva er forventet vekst i AI-forbruk de neste 12 månedene?" (10x? 2x? Flat?)
   • "Planlegger dere å ekspandere til flere regioner?" (→ påvirker multi-region quota strategy)

7. Existing challenges:

   • "Har dere opplevd quota exhaustion eller uventede kostnader tidligere?"
   • "Hva er største bekymring rundt AI-kostnader akkurat nå?"

8. Decision-making speed:

   • "Hvor raskt trenger team å kunne øke quotas?" (Samme dag? 1 uke SLA?)
   • "Hvor mye godkjenningsprosess tåler organisasjonen før innovasjonstakten bremses?"

Fallgruver og røde flagg

Anti-patterns å advare mot:

1. "Vi setter bare quota til max og ser hva som skjer"

   • Problem: Ingen økonomisk kontroll, team over-provisioner "for sikkerhets skyld"
   • Konsekvens: 30-50% higher costs enn nødvendig
   • Løsning: Start konservativt, øk basert på faktisk bruk

2. "Vi bruker kun budgets uten quotas"

   • Problem: Budgets stopper ikke forbruk, kun varsler
   • Konsekvens: Team får quota exhaustion midt i måned, ELLER bruker for mye fordi det ikke er teknisk begrensning
   • Løsning: Kombiner budgets (økonomisk) + quotas (teknisk) + policies (governance)

3. "Vi gir alle Contributor-tilgang for å slippe overhead"

   • Problem: Ingen kontroll, alle kan deploye uten godkjenning
   • Konsekvens: Shadow AI-tjenester, ingen cost allocation, compliance-problemer
   • Løsning: Least privilege, bruk Reader default + automation for godkjenningsflyt

4. "Vi setter opp governance men kommuniserer det ikke til utviklere"

   • Problem: Policies blokkerer utviklere uten at de forstår hvorfor
   • Konsekvens: Frustrasjon, workarounds, shadow IT
   • Løsning: Tydelig dokumentasjon, self-service portaler, synlig escalation path

5. "Vi implementerer hard-limit automation som stopper produksjon ved 100% budsjett"

   • Problem: Business-kritisk AI-tjeneste går ned midt i arbeidstid fordi budsjettet ble nådd
   • Konsekvens: Revenue loss, reputasjonsskade, stress
   • Løsning: Hard limits kun for non-production, produksjon har alerts + manual intervention

6. "Vi har ikke skilt dev/test/prod subscriptions"

   • Problem: Eksperimentering i dev bruker quota som prod trenger
   • Konsekvens: Produksjonsworkload throttles pga. dev-aktivitet
   • Løsning: Separate subscriptions med egne quotas, eller dedikert quota allocation per environment

Anbefalinger per modenhet

Modenhetsnivå 1: Initial (Ingen eksisterende governance)

Akseptansekriterier:

• Organisasjonen har nettopp startet med AI Foundry
• Ingen etablerte FinOps-prosesser
• 1-5 AI-workloads i produksjon

Anbefalt approach:

1. Uke 1-2: Visibility

   • Implementer tagging (mandatory: CostCenter, Environment, Owner)
   • Sett opp Azure Cost Management + weekly email reports
   • Opprett ett samlet budget på subscription-nivå

2. Uke 3-4: Basic Controls

   • Sett konservative quotas basert på current usage * 2
   • Opprett alerts ved 75% og 90% quota utilization
   • Dokumenter escalation path for quota requests

3. Måned 2-3: Process

   • Etabler monthly cost review (30 min møte med IT + finance)
   • Start quota right-sizing (identifiser over-provisioned deployments)
   • Pilot PTU for 1-2 stable workloads

KPIs for modenhet 1 → 2:

• 100% tagging compliance
• <20% kostnadsspredning mellom måneder
• Zero quota exhaustion incidents
• Monthly cost reviews gjennomført 3 måneder på rad

---

Modenhetsnivå 2: Managed (Basic governance på plass)

Akseptansekriterier:

• Tagging og budgets på plass
• Månedlige cost reviews fungerer
• 5-20 AI-workloads i produksjon

Anbefalt approach:

1. Automation:

   • Implementer automated cleanup av idle deployments (>14d uten bruk)
   • Azure Policy for model restrictions (e.g., block preview in production)
   • Automated quota requests via self-service portal (e.g., ServiceNow integration)

2. Chargeback:

   • Implementer cost allocation per business unit (via tagging)
   • Monthly chargeback reports til BU-ledere
   • Incentivize savings (BUs keep 50% of optimization savings)

3. Optimization:

   • Quarterly deep-dive: Workload-by-workload cost/benefit analysis
   • Identify PTU migration candidates (>5M tokens/month, stable)
   • Model substitution testing (can gpt-4o-mini replace gpt-4o for specific tasks?)

KPIs for modenhet 2 → 3:

• >30% av workloads på PTU (hvis applicable)
• <10% month-over-month cost variance (better predictability)
• Automated quota requests (<4 hour SLA)
• Documented cost optimization per quarter (savings target: >15%)

---

Modenhetsnivå 3: Optimized (Advanced FinOps for AI)

Akseptansekriterier:

• Mature governance + automation
• 20+ AI-workloads
• Multi-region, multi-subscription

Anbefalt approach:

1. Advanced Analytics:

   • ML-based anomaly detection for cost spikes (Azure Monitor + custom analytics)
   • Predictive modeling for quota demand (forecast 3 months ahead)
   • Total Cost of Ownership (TCO) tracking inkl. governance overhead

2. Platform Engineering:

   • Azure APIM gateway for smart routing (cost-based + latency-based)
   • Custom quota management portal (beyond native Azure UI)
   • Integration med CI/CD: Cost estimation i pull requests (preview cost impact av endringer)

3. Continuous Optimization:

   • A/B testing for model selection (measure quality vs. cost tradeoff)
   • Dynamic quota reallocation (ML-driven, adjusts quotas based on demand patterns)
   • Benchmarking mot industry standards (e.g., "cost per customer interaction")

KPIs for sustained excellence:

• <5% month-over-month variance
• >40% savings vs. unoptimized baseline
• Zero manual quota approvals (100% automated for requests <2M TPM)
• Cost-per-AI-transaction trending downward YoY

---

Kilder og verifisering

Microsoft Learn (Verified via MCP):

1. Govern Azure platform services (PaaS) for AI URL: https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/ai/platform/governance Confidence: Verified (Feb 2026) — Comprehensive governance framework, 8-step cost governance process

2. Manage and increase quotas for hub resources URL: https://learn.microsoft.com/en-us/azure/ai-foundry/how-to/hub-quota Confidence: Verified (Feb 2026) — Quota management UI, VM quota, model quota allocation

3. Plan and manage costs for Microsoft Foundry URL: https://learn.microsoft.com/en-us/azure/ai-foundry/concepts/manage-costs Confidence: Verified (Feb 2026) — Budget creation, cost monitoring, RBAC for cost visibility

4. Azure OpenAI Dynamic quota (Preview) URL: https://learn.microsoft.com/en-us/azure/ai-foundry/openai/how-to/dynamic-quota Confidence: Verified (Feb 2026) — When to use dynamic quota, cost implications

5. Consolidated view for Foundry Tools in the Azure portal URL: https://learn.microsoft.com/en-us/azure/ai-foundry/concepts/ai-foundry-consolidated-view Confidence: Verified (Feb 2026) — Dashboard for costs, quota utilization, alerts

6. Azure OpenAI quotas and limits URL: https://learn.microsoft.com/en-us/azure/ai-foundry/openai/quotas-limits Confidence: Verified (Feb 2026) — Model-specific TPM/RPM limits by tier

7. Azure OpenAI in Azure AI Foundry Models quota management URL: https://learn.microsoft.com/en-us/azure/ai-foundry/openai/how-to/quota Confidence: Verified (Feb 2026) — Quota view, request increases, migrating deployments

8. Manage AI costs (Cloud Adoption Framework) URL: https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/ai/manage#manage-ai-costs Confidence: Verified (Feb 2026) — Monthly reviews, model selection optimization

9. Microsoft Foundry rollout across organization (Governance section) URL: https://learn.microsoft.com/en-us/azure/ai-foundry/concepts/planning#governance Confidence: Verified (Feb 2026) — Azure Policy for model access, TPM limits at deployment level

10. Azure API Management generative AI gateway capabilities URL: https://learn.microsoft.com/en-us/azure/api-management/genai-gateway-capabilities Confidence: Verified (Feb 2026) — Gateway controls for cost management

Code Samples (MCP):

11. Azure Quota Management client library (Python) URL: https://learn.microsoft.com/en-us/python/api/overview/azure/mgmt-quota-readme Confidence: Verified — Programmatic quota management

12. Cognitive Services account usage retrieval (Azure CLI) URL: https://learn.microsoft.com/en-us/azure/ai-services/multi-service-resource Confidence: Verified — az cognitiveservices account list-usage command

Baseline Knowledge (Model Training Data):

13. Offentlig sektor Norge — økonomistyring Confidence: Baseline — DFØ principles, Riksrevisjonen audit requirements, statsbudsjett-prosesser (Basert på generell kunnskap om norsk offentlig forvaltning, ikke spesifikk MCP-kilde)

14. Cost optimization patterns Confidence: Baseline — TCO analysis, break-even calculations, PTU vs. consumption tradeoffs (Basert på generelle FinOps-prinsipper)

---

Confidence Summary per Section:

Section	Confidence Level	Notes
Quota Management	Verified	Directly from Microsoft Learn quota docs
Budget Controls	Verified	Azure Cost Management official docs
Azure Policy	Verified	CAF governance guidance
Cost Monitoring	Verified	Consolidated view + cost analysis docs
Dynamic Quota	Verified	Preview feature documentation
Architecture Patterns	Baseline	Synthesized from best practices, not single source
Decision Guidance	Baseline	Derived from governance principles + experience
Azure Integration (Policy, Monitor, APIM)	Verified	Official docs for each service
Offentlig sektor Norge	Baseline	No specific MCP source for Norwegian public sector
Cost & Licensing	Verified (pricing) + Baseline (optimization tips)	Pricing from Learn, tips synthesized
For arkitekten	Baseline	Advisory guidance, not documented feature

Total MCP Calls: 4 (3x microsoft_docs_search, 1x microsoft_docs_fetch, 1x microsoft_code_sample_search) Unique Source URLs: 12 (Microsoft Learn verified) Baseline sections: 4 (Architecture patterns, Norwegian public sector, decision guidance, advisory)