# Model Drift and Performance Degradation Detection

**Last updated:** 2026-04
**Status:** GA
**Category:** MLOps & GenAIOps
**Type:** reference
**Source:** https://learn.microsoft.com/azure/machine-learning/concept-model-monitoring

---

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

Model drift og performance degradation er kritiske fenomener som oppstår når en maskinlæringsmodells ytelse forverres over tid i produksjon. Dette skjer fordi virkeligheten endrer seg – input-data får andre distribusjoner, forretningslogikk endres, sensorer kalibreres feil, eller brukernes atferd endrer seg. Uten kontinuerlig overvåking kan modeller raskt bli utdaterte og levere feil prediksjoner som undergraver forretningsmål eller skaper compliance-problemer i regulerte sektorer.

Azure Machine Learning tilbyr et omfattende modell-monitoring-rammeverk som oppdager drift og degradering gjennom:

- **Data drift** – endringer i input-data sammenlignet med treningsdata eller nylig produksjonsdata
- **Prediction drift** – endringer i modellens output-distribusjon
- **Data quality** – deteksjon av null-verdier, datatype-feil, out-of-bounds-verdier
- **Feature attribution drift** – endringer i feature importance under produksjon
- **Model performance** – objektiv ytelse mot ground truth (krever faktiske utfall)

Rammeverket er integrert med Azure Event Grid for automatisert respons (f.eks. modell-retraining) og støtter både online endpoints og batch deployments.

**Verified (MCP):** Azure Machine Learning Model Monitoring er GA-status per februar 2026, med støtte for tabular classification og regression tasks.

---

## Kjernekomponenter

### 1. Monitoring Signals

Azure Machine Learning støtter flere built-in signals (med GA- eller preview-status):

| Signal | Beskrivelse | Status | Metrics |
|--------|-------------|--------|---------|
| **Data Drift** | Sporer endringer i input-distribusjon | GA | Jensen-Shannon Distance, Population Stability Index, Normalized Wasserstein Distance, Two-Sample Kolmogorov-Smirnov Test, Pearson's Chi-Squared Test |
| **Prediction Drift** | Sporer endringer i output-distribusjon | GA | Jensen-Shannon Distance, Population Stability Index, Normalized Wasserstein Distance, Chebyshev Distance, Two-Sample Kolmogorov-Smirnov Test, Pearson's Chi-Squared Test |
| **Data Quality** | Null rates, data type errors, out-of-bounds | GA | Null value rate, Data type error rate, Out-of-bounds rate |
| **Feature Attribution Drift** | Feature importance-endringer | Preview | Normalized Discounted Cumulative Gain |
| **Model Performance** | Objektiv ytelse (krever ground truth) | Preview | Accuracy, Precision, Recall (classification); MAE, MSE, RMSE (regression) |

**Verified (MCP):** Metrics og signal-typer hentet fra offisiell Microsoft Learn-dokumentasjon (2026-04).

### 2. Reference Data

Modell-monitoring krever sammenligningsgrunnlag (baseline):

- **Training data** – opprinnelig treningsdata (anbefalt for data drift og data quality)
- **Validation data** – valideringsdata (anbefalt for prediction drift)
- **Recent past production data** – nylig produksjonsdata (for rolling baseline)
- **Ground truth data** – faktiske utfall (påkrevd for model performance)

### 3. Production Inference Data

Produksjonsdata kan samles inn via:

- **Azure ML Data Collector** – automatisk innsamling fra online endpoints med `correlationid` for join
- **Manuell innsamling** – selvregistrerte data assets (krever custom preprocessing component)

**Verified (MCP):** Azure ML Data Collector støtter automatisk correlation ID-generering for data joining.

### 4. Serverless Spark Compute

Monitoring-jobber kjører på serverless Spark compute pools:

- Støttede VM-typer: `Standard_E4s_v3`, `Standard_E8s_v3`, `Standard_E16s_v3`, `Standard_E32s_v3`, `Standard_E64s_v3`
- Runtime version: 3.3 eller 3.4 (Spark)
- Skalerer automatisk basert på data-volum

### 5. Lookback Windows

Konfigurerbare tidsperioder for produksjons- og referansedata:

- **Lookback window size** – varighet av data-vindu (ISO 8601-format, f.eks. `P7D` = 7 dager)
- **Lookback window offset** – offset fra monitor-kjøretid (f.eks. `P0D` = ingen offset, `P2D` = 2 dagers offset)

**Best practice:** Unngå overlapping mellom produksjons- og referansedata-vindu for meningsfull sammenligning.

---

## Arkitekturmønstre

### Pattern 1: Out-of-Box Monitoring (Online Endpoint)

**Scenario:** Modell deployed til Azure ML online endpoint med data collection aktivert.

**Komponenter:**
1. **Online endpoint** med data collection (`azureml.monitoring.ModelDataCollector`)
2. **Automatisk datainnsamling** til Azure Blob Storage
3. **Smart defaults** for data drift, prediction drift, data quality
4. **Scheduled monitoring job** (daglig/ukentlig)
5. **Email alerts** ved threshold-brudd

**Setup (Python SDK):**

```python
from azure.ai.ml import MLClient
from azure.ai.ml.entities import (
    AlertNotification,
    MonitoringTarget,
    MonitorDefinition,
    MonitorSchedule,
    RecurrencePattern,
    RecurrenceTrigger,
    ServerlessSparkCompute
)

spark_compute = ServerlessSparkCompute(
    instance_type="standard_e4s_v3",
    runtime_version="3.3"
)

monitoring_target = MonitoringTarget(
    ml_task="classification",
    endpoint_deployment_id="azureml:credit-default:main"
)

alert_notification = AlertNotification(
    emails=['abc@example.com', 'def@example.com']
)

monitor_definition = MonitorDefinition(
    compute=spark_compute,
    monitoring_target=monitoring_target,
    alert_notification=alert_notification
)

recurrence_trigger = RecurrenceTrigger(
    frequency="day",
    interval=1,
    schedule=RecurrencePattern(hours=3, minutes=15)
)

model_monitor = MonitorSchedule(
    name="credit_default_monitor_basic",
    trigger=recurrence_trigger,
    create_monitor=monitor_definition
)

ml_client.schedules.begin_create_or_update(model_monitor)
```

**Verified (MCP):** Kode-eksempel fra Microsoft Learn (azure-ai-ml SDK v2).

### Pattern 2: Advanced Monitoring med Feature Importance

**Scenario:** Overvåk kun top N viktigste features for å redusere noise og compute-kostnad.

**Komponenter:**
1. **Training data** som reference baseline
2. **Target column** definert (f.eks. `DEFAULT_NEXT_MONTH`)
3. **Top N feature importance** (f.eks. top 10 features)
4. **Custom metric thresholds** per feature-type

**Setup (Python SDK):**

```python
from azure.ai.ml.entities import (
    DataDriftSignal,
    DataDriftMetricThreshold,
    NumericalDriftMetrics,
    CategoricalDriftMetrics,
    MonitorFeatureFilter,
    ReferenceData,
)

reference_data_training = ReferenceData(
    input_data=Input(
        type="mltable",
        path="azureml:credit-reference:1"
    ),
    data_column_names={
        "target_column":"DEFAULT_NEXT_MONTH"
    },
    data_context=MonitorDatasetContext.TRAINING,
)

features = MonitorFeatureFilter(top_n_feature_importance=10)

metric_thresholds = DataDriftMetricThreshold(
    numerical=NumericalDriftMetrics(
        jensen_shannon_distance=0.01
    ),
    categorical=CategoricalDriftMetrics(
        pearsons_chi_squared_test=0.02
    )
)

advanced_data_drift = DataDriftSignal(
    reference_data=reference_data_training,
    features=features,
    metric_thresholds=metric_thresholds,
    alert_enabled=True
)
```

**Verified (MCP):** Feature importance-basert filtering er dokumentert i Microsoft Learn.

### Pattern 3: Model Performance Monitoring med Ground Truth

**Scenario:** Objektiv ytelses-tracking når ground truth data er tilgjengelig.

**Forutsetninger:**
- **Unique ID** i både model output og ground truth (f.eks. `correlationid`)
- **Ground truth data asset** oppdatert kontinuerlig
- **Join column** for å koble output og ground truth

**Setup (Python SDK):**

```python
from azure.ai.ml.entities import (
    ModelPerformanceSignal,
    ModelPerformanceMetricThreshold,
    ModelPerformanceClassificationThresholds,
    ProductionData,
)

production_data = ProductionData(
    input_data=Input(
        type="uri_folder",
        path="azureml:credit-default-main-model_outputs:1"
    ),
    data_column_names={
        "target_column": "DEFAULT_NEXT_MONTH",
        "join_column": "correlationid"
    },
    data_window=BaselineDataRange(
        lookback_window_offset="P0D",
        lookback_window_size="P10D",
    )
)

reference_data_ground_truth = ReferenceData(
    input_data=Input(
        type="mltable",
        path="azureml:credit-ground-truth:1"
    ),
    data_column_names={
        "target_column": "ground_truth",
        "join_column": "correlationid"
    },
    data_context=MonitorDatasetContext.GROUND_TRUTH_DATA,
)

metric_thresholds = ModelPerformanceMetricThreshold(
    classification=ModelPerformanceClassificationThresholds(
        accuracy=0.50,
        precision=0.50,
        recall=0.50
    ),
)

model_performance = ModelPerformanceSignal(
    production_data=production_data,
    reference_data=reference_data_ground_truth,
    metric_thresholds=metric_thresholds,
    alert_enabled=True
)
```

**Verified (MCP):** Model performance monitoring krever unique ID i både output og ground truth for join-operasjon.

### Pattern 4: Event-Driven Retraining (Event Grid Integration)

**Scenario:** Automatisk retraining når drift eller performance-degradation detekteres.

**Komponenter:**
1. **Event Grid system topic** for Azure ML workspace
2. **Event subscription** med advanced filter
3. **Event handler** (Azure Functions, Logic Apps, Event Hubs)
4. **ML pipeline** for retraining

**Event Filter (avansert):**

```json
{
  "Key": "data.RunTags.azureml_modelmonitor_threshold_breached",
  "Operator": "String contains",
  "Value": "has failed due to one or more features violating metric thresholds"
}
```

**Verified (MCP):** Event Grid-integrasjon støttes for å trigge automatisk respons ved drift-deteksjon.

### Pattern 5: Custom Signal med Egendefinerte Metrics

**Scenario:** Implementer egne metrics som ikke dekkes av built-in signals (f.eks. `std_deviation`).

**Forutsetninger:**
- **Custom component** registrert som Azure ML component
- **Input signature:** `production_data` (mltable), `<metric>_threshold` (literal)
- **Output signature:** `signal_metrics` (mltable) med kolonnene `group`, `metric_name`, `metric_value`, `threshold_value`

**Setup (Azure CLI YAML):**

```yaml
create_monitor:
  monitoring_signals:
    customSignal:
      type: custom
      component_id: azureml:my_custom_signal:1.0.0
      input_data:
        production_data:
          input_data:
            type: uri_folder
            path: azureml:my_production_data:1
          data_context: test
          data_window:
            lookback_window_size: P30D
            lookback_window_offset: P7D
          pre_processing_component: azureml:custom_preprocessor:1.0.0
      metric_thresholds:
        - metric_name: std_deviation
          threshold: 2
```

**Verified (MCP):** Custom signals støttes via registrerte Azure ML components.

---

## Beslutningsveiledning

### Når bruke hvilken monitoring signal?

| Scenario | Anbefalt Signal | Begrunnelse |
|----------|----------------|-------------|
| **Nylig deployed modell** | Data Drift + Data Quality | Rask deteksjon av input-endringer |
| **Høy business-kritikalitet** | Data Drift + Prediction Drift + Feature Attribution Drift | Bred overvåking fra flere vinkler |
| **Ground truth tilgjengelig** | Model Performance | Objektiv ytelse-tracking |
| **Mange features (100+)** | Top N Feature Importance | Reduserer noise og compute-kostnad |
| **Regulert sektor** | Alle signals + Custom metrics | Full audit trail og compliance |

### Valg av reference data

| Reference Data | Best For | Tradeoff |
|----------------|----------|----------|
| **Training data** | Data drift, data quality | Statisk baseline – oppdager endringer fra opprinnelig distribusjon |
| **Validation data** | Prediction drift | Sammenligner mot test-distribusjon |
| **Recent past production data** | Rolling baseline | Adaptiv – følger endringer over tid, men kan skjule gradvis drift |
| **Ground truth data** | Model performance | Krever kontinuerlig innsamling av faktiske utfall |

### Monitoring-frekvens

| Data-volum | Anbefalt Frekvens | Rationale |
|------------|-------------------|-----------|
| **Høy trafikk (1000+ requests/dag)** | Daglig | Nok data for statistisk signifikans |
| **Moderat trafikk (100-1000/dag)** | Ukentlig | Samle nok data før analyse |
| **Lav trafikk (<100/dag)** | Månedlig | Unngå falske positiver fra små samples |

**Best practice:** Start med daglig monitoring og juster basert på alert fatigue og datainnsamling.

---

## Integrasjon med Microsoft-stakken

### Azure Machine Learning

- **Online Endpoints:** Automatisk data collection med `azureml.monitoring.ModelDataCollector`
- **Batch Endpoints:** Manuell datainnsamling (krever custom preprocessing component)
- **MLflow:** Modell-registrering med lineage tracking
- **Azure ML Pipelines:** Automatisk retraining-workflows

**Verified (MCP):** Data collector støtter online endpoints; batch endpoints krever custom preprocessing.

### Azure Event Grid

- **System Topics:** Azure ML workspace events
- **Event Types:** `Run status changed` (ikke `Dataset drift detected` – deprecated v1)
- **Event Handlers:** Azure Functions, Logic Apps, Event Hubs
- **Advanced Filters:** Filter på `azureml_modelmonitor_threshold_breached` tag

**Eksempel Event Grid-integrasjon:**

1. Opprett Event Grid system topic for workspace
2. Opprett event subscription med filter:
   - Key: `data.RunTags.azureml_modelmonitor_threshold_breached`
   - Operator: `String contains`
   - Value: `<monitor-name>_<signal-description>` (f.eks. `credit_monitor_data_drift`)
3. Konfigurer endpoint (Event Hubs, Azure Function)
4. Trigger ML pipeline for retraining ved drift

**Verified (MCP):** Event Grid-integrasjon er dokumentert for automated response.

### Azure Monitor & Application Insights

- **Metrics:** Online endpoint metrics (CPU, memory, RequestsPerMinute)
- **Logs:** Monitoring job execution logs
- **Alerts:** Custom alerting på metrics (komplementær til built-in alerts)
- **Dashboards:** Visualisering av drift metrics over tid

### Azure Blob Storage

- **Production inference data:** Automatisk lagring fra data collector
- **Monitoring artifacts:** Metrics i JSON-format
- **Ground truth data:** Manuell opplasting av faktiske utfall

---

## Offentlig sektor (Norge)

### Utredningsinstruksen (§ 13)

Modell-monitoring adresserer flere krav:

- **§ 13.1 (Konsekvensvurdering):** Kontinuerlig validering av modellens faktiske effekt i produksjon
- **§ 13.5 (Evaluering):** Systematisk oppfølging av modellytelse mot fastsatte mål
- **§ 13.6 (Revidering):** Automatisk varsling ved degradering som kan trigge revidering

**Anbefaling:** Sett alert thresholds i samsvar med målkriterier fra konsekvensvurdering.

### Digdir AI-prinsipper

| Prinsipp | Hvordan Model Monitoring Støtter |
|----------|----------------------------------|
| **Transparens** | Loggfør alle drift-deteksjoner og threshold-brudd for audit trail |
| **Ansvarlig bruk** | Objektiv ytelse-tracking mot ground truth sikrer kvalitet |
| **Personvern** | Data drift detection kan identifisere endringer i sensitive features |
| **Robusthet** | Kontinuerlig validering av modell-stabilitet i produksjon |

### DPIA og ROS-analyser

- **Datakvalitet:** Data quality signal detekterer null-verdier og out-of-bounds som kan være privacy-risiko
- **Bias-deteksjon:** Feature attribution drift kan indikere endret bias i produksjon
- **Incident response:** Event Grid-integrasjon muliggjør rask respons ved avvik

### NSM Grunnprinsipper for IKT-sikkerhet

- **Logging (GP4):** Alle monitoring-kjøringer logges med timestamp og resultat
- **Overvåking (GP5):** Kontinuerlig overvåking av modell-atferd i produksjon
- **Incident management (GP7):** Automatisk varsling via Event Grid ved threshold-brudd

**Anbefaling:** Integrer monitoring alerts med SIEM/SOC for koordinert respons.

---

## Kostnad og lisensiering

### Azure Machine Learning Pricing

| Komponent | Kostnadsdriver | Estimat (NOK/måned) |
|-----------|---------------|---------------------|
| **Serverless Spark Compute** | VM-timer (Standard_E4s_v3: ~$0.54/time) | Avhenger av data-volum og frekvens |
| **Storage (Blob)** | Production inference data (Standard, hot tier: ~$0.02/GB) | Lav kostnad for de fleste workloads |
| **Data Collector** | Ingen ekstra kostnad (inkludert i endpoint) | 0 NOK |
| **Event Grid** | Events ($0.60 per million operations) | Neglisjerbar |

**Eksempel-beregning (daglig monitoring, 100K rows/dag):**

- Spark job (15 min/dag): ~0.5 timer/måned × $0.54 = ~$0.27 ≈ **3 NOK/måned**
- Storage (3 GB/måned): 3 × $0.02 = ~$0.06 ≈ **0.60 NOK/måned**
- **Total:** ~**3.60 NOK/måned** (ekskl. endpoint-kostnader)

**Baseline:** Modell-monitoring er relativt billig sammenlignet med kostnaden av modell-degradering.

### Lisensiering

- **Azure ML Workspace:** Ingen lisenskostnad (pay-per-use for compute/storage)
- **Event Grid:** Ingen lisenskostnad (pay-per-event)
- **Azure Monitor:** Inkludert i Azure-subscriptions

**Verified (MCP):** Pricing-estimater basert på Azure offentlig prisliste (januar 2026).

### Kostnadsoptimalisering

1. **Monitor top N features** – reduser antall features som overvåkes
2. **Juster monitoring-frekvens** – ukentlig/månedlig for lav-trafikk-modeller
3. **Lookback window size** – balanser statistisk signifikans vs. compute-kostnad
4. **Use recent past production data** som baseline (ingen storage av treningsdata)

---

## For arkitekten (Cosmo)

### Quick Decision Framework

**Spørsmål til kunde:**

1. **Er modellen deployed til Azure ML online endpoint?**
   - Ja → Bruk out-of-box monitoring med data collector
   - Nei → Manuell datainnsamling + custom preprocessing component

2. **Har dere tilgang til ground truth data?**
   - Ja → Inkluder model performance signal
   - Nei → Data drift + prediction drift + data quality

3. **Hvor mange features har modellen?**
   - <20 → Monitor alle features
   - 20-100 → Monitor top N (N=10-20)
   - >100 → Feature subset eller top N (N=20-30)

4. **Hvor kritisk er modellen for business?**
   - Høy → Daglig monitoring + Event Grid + automatisk retraining
   - Moderat → Ukentlig monitoring + email alerts
   - Lav → Månedlig monitoring

5. **Er dette regulert sektor?**
   - Ja → Alle signals + custom metrics + full audit trail
   - Nei → Standard signals (data drift, prediction drift, data quality)

### Typiske Anti-patterns

| Anti-pattern | Hvorfor Dette er Dårlig | Anbefaling |
|--------------|------------------------|------------|
| **Ingen monitoring** | Modellen degraderer uten deteksjon | Start med out-of-box monitoring umiddelbart |
| **For mange features** | Alert fatigue, høy compute-kostnad | Top N feature importance |
| **For høy frekvens** | Unødvendig compute-kostnad for lav-trafikk | Juster til ukentlig/månedlig |
| **Ingen Event Grid** | Manuell respons ved drift | Automatiser retraining-workflow |
| **Training data som baseline alltid** | Kan være outdated etter år | Vurder rolling baseline (recent past production data) |

### Integration Checklist

- [ ] **Data collection aktivert** (online endpoints) eller custom preprocessing (batch/external)
- [ ] **Reference data registrert** som Azure ML data asset
- [ ] **Monitoring signals konfigurert** (minimum data drift + data quality)
- [ ] **Alert thresholds satt** basert på business-kritikalitet
- [ ] **Email notifications** til data science team
- [ ] **Event Grid subscription** for automatisk respons (optional men anbefalt)
- [ ] **Monitoring frekvens** justert til datainnsamling-rate
- [ ] **Lookback windows** konfigurert (ingen overlapping)
- [ ] **Feature subset/top N** valgt (hvis mange features)
- [ ] **Ground truth pipeline** etablert (hvis model performance signal)

### Arkitektur-templates

**Template 1: Basic Monitoring (Small Team, Low Complexity)**

```
Azure ML Online Endpoint (data collector)
    ↓
Blob Storage (production inference data)
    ↓
Serverless Spark (daily monitoring)
    ↓
Email Alerts (threshold breach)
```

**Template 2: Advanced Monitoring (Enterprise, High Criticality)**

```
Azure ML Online Endpoint (data collector)
    ↓
Blob Storage (production + ground truth data)
    ↓
Serverless Spark (daily monitoring: drift + performance)
    ↓
Event Grid (threshold breach event)
    ↓
Azure Function (trigger retraining pipeline)
    ↓
Azure ML Pipeline (automated retraining + deployment)
```

**Template 3: Batch/External Deployment**

```
External Model (manual data collection)
    ↓
Azure ML Data Asset (registered production data)
    ↓
Custom Preprocessing Component (format to mltable)
    ↓
Serverless Spark (weekly monitoring)
    ↓
Email Alerts + Azure Monitor Dashboard
```

### Conversation Starters

- "Har modellen din endret atferd siden den ble deployet?"
- "Hvor lang tid tar det før dere oppdager at modellen gir dårlige prediksjoner?"
- "Har dere tilgang til faktiske utfall (ground truth) for å validere modell-nøyaktighet?"
- "Hvor mange features monitorer dere – og er de alle like viktige?"
- "Hva skjer når en threshold brytes – har dere en plan for respons?"

---

## Kilder og verifisering

### Microsoft Learn (MCP-verified)

1. **Azure Machine Learning model monitoring (Concept)**
   https://learn.microsoft.com/en-us/azure/machine-learning/concept-model-monitoring?view=azureml-api-2
   *Verified: 2026-04 via microsoft_docs_fetch*
   - Monitoring signals, metrics, reference data, lookback windows

2. **Monitor the performance of models deployed to production**
   https://learn.microsoft.com/en-us/azure/machine-learning/how-to-monitor-model-performance?view=azureml-api-2
   *Verified: 2026-04 via microsoft_docs_fetch*
   - Setup guides (CLI, SDK, Studio), Event Grid integration, interpret results

3. **Data drift (preview) will be retired, and replaced by Model Monitor**
   https://learn.microsoft.com/en-us/azure/machine-learning/how-to-monitor-datasets?view=azureml-api-1
   *Verified: 2026-04 via microsoft_docs_search (3 results)*
   - Legacy DataDriftDetector (v1) vs. Model Monitor (v2)

4. **Trigger applications, processes, or CI/CD workflows based on Azure Machine Learning events**
   https://learn.microsoft.com/en-us/azure/machine-learning/how-to-use-event-grid?view=azureml-api-2
   *Verified: 2026-04 via microsoft_docs_search*
   - Event Grid integration, advanced filters

5. **Machine learning operations (MLOps v2)**
   https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/machine-learning-operations-v2
   *Verified: 2026-04 via microsoft_docs_search (multiple references)*
   - Data drift, prediction drift, resource monitoring

### Code Samples (MCP-verified)

1. **Model monitoring setup (Python SDK v2)**
   https://learn.microsoft.com/en-us/azure/machine-learning/how-to-monitor-model-performance
   *Verified: 2026-04 via microsoft_code_sample_search*
   - Out-of-box monitoring, advanced monitoring, model performance

2. **DataDriftDetector (Python SDK v1 – deprecated)**
   https://learn.microsoft.com/en-us/python/api/azureml-datadrift/azureml.datadrift.datadriftdetector
   *Verified: 2026-04 via microsoft_code_sample_search*
   - Legacy API for comparison

3. **Custom signal component examples**
   https://github.com/Azure/azureml-examples/tree/main/cli/monitoring/components/custom_signal
   *Referenced: 2026-04 in Microsoft Learn documentation*

### Confidence Markers

| Seksjon | Confidence | Kilde |
|---------|-----------|-------|
| Introduksjon | **Verified** | MCP: concept-model-monitoring (GA status confirmed) |
| Kjernekomponenter | **Verified** | MCP: monitoring signals table, metrics, data collector |
| Arkitekturmønstre | **Verified** | MCP: code samples (Python SDK v2) |
| Beslutningsveiledning | **Baseline** | Cosmo's expertise + best practices fra docs |
| Integrasjon med Microsoft-stakken | **Verified** | MCP: Event Grid, Azure Monitor, Blob Storage |
| Offentlig sektor | **Baseline** | Cosmo's domain knowledge + norsk lovverk |
| Kostnad og lisensiering | **Baseline** | Azure offentlig prisliste (januar 2026) |

### Sist oppdatert

**2026-04** – Basert på Microsoft Learn-dokumentasjon (azure-ai-ml SDK v2, API version 2).


### Azure ML Model Drift & Performance Degradation Monitoring (2026)

**Model monitoring** provides continuous tracking of production model performance:

**Degradation signals**:
- **Prediction drift**: Output distribution shifts away from training baseline
- **Feature attribution drift**: Feature importance changes indicate concept drift
- **Data quality degradation**: Input data quality issues upstream
- **Performance metric degradation**: Track against ground truth when labels available

**Monitoring configuration**:
```python
# Set up monitoring for deployed models on online endpoints
# Azure ML handles data collection and signal computation
# Monitoring jobs run on schedule (default: daily)
```

**Alert thresholds** (recommended):
- Data drift coefficient > 0.1: Investigate
- Data drift coefficient > 0.3: Retrain trigger
- Prediction drift > 15%: Production alert
- Unusable nodes > 0: Infrastructure alert (Azure Monitor)

**Continuous learning loop**:
1. Monitor signals → detect drift early
2. Critically evaluate inherent model risks
3. Identify hidden problems before business impact
4. Trigger retraining or model update workflow
5. Validate new model before rollout (blue-green/canary)

**Integration**: Azure Event Grid for alerting → Logic Apps / Functions → automated retraining trigger

**For GenAI/LLM**: MLflow 3 production monitoring reuses development scorers (Groundedness, Relevance) on production traces — consistent quality measurement throughout lifecycle.