Luftgap-kravet
Forsvarsentreprenører, statlige etterretningsbyråer og operatører av kritisk infrastruktur administrerer nettverk der ekstern internett-tilkobling er fysisk umulig, ikke bare forbudt av policy. En SCIF (Sensitive Compartmented Information Facility) er et rom eller en fasilitet designet for å forhindre elektronisk avlytting og signaletterretningsinnsamling — det er Faraday-bur, uten trådløse signaler som går inn eller ut. Et klassifisert statlig nettverk under ITAR (International Traffic in Arms Regulations) kontroll kan ikke overføre dekkede tekniske data til ikke-godkjente parter — en kategori som inkluderer skytjenesteleverandører som ikke er godkjent under ITAR.
For organisasjoner i disse miljøene er "cloud SaaS" ikke en risiko som skal håndteres — det er en teknisk umulighet. Ethvert anonymiseringsverktøy som krever en aktiv nettverkstilkobling kan ikke distribueres. Ethvert verktøy som kontakter hjemmet for lisensverifisering er en ikke-starter. Ethvert verktøy hvis deteksjonsmodeller krever sky-API-anrop for inferens kan ikke fungere.
Ollama-samfunnet nevner spesifikt luftgap-distribusjon som den primære begrunnelsen for lokale AI-verktøy: "Alle data forblir på enheten din med Ollama, uten informasjon sendt til eksterne servere — spesielt viktig for sensitivt arbeid som leger som håndterer pasientnotater eller advokater som gjennomgår saksfiler." Den samme rasjonale gjelder på organisasjonsnivå for klassifiserte og ITAR-kontrollerte miljøer.
ITAR-brukstilfellet
En datavitenskapsmann hos en forsvarsentreprenør som behandler personalregistre under ITAR-krav må de-identifisere filer før de deles med en journalist som har sendt inn en FOIA-forespørsel. Entreprenørens nettverk er luftgapet. Behandlingen må skje på den luftgapede maskinen og må produsere utdata som er egnet for offentlig utgivelse.
Dette brukstilfellet har ingen sky-løsning. Den eneste veien er et verktøy som kjører helt på den lokale maskinen, bruker deteksjonsmodeller lagret lokalt, og produserer anonymiserte utdata uten ekstern kommunikasjon. Desktop-applikasjonen basert på Tauri 2.0 kjører i akkurat denne konfigurasjonen: etter nedlasting og installasjon, gjøres det ingen nettverksanrop under dokumentbehandling. spaCy NER-modellene, regex-mønstrene og transformer-inferensen kjører lokalt. Behandlingsutdata forlater aldri maskinen med mindre de eksplisitt eksporteres av brukeren.
Reversibel pseudonymisering for klassifiserte operasjoner
Et relatert krav i klassifiserte og statlige sammenhenger: reversibel pseudonymisering som opprettholder analytisk nytte samtidig som den beskytter ekte identiteter. GDPR Artikkel 4(5) anerkjenner formelt pseudonymisering som et databeskyttelsestiltak som reduserer samsvarsrisiko — pseudonymiserte data er underlagt reduserte forpliktelser sammenlignet med fullt identifiserbare data, forutsatt at pseudonymiseringsnøklene holdes adskilt fra det pseudonymiserte datasettet.
IAPP-forskning (2024) fant at bare 23 % av anonymiseringsverktøyene tilbyr ekte reversibilitet — evnen til å dekryptere pseudonymiserte data tilbake til originale verdier ved hjelp av en nøkkel som holdes adskilt fra utdataene. Flertallet av verktøyene implementerer permanent erstatning (den originale dataen overskrives og kan ikke gjenopprettes) eller maskering (delvis visning av den originale verdien).
For statlige operasjoner der pseudonymiserte datasett må være delbare på tvers av rom — ett team mottar det pseudonymiserte datasettet for analytisk arbeid, et annet team har dekrypteringsnøkkelen for re-identifikasjon når det er juridisk påkrevd — er reversibel kryptering med nøkkelseparasjon den eneste samsvarende arkitekturen.
Null-kunnskapsmetoden utvider dette ytterligere: krypteringsnøkkelen genereres klientside og overføres aldri. Selv om leverandøren av anonymiseringsverktøyet ble innkalt, kan de ikke produsere dekrypteringsnøkkelen fordi de aldri mottok den. For klassifiserte miljøer der kjede av bevis for krypteringsnøkler er et sikkerhetskrav i seg selv, gir denne arkitekturen den nødvendige tryggheten.
EDPB-retningslinjer for samsvar
EDPB-retningslinjer 05/2022 om pseudonymisering krever nøkkelseparasjon: pseudonymiseringsnøkkelen må holdes av en annen part enn den parten som mottar det pseudonymiserte datasettet, eller lagres med tekniske kontroller som forhindrer den mottakende parten fra å få tilgang til både dataene og nøkkelen samtidig.
Kombinasjonen av klientside nøkkelgenerering (nøkkelen forlater aldri brukerens enhet), lokal behandling (data forlater aldri det luftgapede miljøet), og separat eksport av pseudonymiserte utdata og dekrypteringsnøkler tilfredsstiller EDPBs krav om nøkkelseparasjon samtidig som det oppfyller det luftgapede driftskravet.
Kilder: