open/ms-ai-architect
1
0
Fork 0
Code Issues Releases 1 Activity
ms-ai-architect/skills/ms-ai-governance/references/norwegian-public-sector-governance/digdir-principle-2-interoperability.md
Kjell Tore Guttormsen ddce43d8b2 feat(ms-ai-architect): Spor 1 — Port-1-substrat migrert på 4 ikke-advisor-skills (243 Source + 327 Type + 325 TOC + stale-verified poison fjernet) [skip-docs] 
Steg 9 (R4): unified migrate-corpus.mjs --write over engineering/governance/
infrastructure/security. 327 filer mutert, verified=null, prosa byte-identisk
(fra første ## seksjon), advisor urørt (0 endringer).

To applier-fixes oppdaget under kjøring (TDD, RED→GREEN):
- insertHeaderFields: anker faller nå tilbake når en meta-linje selv passerer
  500B (2 filer pakket et avsnitt i **Status:** → Type/Source landet utenfor
  scan-vinduet, applierens post-write-assertion fanget + restaurerte).
- normalizeStaleVerified: fjerner nå ALLE stale non-date **Verified:** i
  500B-vinduet, inkl. stray body-dup rett under --- (9 mlops-genaiops-filer var
  ellers falskt "verified"/fresh, droppet fra worklist). Operatør-godkjent
  utvidelse av carve-out; kun stray metadata-linjer, aldri prosa.

test-transform-criterion: precondition oppdatert til post-migrasjons-sannhet
(fila bærer nå Source). Suite 728/728 grønn.
2026-07-04 10:19:11 +02:00

15 KiB
Raw Blame History

Digdirs arkitekturprinsipp 2: Samhandlingsevne

Last updated: 2026-05 Status: Gjeldende Category: Norwegian Public Sector AI Governance Type: reference Source: https://learn.microsoft.com/azure/api-management/api-management-key-concepts

Innhold

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):

Regjeringen:

Data.norge.no:

Microsoft Learn:

Sist verifisert: 2026-04-09