ktg-plugin-marketplace/plugins/ms-ai-architect/skills/ms-ai-governance/SKILL.md

---
name: ms-ai-governance
description: |
  This skill should be used when the user asks about Norwegian public sector AI compliance,
  utredningsinstruksen for AI projects, EU AI Act risk classification, DPIA for AI systems,
  Digdir architecture principles, responsible AI governance, or monitoring and observability
  for AI in production.
  Triggers on: "Norwegian public sector AI compliance", "utredningsinstruksen for AI",
  "AI Act risk classification", "DPIA for AI system", "Digdir architecture principles",
  "ansvarlig AI i offentlig sektor", "compliance-vurdering for AI", "Forvaltningsloven AI",
  "Schrems II AI", "bias detection", "AI governance framework".
---

# ms-ai-governance

Provide governance and compliance guidance for AI systems in Norwegian public sector. Cover the full regulatory landscape: Norwegian administrative law, EU regulations, responsible AI implementation, and production monitoring.

## Primary agents

- **architecture-review-agent** — Evaluate AI architecture against governance requirements and Digdir principles
- **dpia-agent** — Conduct Data Protection Impact Assessments (DPIA) for AI systems
- **summary-agent** — Summarize regulatory status and compliance gaps

---

## 1. Norsk offentlig sektor-rammeverk

### 1.1 Utredningsinstruksen

All state measures, including AI system adoption, must be assessed before decision. Answer these six mandatory questions:

1. What is the problem, and what do we want to achieve?
2. Which measures are relevant?
3. What principled questions do the measures raise?
4. What are the positive and negative effects, how lasting are they, and who is affected?
5. Which measure is recommended, and why?
6. What are the prerequisites for successful implementation?

Always assess the null alternative (no AI). Scale assessment depth proportionally to impact — from minimum analysis (FAQ chatbot) to full socioeconomic analysis (automated decision-making).

> **Reference:** `references/norwegian-public-sector-governance/utredningsinstruksen-ai-methodology.md`

### 1.2 Digdir arkitekturprinsipper

All seven Digdir architecture principles apply to AI systems. Evaluate each AI system against these criteria:

| # | Prinsipp | Core AI criterion | Reference |
|---|----------|-------------------|-----------|
| 1 | Brukersentrering | User needs documented, fallback when AI fails, WCAG 2.1 AA | `digdir-principle-1-user-centric-design.md` |
| 2 | Interoperabilitet | Open standards, documented APIs, DCAT-AP-NO metadata, EIF compliance | `digdir-principle-2-interoperability.md` |
| 3 | Apenhet | AI workings documented, citizen insight into AI decisions, algorithmic transparency | — |
| 4 | Sikkerhet by design | ROS analysis, NSM principles, prompt injection/data poisoning addressed | `digdir-principle-4-trust-security.md` |
| 5 | Datakvalitet | Training data quality-assured, bias identified, data catalog updated | — |
| 6 | Baerekraft | Energy consumption estimated, model size proportional to task, cost budgeted | `gevinstrealisering-ai-projects.md` |
| 7 | Tilgjengelighet | WCAG 2.1 AA, assistive tech tested, language support (nb/nn/sami) | `accessibility-requirements-wcag-norway.md` |

All references in `references/norwegian-public-sector-governance/`.

### 1.3 Forvaltningsloven

Key requirements for AI in administrative decisions:

- **Duty to justify decisions (SS 24-25):** AI-supported decisions must explain WHY the AI recommended a particular outcome. State the rules, facts, and AI role.
- **Right of access to automated processes:** System documentation for AI decision systems must be available to citizens. Manual override must be possible.
- **Right of appeal:** Full appeal rights regardless of AI involvement. Appeal body must assess all aspects including AI recommendations. Systematic AI errors trigger duty to review affected decisions.
- **Legal basis required:** Automated decisions require explicit legal authority in law or regulation.

> **Reference:** `references/norwegian-public-sector-governance/forvaltningsloven-ai-decisions.md`

---

## 2. EU-regelverk

### 2.1 AI Act

EU AI Act (Regulation 2024/1689) classifies AI systems by risk level:

| Risk level | Description | Public sector examples | Requirements |
|-----------|-------------|------------------------|------|
| **Unacceptable** | Prohibited use | Social scoring, manipulation of vulnerable groups | Total ban |
| **High risk** | Regulated use (Annex III) | Decision systems, welfare, hiring | Full compliance |
| **Limited risk** | Transparency requirements | Chatbots, content generation | Disclosure obligation |
| **Minimal risk** | Voluntary compliance | Spam filters, internal search | Recommended Code of Conduct |

High-risk systems require: risk management system, data governance, technical documentation, logging, transparency, human oversight, and accuracy/robustness/cybersecurity throughout the lifecycle.

> **Reference:** `references/responsible-ai/ai-act-compliance-guide.md`
> **Reference:** `references/responsible-ai/ai-act-annex-iii-checklist.md`
> **Reference:** `references/responsible-ai/ai-act-conformity-assessment.md`
> **Reference:** `references/responsible-ai/ai-act-provider-obligations.md`
> **Reference:** `references/responsible-ai/ai-act-deployer-obligations.md`

### 2.2 GDPR / Personopplysningsloven

#### Treatment basis for AI (Article 6)

| Basis | Relevance for public sector AI |
|-------|-------------------------------|
| Art. 6(1)(a) Consent | Rarely sufficient alone for public authority |
| Art. 6(1)(b) Contract | Relevant for service delivery |
| Art. 6(1)(c) Legal obligation | When AI supports legally mandated tasks |
| Art. 6(1)(e) Public authority / public interest | **Primary basis** for AI in public administration |
| Art. 6(1)(f) Legitimate interest | Does NOT apply to public authority exercise |

**DPIA (Art. 35):** Mandatory when AI processing likely results in high risk. Nearly always applies when combining new technology (AI) with profiling, large-scale processing, special category data, or vulnerable groups. Consult DPO; consult Datatilsynet if high residual risk remains.

**Automated decisions (Art. 22):** Right not to be subject to solely automated decisions. Exceptions require consent, contractual necessity, or legal authority — with right to human review. Norwegian public sector requires explicit legal basis for fully automated decisions.

**Data subject rights:** Ensure right of access (Art. 15), rectification (Art. 16), erasure (Art. 17), portability (Art. 20), and objection (Art. 21) for all AI processing.

> **Reference:** `references/responsible-ai/gdpr-compliance-ai-systems.md`
> **Reference:** `references/norwegian-public-sector-governance/dpia-norwegian-methodology-ai.md`

### 2.3 Schrems II og dataoverfoering

Schrems II (C-311/18) requires Transfer Impact Assessment for AI systems using US cloud providers. For Azure/Microsoft: map data flows, use SCCs as primary transfer basis, assess FISA 702/CLOUD Act exposure, implement supplementary measures (encryption, pseudonymization). Microsoft EU Data Boundary ensures processing within EU/EEA for core services including Azure OpenAI Service (Sweden Central, West Europe).

> **Cross-reference:** `skills/ms-ai-security/references/ai-security-engineering/data-leakage-prevention-ai.md`

---

## 3. Ansvarlig AI

### 3.1 Bias detection and mitigation

Measure bias using Fairlearn or Azure AI Fairness Dashboard (demographic parity, equalized odds, disparate impact). Conduct disaggregated analysis across protected groups. Document findings in Model Cards.

> **Reference:** `references/responsible-ai/bias-detection-mitigation-strategies.md`
> **Reference:** `references/responsible-ai/fairness-testing-measurement.md`

### 3.2 Explainability

Explainability requirements scale with impact: fully automated decisions need complete logic explanation; AI-assisted case handling needs SHAP/LIME; chatbots need source attribution; internal analytics need method documentation.

> **Reference:** `references/responsible-ai/model-explainability-interpretability.md`
> **Reference:** `references/responsible-ai/transparency-documentation-standards.md`

### 3.3 Human-in-the-loop (HITL)

Three oversight levels: **Human-in-the-loop** (approve every decision — high-risk), **Human-on-the-loop** (monitor and intervene — AI-assisted), **Human-in-command** (set parameters and boundaries — automated with escalation). Key patterns: Approval Gateway, Confidence Threshold, Random Audit, Exception Routing, Dual Review.

> **Reference:** `references/responsible-ai/human-in-the-loop-oversight.md`

### 3.4 AI Governance Framework

Establish organizational structure (AI Governance Board, Ethics Committee, AI Product Owner, DPO, CISO) and processes (AI strategy, impact assessment, model registry, incident handling, periodic review).

> **Reference:** `references/responsible-ai/ai-governance-structure-framework.md`
> **Reference:** `references/responsible-ai/responsible-ai-policy-development.md`

### 3.5 Red teaming

Systematic testing cycle: plan scope, threat model (STRIDE for AI), test (prompt injection, jailbreaking, data extraction, bias exploitation), report with severity, mitigate, and re-test on model upgrades.

> **Reference:** `references/responsible-ai/red-teaming-ai-models.md`
> **Cross-reference:** `skills/ms-ai-security/references/ai-security-engineering/ai-red-team-operations-practical.md`

### 3.6 AI Impact Assessment

Holistic assessment beyond DPIA covering: privacy, security (ROS), ethics (fairness, autonomy, dignity), societal impact, democratic implications, and equality consequences.

> **Reference:** `references/responsible-ai/ai-impact-assessment-framework.md`
> **Reference:** `references/responsible-ai/ai-risk-taxonomy-classification.md`

---

## 4. Monitorering og observerbarhet

Monitor AI systems in production for both operational and regulatory compliance. Instrument with Application Insights, track custom metrics (model performance, confidence, response times), log AI events (fallback, low-confidence, escalation), and trace dependencies to Azure OpenAI and AI Search.

#### Key metrics for public sector AI

| Category | Metric | Target |
|----------|--------|--------|
| Performance | Response time P95 | < 5s for user-facing |
| Quality | Groundedness score | > 0.8 for RAG |
| Safety | Blocked attempts (content safety) | Track trend, escalation rule |
| Drift | Prediction distribution over time | Statistical deviation detection |
| Cost | Token consumption per conversation | Budget limit with alerting |

Implement drift detection (data drift, concept drift, feature drift, prediction drift) using PSI, KS-test, or chi-squared. Alert on severity: Sev 0 (immediate — safety breach), Sev 1 (<1h — performance below threshold), Sev 2 (<4h — cost overrun), Sev 3 (next business day — trend deviation).

> **Key references** in `references/monitoring-observability/`:
> - `application-insights-llm-monitoring.md` — Application Insights for LLM
> - `azure-monitor-ai-services-setup.md` — Azure Monitor setup
> - `drift-detection-automated-retraining.md` — Drift detection

---

## 5. Referansekatalog

### 5.1 Own references

| Directory | Files | Coverage |
|-----------|-------|----------|
| `references/norwegian-public-sector-governance/` | 29 | Utredningsinstruksen, Forvaltningsloven, Digdir principles, DPIA methodology, ROS analysis (incl. threat library, scoring rubrics, sector checklists), NSM, EIF, procurement, benefit realization, accessibility, copyright, budgeting |
| `references/responsible-ai/` | 30 | AI Act (compliance guide, Annex III, classification, provider/deployer obligations, FRIA template, conformity assessment, transparency notices, Microsoft tools mapping), GDPR, bias, explainability, HITL, governance, red teaming, content safety, data quality, drift detection, ethics, accountability |
| `references/monitoring-observability/` | 18 | Azure Monitor, Application Insights, token tracking, KQL, dashboards, alerting, distributed tracing, drift detection, compliance monitoring, cost attribution, data residency, anomaly detection, Copilot observability, streaming, RAG quality, audit logging, SLA |

### 5.2 Cross-references

- **ms-ai-advisor** `references/architecture/`: public-sector-checklist, ai-utredning-template, decision-trees, alternativanalyse-methodology, source-traceability
- **ms-ai-security** `references/ai-security-engineering/`: STRIDE threat modeling, red team operations, content safety calibration, data leakage prevention, PII detection (Norwegian), prompt injection defense, Zero Trust

---

## 6. Beslutningsrammeverk

### 6.1 Naar er DPIA pakrevd?

```
Er personopplysninger involvert?
├── Nei → DPIA ikke pakrevd (men vurder AI impact assessment)
└── Ja →
    ├── Brukes ny teknologi (AI/ML)?
    │   └── Ja → +1 risikofaktor
    ├── Profilering eller systematisk evaluering?
    │   └── Ja → +1 risikofaktor
    ├── Behandling i stor skala?
    │   └── Ja → +1 risikofaktor
    ├── Saerlige kategorier data (Art. 9)?
    │   └── Ja → +1 risikofaktor
    ├── Systematisk monitorering?
    │   └── Ja → +1 risikofaktor
    └── Saarbare grupper (barn, pasienter, trygdemottakere)?
        └── Ja → +1 risikofaktor

Resultat:
  >= 2 risikofaktorer → DPIA er OBLIGATORISK
  1 risikofaktor     → DPIA sterkt anbefalt
  0 risikofaktorer   → Vanlig risikovurdering tilstrekkelig
```

### 6.2 AI Act risikoklassifisering

```
Er AI-systemet paa forbudslisten (Art. 5)?
├── Sosial scoring av myndigheter
├── Utnyttelse av saarbare grupper
├── Biometrisk fjernidentifisering i sanntid (unntak: alvorlig kriminalitet)
├── Emotion recognition paa arbeidsplass/skole (unntak: sikkerhet/medisin)
└── Ja til noen → UAKSEPTABEL RISIKO — Forbudt

Er AI-systemet i Annex III?
├── Biometrisk identifisering
├── Kritisk infrastruktur
├── Utdanning/opplaering
├── Ansettelse/personal
├── Essensielle offentlige tjenester
├── Rettshåndhevelse
├── Migrasjon/grensekontroll
├── Rettsforvaltning/demokrati
└── Ja til noen → HOEY RISIKO — Full compliance-krav

Samhandler systemet direkte med borgere?
├── Chatbot, innholdsgenerering, deepfakes
└── Ja → BEGRENSET RISIKO — Transparenskrav

Ingen av de ovennevnte?
└── MINIMAL RISIKO — Frivillig Code of Conduct
```

### 6.3 Naar skal Datatilsynet konsulteres?

```
Er DPIA gjennomfoert?
├── Nei → Gjennomfoer DPIA foerst
└── Ja →
    Er restrisikoen fremdeles HOEY etter tiltak?
    ├── Nei → Ingen konsultasjonsplikt (men kan gjoeres frivillig)
    └── Ja →
        ├── Forhaandskonsultasjon er OBLIGATORISK (Art. 36)
        ├── Send inn: DPIA-rapport, tiltak, restrisiko-vurdering
        ├── Datatilsynet har 8 uker til aa svare (kan forlenges med 6 uker)
        └── Ikke implementer foer svar foreligger
```

### 6.4 Hvilke Digdir-prinsipper gjelder?

All seven principles apply to every AI system. Prioritize based on system type:

| Systemtype | Prioriterte prinsipper |
|-----------|----------------------|
| Borgervendt tjeneste (chatbot, selvbetjening) | 1-Brukersentrering, 3-Apenhet, 7-Tilgjengelighet |
| Vedtakssystem (saksbehandling) | 4-Sikkerhet, 3-Apenhet, 5-Datakvalitet |
| Integrasjonsloesning (dataflyt mellom etater) | 2-Interoperabilitet, 5-Datakvalitet, 4-Sikkerhet |
| Intern analyse (statistikk, innsikt) | 5-Datakvalitet, 6-Baerekraft, 3-Apenhet |
| Infrastruktur (AI-plattform) | 4-Sikkerhet, 2-Interoperabilitet, 6-Baerekraft |

---

## 7. MCP-verktoy

Use these MCP tools to keep governance knowledge current:

- **microsoft_docs_search** — Search for compliance updates: `"Azure AI responsible AI compliance"`, `"EU AI Act Azure compliance"`, `"Azure data residency EU"`, `"Microsoft GDPR compliance tools"`
- **microsoft_docs_fetch** — Fetch complete regulatory documentation, checklists, and step-by-step guides from search results

Workflow: Search → Fetch relevant pages → Verify against current regulations → Combine with own references for Norwegian context.