What to put on an AI trust page (and what to leave off)
Security pages grew up answering questions about encryption and uptime. Customers now ask a different set: which AI tools do you use, does our data go into them, and who decided that was acceptable. A short public page can answer most of them before the questionnaire is sent.
- By
- GhostAudit
- Published
- Last reviewed
- Reading time
- 6 min read
Key points
- A trust page is a set of public commitments. Put on it only what you can evidence today and are prepared to keep true.
- Seven things belong on it: governance, approved tools, customer data, monitoring and controls, self-assessments, documents on request, and a contact.
- The customer-data answers carry the most weight and the most risk. Have the accountable person confirm each one, and date it.
- Leave off certifications you do not hold, internal risk ratings, anything about individual employees, and adjectives.
- Publish as a dated version with a change log. A page that silently changes is worth less than one that shows its history.
Why a page, and why now
A company that sells to other companies is assessed by them. The instruments used for that assessment have added artificial intelligence: the Cloud Security Alliance publishes an AI Controls Matrix with a companion questionnaire, and the Shared Assessments SIG questionnaire is widely used for third-party risk. The questions underneath are few and they repeat. We describe them in how to answer the AI questions in customer security questionnaires.
When the same handful of questions arrives from every customer, answering them once, in public, is cheaper for you and faster for them. A reviewer who finds a clear page often shortens the questionnaire or skips its AI section. A reviewer who finds nothing assumes the worst and asks everything.
A trust page is not marketing. It is closer to a signed statement. Everything on it can be quoted back to you in a contract negotiation, so the test for every sentence is the same: can we show this today, and will we keep it true?
The seven things that belong on it
1. How you govern AI
State, plainly, whether you have an AI policy, when it was approved, how often it is reviewed and who is accountable. Give a role rather than a person's name: "Head of IT and Security" survives a resignation.
A good line reads: "AI acceptable use policy: in place, approved 10 October 2026, reviewed once a year." A weak one reads: "We take a responsible approach to AI." The first can be checked. The second cannot, and reviewers have learned to read it as "no policy".
If you keep an inventory of AI systems, say so. Both the NIST AI Risk Management Framework and ISO/IEC 42001 treat knowing what you run as the starting point, and so do customers.
2. The AI tools you have approved
List them by name, with one line on what each is used for. This is the single most useful section for a reviewer, because it turns "do you use AI?" into something specific they can assess against their own list of acceptable vendors.
Say what the list means: "Tools that have not been approved are not permitted for company work." If you cannot yet say that, say what is true, for example that unapproved tools are being identified and reviewed.
Do not list every tool an employee has ever opened. The page states your policy, not your telemetry.
3. What happens to customer data
This is the section customers read first. Answer five questions directly:
- Is customer data entered into AI tools at all?
- If so, into which tools?
- Under what contractual terms are those tools held?
- Is customer data used to train AI models?
- Does a person review AI output before it reaches a customer?
Each answer is a commitment. "No. Our agreements with these vendors exclude training on our data" is a strong statement, and it had better be true of the plan you actually hold. The terms of an AI tool differ by plan: a personal account and an enterprise workspace of the same product can have opposite positions on training. Check the vendor's terms for your plan before you write the sentence. Our vendor fact pages show what each vendor states, per plan, with the source.
Because these are commitments, have the accountable person confirm each one and show the date: "Confirmed by the workspace owner on 3 October 2026." It tells the reader that somebody stood behind the answer on a particular day.
4. Monitoring and controls
Say how you know the policy is followed. If you monitor which AI tools are used, say what the monitoring records and what it does not. Customers care about this for two reasons that pull in opposite directions: they want to know you would notice an employee pasting their contract into a chatbot, and they do not want their own correspondence with your staff captured by a surveillance tool.
A statement that satisfies both: "We monitor which AI tools are used on company devices, never what is typed into them." Add the controls that exist: whether prohibited tools are blocked, whether employees are warned before using an unapproved one, how long usage records are kept.
5. Frameworks you have assessed against
If you have assessed your AI use against a framework, list the framework and the date. Call it what it is. A self-assessment is a self-assessment: "These are self-assessments carried out by us. They are not certifications or independent audits."
That sentence costs nothing and protects you. The United States Federal Trade Commission has warned companies to keep their AI claims in check, and an overstated compliance claim on a public page is the easiest kind to find.
6. Documents available on request
Some evidence should reach a customer and not the whole internet: the policy itself, an inventory report, an assessment summary. List what exists and offer it on request. Ask who is asking and why, approve each request, and mark the copy you send with the recipient's name.
Listing a document you have not written is worse than listing none.
7. A contact, a date and a change log
Give an address a person reads. Show when the page was last published. Keep a short log of what changed: "Added Claude to approved AI tools. Updated the answer on which tools may process customer data."
The change log is what turns a page into a record. It shows the page is maintained, and it means a customer who relied on last quarter's version can see exactly what moved.
What to leave off
Certifications you do not hold. Not "working towards", not "aligned with" beside a logo. If you hold a certificate, state its scope and offer it. If you do not, the self-assessment line above is the honest alternative.
Internal risk ratings. That you rate a tool "high risk" internally is useful to you and alarming, without context, to everyone else. Publish the decision (approved, and for what), not the working.
Anything about individual employees. No names of system owners, no usage figures per person or per team. A trust page is about the company's commitments.
Statements about the future. "We will never" is a promise your successors must keep. "We do not" is a fact you can evidence today.
Adjectives. "Robust", "rigorous", "state of the art" and "industry-leading" carry no information. A reviewer skims past them looking for a date, a name or a number.
Keeping it true
A trust page fails in one of two ways. It is published once and rots, or it is wired to live data and changes without anyone deciding that it should.
The remedy for both is the same: publish deliberately, as a version. Draft changes are not public. When the facts behind the page change (a new tool is approved, the policy is re-approved, an assessment is completed) someone looks at what would change on the page and publishes it. The published version carries a number and a date.
Review the page whenever you approve a new AI tool, change a vendor plan, or re-approve the policy, and at least once a quarter. Put the review in the same calendar as the policy review.
Then use it. Link it from your security page and from the footer of your site. Send it with the first reply to a security questionnaire. When a customer asks a question it does not answer, consider whether the answer belongs on the page.
How GhostAudit helps
The AI trust center in GhostAudit publishes a page with the sections described here. The approved tools, policy dates and assessment dates are read from your governance records at the moment you publish; the customer-data answers appear only after the workspace owner confirms each one; and documents are shared on request with the recipient's name on every page.
You can read a complete example, for a fictional company, at the trust center of Demo Corporation.
Sources
- Cloud Security Alliance: AI Controls Matrixcloudsecurityalliance.org
- Shared Assessments: Standardized Information Gathering (SIG) questionnairesharedassessments.org
- NIST AI Risk Management Frameworknist.gov
- ISO/IEC 42001:2023, AI management systems (ISO)iso.org
- Federal Trade Commission: Keep your AI claims in checkftc.gov
This guide is for orientation and is not legal advice. It was last reviewed on 13 November 2026; laws and guidance change, so check the official texts linked above. Spotted something out of date? Tell us.