Ordre 20260912T193441Z-7358817909. Steg 1 var ikke transformen, men å rette
roadmapens R13-gate og få den ratifisert. Gaten `grep -rl "Cosmo"
skills/*/references -> 0` var usann på to uavhengige måter:
1. Ordren fanget den første: 451 av forekomstene er Azure Cosmos DB, ekte
produktinnhold. Diskriminatoren er ikke bokstaven «s» — `Cosmos <norsk
substantiv>` er genitiv av personaen (`### Cosmos tonalitet`), mens
`Cosmos DB`/`CosmosClient`/`cosmos_ru` er produkt.
2. Denne økten fant den andre: 132 persona-forekomster ligger i prosa,
tabeller, dialog-replikker og proveniens-linjer. Heading-nøytralisering
kan ikke nå dem, så «0 persona» er uoppnåelig også under den ratifiserte
formen. Operatøren ratifiserte alternativ A: gaten speiler formen, og de
132 bokføres til R13b/R14.
Tre korreksjoner av premisser som sto i ordren og STATE:
«ca 320 produkt» -> 451 (case-sensitivt nett manglet 327 lowercase
TOC-ankre + 99 identifikatorer; sann nevner 1 638)
«169 headinger» -> 401. 169 var `^## For Cosmo`-prefikset (168) og var
internt inkonsistent med sin egen topp-variant (204)
«417 matcher ingen
populasjon» -> 417 er cosmo-headinger utenfor kodefences; briefens
nevner var reell hele tiden
Fence-bevissthet er målt skadelig, ikke nødvendig: begge toggle-regler er
gale på dette korpuset (naiv toggle skjuler en ekte heading i
chain-of-thought-prompting.md, CommonMark-regelen ubalanserer
service-level-documentation-dr.md). Fence-agnostisk deteksjon finner 401
heading-linjer i nøyaktig de samme 40 variantene som fence-bevisst finner
400 i — ingen kodeblokk-linje er byte-identisk til en persona-heading. Derfor
nøkles transformen på 40 enumererte heading-tekster og ignorerer fences. En
ukjent variant kaster; en slug-kollisjon kaster. Ingenting auto-fikses.
TOC-en regenereres ikke, den rettes kirurgisk: alle 327 persona-lenker hadde
lenketekst lik én av de 40 heading-tekstene og anker lik slugify av den
(327/327, 0 avvik), så heading og TOC-entry skrives i samme operasjon og
ingen mellomtilstand etterlater en død lenke.
Ratifisert målform: `For Cosmo`, `For Cosmo Skyberg` og `For arkitekten
(Cosmo)` konvergerer på `For arkitekten`. To filer kolliderte og er adjudisert
ved å lese dem, ikke ved regel.
Verifisering (alle 7 kriterier fra ordren):
G1 persona på heading-linjer 401 -> 0
G2 døde fragmentlenker 1 -> 1 (pre-eksisterende, unntatt)
G3 produkt-forekomster 451 -> 451; `Cosmos DB|Azure Cosmos` 308 = 308
de 3 kun-produkt-filene byte-identiske
nettet validert begge veier injisert persona feller G1; genitiv feller G1;
produkt-heading og de 3 filene passerer
hele diffen 802 heading-linjer + 654 TOC-linjer, ANNET = 0
linjeantall 728 lagt til = 728 slettet
suite 1120/1120 (1097 + 23 nye)
validate-plugin 250 PASS / 0 FAIL
stikkprøve 10 filer, alle 5 skills, inkl. de 3 mest
produkt-tunge (26/20/19) — kun heading+TOC
Utenfor scope, urørt: de 4 SKILL.md, de 23 commands, CLAUDE.md, README.md,
NOTICE.md, docs/ (alt R14).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
219 lines
12 KiB
Markdown
219 lines
12 KiB
Markdown
# Digital samhandling og EIF - De 5 lagene
|
||
|
||
**Last updated:** 2026-02
|
||
**Status:** Gjeldende
|
||
**Category:** Norwegian Public Sector AI Governance
|
||
**Type:** reference
|
||
**Source:** https://learn.microsoft.com/dynamics365/guidance/techtalks/integrate-finance-operations-overview
|
||
|
||
---
|
||
|
||
## Innhold
|
||
|
||
- [Introduksjon](#introduksjon)
|
||
- [De fem samhandlingslagene](#de-fem-samhandlingslagene)
|
||
- [Anvendelse på AI-løsninger](#anvendelse-på-ai-løsninger)
|
||
- [Microsoft-teknologier per lag](#microsoft-teknologier-per-lag)
|
||
- [Beslutningsveiledning](#beslutningsveiledning)
|
||
- [For arkitekten](#for-arkitekten)
|
||
- [Kilder og verifisering](#kilder-og-verifisering)
|
||
|
||
## Introduksjon
|
||
|
||
Norge implementerte European Interoperability Framework (EIF) da landet signerte Tallinn-erklæringen i 2017, sammen med EU og andre EFTA-land. Norges nasjonale samhandlingsrammeverk heter i dag **Rammeverk for digital samhandling** og bygger på EIF-prinsippene.
|
||
|
||
EIF definerer hvordan offentlige administrasjoner, bedrifter og innbyggere skal kommunisere på tvers av landegrenser i Europa. Rammeverket inneholder 47 anbefalinger organisert rundt tre pilarer: 12 prinsipper for politikkutforming, samhandlingslag, og en konseptuell modell for integrerte offentlige tjenester.
|
||
|
||
Digitaliseringsdirektoratet (Digdir) har ansvaret for norsk rapportering til EIF, og Norge regnes som blant de landene som presterer best på implementering av EIF – selv om det har vært en relativ nedgang det siste året. Rammeverket er obligatorisk når digitale tjenester etableres eller videreutvikles og skal samhandle med andre organisasjoner.
|
||
|
||
## De fem samhandlingslagene
|
||
|
||
Norges tilpasning av EIF opererer med **fem samhandlingslag** (ikke fire, som i original EIF). Det femte laget – styring og forvaltning – går på tvers av de andre lagene og sikrer konsistent governance.
|
||
|
||
### 1. Juridisk samhandling (Legal Interoperability)
|
||
|
||
Juridisk samhandling sikrer at organisasjoner som opererer under ulik lovgivning kan samarbeide, og at rettsgrunnlaget for samarbeid mellom aktører er på plass.
|
||
|
||
**Nøkkelelementer:**
|
||
- Sammenheng mellom nasjonal og europeisk lovgivning (GDPR, AI Act, Forvaltningsloven)
|
||
- Hjemmel for dataflyt mellom offentlige etater
|
||
- Kontraktuelle rammer for deling av data og tjenester
|
||
- Sektorspesifikk lovgivning (helse, utdanning, transport)
|
||
|
||
**AI-spesifikke juridiske hensyn:**
|
||
- AI Act compliance (høyrisiko-klassifisering, GPAI-regler)
|
||
- GDPR Article 22 (automatiserte avgjørelser)
|
||
- Forvaltningsloven § 28 (forsvarlighetskrav for offentlige vedtak)
|
||
- Utredningsinstruksen (krav om konsekvensutredning)
|
||
|
||
### 2. Organisatorisk samhandling (Organisational Interoperability)
|
||
|
||
Organisatorisk samhandling handler om hvordan samarbeidende organisasjoner tilpasser tjenestekjeder, forretningsprosesser, roller og forventninger for å oppnå felles mål og gevinster.
|
||
|
||
**Nøkkelelementer:**
|
||
- Prosessharmonisering på tvers av etater
|
||
- Rolledefinering og ansvarsfordeling
|
||
- Felles forståelse av tjenestenivåer (SLA)
|
||
- Koordinering av endringsinitiativ
|
||
|
||
**AI-spesifikke organisatoriske hensyn:**
|
||
- Etablering av AI-styringsstrukturer (AI councils, review boards)
|
||
- Roller: AI product owner, data scientist, model validator, ethics officer
|
||
- Prosesser for modellgodkjenning og utrullingsflyt
|
||
- Håndtering av modelldrif og kontinuerlig læring
|
||
|
||
### 3. Semantisk samhandling (Semantic Interoperability)
|
||
|
||
Semantisk samhandling omhandler betydningen av dataelementer, forholdet mellom dem, og formatet som informasjon utveksles i.
|
||
|
||
**Nøkkelelementer:**
|
||
- Felles datamodeller og ontologier
|
||
- Standardiserte kodeverk og klassifikasjoner
|
||
- Metadata-håndtering og datakataloger
|
||
- Innholdsstandarder (formater, strukturer)
|
||
|
||
**AI-spesifikke semantiske hensyn:**
|
||
- Embeddings og vektor-representasjoner av semantisk innhold
|
||
- Ontologier for domene-spesifikk kunnskapsmodellering (RAG)
|
||
- Prompt templates og system message standardisering
|
||
- Grounding-datakilder og sannhetsreferanser
|
||
|
||
### 4. Teknisk samhandling (Technical Interoperability)
|
||
|
||
Teknisk samhandling sikrer at ulike systemer kan integrere, og krever teknisk standardisering – som i dag støttes av forskrift om IT-standarder i offentlig forvaltning.
|
||
|
||
**Nøkkelelementer:**
|
||
- API-standarder (REST, OData, GraphQL)
|
||
- Protokoller for datautveksling (HTTPS, AMQP, MQTT)
|
||
- Autentisering og autorisasjon (OAuth2, OIDC, SAML)
|
||
- Integrasjonsmønstre (event-driven, sync/async, batch)
|
||
|
||
**AI-spesifikke tekniske hensyn:**
|
||
- Azure OpenAI API og Microsoft Foundry endpoints
|
||
- Chunking-strategier og vektor-databasegrensesnitt (Azure AI Search)
|
||
- Modell-API versjonering og fallback-mekanismer
|
||
- Token-håndtering, streaming, og rate limiting
|
||
|
||
### 5. Styring og forvaltning (Governance)
|
||
|
||
Det femte laget – styring og forvaltning – går på tvers av de andre lagene. Det sikrer konsistent beslutningsprosess, koordinering og overvåking av samhandlingsevne.
|
||
|
||
**Nøkkelelementer:**
|
||
- Ansvarslinjer og eskaleringsmekanismer
|
||
- Standardiseringsvedtak (påbudt bruk av nasjonale komponenter)
|
||
- Overvåking av samhandlingsevne (EIF-monitorering)
|
||
- Finansierings- og finansieringsmodeller for felleskomponenter
|
||
|
||
**AI-spesifikke styringshensyn:**
|
||
- AI governance frameworks (Microsoft Responsible AI Standard)
|
||
- Modellregister og lineage tracking (Microsoft Foundry model catalog)
|
||
- Red teaming og sikkerhetsevaluering
|
||
- Budsjettmodeller for tokenforbruk (PTU vs pay-per-token)
|
||
|
||
## Anvendelse på AI-løsninger
|
||
|
||
Tabellen under viser hvordan de fem lagene gjelder konkret for AI-løsninger i offentlig sektor:
|
||
|
||
| Lag | AI-spesifikke krav | Eksempler |
|
||
|-----|-------------------|-----------|
|
||
| **Juridisk** | AI Act compliance, GDPR, Forvaltningsloven § 28 | Dokumentasjon av høyrisiko-klassifisering; DPIA for personopplysninger i treningsdata; begrunnelse for automatiserte vedtak |
|
||
| **Organisatorisk** | AI-styringsstrukturer, roller, prosesser | AI council som godkjenner nye modeller; ML engineer vs. domain expert roller; modelldrif-respons-prosedyre |
|
||
| **Semantisk** | Ontologier, embeddings, prompt-standarder | RAG-ontologi for vegsikkerhetsdokumenter; prompt template-bibliotek for saksbehandling; metadata-skjema for syntetiske data |
|
||
| **Teknisk** | API-versjoner, chunking, token-håndtering | Azure OpenAI versjonspinning; 1024-token chunks med 128-token overlap; rate limit retry med exponential backoff |
|
||
| **Styring** | Responsible AI, modellregister, red teaming | Microsoft AI Standards; Azure ML model catalog; monthly red team exercises; PTU reservasjonsbudsjett |
|
||
|
||
## Microsoft-teknologier per lag
|
||
|
||
### Juridisk lag
|
||
- **Azure Policy og Compliance Manager:** Automatisk sjekk av AI Act-krav
|
||
- **Microsoft Purview:** Data governance og lineage tracking
|
||
- **Azure Information Protection:** Klassifisering av sensitive data
|
||
|
||
### Organisatorisk lag
|
||
- **Microsoft 365 Copilot governance:** Admin policies for bruk
|
||
- **Power Platform CoE Starter Kit:** AI governance workflows
|
||
- **Azure DevOps:** Prosessmaler for modell-deployment
|
||
|
||
### Semantisk lag
|
||
- **Azure AI Search:** Vektor- og semantisk søk
|
||
- **Azure AI Document Intelligence:** Strukturert ekstraksjon
|
||
- **Azure OpenAI Embeddings:** text-embedding-3-large for representasjon
|
||
|
||
### Teknisk lag
|
||
- **Azure OpenAI Service:** API for GPT-4o, o1-preview
|
||
- **Microsoft Foundry:** Felles plattform for modell, data, evaluering
|
||
- **Azure API Management:** API gateway med rate limiting og versjonering
|
||
- **Event Grid / Service Bus:** Event-driven AI-workflows
|
||
|
||
### Styrings- og forvaltningslag
|
||
- **Azure AI Content Safety:** Moderation og red teaming
|
||
- **Azure Machine Learning (Responsible AI Dashboard):** Bias-evaluering
|
||
- **Microsoft Copilot Studio Analytics:** Bruks- og kvalitetsdata
|
||
- **Azure Cost Management:** Token- og PTU-kostnadsovervåking
|
||
|
||
## Beslutningsveiledning
|
||
|
||
Tabellen under viser hvilke lag som må vurderes for ulike AI-arkitekturbeslutninger:
|
||
|
||
| Beslutning | Juridisk | Org | Semantisk | Teknisk | Styring |
|
||
|------------|----------|-----|-----------|---------|---------|
|
||
| **Valg av Azure OpenAI vs. Copilot Studio** | ✅ (lisens) | ✅ (roller) | ⬜ | ✅ (API) | ✅ (cost) |
|
||
| **RAG-implementasjon** | ✅ (GDPR) | ⬜ | ✅ (ontologi) | ✅ (chunking) | ✅ (lineage) |
|
||
| **Multimodal AI (vision + text)** | ✅ (AI Act) | ⬜ | ✅ (metadata) | ✅ (API) | ✅ (safety) |
|
||
| **Integrasjon med eksisterende fagsystemer** | ✅ (hjemmel) | ✅ (SLA) | ✅ (format) | ✅ (protocol) | ✅ (monitor) |
|
||
| **Bruk av syntetiske data for fine-tuning** | ✅ (privacy) | ⬜ | ✅ (quality) | ✅ (pipeline) | ✅ (audit) |
|
||
| **Agentic AI med tool calling** | ✅ (ansvarsfordeling) | ✅ (eskalering) | ✅ (function schema) | ✅ (API integration) | ✅ (red team) |
|
||
|
||
Legend: ✅ = kritisk vurdering nødvendig, ⬜ = mindre relevant
|
||
|
||
## For arkitekten
|
||
|
||
Når en kunde spør om digital samhandling og EIF, still disse oppfølgingsspørsmålene:
|
||
|
||
1. **Hvilke andre systemer eller etater skal AI-løsningen integrere med?**
|
||
→ Kartlegg om det er interne systemer, eksterne APIer, eller tverrsektorielle felleskomponenter (Altinn, ID-porten, etc.)
|
||
|
||
2. **Er det etablert databehandleravtaler eller samarbeidsavtaler med eksterne parter?**
|
||
→ Juridisk lag: sjekk om hjemmel for dataflyt er på plass
|
||
|
||
3. **Finnes det eksisterende API-standarder eller integrasjonsmønstre i organisasjonen?**
|
||
→ Teknisk lag: unngå å introdusere nye mønstre hvis etablerte fungerer
|
||
|
||
4. **Hvilke kodeverk, klassifikasjoner eller ontologier brukes i dag?**
|
||
→ Semantisk lag: gjenbruk eksisterende semantiske standarder der mulig
|
||
|
||
5. **Hvem er ansvarlig for modellgodkjenning og sikkerhetsvurdering?**
|
||
→ Organisatorisk og styrings-lag: identifiser AI governance-roller
|
||
|
||
6. **Er det krav om revisjon eller etterprøvbarhet av AI-vedtak?**
|
||
→ Styringslag: design for auditability (model lineage, prompt logging)
|
||
|
||
7. **Er løsningen klassifisert som høyrisiko etter AI Act?**
|
||
→ Juridisk lag: høyrisiko krever ekstra dokumentasjon og conformity assessment
|
||
|
||
8. **Er det budsjett for provisioned throughput units (PTU), eller skal det være pay-per-token?**
|
||
→ Styrings- og kostnadslag: påvirker arkitektvalg (burstiness vs. forutsigbar belastning)
|
||
|
||
## Kilder og verifisering
|
||
|
||
### Digdir og norske myndigheter
|
||
- [Rammeverk for digital samhandling](https://www.digdir.no/digital-samhandling/rammeverk-digital-samhandling/2148) — Hovedsiden for det norske rammeverket
|
||
- [Bruk rammeverk for digital samhandling](https://www.digdir.no/krav-og-anbefalinger/bruk-rammeverk-digital-samhandling-digitale-loysingar-som-skal-samhandle-med-andre/3111) — Krav og anbefalinger
|
||
- [Slik anvender du rammeverket i praksis](https://www.digdir.no/digital-samhandling/slik-anvender-du-rammeverket-digital-samhandling-i-praksis/1689) — Praktisk veiledning
|
||
- [EIF-monitorering](https://www.digdir.no/rikets-digitale-tilstand/eif-monitorering/5235) — Norges årlige EIF-rapportering
|
||
- [Felles struktur og arkitektur for samhandling](https://www.digdir.no/digital-samhandling/felles-struktur-og-arkitektur-samhandling/2150) — Arkitekturveiledning
|
||
|
||
### EU og EIF
|
||
- [European Interoperability Framework (EIF) – official site](https://interoperable-europe.ec.europa.eu/collection/nifo-national-interoperability-framework-observatory/european-interoperability-framework) — EU-portal
|
||
- [New European Interoperability Framework (brochure)](https://ec.europa.eu/isa2/sites/default/files/eif_brochure_final.pdf) — EIF oversiktsdokument
|
||
- [The EIF in detail](https://interoperable-europe.ec.europa.eu/collection/iopeu-monitoring/european-interoperability-framework-detail) — Full detalj om de 47 anbefalingene
|
||
|
||
### Microsoft
|
||
- [Explore integration patterns (Power Platform)](https://learn.microsoft.com/en-us/power-platform/architecture/key-concepts/integration-patterns/patterns) — Instant trigger, event-driven, data consolidation, service-oriented, synchronization
|
||
- [Data integration patterns for Microsoft industry clouds](https://learn.microsoft.com/en-us/industry/well-architected/cross-industry/data-integration-patterns) — Real-time, asynchronous, batch, presentation layer
|
||
- [Integration patterns for Dynamics 365 finance and operations](https://learn.microsoft.com/en-us/dynamics365/guidance/techtalks/integrate-finance-operations-overview) — Synchronous, asynchronous, event-driven
|
||
- [Interoperability with Enterprise Services and COM+ Transactions](https://learn.microsoft.com/en-us/dotnet/framework/data/transactions/interoperability-with-enterprise-services-and-com-transactions) — Teknisk interoperabilitet på transaksjonsnivå
|
||
|
||
---
|
||
|
||
**Merk:** Dette dokumentet beskriver gjeldende rammeverk per februar 2026. EU arbeider med "Next Generation EIF" som forventes vedtatt Q1 2026, og Norge vil måtte tilpasse seg eventuelle endringer i dette rammeverket.
|