By Mehdi HassanWhat should an AI company's trust page include?
An AI company's trust page should include six things: a plain answer on training use, data retention and deletion, model providers, a subprocessor list, security certifications and their status, and how customers control their data. Add a last-updated date, a security contact and links to the full legal documents. Every statement must be true today.
Buyers are skeptical about AI by default, and data handling is usually their first question. Our AI startup website design playbook argues the data answer belongs near the top of the homepage. This template gives you the full page that one-line answer links to.
Why does an AI trust center page matter more than a privacy policy?
An AI trust center page matters more in a sales cycle because it's written for buyers and security reviewers, while a privacy policy is written for legal compliance. Reviewers want direct answers to specific questions, such as "are prompts stored?", and a long legal document makes them hunt for each one.
Our 2026 research found consistent trust-center practice across SaaS and security companies: certifications above the fold, often a dedicated trust subdomain, a subprocessor list, and a page that's kept current. AI companies need all of that plus answers that general SaaS trust pages don't cover: training, prompts, outputs and model providers. For the general SaaS version, see our guide to trust center design.
Page | Written for | Answers |
|---|---|---|
Privacy policy | Regulators and legal | What personal data is collected and why |
Terms of service | Legal | Rights and obligations of both sides |
Trust page | Buyers and security reviewers | Training, retention, providers, security, controls |
DPA | Customer legal teams | Contractual data-processing commitments |
What is the AI trust page template, section by section?
The template has eight sections, in the order reviewers usually ask. Fill in each bracketed field with what's true for your product today. If a section doesn't apply, say so in one line rather than deleting it, because a missing section looks like an avoided question.
1. Training on customer data
"We [do / do not] use customer data, including prompts, files and outputs, to train or fine-tune models. [If yes: what is used, for which plans, and how to opt out.]"
2. Data retention and deletion
"We keep [prompts / files / outputs / logs] for [period]. Customers can delete [what] by [how]. Deleted data is removed from backups within [period]."
3. Model providers
"We use models from [provider names]. Data sent to them is [covered by zero-retention terms / retained for period / not used for training under our agreement]. [Self-hosted models: name them.]"
4. Subprocessors
A table: subprocessor name, what it does, data it processes, location. Add "We notify customers of new subprocessors by [method] [time] in advance."
5. Data location
"Customer data is stored in [regions]. [Region selection is available on plan.]"
6. Security certifications
"We hold a SOC 2 [Type I / Type II] report covering [period], available under NDA [link]." Or: "We are [preparing for / undergoing] a SOC 2 [type] audit, expected [stage]."
7. Customer controls
Admin settings, SSO, role-based access, audit logs, data export, opt-outs. List only what exists.
8. Contact and updates
"Last updated [date]. Security questions: [email]. Report a vulnerability: [link or email]."
How do you write the "we don't train on your data" section?
Write the "we don't train on your data" section as one direct sentence, then define exactly what "your data" covers and any exceptions. Buyers read this line closely, so vague phrasing such as "we respect your data" reads as a dodge. Be precise about prompts, uploaded files, outputs, feedback and usage logs.
Common gaps to close:
- Feedback signals. If thumbs-up or corrections are used to improve models, say so.
- Free vs paid plans. If training rules differ by plan, show a small table.
- Model providers. Your policy only holds if your providers' terms match it. Say what their terms are.
- Aggregated metrics. If you use anonymized usage statistics, describe them so they aren't mistaken for training.
Hypothetical example: a filled-in training section
Hypothetical example for an AI meeting-notes startup:
"We do not use your recordings, transcripts, notes or prompts to train or fine-tune any model, on any plan. Transcription and summarization run through [provider] under an agreement that prevents them from training on your data. If you rate a summary, we store the rating to measure quality, but not the content it refers to. Last updated [date]."
Every claim here would need to be true for the real product. Replace the bracketed fields and remove any sentence you can't stand behind.
How should an AI trust page list model providers and subprocessors?
List model providers and subprocessors in a table with four columns: name, purpose, data processed and location. Keep it on the trust page itself, not in a PDF, and say how customers are told about changes. Enterprise buyers usually compare this list against their own approved-vendor list.
Subprocessor | Purpose | Data processed | Location |
|---|---|---|---|
[Cloud host] | Application hosting and storage | All customer data | [Region] |
[Model provider] | Model inference | Prompts and outputs | [Region] |
[Email service] | Transactional email | Names, email addresses | [Region] |
[Analytics tool] | Product usage analytics | Usage events, no content | [Region] |
Treat this as a template, not a recommendation of specific vendors. HR and people-data products face extra scrutiny here, which our guide to HR software trust pages covers in detail.
Where should the trust page live and how do you keep it current?
The trust page should live at a short, obvious URL, such as /trust or a trust subdomain, and be linked from the homepage, pricing page, footer and any security questionnaire you send. Keep it current by assigning an owner, adding a visible last-updated date, and reviewing it whenever a provider, subprocessor or certification changes.
Build it in your CMS rather than as a hard-coded page, so the person who owns compliance can update it without a developer. For design patterns from security companies that do this well, see our cybersecurity website examples. And plan where it fits in your sitemap with our AI startup website pages checklist.
