Why Architecture Matters More Than Privacy Policies
The Stored Communications Act, encryption theater, and the question your vendor hopes you never ask: where does your data exist during processing?
The Heppner ruling puts a question in front of every attorney using commercial AI: does my tool's architecture survive a court asking who had access to this content? Most legal AI vendors answer with policies—ZDR agreements, DPAs, SOC 2 certifications, encryption at rest. These matter. But policies are promises. They don't survive a court order that compels production of data the vendor already has. This article walks through four layers of the problem—from the Stored Communications Act to vector embeddings—and explains why the answer is architectural, not contractual.
Layer 1: The Stored Communications Act Problem
Legal AI vendors that receive and store user content are almost certainly "remote computing services" (RCS) under 18 U.S.C. § 2711(2)—services that provide "computer storage or processing services by means of an electronic communications system." If you are sending documents to a vendor's server for AI processing, that vendor is providing remote computing services.
This classification carries consequences most attorneys never consider:
- § 2703: The government can compel production of stored communications and records from an RCS provider with a court order or subpoena. The standard is lower than you think—a § 2703(d) order requires only "specific and articulable facts" showing the records are "relevant and material," not probable cause.
- § 2705: Delayed-notice provisions mean the government can obtain a court order prohibiting the provider from notifying you that your data was disclosed. Your vendor may not be allowed to tell you they handed over your documents.
Your legal AI vendor can be compelled to produce your data, and they may not be allowed to tell you. This is not a hypothetical—it is the statutory framework under which every SaaS vendor operates.
For a detailed analysis of the SCA's application to legal AI vendors, see our Stored Communications Act framework analysis.
The key point: your DPA's data custodian designation does not override federal statute. The SCA does not care who the contract calls the custodian. If the vendor stores your data on their servers, law enforcement can compel production regardless of what your DPA says about custody, processing roles, or data ownership.
Layer 2: The Encryption Illusion
"Encrypted at rest" is the most reassuring phrase in legal AI marketing. It is also the most misleading.
Encryption at rest means data is encrypted when stored on disk. This protects against unauthorized physical access to the storage medium—a stolen hard drive, an unauthorized database dump. It does not protect against the vendor itself.
During AI inference, your content is plaintext in the vendor's compute environment. The vendor must decrypt your documents to process them. The KMS (Key Management Service) keys sit on the same infrastructure. "Encrypted at rest" means the vendor locked the door and kept the key in the lock.
- SOC 2 audits storage security and access controls—it does not audit what happens during inference processing
- MFA protects against unauthorized login—it does not change what the vendor can access once authenticated
- Encrypted databases protect against external breach—they do not protect against the vendor's own access to plaintext during processing
Where does your data exist during processing, and who can access it? Every security checkbox on a vendor's marketing page addresses data at rest or in transit. None addresses data during inference—when your privileged content is decrypted, loaded into GPU memory, and processed in plaintext on the vendor's infrastructure.
This is not a criticism of encryption. Encryption at rest is necessary. But it is a storage control, not a processing control. For privileged legal content, the processing moment is where exposure occurs—and no amount of storage-layer encryption addresses it.
Layer 3: The Vector Embeddings Problem
Many legal AI vendors offer features that require persistent representations of your documents on their infrastructure. Two architectures are particularly problematic for privilege analysis:
RAG (Retrieval-Augmented Generation)
RAG pipelines work by vectorizing your documents into numerical embeddings stored in a vector database. When you ask a question, the system similarity-searches these embeddings to find relevant chunks, then feeds those chunks to the language model.
The embeddings are a semantic representation of your documents that persists on the vendor's infrastructure. They encode meaning—topics, relationships, arguments, facts. Even if the original text is deleted, the embeddings remain queryable.
Knowledge Graphs
Some vendors build knowledge graphs from your documents—extracting entities (people, companies, dates, claims) and relationships (represented by, filed against, argued that) into a persistent graph database. This is an even more explicit encoding of your case information.
Both RAG and knowledge graphs are structurally incompatible with zero-knowledge claims. The vendor has a semantic representation of your documents on their servers. The embeddings and graph nodes encode meaning that can be reconstructed, queried, or subpoenaed. You cannot claim zero knowledge while maintaining a knowledge graph of your client's documents.
A vendor who says "we delete your documents after processing" but maintains vector embeddings of those documents has not deleted the information—they have transformed it into a different representation that still encodes the substance of your privileged content.
For more on why RAG pipelines are problematic for legal documents specifically, see Why RAG Will Make You Sad (In Law).
Layer 4: The Architectural Answer
The first three layers describe the same fundamental problem: when your content exists on someone else's infrastructure, policies cannot guarantee what happens to it. Contracts promise. Statutes compel. Architecture constrains.
The architecture that resolves each of these layers has three properties:
Pillar 1: Local-Only Client
Your documents, prompts, and chat history exist only on your device. A desktop application—not a web app—processes documents locally. No server-side storage of work product. The vendor's server has zero content fields in its database schema because it was never designed to receive content.
This eliminates the SCA exposure: the vendor is not an RCS for your content because they never receive it. There is nothing to compel production of. There are no embeddings, no knowledge graph, no vector database—because the vendor never had the documents to vectorize.
Pillar 2: Zero Data Retention
The AI provider processes queries in transient memory and immediately discards. No disk writes, no logs, no training. Contractual ZDR agreements with the AI provider ensure ephemeral processing.
This addresses the inference-time exposure: the content is plaintext during processing, but only in the AI provider's ephemeral compute. No copy persists. The processing moment is transient by contract and by design.
Pillar 3: Ephemeral Key Exchange
The vendor provisions AI access through ECDH key agreement without ever touching user queries. The server generates credentials on-demand, encrypts them with the client's public key, and never stores them. The vendor distributes keys; it never sees payloads.
This eliminates the vendor from the content path entirely. Your content goes from your device directly to the AI provider. The vendor occupies the authentication plane—never the data plane.
Policies are promises. Architecture is physics. We rely on physics.
| Dimension | SaaS Wrapper | Architectural Controls |
|---|---|---|
| Content path | Through vendor servers | Direct device-to-provider |
| SCA exposure | Vendor compellable | Nothing to compel |
| Inference-time data | Plaintext on vendor infra | Plaintext at provider only (ZDR) |
| Persistent representations | Embeddings, graphs, logs | None—no server-side content |
| Subpoena response | "We have a DPA" | "We have nothing to produce" |
| Privilege analysis | Third-party disclosure occurred | No third-party disclosure |
Any one pillar alone is insufficient. A local client that sends queries through a vendor's relay server has a custody gap. Zero Data Retention without a local client still puts content on the vendor's servers in transit. Passthrough authentication without ZDR leaves content sitting on the provider's infrastructure. Together, they produce the zero-knowledge property: the vendor cannot know what you asked. The provider cannot retain what you sent. Your device is the only place your work exists.
FAQ
Isn't a strong DPA enough to protect privilege?
A DPA assigns processing roles and contractual obligations. It does not change the underlying architecture. If the vendor receives and processes your content, a court order under the SCA can compel production regardless of what your DPA says about custody. The DPA is necessary for regulatory compliance (GDPR, CCPA). It is not sufficient for privilege preservation against compelled disclosure.
What about vendors who say they delete data after processing?
Deletion policies are contractual commitments. They help. But they create a window of exposure between receipt and deletion during which the data exists on the vendor's infrastructure and can be intercepted, compelled, or inadvertently retained. More importantly, check whether the vendor maintains vector embeddings or knowledge graphs derived from your documents—those persist even after the original text is deleted.
Is running a local model the most private option?
Yes. A fully local model with no network calls is the privacy ceiling. We say this openly. But local models do not yet match the capabilities of frontier models (Gemini, GPT-4, Claude). For attorneys who need those capabilities with the strongest available privacy architecture, the three-pillar approach—local client, ZDR, ephemeral key exchange—is the answer.
How does this relate to the Heppner ruling?
Rakoff found "not remotely any basis" for the privilege claim: Heppner disclosed to a third-party AI that expressly disclaimed confidentiality. The work product claim failed separately—the documents were prepared by the defendant, not by or at the direction of counsel. The architectural question Heppner surfaces is broader than either ground: any tool where the vendor receives your content creates a potential third-party disclosure. Enterprise ZDR agreements improve the analysis. Architectural controls that eliminate vendor access to content resolve it entirely. See our full Heppner analysis.
See the Architecture
inCamera is built on architectural controls—local-only client, Zero Data Retention, ephemeral key exchange. We are never in the data path.