The AI Compliance Checklist Every Product Now Needs

You were winning the enterprise deal. The buyer loved the demo, the ROI math worked, and the contract was in review. Then their security team sent over a questionnaire with 120 items, most of them about AI specifically. Your team answered maybe 30 of them honestly. The other 90 are blanks, deferred, or aspirational. The deal is now delayed a quarter while your legal and engineering teams scramble to backfill answers that should have been ready on day one. Two of your competitors pass the questionnaire in a week because they had the answers prepared. Your deal is at risk.

This is the compliance gap, and in 2026 it is one of the three most common ways enterprise AI products lose deals — behind "quality wasn't ready" and "integration was too hard," but ahead of "priced too high." The gap is entirely preventable with one afternoon of work, a standard checklist, and a commitment to keep it current. This post is that checklist.

I'm not going to give you legal advice — I'm not a lawyer, and any real compliance decision needs one. I'm going to give you the product-side checklist: the specific items every 2026 enterprise AI product has to have an answer for, grouped so a PM can take them to legal as a starting point rather than a cold ask. The goal is to make compliance a spec item that sits alongside the rest of the one-pager, not a surprise that derails a deal in month three.

No code. Real regulatory names. Concrete document templates. The things your security questionnaire will ask, organised so you can answer them.

---

The compliance map, at a glance

There are roughly six domains of AI compliance every 2026 enterprise product has to answer for. Each one has a different set of stakeholders, a different set of documents, and a different way of breaking a deal.

Six domains, each with roughly 10-20 concrete checklist items beneath it. Let me walk through each with the specific items you need, the documents that satisfy them, and the 2026 realities of what enterprise buyers actually ask for.

---

Domain 1: data flow and residency

What enterprise buyers ask: "Where does our data go when we use your AI feature? Which third parties see it? In which regions is it processed? Can we restrict processing to specific regions?"

Why this matters in 2026: every enterprise buyer has data-residency constraints, either regulatory (GDPR, German data law, Swiss data law, UK data protection, various US state laws, Indian DPDP Act) or contractual (their own customers expect data to stay in certain regions). If your AI feature sends data to a provider that doesn't respect those constraints, the deal can't close.

The specific checklist items:

1. A data flow diagram for every AI feature. Where the user's input goes, which services it passes through, where it's stored, for how long. Not a slide — a real diagram with specific components named. Your engineering team produces this; the PM owns that it exists.
2. Named third-party subprocessors. Which AI providers, which vector stores, which grading platforms, which observability tools see customer data. Each one is a subprocessor under GDPR and typically requires DPA coverage.
3. Regional processing options. Does the feature work if the buyer requires processing in the EU only? In the US only? In their own cloud tenancy? Each frontier provider (Anthropic, OpenAI, Google) has specific regional options in 2026; know which ones you support.
4. Data flow exceptions. What data never leaves the buyer's environment? (Often: the buyer's own documents in RAG pipelines, if indexed on their infrastructure.) What does leave? (Often: the user's query, sent to the model provider.) Enterprise buyers want the distinction explicit.
5. Transit and at-rest encryption. TLS 1.3 for in-flight data, AES-256 at rest, documented. This is table stakes in 2026 but the questionnaire will ask.

The document that answers most of this: a Data Processing Addendum (DPA) tailored for AI workflows. Your legal team probably has a standard DPA; the AI-specific version names the subprocessors, describes the AI-specific data flows, and commits to the residency options. Most enterprise buyers in 2026 will attach their own DPA template and ask you to sign it; having a pre-approved version of your own that you can offer instead saves weeks of legal back-and-forth.

Specific 2026 trap: assuming the frontier provider's DPA covers your app. It doesn't. The provider's DPA covers the provider's handling of data you send them. Your app sits between the user and the provider, and your DPA has to cover your handling separately. Both DPAs are needed.

---

Domain 2: training and retention

What enterprise buyers ask: "Is our data used to train your or your provider's models? How long is it retained? Can we opt out? Can we delete it on request?"

Why this matters: this is the single most common compliance question in 2026, and it's the one that kills the most deals when the answer is unclear. Enterprise buyers will not send confidential data through a feature that could be used to improve a model that a competitor might also use. The default answer must be "your data is not used for training, and here's the document that proves it."

The checklist items:

1. "No training on your data" as the default. Every major frontier provider (Anthropic, OpenAI, Google) offers a no-training-on-input option for enterprise customers in 2026. Make sure your app is configured to use it. Get the provider's attestation in writing.
2. Retention limits, documented. How long does the provider store the data? How long does your app store it? Typical 2026 enterprise answer: 30 days max at the provider level, configurable at your app level (often set to 7-14 days for operational purposes).
3. Zero retention option. Some provider tiers offer "zero retention" — data is not persisted at all beyond the API call. For high-sensitivity deals, this is the ask. Know which tiers support it.
4. Deletion on request. GDPR "right to be forgotten" and similar regulations require that you can delete a user's data on request, including data passed through the AI pipeline. Your system has to be able to identify and purge a specific user's data end-to-end. This is infrastructure work; start it early.
5. Data isolation. User A's data does not influence user B's output. This is usually trivially true because each call is stateless, but buyers ask it explicitly and "yes, here's why" is a better answer than "obviously."
6. Fine-tuned model attribution. If you fine-tune models on user data (usually you shouldn't — see Course 2 B6.2), you need a clear story about which users' data went into which model, and how a single user's deletion request affects the fine-tuned model. Most mature answer in 2026: don't fine-tune on customer data at all, or fine-tune per-tenant with clean deletion.

The document: an AI Data Handling Policy you publish publicly on your trust / security site. One page. Covers the above items in plain language. Buyers check this page first; if it exists and is specific, they relax; if it's vague or missing, the questionnaire gets longer.

Specific 2026 trap: "we don't train on your data" as a spoken promise but not in the contract. Without contractual language, the buyer's legal team assumes the opposite and the deal gets stuck. Put "no training on customer data" explicitly in the MSA or the DPA. Your competitors do.

---

Domain 3: privacy and PII handling

What enterprise buyers ask: "What happens when our data contains PII? Do you detect it? Do you redact it? Do you log raw PII anywhere?"

The checklist items:

1. PII detection at ingest. Before data hits the model, a detection step identifies common PII categories (names, emails, phone numbers, SSNs, credit cards, health identifiers). The set depends on your audience; 2026 starter set for B2B is names, emails, phone numbers, financial account numbers, SSN-shaped strings, and credit card numbers.
2. Redaction policy. What happens when PII is detected? Three common options: block (reject the input with an explanation), redact (replace with placeholders like [NAME] before sending to the model), or pass-through (send as-is, document that it happened). The right option depends on the feature; most enterprise features in 2026 default to redact.
3. Logging policy. The observability stack (Course 2 B5.3) logs prompts and outputs. Those logs may contain PII. Your retention policy on those logs has to be explicit: how long, who can access, under what circumstances. Most mature answer: PII redacted in the logs, not just in the model call. This is infrastructure work and is rarely free.
4. Processor agreements. Any third party that touches the logs (Datadog, Sentry, analytics) is a processor of the data. They need their own DPA coverage, and the buyer will ask.
5. Cross-tenant isolation in logs. Your team can read logs; which logs can they read? If a support engineer can search across tenants, that's a privacy risk. 2026 best practice: per-tenant log isolation and access audit.

The document: a Data Protection Impact Assessment (DPIA) for high-risk features. Not every feature needs one, but any feature that processes health data, financial data, children's data, or data from vulnerable populations does, per GDPR and equivalent regulations. The DPIA is a 3-5 page document your legal team produces; your job as PM is to flag which features need one and get them into legal's queue early.

Specific 2026 trap: assuming PII is rare in your inputs. Customer support transcripts are full of PII. Meeting notes are full of PII. Email bodies are full of PII. If your feature ingests any of these, PII handling is not optional — it's in the path on every single call. Detect and redact at ingest, not at review time.

---

Domain 4: EU AI Act classification

What enterprise buyers ask: "Under the EU AI Act, what category is your AI system? What obligations does that trigger? Where is your classification documentation?"

Why this matters in 2026: the EU AI Act is in force. High-risk AI systems have documentation obligations that your enterprise buyers in Europe will check. General-purpose AI models (like the frontier models you wrap) have transparency obligations that affect downstream products. Buyers want to know where you sit.

The checklist items:

1. Classification statement. Which category does your AI system fall into under the AI Act? Minimal risk (most features — no obligations), limited risk (transparency required — users must know they're interacting with AI), high-risk (heavy obligations — risk management, data governance, human oversight, transparency, conformity assessment), or prohibited (not shippable in the EU). Most SaaS AI features in 2026 are minimal or limited risk.
2. Transparency statement for limited-risk systems. If your feature is a chatbot, emotion recognition, biometric categorisation, or deepfake generation, you must disclose that to users. One sentence in the UI, usually.
3. High-risk documentation if applicable. If your feature is used for employment decisions, credit scoring, law enforcement, critical infrastructure, education access, or similar high-risk uses, you need a technical documentation package covering risk assessment, training data, testing, monitoring, and human oversight. This is a significant document and typically months of work.
4. GPAI downstream obligations. Even if your feature isn't high-risk, you're likely using a general-purpose AI model (GPAI) from a frontier provider. The AI Act puts transparency obligations on GPAI providers (model cards, training data summaries, copyright compliance); as a downstream user, you inherit some of these obligations and need to know your provider is meeting them.
5. Human oversight design. Any high-risk feature must have documented human oversight. What does "oversight" look like in your product? Who reviews? How often? With what authority to override?

The documents: for minimal-risk features, a one-page AI Act Statement on your trust site is sufficient. For limited-risk, the same plus in-product disclosure. For high-risk, you need the full technical documentation package, and this is where you'll want real legal and regulatory help — don't try to do it as a PM alone.

Specific 2026 trap: assuming the AI Act doesn't apply because your company isn't in the EU. It applies to any AI system available to EU users, regardless of where your company is based. If you have EU customers, the Act applies. Check early, classify early, document early.

---

Domain 5: security and audit

What enterprise buyers ask: "Do you have SOC 2? ISO 27001? How does your AI feature fit into those reports? Who has access to customer data? What's your incident response plan?"

The checklist items:

1. SOC 2 Type II report that covers AI features, not just traditional infrastructure. Many companies have SOC 2 for their legacy product but the AI features are outside the scope of the audited system. If that's you, fix it. Add AI features to the audit scope in the next cycle. Enterprise buyers in 2026 will check whether the AI is in scope.
2. Access controls on AI-specific systems. Who can read prompts, outputs, eval data, fine-tuning data? Role-based access with audit logs. Less mature teams have "everyone on the AI team" access; more mature teams have role-based access with specific justifications for each role's permissions.
3. Penetration testing that includes AI attack surfaces. Prompt injection (Course 2 B2.4) is a penetration testing concern. Your pen test should include AI-specific attack vectors: injection, data extraction attempts, model-response manipulation. Buyers will ask whether your pen test covers AI.
4. Incident response plan with AI-specific scenarios. What happens when a prompt injection succeeds? When the model leaks data? When a hallucination causes customer harm? Your IR plan should name these scenarios specifically, not just generic "data breach" scenarios.
5. Audit trail of prompt and model changes. Every prompt change, every model version change, every eval-set change is logged with who, what, when, and why. Buyers in regulated industries want to know they can reconstruct exactly what the AI system was doing on a specific date.
6. Vendor risk assessment for AI providers. Your frontier model provider is a vendor and needs to go through your standard vendor risk process. Most enterprises have a template; make sure Anthropic, OpenAI, or whoever you use has been through it.

The document: your SOC 2 Type II report is the gold standard. If you don't have one yet, an ISO 27001 certification or a third-party security attestation is a step in the right direction. The thing you can't skip is the scope — whatever framework you use, AI features must be explicitly in scope.

Specific 2026 trap: "we'll add AI to the SOC 2 next year." Enterprise buyers hear this as "you're not taking AI security seriously enough yet," and they're right. The fix is to do it early, even if it means accelerating the audit timeline. Every quarter you wait, more deals hit this question.

---

Domain 6: contractual assurances

What enterprise buyers ask: "What do you commit to in writing? IP indemnity? Accuracy warranties? Liability caps?"

The checklist items:

1. IP indemnity for AI outputs. If the AI produces output that infringes a third party's copyright or trademark, who's liable — you or the buyer? In 2026 enterprise deals, buyers expect the vendor to indemnify for AI output IP claims, up to a capped amount. Major frontier providers (Anthropic, OpenAI) offer this for their API outputs; you can pass it through contractually. Without this line, enterprise legal teams will block the deal.
2. Accuracy disclaimers, clearly scoped. No AI output is 100% accurate; you can't warranty it. But you can commit to specific quality bars, specific testing procedures, and specific operational guarantees. The contract should be specific about what you're not warrantying (individual output accuracy) and what you are (the process, the controls, the uptime).
3. Uptime SLA that includes AI provider outages. If Anthropic's API goes down for two hours, is that counted against your SLA? Buyers want clarity. Most 2026 AI products explicitly carve out frontier provider outages but commit to maximum downtime and communication windows.
4. Data deletion commitment. Contractually, not just policy-wise. "Upon termination or on request, we will delete all customer data within 30 days and provide written confirmation." Legal teams love this clause; without it, buyers assume worst case.
5. Notification obligations for incidents. How quickly will you notify the buyer of a security incident, data leak, or AI-specific failure? 24 hours is becoming the 2026 standard; some buyers ask for faster.
6. Right to audit. Large enterprise buyers want the contractual right to audit your AI systems, especially if they're in regulated industries. You don't have to agree to unlimited audits, but the contract should describe the process.

The document: your Master Service Agreement (MSA) plus the AI-specific DPA. The combination covers everything above. Most of the work is legal's, not yours — but you as PM need to know what the buyer will ask and make sure legal has pre-negotiated language ready.

Specific 2026 trap: letting enterprise deals drive each contract negotiation from scratch. Every deal's negotiation is slightly different, but 80% of the questions are the same ones. Build a standard enterprise MSA and DPA template with pre-negotiated language for the common clauses; update it quarterly with what the last batch of deals asked for. Teams that do this close enterprise deals 30-50% faster than teams that re-negotiate from scratch each time.

---

The one-page compliance checklist

For a PM to use this post operationally, here is the condensed version — print it, put it in your onboarding doc for any AI product team, and use it as a starting point for every new AI feature.

# [Feature] Compliance Checklist — [date]

## Data flow and residency
- [ ] Data flow diagram
- [ ] Subprocessors list
- [ ] Regional processing options documented
- [ ] DPA updated

## Training and retention
- [ ] "No training on customer data" configured with provider
- [ ] Provider retention limit documented
- [ ] User deletion on request implemented
- [ ] AI Data Handling Policy published

## Privacy and PII
- [ ] PII detection at ingest
- [ ] Redaction policy documented
- [ ] Log retention and access audit
- [ ] DPIA completed (if high-risk category)

## EU AI Act
- [ ] Classification statement (minimal / limited / high / prohibited)
- [ ] Transparency disclosure (if limited-risk or above)
- [ ] Technical documentation (if high-risk)
- [ ] GPAI provider transparency confirmed

## Security and audit
- [ ] SOC 2 scope includes AI features
- [ ] Access controls and audit logs for AI systems
- [ ] Penetration test covers AI attack surface
- [ ] Incident response plan names AI scenarios
- [ ] Audit trail on prompt / model changes

## Contractual
- [ ] IP indemnity clause in MSA
- [ ] Accuracy disclaimers
- [ ] SLA handles provider outages
- [ ] Data deletion commitment
- [ ] Incident notification timeline
- [ ] Right to audit clause (for enterprise)

Twenty-four items. Most of them can be "yes, already done" for a mature team; for a new feature or a new team, expect 10-15 to need real work. The PM's job is not to complete all 24 personally. It is to make sure someone owns each one, and the answers exist before the first enterprise questionnaire shows up.

The practical sequence:

1. Run this checklist at spec time, not post-launch.
2. For each "no," assign an owner (legal, security, engineering, or yourself) and a target date.
3. Re-run the checklist monthly until everything is green.
4. Re-run quarterly thereafter to catch drift.

An afternoon of upfront work, a few hours a month of maintenance, and you are no longer the team that loses deals to compliance questionnaires.

---

A worked example: a deal saved by preparation

Here's a specific 2026 pattern I've watched play out twice, with names anonymised. Same company, same feature, two different sales cycles.

Cycle 1 — deal lost: sales is closing a mid-market B2B deal for a support-AI product. The demo is great. The pricing is agreed. The contract is in review. The buyer's security team sends a 130-item questionnaire. The AI-specific sections are most of it. The team scrambles. They have DPA language but it's generic, not AI-tailored. SOC 2 doesn't cover AI features. No DPIA exists. No statement on EU AI Act. Retention policy is in slack messages, not a document. The team answers 60 of 130 items within a week; the rest take three more weeks. The buyer's CISO loses patience. A competitor with worse features but complete paperwork closes the deal. Lost.

Cycle 2 — deal saved: same team, 3 months later, different buyer. The team has since built the checklist. DPA is AI-tailored. SOC 2 scope now explicitly covers AI features. DPIA template exists. AI Act classification statement is on the trust site. Retention policy is a published document. A new 125-item questionnaire arrives. The team answers 110 of them in 48 hours from the existing doc inventory; the 15 remaining items are genuine new questions from this specific buyer. Total questionnaire turnaround: 5 days instead of 4 weeks. Deal closes.

Cost of preparation: ~2 weeks of cross-functional work (PM, legal, security, engineering) spread across the 3 months between cycles. Value: one enterprise deal saved that was worth ~$300K ARR, and every subsequent enterprise deal is ~3x faster to close.

The pattern is this specific: every team that builds the checklist retroactively after losing a deal says "we should have done this at spec time." Every team that builds it at spec time says "it was cheaper than we thought and it closed deals we wouldn't have won."

---

The failure mode: "that's legal's problem"

The single specific failure mode for this post: a PM who treats the compliance checklist as legal's problem and delegates entirely. Legal is a required partner, but they can only answer the legal shape of the questions. The PM has to know which AI features exist, what data they process, what the risks are, and when the compliance work has to happen in the build cycle. A PM who says "I'll let legal handle the AI Act when it comes up" is a PM whose deals will stall in month three while legal frantically backfills.

The counter: treat compliance as a normal item in the one-pager, not a special legal concern. Section 11 of the one-pager (Observability and Guardrails, from P2.4) already covers the operational side; the compliance work adds Sections 11b and 11c (data handling and legal commitments). Every AI feature PRD has a line naming which compliance items apply and who owns each. If that line is missing, the PRD is incomplete.

The cultural shift: compliance becomes a thing the PM tracks, not a thing that happens to them. Teams that make this shift ship faster and win more enterprise deals, because the work is distributed and timely instead of reactive and frantic.

---

What just changed in your roadmap

• Run the 24-item checklist on every AI feature at spec time. Assign owners for every "no." Re-run monthly.
• Publish an AI Data Handling Policy on your trust site — one page, specific, linked from the buyer's first point of contact.
• Get AI features into the SOC 2 scope if they aren't already. Even a partial scope is better than being outside the report entirely.
• Classify every AI feature under the EU AI Act and put the classification statement on your trust site. Most will be minimal or limited risk; the statement is short.
• Build a pre-negotiated enterprise MSA and DPA template with AI-specific language. Update quarterly. Teams that ship this close enterprise deals 30-50% faster.
• Treat compliance as a PM item, not a legal hand-off. Legal is a partner; the PM owns the schedule and the inventory.
• Assume the first enterprise questionnaire will ask 100+ questions, most of them AI-specific. Prepare the answers before the questionnaire arrives, not after.
• Re-run the checklist quarterly to catch drift — new features, new subprocessors, new regulations, new model versions all shift the answers.

Next post, P4.3, covers the rollout side of trust and risk: rolling out an AI feature without losing the room. Canaries, betas, opt-ins, comms plans, and the specific sequence for exposing an AI feature to increasing user populations without producing the kind of public failure that makes the launch into a news story.

---

Course navigation

📚 AI for Product · Course Home — 20 posts, five modules.

---

Cover photo via Unsplash. This post is part of the AI for Product series.