ktg-plugin-marketplace/plugins/ms-ai-architect/skills/ms-ai-governance/SKILL.md
Kjell Tore Guttormsen 6a7632146e feat(ms-ai-architect): add plugin to open marketplace (v1.5.0 baseline)
Initial addition of ms-ai-architect plugin to the open-source marketplace.
Private content excluded: orchestrator/ (Linear tooling), docs/utredning/
(client investigation), generated test reports and PDF export script.
skill-gen tooling moved from orchestrator/ to scripts/skill-gen/.

Security scan: WARNING (risk 20/100) — no secrets, no injection found.
False positive fixed: added gitleaks:allow to Python variable reference
in output-validation-grounding-verification.md line 109.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-04-07 17:17:17 +02:00

16 KiB

name description
ms-ai-governance 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.