Turn architecture choices into
a document people can review.
Answer structured questions about data privacy, retention, model providers, permissions, guardrails, and auditability. Generate a Trust Spec document that security, legal, and enterprise customers can actually review.
Open items are flagged automatically so nothing gets quietly skipped. No account is required, and nothing is sent to Dwayo unless you choose to save, export, or request a review.
01 System overview
02 Data & privacy
03 Providers & models
04 Permissions & access
05 Guardrails
06 Auditability & monitoring
What is an
AI Trust Spec?
A Trust Spec is a single document that states, in plain terms, how an AI system handles the questions that security teams, legal counsel, procurement, and enterprise customers consistently ask: what data it processes, where that data lives, which model providers it uses, who can access it, what guardrails exist, and how its behavior can be audited and rolled back.
Most teams can answer these questions individually — they're just rarely written down in one place, which means every reviewer asks them separately, and the answers can drift between code, prompts, and whatever the engineer who built it remembers.
Why these decisions
need to be written down.
Enterprise deals stall in security review when basic questions about data handling and model providers can't be answered quickly. Internal launches get delayed when legal and engineering discover they assumed different retention periods. Incidents take longer to resolve when nobody can say quickly whether rollback is even possible.
A Trust Spec doesn't prevent these problems by itself — but it surfaces them early, while they're still a form field to fill in rather than a blocked deal or a live incident.
What each section
of the spec covers.
What categories of data the system processes, where that data resides, how long it's retained, and whether it's shared beyond the model provider.
Which model providers are in use, whether training on your data has been explicitly opted out, and whether a fallback provider exists if the primary one is unavailable.
Who can reach the system, whether it can write to external systems, and whether high-impact actions require a human in the loop.
Content filtering, prompt injection mitigations, and the approach taken to reduce hallucinated or unsupported outputs.
Whether inputs and outputs are logged, whether outputs are sampled for human review, and whether a rollback path exists for a bad model or prompt change.
Whether a named contact and process exist for responding when the system misbehaves — a question reviewers ask more often than teams expect.
How to use the
generated spec.
- Complete every field with the actual current state of the system, not the intended future state.
- Mark anything uncertain as "unknown" rather than guessing — open items are more useful than false confidence.
- Review the open-items list with the people who own each decision: engineering, security, legal, and the product owner.
- Resolve high-risk open items before the system reaches production or an enterprise security review.
- Store the spec alongside the system's other documentation and version it with meaningful changes.
- Revisit the spec when providers, data handling, permissions, or guardrails change.
What this generator does not do: it doesn't verify that the implementation matches the answers given, and it isn't a substitute for a security, privacy, or legal review appropriate to your system's risk and regulatory exposure.
When to create
a Trust Spec.
- Before an enterprise customer's security review.
- Before launching an AI feature that touches customer or employee data.
- When evaluating a third-party AI vendor or tool.
- During an internal architecture or governance review.
- After adding a new model provider or data source.
- Before expanding access from internal users to customers or the public.
Before you send this
to security.
What is an AI Trust Spec?
A Trust Spec is a single reviewable document that states how an AI system handles data privacy, retention, model providers, permissions, guardrails, and auditability. It replaces assumptions scattered across code, prompts, tickets, and chat threads with one explicit record stakeholders can review.
Who typically reviews a Trust Spec?
Security, legal, procurement, and enterprise customers commonly ask for this information before approving an AI feature or vendor. Engineering and product teams also use it internally to confirm a shared understanding before launch — see our Trust & Safety page.
Does completing this generator make my AI system compliant?
No. It documents the choices you've made so far and flags items left undefined. It is not a certification, audit, or legal compliance determination — those require a qualified review against the specific regulations and contracts that apply to your system.
What happens to items I mark as "unknown" or "no"?
The generator lists them separately as open items. Marking something unknown is more useful than guessing — it shows reviewers exactly what still needs an answer before the spec is complete.
Can I use this for a vendor's AI product, not just something we built?
Yes. Procurement and security teams often use the same fields to evaluate a third-party AI tool — ask the vendor to complete the fields, or fill them in based on their documentation and contract terms.
Does Dwayo see what I enter?
The document is generated in your browser. Your answers are only shared with Dwayo if you choose to save a result, export it through the lead-capture flow, or request a review. See our privacy policy.
A spec with open items is more useful
than one that hides them.
Resolve the highest-risk open items first. If data handling, provider contracts, or guardrail design need deeper review, a Dwayo engineer can help close the gaps before this spec goes to a customer or auditor.