Buying and budgeting
Read the data terms before the feature list
A vendor-review worksheet for data access, training use, retention, deletion, and incident responsibility.
Published · Collection dates are retrospective editorial dates.
An AI product can be easy to buy and difficult to unwind. By the time a team asks where transcripts are stored, the system may already be receiving customer information and sending it through several services.
Read the data terms while you still have choices. The goal is a clear description of what information enters the workflow, who can use it, how long it remains, and what happens when the arrangement changes.
This is an operational review guide. It does not determine which laws apply to your business or substitute for legal and security review where those are needed. Its purpose is to make those reviews specific enough to be useful.
Begin with a data inventory, not a badge
Write down the information the workflow will handle. Separate recordings, transcripts, summaries, account identifiers, attachments, system logs, and credentials. “Customer data” is too broad to reveal how each type is processed.
Then trace where each type goes. A voice service might produce audio, a transcription service might create text, a model service might receive a request, and an integration might write a summary into a CRM. That is a hypothetical flow, not an assumption about any particular supplier.
Ask the vendor to correct the map. Include services behind the main product, human support access, and any diagnostic tools that can receive content. A supplier list without the purpose of each processor is hard to evaluate.
NIST's generative AI profile identifies data privacy and component-integration risks. Your map turns those broad risk categories into questions about the actual proposed system.
Get answers at the data-type level
| Question | Evidence to request | Ambiguity to resolve |
|---|---|---|
| Who can access content? | Access roles and support-access process | Whether staff access is routine or exceptional |
| Is content used for training? | Applicable contract and product setting | Whether the answer covers every service in the flow |
| How long is it retained? | Schedule for each data type | Whether logs, backups, and derived records differ |
| Where is it processed? | Relevant hosting and processor information | Whether storage location and processing location differ |
| Can it be exported? | Sample export and field description | Whether you receive usable records or only raw transcripts |
| Can it be deleted? | Deletion process and documented limits | Whether deletion reaches copies and downstream systems |
| What happens in an incident? | Notice terms and named responsibilities | Who investigates, contains, and communicates |
Ask for the document or setting that governs your account. A general marketing answer may describe a different plan, region, or configuration. Record the version and date reviewed, and identify which terms control if two documents conflict.
Separate training from ordinary processing
“Not used for training” is a useful answer to one question. It does not answer whether the supplier stores the content, allows human support access, uses it for other service purposes, or sends it to another processor.
Likewise, a retention setting for transcripts may not cover recordings or operational logs. Ask separately. If a supplier says data is anonymized, ask what information remains, what process is used, and whether the contractual commitment applies to the derived material.
Avoid collecting information the workflow does not need. If the task is to request a callback, it may not require a detailed sensitive narrative. Data minimization begins with the questions the system asks, not just the place it stores the answers.
Make deletion a testable operation
Before rollout, use a safe test record and walk through export and deletion. Inspect what disappears, what remains, and how the process is documented. Ask what you must do in connected systems after the vendor deletes its own copy.
Clarify backup handling and legal retention exceptions with the appropriate reviewers. The right answer may involve a documented schedule rather than instant removal from every medium. You need an accurate commitment, not an absolute promise the service cannot support.
A separate healthcare example
For workflows involving electronic protected health information, HHS's cloud-computing guidance explains that a cloud service provider can be a business associate even when it cannot view encrypted information. It also discusses business associate agreements and shared responsibilities.
The practical question is therefore broader than whether the main vendor offers a BAA. Map the parties and data flows, identify which agreements and controls apply, and have the responsible healthcare privacy and security reviewers assess the arrangement. A signed agreement alone does not validate every configuration or use.
Keep this healthcare review separate from ordinary purchasing questions. Do not copy its terminology into another industry and assume it establishes the applicable obligations there.
Leave the meeting with an accountable record
Create a short review log: question, answer, evidence, owner, unresolved issue, and launch consequence. Some open questions may be acceptable for a limited test using synthetic data. Others may prevent live processing. Have the responsible reviewers make that decision explicitly.
Assign an owner to notice changes in terms, subprocessors, retention settings, and integration permissions. The review is not finished forever when the contract is signed. The product and your own workflow can change.
The feature list tells you what a system might do. The data review tells you what relationship you are entering and what work your organization will own after customer information starts moving through it.
Sources
For help defining this workflow, explore our workflow integration work.
Keep reading
