A practical guide to digital self-defense — for privacy-conscious individuals who refuse to be profiled, harvested, or surveilled.
Acknowledgement: This guide is for educational purposes only. See the Legal Disclaimer at the bottom before taking any action.
Section A — What "Sovereign AI" and "Sovereign Data" Mean
Sovereign AI
Sovereign AI means artificial intelligence that runs entirely under your control — on your own hardware, in your own environment, with no dependency on a remote cloud server. You own the model, the inference engine, and the data. No company can read your prompts, log your conversations, update the model without your consent, or hand your data to a government under foreign law.
Simple test: If unplugging your internet connection stops the AI from working, it is not sovereign.
Sovereign Data
Sovereign data means you — not a corporation, not a cloud provider, not a government — control where your data lives, how it is encrypted, who can access it, and under which jurisdiction it sits. True data sovereignty requires:
Storage you physically own or fully encrypt before it leaves your hands
Encryption keys that only you hold
Access controls you configure and audit
Backups stored in locations and jurisdictions of your choice
Why Cloud AI Is Inherently Non-Sovereign
Every major cloud AI service — regardless of how privacy-friendly its marketing appears — has structural features that undermine sovereignty:
Telemetry and logging: Prompts, responses, usage patterns, and metadata are routinely logged, even when providers claim otherwise.
Training data pipelines: Terms of service frequently reserve the right to use your conversations to improve models.
Foreign jurisdiction: Servers located in the United States, EU, or other jurisdictions are subject to the laws of those regions — regardless of where you live.
The CLOUD Act (US): The Clarifying Lawful Overseas Use of Data Act (2018) allows US law enforcement to compel US-based cloud providers to hand over data stored anywhere in the world — including data belonging to non-US citizens.
No verifiability: You cannot audit what a closed cloud AI model does with your input after you send it.
Bottom line: If your data touches a cloud server you do not own, you have ceded sovereignty over it.
Section B — Threat Model
A threat model is a structured way of asking: Who wants my data, why, and what can they do with it? Different adversaries require different defenses.
Threat Governments
Mass surveillance: Bulk interception of internet traffic by intelligence agencies (e.g., PRISM, XKeyscore programs).
Data retention laws: Many countries require ISPs and cloud providers to retain metadata and content for months or years.
Cross-border access: MLAT treaties, Five Eyes intelligence sharing, and the CLOUD Act allow governments to reach data held in other jurisdictions.
Device seizure: Border agents and law enforcement can seize and image devices without a warrant in many jurisdictions.
Prompt logging: Your questions to cloud AI systems are stored on remote servers.
Training data harvesting: Conversations may be used to improve models unless you explicitly opt out — and opt-out mechanisms are not always reliable or verifiable.
Third-party data sharing: AI providers may share de-identified (but often re-identifiable) data with research partners or affiliates.
Model updates without notice: The AI you interact with today may behave differently tomorrow due to silent updates.
Adversary
Primary Goal
Key Lever
Primary Defense
Government
Surveillance, control
Legal compulsion
Encryption, jurisdiction choice
Corporation
Profit from data
Terms of service
Minimization, local storage
Criminal
Financial gain
Exploits, social engineering
Backups, strong auth, patching
Cloud AI provider
Model improvement, analytics
TOS acceptance
Local AI, no sensitive prompts
Section C — Sovereign AI in Practice
Running AI locally means your prompts never leave your device. The following stack lets you use powerful AI tools without trusting any third party.
Step 1 — Choose a Local Model
Open-source models can run on consumer hardware. Well-regarded families include:
Llama (Meta) — widely supported, strong general capability
Mistral / Mixtral — efficient, high quality per compute unit
Qwen (Alibaba) — strong multilingual performance
Phi (Microsoft) — small but capable, good for low-power hardware
Gemma (Google) — open weights, competitive quality
Why open-source? You can inspect the weights, verify no hidden telemetry is baked in, and run the model fully offline. Closed models from cloud providers are black boxes by definition.
LM Studio — desktop GUI for Windows/Mac/Linux, easy model management
Jan — open-source desktop app with offline-first design
llama.cpp — lightweight C++ runtime, runs on CPU with no GPU required
GPT4All — privacy-focused desktop app for non-technical users
Step 3 — Keep All Supporting Data Local
Embeddings: Generate vector embeddings locally using models like nomic-embed or sentence-transformers. Never send documents to a cloud embedding API.
Vector databases: Use local vector stores such as Chroma, Weaviate (self-hosted), or FAISS. Your document index stays on your machine.
Documents and context: Feed sensitive documents to your local AI directly — never upload them to a cloud AI service.
Step 4 — Operational Rules for AI Usage
Use cloud AI only for non-sensitive, publicly available information where privacy is not a concern.
Never paste passwords, private keys, financial records, medical data, or personal identifiers into a cloud AI prompt.
Treat any cloud AI prompt as potentially logged and stored indefinitely.
Prefer open-source models you can audit over proprietary models you cannot.
When in doubt, run it locally.
Section D — Sovereign Data Storage
Data sovereignty exists on a spectrum from fully air-gapped to internet-connected. Each tier offers different trade-offs between accessibility and security.
Tier 1 — Offline / Air-Gapped
The highest level of protection. Data is never connected to a network. Suitable for seed phrases, private keys, legal documents, and irreplaceable archives.
Encrypted SSDs/HDDs:
VeraCrypt — cross-platform, open-source, supports hidden volumes for plausible deniability
LUKS — Linux native full-disk encryption, robust and audited
BitLocker — Windows built-in; use only with a locally held key, not Microsoft account escrow
Write-once archival media (M-Disc): Millenniata M-Disc uses a stone-like recording layer estimated to last 1,000+ years. Not rewritable — provides tamper evidence and durability against magnetic damage.
Paper backups: QR codes encode data compactly on paper. Seed phrases for cryptocurrency wallets and encryption keys can be stored on durable archival paper or stamped into stainless steel.
Faraday protection: A Faraday cage blocks electromagnetic signals, protecting against remote activation, RF attacks, and EMP events.
A microwave oven (unplugged) provides basic Faraday shielding for small devices
Commercial Faraday bags — purpose-built for phones, drives, and cards
Ammo cans lined with foam provide low-cost, robust EMP and RF protection
Tier 2 — Near-Offline (LAN-Only)
Data is accessible within your home or office network but never exposed to the internet. High availability with strong privacy.
TrueNAS (Scale or Core): Enterprise-grade open-source NAS OS with ZFS filesystem, built-in encryption, and RAID support.
Unraid: Flexible NAS/server platform popular with home users; supports encrypted drives and Docker-based local services.
Synology NAS: Consumer-friendly hardware with optional full-volume encryption; disable QuickConnect for LAN-only operation.
NUC / Raspberry Pi servers: Low-power mini-computers running Linux, suitable for hosting local services like Nextcloud, Home Assistant, or local AI models.
Start9 / Umbrel: Self-sovereignty platforms designed to run encrypted local services (file storage, messaging, Bitcoin nodes) without cloud dependencies.
LAN-only rule: Firewall your NAS to deny all inbound and outbound connections from the WAN interface. Access it only from trusted devices on your local network.
Tier 3 — Online but User-Controlled
If internet access to your data is required, self-hosting is far more sovereign than using a third-party cloud provider.
Nextcloud: Full-featured self-hosted cloud storage, calendar, contacts, and office suite. Run it on a VPS you control or on hardware at home behind a VPN.
Seafile: High-performance self-hosted file sync with client-side encryption (Seafile Drive Client encrypts files before they leave your device).
Security requirements for self-hosted:
TLS (HTTPS) with a valid certificate — use Let's Encrypt
Hardware security keys (YubiKey, FIDO2) for two-factor authentication
Strong, unique passwords managed by a local password manager (Bitwarden self-hosted or KeePassXC)
Automatic security updates and regular audits of exposed services
Warning: Third-party cloud services — even "encrypted" providers like Dropbox, Google Drive, or iCloud — are never fully sovereign. The provider holds the keys or can be compelled to create access. Self-host or store nothing sensitive.
Section E — Operational Security (OpSec)
Operational security is the discipline of protecting information through consistent habits and practices. Good OpSec closes the gaps that strong encryption alone cannot.
Password Hygiene
Use a unique, randomly generated password for every account — no reuse, ever.
Minimum 16 characters; prefer 24+ for critical accounts.
Store passwords in a local password manager: KeePassXC (fully offline) or Bitwarden (self-hosted).
Enable hardware two-factor authentication (YubiKey, FIDO2) on all critical accounts.
Avoid SMS-based 2FA — SIM-swapping attacks are common and effective.
Full-Disk Encryption
Encrypt every device: laptop, desktop, phone, tablet, external drive.
Encryption is useless if the device is powered on and unlocked — lock your screen when stepping away.
On Linux: LUKS with a strong passphrase. On macOS: FileVault with a local recovery key (not iCloud). On Windows: VeraCrypt or BitLocker with a locally stored key.
Do not store your encryption key or recovery key in a cloud service.
Browser Privacy
Browser choice: Firefox (with hardening) or Brave for general use. Tor Browser for high-sensitivity browsing.
Essential extensions: uBlock Origin (ad and tracker blocking), Privacy Badger, and Cookie AutoDelete.
DNS: Use an encrypted DNS resolver (DNS-over-HTTPS or DNS-over-TLS) — or run your own Pi-hole for network-wide blocking.
Search engine: DuckDuckGo, Startpage, or SearXNG (self-hosted) instead of Google or Bing.
Disable WebRTC in browsers to prevent IP leaks when using a VPN.
Clear cookies and site data regularly; use container tabs to isolate sessions.
Any task involving personal data, business strategy, legal matters, medical information, or financial details should use a local AI model only.
Treat the boundary between your local machine and the internet as a hard security boundary for AI usage.
The 3-2-1 Backup Rule
3 copies of your data — 2 different media types (e.g., SSD + external drive) — 1 copy stored offline or off-site
Copy 1: Primary storage (your working drive)
Copy 2: Local backup (encrypted external drive, stored in a different physical location in your home)
Copy 3: Offline or off-site backup (encrypted drive at a trusted off-site location, or an encrypted cloud archive where you hold the decryption key)
Automate backups — a backup you have to remember to run will eventually not run.
Section F — Resilience & Disaster Planning
Data sovereignty means nothing if your data is destroyed by a disaster. Resilience planning ensures you can recover from fire, theft, flood, hardware failure, or ransomware.
Physical Threat Protection
Fire: Store at least one backup copy off-site — a fire that destroys your home destroys every drive in it. A fireproof safe provides limited protection (most are rated for paper, not drives).
Flood and water damage: Store drives in sealed, waterproof containers. Keep off-site backups above flood level.
Theft: Full-disk encryption means a stolen drive is useless without your passphrase. Do not write your passphrase on the drive or store it nearby.
EMP / Geomagnetic events: Faraday protection (ammo cans, Faraday bags) protects against electromagnetic pulses. M-Disc optical media is immune to magnetic fields.
Off-Site Encrypted Backups
Encrypt your backup archive before it leaves your hands, using a key only you hold.
Tools: Restic (command-line, encrypted, supports many backends), Borg Backup, or Duplicati (GUI, encrypted).
Off-site options: a trusted family member's location, a safety deposit box, or a rented dedicated server where you store only pre-encrypted archives.
Checksum Verification
Generate a SHA-256 checksum of every important file after creation and store the checksum separately from the file.
After any backup or restore operation, verify the checksum matches to confirm data integrity.
Bit rot (silent data corruption) can occur over years on HDDs and optical media. ZFS (used in TrueNAS) performs automatic checksum verification on stored data.
Test Restores — The Most Overlooked Step
A backup you have never restored from is an untested assumption. Schedule a full restore test at least once per year. Verify that your encrypted backups can actually be decrypted and that all critical files are intact.
Document your restore procedure in writing, stored offline.
Include a list of the tools and passphrases needed to decrypt and access your backups.
Store this documentation separately from your backups — a ransomware attack that encrypts your drives should not also destroy your recovery instructions.
Section G — Data Poisoning: What It Is & How It Protects You
What Is Data Poisoning?
Data poisoning is the intentional modification, corruption, or manipulation of data to influence how an AI model learns or behaves. When an AI model is trained on large datasets scraped from the internet, the content of that data directly shapes the model's outputs, biases, and capabilities.
Data poisoning works in two directions:
Offensive poisoning — used by attackers to degrade, mislead, or subvert AI systems. An attacker who can inject bad data into a training pipeline can cause the model to learn incorrect facts, develop dangerous behaviors, or produce predictably wrong outputs.
Defensive poisoning — used by privacy-conscious individuals to prevent unauthorized AI training on their data. By subtly modifying the data you publish, you can make it far less useful as training material without making it look visually different to a human reader.
Key principle: If companies scrape your data without consent to train AI systems, you have a right to make that data as unhelpful to them as possible.
Types of Data Poisoning
Type 1Label Flipping
In supervised learning, every training example has a label (e.g., "this image shows a cat"). Label flipping assigns incorrect labels to training data — telling the model that cats are dogs, or that benign emails are spam. When a model trains on enough flipped labels, its classification behavior degrades or inverts. This is primarily an offensive technique used to attack commercial AI pipelines.
Type 2Content Corruption
Content corruption embeds misleading patterns or deliberately incorrect information within training data. An example is writing text that looks coherent and authoritative but contains subtly false facts or contradictory statements. If this content is scraped at scale, the model learns from the corrupted signal and may produce systematically wrong outputs on related topics.
Type 3Adversarial Noise
Adversarial noise involves adding carefully calculated perturbations — modifications so small that human eyes cannot detect them — to images, audio, or text. The result looks identical to the original but causes AI models to misclassify, misinterpret, or fail to learn useful representations from it. This is the most technically sophisticated form of data poisoning and is the basis of several defensive tools described below.
Type 4Watermarking
Watermarking embeds a hidden, detectable signature into your data — an imperceptible pattern that persists through scraping and training. If a model is later found to reproduce your watermarked data, the watermark provides forensic evidence that your content was used without authorization. This enables legal action and attribution. Watermarking is a purely defensive technique — it does not degrade AI systems; it makes unauthorized use of your data traceable.
The following techniques are available to individuals who want to protect their images, documents, and personal data from being scraped and used for AI training:
Cloak your photos before uploading: Tools like Glaze and Fawkes (developed at the University of Chicago) add imperceptible adversarial noise to portrait images. To a human viewer, the photo looks normal. To a facial recognition or style-learning AI, the image is confusing and produces useless training signal. Use these tools on any photos you publish publicly.
Add adversarial noise to artwork and illustrations:Glaze specifically protects artistic style from being replicated by generative AI. Artists who publish their work online can apply Glaze to prevent models from learning their unique visual style from scraped images.
Poison documents to disrupt text model training: Tools like Nightshade embed perturbations into image files that, when used as training data, cause generative models to associate concepts incorrectly. Applying Nightshade to images before publication can collectively degrade the usefulness of scraped datasets.
Watermark your content for traceability: Embed invisible watermarks in your writing, images, and documents using tools like Stegano (Python library) or commercial watermarking services. If your content appears in AI training data or model outputs, the watermark provides proof of origin.
Publish strategically misleading public data: If you maintain a public presence, consider intentionally publishing false or contradictory information about yourself in places likely to be scraped — wrong middle names, fictional job titles, decoy biographical details. Surveillance systems and data brokers that aggregate this information will incorporate the noise, degrading the accuracy of any profile built on you.
Use robots.txt and legal notices: Include explicit instructions in your website's robots.txt file prohibiting AI training crawlers. While not technically enforceable, it establishes intent and may support legal arguments in jurisdictions where training data scraping is regulated.
Ethical Boundaries
Defensive poisoning is ethically acceptable when you are protecting your own data — your images, your writing, your identity. You are not obligated to make your data useful for systems that exploit it without consent.
Offensive poisoning is a different matter entirely. Deliberately corrupting training data belonging to or used by others — particularly in ways intended to cause safety failures, spread false information, or harm third parties — is unethical and may constitute criminal activity under computer fraud, sabotage, or telecommunications laws in many jurisdictions.
The line is clear: Protect your own data aggressively. Do not weaponize data poisoning against systems or people that did not consent to receive it.
Related Video Resource
The following video provides additional context on AI sovereignty, data privacy, and protecting yourself from surveillance systems:
Related Reading — ai.tedlee.ca
These articles from ai.tedlee.ca provide deeper analysis on surveillance, AI risks, and digital defence:
Educational purposes only. This page is provided for general educational and informational purposes. It is not legal advice, financial advice, cybersecurity advice, or professional guidance of any kind.
No guarantee of protection. No method, tool, or technique described on this page guarantees protection from government surveillance, corporate data collection, criminal activity, data loss, or any other harm. Security is probabilistic, not absolute.
Local laws apply. Data privacy and encryption laws vary significantly by country, state, and jurisdiction. Some techniques described here — including strong encryption, data poisoning, and VPN use — may be restricted or prohibited in certain regions. You are solely responsible for complying with all applicable laws and regulations in your jurisdiction.
No liability. The author, publisher, and any associated parties assume no responsibility or liability for any actions taken — or not taken — based on the information presented on this page. Use of any tool, technique, or method described here is entirely at your own risk.
Consult professionals. For specific legal, financial, or security concerns, consult a qualified lawyer, certified security professional, or financial advisor in your jurisdiction.
No endorsement. Mention of specific tools, software, or services on this page does not constitute endorsement, recommendation, or warranty of fitness for any particular purpose. Evaluate all tools independently before use.