Describe each AI feature by what it does, which data it touches, which models or providers it uses, and what controls apply. Avoid absolute words like safe, unbiased, or hallucination-free. State limits plainly and link evidence. If a control is not in place, say so or leave the claim out.
Start with a plain inventory
Buyers ask the same handful of questions. Answer them first, in a short block per feature.
| Question | What to write |
|---|---|
| What does it do? | One sentence on the task |
| What data does it see? | Categories, and whether customer data is included |
| Is customer data used to train models? | Yes or no, and where it is documented |
| Which providers or models are involved? | Names you can disclose, or the category |
| Who can turn it on or off? | Admin setting, default state |
| What human review exists? | Where a person checks the output |
Keep every answer to what you can show today.
Say what SBOM guidance does and does not cover
CISA's 2026 minimum elements note that AI software systems may have extra components not captured by the minimum elements, and mention what AI engineers call model cards or data cards as examples of useful additional data. The same document says it does not introduce extra elements for AI systems, and notes separate joint guidance with G7 partners on SBOM for AI, released in May 2026. If you describe an "AI bill of materials" on your page, be clear about which document or format you are following.
Words to avoid
- "Safe" or "secure by default" with no scope.
- "No hallucinations" or "always accurate."
- "Your data never leaves" unless you can prove every path, including logs and third-party providers.
- "Compliant" as a bare adjective.
Replace them with testable statements: "Customer content is not used to train provider models under our agreement with the provider," when that is true and documented, or "Outputs are drafts that a user reviews before sending."
Cover the controls people probe
- Access. Who can invoke the feature and with what permissions.
- Data handling. Retention of prompts and outputs, and where logs go.
- Third parties. Which providers process data, and whether they appear on your subprocessor list.
- Testing. Whether you test for prompt injection and misuse, and how often.
- Change. How you tell customers when a model or provider changes.
Where one of these is a gap, write a dated plan, not a promise.
Keep the page and the product in step
AI features change faster than most controls. Add the AI section to your review rhythm and tie it to release notes. If a feature is early access, label it that way. A clear "early access" label tells a reviewer what to expect and protects you from a claim that outruns the product.
Where Safeguard fits
Safeguard's policies, gates, and guardrails, MCP Guardrail, and agent identity capabilities help teams govern AI tools and agents inside their own development environment. Try a free scan at gold.safeguard.sh/scan.
Quick check
Do I need to name my AI model providers?
If your contracts allow it, naming them helps buyers. Otherwise describe the category and list them on a subprocessor page that customers can request.
Is an AI SBOM required on a trust page?
No. It is useful if you have one. Describe what it covers and which guidance you followed, and do not imply more than it contains.
Sources
Last reviewed: 19 October 2026.
