ktg-plugin-marketplace/plugins/ms-ai-architect/skills/ms-ai-engineering/references/mlops-genaiops/mlops-fundamentals-overview.md

MLOps Fundamentals - Lifecycle and Principles

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

---

Verified: MCP 2026-04

Introduksjon

Machine Learning Operations (MLOps) er anvendelse av DevOps-prinsipper på machine learning-prosjekter. Målet er å automatisere og effektivisere hele ML-livssyklusen – fra eksperimentering og trening, via deployment, til overvåking og retrening. MLOps bygger på etablert DevOps-praksis som continuous integration (CI), continuous deployment (CD), version control, og infrastructure as code (IaC), men legger til ML-spesifikke utfordringer som data versioning, model tracking, feature engineering, og drift detection.

I motsetning til tradisjonell applikasjonsutvikling, hvor kode er deterministisk, opererer ML-modeller med data som en kjerneavhengighet. Dette introduserer ekstra kompleksitet: modeller må retrenes når data endrer seg, modellytelse kan degradere over tid (model decay), og reproduserbarhet krever versjonering av både kode, data, og miljøer. MLOps adresserer disse utfordringene ved å tilby strukturerte prosesser og verktøy for model lifecycle management.

Microsoft tilbyr Azure Machine Learning som primærplattform for MLOps, med integrert støtte for pipelines, model registries, automated retraining, monitoring, og integrasjon med Azure DevOps og GitHub Actions. MLOps-modenhet måles typisk langs en 5-nivåskala (Level 0-4), hvor organisasjoner gradvis beveger seg fra manuelle prosesser til fullautomatisert CI/CD/CT (Continuous Training).

Kjernekomponenter

MLOps-livssyklusen består av flere distinkte faser, ofte kategorisert som "inner loop" (data science-fokusert) og "outer loop" (engineering/operations-fokusert).

Inner Loop (Data Science)

Komponent	Beskrivelse	Ansvarlig rolle
Data Collection	Innhenting og aggregering av treningsdata fra produksjonskilder	Data Engineer
Data Preparation	Rensing, validering, transformasjon, og feature engineering	Data Scientist + Data Engineer
Model Training	Eksperimentering, hyperparameter tuning, modellutvikling	Data Scientist
Model Evaluation	Validering av modellytelse mot acceptance criteria	Data Scientist

Outer Loop (ML Engineering)

Komponent	Beskrivelse	Ansvarlig rolle
Model Packaging	Containerisering av modell med dependencies (Docker)	ML Engineer
Model Registration	Versjonering og lagring i model registry	ML Engineer
Model Deployment	Utrulling til inference endpoints (batch/online)	ML Engineer + DevOps
Model Monitoring	Overvåking av ytelse, drift, og data quality	ML Engineer + Data Scientist
Model Retraining	Automatisk eller manuell retrening ved degradering	Data Scientist + ML Engineer

MLOps Capabilities (Azure ML)

1. Reproducible ML Pipelines – Definere gjenbrukbare steps for data prep, training, scoring
2. Reusable Environments – Version-controlled conda/pip environments for consistency
3. Model Registry – Sentralisert lagring med metadata (hvem, hva, når, hvorfor)
4. Lineage Tracking – Full sporbarhet fra raw data til deployed model
5. Event-Driven Automation – Azure Event Grid for lifecycle events (training complete, drift detected)
6. Monitoring & Alerting – Sentralisert innsamling av metrics (model performance, data drift, infrastructure)
7. CI/CD Integration – Azure Pipelines, GitHub Actions, eller andre CI/CD-verktøy

Arkitekturmønstre

MLOps-arkitekturen følger typisk fire hovedfaser: Data Estate, Administration & Setup, Model Development (Inner Loop), og Model Deployment (Outer Loop).

Pattern 1: Manual MLOps (Level 0)

Scenario: Ingen formalisert MLOps-prosess. Data scientists jobber isolert, leverer modeller som filer.

Karakteristikker:

• Manuell datahenting og modelltrening
• Ingen eksperiment tracking eller version control
• Modeller deployes manuelt av data scientist
• Ingen sentralisert monitoring

Når bruke:

• POC/prototyping-faser
• Små team uten dedikert ML engineering
• Lav modell refresh-frekvens

Risiko: Ikke-reproduserbar, vanskelig å skalere, høy avhengighet av individer.

Pattern 2: Automated Training (Level 2)

Scenario: Treningsprosessen er automatisert og sporbar, men deployment er fortsatt manuell.

Karakteristikker:

• Automatiserte data pipelines
• Managed compute (Azure ML Compute)
• Experiment tracking (MLflow)
• Model registry med versioning
• Scheduled eller event-driven retrening
• Manuell release til produksjon

Når bruke:

• Team med data scientists + data engineers, men begrenset DevOps-kapasitet
• Moderat modell refresh-frekvens (ukentlig/månedlig)
• Kontrollert release-prosess med QA gates

Teknologi: Azure ML Pipelines, Azure Event Grid, Managed Feature Store.

Pattern 3: Full CI/CD/CT (Level 4)

Scenario: Fullautomatisert end-to-end MLOps med zero-touch deployment og self-healing.

Karakteristikker:

• Automatisk datapipeline og modelltrening
• Automatisk A/B testing og blue-green deployment
• Policy-basert model promotion (registries)
• Drift detection trigger automatic retraining
• Sentralisert monitoring med auto-alerting
• Infrastructure as Code (Bicep/Terraform)

Når bruke:

• Store team med dedikert ML Platform Engineering
• Høyfrekvent modell refresh (daglig/real-time)
• Kritiske produksjonssystemer med SLA-krav

Teknologi: Azure ML CLI/SDK v2, Azure DevOps, Event Grid, Azure Monitor, ML Registries.

Beslutningsveiledning

Velge riktig modenhetsnivå

Kriterium	Level 0-1	Level 2	Level 3-4
Team size	1-3 personer	3-10 personer	10+ personer
Modeller i prod	1-2	3-10	10+
Refresh-frekvens	Månedlig/kvartalsvis	Ukentlig	Daglig/kontinuerlig
Compliance-krav	Lave	Moderate	Høye (regulerte sektorer)
DevOps-kapasitet	Ingen	Begrenset	Dedikert team
SLA-krav	Best effort	95% uptime	99%+ uptime

Vanlige feil (Anti-patterns)

Feil	Konsekvens	Løsning
Ingen data versioning	Umulig å reprodusere modeller	Bruk Azure ML Datasets med versioning
Manuell deployment	Høy risiko for feil, ingen rollback	Implementer CI/CD med automated tests
Ingen drift monitoring	Modeller degraderer uoppdaget	Implementer data drift detection + alerting
Tight coupling	Endringer i én komponent bryter hele systemet	Bruk modular pipelines med klare interfaces
Manglende lineage	Umulig å spore root cause ved feil	Aktiver full lineage tracking i Azure ML

Røde flagg

• "Vi retrainer modellen når noen husker det" → Ingen scheduled retraining
• "Modellen ligger på data scientist sin laptop" → Ingen model registry
• "Vi vet ikke hvilke data som ble brukt til trening" → Ingen data lineage
• "Deployment tar 2 uker" → Ingen CI/CD automation
• "Vi oppdager model decay når brukere klager" → Ingen proactive monitoring

Integrasjon med Microsoft-stakken

Azure Machine Learning

Primærplattform for MLOps. Tilbyr:

• Azure ML Pipelines – Orchestration av training/deployment workflows
• Model Registry – Sentralisert model versioning + promotion
• Managed Endpoints – Online (real-time) og Batch inference
• Environments – Reproducible conda/docker environments
• Compute Targets – Managed compute clusters (CPU/GPU)

Integrasjonspunkter:

• Azure DevOps – CI/CD pipelines via Azure Pipelines extension
• GitHub Actions – GitHub integration for MLOps workflows
• Azure Event Grid – Event-driven automation (model registered, drift detected)
• Azure Monitor – Centralized logging + alerting

Azure DevOps

CI/CD orchestration. Bruk for:

• Azure Pipelines – Automated testing, model training, deployment
• Azure Repos – Source control for training code, pipeline definitions
• Azure Boards – Agile planning (sprints, backlog)

Sample pipeline (YAML):

trigger:
- main

variables:
  service-connection: 'ml-service-connection'
  resource-group: 'ml-rg'
  workspace: 'ml-workspace'

jobs:
- job: SubmitMLJob
  pool:
    vmImage: ubuntu-latest
  steps:
  - task: UsePythonVersion@0
    inputs:
      versionSpec: '>=3.10'
  - bash: |
      az extension add -n ml
    displayName: 'Add Azure ML CLI'
  - task: AzureCLI@2
    inputs:
      azureSubscription: $(service-connection)
      scriptType: bash
      inlineScript: |
        az ml job create --file pipeline.yml \
          -g $(resource-group) \
          -w $(workspace)

GitHub Actions

Alternative til Azure DevOps. Bruk for:

• Open source-prosjekter
• Team som allerede bruker GitHub
• Enklere setup for mindre team

Sample workflow:

name: Train and Deploy ML Model
on:
  push:
    branches: [main]
jobs:
  train:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - uses: azure/login@v1
      with:
        creds: ${{ secrets.AZURE_CREDENTIALS }}
    - run: |
        az extension add -n ml
        az ml job create --file pipeline.yml

Azure AI Foundry

For generative AI workloads. MLOps-prinsipper gjelder, men med tillegg:

• Prompt versioning – Prompt engineering som kode
• RAG pipelines – Vector ingestion + indexing automation
• Safety monitoring – Content filtering + responsible AI metrics
• Token cost tracking – GenAIOps-spesifikk

Husk: GenAIOps er supplement til MLOps, ikke erstatning. Bruk MLOps Maturity Model + GenAIOps Maturity Model separat.

Offentlig sektor (Norge)

Compliance og revisjon

Riksrevisjonen og Difi-krav krever:

• Full sporbarhet – Hvem trente modellen, med hvilke data, når?
• Reproducerbarhet – Kunne gjenskape nøyaktig samme modell
• Auditability – Logging av alle endringer i model lifecycle
• Explainability – Kunne forklare modellbeslutninger (GDPR Art. 22)

Azure ML støtter:

• Lineage tracking – Automatisk logging av data → model → deployment
• Model interpretability – SHAP, LIME integration
• Audit logs – Azure Monitor + Log Analytics
• Tags og metadata – Custom tags for organisasjonsspesifikke krav

Datahåndtering

Personvern (GDPR/Datatilsynet):

• Data må lagres i EU/Norge (Azure Norway East/West)
• Samtykke må versjoneres sammen med data
• Rett til sletting må implementeres (data deletion pipelines)

Anbefaling: Bruk Azure ML Datasets med:

• Data versioning – Immutable snapshots
• Access control – RBAC på dataset-nivå
• Encryption – At rest (Storage Account) + in transit (HTTPS)

Dokumentasjonskrav

For hver modell i produksjon:

• Model Card – Beskrivelse av modell, use case, limitations
• Training Data Spec – Hvilke data, tidsperiode, pre-processing
• Performance Metrics – Accuracy, precision, recall, etc.
• Bias Assessment – Fairness metrics per demografisk gruppe
• Retraining Policy – Når og hvorfor modellen retrenes

Automatiser: Generer Model Cards automatisk som del av CI/CD pipeline.

Kostnad og lisensiering

Azure Machine Learning prising

Compute Costs (primær kostnad):

• Training Compute – Azure ML Compute Clusters (pay-per-use)
  • CPU: ~3-15 NOK/time (avhengig av VM size)
  • GPU: ~50-300 NOK/time (NC-series, ND-series)
• Inference Compute – Managed Online Endpoints
  • CPU: ~2-10 NOK/time
  • GPU: ~40-200 NOK/time
• Batch Inference – Samme som training compute (pay-per-job)

Storage Costs:

• Azure Blob Storage – ~0.15 NOK/GB/måned (standard tier)
• Model Registry Storage – Inkludert i Blob Storage

Optimaliseringstips:

• Bruk auto-shutdown på compute clusters (idle timeout)
• Bruk low-priority VMs for ikke-kritiske training jobs (60-80% rabatt)
• Implementer model caching for å unngå retraining
• Bruk serverless compute for mindre workloads (ny funksjon)

DevOps-verktøy

DevOps for Machine Learning — Azure DevOps Integration (Verified MCP 2026-04)

Azure Pipelines + Azure ML (how-to-devops-machine-learning):

Automate the ML lifecycle via Azure DevOps pipelines:

1. Data preparation (ETL)
2. On-demand scale-out training
3. Model deployment (public/private web service)
4. Monitoring (performance, data drift)

Prerequisite: Python >=3.10 required for Azure ML SDK v2 scripts. Install Azure Machine Learning extension for Azure Pipelines from VS Marketplace.

Authentication options (Verified MCP 2026-04):

• Azure Resource Manager service connection (recommended) — use with AzureMLJobWaitTask@1 from Azure ML extension
• Generic service connection — use with InvokeRESTAPI task calling REST API directly (api-version: 2024-04-01)

Azure DevOps pipeline YAML pattern (ARM service connection):

- task: AzureCLI@2
  name: submit_azureml_job_task
  inputs:
    azureSubscription: $(service-connection)
    scriptType: bash
    inlineScript: |
      job_name=$(az ml job create --file pipeline.yml -g $(resource-group) -w $(workspace) --query name --output tsv)
      echo "##vso[task.setvariable variable=JOB_NAME;isOutput=true;]$job_name"

- job: WaitForJobCompletion
  pool: server  # Server job — no agent costs, runs on pipeline machine
  dependsOn: SubmitAzureMLJob
  steps:
  - task: AzureMLJobWaitTask@1  # From Azure ML extension (not "classic")
    inputs:
      serviceConnection: $(service-connection)
      resourceGroupName: $(resource-group)
      azureMLWorkspaceName: $(workspace)
      azureMLJobName: $(azureml_job_name_from_submit_job)

Note: AzureMLJobWaitTask@1 runs as a server job (no agent pool costs). Max wait: 2 days (Azure DevOps hard limit). Use AzureMLJobWaitTask@1, not the legacy "Machine Learning (classic)" extension.

MLOps maturity model: Manual → Partial automation → Full CI/CD → Full MLOps with monitoring

Key automation operations (Azure DevOps):

• Infrastructure deployment (Terraform / Bicep)
• Component registration and versioning
• Model training on compute clusters
• Online/batch endpoint deployment
• Production monitoring alerts

Verktøy	Kostnad	Anbefaling
Azure DevOps	Gratis for 5 brukere + 1800 min/mnd pipeline	Bruk Basic plan for mindre team
GitHub Actions	Gratis for public repos, 2000 min/mnd private	Vurder ved open source
Azure Event Grid	~0.50 NOK per 100k events	Neglisjerbar for de fleste
Azure Monitor	~25 NOK/GB ingested logs	Konfigurer log retention policies

TCO-sammenligning

Scenario: 10 modeller i produksjon, retrening ukentlig

Komponent	Level 0 (Manuell)	Level 2 (Automated Training)	Level 4 (Full MLOps)
Compute	~5 000 NOK/mnd	~8 000 NOK/mnd	~12 000 NOK/mnd
Storage	~500 NOK/mnd	~1 000 NOK/mnd	~2 000 NOK/mnd
Tooling	0 NOK	~500 NOK/mnd	~1 500 NOK/mnd
FTE-kostnad	2 FTE (manuelt arbeid)	1 FTE + 0.5 FTE	0.5 FTE (automated)
Total/år	~3M NOK (inkl. FTE)	~1.5M NOK	~800K NOK

ROI breakpoint: Full MLOps lønner seg typisk ved 5+ modeller i produksjon med månedlig/ukentlig refresh.

For arkitekten (Cosmo)

Spørsmål å stille kunden

1. Hvor mange modeller planlegger dere i produksjon innen 12 måneder? → Indikerer om Level 0-1 holder, eller om CI/CD er nødvendig.

2. Hvor ofte må modellene retrenes? → Daglig = krev Level 3-4, månedlig = Level 2 kan holde.

3. Har dere dedikert ML Engineering eller DevOps-kapasitet? → Nei = start med Level 1-2, Ja = sikt mot Level 3-4.

4. Hvilke compliance-krav har dere? (GDPR, ISO, Riksrevisjonen) → Høye krav = krev lineage tracking, explainability fra dag 1.

5. Hva er acceptable downtime for modell-inference? → <1% = krev blue-green deployment + automated rollback (Level 4).

6. Bruker dere allerede Azure DevOps eller GitHub? → Tilpass MLOps-stack til eksisterende tooling.

7. Har dere data scientists uten engineering-bakgrunn? → Vurder Azure ML Designer (low-code pipelines) eller Databricks.

8. Er dette discriminative models (klassisk ML) eller generative AI? → GenAI = legg til prompt versioning, RAG pipelines, safety monitoring.

Fallgruver per modenhetsnivå

Level 0-1:

• Feil: "Vi starter med manuelt, automatiserer senere" Risiko: Teknisk gjeld, umulig å migrere uten rewrites Anbefaling: Implementer minimum version control + experiment tracking fra dag 1.

Level 2:

• Feil: "Vi automatiserer trening, men deployment er QA-gated manuelt" Risiko: Bottleneck i deployment, modeller ligger udeployed i uker Anbefaling: Automatiser deployment til staging, men behold manual approval til prod.

Level 3-4:

• Feil: "Vi automatiserer alt, inkludert prod-deployment uten human-in-the-loop" Risiko: Dårlige modeller deployes automatisk, ingen rollback Anbefaling: Implementer automated quality gates (min accuracy threshold) + canary deployment (gradvis rollout).

Anbefalinger per scenario

Scenario	Anbefalt Level	Kritisk komponent	Verktøy
POC/Prototyping	Level 0-1	Experiment tracking	Azure ML Studio + Notebooks
Første produksjonsmodell	Level 2	Model registry + monitoring	Azure ML + GitHub Actions
5-10 modeller, moderat refresh	Level 2-3	Automated training + CI/CD	Azure ML + Azure DevOps
10+ modeller, høy refresh	Level 4	Full automation + drift detection	Azure ML + Event Grid + Monitoring
Regulert sektor (finans, helse)	Level 3+ (compliance)	Lineage + explainability	Azure ML + Model Cards + Audit Logs
Generative AI (RAG, LLM)	Level 2+ GenAIOps	Prompt versioning + safety	Azure AI Foundry + Prompt Flow

Quick Decision Tree

Er dette en POC?
├─ Ja → Level 0-1 (manuelt, men med experiment tracking)
└─ Nei → Er det <3 modeller?
    ├─ Ja → Level 2 (automated training)
    └─ Nei → Er det høyfrekvent retrening (ukentlig+)?
        ├─ Ja → Level 3-4 (full CI/CD/CT)
        └─ Nei → Level 2-3 (automated training + manual deployment)

Red Flags som krever eskalering

• Kunde vil "bygge egen MLOps-platform" → Styr mot Azure ML, ikke reinvent the wheel
• Ingen data governance → Blokkerer production-readiness, fiks data management først
• "Vi trenger ikke monitoring, modellen er ferdig trent" → Model decay er uunngåelig, påkrev monitoring
• Team uten ML Engineering → Vurder Databricks (managed platform) eller bygg kapasitet

Kilder og verifisering

Microsoft Learn (Verified via MCP)

1. MLOps Maturity Model https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/mlops-maturity-model Confidence: Verified – Offisiell dokumentasjon på modenhetsnivåer 0-4.

2. MLOps Model Management with Azure ML https://learn.microsoft.com/en-us/azure/machine-learning/concept-model-management-and-deployment?view=azureml-api-2 Confidence: Verified – Core MLOps capabilities, lifecycle management.

3. MLOps and GenAIOps for AI Workloads https://learn.microsoft.com/en-us/azure/well-architected/ai/mlops-genaiops Confidence: Verified – Workload operations lifecycle, automation, monitoring.

4. Concepts - MLOps for AI/ML Workflows (AKS) https://learn.microsoft.com/en-us/azure/aks/concepts-machine-learning-ops Confidence: Verified – DevOps principles applied to MLOps, inner/outer loop.

5. Azure ML Pipelines Overview https://learn.microsoft.com/en-us/azure/machine-learning/concept-ml-pipelines?view=azureml-api-2 Confidence: Verified – Pipeline orchestration, reproducibility.

6. Introduction to MLOps (Training Path) https://learn.microsoft.com/en-us/training/paths/introduction-machine-learn-operations/ Confidence: Verified – Learning path covering DevOps for ML, source control, automation, CD.

7. Machine Learning Operations v2 Architecture https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/machine-learning-operations-v2 Confidence: Verified – MLOps v2 architectural pattern, classical ML, CV, NLP.

8. GenAIOps for Organizations with MLOps Investments https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/genaiops-for-mlops Confidence: Verified – GenAIOps maturity model vs MLOps maturity model.

Code Samples (Verified via MCP)

• Azure ML Pipeline Definition (Python SDK) https://learn.microsoft.com/en-us/azure/machine-learning/how-to-create-component-pipeline-python?view=azureml-api-2 Confidence: Verified – Python decorator pattern for pipeline orchestration.

• Azure DevOps YAML Pipeline for Azure ML https://learn.microsoft.com/en-us/azure/machine-learning/how-to-devops-machine-learning?view=azureml-api-2 Confidence: Verified – CI/CD integration with Azure Pipelines.

Konfidensnivå per seksjon

Seksjon	Confidence	Kilde
Introduksjon	Verified	Microsoft Learn MLOps concepts
Kjernekomponenter	Verified	Azure ML capabilities documentation
Arkitekturmønstre	Verified	MLOps Maturity Model (Level 0-4)
Beslutningsveiledning	Baseline	Utledet fra maturity model + best practices
Integrasjon med MS-stack	Verified	Azure ML, DevOps, GitHub docs + code samples
Offentlig sektor	Baseline	GDPR/Datatilsynet + Azure compliance docs
Kostnad	Baseline	Azure Pricing Calculator (februar 2026)
For arkitekten	Baseline	Cosmo's domain expertise + maturity model

Sist verifisert

Alle kilder verifisert via microsoft-learn MCP-server 2026-04. Azure ML dokumentasjon gjelder API v2 (current) med mindre annet er nevnt.