Versjon 1.2, 21. oktober 2026. Forordningen innlemmes i EØS-avtalen og skal gjennomføres i norsk rett. Fristene og tilsynsstrukturen i Norge, og tidslinjen for kravene til høyrisikosystemer, kan endres av pågående forenklingsforslag («digital omnibus»). Vi gjennomgår dokumentet ved hver utgivelse som endrer funksjon, og minst hver sjette måned. Dokumentet er ikke juridisk rådgivning.
1. Roller
| Part | Rolle etter forordningen | Konsekvens |
|---|---|---|
| Schoolhub | Leverandør av et KI-system som setter sammen modeller til en tjeneste. Bruker generelle KI-modeller fra tredjeparter som komponent, og er ikke selv leverandør av slike modeller | Åpenhet (art. 50), dokumentasjon, kvalitets- og risikostyring i den grad systemet er høyrisiko, KI-kompetanse (art. 4) |
| Kommunen | Idriftsetter | Bruk i tråd med instruks, menneskelig tilsyn, oppbevaring av logger (art. 26), informasjon til ansatte, DPIA, KI-kompetanse (art. 4) |
| Modellleverandører (OpenAI via Microsoft, Anthropic og Mistral via nexos.ai, og Mistral AI direkte) | Leverandører av generelle KI-modeller (art. 53 og 55) | Vi krever dokumentasjon og sammendrag av treningsdata fra dem som del av databehandleravtalen og innkjøpet |
Modellene som er tilgjengelige står i apps/api/src/maalfrid/gateway/models.yaml og på siden «Modeller» på nettstedet. Hos Microsoft Azure OpenAI: GPT-6.1 Sol, GPT-5.6 Terra, GPT-5.4 mini og GPT-5 nano. Hos nexos.ai: Claude Opus 5.5, Sonnet 5.5, Haiku 5.5, Mistral Small 4, Kimi K3, GLM 5.3 og DeepSeek V4.1 Flash. Hos Mistral AI: Mistral Large 4, Medium 3.5 og Small 4 (forvalg Åpen og Intern; kommunen avgjør), med Voxtral (tale til tekst) og Mistral OCR som valgfrie tilvalg. Hos GreenPT: Kimi K3, GLM 5.3, MiniMax M3, DeepSeek V4.1 Flash og GLM 5.3 Flash, og tekstvektormodellen Qwen3 Embedding 8B. Kimi, GLM, MiniMax, DeepSeek og Qwen er åpne modeller av kinesisk opphav som bare kjøres av GreenPT i EU eller nexos.ai; opphavet vises i modellvalget, og kommunen kan slå dem av. Dokumentasjon og sammendrag av treningsdata fra modellutviklerne (art. 53) er ikke innhentet ennå og står som oppgave i ISMS T-16.
Kommunens egne assistenter, laget i assistentbyggeren, kan gjøre kommunen til leverandør av et eget system hvis bruksområdet er høyrisiko. Derfor har hver assistent et formål og en risikoklasse i registeret (kapittel 3), og utgivelse krever godkjenning (utkast, gjennomgang, publisert).
2. Risikoklasser og hvor Målfrid ligger
| Klasse | Eksempler | Målfrid |
|---|---|---|
| Forbudt praksis (art. 5) | Sosial scoring, følelsesgjenkjenning på arbeidsplassen og i utdanning, manipulerende teknikker | Ingen funksjon i Målfrid. Referatfunksjonen gjør ikke stemme- eller følelsesanalyse, og HR-assistenten vurderer ikke enkeltpersoner. Assistentbyggeren har retningslinje og godkjenningssjekk mot forbudte formål |
| Høyrisiko (art. 6, vedlegg III) | Blant annet arbeidsforhold og HR (rekruttering, vurdering, oppsigelse), tilgang til offentlige tjenester og ytelser (vurdere kvalifikasjon), utdanning (vurdering) og rettsanvendelse | Plattformen er ikke høyrisiko i seg selv. En assistent som i praksis brukes til slike formål, for eksempel å rangere søkere eller avgjøre rett til ytelse, blir høyrisiko. Slike formål er utenfor tjenestens bruksområde og blokkeres i godkjenningen av assistenter |
| Begrenset risiko (art. 50) | Chatboter og KI-generert innhold | Hovedklassen. Brukeren skal informeres om at hen samhandler med KI, og syntetisk innhold merkes |
| Minimal risiko | Søk, sammendrag og språkvask | Kjernebruk |
Kravene til åpenhet i art. 50 gjelder fra august 2026 og er innført. Det er KI-merking i brukergrensesnittet og i eksport («Utkast laget med KI-assistent, kvalitetssikret av …»), maskinlesbar markering av generert tekst i artefakter, og tydelig angivelse av modell, leverandør og region.
3. Register over assistenter
Registeret er en oversikt i administrasjonsdelen som kan eksporteres. Hver assistent har formål, risikoklasse, dataklasser, tillatte leverandører, kilder, verktøy, menneskelig kontrollpunkt, eier, godkjenner, versjon og dato. Startsettet:
| Assistent | Formål | Risikoklasse | Menneskelig kontroll | Merknad |
|---|---|---|---|---|
| Klarspråk og målform | Omskrive tekst til klarspråk og mellom bokmål og nynorsk | Minimal | Brukeren leser og godkjenner før bruk | Trenger ingen personopplysninger. Standard dataklasse er Intern |
| Referat | Transkribere møteopptak og lage referat etter mal | Begrenset (åpenhet) | Møteleder godkjenner referatet. Opptak krever varsling til deltakerne | Ingen følelsesgjenkjenning (art. 5(1)(f)). Konfidensiell som standard for HR- og personalmøter |
| Politisk sak-søk | Søke i og sammenfatte saksframlegg, protokoller og planer med kildehenvisning | Minimal | Kildene vises, og brukeren verifiserer | Bare offentlige dokumenter (dataklasse Åpen) |
| HR-reglement | Svare på spørsmål om kommunens personalreglement med sitater | Minimal (grensetilfelle) | Brukeren verifiserer mot kilden. Assistenten vurderer ikke enkeltpersoner og gir ikke råd i konkrete personalsaker | Blir høyrisiko hvis den brukes til å vurdere eller rangere ansatte eller søkere. Dette er blokkert i ledeteksten og i godkjenningen |
| Byggesaksveileder | Veilede om regelverk, sjekklister og krav i byggesak | Begrenset | Saksbehandler tar avgjørelsen. Ingen vedtak | Revurderes hvis den påvirker retten til en tjeneste, med vurdering av høyrisiko |
Kommunens egne assistenter får de samme feltene. Godkjenningsskjemaet inneholder en obligatorisk risikoklassifisering med sjekkpunkter: berører assistenten vedtak om enkeltpersoner, rekruttering eller vurdering av ansatte, tilgang til ytelser, eller barn og utdanning? Svaret «ja» gir blokkering og eskalering til personvernansvarlig.
4. Menneskelig kontroll (art. 14 og 26(2))
Menneskelig kontroll er bygget inn i produktet, ikke bare beskrevet i prosedyrer:
- Svar presenteres som utkast, ikke som avgjørelser. Eksport krever at brukeren fyller ut «kvalitetssikret av».
- Kilder vises med forhåndsvisning, slik at påstander kan etterprøves.
- Det er ingen automatiske vedtak (art. 22 i GDPR) og ingen verktøy som skriver til fagsystemer.
- Assistenter går gjennom en godkjenningsflyt (gjennomgang, publisert) som logges.
- Brukeren kan alltid avvise eller overstyre, og handlingen logges.
- Brukerne læres opp i begrensninger, hallusinasjon og automatiseringsskjevhet.
5. Logging (art. 12 og 26(6))
- Art. 12 gjelder høyrisikosystemer og krever automatisk logging over systemets levetid. Selv om Målfrid normalt ikke er høyrisiko, er loggingen bygget til dette nivået. Revisjonsloggen har aktør, tidspunkt, handling, objekt, enhet, dataklasse, modell, leverandør og region. For hver melding lagres også modell, antall tokens, kostnad, svartid og sitater.
- Art. 26(6) krever at idriftsetter oppbevarer automatisk genererte logger i minst seks måneder, med mindre annen lov krever noe annet. Standard i Målfrid er 5 år for handlingsloggen. Innhold oppbevares etter dataklasse. Dere kan eksportere logger, blant annet som Noark 5-pakke.
- Loggene lar dere følge opp driften, oppdage risiko og rapportere alvorlige hendelser (art. 26(5) og 73) til leverandør og tilsyn.
6. Øvrige forpliktelser og tiltak
| Krav | Tiltak |
|---|---|
| Art. 4 KI-kompetanse | Opplæring av pilotbrukere og administratorer med dokumentert deltakelse. Modulen «KI-kompetanse» i appen har seks moduler på bokmål og nynorsk, quiz med 80 % for å bestå, kursbevis med verifiseringskode og rapport for ledere per enhet. Dere kan velge å sperre dataklassene Konfidensiell og Personopplysninger til brukeren har bestått modul 1–4 |
| Art. 9 og 17 Risiko og kvalitet (hvis høyrisiko) | ROS-analyse og beslutningsprosess finnes og kan utvides |
| Art. 10 Data og datastyring | Kunnskapsbaser har eier, kilde, dato og dataklasse |
| Art. 13 Åpenhet overfor idriftsetter | Denne dokumentasjonen, modellkort for tilgjengelige modeller og bruksanvisning |
| Art. 15 Nøyaktighet, robusthet og cybersikkerhet | Evaluering per språk og testing mot skjulte instruksjoner i tekst (prompt injection) |
| Art. 26(7) Informere ansatte | Kommunen informerer tillitsvalgte og brukere før bruk |
| Art. 27 Konsekvensvurdering for grunnleggende rettigheter | Offentlige idriftsettere av høyrisikosystem skal gjøre en slik vurdering. Malen følger DPIA-strukturen hvis det er aktuelt |
| Art. 50 Åpenhet | Innført, se kapittel 2 |
| Art. 53 og 55 Leverandører av generelle KI-modeller | Krav i innkjøp og databehandleravtale mot modellleverandørene |
6b. Sammenheng med personvern
Kravene til idriftsetter etter art. 26 henger sammen med kommunens personvernarbeid:
- DPIA kapittel 4.2 beskriver KI-spesifikke risikoer: hallusinasjon, skjevhet, kvalitet på nynorsk og bokmål, automatiseringsskjevhet, skjulte instruksjoner i tekst, lekkasje mellom kommuner og leverandørtilgang.
- Register over underdatabehandlere viser modellleverandørene.
- Behandlingsprotokollen og malen for ansatte dekker informasjon til ansatte (art. 26(7)) og skillet mot kontrolltiltak etter arbeidsmiljøloven kapittel 9.
- Kravet om menneskelig tilsyn og logging oppfylles av funksjonene i kapittel 4 og 5. Handlingsloggen oppbevares i 5 år, se sletting og lagringstid.
- En konsekvensvurdering for grunnleggende rettigheter (art. 27) er bare aktuell hvis kommunen tar i bruk en assistent som er høyrisiko. Den bygger da på DPIA-strukturen.
7. Prosess for endringer
- Ny assistent eller nytt bruksområde: klassifiser (kapittel 3) og før i registeret.
- Mistanke om høyrisiko: stopp publiseringen, kontakt personvernansvarlig og vurder vedlegg III.
- Ny modellleverandør: oppdater register over underdatabehandlere, ROS, TIA ved overføring til tredjeland, og innkjøpsdokumentasjonen.
- Gjennomgang av dette dokumentet og kapittel 6b: ved hver utgivelse som endrer funksjon, og minst hver sjette måned.