Privacy-Preserving AI: Shipping AI When You Can’t See the Data

Co-written with Kaouther Ouenniche

Every product team feels the same pressure right now: Ship AI, fast, everywhere. For most teams, that means plugging user data into a model and iterating.

But if your product is built around sensitive data—health records, financial information, identity credentials—the need for data privacy adds pressure in the opposite direction.

At Dashlane, we live at the extreme end of that tension. Our entire product promise is that only the user can see their own data: Not hackers, not Dashlane, and not our cloud provider. We do this using zero-knowledge architecture.

Applying AI to a security product that processes credentials and identity data forced us to rethink everything, including how we train and evaluate our models, where inference runs, and how we debug without ever seeing the inputs.

This post shares what we've learned across two concrete use cases and a playbook for teams facing similar constraints who want to be private by design.

The AI product cycle is a continuous loop: You collect signals, train, evaluate, deploy, and keep learning from production. That loop is what makes AI products improve over time. In a normal setup, the loop closes naturally.

When your product is built around not seeing user data, two parts of that cycle become hard:

In addition, there's a gap that most teams overlook. Standard practice is to encrypt data in transit and at rest. However, the moment your model runs inference, the data has to be decrypted in memory. At that point, the cloud environment can see it. Your ops tooling can see it. It can appear in logs during a debugging session.

Our first use case is our AI anti-phishing detection model. The goal was to protect Dashlane customers from entering their credentials on fake pages, in real time, without collecting or inspecting user browsing data.

After all, with attackers using AI to build phishing sites at scale, static URL lists are no longer sufficient.

To accomplish this, we needed to address three questions:

When teams can't access customer data for training, three approaches come up repeatedly:

None of these is wrong, and none is sufficient on its own. What works is combining them, with a clear understanding of what each source contributes.

To train our phishing model, we used internal crowdsourcing as our primary improvement loop because it's the fastest way to iterate safely. Then, we leveraged synthetic augmentation not as a foundation but as a way to stress the model and cover gaps. We tapped into public datasets and were mindful of copyrights and licensing. Finally, we used privacy-safe telemetry—aggregate counts and metrics, not raw samples—to detect drift.

The central question for a training set is not "How much data do we have?" It's "Does the data reflect the full range of real behaviors our users will bring?" This includes different languages, contexts, and edge cases. Coverage is the key.

When you can't access user data, the first instinct is to find a larger, smarter model that needs less signal to perform. Our experience is the opposite: Start with the smallest model that can live inside your privacy boundary and only escalate if you genuinely can't get the signal you need.

A smaller model needs less data to reach useful performance, which matters when data is your constraint. It iterates faster and costs less. When something breaks, you can identify which feature caused it, rather than debugging a black box. Governance is easier because you can explain what the model is doing. And on-device deployment becomes realistic, which is the best privacy outcome you can get.

For structured data problems, good feature engineering plus a well-trained, lightweight model will regularly outperform a large model fed raw inputs. You're guiding the AI toward the signal instead of hoping it finds the pattern.

For our anti-phishing model, we deliberately avoided the  approach in which a large model reads the full page and renders a verdict. Instead, we trained a model based on around 80 indicators (features) extracted from page structure. It's stable, cheap to compute, and explainable. And because the model is small and the features are lightweight, it runs entirely on-device. No data leaves the device, and there’s no cloud surface to attack. We get maximum privacy by construction.

Our second use case is more complex.

For our business customers, we generate audit logs of credential activity across the organization — rich, sensitive signals about who accessed what, when, and from where. This is exactly the kind of data an AI copilot could turn into actionable security insights.

However, we had two important challenges:

There were no obvious solutions when we embarked on that journey, so we intentionally took an incremental approach, shipping value at each step rather than waiting for a complete solution.

We started with static dashboards in our admin console, then added SIEM integrations, letting customers pipe logs into security platforms they already trusted. We implemented an MCP connector so customers can connect their own AI agent, operating only within data boundaries they control. Finally, we introduced AI in the product itself.

Because the data volume requires cloud-scale compute, our solution was to run a self-hosted model inside AWS EC2 Attested Instances, which are hardware-isolated environments where the data can be decrypted, processed, and re-encrypted entirely within the boundary. Neither Dashlane nor AWS can access plaintext data at any point during processing. No query content, response data, or customer data of any kind is transmitted to a third-party AI provider.

Encryption at rest and in transit is standard practice. Confidential computing closes the remaining gap: Processing encrypted data in use. In that case, at the moment inference runs.

The core idea is to run your computation inside a hardware-protected enclave—a sealed environment where data is processed in isolation. The cloud provider operates the hardware around it but can’t see inside. Neither can your own team.

The data flow works as follows. Your data stays encrypted at rest and enters the process encrypted. Before any data is processed, the EC2 Attested Instance generates a cryptographic attestation, which means it proves to a key management system that it’s the expected environment, running the expected code, on verified hardware. Only after that verification does the decryption key get released, directly into the instance.

Once inside the boundary, when an admin submits a query, the following steps happen entirely within the enclave:

This is the architecture behind Omnix AI Advisor. If you want more technical detail, our earlier post on the architecture behind AI Advisor covers NitroTPM attestation, the enclave setup, and how we integrated Mistral AI on AWS.

These two use cases reflect a broader principle: Privacy constraints are an input to design, not a review gate at the end.

The most common failure pattern is addressing privacy too late, treating it as a legal checkpoint after the system already exists. By that point, you usually need to rewrite everything or abandon ideas that could have worked if the constraint had been clear from day one.

What works is treating privacy as a first-class requirement alongside cost, performance, and reliability. At Dashlane, we formalized this with two explicit tiers. Tier one is non-negotiable: Privacy and reliability. A system that’s private but unstable is not shippable. Tier two is where optimization happens: Accuracy, latency, cost, explainability. These matter, but they’re goals pursued within the boundary set by tier one.

That split sounds simple. In practice, it changes every prioritization conversation because everyone now agrees on what’s fixed and what’s allowed to flex.

We made privacy a first-class requirement by codifying it at every level. It starts with our privacy stance, which is how we think about customer data. That stance is grounded in our zero-knowledge architecture, the technical guarantee that only the user can see their own data.

From there, we translated it into our privacy policy, which is available for our customers on our website, and an acceptable use policy that tells every team, concretely, what they can and can’t do with data.

Lastly, we wrote a dedicated AI policy to guide how teams can use AI internally and in the product.

That means that when a team comes with an AI idea, the boundaries are already defined. The conversation starts from a shared foundation, not from scratch.

Privacy-preserving AI is not a future aspiration. We've been shipping it in production, learning from it, and building on it. We hope more products will follow our inspiration and build products that are both secure by design and private by design.

This blog post is inspired from a series of talks Kaouther—a senior machine learning engineer at Dashlane—and I have been giving the past six months. Get more details, as well as additional references, by checking out our deck.