← Back to all posts

Why We Built Nera ChatApp to Never See Your Data

By Ed Chow, CPO, Nera Systems

There’s a design decision baked into Nera’s architecture that we made early and haven’t revisited. Not because we couldn’t, but because every customer conversation since has confirmed we got it right.

The decision: the LLM never sees your data in plaintext. Not Gemini. Not ChatGPT. Not Claude. Not us. Nobody.

That constraint sounds simple. Getting there wasn’t.

What Customer Conversations Taught Us

I’ve now had versions of the same conversation many times. The person on the other side is a VP of Analytics, a Chief Data Officer, or a CISO. They’re not skeptical about AI. They’re already using it, on their easy data. Public datasets. Sanitized reports. Internal wikis that contain nothing sensitive.

The question they keep asking isn’t “does AI work?” It’s: How do we use AI on the data we actually care about?

Patient records. Client portfolios. Proprietary pricing models. Cross-company datasets collected under sharing arrangements that explicitly prohibit third-party exposure. The data that would actually move the needle sits untouched, locked out of their AI strategy—not because of technical limits, but because of a trust gap they can’t close.

What made the problem concrete for me was a consumer products analytics use case: two companies wanting to analyze shared retail data to understand consumer behavior across brands. The insight they needed was sitting right there. But getting to it meant months of work before a single query could run: legal teams on both sides, NDAs, data sharing agreements negotiated line by line, a trusted third-party vendor brought in under carefully scoped terms.

By the time the analysis was done, the market window had often moved on. And if either side wanted a follow-up question, the process started over.

That’s the real cost. Not inaction, but expensive, inflexible action. Months of legal overhead to run an analysis that should take minutes. A process so cumbersome that most questions never got asked.

That use case set the criteria for everything we built:

  • Eliminate the trust problem structurally, not with contracts.

  • Do it at the speed of a question, not a legal review.

The Constraint That Became the Product

With those criteria in hand, we evaluated every serious option.

TEE-Based Services

Hardware-isolated enclaves that process data in a protected bubble the cloud provider theoretically can’t see.

Compelling architecture, but TEEs transfer trust to a chip vendor with a documented history of side-channel vulnerabilities. We’d be replacing one trust question with another.

Tokenization and Redaction

Tokenization deploys fast and keeps the vault with the data owner. But tokenization is substitution, not encryption. The LLM receives a placeholder where the real value was. It can read around it, but it cannot compute on it.

Ask it to identify accounts with declining revenue when the revenue figures have been replaced with tokens, and the analysis fails. You’ve protected the leaves but not the tree.

Trust-the-Vendor Enterprise AI

Microsoft 365 Copilot, ChatGPT Enterprise, Claude Enterprise, Gemini—all promise no training on your data, SOC 2 compliance, and contractual indemnity.

For a lot of data, that’s reasonable.

But the vendor still sees your plaintext. For regulated data or cross-organizational collaboration, a contractual promise is legally insufficient. You’re back to the same third-party trust problem the CPG use case exposed.

Self-Hosted Private LLMs

Self-hosted private LLMs keep data inside your environment but strand you on open-weight models that permanently lag the frontier.

The analytical capability you need lives in commercial models in someone else’s cloud.

Other PETs Vendors

Other PETs vendors had the right architectural idea: data encrypted during processing, customer holds the keys.

But conventional implementations carried four problems that made them unusable:

  1. Always-on ciphertext inflation that bloated storage and made datasets impractical to transmit.

  2. High latency.

  3. Months-long deployment requiring deep cryptographic expertise.

  4. No path to commercial LLMs.

The technology was sound. The product wasn’t there.

What we wanted was simple to state: A way to use frontier commercial LLMs on data those LLMs can never actually read.

Encryption that holds not just in transit, not just at rest, but during processing.

That’s the architecture we built.

The Hard Part Nobody Talks About

The reason other PETs vendors never cracked enterprise AI isn’t that the cryptography was wrong. It’s four practical problems we had to solve.

Storage Inflation and Bandwidth

Conventional encryption-in-use keeps data inflated at all times. A modest dataset becomes a massive, impractical upload.

Nera uses inflate-on-use:

  • Data is stored and transmitted at close to its original size.

  • Inflation only occurs at computation.

The file you upload to Nera ChatApp is essentially the same size as your original spreadsheet.

Result: up to 10,000× better storage efficiency versus conventional implementations.

Latency

Operating on always-inflated ciphertext is slow at every step.

Inflate-on-use plus algorithmic improvements gets us up to 100× faster than conventional approaches.

The real remaining gap: encryption adds overhead plaintext doesn’t. But that overhead is a fraction of LLM inference time.

Result: total end-to-end latency is typically under 2× plaintext, often imperceptible to users waiting on analytical results.

Deployment Complexity

Months of integration. Deep cryptographic expertise required. Nera is SaaS with commercial LLMs already integrated.

Result: days to deploy, no cryptographic expertise needed.

No Path to GPT, Gemini, or Claude

The one problem conventional implementations never solved. Nera built an architecture that lets commercial LLMs reason on encrypted data without reading it. Not a fix to an old problem. A new capability the category didn’t have.

What It Looks Like in Practice

A customer uploads a financial dataset: quarterly revenue by account, confidential client names, and deal values.

They type:

Which accounts show declining revenue over the last three quarters, and what’s the aggregate exposure?

Step 1: Encryption at Source

Before the file leaves the customer’s environment, Nera encrypts it client-side using their key. The key never moves. The encrypted file—close to original size—is what gets transmitted.

Step 2: Query Decomposition

The LLM analyzes the query structure, determining what computations need to run against your data. It never sees the data itself, only the shape of the question.

Step 3: Encrypted Computation

Nera’s data infrastructure performs low-latency encrypted computation against your data, processing the actual values without ever decrypting them.

Step 4: Encrypted Result Returned

The result comes back still in encrypted form.

Step 5: Decryption at Destination

The customer’s private key decrypts the result. The answer lands in plaintext on their screen.

The LLM processed your query. The LLM never read your data. Those two things are simultaneously true. That’s the architecture.

What It Unlocks

The conversation about AI and sensitive data has been a compliance conversation:

  • Can we satisfy the regulator?

  • Can we pass the legal review?

  • Can we get the CISO to sign off?

Those are threshold questions. The floor, not the ceiling.

When the guarantee is structural rather than contractual—not our vendor promises not to look, but our vendor provably cannot look—the conversation moves to what actually matters:

New Possibilities

  • Cross-organizational analytics that used to require months of legal negotiation can now run in minutes.

  • Regulated-industry deployments stuck in legal review now have a clean answer to “where does the data go?”

  • Multi-party collaborations where the value is in the combination but neither side will expose their data become practical.

Those aren’t edge cases.

For the customers we’re building for, those are the most valuable workflows in their business. They’ve been blocked not by technical limits, but by a trust architecture that wasn’t good enough.

We built Nera ChatApp to never see your data because the only way to close that trust gap is to make the guarantee structural. Not a promise. Not a policy. An architectural fact.


Nera ChatApp

chatapp.nera.systems

Questions or use cases:

info@nera.systems