ms-ai-architect/skills/ms-ai-security/references/cost-optimization/budget-forecasting-ai-projects.md
Kjell Tore Guttormsen 35ac933590 feat(ms-ai-architect): #29 ratifisert — filstorrelse-feltet er selv-invaliderende, og klassen var 3 ikke 1 [skip-docs]
idx-26u og idx-26v anvendt, footeren i azure-cost-management-ai.md lukket.

#29 ER EN NY FORM, IKKE EN ARV. idx-26u paastod selv at sletting «follows
from an existing ratification rather than requiring a new one» (idx-26j).
Premisset ble maalt og forkastet: #22s referent-test naar ikke en
filstorrelse i noen retning — delete-siden hviler paa at ingenting kan
adjudisere paastanden, og git adjudiserer denne eksakt; keep-siden er «a
count of sources, URLs or documents the file itself lists», og en byte-
storrelse teller ingenting fila lister. Samme arve-type ble forkastet to
ganger forrige okt.

TRE GRUNNER, hver maalt: (1) ingen del av linja er sann, saa #28 sender
saken videre til #24 i sine egne ord; (2) sletting koster ingen sann
informasjon; (3) den eneste tilgjengelige reparasjonen er selv-
invaliderende — «~18 KB» blir usann ved neste edit, altsaa aa forfatte
en fremtidig instans av defektklassen man lukker.

KLASSEN BLE MAALT FOER SPORSMAALET BLE STILT — steget idx-26j sitt
scope-addendum sa manglet da booking stoppet paa 7 av 21. Kun idx-26u var
bookfoert, men «**File size:**» stod i TRE filer:
  azure-cost-management-ai.md:295            ~14 KB mot 18499 B (18.0 KB, 29 %)
  budget-forecasting-ai-projects.md:530      ~14 KB mot 20001 B (19.5 KB, 39 %)
  agent-evaluation-testing-frameworks.md:565 ~29 KB mot 27864 B (27.2 KB, 6.6 %)
Den tredje er forsvarlig under tilden og ble slettet likevel, fordi
operatoren ratifiserte grunnlaget «felt-typen», ikke «feilens storrelse».
Bookfoert som idx-26au + idx-26av, begge lukket i samme okt.

idx-26v SLETTET PAA EGEN GRUNN, ikke #29 og ikke #28 — #28s egen grense
sier at en telling som bare er uverifiserbar, ikke maalbart gal, fortsatt
er idx-26j-klassen. Avviket fra idx-26j, som ERSTATTET sin instans, er
begrunnet i maaling: 26j hadde en partisjon aa telle (12/5), denne fila
har ingen. Kildetabellen er 8/8 Verified (100/0), seksjonstabellen 3/3
(50/50). «3 av 6 seksjoner» ville oppfunnet en nevner og byttet paastand.

NABO BOOKFOERT VED EDIT-STEDET, IKKE SLETTET: «- **Word count:** ~3200 ord»
(:564, maalt 3374 — 5.2 % feil) sto rett over den slettede linja og er
trolig samme klasse, men var ikke i ratifiseringssporsmaalet. AA utvide
#29 dit ville vaert den stille utvidelsen #22 og #26 begge nektet.
Bookfoert AAPEN som idx-26aw; eneste ordtellings-felt i korpuset.

KEEP-NABOENE MAALT, IKKE ANTATT — alle tre sanne under #28s /en-us/-
normalisering (8 av 9, 8 av 9, 10 av 11). «**Document metadata:**»
beholdt uendret per #22s label-regel (navngir innhold, ikke generasjon).

Korrigert i idx-26u sin egen evidens: «working tree = 18554» var utdatert
(30d4340 rort fila etterpaa), faktisk 18499. Konklusjonen uendret.

Ko: 57 entries (10 aapne, 47 resolved). Suite 1052/1052. Hel-linje-bevis:
alle fire slettede linjer 0 forekomster korpus-bredt, alle bevarte 1x.

[skip-docs]: ingen brukerrettet doc-impact. Kun linjer slettet inne i
eksisterende ref-filer — ref-docs er fortsatt 389, saa README-badgen og
CLAUDE.md-tellingen staar uendret. Ingen ny kommando, agent, skill eller
hook.
2026-08-12 22:07:26 +02:00

529 lines
20 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Budget Forecasting and Financial Planning for AI
**Last updated:** 2026-06-19
**Status:** GA
**Category:** Cost Optimization & FinOps for AI
**Type:** reference
**Source:** https://learn.microsoft.com/azure/foundry/concepts/manage-costs
---
## Innhold
- [Introduksjon](#introduksjon)
- [Kjernekomponenter](#kjernekomponenter)
- [Arkitekturmønstre](#arkitekturmønstre)
- [Beslutningsveiledning](#beslutningsveiledning)
- [Integrasjon med Microsoft-stakken](#integrasjon-med-microsoft-stakken)
- [Offentlig sektor (Norge)](#offentlig-sektor-norge)
- [Kostnad og lisensiering](#kostnad-og-lisensiering)
- [For arkitekten (Cosmo)](#for-arkitekten-cosmo)
- [Kilder og verifisering](#kilder-og-verifisering)
## Introduksjon
Budget forecasting og finansiell planlegging er kritiske disipliner for AI-prosjekter i Microsoft-stakken. Mens tradisjonell IT-budsjettforing opererer med forutsigbare kapasitetsmodeller, introduserer AI-arbeidsbelastninger nye utfordringer: token-basert forbruk, uforutsigbare skaleringsmønstre, og kostnadsvarians knyttet til modellvalg og treningsfrekvens.
Effektiv forecasting for Azure OpenAI, Microsoft Foundry og tilhørende tjenester krever en hybrid tilnærming som kombinerer historisk trendanalyse, kapasitetsplanlegging og kontinuerlig justering basert på faktisk forbruk. Ifølge FinOps Framework-anbefalinger fra Microsoft ligger målet på <12% varians mellom forecast og faktisk kostnad ved normale bruksmønstre, og 12-20% varians ved inkludering av anomalier.
For offentlig sektor i Norge innebærer dette en ekstra kompleksitet: årlige budsjettmandater, statsbudsjettet sitt årlige rytme, og krav til budsjettdisiplin i henhold til DFØ-regelverk. AI-prosjekter må derfor balansere teknisk skalering med administrativ budsjettføring — ofte med behov for halvårsrevisjon og tilleggsbevilgninger.
---
## Kjernekomponenter
### Forecasting-metoder i Azure Cost Management
| Metode | Bruksområde | Tidsperspektiv | Presisjon |
|--------|-------------|----------------|-----------|
| **Native Cost Analysis Forecast** | Konsistent forbruk uten anomalier | 1-12 måneder | Høy ved stabile mønstre |
| **AutoML-basert forecasting** | Komplekse trender, sesongvariasjon | 3-24 måneder | Meget høy ved tilstrekkelig historikk |
| **Manual projection** | Nye arbeidsbelastninger, planlagte endringer | Variabel | Avhenger av ekspertinput |
| **Hybrid approach** | Enterprise-løsninger med flere komponenter | 6-36 måneder | Best practice for AI-prosjekter |
**Verified** — Microsoft Learn, Azure Cost Management dokumentasjon
### Budsjettdimensjoner for AI-prosjekter
AI-kostnader må segmenteres langs flere akser for nøyaktig forecasting:
| Dimensjon | Komponenter | Forecasting-metode |
|-----------|-------------|-------------------|
| **Compute** | Training (GPU hours), Inference (TPM/RPM), PTU hosting | Historisk + planlagt vekst |
| **Storage** | Training data, Model artifacts, Feature stores, Logging | Lineær vekst + retensjonspolicy |
| **Networking** | Data transfer, API calls, Cross-region replication | Forbruksbasert + traffic patterns |
| **Licensing** | Model APIs (token-cost), Fine-tuning, Commitment tiers | Kontraktsbasert + overage forecast |
| **Operational** | Monitoring, Log Analytics, Application Insights | Fast + % av total |
**Verified** — Microsoft Foundry Cost Management Guide
### Scenario-analyse for AI-budsjetter
Robust forecasting krever minimum tre scenarier:
| Scenario | Parametere | Bruk |
|----------|-----------|------|
| **Base case** | Historisk trend + kjente endringer | Budsjettgrunnlag |
| **Growth case** | +30-50% bruksvekst, nye features | Kapasitetsplanlegging |
| **Constraint case** | -20% budsjett, cost optimization | Risikostyring |
**Baseline** — FinOps best practices
---
## Arkitekturmønstre
### Mønster 1: Top-down budgetallokering
**Beskrivelse:** Organisasjonsnivå setter total AI-budsjett, deretter fordeling til teams/prosjekter.
**Implementering:**
1. Opprett budsjetter på subscription-nivå i Azure Cost Management
2. Bruk resource group tags for fordeling (project, cost-center, environment)
3. Implementer tag inheritance for automatisk scope
4. Sett budgetvarsler på 80%, 100% og 110% (forecasted threshold)
**Fordeler:**
- Enkel governance
- Klar finansiell kontroll
- Forutsigbarhet for CFO
**Ulemper:**
- Risiko for underallokering til høyverdi-prosjekter
- Manglende fleksibilitet ved uforutsette behov
**Bicep-eksempel for subscription budget:**
```bicep
targetScope = 'subscription'
param budgetName string = 'AI-Project-Q1-2026'
param amount int = 500000 // NOK 500k
param timeGrain string = 'Quarterly'
param startDate string = '2026-01-01'
param endDate string = '2026-03-31'
resource budget 'Microsoft.Consumption/budgets@2023-11-01' = {
name: budgetName
properties: {
timePeriod: {
startDate: startDate
endDate: endDate
}
timeGrain: timeGrain
amount: amount
category: 'Cost'
notifications: {
Warning: {
enabled: true
operator: 'GreaterThan'
threshold: 80
contactEmails: ['finans@example.no']
}
Critical: {
enabled: true
operator: 'GreaterThan'
threshold: 100
contactEmails: ['finans@example.no', 'ai-lead@example.no']
}
ForecastOverrun: {
enabled: true
operator: 'GreaterThan'
threshold: 110
contactEmails: ['finans@example.no']
thresholdType: 'Forecasted'
}
}
}
}
```
**Verified** — Microsoft Code Sample, Azure Cost Management Budget API
---
### Mønster 2: Bottom-up estimering
**Beskrivelse:** Teams estimerer behov basert på tekniske planer, aggregeres til total.
**Implementering:**
1. Bruk Azure Pricing Calculator for modellering av planlagt arkitektur
2. Estimer token-forbruk basert på forventet trafikk
3. Kalkuler training-kostnader (tokens × epochs × training price)
4. Legg til buffer (15-25%) for uforutsette behov
5. Aggreger og valider mot historisk trenddata
**Fordeler:**
- Høy presisjon ved godt definerte use cases
- Teknisk forankring
- Enklere å forsvare budsjettbehov
**Ulemper:**
- Risiko for overestimering (sandbagging)
- Tidkrevende prosess
**Formel for Azure OpenAI token-forecast:**
```
Månedlig kostnad = (Input tokens × Input pris) + (Output tokens × Output pris)
Eksempel (GPT-4o):
- 100M input tokens × $2.50/1M = $250
- 200M output tokens × $10.00/1M = $2000
- Total = $2250/mnd ≈ NOK 24 750 (kurs 11 NOK/USD)
```
**Verified** — Azure OpenAI Pricing Documentation
---
### Mønster 3: Hybrid med guardrails
**Beskrivelse:** Kombinerer top-down (total ramme) med bottom-up (teknisk plan) og dynamiske guardrails.
**Implementering:**
1. Sett overordnet budsjettramme (top-down)
2. Valider mot teknisk forecast (bottom-up)
3. Implementer automatiske kontroller:
- Azure Policy: Begrens VM SKUs til godkjente typer
- Quota limits per modell/region
- Auto-shutdown for dev/test-miljøer
- PTU commitment for forutsigbare arbeidsbelastninger
4. Månedlig reconciliation og forecast-justering
**Fordeler:**
- Balansert tilnærming
- Kontinuerlig forbedring
- Risikomitigering
**Ulemper:**
- Høyere administrasjonskostnad
- Krever modenhet i FinOps
**Best practice:** Dette er anbefalt tilnærming for enterprise AI-prosjekter.
---
## Beslutningsveiledning
### Når bruke hvilken forecasting-metode
| Situasjon | Anbefalt metode | Begrunnelse |
|-----------|----------------|-------------|
| Nytt AI-prosjekt, <3 mnd historikk | Manual projection + Azure Pricing Calculator | Manglende trenddata |
| Etablert workload, stabil trend | Native Cost Analysis forecast | Innebygd, rask, tilstrekkelig |
| Kompleks portefølje, sesongvariasjon | AutoML forecasting i Azure ML | Høyest presisjon |
| Offentlig sektor, årsbudsjett | Hybrid + kvartalsrevisjon | Tilpasning til årssyklus |
| Agile/ukjent vekst | Rolling 3-month forecast + budsjettbuffer | Fleksibilitet |
**Baseline** — FinOps Framework
### Vanlige feil i AI-budsjettforing
| Feil | Konsekvens | Mitigering |
|------|-----------|------------|
| Ignorere fine-tuning hosting cost | Ubudsjettert 24/7 hourly cost | Monitor deployments, delete inactive |
| Anta lineær kostnadsreduksjon ved model downgrade | Faktisk tap kan være marginal | Benchmark før beslutning |
| Ekskludere monitoring/logging fra forecast | 10-15% underbudsjettert | Alltid inkluder operational overhead |
| Bruke USD-priser uten valutabuffer | Valutarisiko (NOK/USD swap) | Legg til 5-10% valutabuffer |
| Filtrere ut anomalier uten dokumentasjon | Tapt læring for fremtidige forecasts | Logg alle justeringer |
**Baseline** — Empirisk observasjon
### Røde flagg i forecast
Disse signalene indikerer behov for forecast-revisjon:
- **>20% varians** mellom forecast og faktisk over 2 måneder
- **Hyppige anomalier** (>2 per måned) som ikke er forklart
- **PTU utilization <60%** — indikerer overprovisionering
- **Rapid model switching** — tyder på manglende strategi
- **Zero cost for monitoring** — urealistisk, sannsynligvis glemt
**Baseline** — FinOps KPIs
---
## Integrasjon med Microsoft-stakken
### Azure Cost Management + Budgets
**Capabilities:**
- Native forecasting (1-12 months)
- Budget alerts (actual & forecasted thresholds)
- Cost exports til Storage Account
- Anomaly detection (ML-basert)
- Tag-basert kostnadsoversikt
**Limitasjoner:**
- Ingen hard limits (kun varslinger) — krever custom automation for enforcement
- Forecast baseline krever minimum 10 dager historikk
- Kun subscription/resource group scope for budgets
**Integrasjon med AI-prosjekter:**
```python
# Python SDK for å hente cost forecast programmatisk
from azure.mgmt.costmanagement import CostManagementClient
from azure.identity import DefaultAzureCredential
credential = DefaultAzureCredential()
client = CostManagementClient(credential)
scope = f"/subscriptions/{subscription_id}"
# Forecast er tilgjengelig via Cost Analysis APIs
```
**Verified** — Azure Cost Management Python SDK
---
### Power BI + Cost Data Export
**Workflow:**
1. Sett opp daglig export av cost data til Storage Account
2. Opprett Power BI dataflow mot blob storage
3. Bygg custom forecast models i Power BI (exponential smoothing, trend lines)
4. Del rapporter med finance/management
**Fordeler:**
- Full kontroll over forecasting-modeller
- Integrasjon med andre finansdata
- Visuell dashboards for stakeholders
**Power BI Forecast Formula (DAX):**
```dax
ForecastedCost =
CALCULATE(
SUM(Costs[Amount]),
DATESINPERIOD(
Calendar[Date],
LASTDATE(Calendar[Date]),
3,
MONTH
)
) * 1.15 // 15% growth assumption
```
**Baseline** — Power BI forecasting patterns
---
### Azure Machine Learning AutoML
For enterprise-scenario med komplekse trender:
```python
from azure.ai.ml import automl
forecasting_job = automl.forecasting(
compute="cpu-cluster",
experiment_name="ai-cost-forecasting",
training_data=cost_history_data,
target_column_name="daily_cost",
primary_metric="normalized_root_mean_squared_error",
n_cross_validations="auto",
)
forecasting_job.set_forecast_settings(
time_column_name="date",
forecast_horizon=90, # 90 days ahead
country_or_region_for_holidays='NO' # Norge
)
```
**Verified** — Azure ML AutoML Code Sample
---
### FinOps Hubs + AI Copilot
Microsoft FinOps Hubs tilbyr AI-drevet forecasting via Azure Data Explorer KQL:
```kql
// Identifiser kostnadsspikes siste 3 måneder
CostDetails
| where TimeGenerated > ago(90d)
| where ServiceName == "Cognitive Services"
| summarize DailyCost = sum(CostInBillingCurrency) by bin(TimeGenerated, 1d)
| extend Anomaly = series_decompose_anomalies(DailyCost)
| where Anomaly > 1.5
```
**AI-agent over FinOps hubs (MCP 2026-06):** Du kan nå koble en AI-agent direkte til FinOps hub-databasen via **Azure MCP server** og stille naturlig-språk-spørsmål om allokering, forecasting, anomalier og rate-optimering — enten i **GitHub Copilot (Agent mode i VS Code)** med ferdige FinOps-instruksjoner, eller som en **Copilot Studio-agent** publisert til Teams/M365 Copilot. Agenten forstår FinOps + **FOCUS**-skjemaet (andre MCP-klienter som Claude kan også brukes). Eksempel: «Show me the cost for last month, this month, and the forecasted cost by end of month for the top subscriptions.»
**Verified** — FinOps Hubs Documentation
---
## Offentlig sektor (Norge)
### Statsbudsjettets årssyklus
Norsk offentlig sektor opererer med fast årsbudsjett vedtatt av Stortinget. AI-prosjekter må tilpasse forecasting til denne syklusen:
| Fase | Tidspunkt | AI-forecasting aktivitet |
|------|-----------|--------------------------|
| **Budsjettforslag** | Mai-juni | Leverere 18-måneders forecast for neste år + n+1 |
| **Budsjettvedtak** | November-desember | Finalisere allokering |
| **Q1 revisjon** | Mars | Justere forecast basert på Q4 faktisk |
| **Halvårsrevisjon** | Juni | Vurdere behov for tilleggsbevilgning |
| **Q3 checkpoint** | September | Forecast til årsslutt, planlegge carry-over |
| **Årsavslutning** | Desember | Unngå ubrukte midler (bruk-eller-tap) |
**Spesielle hensyn:**
- **Tilleggsbevilgninger** tar 3-6 måneder — forecasting må identifisere gap tidlig
- **Omprioriteringer** mellom kapitler krever politisk godkjennelse
- **DFØ-rapportering** krever månedsvis rapportering på KOSTRA-koder
**Baseline** — DFØ budsjettreglement
---
### Offentlige anskaffelser og commitment tiers
Azure commitment tiers (Provisioned Throughput Units) kan gi 30-50% besparelse, men krever binding:
**Dilemma for offentlig sektor:**
- Langsiktig binding (1-3 år) vs. årlige budsjetter
- Risiko for stranded commitment ved prosjektavslutning
- Anskaffelsesrettslige krav til konkurranse
**Løsning:**
- Bruk PTU commitment for stabile baseline-workloads
- Kombiner med pay-as-you-go for overflow (hybrid model)
- Inkluder exit-strategi i forecast (de-provisioning cost)
**Verified** — Azure OpenAI PTU Documentation
---
## Kostnad og lisensiering
### Verktøykostnader for forecasting
| Verktøy | Kostnad | Bruksområde |
|---------|---------|-------------|
| **Azure Cost Management** | Gratis (inkludert i subscription) | Baseline forecasting |
| **Power BI Pro** | NOK 110/bruker/mnd | Custom dashboards |
| **Azure ML (AutoML)** | Compute-basert (~NOK 50-200/run) | Advanced forecasting |
| **FinOps Hubs** | Gratis (infrastructure cost: ~$50-200/mnd) | Enterprise FinOps |
**Verified** — Azure Pricing
---
### Besparelsespotensiale
Korrekt forecasting driver kostnadsoptimalisering:
| Optimalisering | Typisk besparelse | Forecasting-rolle |
|----------------|-------------------|-------------------|
| **Riktig PTU-dimensjonering** | 20-40% | Identifisere stabil baseline |
| **Reserved Instances (VMs)** | 30-60% | Forutsi compute-behov |
| **Model right-sizing** | 10-30% | Benchmarke cost vs. performance |
| **Auto-shutdown dev/test** | 50-70% (non-prod) | Unngå zombie-resources |
| **Data retention optimization** | 15-25% | Forecast storage growth |
**Baseline** — Azure Well-Architected Cost Optimization
---
### Optimaliseringstips
1. **Bruk forecasted thresholds** — ikke bare actual — for proaktiv alerting
2. **Implementer chargeback** — allokere kostnader til forbrukende teams øker accountability
3. **Automatiser cost exports** — daglig dump til Storage gir fleksibilitet for custom analyse
4. **Kombiner commitment + consumption** — hybrid approach for kostnadskontroll
5. **Inkluder valutabuffer** — NOK/USD volatilitet kan ødelegge forecasts
---
## For arkitekten (Cosmo)
### Spørsmål å stille kunden
1. **Budsjettmodell:** "Opererer dere med fast årsbudsjett eller rullerende forecasts?"
2. **Historikk:** "Har dere 3+ måneder med AI-kostnadsdata, eller er dette greenfield?"
3. **Vekstambisjon:** "Forventer dere lineær vekst, eksponentiell, eller ukjent?"
4. **Risikotoleranse:** "Hva er konsekvensen av å overskride budsjettet — politisk, administrativ, teknisk?"
5. **Governance:** "Hvem har ansvar for forecasting — finance, IT, eller delt?"
6. **Tooling:** "Bruker dere allerede Power BI, Azure ML, eller andre forecasting-verktøy?"
7. **Compliance:** "Er dere underlagt offentlige budsjettregler (DFØ, statsbudsjettet)?"
8. **Commitment:** "Er dere villige til å binde dere til PTU/Reserved Instances for besparelser?"
---
### Fallgruver å unngå
- **Ekstrapolering uten validering** — ikke anta at siste måneds vekst fortsetter lineært
- **Ignorere sesongeffekter** — offentlig sektor har ofte Q4-rush (bruk budsjett før årsslutt)
- **Overvurdering av model downgrade-besparelser** — GPT-4 → GPT-3.5 gir ikke alltid 1:1 cost reduction (pga. kvalitetstap)
- **Glemme monitoring overhead** — Log Analytics, Application Insights kan være 10-15% av total
- **Statiske forecasts** — AI-prosjekter endrer seg raskt, revisjon hver måned er minimum
---
### Anbefalinger per modenhetsnivå
| Nivå | Kjennetegn | Anbefalt tilnærming |
|------|-----------|---------------------|
| **Nivå 1: Ad-hoc** | Ingen systematisk forecasting | Start med Azure Cost Management native forecast + månedlige budsjetter |
| **Nivå 2: Reaktiv** | Budsjetter finnes, men ofte overskredet | Implementer forecasted thresholds + anomaly alerts |
| **Nivå 3: Proaktiv** | Regelmessig forecast-revisjon | Legg til Power BI dashboards + scenario-analyse |
| **Nivå 4: Optimalisert** | Automatisert forecasting + chargeback | Integrer AutoML forecasting + FinOps Hubs |
| **Nivå 5: Prediktiv** | Forecasting driver arkitekturbeslutninger | AI-drevet cost optimization + continuous forecasting |
---
## Kilder og verifisering
### Microsoft Learn kilder (MCP-verified)
1. **FinOps Forecasting Capability**
https://learn.microsoft.com/en-us/cloud-computing/finops/framework/quantify/forecasting
*Confidence: Verified* — Komplett guide til forecasting i Azure
2. **Plan to Manage Costs for Azure OpenAI**
https://learn.microsoft.com/en-us/azure/foundry/concepts/manage-costs
*Confidence: Verified* — Token-basert pricing, forecasting, budgets
3. **Azure Cost Management - Create Budgets**
https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/tutorial-acm-create-budgets
*Confidence: Verified* — Budget alerts, forecasted thresholds
4. **Governance for AI Workloads**
https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/ai/infrastructure/governance
*Confidence: Verified* — Cost management for AI
5. **Azure ML AutoML Forecasting**
https://learn.microsoft.com/en-us/azure/machine-learning/how-to-auto-train-forecast
*Confidence: Verified* — Advanced forecasting med ML
6. **FinOps Hubs with AI**
https://learn.microsoft.com/en-us/cloud-computing/finops/toolkit/hubs/configure-ai
*Confidence: Verified* — KQL-basert cost forecasting
7. **Cost Optimization Design Principles for AI**
https://learn.microsoft.com/en-us/azure/well-architected/ai/design-principles
*Confidence: Verified* — Well-Architected Framework
8. **Fine-Tuning Cost Management**
https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/fine-tuning-cost-management
*Confidence: Verified* — Training + hosting + inference cost
---
### Konfidensnivå per seksjon
| Seksjon | Konfidens | Kilde |
|---------|-----------|-------|
| Kjernekomponenter | Verified | Microsoft Learn MCP |
| Arkitekturmønstre | Verified | Code samples + dokumentasjon |
| Beslutningsveiledning | Baseline | FinOps Framework + empiri |
| Microsoft-integrasjon | Verified | MCP-verified APIs og SDKs |
| Offentlig sektor | Baseline | DFØ-regelverk + norsk kontekst |
| Kostnad og lisensiering | Verified | Azure Pricing + dokumentasjon |
| For arkitekten | Baseline | Konsulenterfaringer + best practices |
---
**Unique sources:** 8 Microsoft Learn URLs