Versjon 1.1, 21. oktober 2026. Dette er svarene vi gir på spørsmålene som IT-sjefen og personvernombudet i en kommune vanligvis stiller før en anskaffelse. Svarene bygger på databehandleravtalen, DPIA, ROS og de tekniske løsningene i Målfrid. Der noe ikke finnes, står det «Nei» eller «Planlagt», ikke et omskrevet svar.
Kommunen kan bruke tabellene som utfylt spørreskjema. Kolonnen «Dokumentasjon» viser hvor svaret kan kontrolleres.
1. Selskap og ansvar
| Spørsmål | Svar | Dokumentasjon |
|---|---|---|
| Hvem er databehandler? | Schoolhub AS, org.nr. 932739798, Bryggerikaien 24, 4014 Stavanger. Kommunen er behandlingsansvarlig | Databehandleravtale |
| Har dere personvernombud? | Ja. Fresh Compliance GmbH i Berlin, info@freshcompliance.de | Behandlingsprotokoll |
| Hvem kontakter vi om personvern og sikkerhet? | personvern@malfrid.eu | Databehandleravtalen, partsoversikten |
| Bygger avtalen på en kjent mal? | Ja, på KS sin databehandleravtale for kommunal sektor (bilag 3 til SSA-L), med tillegg for KI | Databehandleravtale |
| Bruker dere et anerkjent rammeverk? | Ja, NSMs grunnprinsipper for IKT-sikkerhet som sjekkliste i utvikling og drift. Det er ikke en sertifisering | Egenvurdering etter NSM-prinsippene |
2. Data, sted og leverandører
| Spørsmål | Svar | Dokumentasjon |
|---|---|---|
| Hvor lagres dataene? | Hos Scaleway SAS i Frankrike (Paris). Sikkerhetskopier og katastrofekopi i Amsterdam | Underdatabehandlere |
| Hvor behandles meldingene når en språkmodell svarer? | Hos modellleverandøren, i EU/EØS. Standard er GreenPT (Nederland), som behandler i Frankrike og Finland. Kommunen bestemmer hvilke dataklasser hver leverandør og modell brukes til. Vårt forvalg er alle klasser for GreenPT, og Åpen og Intern for nexos.ai, Mistral AI (fransk selskap) og Microsoft Azure OpenAI (EU Data Zone). Endringer logges. Nettsøk leveres av Staan. Region lagres i loggen for hvert svar | Underdatabehandlerregisteret |
| Brukes amerikanske selskaper? | Microsoft Azure OpenAI (EU Data Zone, Sverige) er amerikansk konsern, og brukes for Konfidensiell og Personopplysninger bare i kommuner som har valgt det. nexos.ai har en amerikansk underleverandør (Fireworks AI, Inc.) og modeller fra amerikanske utviklere, og har derfor Åpen og Intern som forvalg. Mistral AI er et fransk selskap og har også Åpen og Intern som forvalg. Vurderingen av tilgang fra tredjeland står i overføringsvurderingen. | Overføringsvurdering |
| Brukes modeller av kinesisk opphav? | Ja, åpne modeller laget av kinesiske selskaper (Kimi, GLM, MiniMax, DeepSeek, Qwen). De kjøres bare av GreenPT i EU, eller av nexos.ai (forvalg Åpen og Intern). Ingen forespørsel går til kinesisk drevne tjenester. Kommunen kan slå modellene av, og en overordnet enhet kan låse valget | ROS, modellsiden på nettstedet |
| Trenes modeller på våre data? | Nei. Det er forbudt i databehandleravtalen, og kravet gjelder også hver modellleverandør før den slås på. Dette er et avtalekrav som kommunen kontrollerer i avtalene, ikke noe som kan måles i produktet | Databehandleravtalen punkt 3.4 og underdatabehandlerregisteret punkt 3 |
| Kan en leverandør slås på uten at vi vet det? | Nei. En ny eller utskiftet underdatabehandler krever kommunens skriftlige forhåndsgodkjenning, og kommunen varsles minst 30 dager før endringen | Databehandleravtalen punkt 5.3 |
| Hvilke data sendes til modellene? | Meldingen og de kildeutdragene som trengs for svaret. Før en melding sendes, sjekker Målfrid dataklassen mot kommunens regler. Brudd avvises og logges | DPIA |
| Hva skjer hvis en leverandør faller ut? | Bare en annen leverandør som er tillatt for samme eller en strengere dataklasse kan brukes. Ellers får brukeren en feilmelding | ROS, R13 |
3. Dataklasser
| Spørsmål | Svar | Dokumentasjon |
|---|---|---|
| Kan vi skille mellom ulike typer data? | Ja. Brukeren velger Åpen, Intern, Konfidensiell eller Personopplysninger før første melding. Klassen avgjør hvilke modeller som kan brukes, hvordan innholdet lagres, hvor lenge det beholdes og hvor sterk innlogging som kreves. Klassen kan bare heves i en samtale | DPIA |
| Hva skjer hvis noen limer inn et fødselsnummer? | I en åpen samtale avvises meldingen. I andre klasser foreslår Målfrid en høyere klasse. Avvisningen logges | Loggeksempel på siden om personvern og etterlevelse |
| Kan et IKT-samarbeid sette felles regler? | Ja. En overordnet enhet kan låse innstillinger, for eksempel at personopplysninger bare behandles av europeiske leverandører. Samarbeidet kan ikke lese kommunenes samtaler | DPIA |
4. Innlogging og tilgang
| Spørsmål | Svar | Dokumentasjon |
|---|---|---|
| Hvordan logger ansatte inn? | Med kommunens Microsoft Entra ID. Skoler kan bruke Feide. Flerfaktor kreves for alle dataklasser | Databehandleravtalens bilag 4 |
| Kreves sterkere innlogging for sensitive data? | Ja. For Konfidensiell og Personopplysninger kreves sikkerhetsnøkkel eller Windows Hello. For Personopplysninger kreves ny innlogging etter 8 timer | Bilag 4 |
| Hvor avgjøres tilgang? | På tjenersiden, aldri i nettleseren. Roller arves nedover i organisasjonen, og en overordnet enhet kan låse en innstilling | Bilag 4 |
| Kan en kommune lese en annen kommunes data? | Nei. Hver kommunes data er skilt fra de andres i databasen, også gjennom et IKT-samarbeid. Isolasjonen testes automatisk ved hver endring av koden | ROS |
| Hvem hos Schoolhub kan se kundedata? | Bare ansatte med et konkret oppdrag, for begrenset tid, med logging og taushetserklæring. Produksjonsdata brukes ikke i utvikling | Databehandleravtalen punkt 4.5 og bilag 4 |
5. Kryptering
| Spørsmål | Svar | Dokumentasjon |
|---|---|---|
| Er trafikken kryptert? | Ja, all trafikk er kryptert | Bilag 4 |
| Er lagrede data kryptert? | Ja, databaser og fillagring er kryptert i hvile hos Scaleway | Bilag 4 |
| Finnes det ekstra kryptering for sensitive data? | Ja. Innhold i Konfidensielle samtaler og Personopplysninger er kryptert felt for felt før det lagres. Nøkler og hemmeligheter ligger i Scaleway sin nøkkel- og hemmelighetsforvaltning, ikke i koden | Bilag 4 |
6. Logging og innsyn
| Spørsmål | Svar | Dokumentasjon |
|---|---|---|
| Logges bruken? | Ja. Hver melding, hvert svar, administratorhandlinger og avviste forespørsler. Loggen viser hvem, når, dataklasse, modell, leverandør og region, og inneholder ikke samtalen selv | Loggeksempel |
| Kan loggen endres i ettertid? | Applikasjonen kan bare legge til nye linjer, ikke endre eller slette. Hvert døgn lages en kontrollsum per kommune som kobles til forrige døgns kontrollsum, slik at endring i ettertid kan oppdages | DPIA |
| Hvor lenge oppbevares loggen? | 5 år som standard. Avviste forespørsler 365 dager | Sletting og lagringstid |
| Kan vi hente ut loggen? | Ja. Revisor og arkivadministrator eksporterer loggen som JSONL eller CSV. Selve eksporten logges | Loggeksempel |
| Kan vi svare på et innsynskrav? | Ja. Innsynsmodulen søker i samtaler på tvers av brukere i egen kommune, foreslår skjerming med lovhjemmel og lager en utleveringspakke med kontrollsum. Et menneske godkjenner skjermingen | Registrertes rettigheter |
7. Sletting, sikkerhetskopi og avvikling
| Spørsmål | Svar | Dokumentasjon |
|---|---|---|
| Hvor lenge lagres samtaler? | Standard: Åpen 24 måneder, Intern 12 måneder, Konfidensiell 90 dager og Personopplysninger 30 dager. Kommunen kan velge kortere. Journalførte samtaler beholdes til arkivet har bekreftet mottak | Sletting og lagringstid |
| Hvordan skjer slettingen? | Automatisk, en gang i døgnet, etter reglene for dataklassen. Kjøringen logges | Samme dokument |
| Hvilke sikkerhetskopier finnes? | Daglig kopi i 30 dager og ukentlig kryptert kopi i 90 dager, lagret i Amsterdam | Databehandleravtalen bilag 4 og 5 |
| Hva er målet for gjenoppretting? | 4 timer ved sonefeil og 8 timer ved regionfeil | Bilag 4 |
| Hva skjer ved avtalens slutt? | Vi leverer alle data i åpent format (JSON, PDF, Noark 5-pakke, logg som JSONL eller CSV) senest innen 30 dager. Etter kommunens bekreftelse slettes alt. Sikkerhetskopier utløper av seg selv, og alt er borte senest 90 dager etter sletting | Databehandleravtalen punkt 14 |
8. Hendelser og sårbarheter
| Spørsmål | Svar | Dokumentasjon |
|---|---|---|
| Hvor raskt varsler dere om brudd? | Uten ugrunnet opphold, og med mål om innen 24 timer etter at vi oppdager eller mistenker et brudd. Kommunen kan da vurdere meldeplikten til Datatilsynet innen 72 timer | Avvikshåndtering |
| Hvordan holdes programvaren oppdatert? | Automatiske varsler om sårbare avhengigheter, månedlig oppdatering av basebilder og skanning av avhengigheter og hemmeligheter i hver kodeendring | Egenvurdering etter NSM-prinsippene |
| Hvordan endres koden? | Kodegjennomgang og automatiske tester før hver endring. Nye versjoner rulles ut uten nedetid | Bilag 4 |
| Skannes opplastede filer? | Ja, for skadevare. Smittede filer avvises og logges | Bilag 4 |
9. KI-forordningen og personvern
| Spørsmål | Svar | Dokumentasjon |
|---|---|---|
| Hva er Målfrid etter KI-forordningen? | Et KI-system med begrenset risiko. Schoolhub er leverandør, og kommunen er idriftsetter. En assistent som brukes til rangering av søkere eller avgjørelse om ytelser, kan bli høyrisiko og er utenfor omfanget | KI-forordningen |
| Tar Målfrid avgjørelser? | Nei. Svar er utkast med kilder som et menneske vurderer. Målfrid fatter ikke vedtak | KI-forordningen, kapittel 4 |
| Merkes KI-generert innhold? | Ja, i grensesnittet og i eksport | KI-forordningen |
| Hvem eier DPIA-en? | Kommunen. Vi leverer et ferdig underlag og en ROS-analyse som kommunen kopierer og fyller ut sammen med personvernombudet | DPIA |
| Hvilke registrerte rettigheter støtter dere? | Innsyn, retting, sletting, begrensning, portabilitet og protest. Henvendelser til oss videresendes til kommunen, normalt innen tre virkedager | Registrertes rettigheter |
10. Tilgjengelighet
| Spørsmål | Svar | Dokumentasjon |
|---|---|---|
| Følger løsningen WCAG 2.1 AA? | Løsningen er bygd mot nivå AA og testes automatisk. Tilgjengelighetserklæringen beskriver status | Tilgjengelighet |