ms-ai-architect/skills/ms-ai-engineering/references/mlops-genaiops/ci-cd-for-ml-models.md

# CI/CD Pipelines for Machine Learning Models

**Last updated:** 2026-06-19
**Status:** GA
**Category:** MLOps & GenAIOps
**Type:** reference
**Source:** https://learn.microsoft.com/azure/machine-learning/concept-ml-pipelines

---

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

CI/CD (Continuous Integration/Continuous Delivery) for maskinlæringsmodeller representerer en utvidelse av tradisjonelle DevOps-praksiser for å håndtere den unike kompleksiteten i ML-arbeidslaster. I motsetning til tradisjonell programvareutvikling, hvor deployment handler om kode, krever ML-løsninger automatisering av hele livssyklusen fra data validering og modelltrening til produksjonsutrulling og kontinuerlig overvåking.

Kjerneprinsippet er å automatisere bygging, testing og deployment av både kode *og* ML-modeller for å levere releaser mer hyppig og pålitelig enn manuelle prosesser. Dette blir stadig mer kritisk ettersom organisasjoner flytter fra eksperimentelle ML-prosjekter til produksjonssystemer som må opprettholde nøyaktighet, sikkerhet og compliance over tid.

Microsoft AI-stakken støtter CI/CD gjennom integrasjon mellom Azure Machine Learning, Azure DevOps og GitHub Actions, og tillater team å velge verktøy som passer deres modenhetsnivå og organisatoriske standarder. Denne tilnærmingen sikrer at ML-pipelines kan spores, reproduseres og skaleres på tvers av utviklings-, staging- og produksjonsmiljøer.

## Kjernekomponenter

### Pipeline Stages for ML CI/CD

| Stage | Beskrivelse | Typiske Aktiviteter | Automatiseringsgrad |
|-------|-------------|---------------------|---------------------|
| **Continuous Integration (CI)** | Verifisere kode og modellkvalitet før deployment | Unit testing, linting, data validation, integration testing | Høy (automatisert ved PR/merge) |
| **Model Training** | Trene modeller på preprocessert data | Feature engineering, hyperparameter tuning, experiment tracking | Varierer (manuell → automatisert) |
| **Model Validation** | Evaluere modellytelse mot akseptansekriterier | A/B testing, compliance checks, performance benchmarks | Middels til høy |
| **Continuous Delivery (CD)** | Deploy modeller til pre-prod og prod miljøer | Containerization, endpoint deployment, traffic routing | Høy |
| **Monitoring** | Overvåke modeller i produksjon | Data drift detection, performance degradation, security scanning | Kontinuerlig (automatisert) |

### Testing Strategies

ML-pipelines krever flere lag av testing som går utover tradisjonell kode-testing:

| Testtype | Formål | Verktøy (Microsoft Stack) | Når Utføres |
|----------|--------|---------------------------|-------------|
| **Unit Testing** | Validere individuelle funksjoner og komponenter | pytest, unittest i Azure Pipelines/GitHub Actions | Ved hver commit |
| **Data Validation** | Sjekke datakvalitet, schema changes, missing values | Azure ML Data Quality, Great Expectations | Pre-training, kontinuerlig |
| **Integration Testing** | Teste end-to-end ML pipelines i staging-miljø | Azure ML Pipelines, Databricks workflows | Ved PR merge til main |
| **Model Performance Testing** | Verifisere at modellen møter ytelseskrav | Azure ML Metrics, MLflow | Post-training, pre-deployment |
| **Infrastructure Testing** | Validere compute, networking, storage resources | Azure CLI, ARM template validation | Pre-deployment |

### Deployment Gates

Deployment gates fungerer som kvalitetssikringsmekanismer før modeller promoteres til produksjon:

- **Automated Approval Gates**: Modeller må passere definerte terskelverdier (accuracy, precision, recall)
- **Manual Approval Gates**: Krav til godkjenning fra data scientists, compliance team eller business stakeholders
- **Compliance Gates**: Automatisk scanning for sikkerhetssårbarheter (CVE), GDPR/AI Act compliance, bias detection
- **A/B Testing Gates**: Sammenligning av ny modell mot nåværende produksjonsmodell før full rollout

### Rollback Mechanisms

Robuste rollback-strategier er kritiske for ML-systemer:

| Mekanisme | Beskrivelse | Bruksscenario | Microsoft Implementering |
|-----------|-------------|---------------|--------------------------|
| **Blue-Green Deployment** | Kjør to identiske prod-miljøer; switch mellom dem | Zero-downtime rollback | Azure ML Managed Endpoints (multiple deployments) |
| **Canary Deployment** | Gradvis rollout til økende andel brukere | Risikoreduksjon ved store endringer | Azure ML Traffic Routing (percentage-based) |
| **Model Versioning** | Hold flere modellversjoner tilgjengelig | Rask rollback til tidligere versjon | Azure ML Model Registry, MLflow Model Registry |
| **Artifact Tagging** | Tag modeller med "production", "staging", "experimental" | Enkel identifikasjon av deploy-klare modeller | Azure ML Tags, Unity Catalog (Databricks) |

## Arkitekturmønstre

### Pattern 1: Azure DevOps Pipeline for ML

Dette mønsteret bruker Azure Pipelines for både CI og CD, med Azure ML for modelltrening og deployment.

**Komponenter:**
- **Source Control**: Azure Repos (eller GitHub)
- **CI Pipeline**: Azure Pipelines (YAML-basert)
- **ML Orchestration**: Azure Machine Learning Pipelines
- **Artifact Storage**: Azure ML Model Registry
- **Deployment Target**: Azure ML Managed Endpoints eller AKS

**Workflow:**
1. Data scientist committer kode til feature branch
2. PR trigger CI pipeline: linting, unit tests, data validation
3. Ved merge til main: trigger training pipeline i Azure ML
4. Modell registreres i Model Registry med metrics og lineage
5. CD pipeline deployer modell til staging endpoint
6. Etter godkjenning: promote til production endpoint med blue-green deployment

**Eksempel YAML (forenklet):**
```yaml
trigger:
  branches:
    include:
      - main

pool:
  vmImage: 'ubuntu-latest'

stages:
- stage: CI
  jobs:
  - job: Validate
    steps:
    - task: UsePythonVersion@0
      inputs:
        versionSpec: '3.10'
    - script: |
        pip install -r requirements.txt
        pytest tests/
      displayName: 'Run Unit Tests'

- stage: Train
  jobs:
  - job: TrainModel
    steps:
    - task: AzureCLI@2
      inputs:
        scriptType: 'bash'
        scriptLocation: 'inlineScript'
        inlineScript: |
          az ml job create --file training-pipeline.yml --resource-group <rg> --workspace-name <ws>

- stage: Deploy
  jobs:
  - deployment: DeployToStaging
    environment: 'staging'
    strategy:
      runOnce:
        deploy:
          steps:
          - task: AzureCLI@2
            inputs:
              inlineScript: |
                az ml online-endpoint create --name model-endpoint-staging
                az ml online-deployment create --endpoint model-endpoint-staging --file deployment.yml
```

**Fordeler**: Integrert med Azure økosystem, god RBAC, compliance-tracking
**Ulemper**: Krever Azure DevOps lisens, mer kompleks oppsett for små team

---

### Pattern 2: GitHub Actions for ML Deployment

Dette mønsteret bruker GitHub Actions for CI/CD, med OpenID Connect (OIDC) for sikker autentikasjon til Azure.

**Komponenter:**
- **Source Control**: GitHub
- **CI/CD**: GitHub Actions (YAML workflows)
- **ML Orchestration**: Azure Machine Learning CLI v2
- **Authentication**: OpenID Connect (federated credentials)
- **Deployment**: Azure ML Managed Endpoints

**Workflow:**
1. Push til main branch trigger GitHub Actions workflow
2. Workflow sjekker ut kode, autentiserer med Azure via OIDC
3. Installerer Azure ML CLI v2 og kjører training job
4. Modell registreres automatisk med MLflow tracking
5. CD-steg deployer modell til endpoint med traffic routing

**Eksempel YAML:**
```yaml
name: ML-Pipeline-Deployment
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

permissions:
  id-token: write
  contents: read

jobs:
  train-and-deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3

    - name: Azure Login (OIDC)
      uses: azure/login@v2
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

    - name: Setup Azure ML CLI
      run: az extension add -n ml -y

    - name: Run Training Pipeline
      run: |
        az ml job create --file pipeline.yml \
          --resource-group ${{ vars.RESOURCE_GROUP }} \
          --workspace-name ${{ vars.WORKSPACE_NAME }}

    - name: Deploy to Endpoint
      run: |
        az ml online-deployment create \
          --endpoint model-endpoint \
          --file deployment.yml \
          --all-traffic
```

**Fordeler**: Gratis for public repos, enkel integrasjon med GitHub ecosystem, moderne OIDC-autentikasering
**Ulemper**: Mindre enterprise features enn Azure DevOps, rate limits på free tier

---

### Pattern 3: Hybrid DevOps + ML Pipeline

Dette mønsteret separerer ML-spesifikke pipelines (Azure ML Pipelines) fra DevOps pipelines (Azure DevOps/GitHub Actions).

**Komponenter:**
- **DevOps CI/CD**: Azure DevOps eller GitHub Actions
- **ML Pipelines**: Azure ML Pipelines (for data prep, training, batch scoring)
- **Orchestration Layer**: Azure Data Factory eller Databricks Workflows
- **Model Management**: MLflow tracking + Azure ML Model Registry

**Når Bruke Dette:**
- Team har separate roller: data engineers (Azure ML Pipelines), DevOps engineers (CI/CD)
- Komplekse data dependencies krever orchestration utover DevOps-verktøy
- Behov for reusable ML pipeline components på tvers av prosjekter

**Workflow:**
1. DevOps pipeline deployer infrastruktur (IaC) og kode
2. DevOps pipeline trigger Azure ML Pipeline for training
3. Azure ML Pipeline håndterer data prep → training → validation
4. Ved suksess: DevOps CD pipeline deployer modell til endpoint
5. Databricks Workflows håndterer scheduled retraining og batch scoring

**Decision Tree:**
- Bruk Azure ML Pipelines for: ML-spesifikk orchestration (caching, reuse, distributed compute)
- Bruk Azure Pipelines for: CI/CD, infrastructure deployment, approval gates
- Bruk Azure Data Factory for: Data orchestration (ETL/ELT), cross-platform data movement

**Referanse**: [Which Azure pipeline technology should I use?](https://learn.microsoft.com/en-us/azure/machine-learning/concept-ml-pipelines#which-azure-pipeline-technology-should-i-use)

## Beslutningsveiledning

### Decision Table: Velge Riktig CI/CD Strategi

| Kriterium | Azure DevOps | GitHub Actions | Databricks MLOps Stacks |
|-----------|--------------|----------------|-------------------------|
| **Team størrelse** | Middels til stor (10+) | Liten til middels (2-20) | Middels til stor (Databricks-basert) |
| **Eksisterende infra** | Azure-tungt økosystem | GitHub-native teams | Databricks Lakehouse users |
| **Compliance krav** | Høy (RBAC, audit trails) | Middels (krever ekstra config) | Høy (Unity Catalog integration) |
| **Modenhetsnivå** | Middels til høy MLOps-modenhet | Lav til middels | Høy (krever Databricks kompetanse) |
| **Kostnadsmodell** | Paid (per pipeline parallelism) | Gratis for public, paid for private | Databricks lisens påkrevd |
| **Best for** | Enterprise ML i Azure | Startups, open-source prosjekter | Data science teams på Databricks |

### Vanlige Feil

| Feil | Konsekvens | Mitigering |
|------|------------|-----------|
| **One-size-fits-all pipeline** | Treg CI/CD for små endringer | Lag separate pipelines for kode vs. modelltrening |
| **Manglende data versioning** | Ikke-reproduserbare modeller | Bruk Delta Lake, DVC eller Azure ML Data Assets |
| **Hardkodede credentials** | Sikkerhetssårbarheter | Bruk Azure Key Vault, GitHub Secrets, eller OIDC |
| **Ingen rollback-strategi** | Langvarige production-issues | Implementer blue-green eller canary deployment |
| **Overfitting til test data** | Modeller feiler i prod | Bruk separate validation og test sets, monitor data drift |
| **Skip av compliance gates** | Regulatoriske brudd | Automatiser security scanning, bias detection i pipeline |

### Røde Flagg

Disse signalene indikerer at din ML CI/CD ikke er production-ready:

- ❌ **Manuell deployment av modeller**: Høy risiko for human error
- ❌ **Ingen automated testing**: Modeller deployes uten validering
- ❌ **Manglende monitoring**: Data drift eller model decay oppdages ikke
- ❌ **Secret sprawl**: API keys og credentials i kode eller config-filer
- ❌ **Single point of failure**: Ingen redundancy i produksjons-endepunkter
- ❌ **Ingen audit trail**: Kan ikke spore hvilken kode/data som produserte en modell

## Integrasjon med Microsoft-stakken

### Azure DevOps Integration

**Setup:**
- Opprett Azure DevOps project med Azure Repos
- Koble til Azure ML workspace via Service Principal eller Managed Identity
- Installer Azure ML CLI v2 extension i pipeline agents
- Konfigurer variable groups for miljø-spesifikke settings

**Key Features:**
- **Build Validation Policies**: Krev at CI pipeline passes før PR merges
- **Release Gates**: Automatiske eller manuelle godkjenninger før prod deployment
- **Artifact Feeds**: Host private Python packages for ML-prosjekter
- **Test Plans**: Integrert testing for modellvalidering

**Best Practices:**
- Bruk YAML pipelines (ikke Classic UI) for version control
- Separate build artifacts (kode) fra ML artifacts (modeller)
- Bruk environments for staging/production med approval gates

---

### GitHub Actions Integration


### GitHub Actions with Azure Machine Learning (Verified MCP 2026-04)
The recommended authentication approach is **OpenID Connect (OIDC) with federated credentials** — eliminates long-lived secrets. Two options:
- **Option 1: Microsoft Entra application** — Create app registration, configure federated identity credential, assign role.
- **Option 2: User-assigned managed identity** — Create UAI, configure federated identity credential, assign role.

**Workflow structure** (`/.github/workflows/`):
```yaml
permissions:
  id-token: write
jobs:
  build:
    steps:
    - uses: actions/checkout@v4
    - uses: azure/login@v2
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
    - run: az ml job create --file pipeline.yml
```

**MLOps v2 GitHub setup** (recommended end-to-end):
1. Fork `Azure/mlops-v2-gha-demo` template repo
2. Set GitHub secrets: `ARM_CLIENT_ID`, `ARM_CLIENT_SECRET`, `ARM_SUBSCRIPTION_ID`, `ARM_TENANT_ID`
3. Deploy infrastructure via `tf-gha-deploy-infra.yml` workflow (Terraform)
4. Run `deploy-model-training-pipeline` and `deploy-online-endpoint-pipeline` workflows

**Pipeline stages**: Prepare Data → Train Model → Evaluate Model → Register Model → Deploy Endpoint

**Note (2026-04):** The `--json-auth`/`--sdk-auth` parameters for `az ad sp create-for-rbac` are deprecated. New projects should use OIDC with federated credentials instead.


**Setup:**
- Opprett `.github/workflows/` directory i repo
- Konfigurer GitHub Secrets for Azure credentials (eller OIDC)
- Bruk `azure/login@v2` action for autentikasering
- Installer Azure ML CLI via `az extension add -n ml`

**Key Features:**
- **Reusable Workflows**: Share ML pipeline logic across repos
- **Matrix Builds**: Test modeller på flere Python-versjoner eller compute targets
- **Environments**: Protected branches med required reviewers
- **GitHub Packages**: Host container images for ML inference

**Best Practices:**
- Bruk OpenID Connect (OIDC) i stedet for service principal secrets
- Limit workflow permissions (`permissions: id-token: write`)
- Bruk `concurrency` settings for å unngå parallelle deployments
- Cache pip dependencies med `actions/cache` for raskere runs

**Eksempel: OIDC Setup**
1. Opprett federated credential i Azure AD app registration
2. Konfigurer GitHub Secrets: `AZURE_CLIENT_ID`, `AZURE_TENANT_ID`, `AZURE_SUBSCRIPTION_ID`
3. Bruk `azure/login@v2` med OIDC i workflow

---

### Azure Container Registry (ACR)

**Rolle i ML CI/CD:**
- Lagre custom training container images
- Host inference containers for model deployment
- Integrate med Azure ML for reproducible environments

**Workflow:**
1. Build Docker image med ML code og dependencies
2. Push til ACR med semantic versioning tags
3. Azure ML Environments refererer til ACR image URI
4. Deployment bruker samme image for consistency

**Security:**
- Bruk Azure AD authentication (ikke admin credentials)
- Enable vulnerability scanning (Microsoft Defender for Containers)
- Implement image retention policies for cost optimization

---

### Azure Kubernetes Service (AKS)

**Bruk for ML:**
- Host Azure ML inference endpoints for high-throughput scenarios
- Custom model serving (utover Azure ML Managed Endpoints)
- Multi-tenant ML platforms med namespace isolation

**CI/CD Integration:**
```bash
# Deploy model til AKS via Azure ML
az ml online-deployment create \
  --endpoint my-endpoint \
  --compute azureml:aks-cluster \
  --file deployment.yml
```

**Considerations:**
- Krever Kubernetes kompetanse for operasjon
- Mer fleksibilitet enn Managed Endpoints, men mer overhead
- Best for: høy-throughput inference, custom serving logic

## Offentlig sektor (Norge)

### Sikkerhetskrav

Offentlig sektor i Norge må overholde strengere krav enn privat sektor ved deployment av ML-systemer:

| Krav | Relevans for CI/CD | Implementering |
|------|-------------------|----------------|
| **NSM Grunnprinsipper** | Alle deployment pipelines må logge actions | Azure Monitor Logs, Azure DevOps audit logs |
| **eForvaltningsforskriften** | Kode og modeller må kunne auditeres | Git history, MLflow lineage tracking |
| **Personvernforordningen (GDPR)** | Data i pipelines må beskyttes | Azure Private Link, encrypted storage |
| **Sikkerhetsloven** | Kritiske systemer krever godkjenningsprosesser | Manual approval gates i CD pipeline |

**Best Practice for Offentlig Sektor:**
- Kjør CI/CD pipelines i Azure Norge-regioner (Norway East/West)
- Bruk Azure Policy for å enforce compliance (eks. "require tags on all ML models")
- Implementer "four eyes principle" for production deployments (required reviewers)
- Hold audit trail i minimum 5 år (GDPR-krav for offentlig sektor)

---

### Godkjenningsprosesser

Offentlige virksomheter har ofte formelle godkjenningsprosesser som må integreres i CI/CD:

**Stage-Gate Model:**
1. **Development Stage**: Fri eksperimentering, minimal godkjenning
2. **Test Stage**: Godkjenning fra tech lead eller senior data scientist
3. **Pre-Production Stage**: Godkjenning fra compliance officer og security team
4. **Production Stage**: Godkjenning fra product owner og evt. sikkerhetsrådgiver

**Implementering i Azure DevOps:**
- Bruk Environments med Required Reviewers
- Konfigurer Branch Policies med "Require approval from specific users"
- Implementer custom pre-deployment gates (API-kall til internt godkjenningssystem)

**Implementering i GitHub Actions:**
```yaml
jobs:
  deploy-to-prod:
    runs-on: ubuntu-latest
    environment:
      name: production
      # Krever godkjenning fra minst 2 reviewers i GitHub Settings
    steps:
    - name: Deploy model
      run: az ml online-deployment create --file deployment.yml
```

---

### Compliance med AI Act

EU AI Act (implementeres i Norge via EØS) krever ekstra dokumentasjon for "høyrisiko AI-systemer":

| Krav | CI/CD Implementering |
|------|---------------------|
| **Risk Assessment** | Automatisk generering av risk report i pipeline (template-basert) |
| **Data Governance** | Track data lineage fra source til modell (Azure ML Data Assets) |
| **Model Documentation** | Automatisk generering av model cards (metadata, metrics, limitations) |
| **Human Oversight** | Manual approval gates for høyrisiko-systemer |
| **Transparency** | Eksporter alle pipeline runs til immutable audit log |

**Eksempel: Auto-generere Model Card**
```python
# I training pipeline (post-training step)
from azureml.core import Run
run = Run.get_context()

model_card = {
    "model_name": "customer-churn-predictor",
    "version": "1.2.0",
    "training_data": "customer-data-2024-Q1",
    "accuracy": 0.87,
    "bias_metrics": {"gender_parity": 0.95},
    "intended_use": "Predicting customer churn for retention campaigns",
    "limitations": "Not suitable for real-time decisions on individual customers",
    "risk_level": "medium"
}

run.log_table("model_card", value=model_card)
```

## Kostnad og lisensiering

### Azure DevOps Prising (2026)

| Komponent | Gratis Tier | Paid Tier | Kostnad (NOK/mnd) |
|-----------|-------------|-----------|-------------------|
| **Azure Repos** | Ubegrenset private repos | - | Inkludert |
| **Azure Pipelines** | 1 free Microsoft-hosted job (1800 min/mnd) | Ekstra parallel jobs | ~450 NOK/job |
| **Artifacts** | 2 GB gratis | 1 TB | ~30 NOK/GB utover 2 GB |
| **Test Plans** | Ikke inkludert | Per user | ~625 NOK/bruker/mnd |

**Viktige Poeng:**
- Microsoft-hosted agents (Linux/Windows) er billigere enn self-hosted for små team
- Self-hosted agents er gratis, men krever vedlikehold av infra
- Private repos er gratis (uavhengig av antall)

**Kostnadsoptimalisering:**
- Bruk single-stage pipelines for enkle ML-jobs (reduserer pipeline run time)
- Implementer caching av pip packages (reduserer build time)
- Bruk matrix builds kun når nødvendig (teller som separate jobs)

---

### GitHub Actions Prising (2026)

| Plan | Free | Team | Enterprise |
|------|------|------|-----------|
| **Inkludert Minutes** | 2000 min/mnd | 3000 min/mnd | 50 000 min/mnd |
| **Kostnad per Ekstra Minutt** | ~0,09 NOK (Linux) | ~0,09 NOK | ~0,09 NOK |
| **Storage** | 500 MB | 2 GB | 50 GB |
| **Concurrent Jobs** | 20 | 60 | 180 |

**Viktige Poeng:**
- Public repositories: Ubegrenset gratis minutes
- Windows og macOS runners koster mer (2x og 10x multiplier)
- Self-hosted runners er gratis (ingen minutt-grense)

**Kostnadsoptimalisering:**
- Bruk `ubuntu-latest` (billigst runner type)
- Implementer `concurrency` groups for å unngå duplikate runs
- Bruk `paths` trigger filters for å kun kjøre pipeline ved relevante endringer:
```yaml
on:
  push:
    paths:
      - 'src/**'
      - 'training/**'
```

---

### Azure Machine Learning Compute Prising

CI/CD pipelines for ML krever compute for training og deployment:

| Compute Type | Bruksscenario | Kostnad (NOK/time, estimat) |
|--------------|---------------|------------------------------|
| **Compute Instance** | Interaktiv utvikling, små treningsjobber | ~15-150 NOK/time |
| **Compute Cluster** | Automatisk skalerende training | ~10-200 NOK/time (per node) |
| **Managed Endpoints** | Real-time inference | ~100-500 NOK/time (avhengig av SKU) |
| **Batch Endpoints** | Batch scoring | Kun compute cost (ingen endpoint overhead) |

**Optimaliseringstips:**
- Bruk low-priority VMs for training (opptil 80% rabatt, men kan preemptes)
- Implementer auto-shutdown for compute instances (spar kostnad ved inaktivitet)
- Bruk batch endpoints for ikke-sanntids inference (unngå "always on" cost)

**Eksempel Pipeline Cost Breakdown (typisk MLOps setup):**
- Azure DevOps: 450 NOK/mnd (1 parallel job)
- Azure ML Compute Cluster: ~2000 NOK/mnd (10 timer training/uke på Standard_D4s_v3)
- Managed Endpoint: ~3000 NOK/mnd (Standard_DS3_v2, always-on)
- Storage og Monitoring: ~500 NOK/mnd
- **Total:** ~5950 NOK/mnd

## For arkitekten (Cosmo)

### Spørsmål å Stille Klienten

1. **Organisatorisk Modenhet:**
   - "Har dere erfaring med DevOps-pipelines i dag? Bruker dere Azure DevOps eller GitHub Actions?"
   - "Har dere separate team for data science og DevOps, eller er rollene integrert?"
   - "Hvor ofte deployer dere modeller til produksjon i dag? (daglig/ukentlig/månedlig)"

2. **Compliance og Sikkerhet:**
   - "Er dette en høyrisiko AI-applikasjon i henhold til AI Act? (eks. rekruttering, kredittscoring)"
   - "Hvilke compliance-krav må dere overholde? (GDPR, sikkerhetslov, bransjespesifikke)"
   - "Har dere krav til 'four eyes principle' for produksjons-deployments?"

3. **Teknisk Infrastruktur:**
   - "Kjører dere allerede arbeidslaster i Azure? Hvilke regioner brukes?"
   - "Har dere eksisterende CI/CD-infrastruktur vi kan bygge videre på?"
   - "Trenger dere support for multi-cloud eller hybrid deployment?"

4. **ML-Spesifikke Behov:**
   - "Hvor ofte må modellene retraines? (continuous/scheduled/manual)"
   - "Trenger dere A/B testing eller canary deployments for gradvis rollout?"
   - "Har dere krav til reproduserbarhet og audit trails for modelltrening?"

5. **Kostnadsrammer:**
   - "Hva er budsjettet for CI/CD-infrastruktur? (DevOps lisenser + compute)"
   - "Er dere komfortable med consumption-based prising (pay-per-use)?"
   - "Har dere kompetanse til å drifte self-hosted runners for kostnadsoptimalisering?"

---

### Fallgruver å Unngå

1. **Over-Engineering Tidlig:**
   - Start IKKE med kompleks multi-stage pipeline før team har grunnleggende CI/CD
   - Bruk Azure ML Studio UI først, migrer til YAML når prosessen er stabil
   - Unngå custom Docker containers før det er strengt nødvendig (bruk curated environments)

2. **Secret Sprawl:**
   - ALDRI hardkode API keys eller connection strings i pipeline YAML
   - Bruk Azure Key Vault eller GitHub Secrets konsekvent
   - Implementer OIDC (OpenID Connect) for Azure-autentikasering i stedet for service principal secrets

3. **Manglende Testing i Staging:**
   - IKKE deploy direkte til prod fra training pipeline
   - Krev at modeller testes i staging-miljø med real-world data
   - Implementer smoke tests (basic inference requests) før full rollout

4. **Ignore Data Versioning:**
   - ML-modeller er et produkt av både kode OG data
   - Bruk Azure ML Data Assets eller Delta Lake for å tracke data lineage
   - Tag modeller med data version for reproduserbarhet

5. **Single Point of Failure:**
   - Ikke ha kun ett produksjons-endpoint uten fallback
   - Implementer blue-green deployment eller ha tidligere modellversjon klar til rollback
   - Monitor endpoint health og implementer automatic failover

---

### Anbefalinger per Modenhetsnivå

#### Nivå 0: No MLOps (manuell deployment)
**Status:** Data scientists kjører Jupyter notebooks lokalt, manuell deployment av modeller
**Anbefaling:**
- Start med GitHub Actions for enkel CI/CD (gratis for public repos)
- Bruk Azure ML Studio UI for modelltrening (low-code approach)
- Implementer basic monitoring (Azure Application Insights)
- **Ikke** fokuser på automatisk retraining ennå

---

#### Nivå 1: DevOps, No MLOps
**Status:** Tradisjonell CI/CD finnes, men ikke tilpasset ML-workflows
**Anbefaling:**
- Utvid eksisterende Azure DevOps/GitHub Actions pipelines med ML steps
- Implementer Azure ML CLI v2 i pipeline for modelltrening
- Introduser Model Registry for versjonering
- Legg til data validation steps (schema checks, missing values)

---

#### Nivå 2: Automated Training
**Status:** ML pipelines er automatisert, men deployment er fortsatt manuell
**Anbefaling:**
- Implementer CD pipeline for automated deployment til staging
- Legg til approval gates for produksjons-deployments
- Bruk blue-green eller canary deployment strategies
- Integrer monitoring i feedback loop (data drift → trigger retraining)

---

#### Nivå 3: Automated Deployment
**Status:** Full CI/CD, modeller deployes automatisk ved godkjenning
**Anbefaling:**
- Implementer continuous retraining triggers (schedule eller data drift-basert)
- Bruk feature stores for konsistent data across training/inference
- Introduser automated A/B testing for modellvalidering
- Implementer ML-specific monitoring (model performance, bias, fairness)

---

#### Nivå 4: Full MLOps Automation
**Status:** Alt er automatisert, inkludert retraining og deployment
**Anbefaling:**
- Optimaliser pipeline ytelse (caching, parallelisering)
- Implementer multi-region deployment for high availability
- Introduser AutoML for hyperparameter tuning
- Bruk Responsible AI dashboard for compliance automation

---

#### Nivå 5: MLOps som Platform
**Status:** MLOps-kapabiliteter tilbys som intern platform til data science teams
**Anbefaling:**
- Bygg reusable pipeline templates (Azure ML Components)
- Implementer self-service model deployment (internal developer platform)
- Bruk Infrastructure-as-Code (Terraform/Bicep) for miljøkonsistens
- Etabler sentralisert monitoring dashboard for alle modeller

## Kilder og verifisering

### Microsoft Learn URLs (Verified via MCP)

1. **Use GitHub Actions with Azure Machine Learning**
   https://learn.microsoft.com/en-us/azure/machine-learning/how-to-github-actions-machine-learning
   (Status: Verified MCP 2026-04 — OIDC recommended; supports Entra app or user-assigned managed identity)

2. **MLOps and GenAIOps for AI workloads on Azure**
   https://learn.microsoft.com/en-us/azure/well-architected/ai/mlops-genaiops
   (Status: Verified 2026-02, Well-Architected Framework MLOps guide)

3. **Set up MLOps with GitHub**
   https://learn.microsoft.com/en-us/azure/machine-learning/how-to-setup-mlops-github-azure-ml
   (Status: Verified MCP 2026-04 — uses mlops-v2-gha-demo accelerator; --json-auth deprecated, OIDC recommended)

4. **How does Databricks support CI/CD for machine learning?**
   https://learn.microsoft.com/en-us/azure/databricks/machine-learning/mlops/ci-cd-for-ml
   (Status: Verified 2026-02, Databricks MLOps Stacks guide)

5. **Use Azure Databricks to orchestrate MLOps**
   https://learn.microsoft.com/en-us/azure/architecture/ai-ml/idea/orchestrate-machine-learning-azure-databricks
   (Status: Verified 2026-02, arkitekturmønster for MLOps på Databricks)

6. **Concepts - Machine learning operations (MLOps) for AKS**
   https://learn.microsoft.com/en-us/azure/aks/concepts-machine-learning-ops
   (Status: Verified 2026-02, MLOps principles og DevOps-integrasjon)

7. **Azure CI/CD data pipelines**
   https://learn.microsoft.com/en-us/azure/devops/pipelines/apps/cd/azure/cicd-data-overview
   (Status: Verified 2026-02, data science CI/CD overview)

8. **Which Azure pipeline technology should I use?**
   https://learn.microsoft.com/en-us/azure/machine-learning/concept-ml-pipelines
   (Status: Verified 2026-02, decision guide for Azure Pipelines vs. Azure ML Pipelines)

### Konfidensnivå per Seksjon

| Seksjon | Konfidens | Kilde |
|---------|-----------|-------|
| Introduksjon | Verified | MCP: MLOps and GenAIOps guide |
| Kjernekomponenter → Pipeline Stages | Verified | MCP: AKS MLOps concepts, CI/CD data pipelines |
| Kjernekomponenter → Testing Strategies | Baseline | Modellkunnskap + MCP: MLOps principles |
| Kjernekomponenter → Deployment Gates | Verified | MCP: Azure ML deployment docs |
| Kjernekomponenter → Rollback Mechanisms | Verified | MCP: Azure ML managed endpoints |
| Arkitekturmønstre → Azure DevOps Pipeline | Verified | MCP: Azure Pipelines MLOps setup |
| Arkitekturmønstre → GitHub Actions | Verified | MCP: GitHub Actions + Azure ML guide |
| Arkitekturmønstre → Hybrid DevOps + ML | Verified | MCP: Which pipeline technology guide |
| Beslutningsveiledning | Baseline | Modellkunnskap + best practices |
| Integrasjon med Microsoft-stakken | Verified | MCP: Multiple Azure ML integration docs |
| Offentlig sektor (Norge) | Baseline | Modellkunnskap (NSM, GDPR, AI Act) |
| Kostnad og lisensiering | Baseline | Modellkunnskap (2026 prising estimert) |
| For arkitekten (Cosmo) | Baseline | Beste praksiser + MLOps maturity model |

**Overall Konfidens:** 85% (majoriteten av innhold er verifisert via Microsoft Learn MCP-kilde, offentlig sektor og prising er basert på modellkunnskap og er merket som "Baseline")