Versjon 1.1, 5. november 2026.
Dokumentet viser hvordan Målfrid er plassert etter KI-forordningen, hva registeret over maler og rutiner inneholder, og hvilke plikter som ligger hos Schoolhub og hos kommunen. Forordningen skal innlemmes i EØS-avtalen og gjennomføres i norsk rett. Norske frister og tilsynsordning, og tidslinjen for kravene til høyrisikosystemer, kan bli endret av EUs forenklingsforslag («digital omnibus»). Dokumentet er ikke juridisk rådgivning.
1. Roller
| Part | Rolle etter forordningen | Hva det betyr |
|---|---|---|
| Schoolhub AS | Leverandør av et KI-system som setter sammen modeller fra andre til en tjeneste. Schoolhub utvikler ikke selv generelle KI-modeller | Åpenhet (art. 50), KI-kompetanse (art. 4), og dokumentasjon, kvalitetsstyring og risikostyring i den grad systemet brukes til høyrisikoformål |
| Kommunen | Idriftsetter | Bruk etter bruksanvisningen, menneskelig tilsyn, oppbevaring av logger (art. 26), informasjon til ansatte, DPIA og KI-kompetanse (art. 4) |
| Utviklerne av modellene (blant andre OpenAI, Mistral AI og utviklerne av de åpne modellene) | Leverandører av generelle KI-modeller (art. 53 og 55) | Vi krever dokumentasjon og sammendrag av treningsdata gjennom innkjøpet og avtalene med leverandørene som kjører modellene |
Modellene står i apps/api/src/maalfrid/gateway/models.yaml og på siden «Modeller» på nettstedet. Leverandørene som kjører dem, er:
| Leverandør | Modeller | Startmalen for dataklasser |
|---|---|---|
| GreenPT (Frankrike og Finland) | Kimi K3, GLM 5.3, MiniMax M3, DeepSeek V4.1 Flash, GLM 5.3 Flash og tekstvektormodellen Qwen3 Embedding 8B | Alle fire klasser |
| Mistral AI (Frankrike) | Mistral Large 4, Mistral Medium 3.5, Mistral Small 4, GLM 5.3 (EU-endepunkt), Voxtral Mini Transcribe og Voxtral Mini Realtime (tale til tekst) og Mistral OCR (tekstgjenkjenning) | Alle fire klasser |
| Microsoft Azure OpenAI (EU Data Zone, ressurs i Sverige) | GPT-6.1 Sol, GPT-5.6 Terra, GPT-5.4 mini, GPT-5 nano og bildemodellen GPT Image 1.5 | Av til kommunen slår den på for en klasse |
Kommunen definerer selv dataklassene. Tabellen viser startmalen en ny kommune får. Kommunen bestemmer hvilke klasser hver leverandør og hver modell kan behandle, og en overordnet enhet kan låse valget. En leverandør eller modell kommunen ikke har valgt for en klasse, kan ikke brukes for den. En kommune som endrer startmalen, tar med sitt eget oppsett i sin vurdering etter forordningen. Kimi, GLM, MiniMax, DeepSeek og Qwen er åpne modeller av kinesisk opphav. De kjøres bare av leverandørene i tabellen, aldri av tjenester som drives av kinesiske selskaper. Opphavet vises i modellvalget, og kommunen kan slå av alle slike modeller. Vi krever dokumentasjon og sammendrag av treningsdata fra modellutviklerne (art. 53) gjennom avtalene med leverandørene.
Maler og rutiner som kommunen lager, kan gjøre kommunen til leverandør av et eget system hvis bruksområdet er høyrisiko. Derfor har hver av dem et formål og en risikoklasse i registeret (kapittel 3). Den som tar noe i bruk, står for formålet og risikoklassen. Det trengs ingen godkjenning fra en annen person for å ta noe i bruk (med unntak av deling til en hel enhet, som en leder eller administrator i enheten bekrefter), men hver ibruktaking logges med navn, og tidligere versjoner kan hentes fram.
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 | Målfrid har ingen slike funksjoner. Referat, levende referat og diktering analyserer ikke stemme eller følelser, og HR-assistenten vurderer ikke enkeltpersoner. Formålet står i registeret, og den som tar noe i bruk, står for det |
| Høyrisiko (art. 6 og vedlegg III) | Blant annet arbeidsforhold og HR (rekruttering, vurdering, oppsigelse), tilgang til offentlige tjenester og ytelser, vurdering i utdanning og rettsanvendelse | Plattformen er ikke høyrisiko i seg selv. En assistent som i praksis brukes til slike formål, for eksempel til å rangere søkere eller avgjøre rett til en ytelse, blir høyrisiko. Slike formål er utenfor tjenestens bruksområde, men tjenesten har ingen teknisk sperre mot dem. Kommunen må vurdere formålet før noe tas i bruk |
| Begrenset risiko (art. 50) | Chatboter og KI-generert innhold | Hovedklassen for Målfrid. Brukeren får vite at hen bruker KI, og generert innhold merkes |
| Minimal risiko | Søk, sammendrag og språkvask | Det meste av den daglige bruken |
Kravene til åpenhet i art. 50 gjelder fra 2. august 2026, og Målfrid oppfyller dem slik:
- Eksport til Word, PowerPoint og PDF får en maskinlesbar merking i filens egenskaper: «Dokument laget med KI-assistent, kvalitetssikret av …» med navnet på den som har kvalitetssikret, eller «Utkast laget med KI-assistent. Ikke kvalitetssikret.», sammen med modell, leverandør, region og dataklasse. Selve dokumentet er uten merking, slik at det kan sendes som det er. Når kommunen publiserer tekst for å informere allmennheten, skal en person ha kvalitetssikret og ta det redaksjonelle ansvaret (art. 50 nr. 4). Ellers må kommunen selv opplyse om at teksten er laget med KI. Arkivpakken (Noark) har merkingen og metadataene synlig i dokumentet.
- Utkast og bilder får maskinlesbar merking som KI-generert.
- Modell, leverandør og region vises for hvert svar.
3. Register over maler og rutiner
Registeret er en oversikt i administrasjonsdelen som kan eksporteres. For hver mal (skills) står formål, risikoklasse, dataklasser, kilder og handlinger malen kan bruke, menneskelig kontrollpunkt, eier, versjon og dato. For hver rutine (routines) står malen og versjonen den bruker, ansvarlig, kildene den er bundet til, mottakere og hvem som tok den i bruk. Målfrid er én agent: det finnes ingen egne assistenter, flyter, visninger eller verktøy.
Kommunen lager selv malene og rutinene den trenger. Malene som følger med, er eksempler som kommunen kan ta i bruk eller endre. Hver rutine kommunen oppretter, får sin egen oppføring i registeret med formål og risikoklasse, på samme måte som kommunens egne maler. Formål, risikoklasse og beskrivelse av menneskelig kontroll står i malens frontmatter, og README-en for malen genereres fra den, slik at den ikke kan påstå noe regelverket i koden ikke håndhever. send og journal lager alltid en godkjenning som en person må si ja til.
Eksempler med foreslått risikoklasse
Kommunen som tar et eksempel i bruk, sjekker den foreslåtte klassen med spørsmålene lenger ned og bestemmer den ut fra hvordan malen skal brukes.
| Mal | Formål | Menneskelig kontroll | Merknad |
|---|---|---|---|
| Ukesoversikt: henvendelser og frister | Gi eieren en oversikt over nye henvendelser, oppgaver og frister den neste uka | Oversikten er skrevet til eieren og sender ingenting. Fristene regnes ut i kode | Lav risiko |
| Ta imot henvendelser | Lese nye e-poster i en felles postkasse, foreslå enhet og saksbehandler, lage en oppgave og et svarutkast | Forslag til enhet og hastegrad er forslag en person bekrefter. Alle svar går som godkjenning med nøyaktig innhold | Middels risiko. Fristen regnes ut i kode. Klassen må vurderes på nytt hvis malen brukes til å avgjøre hvem som har krav på en tjeneste |
| Høringsanalyse | Sortere høringsinnspill etter tema og holdning, finne innsigelser og lage grunnlag for oppsummeringen | Innspill avidentifiseres før modellen ser dem, hver konklusjon viser til innspillet den bygger på, og en person gjennomgår konklusjonene. Tallene i matrisen er utkast | Middels risiko |
| Vedtakshistorikk | Svare på spørsmål om kommunens politiske vedtak i tidsrekkefølge, med henvisning til sakene | Kildene vises. Foreslåtte koblinger mellom vedtak er forslag, og svaret sier fra når ingenting er vedtatt | Lav risiko. Bare offentlige dokumenter |
Kommunens egne maler får de samme feltene: formål, risikoklasse og en beskrivelse av den menneskelige kontrollen. Den som lager malen, fyller dem ut ved å svare på fire spørsmål: om malen berører vedtak om enkeltpersoner, rekruttering eller vurdering av ansatte, tilgang til tjenester eller ytelser, eller barn og utdanning. Ett ja gir høyrisiko. Målfrid sier da at kommunen skal stoppe og kontakte personvernansvarlig (kapittel 8), og for å ta malen i bruk må personen krysse av for at personvernansvarlig er kontaktet. Utover dette hindrer ikke tjenesten bruken. En mal der spørsmålene ikke er besvart, står som minimal risiko i registeret.
Deler av en rutine
En rutine kan ha samlinger av poster (for eksempel innspill til en høring), faste trinn som kjører før og etter modellen, kjøring for hvert element i en kilde og en side med resultatene. Hver del har sin egen risiko og er ført for seg i registeret.
| Del | Hva den gjør | Risikoklasse | Menneskelig kontroll | Merknad |
|---|---|---|---|---|
| Samlinger av poster | Lagrer data som personer jobber videre med, med dataklasse, opphav for hvert felt og oppbevaringstid | Avhenger av innholdet. En post får den høyeste dataklassen blant det som kommer inn i den | Det en person har rettet, blir aldri overskrevet av en kjøring. Rettelser logges med feltnavn, ikke verdier | Poster kan inneholde personopplysninger, for eksempel innspill med navn. Innholdet er kryptert med kommunens nøkkel |
| Kilder og tillatte handlinger | Rutinen får bare verktøy for kildene den er bundet til (postkasse, kunnskapsbase, samling, frister, oppgavekø, tilkobling) og handlingene malen tillater (read, write_self, create_task, send, journal) | Avhenger av kildene | send og journal lager alltid en godkjenning bundet til nøyaktig innhold. Kommunen kan stramme inn per dataklasse, aldri løsne. En rutine kan aldri lese mer enn kildelisten, selv om ansvarlig kan | Etter tekst fra en upålitelig kilde har kjøringen ingen verktøy som kan føre innhold ut. Mottakere regnes ut i kode |
| Kjøring for hvert element (fan-out) | Kjører samme oppskrift for hvert innspill eller hver e-post som egen delkjøring med egen kontekst, eget budsjett og én dybde | Begrenset (åpenhet). Minimal hvis innholdet ikke er personopplysninger | Det modellen fyller ut, er forslag. Lav sikkerhet sender posten til en gjennomgangsliste, og en person kan rette hvert felt. Ett innspill kan ikke styre analysen av de andre | Et modellsvar som ikke passer skjemaet, gir feil for det elementet. Delvis feil er synlig per element. Et sitat kan kreves ordrett i kilden, og et felt fylles bare ut når en betingelse er oppfylt |
Faste trinn (pseudonymise, compute_deadlines, check_output, aggregate) | Kode som kjører før og etter modellen: erstatter navn, fødselsnummer, e-postadresser og telefonnumre, regner ut frister, kontrollerer og slår sammen resultater | Personverntiltak og kontroll i kode | Trinn loven eller personvernet krever, overlates aldri til modellen. Frister regnes ut i kode | Pseudonymisering reduserer mengden personopplysninger som går til modellen, men fjerner ikke alle. Fritekst kan avsløre en person på andre måter |
| Side | Viser resultatene som View JSON og lar en person rette et felt, opprette, slå sammen eller arkivere poster | Minimal | Hver handling sjekkes på tjeneren mot rollen til den som bruker siden, og logges før den utføres | Handlingene er et fast sett. Det skrives ingen egen kode i siden |
| Prøv | Kjører rutinen på ekte data uten at noe sendes eller skrives utenfor rutinens egne resultater | Minimal | Alle handlinger svelges av kjøringen. Personen tar rutinen i bruk selv | En rutine kan ikke lage en kobling til et eksternt system eller et vilkårlig kall til nettet. Koblinger til andre systemer er faste verktøy |
| Uten ansvarlig | Når ansvarlig slutter, stopper rutinen og starter ikke av seg selv | Minimal | Administrator får en oppgave, utpeker ny ansvarlig, og den nye gjennomgår kilder, mottakere og det som kom mens rutinen sto stille, før den startes. Tapte kjøringer spilles aldri av i det stille |
Høringsanalyse og Vedtakshistorikk er eksempler på slike maler og er ført i registeret på samme måte som maler kommunen lager selv.
Bildegenerering
Brukeren kan lage bilder og illustrasjoner ut fra en beskrivelse, i samtaler, presentasjoner og dokumenter. Funksjonen er ført for seg i registeret fordi den lager syntetisk innhold etter art. 50.
| Felt | Verdi |
|---|---|
| Formål | Illustrasjoner til presentasjoner, dokumenter og samtaler. Ikke bilder av virkelige personer eller hendelser som skal oppfattes som dokumentasjon |
| Risikoklasse | Begrenset (art. 50(2): syntetisk innhold skal merkes) |
| Modell | GPT Image 1.5 (modell-id gpt-image-1.5) |
| Leverandør og behandlingssted | Microsoft Azure OpenAI, EU Data Zone, ressurs i Sverige. Modellen er av i startmalen til kommunen slår den på for en klasse, og kommunen velger dataklasser for den på samme måte som for andre modeller |
| Av og på | Innstillingen image_generation_enabled slår funksjonen av og på. Den er på som standard, gjelder nedover i organisasjonen og kan låses |
| Maskinlesbar merking | Hvert bilde lagres som PNG med tekstfeltene ai_generated=true, generator (modell-id) og created, og med XMP-data der Iptc4xmpExt:DigitalSourceType er trainedAlgorithmicMedia. Merkingen gjelder også testbilder. Bilder over 2 MB skaleres ned, og merkingen beholdes |
| Synlig merking | Bildet vises med etiketten «KI-generert» i appen. Ved eksport til Word og PowerPoint står etiketten i bildets alternative tekst |
| Menneskelig kontroll | Brukeren ser bildet før det brukes, kan lage et nytt og er ansvarlig for innholdet i dokumentet |
| Logging | Hver generering gir hendelsen image.generate med modell, leverandør, størrelse og kostnad. Beskrivelsen av bildet står ikke i revisjonsloggen. Den lagres kryptert sammen med bildet |
| Grenser | Hastighetsgrense per bruker og enhet (rate_limit_image_generate_per_minute). Beskrivelsen kan være opptil 2 000 tegn |
4. Menneskelig kontroll (art. 14 og 26(2))
Den menneskelige kontrollen er bygd inn i produktet:
- Svar vises som forslag som en saksbehandler vurderer. Eksporterte filer har i egenskapene hvem som har kvalitetssikret, eller at dokumentet ikke er kvalitetssikret.
- Kildene vises med forhåndsvisning, slik at påstander kan kontrolleres.
- Målfrid fatter ingen automatiske vedtak (GDPR art. 22) og har ingen verktøy som skriver til fagsystemer.
- Hver handling som sender eller endrer noe utenfor rutinens egne resultater, stopper ved en godkjenning bundet til nøyaktig innhold, der en person må si ja. Å ta i bruk en mal eller rutine er en bevisst handling av en navngitt person med riktig rolle, og det trengs ingen godkjenning fra en annen. Handlingen logges, versjonene kan ikke endres, og den som har laget noe, kan trekke det tilbake. Endringer du ber om i «Endre»-samtalen, legges inn i utkastet, og «Ta i bruk» lager en ny versjon. Et utkast kjører ikke for andre.
- Det en rutine lager, avgjør ingenting alene: tallene i en matrise og forslagene i en gjennomgang er utkast til en saksbehandler. Der en person har fylt ut et felt, gjelder personens verdi framfor modellens, og kjøringen sier fra om hva den hoppet over.
- Brukeren kan alltid avvise eller overstyre, og handlingen logges.
- Brukerne læres opp i begrensningene til språkmodeller, i oppdiktede svar og i faren for å stole for mye på automatiske forslag.
5. Logging (art. 12 og 26(6))
- Art. 12 gjelder høyrisikosystemer og krever automatisk logging gjennom hele levetiden. Målfrid er normalt ikke høyrisiko, men loggingen er bygd for dette nivået. Revisjonsloggen har aktør, tidspunkt, handling, objekt, enhet, dataklasse, modell, leverandør og region. For hver melding lagres også modell, tekstmengde, kostnad, svartid og kilder.
- Art. 26(6) krever at idriftsetter oppbevarer automatisk genererte logger i minst seks måneder, med mindre annen lov sier noe annet. Revisjonsloggen i Målfrid oppbevares i 5 år. Innhold oppbevares etter fristene kommunen har satt for dataklassen. Kommunen kan eksportere loggen, og samtaler kan eksporteres som Noark 5-pakke.
- Med loggene kan kommunen følge med på driften, oppdage risiko og rapportere alvorlige hendelser (art. 26(5) og 73) til leverandøren og tilsynet.
6. Andre plikter og tiltak
| Krav | Tiltak |
|---|---|
| Art. 4 KI-kompetanse | Kurset «KI-kompetanse» i appen har seks moduler på bokmål og nynorsk, quiz der 80 % riktige svar gir bestått, kursbevis med verifiseringskode og rapport per enhet for ledere. Kommunen kan velge dataklasser som er sperret til brukeren har bestått modul 1 til 4 (for eksempel klassene for taushetsbelagt innhold og personopplysninger) |
| Art. 9 og 17 Risiko og kvalitet (hvis høyrisiko) | ROS-analysen og prosessen for endringer i kapittel 8 kan utvides til et høyrisikosystem |
| Art. 10 Data og datastyring | Kunnskapsbaser har eier, kilde, dato og dataklasse (fra kommunens egen liste). Alt innhold er kryptert med en nøkkel som er egen for kommunen |
| Art. 13 Åpenhet overfor idriftsetter | Dette dokumentet, modelloversikten og brukerdokumentasjonen |
| Art. 15 Nøyaktighet, robusthet og cybersikkerhet | Evaluering på bokmål og nynorsk og testing mot skjulte instruksjoner i tekst (prompt injection) |
| Art. 26(7) Informasjon til ansatte | Kommunen informerer tillitsvalgte og brukere før bruk |
| Art. 27 Konsekvensvurdering for grunnleggende rettigheter | Offentlige idriftsettere av høyrisikosystemer skal gjøre en slik vurdering. Malen følger DPIA-strukturen når den trengs |
| Art. 50 Åpenhet | Se kapittel 2 |
| Art. 53 og 55 Leverandører av generelle KI-modeller | Krav i innkjøpet og i avtalene med leverandørene som kjører modellene |
7. Sammenheng med personvern
Pliktene til idriftsetter etter art. 26 henger sammen med kommunens personvernarbeid:
- DPIA-underlaget, kapittel 4.2, beskriver risikoene som er særlige for KI: oppdiktede svar, skjevhet, kvaliteten på bokmål og nynorsk, for stor tillit til automatiske forslag, skjulte instruksjoner i tekst, lekkasje mellom kommuner og tilgang hos leverandører.
- Registeret over underdatabehandlere viser modellleverandørene.
- Behandlingsprotokollen og malen for personvernerklæring til ansatte dekker informasjonen 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. Revisjonsloggen oppbevares i 5 år, se sletting og lagringstid.
- En konsekvensvurdering for grunnleggende rettigheter (art. 27) trengs bare hvis kommunen tar i bruk en mal eller rutine som er høyrisiko. Den bygger da på DPIA-strukturen.
8. Prosess for endringer
- Ny mal, ny rutine eller nytt bruksområde: klassifiser etter kapittel 3 og før det inn i registeret.
- Mistanke om høyrisiko: stopp ibruktakingen eller trekk tilbake det som er i bruk, kontakt personvernansvarlig og vurder vedlegg III.
- Ny modellleverandør: oppdater registeret over underdatabehandlere, ROS-analysen, overføringsvurderingen hvis data kan gå til tredjeland, og innkjøpsdokumentene.
- Gjennomgang av dette dokumentet: ved hver utgivelse som endrer funksjoner, og minst hver sjette måned.