By Gary Cheung · 5-minute read
At a glance
- The risk: Vendor-level assurances can conceal different treatment of prompts, outputs, files, metadata, and connected-system data across products and configurations.
- The governance implication: Approval must be based on the exact service, account, features, data flows, and contract—not the provider’s brand or a generic security statement.
- The leadership takeaway: Do not approve consequential use until an accountable owner can evidence what data moves where, how long it remains, and who can stop the deployment if those conditions change.
The consequential decision is not simply whether an AI vendor is reputable. It is whether a specific deployment should be allowed to process a defined class of business information.
That distinction matters in regulated organizations. The same provider may offer consumer, enterprise, and API services with different training rules, retention periods, administrative controls, connected tools, and contractual protections. A statement that data is “not used for training” answers only one question; it does not establish where the data is stored, who can access it, how it is deleted, or what happens when a feature changes.
Leaders therefore need an approval record tied to the real deployment. These five checks turn vendor due diligence into a decision that can be defended later.
1. Separate Training, Retention, and Human Access
Training use, service retention, and human access are separate control questions. Treating “no training” as shorthand for privacy can create a false sense of assurance.
OpenAI states that business data is not used to train its models by default. Its API documentation separately describes abuse-monitoring retention and application-state retention, which vary by endpoint and feature. Anthropic likewise documents product-, feature-, and model-specific retention arrangements, including eligibility limits for zero-data-retention configurations.
The approval record should state which policy applies to the organization’s exact account and use case. It should also identify any opt-in, support-access, abuse-monitoring, legal, or safety exceptions.
Evidence to obtain: the applicable product terms, administrator settings, retention table, access model, and dated confirmation of any negotiated exception.
2. Map the Complete Data Path
Prompt text is only part of the exposure. An AI workflow may also transmit uploaded documents, retrieved records, conversation history, system instructions, user identifiers, telemetry, tool outputs, and data sent to connected applications.
Before approval, map each data class from collection to deletion. Include the AI provider, cloud hosting, subprocessors, plug-ins, retrieval stores, logging platforms, and any external tools the model can call. A secure model endpoint does not compensate for an ungoverned connector or a retained copy in an adjacent service.
This is where vendor review becomes a business decision rather than a questionnaire exercise: leaders must decide which information the use case genuinely requires and which data should never enter the workflow.
Evidence to obtain: a deployment-specific data-flow diagram, subprocessor list, data-location commitments, connector inventory, and approved input classification.
3. Test Retention, Deletion, and Logging
Published policies describe intended treatment. Governance needs evidence that the selected configuration behaves as expected.
Test the deployment with synthetic or non-sensitive data. Confirm what appears in user history, administrator consoles, audit logs, support tooling, files, vector stores, and connected systems. Exercise deletion and export functions, and record what is removed immediately, what remains for a defined period, and what is retained under an exception.
Do not promise “no logs” unless the organization can verify that claim across the full workflow. Logging may be necessary for security, investigations, or regulatory evidence; the control objective is purposeful, bounded, protected retention—not invisibility.
Evidence to obtain: test results, screenshots or system records, retention configurations, deletion behavior, and the owner responsible for periodic revalidation.
4. Read Assurance Evidence for Scope, Not Badges
SOC reports, certifications, penetration tests, and security questionnaires can be useful. They are not substitutes for understanding scope.
Check whether the evidence covers the service, infrastructure, region, subprocessors, and control period relevant to the proposed deployment. Review exceptions and remediation status. A certification attached to the provider does not automatically demonstrate that a newly released AI feature, external connector, or customer-managed configuration is controlled.
NIST describes its AI Risk Management Framework as voluntary guidance for incorporating trustworthiness considerations into the design, development, use, and evaluation of AI systems. That is a useful reminder: a framework can organize the review, but leaders still need evidence for the deployed system and its business context.
Evidence to obtain: current assurance reports, scope statements, exceptions, penetration-test coverage, incident-notification terms, and confirmation that the contracted service is included.
5. Assign Authority Before Go-Live
The final control is organizational. Someone must own the decision to rely on the service, and someone must have authority to challenge or stop it.
Define the business owner, data owner, technology owner, risk reviewer, and incident decision-maker. Set review triggers for material product changes, new models, new connectors, altered retention terms, subprocessor changes, or expansion into more sensitive decisions.
Approval should be conditional where evidence is incomplete. Conditions might restrict data classes, require human verification, limit the deployment to a controlled population, or require renewed review before a feature is enabled. If no one can enforce those conditions, the organization has not completed governance—it has documented an assumption.
Evidence to obtain: a named accountable owner, approval conditions, escalation route, stop authority, review triggers, and a dated reassessment point.
Leadership Questions
- Which exact product, account type, model, features, and connected services are we approving—and what business decision will depend on them?
- Can the accountable owner demonstrate the complete data path, retention behavior, contractual protections, and unresolved exceptions?
- Who has authority to restrict or stop the deployment when the vendor, configuration, or intended use changes?
Closing Thought
Vendor assurances are inputs to a decision, not the decision itself. Secure AI deployment begins when leaders can connect contractual promises and technical settings to a named owner, a defined use case, and an enforceable boundary.
Sources and Further Reading
- OpenAI — Enterprise privacy
- OpenAI — API data controls
- Anthropic — API and data retention
- NIST — AI Risk Management Framework
- Beyond1n0 — AI Risk Management Guide
- Beyond1n0 — AI Assurance: What Risk and Compliance Teams Should Actually Be Looking For
About Gary Cheung: Gary writes about AI governance, information risk, and accountable technology decisions. Discuss an AI governance challenge.
