Luftgapkravet
Försvarsentreprenörer, statliga underrättelsemyndigheter och kritiska infrastrukturoperatörer hanterar nätverk där extern internetanslutning är fysiskt omöjlig, inte bara förbjuden av policy. En SCIF (Sensitive Compartmented Information Facility) är ett rum eller anläggning som är utformad för att förhindra elektronisk avlyssning och signalspaning — den är Faraday-burad, utan trådlösa signaler som kommer in eller går ut. Ett klassificerat statligt nätverk under ITAR (International Traffic in Arms Regulations) kontroll kan inte överföra täckta tekniska data till icke-godkända parter — en kategori som inkluderar molntjänstleverantörer som inte är godkända under ITAR.
För organisationer i dessa miljöer är "moln-SaaS" inte en risk att hantera — det är en teknisk omöjlighet. Alla anonymiseringverktyg som kräver en aktiv nätverksanslutning kan inte användas. Alla verktyg som kontaktar hemmet för licensverifiering är en icke-starter. Alla verktyg vars detektionsmodeller kräver moln-API-anrop för inferens kan inte fungera.
Ollama-gemenskapen nämner specifikt luftgapad distribution som den primära motiveringen för lokala AI-verktyg: "All data stannar på din enhet med Ollama, utan information som skickas till externa servrar — särskilt viktigt för känsligt arbete som läkare som hanterar patientanteckningar eller advokater som granskar rättsfall." Samma resonemang gäller på organisationsnivå för klassificerade och ITAR-kontrollerade miljöer.
ITAR-användningsfallet
En datavetare vid en försvarsentreprenör som bearbetar personalregister under ITAR-krav behöver avidentifiera filer innan de delas med en journalist som begär information enligt FOIA. Entreprenörens nätverk är luftgapad. Bearbetningen måste ske på den luftgapade maskinen och måste producera utdata som är lämpliga för offentlig publicering.
Detta användningsfall har ingen molnlösning. Den enda vägen är ett verktyg som körs helt på den lokala maskinen, tillämpar detektionsmodeller som lagras lokalt och producerar anonymiserade utdata utan någon extern kommunikation. Desktop-applikationen baserad på Tauri 2.0 körs i exakt denna konfiguration: efter nedladdning och installation görs inga nätverksanrop under dokumentbearbetningen. spaCy NER-modellerna, regex-mönstren och transformerinferensen körs lokalt. Bearbetningsutdata lämnar aldrig maskinen om de inte uttryckligen exporteras av användaren.
Återvändbar pseudonymisering för klassificerade operationer
Ett relaterat krav i klassificerade och statliga sammanhang: återvändbar pseudonymisering som bibehåller analytisk nytta samtidigt som verkliga identiteter skyddas. GDPR Artikel 4(5) erkänner formellt pseudonymisering som en dataskyddsåtgärd som minskar efterlevnadsrisken — pseudonymiserade data är föremål för minskade skyldigheter jämfört med fullt identifierbara data, förutsatt att pseudonymiseringsnycklarna hålls åtskilda från den pseudonymiserade dataset.
IAPP-forskning (2024) fann att endast 23% av anonymiseringverktygen erbjuder verklig återvändbarhet — förmågan att dekryptera pseudonymiserade data tillbaka till ursprungliga värden med hjälp av en nyckel som hålls åtskild från utdata. Majoriteten av verktygen implementerar permanent ersättning (den ursprungliga datan skrivs över och kan inte återställas) eller maskering (delvis visning av det ursprungliga värdet).
För statliga operationer där pseudonymiserade dataset måste vara delbara mellan avdelningar — ett team får det pseudonymiserade datasetet för analytiskt arbete, ett annat team har dekrypteringsnyckeln för re-identifikation när det krävs lagligt — är återvändbar kryptering med nyckelåtskillnad den enda efterlevnadsarkitekturen.
Nollkunskapsmetoden utvidgar detta ytterligare: krypteringsnyckeln genereras klientsidan och överförs aldrig. Även om leverantören av anonymiseringsverktyget skulle kallas till domstol kan de inte producera dekrypteringsnyckeln eftersom de aldrig fick den. För klassificerade miljöer där kedjan av bevis för krypteringsnycklar i sig är ett säkerhetskrav, ger denna arkitektur den nödvändiga försäkran.
EDPB-riktlinjer efterlevnad
EDPB Riktlinjer 05/2022 om pseudonymisering kräver nyckelåtskillnad: pseudonymiseringsnyckeln måste hållas av en annan part än den part som tar emot det pseudonymiserade datasetet, eller lagras med tekniska kontroller som förhindrar den mottagande parten från att få tillgång till både data och nyckel samtidigt.
Kombinationen av klientsidigt nyckelgenerering (nyckeln lämnar aldrig användarens enhet), lokal bearbetning (data lämnar aldrig den luftgapade miljön) och separat export av pseudonymiserade utdata och dekrypteringsnycklar uppfyller EDPB:s krav på nyckelåtskillnad samtidigt som den uppfyller det luftgapade driftskravet.
Källor: