Secure AI assistant claims: what should buyers ask?
Last reviewed May 24, 2026
Secure AI assistant claims usually combine product security, data handling, model use, identity controls, and AI-specific risk in one sentence. This guide turns those claims into evidence needed and buyer questions for vendor evaluation.
Evidence buyers verify
- The exact secure AI assistant claim and the product plan or feature it applies to.
- A data-flow map for prompts, files, outputs, logs, connectors, support access, and admin exports.
- Identity, access, and role-control evidence for users, admins, apps, and integrations.
Opens the checker for this claim type. Paste your vendor's exact wording there. Evidence questions only — not a blacklist or fraud detector. Not sure what a result looks like? See a sample receipt.
Sources this guide draws from
- · January 26, 2023
Source for AI risk-management context and trustworthy AI characteristics.
- · Excerpt from NIST AI RMF 1.0 (2023)
Source for secure and resilient, privacy-enhanced, accountable, transparent, and human-oversight evidence questions.
- · Accessed May 24, 2026
Public company source for business-data, encryption, access-management, retention, and training-boundary security wording; used as claim wording evidence, not independent validation.
- · Updated May 21, 2026
Public company source for enterprise-grade privacy and security controls claim wording; not a third-party security audit.
Public claims with documented evidence gaps
"Enterprise-grade privacy and security controls"
Compliance / Safety- Source and date
- OpenAI Help Center: What is ChatGPT Enterprise? · Updated May 21, 2026
- Evidence signal
- Security-grade wording without the specific controls, product scope, or admin boundary in the claim itself.
- Evidence gap
- A buyer needs the exact controls, supported plan, admin scope, identity integration, logging, data retention, and excluded surfaces.
- Buyer question
- For the enterprise-grade privacy and security controls claim, which controls apply to our plan, data types, and assistant features?
"data always remains confidential, secure, and entirely owned by you"
Compliance / Safety- Source and date
- OpenAI business data page · Accessed May 24, 2026
- Evidence signal
- Broad data-control wording that needs product, retention, training, and support-access boundaries.
- Evidence gap
- A buyer needs the data categories covered, training-use default, retention settings, support access, subprocessors, and customer responsibility limits.
- Buyer question
- For the data remains confidential and owned by you claim, what data categories and product surfaces are covered or excluded?
"encrypted at rest and in transit"
Compliance / Safety- Source and date
- OpenAI business data page · Accessed May 24, 2026
- Evidence signal
- Encryption wording that may not explain key control, logs, attachments, integrations, or admin-export paths.
- Evidence gap
- A buyer needs encryption method, key management option, covered storage locations, integration path, audit logging, and exception handling.
- Buyer question
- For the encrypted at rest and in transit claim, which data stores, logs, files, and integrations are included?
"We don't train our models on your organization's data by default"
Compliance / Safety- Source and date
- OpenAI business data page · Accessed May 24, 2026
- Evidence signal
- Training-boundary claim qualified by 'by default', which means opt-in and configuration choices can change it. The claim also depends on product plan, API usage mode, fine-tuning, and subprocessor practices.
- Evidence gap
- A buyer needs the exact product surfaces and plans covered by the default no-training commitment, what opt-in or configuration options change that boundary, which subprocessors have access to inputs and outputs, and what the DPA says about training scope for the specific plan.
- Buyer question
- For the no-training-by-default claim, which product surfaces, plans, API configurations, fine-tuning workflows, and subprocessors are covered or excluded from the training boundary?
Match each claim pattern to the evidence buyers need
| Claim pattern | Evidence needed | Buyer question |
|---|---|---|
| Secure AI assistant or enterprise-grade AI security | Security architecture, identity controls, role model, admin settings, audit logs, incident process, and product-plan scope. | Which assistant features can access sensitive data, and which controls restrict that access? |
| Private AI, confidential data, or customer-owned data | Training-use boundary, zero-retention option, deletion controls, support-access process, DPA scope, subprocessors, and export paths. | Is our prompt, file, output, log, or feedback data used for model training by default, and which retention or DPA terms apply? |
| Encrypted, protected, or secure by design | Encryption at rest and in transit, key management, tenant isolation, integration security, and exception documentation. | Where does encryption stop: browser, API, storage, logs, connectors, analytics, or support tooling? |
| AI-specific secure or resilient system claim | Threat model for prompt injection, data leakage, tool access, model behavior, abuse handling, monitoring, and degradation path. | What AI-specific risks were tested, and what happens when the assistant receives untrusted instructions or sensitive data? |
| AI data residency, audit log, or subprocessor disclosure claim | Hosting region, data movement path, log coverage, subprocessor list, cross-border transfer basis, and customer configuration boundary. | Which assistant data, logs, files, and connector events stay in the stated region or appear in the audit trail? |
| No training on your data, zero data retention, or DPA-backed data claim | Training opt-out scope per product and plan, data-retention settings and defaults, DPA availability and terms, subprocessor list with data-use roles, and what changes if a connected app, API access, or fine-tuning is enabled. | What does the vendor's DPA say about training, retention, subprocessors, and how each of those obligations changes if we use an API key, connect a third-party app, or enable a fine-tuning workflow? |
Evidence to request
- The exact secure AI assistant claim and the product plan or feature it applies to.
- A data-flow map for prompts, files, outputs, logs, connectors, support access, and admin exports.
- Identity, access, and role-control evidence for users, admins, apps, and integrations.
- Retention, deletion, data-residency, DPA, subprocessor, and model-training boundaries in writing.
- AI-specific risk controls for prompt injection, data leakage, tool actions, monitoring, and human escalation.
- For training-boundary and zero-retention claims: the DPA text, subprocessor list, and which product surfaces, plans, and connected-app configurations are covered or excluded.
Questions to put in front of the vendor
- For this secure AI assistant claim, which data categories are protected and which are outside the stated scope?
- What evidence shows the assistant is secure and resilient for our intended workflow, not only for the vendor's general platform?
- Can admins control access, connectors, retention, export, and model-training settings for this deployment?
- What logs and audit events would help investigate an incorrect answer, unauthorized access, or data exposure concern?
- What DPA, subprocessor, and data-residency evidence supports the assistant claim rather than the vendor's general platform claim?
- Which wording boundary should replace the broad security claim if only selected controls or plans are covered?
Wording boundaries to compare against
- Includes defined enterprise controls for identity, retention, encryption, and audit logging on specified plans.
- Business data is not used for model training by default for named products and configurations.
- Encrypts specified data stores and transfer paths; key-management options and exclusions are documented separately.
- Designed to manage AI-specific risks such as untrusted inputs, tool access, and data leakage through documented controls.
Have your vendor's exact claim wording ready?
Check a secure AI assistant claim How the evidence method works