Luftgappningskravet
Försvarsentreprenörer, statliga underrättelsemyndigheter och operatörer av kritisk infrastruktur 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 en anläggning designad för att förhindra elektronisk avlyssning och signalunderrättelseinhämtning — den är Faraday-skärmad, utan trådlösa signaler som kan komma in eller gå ut. Ett klassificerat statligt nätverk under ITAR-kontroll (International Traffic in Arms Regulations) kan inte sända täckt teknisk data till icke-godkända parter — en kategori som inkluderar molntjänsteleverantörer som inte är clearade under ITAR.
För organisationer i dessa miljöer är "moln-SaaS" inte en risk att hantera — det är en teknisk omöjlighet. Alla anonymiseringsverktyg som kräver en aktiv nätverksanslutning kan inte driftsättas. Alla verktyg som ringer hem för licensverifiering är uteslutna. Alla verktyg vars detektionsmodeller kräver moln-API-anrop för inferens kan inte fungera.
Ollama-gemenskapen nämner specifikt luftgappad driftsättning som den primära motivationen 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 patientjournaler eller jurister som granskar ärendefiler." Samma logik gäller på organisationsnivå för klassificerade och ITAR-kontrollerade miljöer.
ITAR-användningsfallet
En datavetare hos en försvarsentreprenör som bearbetar personalregister under ITAR-krav behöver avidentifiera filer innan de delas med en journalist som begär utlämnande. Entreprenörens nätverk är luftgappat. Bearbetningen måste ske på den luftgappade maskinen och måste producera utdata lämpliga för offentliggörande.
Detta användningsfall har ingen molnlösning. Den enda vägen är ett verktyg som körs helt på den lokala maskinen, tillämpar lokalt lagrade detektionsmodeller och producerar anonymiserade utdata utan någon extern kommunikation. Det Tauri 2.0-baserade Desktop-programmet körs i exakt denna konfiguration: efter nedladdning och installation görs inga nätverksanrop under dokumentbearbetning. SpaCy NER-modellerna, regexmönstren och transformerinferensen körs lokalt. Bearbetningsresultatet lämnar aldrig maskinen om det inte uttryckligen exporteras av användaren.
Reversibel pseudonymisering för klassificerade operationer
Ett relaterat krav i klassificerade och statliga sammanhang: reversibel pseudonymisering som upprätthå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 reducerade skyldigheter jämfört med fullt identifierbara data, under förutsättning att pseudonymiseringsnycklar hålls separat från det pseudonymiserade datasetet.
IAPP-forskning (2024) fann att endast 23 % av anonymiseringsverktygen erbjuder sann reversibilitet — förmågan att dekryptera pseudonymiserade data tillbaka till originalvärden med hjälp av en nyckel som hålls separat från utdata. De flesta verktyg implementerar permanent ersättning (originaldata skrivs över och kan inte återställas) eller maskering (partiell visning av originalvärdet).
För statliga operationer där pseudonymiserade dataset måste kunna delas mellan avdelningar — ett team tar emot det pseudonymiserade datasetet för analytiskt arbete, ett annat team håller dekrypteringsnyckeln för återidentifiering när det krävs juridiskt — är reversibel kryptering med nyckelseparation den enda kompatibla arkitekturen.
Zero-knowledge-metoden utökar detta ytterligare: krypteringsnyckeln genereras på klientsidan och överförs aldrig. Även om anonymiseringsverktygets leverantör kallades till vittnesförhör kan de inte producera dekrypteringsnyckeln eftersom de aldrig fick den. För klassificerade miljöer där krypteringsnycklarnas spårbarhet i sig är ett säkerhetskrav ger denna arkitektur den nödvändiga försäkran.
EDPB-riktlinjeefterlevnad
EDPB Guidelines 05/2022 om pseudonymisering kräver nyckelseparation: 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 komma åt både datan och nyckeln samtidigt.
Kombinationen av klientsidsgenerering av nyckel (nyckeln lämnar aldrig användarens enhet), lokal bearbetning (data lämnar aldrig den luftgappade miljön), och separat export av pseudonymiserade utdata och dekrypteringsnycklar uppfyller EDPB:s nyckelseparationskrav samtidigt som det möter det luftgappade operativa kravet.
Källor: