AI vendor security checklist: data-handling questions to ask before signing

TL;DR — When you buy an AI vendor, the biggest risk is usually not the model itself; it is where your data goes, who can see it, how long it is kept, and whether you can turn risky behavior off in writing. The single most useful move is to ask for a plain-language data-flow diagram plus written answers on retention, training use, subprocessors (third-party providers), deletion, logging, and security controls before you sign anything. Reading time: ~7 min

What it is and where it sits

This is a buyer's checklist for the security and data-handling part of AI vendor review. In plain terms: before your app sends customer data to an AI service, you want to know exactly what leaves your systems, where it is stored, who can access it, and what controls you can enforce.

In a typical setup, the AI vendor sits between your application and one or more model or storage systems. It may replace work your own app used to do locally, like search, summarization, chat, document extraction, or classification. It may also add new components you did not have before: prompt logs, vector storage (a database for embeddings, which are numeric representations of text), human review tools, analytics, and third-party model providers.

That matters because your data may no longer flow only through your own database and app server. It may now pass through the vendor's API gateway, logging systems, model runtime, support tooling, and subprocessors.

[End User] ---- 1. ask question ----> [Your App]
[Your App] ---- 2. HTTPS API call ----> [AI Vendor]
[AI Vendor] ---- 3. prompt/context ----> [Model Provider]
[AI Vendor]
| 4. logs/metrics
v
[Vendor Logging]
[AI Vendor]
| 5. files/embeddings
v
[Vendor Storage]
[Model Provider] ---- 6. response ----> [AI Vendor]
[AI Vendor] ---- 7. answer ----> [Your App]
[Your App] ---- 8. result ----> [End User]

The practical question is not "is the vendor secure?" That is too vague to be useful. The useful question is: "At each step in this flow, what data is sent, stored, retained, used for training, visible to staff, and deletable?"

The six questions that usually decide the deal

If you only ask a few things, ask these:

1. Will any of our prompts, files, outputs, or metadata be used to train models? Ask for a yes/no answer for each data type.
2. What is the retention period for prompts, outputs, uploaded files, logs, and backups? "Retained for abuse monitoring" is not specific enough; ask for days.
3. Who are your subprocessors and model providers? Ask for the current list and how you are notified before changes.
4. Can we disable data retention and logging, or reduce it? Ask what is configurable by contract, dashboard, or API.
5. What regions can our data stay in? Region means the geographic location of processing or storage.
6. How do deletion and access work in practice? Ask for the exact deletion path, timeline, and what remains in backups.

How it actually works

Let's walk one realistic example through the system: your support team wants an AI vendor to summarize incoming customer emails and draft replies.

Step-by-step example

1. A customer sends an email to your support platform. The email contains their name, order number, and a complaint.
2. Your support app sends the email body, subject line, and recent ticket history to the AI vendor over HTTPS (encrypted web traffic).
3. The AI vendor may store the request in request logs, queue it for processing, and pass the prompt to a model provider.
4. The model generates a summary and draft response.
5. The vendor returns the result to your app.
6. Your app shows the draft to a support agent.
7. Separately, the vendor may keep logs for debugging, abuse detection, billing, analytics, or product improvement.

Now translate that flow into procurement questions:

• Email body and ticket history: Are these stored? For how long? In what region?
• Order number and name: Are these considered personal data? Can we redact them before sending?
• Prompt and output logs: Can retention be set to 0 days, or only shortened?
• Model provider handoff: Is the vendor running the model itself, or forwarding to another company?
• Human access: Can support engineers at the vendor inspect our prompts during troubleshooting?
• Training use: Are prompts or outputs used to improve any shared model?
• Deletion: If a customer exercises a deletion request, can the vendor remove the prompt, output, file, and derived embeddings?

What a good answer sounds like

A good answer is concrete and scoped. Example:

• "Prompts and outputs are retained for 30 days in US and EU regions for abuse detection; enterprise customers can request 0-day application retention, but security logs remain for 90 days."
• "Uploaded files are stored encrypted at rest (encrypted on disk) and deleted within 7 days after processing; backups expire within 35 days."
• "Customer content is not used to train shared foundation models; this is stated in the order form and DPA (data processing addendum, the contract covering personal data handling)."

A weak answer sounds like this:

• "We take privacy seriously."
• "We follow industry best practices."
• "Data may be retained for operational purposes."

Those are marketing statements, not operating details.

When to use it (and when not to)

You should do this review any time an AI vendor will receive real customer, employee, financial, health, legal, or proprietary business data. If the tool will only ever see public marketing copy or synthetic test data, you can usually do a lighter review.

You probably don't need this if...

• The AI tool will never touch real business or personal data.
• You are evaluating a prototype in an isolated sandbox with synthetic data only.
• The decision is not about a vendor at all, but about an internal model you run fully inside your own environment.

Trade-offs

Every useful vendor control has a cost. Here is the honest version.

• Benefit: shorter retention or no content logging. Cost: weaker vendor debugging, harder incident investigation, and sometimes reduced product support.
• Benefit: regional processing and storage. Cost: fewer model choices, higher price, or slightly higher latency (delay) if your users are elsewhere.
• Benefit: no training on your data. Cost: enterprise contract negotiation, possibly higher fees, and less access to beta features.
• Benefit: customer-managed encryption keys (keys you control). Cost: more setup, key rotation work, and possible outages if keys are misconfigured.
• Benefit: self-hosted or single-tenant deployment (your isolated environment). Cost: more operational burden, slower upgrades, and less elasticity during traffic spikes.
• Benefit: strict subprocessor approval. Cost: procurement overhead and slower vendor feature rollout.

The key is to match controls to the sensitivity of the data. Do not pay for maximum isolation if the use case is low-risk marketing copy. Do not accept vague defaults if the use case includes customer records or regulated data.

In practice

Below are two practical artifacts you can use today: a vendor questionnaire and a simple redaction gateway pattern.

Example 1: vendor questionnaire you can send before procurement review

Save this as a document or ticket template and ask the vendor to answer line by line.

## AI Vendor Security and Data Handling Questionnaire

1. Data use for training
- Are prompts used to train any shared model? Yes/No
- Are outputs used to train any shared model? Yes/No
- Are uploaded files used to train any shared model? Yes/No
- Is metadata (timestamps, user IDs, IPs) used for product improvement? Yes/No

2. Retention
- Prompt retention period: ___ days
- Output retention period: ___ days
- File retention period: ___ days
- Security log retention period: ___ days
- Backup retention period: ___ days

3. Storage and processing locations
- Available processing regions: ___
- Available storage regions: ___
- Can region be pinned by contract or account setting? Yes/No

4. Access controls
- Can vendor staff access customer content for support? Yes/No
- If yes, under what approval process?
- Are access events logged and reviewable? Yes/No

5. Subprocessors and model providers
- List all current subprocessors involved in storage, logging, model inference, and support.
- How are customers notified before subprocessor changes?

6. Deletion
- How can a customer request deletion: dashboard, API, support ticket?
- Deletion SLA (time to complete): ___ days
- What remains in backups, and for how long?

7. Security controls
- Encryption in transit: TLS version(s) supported
- Encryption at rest: Yes/No
- SSO/SAML support: Yes/No
- SCIM provisioning: Yes/No
- Audit logs export: Yes/No
- Penetration test or third-party assessment available under NDA: Yes/No

8. Contractual commitments
- Is non-training use stated in the MSA/DPA/order form? Yes/No
- Is data residency stated in the contract? Yes/No
- Is breach notification timeline stated in the contract? Yes/No

What it does: this forces the conversation from "trust us" to specific operational facts. Gotcha: if the vendor answers "configurable" or "case by case," ask what the default is and what exact contract language changes it.

Example 2: simple application-side redaction before sending text to an AI API

If you cannot avoid sending sensitive text, reduce it first. This example masks common identifiers before your app forwards content to a vendor.

function redactSupportText(input) {
  return input
    .replace(/\b\d{12,19}\b/g, "[CARD_NUMBER]")
    .replace(/\b\d{3}-\d{2}-\d{4}\b/g, "[SSN]")
    .replace(/\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}\b/gi, "[EMAIL]")
    .replace(/\b\+?[0-9][0-9\-() ]{7,}\b/g, "[PHONE]");
}

const original = "Customer Jane Doe, jane@example.com, says card 4111111111111111 was charged twice.";
const safeForAI = redactSupportText(original);
console.log(safeForAI);

What it does: removes obvious personal and payment-like strings before the API call. Gotcha: regex redaction is imperfect; test it on real samples and do not assume it catches names, addresses, or every identifier format.

Example 3: API request policy your developers can adapt

This shows the kind of internal policy object you can require before any team integrates a vendor.

{
  "vendor": "example-ai-service",
  "approved_use_cases": ["ticket_summarization"],
  "disallowed_data": ["payment_card_data", "government_id", "full_medical_record"],
  "max_retention_days": 30,
  "training_allowed": false,
  "allowed_regions": ["eu", "us"],
  "deletion_request_path": "Privacy portal or vendor support ticket",
  "owner": "Security and Procurement"
}

What it does: turns procurement decisions into something engineering can enforce. Gotcha: this only helps if someone actually checks integrations against it during review.

⚠️ If you change an existing integration to reduce retention, switch regions, or enable deletion, check the vendor's migration notes first. Region moves and storage policy changes can break existing workflows or make historical data unavailable.

The contract point most teams miss

If a sales engineer says "we do not train on your data," ask for the exact place where that appears: order form, DPA, MSA (master services agreement), or security addendum. If it is not written into the signed documents, treat it as a non-binding statement.

Also ask who can change the behavior later. A good follow-up is: "If your default retention or training policy changes, how are we notified, and do we have opt-out or termination rights?"

Further reading

• NIST AI Risk Management Framework
• OWASP Top 10 for Large Language Model Applications
• SOC 2 Trust Services Criteria
• ISO/IEC 27001 Annex A
• The "HTTP Logging" and privacy-related sections of the MDN HTTP docs

This article was written by an AI system and published pending human review. Verify anything you intend to act on.