The Problem Nobody Talks About
You encrypt data at rest. You encrypt data in transit. You have TLS everywhere, disk encryption on every volume, and key management policies that would make an auditor weep with joy. None of it matters at the moment your AI model runs inference.
When an AI model processes a prompt, classifies an image, scores a transaction, or generates a response, it operates on plaintext. The data is decrypted, loaded into memory, fed through the model's layers, and the result is written back. During that window — which can last milliseconds or seconds depending on the model — your sensitive data exists unencrypted in system memory, GPU VRAM, CPU cache lines, and potentially in observability logs that capture inputs and outputs for debugging.
Access controls protect who can reach the data. They do nothing about what happens to the data during computation. A compromised host, a malicious insider with infrastructure access, a side-channel attack against the GPU, or a simple logging misconfiguration — any of these expose the plaintext that your encryption-at-rest was supposed to protect.
If your AI model can read the data, so can anyone with access to the model's runtime environment. Encryption that gets stripped before processing is not protecting the processing. It is protecting the storage and the wire. The gap between "encrypted at rest" and "decrypted for inference" is where data breaches happen.
This is not a theoretical concern. Every major AI data incident in 2025 — from inadvertent training data memorization to prompt injection exfiltration to log-based PII exposure — happened at the computation layer, not the storage layer. The industry has spent two decades hardening storage and transit. The processing layer remains wide open.
Where Sensitive Data Gets Exposed in AI Systems
To protect sensitive data from AI, you first need to understand every point where that data exists in plaintext. There are more than most teams realize.
API Request/Response
Every API call to an AI service sends your data in the request body and receives results in the response. Even with TLS, the data is plaintext at both endpoints. API gateways, load balancers, and WAFs can log full request bodies.
Context Windows
LLMs maintain conversation history in their context window. Every previous message — including sensitive data from earlier turns — is re-processed on every subsequent inference call. Context windows are stored in GPU memory in plaintext.
KV Caches
Transformer models cache key-value pairs from attention layers to avoid recomputation. These caches contain encoded representations of your input data and persist in GPU VRAM across requests in long-running sessions.
Observability Logs
Production AI systems log prompts and responses for monitoring, debugging, and quality evaluation. These logs often contain the full plaintext of every input and output, stored in logging infrastructure with weaker access controls than the primary data store.
Model Weights
Models trained on sensitive data memorize fragments of training examples. Research shows that LLMs can regurgitate verbatim training data, including PII, API keys, and medical records, through targeted prompting or membership inference attacks.
CDN & Edge Caches
AI-generated responses served through CDNs or edge compute nodes are cached in plaintext at geographically distributed points. Cached responses containing sensitive data persist until TTL expiry, outside the security perimeter of the origin infrastructure.
Each of these exposure points is an attack surface. Traditional security treats them as separate problems requiring separate controls. But they share a root cause: the data must be decrypted before the model can use it. Eliminate that requirement, and all six exposure points collapse simultaneously.
Why Traditional Approaches Fail
The security industry has proposed several approaches to protect sensitive data in AI systems. Each addresses a symptom while leaving the root cause intact.
| Approach | What It Does | Why It Fails for AI | Verdict |
|---|---|---|---|
| Tokenization | Replaces sensitive values with random tokens before sending to the model | The model cannot operate meaningfully on tokens. A fraud model cannot score a tokenized transaction amount. An NLP model cannot analyze tokenized text. You lose the value of the AI. | FAILS |
| Data Masking | Redacts or anonymizes sensitive fields before inference | Same fundamental problem. Masked data removes the signal the model needs. Masking a patient's age, diagnosis codes, and lab values from a clinical model means the model cannot do its job. | FAILS |
| DLP Scanning | Scans model inputs/outputs for sensitive patterns and blocks or redacts them | Adds 50–200ms latency per request. Scans after the data is already in plaintext. Regex-based detection misses encoded, obfuscated, or contextually sensitive data. False positives block legitimate queries. | FAILS |
| Access Controls | Restricts who can invoke the AI model and what data they can send | Controls the perimeter, not the computation. A credentialed user or a compromised service account can still exfiltrate data through the model. Does not protect against infrastructure-level attacks. | FAILS |
| Encryption at Rest | Encrypts stored data with AES-256 or similar | Completely irrelevant during inference. The data must be decrypted before the model can process it. By definition, encryption at rest does not protect data in use. | FAILS |
| Secure Enclaves (TEE) | Runs inference inside a trusted execution environment (SGX, TrustZone, SEV) | Better than nothing, but enclaves have been repeatedly broken through side-channel attacks (Spectre, Meltdown, Plundervolt, AEPIC Leak). The data is still plaintext inside the enclave — the enclave just narrows the trust boundary. | FAILS |
| FHE | Computes directly on encrypted data without ever decrypting it | The model operates on ciphertext. Plaintext never exists in the processing environment. No side-channel, no log, no memory dump can extract what was never there. | WORKS |
The pattern is clear. Every approach except FHE attempts to limit plaintext exposure. FHE eliminates it. The distinction is not incremental — it is categorical. Limiting exposure means playing a game of probability against attackers. Eliminating exposure means removing the attack surface entirely.
FHE: Computation on Encrypted Data
Fully homomorphic encryption allows mathematical operations to be performed directly on ciphertext. The result, when decrypted, is identical to the result of performing those same operations on the original plaintext. This is not an approximation. It is a mathematical guarantee rooted in the hardness of lattice problems.
Given plaintext values a and b, encrypted as Enc(a) and Enc(b):
Dec(Enc(a) + Enc(b)) = a + b
Dec(Enc(a) × Enc(b)) = a × b
Addition and multiplication on ciphertext are sufficient to compute any function. The model processes encrypted data, produces encrypted results, and never accesses the decryption key.
For AI inference, this means the model receives encrypted inputs, performs its forward pass entirely on ciphertext — matrix multiplications become homomorphic multiplications, additions remain additions — and returns encrypted outputs. The client, who holds the decryption key, decrypts the result. At no point during computation does plaintext exist on the server.
This is not theoretical. BFV and CKKS FHE schemes are production-ready. BFV handles exact integer arithmetic (ideal for classification, scoring, and matching). CKKS handles approximate floating-point arithmetic (ideal for neural network inference with real-valued weights). H33 implements both, optimized down to 38 microseconds per operation.
The security of FHE rests on the Ring Learning With Errors (RLWE) problem, a lattice-based hardness assumption that is believed to be resistant to both classical and quantum computers. This means FHE-protected AI inference is not just private today — it remains private against future quantum adversaries running Shor's algorithm.
How H33 Implements This
One API call. That is the integration surface. H33 AI Compliance wraps your AI inference pipeline in FHE so that the model's infrastructure never sees plaintext — and you do not need to become a cryptographer to deploy it.
Client-Side Encryption
Input data is encrypted on the client using the H33 SDK before it leaves the client's environment. The encryption key never leaves the client. The server receives ciphertext only.
Encrypted Inference
The AI model performs its computation entirely on encrypted data. Matrix multiplications, activation functions, attention layers — all executed homomorphically. The model produces encrypted results without ever accessing plaintext.
ZK-STARK Attestation
Every operation is cryptographically attested with a ZK-STARK proof. The proof verifies that the computation was performed correctly on the encrypted data without revealing the data itself. You get integrity, not just confidentiality.
Post-Quantum Signatures
The encrypted result and its STARK proof are signed with Dilithium (ML-DSA), a NIST-standardized post-quantum signature scheme. This provides tamper evidence that survives quantum computing advances.
Client-Side Decryption
The client receives the encrypted result, verifies the STARK proof and Dilithium signature, and decrypts locally. The plaintext result exists only on the client device — never on the server, never in logs, never in cache.
The entire pipeline — FHE encryption, homomorphic inference, STARK proof generation, Dilithium signing — executes in a single API roundtrip. H33's optimized BFV implementation processes operations at 38.5 microseconds per authentication on production hardware, with a sustained throughput of over 2.17 million operations per second. This is not batch processing on a nightly schedule. It is real-time encrypted inference at API latencies that are indistinguishable from plaintext processing.
Real-World Applications
FHE-protected AI inference is not a solution looking for a problem. It is the answer to compliance questions that currently have no good answer in regulated industries.
PHI-Blind Diagnosis
AI diagnostic models process patient data — lab results, imaging, vitals — without ever seeing it in plaintext. HIPAA compliance becomes cryptographic, not procedural. The cloud provider cannot access PHI even under subpoena, because it was never decrypted on their infrastructure.
Encrypted Fraud Scoring
Transaction scoring models evaluate fraud risk on encrypted transaction data. Account numbers, amounts, merchant identifiers, and behavioral patterns remain encrypted throughout the entire scoring pipeline. PCI DSS scope collapses because cardholder data is never processed in plaintext.
Privileged Document Analysis
AI-powered contract review and document analysis operates on encrypted legal documents. Attorney-client privilege is maintained cryptographically. The AI provider cannot read the documents, cannot be compelled to produce them, and cannot inadvertently train on them.
Blind Resume Screening
AI screening models evaluate encrypted candidate data without seeing names, demographics, addresses, or photos. Bias is eliminated at the cryptographic level — the model literally cannot access protected attributes. EEOC compliance is provable, not aspirational.
In each case, the pattern is identical: the AI model does its job on encrypted data, and the organization gets the value of AI without the liability of plaintext exposure. Compliance audits shift from "show me your access controls" to "show me your encryption proof" — and a ZK-STARK proof is considerably harder to argue with than a policy document.
Make Your AI Blind to Sensitive Data
H33 AI Compliance wraps your AI inference pipeline in fully homomorphic encryption. One API call. Zero plaintext exposure. Cryptographic proof of every operation. Start with 10,000 free API calls — no credit card required.
Get Started with AI Compliance →