Last batch in HIGH bucket. Combined with d60bbd4 (critical 9 + high batch 1, 21 files), this finishes the critical+high KB-refresh sweep for v1.12.0.
Substantive edits (3 files):
- security-copilot-integration.md: M365 E5/E7 inclusion auto-provisioning, agents-first landing experience, role-based onboarding (Verified MCP 2026-05)
- entra-agent-id-zero-trust.md: Ignite 2025-utvidelser — Conditional Access for agenter, Risky agents, 3 nye Agent ID-roller, Microsoft Agent Identity Platform, Copilot Studio blueprint principal
- ai-center-of-excellence-setup.md: Ny "Oppdateringer 2026-05"-seksjon — tre-roller-modell (platform/workload/CoE), agent-ferdighetsområder, sentralisert→rådgivende operasjonsmodell
Date-bump (20 files):
- HIGH-bucket filer der MCP-fetch viste kosmetiske endringer (forrige sesjons lærdom replikert)
Tests: validate-plugin.sh PASS 219.
246 lines
14 KiB
Markdown
246 lines
14 KiB
Markdown
# Digdirs arkitekturprinsipp 2: Samhandlingsevne
|
||
|
||
**Last updated:** 2026-05
|
||
**Status:** Gjeldende
|
||
**Category:** Norwegian Public Sector AI Governance
|
||
|
||
---
|
||
|
||
## Introduksjon
|
||
|
||
Samhandlingsevne (interoperabilitet) er et av Digdirs overordnede arkitekturprinsipper for digitalisering av offentlig sektor. Prinsippet er obligatorisk for statlig sektor og anbefalt for kommunesektoren. I en tid hvor AI-løsninger skal integreres på tvers av virksomheter og sektorer, blir evnen til å dele data, tjenester og semantisk forståelse avgjørende for å realisere verdien av kunstig intelligens.
|
||
|
||
Norge har etablert sitt eget nasjonale rammeverk for interoperabilitet, tidligere kalt NIF (National Interoperability Framework), nå kjent som "Rammeverk for digital samhandling". Rammeverket sikrer at ulike offentlige systemer, inklusive AI-tjenester, kan samhandle effektivt på tvers av juridiske, organisatoriske, semantiske og tekniske grenser.
|
||
|
||
For AI-arkitekter betyr dette at løsninger må designes for integrasjon fra dag én. En AI-tjeneste som ikke kan dele data, API-er eller semantisk forståelse med andre systemer, vil bremse digitaliseringsarbeidet og skape siloer. Samhandlingsevne er derfor ikke bare et teknisk krav, men en strategisk kapabilitet.
|
||
|
||
## Prinsippets kjerneinnhold
|
||
|
||
### Digdirs formulering
|
||
|
||
Arkitekturprinsippene skal bidra til økt samhandlingsevne på tvers av virksomheter og sektorer. Samhandling handler om evnen til å dele informasjon, data og tjenester mellom ulike systemer og organisasjoner – også når de opererer under ulik lovgivning, har forskjellige tekniske plattformer, og bruker ulike begreper for samme fenomen.
|
||
|
||
### De fire lagene av samhandling
|
||
|
||
Digdirs rammeverk for digital samhandling bygger på en firlags-modell som dekker alle aspekter ved interoperabilitet:
|
||
|
||
1. **Juridisk samhandlingsevne**
|
||
- Sikrer at organisasjoner som arbeider under ulik lovgivning kan samhandle
|
||
- Håndterer databehandleravtaler, samtykke, hjemmel
|
||
- Kritisk for AI-løsninger som behandler personopplysninger eller sikkerhetsgraderte data
|
||
|
||
2. **Organisatorisk samhandlingsevne**
|
||
- Definerer ansvarsforhold, roller og prosesser for samhandling
|
||
- Sikrer at forretningsprosesser på tvers av virksomheter fungerer
|
||
- Inkluderer hvordan AI-tjenester forvaltes og eies
|
||
|
||
3. **Semantisk samhandlingsevne**
|
||
- Har å gjøre med betydningen av dataelementer, relasjonen mellom dem, og formatet informasjonen utveksles på
|
||
- Sikrer at dataenes betydningsinnhold og interne relasjoner bevares i kommunikasjonen
|
||
- Omfatter både semantisk aspekt (betydning, begrepsavklaring) og syntaktisk aspekt (eksakt format og struktur)
|
||
- Kritisk for AI-modeller som trenger konsistent dataforståelse
|
||
|
||
4. **Teknisk samhandlingsevne**
|
||
- Sikrer at ulike systemer kan integreres teknisk
|
||
- Krever teknisk standardisering støttet av IT-standardforskriften
|
||
- Omfatter API-design, autentisering, datautveksling
|
||
|
||
Et femte lag, **styring av samhandling**, ligger på tvers og sikrer at de fire lagene koordineres og forvaltes over tid.
|
||
|
||
### Felles datakatalog (data.norge.no)
|
||
|
||
Sentralt i rammeverket står Felles datakatalog (data.norge.no), som gir oversikt over hvilke data de ulike offentlige virksomhetene har, hvordan de henger sammen, og hva de betyr. Kataloger for datasett, begreper, API-er og informasjonsmodeller gjør det mulig for andre å finne og gjenbruke ressurser.
|
||
|
||
Digitaliseringsrundskrivet stiller krav om at virksomheter skal registrere datasett i Felles datakatalog, minimum når tjenester endres eller etableres. For AI-løsninger betyr dette at treningsdata, evaluasjonsdata og prediksjonsresultater bør beskrives og gjøres tilgjengelig for andre.
|
||
|
||
## Anvendelse på AI-løsninger
|
||
|
||
### API-design for AI-tjenester
|
||
|
||
AI-tjenester skal eksponeres som REST-baserte API-er som følger Digdirs anbefalinger:
|
||
- **Versjonering**: Bruk semantisk versjonering (v1, v2) for å sikre bakoverkompatibilitet når modeller oppdateres
|
||
- **OpenAPI-spesifikasjoner**: Dokumenter alle endepunkter med OpenAPI (Swagger) for å støtte discovery og automatisk klientgenerering
|
||
- **Synkrone vs asynkrone API-er**: Store AI-modeller (f.eks. image generation, document analysis) bør bruke asynkrone mønstre med polling eller webhooks
|
||
- **Rate limiting og throttling**: Beskytt AI-infrastruktur mot overbelastning med tydelige politikker
|
||
- **Feilhåndtering**: Returner strukturerte feilmeldinger med HTTP-statuskoder som følger REST-standarder
|
||
|
||
### Datadeling og standarder
|
||
|
||
AI-modeller er avhengige av høykvalitetsdata fra flere kilder. For å sikre samhandling:
|
||
- **DCAT-AP-NO**: Bruk Norges applikasjonsprofil av DCAT (Data Catalog Vocabulary) for å beskrive datasett
|
||
- **Felles begrepsdefinisjoner**: Registrer AI-relaterte begreper (f.eks. "prediksjonsconfidence", "modellevaluering") i Felles datakatalog
|
||
- **Dataformater**: Preferér JSON over XML for moderne API-er, men støtt XML-transformasjon hvis eldre systemer krever det
|
||
- **Data lineage**: Dokumenter hvor AI-treningsdata kommer fra, hvordan de er prosessert, og hvilke transformasjoner som er gjort
|
||
|
||
### Semantisk interoperabilitet for AI-modeller
|
||
|
||
AI-modeller må forstå og produsere data som er semantisk konsistent med andre systemer:
|
||
- **Felles klassifikasjonssystemer**: Bruk KOSTRA-koder, SSB-koder, eller andre standardiserte klassifiseringer
|
||
- **Ontologier og taksonomi**: Når AI-modeller opererer på domenekunnskap (f.eks. helsevesen, transport), må de følge etablerte ontologier
|
||
- **Named Entity Recognition (NER)**: Hvis AI-modeller ekstraherer entiteter fra tekst, må entitetstypene mappes til Felles begreper
|
||
- **Multimodal AI**: Når AI behandler bilder, video og tekst samtidig, må metadata for alle modaliteter følge samme semantiske standard
|
||
|
||
## Microsoft-teknologier for samhandling
|
||
|
||
### Azure Integration Services *(Verified MCP 2026-04)*
|
||
|
||
Microsoft tilbyr en omfattende integrasjonsplattform som støtter alle fire lag av samhandling:
|
||
|
||
Kjerneteknologier (oppdatert): Azure API Management, Azure Logic Apps, Azure Service Bus, Azure Event Grid, Azure Functions, Azure Data Factory. Disse dekker orchestration, messaging, events og API-er som de fire grunnleggende integrasjonsmønstrene.
|
||
|
||
1. **Azure API Management**
|
||
- Publiser AI-modeller som managed API-er med developer portal
|
||
- Implementer rate limiting, caching, authentication og transformation
|
||
- Støtter OAuth 2.0 med Microsoft Entra ID for sikker autentisering
|
||
- Datatransformasjon: XML til JSON, versjonshåndtering, backward compatibility
|
||
- API Center for sentralisert tracking, discovery, reuse og governance
|
||
|
||
2. **Azure Logic Apps**
|
||
- Orkestrer kall til AI-tjenester som del av større forretningsprosesser
|
||
- Koble sammen Microsoft AI (Azure OpenAI, Cognitive Services) med SAP, Dynamics, Salesforce
|
||
- Over 400 konnektorer for både skytjenester og on-premises systemer
|
||
- Reduserer behov for custom integrasjonskode
|
||
|
||
3. **Azure Service Bus**
|
||
- Asynkron meldingsutveksling mellom AI-tjenester og backend-systemer
|
||
- Støtter AMQP (Advanced Message Queuing Protocol) for enterprise messaging
|
||
- Queue-modell (én-til-én) og Topic/Subscription-modell (pub/sub)
|
||
- Sikrer reliable kommunikasjon ved transaksjonsbaserte AI-workloads
|
||
|
||
4. **Azure Event Grid**
|
||
- Event-drevet arkitektur for AI-pipelines
|
||
- Koble sammen AI-tjenester med Azure Functions, Logic Apps, eller custom handlers
|
||
- Forenkler event-basert utvikling med built-in retry-logikk
|
||
|
||
5. **Azure Data Factory**
|
||
- Orkestrer dataflyt mellom kilder for AI-treningspipelines
|
||
- Støtter ETL/ELT for å transformere data til felles format før AI-prosessering
|
||
- Integrerer med Azure AI Search, Azure Machine Learning, Synapse Analytics
|
||
|
||
### Interoperabilitet med Microsoft Agent Framework
|
||
|
||
For agentiske AI-løsninger (hvor flere AI-agenter samhandler):
|
||
- **Shared memory og context**: Bruk Azure Cosmos DB eller Azure Cache for Redis for felles tilstand
|
||
- **Event-driven messaging**: Agenter kommuniserer via Azure Service Bus eller Event Grid
|
||
- **API Gateway pattern**: API Management fungerer som enkeltpunkt for eksterne klienter
|
||
- **Orchestration**: Azure Logic Apps eller Durable Functions orkestrer agentiske workflows
|
||
|
||
## Beslutningsveiledning
|
||
|
||
### Når velge hvilken integrasjonsløsning?
|
||
|
||
| Scenario | Anbefalt løsning | Begrunnelse |
|
||
|----------|------------------|-------------|
|
||
| Eksponere AI-modell for eksterne konsumenter | Azure API Management | Sikkerhet, developer portal, rate limiting, discovery |
|
||
| Orkestrere AI-pipeline med flere steg | Azure Logic Apps | Low-code, 400+ konnektorer, visual designer |
|
||
| Asynkron kommunikasjon mellom AI-tjenester | Azure Service Bus | Garantert levering, load leveling, transactional messaging |
|
||
| Event-drevet AI-arkitektur | Azure Event Grid | Reaktiv, skalerbar, innebygd retry-logikk |
|
||
| Transformere data før AI-prosessering | Azure Data Factory | ETL/ELT-kapabiliteter, datakatalog-integrasjon |
|
||
| Real-time inferencing med lav latency | Azure Functions + API Management | Serverless, autoscaling, minimal overhead |
|
||
|
||
### Vanlige feil ved AI-interoperabilitet
|
||
|
||
1. **Manglende versjonering av AI-modeller**
|
||
- Problem: Når en modell oppdateres, bryter eksisterende klienter
|
||
- Løsning: Semantisk versjonering i API-stier (/v1/predict, /v2/predict)
|
||
|
||
2. **Ingen dokumentasjon av API-kontrakter**
|
||
- Problem: Utviklere vet ikke hvordan de skal konsumere AI-tjenesten
|
||
- Løsning: OpenAPI-spesifikasjoner, automatisk generert dokumentasjon i API Management developer portal
|
||
|
||
3. **Mangel på felles begreper**
|
||
- Problem: Ulike AI-tjenester bruker forskjellige navn for samme konsept
|
||
- Løsning: Registrer begreper i Felles datakatalog, referer til dem i API-dokumentasjon
|
||
|
||
4. **Tett kobling mellom AI-modell og klient**
|
||
- Problem: Endringer i modellen krever endringer i alle klienter
|
||
- Løsning: API Gateway pattern med transformasjon, abstract model-spesifikke detaljer
|
||
|
||
5. **Ingen strategi for asynkron prosessering**
|
||
- Problem: Lange inferencing-tider blokkerer HTTP-connections
|
||
- Løsning: Job-basert API med polling eller webhook-callbacks
|
||
|
||
### Sjekkliste for AI-interoperabilitet
|
||
|
||
- [ ] Er AI-tjenesten registrert i Felles datakatalog (data.norge.no)?
|
||
- [ ] Følger API-et REST-prinsipper og OpenAPI-standard?
|
||
- [ ] Er alle begreper som brukes i API-et definert og registrert?
|
||
- [ ] Støtter API-et versjonering for fremtidige modellendringer?
|
||
- [ ] Er autentisering og autorisasjon implementert (OAuth 2.0 / Entra ID)?
|
||
- [ ] Finnes det en developer portal hvor eksterne kan oppdage og teste API-et?
|
||
- [ ] Er dataformater standardiserte (JSON, DCAT-AP-NO, etc.)?
|
||
- [ ] Håndterer løsningen både synkrone og asynkrone bruksmønstre?
|
||
- [ ] Er integrasjonsmønstre dokumentert i ADR-er?
|
||
- [ ] Følger løsningen IT-standardforskriften for offentlig sektor?
|
||
|
||
## For arkitekten (Cosmo)
|
||
|
||
Når en bruker spør om AI-samhandling, utforsk:
|
||
|
||
1. **Hvilke systemer skal AI-løsningen samhandle med?**
|
||
- Interne virksomhetssystemer (SAP, Dynamics, egenutviklede)?
|
||
- Andre offentlige virksomheters tjenester?
|
||
- Nasjonale fellesløsninger (ID-porten, Altinn, Maskinporten)?
|
||
- Kommersielle SaaS-tjenester?
|
||
|
||
2. **Hvilket lag av interoperabilitet er mest kritisk?**
|
||
- Juridisk: Databehandleravtaler, GDPR-compliance, sikkerhetsgraderte data?
|
||
- Organisatorisk: Hvem eier AI-modellen, hvem drifter, hvem har ansvaret?
|
||
- Semantisk: Bruker ulike systemer samme begreper, eller trengs mapping?
|
||
- Teknisk: Er eksisterende systemer REST-baserte, eller kreves SOAP/XML-støtte?
|
||
|
||
3. **Hva er volumet og latensy-kravene?**
|
||
- Real-time inferencing (< 100ms)?
|
||
- Batch-prosessering (timer/dager)?
|
||
- Synkron eller asynkron kommunikasjon?
|
||
|
||
4. **Er AI-modellen allerede eksponert som API?**
|
||
- Hvis nei: Hvordan skal den pakkes (Azure Machine Learning endpoints, Azure Functions, AKS)?
|
||
- Hvis ja: Følger den Digdirs API-standarder?
|
||
|
||
5. **Hvilke sikkerhetskrav gjelder?**
|
||
- Kreves Maskinporten for system-til-system autentisering?
|
||
- Skal API-et være offentlig tilgjengelig, eller bare internt?
|
||
- Trengs rate limiting og DDoS-beskyttelse?
|
||
|
||
6. **Hvordan skal API-et oppdages og dokumenteres?**
|
||
- Skal det registreres i Felles datakatalog?
|
||
- Skal det finnes en developer portal?
|
||
- Hvordan kommuniseres endringer til konsumenter?
|
||
|
||
7. **Hva er strategien for versjonering og backward compatibility?**
|
||
- Hvordan håndteres breaking changes når modellen oppdateres?
|
||
- Hvor lenge må gamle API-versjoner støttes?
|
||
|
||
8. **Hvordan sikres datakvalitet og lineage i integrasjoner?**
|
||
- Kan AI-modellen stole på datakvaliteten fra integrasjoner?
|
||
- Er det behov for data validation og cleansing før inferencing?
|
||
- Hvordan spores data fra kilde til prediksjon?
|
||
|
||
## Kilder og verifisering
|
||
|
||
Denne kunnskapsreferansen er basert på følgende autoritative kilder:
|
||
|
||
**Digdir (Digitaliseringsdirektoratet):**
|
||
- [Overordnede arkitekturprinsipper](https://www.digdir.no/digitalisering-og-samordning/overordnede-arkitekturprinsipper/1065)
|
||
- [Rammeverk for digital samhandling](https://www.digdir.no/digital-samhandling/rammeverk-digital-samhandling/2148)
|
||
- [Semantisk samhandlingsevne](https://www.digdir.no/digital-samhandling/semantisk-samhandlingsevne/2980)
|
||
- [Felles datakatalog](https://www.digdir.no/felleslosninger/felles-datakatalog/790)
|
||
- [Nye arkitekturprinsipper – ikke bare for arkitekter](https://www.digdir.no/samhandling/nye-arkitekturprinsipper-ikke-bare-arkitekter/1104)
|
||
- [Felles struktur og arkitektur for samhandling](https://www.digdir.no/digital-samhandling/felles-struktur-og-arkitektur-samhandling/2150)
|
||
|
||
**Regjeringen:**
|
||
- [Meld. St. 22 (2020–2021) - Data som ressurs](https://www.regjeringen.no/no/dokumenter/meld.-st.-22-20202021/id2841118/?ch=5)
|
||
- [IT-standarder i offentlig sektor](https://www.regjeringen.no/no/tema/statlig-forvaltning/it-politikk/it-standarder-i-offentlig-sektor/id2354624/)
|
||
|
||
**Data.norge.no:**
|
||
- [API-er - Felles datakatalog](https://data.norge.no/data-services)
|
||
- [Veileder for tilgjengeliggjøring av åpne data](https://data.norge.no/guide/veileder-apne-data)
|
||
|
||
**Microsoft Learn:**
|
||
- [Basic enterprise integration on Azure](https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/enterprise-integration/basic-enterprise-integration)
|
||
- [Integration architecture design](https://learn.microsoft.com/en-us/azure/architecture/integration/integration-start-here) *(Verified MCP 2026-04)*
|
||
- [Modernize applications using an API wrapper](https://learn.microsoft.com/en-us/azure/app-modernization-guidance/expand/modernize-applications-using-an-api-wrapper)
|
||
- [What is Azure API Management?](https://learn.microsoft.com/en-us/azure/api-management/api-management-key-concepts)
|
||
|
||
**Sist verifisert:** 2026-04-09
|