Why we never train on customer data
It's a one-line promise on our homepage and a clause in our contracts. Here's the architecture behind it: zero data retention, redaction before inference, per-tenant isolation, regional residency, and what 'opt-in improvement' actually means.
Almost every enterprise security review we go through has some version of the same question: Will our customers' conversations be used to train your models?
The answer is no. It has always been no. But "trust us" isn't an answer a CISO at an insurer or a hospital network should accept, and I wouldn't accept it either. So this post explains what the commitment actually says, where it's written down, and the architecture that makes it enforceable rather than aspirational.
What the commitment says
Our AI Addendum contains this sentence:
Pazau does not use Customer Data to train or fine-tune foundation models.
There are three things worth noticing about it.
It's contractual. It isn't in a blog post or a FAQ that can change quietly. It's in the paper you sign, alongside our Data Processing Addendum. If we breached it, you'd have a contract claim.
It covers Pazau and our providers. We don't train on your data, and neither do the model providers we use. They're bound by zero data retention terms (more below).
It's hard for us to change. Internally, any change to AI-related contract language requires sign-off from both me and our Head of AI, Dr. Mei Tanaka. Our legal team can't negotiate it away on a deal, and sales can't promise around it. Customers get the same commitment whether they're on Growth or a seven-figure enterprise contract.
Why we made it a hard line
It would be commercially convenient to pool customer conversations. More data generally means better models, and we handle more than 140 million conversations a year.
We said no for three reasons.
- Support conversations are some of the most sensitive data a company has. They contain health details, payment disputes, addresses, account numbers, and people at their most frustrated. Our customers are airlines, insurers, banks and hospital networks. Their data shouldn't improve their competitor's agent.
- It doesn't hold up under regulation. GDPR purpose limitation, HIPAA's minimum necessary standard, and banking secrecy rules all push against repurposing customer data. A blanket training right would be a liability for every regulated customer we have.
- We don't need it. Pazau Agent's quality comes mostly from structure: Procedures, Actions with enforced limits, and evaluation. Foundation model capability comes from the providers, who train on data that isn't yours.
The architecture
A contract clause is only as good as the systems that enforce it. Here's how data flows when a customer sends a message to a Pazau-powered agent.
1. Redaction before inference
Before any text reaches a model, Pazau Guard scans it and replaces sensitive entities with typed placeholders:
Customer: "My card 4417 1234 5678 9012 was charged twice, DOB 03/14/1987"
To model: "My card [CARD_1] was charged twice, DOB [DOB_1]"
Card numbers, bank accounts, government IDs, dates of birth, health information and credentials are redacted by default. Customers can add their own entity types, such as policy numbers or member IDs. When an Action needs the real value (for example, to look up a card dispute), the platform substitutes it at execution time, inside your tenant, outside the model call. The model reasons about [CARD_1] without ever seeing the digits.
2. Zero data retention with model providers
Every foundation model provider we use is contracted under zero data retention (ZDR) terms. Prompts and completions are processed in memory to serve the request and aren't stored, logged for training, or reviewed by the provider's staff. The providers themselves are listed on our sub-processor page, with their region and purpose. We give 30 days' notice before adding a new one, and you have the right to object.
3. Tenant isolation
Your data is logically isolated from every other customer's, at every layer that holds it:
| Layer | Isolation |
|---|---|
| Conversation storage | Per-tenant encryption keys (AES-256), managed in a KMS; customer-managed keys on Enterprise |
| Knowledge and retrieval | Per-tenant retrieval indices, never shared or merged |
| Procedures and Actions | Scoped to the tenant; Action credentials stored in a per-tenant secrets vault |
| Traces | Written to a per-tenant, append-only store with your retention schedule |
| Model calls | Stateless; no cross-tenant context, cache or memory |
There's no shared "global" index where a hint from one customer's conversation could surface in another's. When we say your agent learns your business, we mean it reads your knowledge base and follows your Procedures. It doesn't absorb other customers' data.
4. Regional residency
US customers are processed and stored in the US. EU customers are contracted with Pazau Ireland Limited and processed and stored in the EU, with Dublin as the primary region and Frankfurt for failover. Model inference for EU tenants runs on EU-hosted endpoints. Data doesn't leave the region to be "improved" somewhere else, because it isn't improved anywhere.
5. Traces
Every AI decision produces a Trace: which Procedure ran, what data the agent saw (post-redaction), which Actions it requested and whether they executed. Traces are immutable and exportable. They're how your QA team audits the agent, and they're also how you can verify what data went where.
What "opt-in improvement" means
Our contracts allow one narrow exception, and it's worth being precise about it.
Some customers want their agent to get better from their own history, for example by tuning a classifier on their past conversations so it routes their specific intents more accurately. We support that, under strict conditions:
- It's opt-in, per customer, in writing. It's off by default.
- It's per-tenant. Anything produced from your data (a tuned classifier, an embedding adapter, an evaluation set) lives in your tenant and is used only for you.
- It never touches a foundation model. We don't fine-tune a shared base model on your data, and we don't send your data to a provider for training.
- You can revoke it. If you turn it off, the tenant-specific artifacts are deleted within 30 days.
Many of our largest customers never enable it, and their agents perform very well. Structure, retrieval and evaluation do most of the work.
What we still use
To be complete: we do use some data about the service to run the service.
- Operational metadata such as latency, error rates, token counts and Action success rates, with no conversation content. This is how we keep the platform healthy.
- Aggregated, anonymized benchmarks, only from customers who opt in to benchmarking. These power published figures like our resolution benchmark. They contain counts and rates, not text.
- Synthetic and licensed data for our own evaluation suites, plus conversations our own support team handles on Pazau for Pazau.
None of this is used to train foundation models, and none of it contains your customers' words.
Questions to ask any AI vendor
Whether or not you choose Pazau, here's the checklist I'd use:
- Is "no training on our data" in the contract, or only in marketing?
- Does it cover your model providers? Are they under ZDR?
- Is sensitive data redacted before inference, or after?
- Are retrieval indices and caches isolated per tenant?
- Can you name every sub-processor and its region?
- If you offer improvement on our data, is it opt-in, per-tenant, and revocable?
- Can we export an audit trail of every AI decision?
If a vendor can't answer all seven in writing, keep asking.
Our answers are on the Trust Center, with our certifications (SOC 2 Type II, ISO 27001, ISO 27701, ISO 42001, HIPAA), our AI Addendum, and our sub-processor list. If your security team wants to go deeper, write to security@pazau.com. We'll get on a call.