# Data Drift Monitoring and Detection

**Last updated:** 2026-04
**Verified:** MCP 2026-04
**Status:** GA
**Category:** MLOps & GenAIOps

---

**Verified:** MCP 2026-04

## Introduksjon

Data drift er endringer i statistisk fordeling av modellinput-data over tid som kan føre til forringet modellprestasjon. For machine learning-modeller er kontinuerlig overvåking av data drift avgjørende for å opprettholde produksjonskvalitet. Azure Machine Learning tilbyr innebygd drift detection som sammenligner produksjonsdata mot baseline-datasett (typisk treningsdata eller nylig produksjonsdata) og beregner statistiske avstandsmål.

Data drift oppstår av flere årsaker: upstream prosessendringer (f.eks. sensor byttet ut, endret måleenhet), datakvalitetsproblemer (defekt sensor som alltid leser 0), naturlig drift (temperatur endres med sesong), eller covariate shift (endring i relasjoner mellom features). Uten deteksjon kan drift føre til at modeller blir utdaterte og leverer dårlige prediksjoner i produksjon.

Azure Machine Learning Model Monitoring forenkler drift detection ved å beregne én enkelt metric som abstraherer kompleksiteten i datasett med hundrevis av features og titusener av rader. Når drift detekteres, kan du drille ned til feature-nivå for å identifisere root cause. Dette top-down approach gjør overvåking enklere enn tradisjonelle regelbaserte teknikker som kan være tidkrevende og feilutsatte.

## Kjernekomponenter

**Monitoring Signals**
Azure Machine Learning støtter flere overvåkingssignaler som kjøres som scheduled jobs:

- **Data drift** – sammenligner distribusjon av modell-input mot baseline (training data eller recent production data)
- **Prediction drift** – sporer endringer i distribusjon av modellens output
- **Data quality** – overvåker data-integritet (null values, type errors, out-of-bounds rate)
- **Feature attribution drift** – sporer endringer i feature importance mellom trening og produksjon
- **Model performance** – objektiv prestasjonsmåling mot ground truth data (krever labeled data)

**Drift Detection Metrics** (Verified — Azure ML docs)
For numeriske features:
- **Jensen-Shannon Distance** – symmetrisk divergens mellom to sannsynlighetsfordelinger
- **Population Stability Index (PSI)** – misure endring i distribusjoner
- **Normalized Wasserstein Distance** – minimum "arbeid" for å transformere baseline til target distribution
- **Two-Sample Kolmogorov-Smirnov Test** – tester om to samples kommer fra samme fordeling

For kategoriske features:
- **Pearson's Chi-Squared Test** – tester uavhengighet mellom kategoriske variabler
- **Euclidean Distance** – beregnet på empiriske fordelinger av kategoriske kolonner

**Lookback Windows og Offset** (Verified — Azure ML docs)
Lookback window size definerer tidsperiode for produksjonsdata (ISO 8601 format, f.eks. `P7D` = 7 dager). Lookback window offset forskyvver slutten av datavindu fra kjøretidspunkt (f.eks. `P2D` for å ekskludere helgedata).

Best practice: Sørg for at reference data window og production data window ikke overlapper. Sett reference offset ≥ production window size + production offset.

**Data Quality Metrics** (Verified — Azure ML docs)
- **Null value rate** – andel null-verdier per feature (støtter 0.00001 presisjon)
- **Data type error rate** – andel verdier som ikke matcher infererred datatype fra reference data (støtter PySpark types: IntegerType, DoubleType, StringType, etc.)
- **Out-of-bounds rate** – andel verdier utenfor akseptabelt range/set bestemt av reference data (for numerical: [min, max], for categorical: distinct values set)

**Azure Event Grid Integration** (Verified — Azure ML docs)
Model monitoring genererer events som kan trigge workflows via Event Grid. Når drift, datakvalitetsproblemer eller performance degradation detekteres, kan du automatisk starte retraining pipelines eller varslingssystemer.

## Arkitekturmønstre

**Out-of-Box Monitoring for Online Endpoints** (Verified — Azure ML docs)
Hvis modellen deployes til Azure Machine Learning online endpoint:
1. Aktiver production inference data collection via model data collector
2. Azure ML samler automatisk model inputs/outputs
3. Sett opp model monitor via SDK/CLI eller Studio UI
4. Spesifiser monitoring signals (data drift, data quality, etc.)
5. Kjør scheduled monitoring jobs (daglig/ukentlig/månedlig)
6. Motta alerts når thresholds overskrides

**Advanced Monitoring Setup** (Verified — code samples)
For finkornet kontroll:

```python
from azure.ai.ml import MLClient
from azure.ai.ml.entities import (
    DataDriftSignal,
    DataQualitySignal,
    MonitorFeatureFilter,
    NumericalDriftMetrics,
    CategoricalDriftMetrics,
    DataDriftMetricThreshold,
    MonitorSchedule,
    ServerlessSparkCompute
)

# Definer data drift signal
features = MonitorFeatureFilter(top_n_feature_importance=20)
metric_thresholds = DataDriftMetricThreshold(
    numerical=NumericalDriftMetrics(jensen_shannon_distance=0.01),
    categorical=CategoricalDriftMetrics(pearsons_chi_squared_test=0.02)
)

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

# Sett opp monitoring schedule
spark_compute = ServerlessSparkCompute(
    instance_type="standard_e4s_v3",
    runtime_version="3.3"
)

monitoring_signals = {'data_drift_advanced': advanced_data_drift}
monitor_definition = MonitorDefinition(
    compute=spark_compute,
    monitoring_signals=monitoring_signals,
    alert_notification=AlertNotification(emails=['team@example.com'])
)

recurrence_trigger = RecurrenceTrigger(frequency="day", interval=1)
model_monitor = MonitorSchedule(
    name="production_drift_monitor",
    trigger=recurrence_trigger,
    create_monitor=monitor_definition
)

ml_client.schedules.begin_create_or_update(model_monitor)
```

**Top-N Feature Monitoring** (Verified — Azure ML docs)
For modeller med mange features: Overvåk kun topp-N viktigste features (basert på feature importance fra training) for å redusere compute cost og monitoring noise.

```python
features = MonitorFeatureFilter(top_n_feature_importance=10)
# eller spesifikk feature-liste:
features = ['feature_A', 'feature_B', 'feature_C']
```

**Custom Monitoring Signals** (Baseline)
Hvis built-in signals ikke passer: Definer custom monitoring signal component med egne metrics og thresholds. Krever implementering av Spark-basert beregningslogikk.

**Legacy Dataset Monitors (v1) → Model Monitor Migration** (Verified — Azure ML docs)
Azure ML Dataset Monitors (preview, v1 SDK) er deprecated. Migrer til Model Monitor (v2 SDK):
- v1: `DataDriftDetector.create_from_datasets()`
- v2: `DataDriftSignal` + `MonitorSchedule`

Model Monitor har flere capabilities (multi-signal, feature attribution drift, generative AI metrics).

## Beslutningsveiledning

**Når bruke data drift monitoring?**
- Modellen er deployed til produksjon (online eller batch endpoint)
- Input-data kan endre seg over tid (sesongvariasjoner, skiftende brukeratferd, upstream prosessendringer)
- Modellprestasjon er kritisk for forretningen
- Du har tilgang til baseline-data (training data eller historisk production data)

**Valg av baseline-data** (Verified — best practices)
- **Data drift/quality**: Bruk training data som baseline for mer meningsfull sammenligning
- **Prediction drift**: Bruk validation data eller labeled test data som baseline
- **Nylig produksjonsdata**: Kan brukes som baseline hvis du vil detektere kortsiktige endringer

**Monitoring Frequency** (Verified — best practices)
- **Daglig**: Modell med høy daglig trafikk og rask data-akkumulering
- **Ukentlig**: Moderat trafikk, ugentlig data-akkumulering tilstrekkelig
- **Månedlig**: Lav trafikk eller sesongbaserte mønstre

Unngå for hyppig monitoring hvis produksjonsdata-volumet er lavt (statistisk insignifikante resultater).

**Alert Threshold-setting** (Baseline + Verified)
Samarbeid med data scientists som kjenner modellen for å sette riktige thresholds. For høye thresholds = missed drift, for lave = alert fatigue.

Start konservativt (f.eks. Jensen-Shannon distance threshold 0.1 for numerical), juster basert på false positive/negative rates.

**Compute Resource Sizing** (Baseline)
Model monitoring bruker Spark for store datasett. Velg instance type basert på data volum:
- `standard_e4s_v3`: Små til medium datasett (<100K rows/dag)
- `standard_e8s_v3` eller høyere: Store datasett (>1M rows/dag)

**Multi-Signal Monitoring** (Verified — best practices)
Kombiner flere signals for bredere dekkning:
- Data drift + Feature attribution drift = tidlig warning om performance issues
- Data quality + Data drift = detekter både strukturelle og distribusjonelle problemer
- Model performance (hvis ground truth tilgjengelig) = objektiv måling

## Integrasjon med Microsoft-stakken

**Azure Machine Learning Workspace** (Verified)
Data drift monitoring krever:
- Azure ML workspace (v2 API)
- Compute resources (serverless Spark eller managed compute cluster)
- Datastore for production inference data (Azure Blob Storage eller ADLS Gen2)
- Optional: Application Insights for custom metrics logging

**Authentication Options** (Verified — Azure ML docs)
- **Credential-based**: Legg til credentials på datastore
- **Credential-less (anbefalt)**: Bruk User-Assigned Managed Identity (UAMI)
  1. Opprett UAMI og attach til workspace
  2. Grant UAMI permissions til datastore
  3. Sett `systemDatastoresAuthMode = 'identity'`

**Azure Monitor + Application Insights** (Verified)
Drift metrics emitteres til Application Insights (tilhører ML workspace). Bruk custom alerting for alle generated metrics.

**Azure Event Grid for CI/CD Integration** (Verified)
Når model monitor detekterer drift og threshold overskrides:
1. Event Grid emitter "Run status changed" event
2. Filter på `azureml_modelmonitor_threshold_breached` tag
3. Trigger automated retraining pipeline (Azure ML pipeline eller Azure DevOps)
4. Redeploy oppdatert modell

Eksempel Event Grid filter (advanced filter):
- Key: `data.RunTags.azureml_modelmonitor_threshold_breached`
- Operator: `String contains`
- Value: `has failed due to one or more features violating metric thresholds`

**Azure AI Foundry (tidligere Azure AI Studio)** (Baseline + Verified)
For generative AI workloads: Azure AI Foundry har egen monitoring med observability features og generation quality metrics (groundedness, relevance, fluency). Støtter også drift detection for grounding data i RAG scenarios.

**Power BI Dashboards** (Baseline)
Export drift metrics fra Azure ML til Power BI for executive dashboards. Koble til workspace blob storage (JSON metrics output) eller Application Insights.

## Offentlig sektor (Norge)

**Krav til sporbarhet** (Baseline + Verified)
Offentlige virksomheter må kunne dokumentere hvordan AI-modeller oppfører seg over tid (Utredningsinstruksen §14, AI Act Article 12). Data drift monitoring gir:
- Tidsserie-logging av modellprestasjon og input-distribusjon
- Feature-level attribution for å forklare hvilke variabler som endrer seg
- Alert-historikk som viser når modellen ble degradert

**DPIA-relevans** (Baseline)
Data Protection Impact Assessment (DPIA) krever kontinuerlig risikovurdering. Data drift kan indikere:
- Endringer i populasjonssammensetning (potensielt bias)
- Datakvalitetsproblemer som kan føre til feilaktige beslutninger
- Covariate shift som kan diskriminere mot underrepresenterte grupper

Dokumenter drift detection som del av "tiltak for å sikre rettmessighet" (GDPR Article 35).

**AI Act Conformity Assessment** (Baseline + Verified)
AI Act krever risk management system for høyrisiko-AI (Article 9). Data drift monitoring er del av "technical and organizational measures" for å sikre accuracy, robustness, cybersecurity.

Spesifikt for offentlig sektor (høyrisiko use cases):
- Logg alle drift detection runs og alert events
- Etabler prosedyre for respons på drift alerts (retraining, model decommissioning)
- Dokumenter baseline-data valg og threshold-setting i teknisk dokumentasjon

**NSM Grunnprinsipper for IKT-sikkerhet** (Baseline)
Prinsipp 2.1 (Kjenne seg selv) og 2.2 (Identifisere og kartlegge): Data drift monitoring gir innsikt i hvordan datagrunnlaget utvikler seg, kritisk for å vurdere om modellen fortsatt er egnet for formålet.

**Digdir sine anbefalinger** (Baseline)
Kunstig intelligens og automatisering i offentlig sektor (veileder): "Systemer må overvåkes kontinuerlig for å sikre at de fungerer som forventet." Data drift monitoring oppfyller dette kravet.

## Kostnad og lisensiering

**Compute Costs** (Baseline + Verified)
Data drift monitoring kjører på Spark compute. Kostnader beregnes per monitoring job run:

- **Serverless Spark** (anbefalt for starte):
  - `standard_e4s_v3`: ~100-150 NOK/time (4 cores, 32 GB RAM)
  - `standard_e8s_v3`: ~200-300 NOK/time (8 cores, 64 GB RAM)
  - Kun betaler for job runtime (typisk 5-20 minutter per run)

- **Managed Compute Cluster** (for store volumer):
  - Samme instans-priser, men kan holdes online (idle cost)
  - Anbefales kun hvis du kjører mange concurrent monitoring jobs

**Daglig Drift Monitor (estimat):**
- 1 daily job, 10 minutter runtime på `standard_e4s_v3`: ~2-3 NOK/dag = ~60-90 NOK/måned
- 1 hourly job, 10 minutter runtime: ~120-180 NOK/måned

**Storage Costs** (Baseline)
Production inference data lagres i Azure Blob Storage eller ADLS Gen2:
- Inference data: ~0.15 NOK/GB/måned (hot tier)
- Drift metrics output (JSON): neglisjerbar (<1 MB per run)

**Eksempel (medium-size deployment):**
- 1M predictions/dag, 10 KB per record = ~10 GB/dag = ~300 GB/måned
- Storage: 300 GB × 0.15 NOK = 45 NOK/måned
- Daily monitoring (10 min/dag): 90 NOK/måned
- **Total: ~135 NOK/måned**

**Application Insights Costs** (Baseline)
Metrics logging til App Insights: ~0.5 NOK/GB ingestion. Drift monitoring genererer minimal telemetry (<100 MB/måned for typical setup).

**Lisensiering** (Verified)
Data drift monitoring er inkludert i Azure Machine Learning (ingen separat lisens):
- Krever Azure ML workspace (ingen cost for workspace selv)
- Compute og storage faktureres separat (consumption-based)

**Cost Optimization Tips** (Baseline)
- Bruk top-N feature monitoring istedenfor alle features
- Juster monitoring frequency basert på data growth rate
- Bruk lookback windows strategisk (ikke prosesser mer data enn nødvendig)
- Cleanup gamle inference data (retention policy)
- Bruk serverless Spark (kun betaler for runtime, ikke idle)

## For arkitekten (Cosmo)

**Når anbefale data drift monitoring:**
- **Alltid** for production-deployed ML models (high-impact decisions)
- Spesielt kritisk: Finance (fraud detection), Healthcare (diagnostics), Public sector (benefit eligibility)
- Påkrevd hvis modellen brukes i automated decision-making (AI Act høyrisiko)

**Implementeringsrekkefølge:**
1. **Uke 1**: Aktiver data collection for online endpoint (model data collector)
2. **Uke 2**: Sett opp basic drift monitoring med default settings (out-of-box)
3. **Uke 3**: Tune thresholds basert på første runs (samarbeid med data scientists)
4. **Uke 4**: Integrer med Event Grid for automated retraining workflows

**Arkitekturvalg:**

| Scenario | Anbefaling |
|----------|------------|
| Ny modell i prod | Start med out-of-box monitoring (data drift + data quality) |
| Modell med mange features (>100) | Bruk top-N feature importance filter |
| Kritisk modell (finance, healthcare) | Multi-signal monitoring (drift + attribution + performance) |
| Høy trafikk (>1M/dag) | Daglig monitoring med serverless Spark e8s_v3 |
| Lav trafikk (<10K/dag) | Ukentlig monitoring med serverless Spark e4s_v3 |
| Ground truth tilgjengelig | Legg til model performance signal (objektiv måling) |
| Generative AI (RAG) | Bruk Azure AI Foundry monitoring (groundedness, relevance) |

**Fallgruver å unngå:**
- ❌ **Ikke** start monitoring uten å definere baseline-data (training data vs. recent production)
- ❌ **Ikke** sett thresholds uten data scientist input (risiko for alert fatigue eller missed drift)
- ❌ **Ikke** ignorer lookback window overlap (kan gi misleading results)
- ❌ **Ikke** bruk MLTable med Spark-based monitoring (limited support, bruk Spark API direkte)
- ❌ **Ikke** glem å sette opp response workflow (drift detection uten action er meningsløst)

**Integrasjon med andre MLOps-komponenter:**
- **CI/CD pipeline**: Event Grid → Azure DevOps → Automated retraining
- **Model registry**: Link drift alerts til model version (traceability)
- **Experiment tracking**: Logg drift metrics sammen med training metrics (MLflow)
- **A/B testing**: Bruk drift detection for å validere champion/challenger models

**Offentlig sektor spesifikt:**
- Dokumenter drift monitoring setup i teknisk dokumentasjon (AI Act krav)
- Etabler eskalasjonsprosedyre for kritiske drift alerts (hvem bestemmer om modell skal decommissioned?)
- Logg alle monitoring runs for audit trail (minimum 5 år retention for offentlig sektor)
- Inkluder drift metrics i årlig AI-system review (internal governance)

**Migration fra v1 Dataset Monitors:**
Hvis kunden bruker legacy `DataDriftDetector` (azureml-datadrift SDK):
1. Map eksisterende baseline/target datasets til v2 reference/production data
2. Konverter frequency (Day/Week/Month) til RecurrenceTrigger
3. Migrer feature_list til MonitorFeatureFilter
4. Migrer drift_threshold til DataDriftMetricThreshold (velg metric type)
5. Test side-by-side før cutover (verifiser samme results)

**Typical Conversation Flow:**
1. **Discover**: "Bruker dere ML i prod? Hvordan overvåker dere modellprestasjon?"
2. **Educate**: "Data drift er en av hovedårsakene til model decay. Azure ML har innebygd drift detection."
3. **Scope**: "La oss starte med basic setup for én modell, tune thresholds, deretter scale ut."
4. **Align**: "For offentlig sektor må vi også dokumentere dette for DPIA og AI Act compliance."
5. **Deliver**: "Jeg setter opp monitoring, dere definerer response workflow sammen med data scientists."

**Red Flags (når advare):**
- Kunde ønsker å monitore 1000+ features real-time (cost explosion, bruk sampling)
- Ingen plan for hva som skal skje når drift detekteres (monitoring uten action)
- Forventer 100% accuracy i drift detection (statistiske metoder har usikkerhet)
- Vil bruke monitoring på modeller uten production traffic (ingen data å monitore)

## Kilder og verifisering

**Verified (Microsoft Learn MCP, 2026-04):**
- Azure Machine Learning model monitoring concept: https://learn.microsoft.com/en-us/azure/machine-learning/concept-model-monitoring?view=azureml-api-2
- Monitor model performance in production: https://learn.microsoft.com/en-us/azure/machine-learning/how-to-monitor-model-performance?view=azureml-api-2
- Data drift (v1, deprecated): https://learn.microsoft.com/en-us/azure/machine-learning/how-to-monitor-datasets?view=azureml-api-1
- Python SDK examples (azure.ai.ml): Code samples verified via microsoft_code_sample_search
- Event Grid integration: https://learn.microsoft.com/en-us/azure/machine-learning/how-to-use-event-grid?view=azureml-api-2

**Baseline (Model knowledge, januar 2025):**
- Cost estimates (Spark compute pricing)
- Public sector compliance mapping (AI Act, DPIA, NSM)
- Custom monitoring signals implementation patterns
- Power BI integration for drift dashboards
- Migration patterns fra v1 til v2 API

**MCP Calls:** 5 (3 × microsoft_docs_search, 1 × microsoft_docs_fetch, 1 × microsoft_code_sample_search)
**Unique Sources:** 12 Microsoft Learn URLs


### Azure ML Model Monitoring — Data Drift Detection (2026) — Verified (MCP 2026-04)

**Model monitoring signals** (out-of-box for online endpoints):

| Signal | What it detects |
|--------|----------------|
| **Data quality** | Null values, out-of-range values, type mismatches in input features |
| **Data drift** | Statistical distribution change: training data vs production data |
| **Prediction drift** | Distribution shift in model output predictions |
| **Feature attribution drift** | Changes in which features drive predictions |
| **Custom signals** | User-defined metrics via Python scripts |

**Setup options**:
- **Out-of-box**: Automatically configured for Azure ML online endpoints (no configuration required)
- **Advanced**: Custom monitoring for models deployed outside Azure ML (batch endpoints, external)
- **Azure Event Grid integration**: Route monitoring alerts for automated response

**Statistical methods used**:
- Jensen-Shannon divergence for categorical features
- Wasserstein distance (Earth Mover's Distance) for numerical features
- Population Stability Index (PSI) for feature stability

**Reference dataset**: Training dataset used as baseline; monitoring compares production distribution against it.

**Alerting**: Configure thresholds per signal; integrate with Azure Monitor alerts and Action Groups.