Quick answer: Before sending customer information to an AI vendor, document what data the task actually needs, which product and contract apply, how information is used and retained, who can access it, and how deletion works. Check downstream providers and international processing too. Start with fictional or minimized data; approve identifiable customer data only after unresolved privacy, security, and contractual questions have been addressed. The FTC recommends selecting service providers carefully, putting security expectations in writing, and verifying that providers follow through. (ftc.gov)
Vendor documentation checked October 4, 2026. This guide provides procurement guidance, not a legal opinion.
1. Define the task and the minimum data needed
Start with a specific use case: “Draft a response to a delivery complaint” is easier to assess than “Give AI access to our customer database.”
Write down:
- The intended output and who will use it.
- The customer fields needed to produce that output.
- The people and systems receiving the input or output.
- Whether the tool merely drafts content or can take actions.
For each field, ask: Would removing this information prevent the task from working? A complaint summary may need the problem description but not a customer’s name, home address, payment details, or complete purchase history. The FTC advises businesses not to collect unnecessary personal information and recommends fictitious information for development where real customer data is unnecessary. (ftc.gov)
Create a simple data-flow sketch:
Customer system → preparation step → AI application → model provider → output destination
Add any logging service, connected tool, or outside provider that receives information. The ICO advises assessing AI security across the wider chain of software components, data flows, and business processes rather than treating the model as an isolated system. (ico.org.uk)
Keep the approved field list narrow. If the workflow later needs attachments or additional customer records, treat that as a change requiring review—not an automatic extension of the original approval.
2. Verify the exact product, contract, and training policy
Do not approve a vendor name alone. Record the legal supplier, product, subscription tier, account type, enabled features, and applicable agreement.
The same provider can publish different data-use rules for individual and business services. OpenAI’s policy, updated March 13, 2026, says content from individual services may be used for training unless the user opts out. Its business-data page says inputs and outputs from specified business products and the API are not used for training or model improvement by default. These are vendor-published statements, not independent findings. (openai.com)
Ask separately about:
- Training or improving general-purpose models.
- Evaluation, feedback, and product improvement.
- Abuse monitoring and safety investigations.
- Human review and support access.
- Optional data-sharing settings and who can change them.
A “no training” statement does not answer whether information is stored: OpenAI’s API documentation, for example, separately describes abuse-monitoring logs and stored application state. (developers.openai.com)
Request the applicable data-processing agreement or addendum, usually called a DPA. Save the version accepted by your organization alongside the order form and security documentation. If a sales answer is important to approval, ask where it is reflected in the binding agreement.
3. Separate retention, deletion, and training use
Ask for a retention schedule by data category—not one headline number.
Your request should cover prompts, outputs, uploaded files, conversation history, searchable document stores, logs, support records, and backups. Ask when the retention period starts: submission, last use, deletion request, or contract termination.
OpenAI’s API documentation illustrates why this matters. It says default abuse-monitoring logs may contain customer content and are retained for up to 30 days, with stated exceptions. It also lists separate storage behavior for particular endpoints. Zero Data Retention requires approval and has endpoint and feature limitations; some ineligible capabilities may still store application state. (developers.openai.com)
For deletion, ask:
- What can an administrator delete during the contract?
- Does deletion cover inputs, outputs, files, and derived records?
- When do backups expire?
- What must be retained for legal or security reasons?
- What evidence confirms completion?
OpenAI’s published DPA, for example, provides for return or deletion following termination at the customer’s instruction, except where applicable law requires retention. That contractual provision is not itself a complete operational deletion schedule. (openai.com)
Use fictional records to test the deletion controls available to you. Record what disappears from the interface and what the vendor says happens elsewhere. A successful interface test should not be described as proof that every backend copy has been erased.
4. Check access controls—and the evidence behind security claims
Examine both sides of access: your employees’ permissions and the vendor’s access to customer content.
Request details about administrator roles, authentication, account removal, API credentials, sharing controls, vendor support access, and access logging. Prefer named accounts and limited permissions over shared administrator credentials. FTC guidance emphasizes need-to-know access and limiting administrative privileges to employees who require them. (ftc.gov)
Then distinguish three kinds of evidence:
| Evidence | What to establish |
|---|---|
| Public security statement | What the vendor says it does |
| Contractual commitment | What the applicable agreement requires |
| Independent assessment | What an assessor examined, for which service and period |
For example, OpenAI publishes encryption claims and references security assessments and certifications. Those statements are a starting point for requesting evidence; they do not establish that your particular workflow has been independently assessed. (openai.com)
If an audit report is available, ask your security reviewer to examine its scope, date, exceptions, and responsibilities assigned to customers. Record any material evidence the vendor will not provide. The FTC specifically recommends checking providers’ technical capabilities and verifying compliance rather than relying on assurances alone. (ftc.gov)
5. Investigate subprocessors and cross-border processing
A subprocessor is another organization engaged to process data on the vendor’s behalf. Request the list relevant to your chosen service, each provider’s function, and how changes are communicated.
Review the objection process as carefully as the list. OpenAI’s published DPA, for example, provides general authorization for listed subprocessors and a 30-day period to object to additions after notice, subject to its specified resolution and termination provisions. (openai.com)
Ask distinct location questions:
- Where is customer content stored?
- Where does model inference occur?
- Where can support or other personnel access it?
- Where are logs and backups handled?
- Which legal entities receive it?
Do not assume regional storage settles international-transfer questions. Under the ICO’s UK guidance, the receiving organization’s place of establishment matters, and making information accessible to an organization outside the UK can constitute an outbound transfer. UK and EU treatment is not identical in every situation. (ico.org.uk)
For processing governed by UK GDPR, the ICO says an appropriate lawful basis is necessary whether personal data is used to train a system or to make predictions with an existing one. The vendor’s willingness to accept data is not a substitute for your organization’s assessment. (ico.org.uk)
Have counsel determine which rules and transfer safeguards apply. The ICO’s AI security and minimization guidance is currently marked as under review following the Data (Use and Access) Act, so verify relevant requirements before a UK-related deployment. (ico.org.uk)
6. Send a procurement questionnaire that requires evidence
Use the following hypothetical questionnaire as a starting template. It is not a completed assessment or a universal legal checklist.
Require each response to include the answer, supporting document or clause, product scope, exceptions, and verification date.
| Area | Question to send |
|---|---|
| Product scope | Which legal entity, plan, features, and agreement will process our approved data? |
| Permitted uses | Is content used for training, evaluation, improvement, monitoring, or human review? Which settings alter this? |
| Retention | What is retained in each data category, for how long, and from which starting event? |
| Access | Which customer and vendor roles can access content? How is access approved, restricted, and logged? |
| Subprocessors | Who receives content, for what purpose, and how are additions notified? |
| Locations | Where do storage, processing, support access, and backup handling occur? |
| Deletion | How do we delete records during service and at exit? What exceptions and completion evidence apply? |
| Incidents | What notification commitment, escalation route, and investigation assistance are provided? |
| Assurance | Which independent reports cover this service, and what customer responsibilities or exceptions do they identify? |
Mark unanswered items as unresolved, not “probably acceptable.” Use written requirements and follow-up evidence to close gaps—the approach the FTC recommends for service-provider oversight. (ftc.gov)
7. Work through a redacted-data example
Hypothetical scenario: A small retailer wants AI to draft replies to damaged-delivery complaints. The tool will not issue refunds or send messages automatically. No effectiveness or security result is claimed here.
Rather than upload the complete support record, prepare this restricted input:
Task: Draft a courteous reply for staff review.
Issue: The customer reports that an item arrived damaged.
Customer request: A replacement.
Approved policy: Ask whether the customer prefers a replacement
or a refund, subject to staff verification.
Do not invent delivery dates, stock availability, or compensation.
For this pilot, use the following proposed workflow:
- Begin with fictional complaints. Check whether the tool can draft useful replies without customer records.
- Prepare real inputs inside an approved system. Remove unnecessary identifiers, payment information, unrelated history, and attachments.
- Keep any record mapping separate. If a temporary reference is needed, do not send the identifying lookup table.
- Inspect the outbound text. Check free-text descriptions for details missed by field-based redaction.
- Require staff review. A staff member checks the draft against the actual complaint and approved policy.
- Store and dispose deliberately. Follow the approved schedule for drafts and temporary working records.
This is an application of the FTC’s advice to use fictitious information where possible and limit unnecessary personal-data exposure. (ftc.gov)
Removing a name does not automatically make a record anonymous. The ICO explains that pseudonymized information remains personal data for an organization holding the additional identifying information, and that indirect identifiers or rare characteristics can enable identification. Keep mappings secure and assess the remaining text rather than labeling it “anonymous” by default. (ico.org.uk)
8. Set approval conditions and know when to stop
Approve a defined workflow, not unrestricted use of an AI tool.
Record the owner, permitted fields, approved configuration, human-review requirement, unresolved limitations, and review triggers. Revisit approval when a contract, feature, integration, or subprocessor changes. Ongoing monitoring follows the FTC’s recommendation to ensure providers continue meeting security expectations. (ftc.gov)
Common mistakes to avoid:
- Treating “no training” as “no storage.”
- Assuming a storage region answers every transfer question.
- Calling name-stripped text anonymous without assessing identifiability.
- Accepting a security claim without checking its scope.
- Approving a pilot and later connecting a larger dataset without review. (developers.openai.com)
Seek specialist advice before proceeding where sensitive information, regulated records, unclear legal authority, or international transfers create unresolved questions. For HIPAA-regulated electronic protected health information, HHS says a covered entity or business associate must have an appropriate business associate agreement with a cloud provider processing or storing that information; other HIPAA obligations still apply. (hhs.gov)
Final check: Can you explain what leaves your systems, why it is necessary, who receives it, what governs its use, and how it is removed? If not, keep the pilot fictional or pause it.