ktg-plugin-marketplace/plugins/ms-ai-architect/skills/ms-ai-engineering/references/mlops-genaiops/automated-retraining-pipelines.md

Automated Retraining Pipelines and Scheduling

Last updated: 2026-02 Status: GA Category: MLOps & GenAIOps

---

Introduksjon

Maskinlæringsmodeller degraderes over tid på grunn av data drift, concept drift og endringer i produksjonsmiljøet — et fenomen kjent som model decay. Automatisert retraining av modeller er derfor en kritisk komponent i moderne MLOps-arkitekturer, som sikrer at produksjonsmodeller opprettholder ytelse og relevans uten manuell intervensjon.

Azure Machine Learning og Azure Databricks tilbyr komplementære løsninger for automatiserte retraining pipelines med planlegging (scheduling), hvor Azure ML fokuserer på code-first MLOps-workflows med integrert pipeline-orkestrering, mens Databricks tilbyr en lakehouse-basert tilnærming med Unity Catalog som sentralt governance-lag.

Verified (MCP): Azure Machine Learning SDK v2 og CLI v2 tilbyr native støtte for recurrence-baserte og cron-baserte schedules for pipeline-kjøringer, mens Azure Databricks støtter både scheduled og triggered retraining via Databricks Jobs og SQL-alerts.

Automatisert retraining omfatter tre hovedkomponenter:

1. Training pipeline — kode som transformerer data, trener modellen og logger artefakter
2. Scheduling mechanism — tidsbaserte triggere (recurrence eller cron) eller event-baserte triggere (data drift, performance degradering)
3. Validation & deployment pipeline — automatisk validering av ny modellversjon og deployment til produksjon

Baseline: GenAI-modeller (LLM-er) har typisk annen retraining-strategi enn tradisjonelle ML-modeller, med fokus på prompt engineering, RAG-optimalisering og fine-tuning i stedet for full retraining.

---

Kjernekomponenter

1. Pipeline Scheduling i Azure Machine Learning

Azure ML tilbyr to triggeringsmekanismer for pipeline-schedules:

Recurrence-basert scheduling:

• Enkel tidsbasert repetering (minutter, timer, dager, uker, måneder)
• Støtter komplekse mønstre (f.eks. "hver mandag og onsdag kl. 18:30")
• YAML-eksempel:

trigger:
  type: recurrence
  frequency: day
  interval: 1
  schedule:
    hours: [4,5,10,11,12]
    minutes: [0,30]
  start_time: "2026-02-10T10:00:00"
  time_zone: "Europe/Oslo"

Verified (MCP): Python SDK v2 tilbyr RecurrenceTrigger med RecurrencePattern for å definere komplekse mønstre:

from azure.ai.ml.entities import JobSchedule, RecurrenceTrigger, RecurrencePattern
from azure.ai.ml.constants import TimeZone

recurrence_trigger = RecurrenceTrigger(
    frequency="day",
    interval=1,
    schedule=RecurrencePattern(hours=10, minutes=[0, 1]),
    start_time=datetime.utcnow(),
    time_zone=TimeZone.UTC,
)

job_schedule = JobSchedule(
    name="daily_retraining_schedule",
    trigger=recurrence_trigger,
    create_job=pipeline_job
)

ml_client.schedules.begin_create_or_update(schedule=job_schedule).result()

Cron-basert scheduling:

• Standard crontab-syntaks for fleksible mønstre
• Format: MINUTES HOURS * * DAYS-OF-WEEK (DAYS og MONTHS behandles alltid som *)
• Eksempel: 15 16 * * 1 = hver mandag kl. 16:15 UTC

from azure.ai.ml.entities import CronTrigger

cron_trigger = CronTrigger(
    expression="0 2 * * *",  # Hver natt kl. 02:00
    start_time=datetime.utcnow(),
    time_zone="Eastern Standard Time",
)

job_schedule = JobSchedule(
    name="nightly_retraining",
    trigger=cron_trigger,
    create_job=pipeline_job
)

Verified (MCP): Schedules kan oppdatere pipeline-parametere ved hver kjøring, f.eks. via ${{name}} (job-navn) eller ${{creation_context.trigger_time}} (trigger-tid) som makroer i input-stier eller string-parametere.

2. Retraining Pipeline Arkitektur

En komplett retraining-pipeline består typisk av flere tasks orkestrert som en multi-task workflow:

Task 1: Model Training

• Last inn nyeste produksjonsdata fra data catalog (Unity Catalog eller Azure ML datastores)
• Kjør feature engineering (on-demand features eller feature tables)
• Tren modellen med valgte hyperparametere (kan være statiske eller dynamiske)
• Logg modell, metrics og parametere til MLflow Tracking Server
• Registrer modellen til Unity Catalog (Databricks) eller Azure ML Model Registry

Verified (MCP): Azure ML støtter AutoMLStep for automatisk feature selection og algorithm selection i pipelines, men for produksjonsretraining anbefales det å begrense tuning til top-performing options for å redusere variance.

Task 2: Model Validation

• Last modell fra registry via model URI (fra Task 1)
• Kjør pre-deployment checks:
  • Format- og metadata-validering
  • Performance-evaluering på test-sett eller data slices
  • Compliance-sjekker (regulatoriske krav, organisatoriske policies)
• Sett "Challenger"-alias hvis validering lykkes
• Logg resultat som tags/annotations på modellversjon

Task 3: Model Deployment

• Sammenlign "Challenger" mot eksisterende "Champion"-modell
  • Offline: Evaluer begge på holdt-ut datasett
  • Online: A/B-testing eller gradvis rollout
• Oppdater "Champion"-alias til ny modell hvis performance er bedre
• Oppdater Model Serving endpoint (real-time) eller batch inference pipeline

Verified (MCP): Azure ML støtter task values for å sende model URI mellom tasks i en pipeline, f.eks.:

from azureml.pipeline.core import Pipeline

pipeline = Pipeline(ws, [train_step, validate_step, deploy_step])

3. Triggered Retraining (Event-Driven)

Scheduled retraining er enklest å implementere, men triggered retraining gir raskere respons på endringer:

Databricks-mønster (Verified MCP):

1. Data profiling pipeline leser logs fra batch/streaming/online inference
2. Beregner metrics (data drift, model performance, infrastructure)
3. Skriver metrics til tabeller i production catalog
4. SQL alert sjekker om metric overskrider threshold
5. Alert konfigureres med webhook destination som trigger training workflow

Eksempel SQL-alert som trigger retraining:

-- Alert trigger hvis accuracy faller under 85%
SELECT AVG(accuracy) as avg_accuracy
FROM prod.monitoring.model_metrics
WHERE timestamp >= current_date() - INTERVAL 7 DAYS

-- Webhook destination: <databricks-job-url>

Azure ML-mønster (Baseline): Azure ML SDK v2 støtter ikke event-based triggers natively, men kan integreres med:

• Azure Event Grid for lifecycle events (model registered, deployment completed)
• Azure Data Factory for external orchestration med event triggers
• Azure Functions med HTTP triggers som starter Azure ML pipelines via REST API

Verified (MCP): Azure ML schedules kan kalles via REST endpoint:

# Publish pipeline to get REST endpoint
published_pipeline = pipeline_run.publish_pipeline(
    name="Retraining Pipeline",
    description="Automated model retraining"
)

rest_endpoint = published_pipeline.endpoint
# Use with OAuth 2.0 bearer token for authentication

4. Pipeline Inputs og Runtime Settings

Verified (MCP): Ved scheduling kan du overstyre pipeline-settings, inputs og outputs:

create_job:
  type: pipeline
  job: ./pipeline.yml
  settings:
    continue_on_step_failure: true
    default_compute: azureml:cpu-cluster
  inputs:
    training_data: ${{name}}  # Dynamisk satt til schedule-navn
  tags:
    schedule: nightly_retraining

Dette gjør det mulig å opprette multiple schedules for samme pipeline med forskjellige parametere (f.eks. forskjellige datasett eller hyperparametere).

---

Arkitekturmønstre

Mønster 1: Periodic Scheduled Retraining (Azure ML)

Use case: Ny treningsdata tilgjengelig med jevne intervaller (daglig, ukentlig).

Arkitektur:

1. Schedule trigger pipeline hver natt kl. 02:00 (cron: 0 2 * * *)
2. Training pipeline henter latest data fra registered dataset eller datastore
3. Validation sammenligner ny modell mot baseline metrics
4. Deployment oppdaterer batch inference endpoint eller Model Serving

Fordeler:

• Enkel å implementere og forstå
• Forutsigbar ressursbruk (kan bruke reserved capacity)
• God for use cases med regular data refresh

Ulemper:

• Reagerer ikke umiddelbart på drift eller performance issues
• Kan trene unødvendig ofte hvis data ikke har endret seg

Kodeeksempel (Verified MCP):

from azure.ai.ml import MLClient, load_job
from azure.ai.ml.entities import JobSchedule, CronTrigger

ml_client = MLClient.from_config()

# Last eksisterende pipeline
pipeline_job = load_job("./training_pipeline.yml")

# Opprett nattlig schedule
cron_trigger = CronTrigger(
    expression="0 2 * * *",
    time_zone="Europe/Oslo"
)

schedule = JobSchedule(
    name="nightly_model_retraining",
    trigger=cron_trigger,
    create_job=pipeline_job
)

ml_client.schedules.begin_create_or_update(schedule).result()

Mønster 2: Triggered Retraining via Monitoring (Databricks)

Use case: Retraining kun når data drift eller performance degradering detekteres.

Arkitektur (Verified MCP):

1. Inference pipeline logger predictions til Unity Catalog tables
2. Data profiling pipeline (scheduled hourly) beregner:
   • Data drift metrics (distribution changes)
   • Model performance (accuracy, F1-score vs. ground truth)
   • Infrastructure metrics (latency, throughput)
3. SQL alert trigger når metric overskrider threshold:

   SELECT AVG(drift_score) as avg_drift
   FROM prod.monitoring.data_drift
   WHERE timestamp >= current_timestamp() - INTERVAL 1 HOUR
   HAVING avg_drift > 0.3  -- Threshold for retraining
   

4. Alert webhook starter training workflow via Databricks Jobs API
5. Training pipeline kjører full training → validation → deployment cycle

Fordeler:

• Rask respons på faktiske endringer
• Redusert ressursbruk (ingen unødvendig retraining)
• Self-healing system (automatic recovery fra model decay)

Ulemper:

• Mer kompleks å sette opp
• Krever robust monitoring infrastructure
• Potensiale for "thrashing" hvis thresholds ikke er riktig kalibrert

Mønster 3: Hybrid Scheduled + Triggered (Azure ML + Event Grid)

Baseline: Kombinerer periodic baseline retraining med event-driven responses.

Arkitektur:

1. Baseline schedule: Ukentlig full retraining (søndag natt)
2. Event-driven: Azure Event Grid subscriber på:
   • Dataset updated events (når ny data publiseres)
   • Custom metrics events (fra monitoring system)
3. Event trigger Azure Function som kaller Azure ML pipeline REST endpoint
4. Pipeline har conditional logic for å hoppe over retraining hvis siste versjon er nylig (<24h gammel)

Fordeler:

• Best of both worlds (forutsigbarhet + responsiveness)
• Unngår duplicate retraining ved overlappende triggers

Ulemper:

• Krever flere Azure-tjenester (Event Grid, Functions)
• Mer kompleks dependency management

---

Beslutningsveiledning

Når bruke scheduled vs. triggered retraining?

Kriterium	Scheduled	Triggered
Data refresh-frekvens	Regulær (daglig/ukentlig)	Uregelmessig eller kontinuerlig
Model decay rate	Langsom og forutsigbar	Rask eller uforutsigbar
Compliance-krav	Trenger dokumentert retraining-kadanse	Trenger bevis for continuous monitoring
Ressursbudsjettering	Reserved capacity (forutsigbar kostnad)	On-demand (variabel kostnad)
Time-to-recovery	Akseptabelt med dager/uker	Krever timer eller mindre
Kompleksitet	Lav (enkelt å vedlikeholde)	Høy (krever monitoring infrastructure)

Anbefaling for offentlig sektor (Norge):

• Start med scheduled retraining (enklere å godkjenne i arkitekturgjennomgang)
• Implementer triggered retraining kun hvis dokumentert behov for rapid response
• Kombiner med manual approval step for kritiske modeller (compliance)

Valg mellom Azure ML og Databricks

Feature	Azure ML	Databricks
Native scheduling	✅ SDK v2 (recurrence + cron)	✅ Databricks Jobs (cron + event)
Event-driven triggers	❌ (via Event Grid/ADF)	✅ (SQL alerts + webhooks)
Data governance	Azure ML datastores	Unity Catalog (bedre governance)
Model registry	Azure ML Model Registry	Unity Catalog Models (med aliaser)
AutoML integration	✅ AutoMLStep i pipelines	✅ AutoML på Databricks Runtime
Hybrid cloud support	❌ (kun Azure)	✅ (multi-cloud med Unity Catalog)
Cost visibility	Logic App charges (HOBO)	Databricks Jobs (transparent)

Verified (MCP): Azure ML schedules oppretter en Logic App som hostes "on behalf of" (HOBO) brukeren, og kostnaden belastes via samme meter som Azure ML workspace.

Anbefaling:

• Azure ML: Hvis allerede investert i Azure ML ecosystem, enkle use cases, AutoML-behov
• Databricks: For lakehouse-arkitekturer, kompleks governance, multi-cloud requirements

---

Integrasjon med Microsoft-stakken

Azure Machine Learning Pipelines

Verified (MCP): Azure ML SDK v2 bruker component-based pipelines hvor hver komponent er en gjenbrukbar kode-modul:

from azure.ai.ml import command, Input, Output
from azure.ai.ml.constants import AssetTypes

# Definer training component
train_component = command(
    name="train_model",
    display_name="Model Training",
    inputs={
        "training_data": Input(type=AssetTypes.URI_FOLDER),
        "max_epochs": Input(type="integer", default=20),
        "learning_rate": Input(type="number", default=0.001),
    },
    outputs={
        "model_output": Output(type=AssetTypes.MLFLOW_MODEL),
    },
    code="./src",
    command="python train.py --data ${{inputs.training_data}} --epochs ${{inputs.max_epochs}}",
    environment="azureml:my-training-env@latest",
)

# Bruk i pipeline
@pipeline()
def training_pipeline(training_data, max_epochs):
    train_step = train_component(
        training_data=training_data,
        max_epochs=max_epochs
    )
    validate_step = validate_component(model=train_step.outputs.model_output)
    deploy_step = deploy_component(model=validate_step.outputs.validated_model)
    return {"deployed_model": deploy_step.outputs.endpoint_url}

Azure Databricks MLOps Workflow

Verified (MCP): Databricks anbefaler "deploy code, not models" — promoter kode fra dev → staging → prod branches:

1. Dev catalog: Data scientists har read-write access, trener modeller interaktivt
2. Staging catalog: CI/CD pipeline kjører integration tests på staging data
3. Prod catalog: Automated retraining pipeline kjører på production data, ML engineers har read-write access

Unity Catalog model aliasing:

from databricks import unity_catalog

# Training pipeline output
model_uri = "models:/prod.ml_models.fraud_detection/12"  # Version 12

# Validation pipeline
uc_client = unity_catalog.get_client()
uc_client.set_model_version_tag(
    model_uri,
    key="validation_status",
    value="PASSED"
)

# Deployment pipeline - sammenlign Challenger vs Champion
challenger_uri = "models:/prod.ml_models.fraud_detection@Challenger"
champion_uri = "models:/prod.ml_models.fraud_detection@Champion"

if challenger_accuracy > champion_accuracy:
    uc_client.set_registered_model_alias(
        name="prod.ml_models.fraud_detection",
        alias="Champion",
        version=12
    )

Azure DevOps / GitHub Actions Integration

Baseline: CI/CD pipelines kan automatisere deployment av retraining schedules:

# .github/workflows/deploy-retraining-schedule.yml
name: Deploy Retraining Schedule

on:
  push:
    branches: [main]
    paths: [pipelines/training/**]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Deploy Azure ML Schedule
        run: |
          az ml schedule create \
            --file schedules/nightly-retraining.yml \
            --resource-group ${{ secrets.RG_NAME }} \
            --workspace-name ${{ secrets.WORKSPACE_NAME }}

---

Offentlig sektor (Norge)

Utredningsinstruksen og Retraining

Relevant for: Automatisert retraining i AI-systemer som behandler personopplysninger eller påvirker borgernes rettigheter.

Krav:

1. Dokumentasjon av retraining-strategi i AI-utredningen (kapittel 4: Teknisk løsning)

   • Frekvens for retraining (scheduled vs. triggered)
   • Validering av nye modellversjoner før deployment
   • Rollback-prosedyre ved performance degradering

2. Logging og sporbarhet:

   • Alle retraining-kjøringer må logges med timestamp, data version, model version
   • MLflow/Unity Catalog gir automatisk lineage tracking
   • Eksporter audit logs til langtidslagring (arkivloven)

3. Human-in-the-loop for kritiske modeller:

   • Automatisert retraining kan kjøre validation, men final deployment krever manuell godkjenning
   • Implementer approval gates i Azure DevOps Pipelines eller Databricks workflows

Eksempel approval gate (Azure DevOps):

# azure-pipelines.yml
stages:
  - stage: Train
    jobs:
      - job: RunTraining
        steps:
          - script: az ml job create --file training-pipeline.yml

  - stage: Validate
    jobs:
      - job: ValidateModel
        steps:
          - script: python validate_model.py

  - stage: Deploy
    dependsOn: Validate
    jobs:
      - deployment: DeployModel
        environment: production  # Krever manual approval i Azure DevOps
        strategy:
          runOnce:
            deploy:
              steps:
                - script: python deploy_model.py

DPIA-vurdering av Automatisert Retraining

Personvernrisiko:

• Ny treningsdata kan introdusere bias → krever automated bias detection i validation pipeline
• Model drift kan påvirke beslutninger → implementer A/B testing før full rollout
• Logging av retraining kan inkludere persondata → pseudonymiser eller anonymiser logs

Tiltak:

• Bruk Azure ML differential privacy features for sensitive data
• Implementer fairness metrics i validation pipeline (Fairlearn integration)
• Dokumenter data retention policy for training data og logs

Digdir Cloud Strategy og Multi-Cloud Retraining

Databricks fordel: Unity Catalog støtter multi-cloud (Azure + AWS + GCP), nyttig for:

• Data residency-krav (treningsdata i Norge, inference i andre regioner)
• Vendor lock-in avoidance (kan flytte retraining pipeline mellom clouds)

Azure ML begrensning: Kun Azure-native, men kan integreres med Azure Arc for hybrid cloud.

---

Kostnad og lisensiering

Azure Machine Learning Schedule Costs

Verified (MCP): Schedules oppretter en Logic App (HOBO-ressurs) som belastes brukeren:

Komponent	Kostnad	Forklaring
Schedule (Logic App)	~$0.000025 per trigger	Standard Logic App pricing
Pipeline compute	Varierer (per SKU)	Compute for training/validation/deployment tasks
Storage	~$0.02/GB/måned	MLflow artifacts, logs, model registry

Eksempel (nattlig retraining):

• 30 triggers/måned × $0.000025 = $0.00075/måned (neglisjerbart)
• Compute (Standard_DS12_v2, 2 timer/natt): ~$0.28/time × 60 timer/måned = $16.80/måned
• Total estimat: ~$17/måned (eksklusive storage)

Kostnadsoptimalisering:

• Bruk spot instances (Azure ML low-priority compute) for training — 60-80% rabatt
• Reduser retraining-frekvens hvis mulig (ukentlig vs. daglig)
• Bruk incremental learning i stedet for full retraining hvis mulig

Azure Databricks Schedule Costs

Databricks Jobs (retraining):

• DBU cost: ~$0.40/DBU (Jobs compute tier, region-avhengig)
• VM cost: Underliggende Azure VMs (f.eks. Standard_DS3_v2: ~$0.20/time)
• Unity Catalog: Inkludert i Databricks-lisens (ingen ekstra kostnad)

Eksempel (nattlig retraining på cluster med 4 nodes):

• 4 nodes × 2 DBU/node × 2 timer × 30 dager = 480 DBU/måned
• 480 DBU × $0.40 = $192/måned (DBU cost)
• VM cost: 4 nodes × $0.20/time × 2 timer × 30 dager = $48/måned
• Total estimat: ~$240/måned

Kostnadsoptimalisering:

• Bruk job clusters (auto-terminate etter kjøring) vs. all-purpose clusters
• Implementer conditional retraining (skip hvis data ikke har endret seg)
• Reduser cluster size (scale down nodes for mindre datasett)

Lisensieringskrav

Plattform	Lisens	Retraining Support
Azure ML	Gratis (betaler kun compute/storage)	✅ Native scheduling
Databricks	Premium eller Enterprise	✅ Jobs + Unity Catalog
Azure DevOps	Basic (gratis for <5 brukere)	✅ CI/CD pipelines
GitHub Actions	Gratis (public repos, 2000 min/måned private)	✅ CI/CD workflows

For offentlig sektor (Norge):

• Azure ML er typisk allerede inkludert i enterprise agreement
• Databricks krever separat lisens (Premium tier minimum for Unity Catalog)
• Vurder total cost of ownership (TCO) over 3 år, ikke bare lisenskostnad

---

For arkitekten (Cosmo)

Spørsmål å stille klienten

1. Data refresh-frekvens:

   • "Hvor ofte får dere ny treningsdata?" (daglig/ukentlig/kontinuerlig)
   • "Hvor raskt må modellen respondere på endringer i data?" (timer/dager/uker)

2. Model decay-karakteristikk:

   • "Har dere erfaring med hvor raskt modellen degraderes i produksjon?"
   • "Finnes det sesongvariasjoner eller plutselige regime shifts?"

3. Compliance og governance:

   • "Krever modellendringer manuell godkjenning før deployment?"
   • "Må alle retraining-kjøringer dokumenteres for revisjon/arkivering?"

4. Eksisterende infrastruktur:

   • "Bruker dere allerede Azure ML eller Databricks for ML-utvikling?"
   • "Har dere etablert CI/CD-pipelines (Azure DevOps/GitHub Actions)?"

5. Ressursbudsjettering:

   • "Hva er budsjett for compute-ressurser til retraining?" (kan påvirke frekvens)
   • "Er det akseptabelt med variabel kostnad (triggered) eller foretrekkes forutsigbar (scheduled)?"

Arkitekturvalg-flytdiagram

START: Trenger dere automatisert retraining?
  |
  ├─> JA → Hvor ofte kommer ny data?
  |         |
  |         ├─> Regulært (daglig/ukentlig) → SCHEDULED RETRAINING
  |         |     |
  |         |     └─> Plattformvalg:
  |         |           ├─> Har Azure ML? → Azure ML Schedules (recurrence/cron)
  |         |           └─> Har Databricks? → Databricks Jobs (scheduled)
  |         |
  |         └─> Uregelmessig/kontinuerlig → TRIGGERED RETRAINING
  |               |
  |               └─> Plattformvalg:
  |                     ├─> Azure ML → Hybrid (Event Grid + Azure Functions)
  |                     └─> Databricks → SQL alerts + webhooks
  |
  └─> NEI → Manual retraining workflow (out of scope)

Trade-offs å kommunisere

Dimensjon	Scheduled	Triggered
Implementeringskompleksitet	⭐⭐ (Lav)	⭐⭐⭐⭐ (Høy)
Time-to-value	🟢 Rask (dager)	🟡 Middels (uker)
Operasjonell robusthet	🟢 Høy (enkel troubleshooting)	🟡 Middels (krever monitoring expertise)
Kostnadseffektivitet	🟡 Middels (kan trene unødvendig)	🟢 Høy (kun når nødvendig)
Compliance-vennlighet	🟢 Høy (forutsigbar, lett å dokumentere)	🟡 Middels (krever event audit trail)

Anti-patterns å unngå

1. Over-engineering: Ikke implementer triggered retraining hvis scheduled er tilstrekkelig
2. Insufficient validation: Aldri deploy retraining uten validation pipeline (minimum accuracy threshold check)
3. Ignoring cost: Monitor schedule costs (especially for high-frequency retraining)
4. Manual steps i automated pipeline: Bryt heller opp i "automated validation" + "manual approval" + "automated deployment"
5. Missing rollback: Ha alltid en plan for å rulle tilbake til forrige "Champion"-modell ved feil

Anbefalinger for offentlig sektor

1. Start konservativt:

   • Implementer scheduled retraining først (ukentlig)
   • Legg til monitoring og alerting
   • Vurder triggered retraining etter 3-6 måneder med produksjonserfaring

2. Dokumenter alt:

   • Bruk Azure DevOps wiki eller Confluence til å dokumentere:
     • Retraining schedule rationale
     • Validation criteria
     • Deployment approval process
   • Eksporter MLflow logs til Azure Blob Storage (immutable, retention policy)

3. Lag human-in-the-loop approval:

   • For kritiske modeller (helse, rettigheter, økonomi): alltid manuell godkjenning før deployment
   • For lavrisiko modeller: automated deployment med post-deployment monitoring

4. Implementer observability:

   • Azure Monitor for pipeline failures
   • Application Insights for model serving latency/errors
   • Custom dashboards (Azure Dashboards eller Power BI) for stakeholders

Integrasjon med andre AI Architect-filer

• CI/CD for ML: Les cicd-for-ai.md for pipeline deployment patterns
• Model monitoring: Les model-monitoring.md for drift detection og alerting
• Cost optimization: Les token-caching-strategies.md for generell kostnadsoptimalisering
• Governance: Les norwegian-public-sector-checklist.md for compliance-krav

---

Kilder og verifisering

Verified (MCP-kilder)

1. Azure ML Schedule Documentation: https://learn.microsoft.com/en-us/azure/machine-learning/how-to-schedule-pipeline-job?view=azureml-api-2 Verifisert 2026-02: Recurrence/cron triggers, schedule management, RBAC, cost model (Logic App HOBO)

2. Databricks MLOps Workflows: https://learn.microsoft.com/en-us/azure/databricks/machine-learning/mlops/mlops-workflow Verifisert 2026-02: Scheduled vs. triggered retraining, SQL alerts, webhook triggers, Unity Catalog aliasing

3. Azure ML Code Samples (Python SDK v2): https://github.com/Azure/azureml-examples (via microsoft_code_sample_search) Verifisert 2026-02: RecurrenceTrigger, CronTrigger, JobSchedule, task values

4. Azure ML AutoML in Pipelines: https://learn.microsoft.com/en-us/azure/machine-learning/how-to-use-automlstep-in-pipelines?view=azureml-api-1 Verifisert 2026-02: AutoMLStep configuration, data inputs, model registration

Baseline (Modellkunnskap)

1. Azure Event Grid integration (ikke native i Azure ML SDK v2, men well-documented pattern)
2. Azure DevOps approval gates (standard DevOps practice, ikke ML-spesifikk)
3. Databricks multi-cloud capabilities (general knowledge om Unity Catalog)
4. Differential privacy i Azure ML (feature i preview, ikke fully GA)

Leseverdi for dypere forståelse

• The Big Book of MLOps (Databricks): https://www.databricks.com/resources/ebook/the-big-book-of-mlops
• MLOps Maturity Model: https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/mlops-maturity-model
• Azure ML CLI v2 Reference: https://learn.microsoft.com/en-us/cli/azure/ml/schedule?view=azure-cli-latest

Total MCP-kilder: 4 unique URLs Total kodeeksempler verifisert: 8 (Python SDK v2, YAML, SQL)

---

Denne filen er generert av Cosmo Skyberg, Microsoft AI Solution Architect, som del av AI Architect Plugin kunnskapsbase. Sist oppdatert: 2026-02-04.