ms-ai-architect/skills/ms-ai-engineering/references/mlops-genaiops/model-evaluation-frameworks.md

Model Evaluation Frameworks and Metrics

Last updated: 2026-06-19 Status: GA Category: MLOps & GenAIOps Type: reference Source: https://learn.microsoft.com/azure/foundry/concepts/observability

---

Innhold

• Introduksjon
• Kjernekomponenter
• Arkitekturmønstre
• Beslutningsveiledning
• Integrasjon med Microsoft-stakken
• Offentlig sektor (Norge)
• Kostnad og lisensiering
• For arkitekten (Cosmo)
• Kilder og verifisering

Introduksjon

Evaluering av AI-modeller, spesielt generative AI-applikasjoner, krever en helt annen tilnærming enn tradisjonell maskinlæring. Mens tradisjonell ML fokuserer på deterministiske metrikker som accuracy og precision, må GenAI-evaluering håndtere multi-turn-samtaler, kontekstuell relevans, sikkerhet og subjektiv kvalitet. Microsoft tilbyr et omfattende rammeverk for modellevaluering gjennom Microsoft Foundry, Azure Machine Learning Prompt Flow og MLflow 3, som dekker hele utviklingsløpet fra modellvalg til produksjonsovervåking.

Evalueringsrammeverket støtter tre hovedfaser: base model selection (sammenligning av foundation models), pre-production evaluation (testing mot ground truth-datasett), og production monitoring (kontinuerlig kvalitetsvurdering med live data). Hver fase bruker en kombinasjon av matematiske metrikker (NLP-baserte), AI-assisterte metrikker (LLM-as-a-judge), og sikkerhetsvurderinger. Dette gir en helhetlig vurdering av modellens kapabiliteter, begrensninger og ansvarlighetsprofil.

Evalueringsprosessen er iterativ og datadrevet. Den starter med å etablere en baseline, velge relevante metrikker tilpasset use casen, kjøre evalueringer mot strukturerte datasett, analysere resultater på både aggregert og instansnivå, og deretter justere modell, prompt eller arkitektur basert på funnene. Riktig evaluering forhindrer kvalitetsregresjoner, identiferer edge cases før produksjonssetting, og gir objektive beslutningsgrunnlag for deployment.

Kjernekomponenter

Evalueringstyper (Microsoft Foundry)

Type	Metrikker	Krever ground truth?	Krever judge model?	Use case
AI Quality (AI-assisted)	Groundedness, Relevance, Coherence, Fluency, GPT similarity	Delvis (kun GPT similarity)	Ja (GPT-3.5+/GPT-4)	Subjektiv kvalitetsvurdering av generert innhold
AI Quality (NLP)	F1, ROUGE, BLEU, GLEU, METEOR	Ja	Nei	Sammenligning mot fasitsvar, tekstlikhet
Risk & Safety	Self-harm, Hateful content, Violence, Sexual content, Protected material, Indirect attack	Nei	Nei (Foundry-hosted GPT-4)	Content moderation og sikkerhetsvurdering

Evaluation Targets

Microsoft Foundry støtter tre evalueringsmål:

1. Model — Evaluer en modell-deployment med bruker-definert prompt mot et datasett (genererer svar on-the-fly).
2. Agent — Evaluer en agent (Copilot Studio, Microsoft Agent Framework) med strukturert reasoning og tool calls.
3. Dataset — Evaluer forhåndsgenererte svar (modell/agent-output allerede i datasettet).

Data Mapping-krav

Metrikk	Query	Response	Context	Ground Truth
Groundedness	✅ Required	✅ Required	✅ Required	❌
Coherence	✅ Required	✅ Required	❌	❌
Fluency	✅ Required	✅ Required	❌	❌
Relevance	✅ Required	✅ Required	✅ Required	❌
GPT similarity	✅ Required	✅ Required	❌	✅ Required
F1/BLEU/ROUGE/METEOR	❌	✅ Required	❌	✅ Required
Safety metrics	✅ Required	✅ Required	❌	❌

Code Example: Azure AI Evaluation SDK

import os
from azure.ai.evaluation import (
    evaluate,
    RelevanceEvaluator,
    CoherenceEvaluator,
    GroundednessEvaluator,
    ContentSafetyEvaluator
)
from azure.identity import DefaultAzureCredential

# Model config for LLM judge
model_config = {
    "azure_endpoint": os.getenv("AZURE_OPENAI_ENDPOINT"),
    "api_key": os.getenv("AZURE_OPENAI_API_KEY"),
    "azure_deployment": "gpt-4o",
    "api_version": "2024-06-01"
}

# Azure AI Project config for safety evaluators
azure_ai_project = os.getenv("AZURE_AI_PROJECT")  # https://{account}.services.ai.azure.com/api/projects/{project}

# Initialize evaluators
evaluators = {
    "relevance": RelevanceEvaluator(model_config=model_config),
    "coherence": CoherenceEvaluator(model_config=model_config),
    "groundedness": GroundednessEvaluator(model_config=model_config),
    "content_safety": ContentSafetyEvaluator(azure_ai_project=azure_ai_project, credential=DefaultAzureCredential())
}

# Run evaluation
result = evaluate(
    data="evaluation_data.jsonl",  # CSV or JSONL format
    evaluators=evaluators,
    evaluator_config={
        "relevance": {
            "column_mapping": {
                "query": "${data.query}",
                "response": "${data.response}",
                "context": "${data.context}"
            }
        },
        "groundedness": {
            "column_mapping": {
                "query": "${data.query}",
                "response": "${data.response}",
                "context": "${data.context}"
            }
        }
    },
    azure_ai_project=azure_ai_project,  # For tracking results in Foundry UI
    output_path="./evaluation_results.json"
)

# Access results
print(f"Average relevance: {result['metrics']['relevance']}")
print(f"Foundry URL: {result.get('studio_url')}")

MLflow 3 Evaluation & Monitoring

MLflow 3 Evaluation Framework (2026)

MLflow 3 provides the evaluation framework for both traditional ML and GenAI applications on Databricks:

Scorer types (unified interface for all evaluation):

Type	Customization	Use Case
Built-in judges	Minimal	Quick evaluation: Correctness, RetrievalGroundedness, Safety, RelevanceToQuery, Fluency, Equivalence — Verified (MCP 2026-04)
Guidelines judges	Moderate	Custom natural-language rules (pass/fail): Guidelines, ExpectationsGuidelines
Custom LLM judges	Full	Domain-specific criteria, detailed scoring
Code-based scorers	Full	Deterministic: exact match, format validation, business logic
Multi-turn judges	Minimal	Conversation-level: ConversationCompleteness, UserFrustration, KnowledgeRetention, ConversationalSafety — Verified (MCP 2026-04)

Key evaluation functions:

import mlflow

# Development evaluation
results = mlflow.genai.evaluate(
    data=eval_dataset,
    scorers=[RelevanceToQuery(), RetrievalGroundedness(), Correctness()]
)

# Production monitoring — same scorers as development
# Automatically applied to production traces

Judge accuracy: Databricks validates with Cohen's Kappa, accuracy, F1 score against human expert judgment.

Traditional ML evaluation (Azure ML):

• Data quality signals: null rate, out-of-bounds, type errors
• Statistical drift: Jensen-Shannon divergence, Wasserstein distance
• Custom metrics via Python scripts in monitoring jobs

MLflow 3 integrerer evaluering og production monitoring i én workflow. Samme LLM judges og scorers kan brukes i development, testing og production.

Hovedkomponenter:

• Tracing — Real-time logging av inputs, outputs, reasoning steps (via mlflow.trace()).
• LLM Judges — Databricks-hosted models (GPT-baserte) for quality assessment. Støtter også egne modeller.
• Scorers — Både built-in (Correctness, Relevance, Groundedness) og custom Python-baserte.
• Review App — UI for human feedback, genererer evaluation datasets.
• Production Monitoring — Automatisk kjøring av judges på production traces (kontinuerlig kvalitetsvurdering).

from mlflow.genai.scorers import Correctness, Relevance

# Use Databricks-hosted judge model (default)
correctness_judge = Correctness()

# Or specify custom model
correctness_judge = Correctness(model="databricks:/databricks-gpt-5-mini")

# Evaluate during development
mlflow.evaluate(
    model=my_rag_app,
    data=evaluation_dataset,
    scorers=[correctness_judge, Relevance()],
    extra_metrics=[mlflow.metrics.latency()]
)

Arkitekturmønstre

Mønster 1: Baseline-Evaluation-Iteration Loop

Når bruke: Kontinuerlig modell- og prompt-tuning under utvikling.

Fremgangsmåte:

1. Establish baseline — Kjør initial evaluering med flere metrikker (relevance, coherence, groundedness, safety).
2. Identify weaknesses — Analyser low-scoring samples (instansnivå, ikke bare aggregert score).
3. Hypothesize improvement — Juster prompt, model parameters, retrieval strategy, eller chunking.
4. Re-evaluate — Kjør samme evaluering, sammenlign metrics mot baseline.
5. Iterate — Gjenta til metrics møter target thresholds.

Fordeler:

• Objektivt beslutningsgrunnlag (ingen "gut feeling").
• Forhindrer regresjon (alle endringer måles).
• Dokumenterer forbedring over tid (versjonering i Foundry).

Ulemper:

• Krever strukturert dataset (manual curation eller synthetic generation).
• Tidkrevende for store datasets (bruk sampling).

Pitfall: Overfitting til evaluation dataset — sørg for at datasett representerer reelle bruksmønstre.

---

Mønster 2: Multi-Metric Decision Gate

Når bruke: Pre-production quality gate før deployment.

Fremgangsmåte:

1. Definer minimum thresholds per metrikk (f.eks. Groundedness ≥ 0.85, Relevance ≥ 0.80, Violence = 0).
2. Kjør full evaluering mot representative dataset (min. 100 samples).
3. Pass/Fail decision — Deployment tillates kun hvis ALL metrics møter thresholds.
4. Logg resultater i Foundry for audit trail.

Fordeler:

• Forhindrer deployment av usikre modeller.
• Balanserer flere kvalitetsdimensjoner (ikke bare én metrikk).
• Compliance-vennlig (dokumentert kvalitetssikring).

Ulemper:

• Kan blokkere deployment selv om én metrikk feiler.
• Threshold-valg er subjektivt og use case-avhengig.

Eksempel threshold-konfigurasjon:

Use Case	Groundedness	Relevance	Coherence	Safety (alle)
Customer support chatbot	≥ 0.90	≥ 0.85	≥ 0.80	= 0 (zero tolerance)
Internal RAG (dokumentasjon)	≥ 0.85	≥ 0.75	≥ 0.70	≤ 1 (low severity OK)
Creative content generation	≥ 0.70	≥ 0.65	≥ 0.80	= 0

---

Mønster 3: LLM-as-a-Judge for Multi-Turn Evaluation

Når bruke: Agentic workflows, multi-turn conversations, komplekse reasoning tasks.

Fremgangsmåte:

1. Bruk specialized judges (IntentResolutionEvaluator, TaskAdherenceEvaluator, ToolCallAccuracyEvaluator).
2. Pass hele samtalehistorikken til judge (ikke bare siste response).
3. Vurder både individual turn quality og conversation coherence.
4. Kombiner med traditional metrics (fluency, safety) for helhetlig vurdering.

Fordeler:

• Fanger opp kontekstuelle feil som enkeltmetrikker ikke ser.
• Kan vurdere reasoning quality (GPT-4o som judge).
• Skalerbar (judge kjører automatisk på batch data).

Ulemper:

• Judge model kan selv ha biases.
• Krever tuning av judge prompts for høy accuracy.
• Kostbart (LLM calls per evaluation sample).

Accuracy-validering av judges: Microsoft validerer judge quality gjennom:

• Cohen's Kappa agreement med human experts.
• F1 score, precision, recall mot gold standard datasets.
• Testing på både akademiske benchmarks og real-world data.

Beslutningsveiledning

Hvilke metrikker skal jeg bruke?

Scenario	Anbefalte metrikker	Rationale
RAG-applikasjon	Groundedness, Relevance, Coherence, Content Safety	Sørg for at svar er forankret i source data, relevant for query, og trygt.
Chatbot (customer support)	Relevance, Fluency, Task Adherence, Safety	Svar må være relevante, godt formulert, løse brukerens problem, og trygge.
Summarization	ROUGE, BLEU, Coherence, Fluency	Sammenlign mot human-written summaries (ground truth).
Agent (tool-calling)	Intent Resolution, Tool Call Accuracy, Task Adherence	Vurder om agent forstår intent, kaller riktige tools, og fullfører task.
Creative generation	Coherence, Fluency, GPT similarity (hvis referanse finnes), Safety	Kvalitet viktigere enn factual correctness.

Vanlige feil

Feil	Konsekvens	Hvordan unngå
Bruker kun én metrikk	Mister andre kvalitetsdimensjoner (f.eks. høy relevance, men unsafe content).	Bruk alltid 3-5 metrikker sammen.
Ikke ground truth	Kan ikke bruke NLP-metrikker (F1, ROUGE).	Kurater ground truth dataset (minst 50-100 samples).
Overfit til evaluation dataset	Modell performer dårlig på reelle brukere.	Inkluder edge cases, bruk synthetic data for variasjon.
Ignorerer instansnivå	Aggregated scores skjuler systematiske feil.	Analyser low-scoring samples individuelt.
Ingen baseline	Kan ikke måle om endringer forbedrer kvalitet.	Logg initial evaluation før enhver tuning.

Røde flagg (må undersøkes)

• Groundedness < 0.70 → Modellen hallusinerer, retrieval fungerer ikke.
• Safety score > 0 (når zero tolerance) → Blokkering nødvendig før deployment.
• High variance i metrikker (f.eks. 0.95 på noen samples, 0.30 på andre) → Dataset har edge cases som ikke håndteres.
• Groundedness høy, men Relevance lav → Retrieval returnerer irrelevante chunks (fix chunking/ranking).
• Coherence lav, men Fluency høy → Respons er språklig OK, men logisk inkonsistent (prompt issue).

Integrasjon med Microsoft-stakken

Microsoft Foundry Portal

• Evaluation page → UI for å opprette, kjøre og visualisere evalueringer.
• Model Catalog → Benchmarks → Sammenlign modeller mot public benchmarks eller egne data.
• Evaluator Library → Repository av Microsoft-kuraterte evaluators (med versjonering).
• Synthetic data generation → Generer test data hvis du mangler ground truth.

Azure Machine Learning Prompt Flow

Retirement 2027-04-20 (verifisert MCP 2026-06-19): Prompt Flow (Microsoft Foundry + Azure ML) pensjoneres 20. april 2027 og anbefales ikke for ny utvikling — migrer til Microsoft Agent Framework (MAF). Evaluation flows beskrevet under er fortsatt gyldige for eksisterende løsninger frem til fristen.

• Evaluation flows → Custom evaluation logic (Python nodes, LLM nodes).
• Batch run evaluation → Kjør flow mot dataset, samle scores.
• Metrics visualization → Compare runs, track improvements.

Azure AI Projects SDK (Cloud Evaluation)

from azure.ai.projects.models import (
    Evaluation,
    InputDataset,
    EvaluatorConfiguration,
    EvaluatorIds
)

# Define evaluators
evaluators = {
    "relevance": EvaluatorConfiguration(
        id=EvaluatorIds.RELEVANCE.value,
        init_params={"deployment_name": "gpt-4o"},
        data_mapping={"query": "${data.query}", "response": "${data.response}"}
    ),
    "violence": EvaluatorConfiguration(
        id=EvaluatorIds.VIOLENCE.value,
        init_params={"azure_ai_project": endpoint}
    )
}

# Create cloud evaluation
evaluation = Evaluation(
    display_name="Cloud evaluation",
    description="Evaluation of RAG agent",
    data=InputDataset(id=data_id),
    evaluators=evaluators
)

# Submit to cloud
evaluation_response = project_client.evaluations.create(evaluation)
print(f"Status: {evaluation_response.status}")

GitHub Actions Integration

• Offline evaluation i CI/CD → Kjør evaluering før merge/deployment.
• Foundry GitHub Action → Automated quality gate i pipeline.

Continuous Evaluation (Production)

from azure.ai.projects.models import (
    EvaluationRule,
    ContinuousEvaluationRuleAction,
    EvaluationRuleEventType
)

# Create continuous evaluation rule
continuous_eval_rule = project_client.evaluation_rules.create_or_update(
    id="my-continuous-eval-rule",
    evaluation_rule=EvaluationRule(
        display_name="Production Quality Monitoring",
        action=ContinuousEvaluationRuleAction(eval_id=eval_object.id, max_hourly_runs=100),
        event_type=EvaluationRuleEventType.RESPONSE_COMPLETED,
        filter=EvaluationRuleFilter(agent_name=agent.name),
        enabled=True
    )
)

Offentlig sektor (Norge)

GDPR og datasuverenitet

• Test data med personopplysninger → Må anonymiseres eller syntetiseres. Microsoft Foundry's synthetic data generation kan brukes.
• Evaluering i EU-regioner → AI-assisted safety metrics hosted kun i East US 2, France Central, UK South, Sweden Central. Velg France Central eller Sweden Central for norske virksomheter.
• Ground truth datasets → Hvis de inneholder sensitive data, må de lagres i GDPR-compliant storage (Azure Blob Storage med encryption at rest, managed identity, private endpoint).

AI Act og transparens

• Evaluationsresultater som dokumentasjon → EU AI Act krever dokumentasjon av risikovurderinger. Foundry evaluations gir audit trail (logg alle evalueringer med timestamps, metrics, data samples).
• LLM-as-a-judge transparency → Dokumenter hvilken judge model som brukes (GPT-4o, Databricks-hosted), og valider judge accuracy mot human experts (Cohen's Kappa).
• Safety evaluations → Obligatorisk for high-risk AI systems (customer-facing chatbots). Kjør safety metrics (violence, hate, self-harm) i pre-production.

Forvaltningsloven og etterprøvbarhet

• Versjonering av evaluations → Foundry Evaluator Library støtter versjonering. Logg hvilken versjon av evaluator som brukes per evaluation run.
• Beslutningsgrunnlag → Hvis AI-system brukes til vedtaksstøtte, må evaluation results kunne produseres som dokumentasjon (JSON export fra evaluate() funksjonen).

Dataklassifisering

Klassifisering	Evaluation data handling
Åpent	Kan bruke Azure OpenAI (Europe), Databricks-hosted judges.
Begrenset	Anonymiser før evaluering, bruk Microsoft Foundry med private endpoint.
Fortrolig	Kun self-hosted judges (deploy GPT-4o i eget subscription), ingen Databricks-hosted models.
Strengt fortrolig	Evaluering på-premises eller Azure confidential computing (ikke GA for LLM judges).

Kostnad og lisensiering

Pricing Model

Komponent	Prismodell	Estimat (NOK/1000 evalueringer, feb 2026)
NLP metrics (F1, ROUGE, BLEU)	Gratis (lokal compute)	0 kr
AI-assisted metrics (GPT-4o judge)	Per token (input + output)	300-800 kr (avhengig av prompt-lengde, response-lengde)
Safety metrics (Foundry-hosted GPT-4)	Gratis (hostet av Microsoft)	0 kr
Synthetic data generation	Per generated sample (GPT-4 tokens)	50-150 kr per 100 samples
Continuous evaluation (production)	Per evaluation run (judge LLM tokens)	Variabel (avhengig av traffic)

Kostnadsoptimalisering:

• Bruk NLP metrics hvor mulig (hvis ground truth finnes).
• Sample dataset (ikke evaluer alle 10 000 samples — 100-500 er ofte nok).
• Bruk mindre judge models (GPT-3.5-turbo) for non-critical evaluations.
• Cache evaluation results (samme data + samme evaluator = same score).
• Kombiner batch evaluation (offline) med sampled continuous evaluation (online).

Lisensiering

• Microsoft Foundry → Pay-as-you-go (ingen lisenskostnad for platform, betaler kun for compute/LLM tokens).
• Azure Machine Learning → Samme som over.
• MLflow 3 (Databricks) → Inkludert i Databricks-abonnement (Premium/Enterprise tier).
• Azure AI Evaluation SDK → Open source (MIT license), gratis å bruke.

Foundry PTU (Provisioned Throughput Units) for Judges

Hvis du kjører massive evalueringer (100K+ samples), vurder PTU for judge models:

• Forutsigbar kostnad (fast månedspris).
• Lavere latency (dedicated capacity).
• Break-even typisk rundt 10M tokens/måned.

For arkitekten (Cosmo)

Kritiske spørsmål å stille

1. Hva er success criteria for modellen? (F.eks. "90% groundedness, zero unsafe content"). Dette definerer hvilke metrikker og thresholds du trenger.
2. Har dere ground truth data? Hvis nei → bruk AI-assisted metrics. Hvis ja → kombiner NLP + AI-assisted for høyere confidence.
3. Hva er risikoprofilen? High-risk (customer-facing) → must have safety evaluations + human review. Low-risk (internal tool) → quality metrics holder.
4. Hvor ofte skal evaluering kjøres? Pre-deployment only, eller kontinuerlig i production? Dette påvirker arkitektur (batch vs. streaming evaluation).
5. Hva er budsjett for evaluering? Judge LLM tokens kan bli dyrt på store volumer — vurder sampling eller NLP metrics.
6. Skal evaluation results brukes i compliance/audit? Ja → sett opp versjonering, immutable logging (Azure Monitor, Application Insights).
7. Har dere edge cases som må testes? (F.eks. non-English queries, jailbreak attempts, domain-specific terminology). Standard datasets dekker ikke dette — må kureres manuelt.
8. Skal dere bruke pre-built evaluators eller custom? Pre-built er raskere, custom gir mer kontroll (men krever utvikling + vedlikehold).

Fallgruver

Fallgruve	Impact	Hvordan unngå
"Vi tester manuelt"	Ikke skalerbart, ikke reproducerbart.	Automatiser med Foundry evaluations fra dag 1.
"Vi bruker kun GPT-4 judge"	Dyrt, langsomt, ikke transparent.	Kombiner med NLP metrics (gratis, rask).
"Vi evaluerer kun pre-deployment"	Production drift går uoppdaget.	Sett opp continuous evaluation (sampling).
"Vi har ikke ground truth"	OK for AI-assisted metrics, men begrenset validering.	Invester i å kurere 50-100 ground truth samples (ROI er høy).
"Vi bruker samme dataset for tuning og testing"	Overfitting, falsk confidence.	Split dataset: 70% tuning, 30% holdout test.

Anbefalinger per modenhetsnivå

Nivå 1: PoC/MVP (1-2 måneder)

• Bruk Microsoft Foundry UI (no-code).
• Kjør 3-4 metrikker (Relevance, Coherence, Groundedness, Safety).
• Dataset: 20-50 manually curated samples.
• Threshold: Soft targets (ikke blokkering).

Nivå 2: Pre-production (3-6 måneder)

• Bygg til Azure AI Evaluation SDK (Python).
• Legg til NLP metrics (hvis ground truth finnes).
• Dataset: 100-200 samples (inkluder edge cases).
• Threshold: Hard gates (må passere før deployment).
• Logg resultater i Foundry for tracking.

Nivå 3: Production (6+ måneder)

• Implementer continuous evaluation (sampling 1-5% av production traffic).
• Integrer med CI/CD (GitHub Actions).
• Custom evaluators for domain-specific quality.
• Dataset: 500+ samples, versjonert, immutable.
• Alerting på metric degradation (Azure Monitor).
• Human-in-the-loop review for edge cases (MLflow Review App).

Kilder og verifisering

Microsoft Learn (Verified via MCP)

1. Evaluate generative AI models and applications by using Microsoft Foundry — Verified — Komplett guide til Foundry UI evaluations, metrics, data mapping.
2. Evaluation flows and metrics (Azure ML Prompt Flow) — Verified — Custom evaluation flows, aggregation nodes.
3. MLflow 3 Evaluation and Monitoring — Verified — LLM judges, scorers, production monitoring.
4. Large language model end-to-end evaluation — Verified — RAG-specific metrics (utilization, completeness, relevance).
5. Azure AI Evaluation SDK Overview — Verified — Python SDK examples, evaluator initialization.
6. Test and evaluate AI workloads on Azure — Verified — Quality metrics, testing vs. evaluation, baselining strategy.
7. Observability in generative AI — Verified — Three-stage evaluation (base model selection, pre-production, production).
8. Azure OpenAI Evaluation API — Verified — REST API, testing criteria, grading process.
9. GitHub Action for Evaluation — Verified — CI/CD integration.
10. Scorers and LLM judges (MLflow 3) — Verified — Judge models, accuracy validation, partner-powered AI disclaimers.

Confidence per seksjon

• Introduksjon, Kjernekomponenter, Arkitekturmønstre → Verified (100% MCP-backed).
• Beslutningsveiledning → Verified (threshold examples fra RAG evaluation guide + Well-Architected).
• Integrasjon med Microsoft-stakken → Verified (code samples fra MCP).
• Offentlig sektor → Baseline (GDPR/AI Act-tolkninger kombinert med Microsoft regional availability-dokumentasjon).
• Kostnad og lisensiering → Baseline (pricing estimates basert på Azure OpenAI token costs, feb 2026).
• For arkitekten → Verified (best practices fra Microsoft Learn, mature practices fra MLflow docs).