Legal, Compliance, and the New AI Risk Surface

Bottom line. Your general counsel does not need an AI strategy. They need answers to five specific questions about what your company is doing with AI, what contracts and policies you have in place, and what happens if something goes wrong. Most leadership conversations with legal about AI in 2026 fail because they're too abstract ("is this risky?") when the right conversation is specific ("here are the five things we're doing and the specific legal exposures from each, what do we need to change?"). This briefing is the structure that makes that conversation productive in 20 minutes instead of 3 meetings.

L3.1 gave you the budget side. L3.2 gives you the risk side. Together they cover the two things every CFO and GC want answered before they sign off on an AI investment. The briefing is written from the leader's perspective — not legal advice, not a compliance manual — but the questions here are the ones that will appear in your next board-level AI risk review and the structure is the one your legal team actually wants from you.

---

The five questions your GC needs answered

Start with the specific questions. These are not philosophical questions about AI ethics or existential risk. They are concrete questions with concrete answers, and every question corresponds to a specific exposure you can name and mitigate.

Question 1: What data is leaving our environment, to which vendors, and under what terms? This is the data-flow question from Course 3's P4.2. Your GC wants a complete, documented list of every AI vendor your organisation uses, what customer or internal data reaches them, what their DPA says about training and retention, and which regulatory jurisdictions apply.

Question 2: Which of our AI features make decisions about identifiable individuals, and what's the human-in-the-loop story? This is the EU AI Act question, even if you're not in the EU. "Decisions about identifiable individuals" — employment screening, credit decisions, healthcare routing, access controls — triggers additional regulatory scrutiny under multiple jurisdictions. If any of your AI features cross this line, legal needs to know the specifics.

Question 3: What's our IP exposure if the AI produces infringing output? Covered partly in Course 3's P4.2 (the IP indemnity clause in enterprise contracts). Your GC needs to know: do we have indemnity from our AI providers, do we pass it through to our customers, and what's our residual exposure if neither applies to a specific claim?

Question 4: What's the incident response plan if an AI feature produces harm, and who owns it? Not "do we have one" — that's too abstract. Your GC wants to know the named owner, the escalation path, the notification timelines, and the specific playbook for the most likely incident categories.

Question 5: What's our policy on using customer data to train or fine-tune models, and is it enforceable? Almost every 2026 enterprise customer contract you sign will have a "we won't train on your data" clause. Legal needs to know: do you actually honor this in your engineering practices, can you prove it in an audit, and what happens if the policy is violated accidentally?

Five questions. If your GC gets answers to these five, they can sign off on most AI investments with appropriate conditions. If they don't, every AI decision becomes a separate legal review because they can't calibrate the generic risk against the specific facts.

Five questions, five answers, one productive legal conversation. Let me walk through each with the specific content your GC is actually looking for.

---

Question 1 in depth: data flows

What your GC wants: a one-page AI data flow inventory listing every vendor, the data categories each sees, the data residency, the retention policy, and whether a DPA is in place. Not 30 pages of legal analysis — a table they can reference.

The specific content of the inventory:

Five rows for a typical Pattern 2 org. Your GC reads this in three minutes and knows the shape of your exposure. Compare to the alternative — "we use AI vendors and we have DPAs" — which gives them zero specific information.

The biggest gap most 2026 teams have: they don't know the complete list. A shadow-vendor is a vendor one team adopted for a pilot and never reported to legal. Shadow vendors are the single largest source of compliance surprise at leadership review time. Regular audits (quarterly) prevent shadow vendors from accumulating; ad-hoc discovery when something goes wrong is too late.

The specific action: have your platform team lead (L2.1) maintain the vendor inventory in a git-tracked doc that updates whenever a new vendor is added. Review quarterly with legal. No vendor goes into production without passing through the inventory.

---

Question 2 in depth: decisions about identifiable individuals

Why this is bigger than most teams realise: the regulatory concept of "automated decision-making about individuals" shows up in GDPR Article 22, the EU AI Act's high-risk categorisation, several US state laws (California, Colorado, Illinois, New York), Canada's PIPEDA, and equivalent rules in most developed jurisdictions. Once an AI feature crosses into this territory, the compliance burden jumps significantly.

The specific triggers:

• Employment screening or candidate ranking (very strict).
• Credit, loan, or insurance decisions (heavily regulated).
• Healthcare triage, diagnosis, or treatment recommendations (regulated plus liability exposure).
• Educational access or admission decisions (increasingly regulated).
• Benefits eligibility determinations (public-sector rules).
• Any AI feature whose output substantially affects a person's rights, opportunities, or legal status.

If your organisation has any feature that could be described as "AI decides or recommends something about a specific person," your GC needs to know about it and needs to approve the human-in-the-loop story.

What a defensible human-in-the-loop story looks like in 2026:

1. The AI recommends, the human decides. The final decision is always made by an identified human (not just "reviewed by" — made by).
2. The human has a realistic opportunity to override. The UI presents the AI recommendation alongside the input data and an unambiguous override control. The human is trained to disagree.
3. Overrides are tracked. Metrics on override rate go to a dashboard. If the override rate is 0%, the humans aren't actually reviewing — it's a rubber stamp, and regulators will spot it.
4. Affected individuals have a channel to contest. The user or applicant can ask why a decision was made and can appeal. "The AI said so" is never an acceptable final answer.
5. The logic and training data are documented. Your team can explain, at a high level, how the model makes recommendations and what data shaped it.

If any of these is missing, the feature has compliance exposure under multiple jurisdictions regardless of your industry. Your GC should require all five before approving the feature for production.

The specific trap: "we're using AI as a suggestion tool, not a decision tool" — when in practice the human always follows the AI's suggestion. A 100% follow-through rate in practice is, legally, automated decision-making even if it's nominally advisory. Measure the override rate; if it's below ~5%, the regulatory framing is wrong and you need to either add meaningful human review or treat the feature as automated and comply accordingly.

---

Question 3 in depth: IP exposure on AI output

The question: if your AI produces output that infringes someone's copyright, trademark, or patent, who's liable — you, your vendor, or your customer?

The 2026 reality:

• Frontier providers (Anthropic, OpenAI, Google) offer IP indemnity for their API outputs, typically with caps (specific dollar amounts or a multiple of your annual contract). Read your current contract; the specific cap matters.
• Your provider's indemnity rarely covers all scenarios. Common carve-outs: if you fine-tuned the model, if you wrote the prompt that triggered the infringement, if you used the output in a way the vendor disclaims (e.g., high-risk applications).
• Your customers expect you to pass through some form of indemnity. In enterprise sales, this is increasingly a contract gate — customers don't want residual liability from AI output they received from you.

What your GC needs to know:

1. Which providers indemnify us, and what's the cap? One-line answer per vendor.
2. What are the carve-outs in each indemnity? Specific exclusions.
3. Do we pass through indemnity to our customers, and to what extent? Your customer contracts.
4. What's our residual exposure — the gap between what your vendor covers and what your customer expects?

The residual exposure gap is usually where the surprise lives. A vendor's indemnity caps at $500K and a customer contract promises unlimited indemnity creates a hard-to-see $X-million gap that your GC needs to know about.

The specific move: ask your GC to produce a one-page IP indemnity matrix showing provider → you → customer for every active AI vendor. The matrix will surface the gaps. Most gaps are addressable through contract negotiation or through limiting the AI features that flow into customer-visible outputs.

---

Question 4 in depth: incident response ownership

The question: when your AI produces output that causes harm — a wrong classification, a hallucinated recommendation, a leaked piece of data, a biased decision — who at your company owns the response?

The 2026 reality: AI incidents are real incidents (Course 3 P4.4 covered this in depth). They have all the properties of traditional incidents — timed response, stakeholder communication, root cause analysis, remediation commitments — plus specific AI-flavored complications: the output may be generated on the fly and hard to reproduce, the affected population may be hard to identify, the "correct" output may be contested, and the vendor may share some responsibility.

What a defensible AI incident response plan contains:

1. A named AI incident owner at the executive level. Not "the AI team" — one person. Typically the platform team lead for Pattern 2 orgs, or a dedicated AI governance lead for Pattern 3.
2. Severity definitions specific to AI (P0: public visibility, legal exposure, multiple affected customers; P1: named customer affected, contained exposure; P2: internal discovery, no customer impact).
3. Notification timelines matching your contract commitments (24 hours is typical for enterprise; faster for some sectors).
4. A pre-drafted communications template for first comms to affected parties (Course 3 P4.4 provides the template).
5. An escalation path that includes legal, comms, and the executive sponsor.
6. A post-incident review template that captures root cause, scope, remediation, and any policy changes.

What your GC wants: confirmation that items 1-6 exist in written form, are current, and have been tested (tabletop exercise at least once a year). "We have a general incident response plan" is insufficient because AI incidents have specific complications that generic plans don't cover.

The specific trap: treating AI incidents as purely technical and letting the engineering team own them end to end without legal, comms, and executive involvement. A 2026 AI incident that goes public without coordinated response is almost always a communications disaster, regardless of how fast the technical fix landed.

---

Question 5 in depth: no-training policy

The question: your enterprise customer contracts promise "we won't train on your data." Can you prove it?

The 2026 reality: most contracts include this clause, most engineering teams don't think about it day to day, and most legal teams assume it's handled at the vendor level without checking whether it's actually enforced in the team's actual usage patterns. The gap between "the contract says we don't train" and "no customer data is ever used for training in any pipeline" is where audits fail.

Specific enforcement checks your GC should verify:

1. Provider-level enforcement: are your frontier vendor API calls configured with the no-training flag? (This is a single flag in most vendor configurations and most teams set it correctly, but it's easy to miss.)
2. Fine-tuning pipelines: if you fine-tune any models, is the training data only from internal sources or explicitly consented customer data? Never general customer data.
3. Retrieval and vector stores: customer data in a RAG system is not "training" in the technical sense, but it can be confused for it in customer conversations. Be clear about the distinction in your contracts.
4. Observability and logging: your logs may contain customer data. Are they subject to any "improvement" pipeline that could constitute training?
5. Eval sets: your eval sets may be derived from customer data. If so, how is that data sanitised and controlled?

The single largest failure mode is item 5 — eval sets built from real customer data without the data being properly anonymised or consented. This is technically "use of customer data to improve the system" and, depending on the exact contract language, can violate the no-training clause. Course 3 P3.2 covered the anonymisation workflow; your GC needs to know it's being followed.

The specific action: annual legal audit of the no-training claim against your actual pipelines. Your platform team walks legal through each pipeline and confirms no customer data flows into training. Takes a day. Saves quarters of incident response if the clause is ever disputed.

---

The four risks that are bigger than most leaders think

Beyond the five questions, four specific risks deserve naming because they're consistently underestimated in 2026 leadership conversations.

Risk 1: Shadow AI vendor adoption

Engineers sign up for a free tier of an AI tool, paste customer data into it for a quick exploration, and never report it. Multiply by the number of engineers and the number of free tools available, and within 6 months your "AI vendor inventory" is missing 30-50% of actual data flows. Each shadow vendor is a potential compliance violation and an unmitigated data leak surface.

The mitigation: an explicit policy that any AI tool touching any data beyond public examples must be approved and added to the inventory. Most 2026 employees follow the policy if it's clear; the minority who don't are caught by the quarterly audit. Both parts matter — the policy alone isn't enough, the audit alone isn't enough.

Risk 2: Prompt injection in production

Course 2 B2.4 covered this in depth. At the leadership level, the specific exposure is: prompts your system shows users can be manipulated by adversarial input to produce outputs your company would not sign off on, from leaking system prompts to generating policy-violating content to making up facts that appear authoritative. This is a real, active attack vector in 2026, not a theoretical concern.

The mitigation: input sanitisation and output filtering (covered in P4.1 and P4.2 of Course 3). Your GC should confirm the platform team has these in place for every user-facing AI feature. Absence of these defences is a material risk to the company.

Risk 3: Regulatory divergence between jurisdictions

The EU AI Act, US state laws, Canadian regulations, UK rules, and emerging frameworks in other jurisdictions are not harmonised. A feature that's legal in one jurisdiction may be restricted in another. Global businesses face this every release.

The mitigation: compliance-by-jurisdiction mapping. For each AI feature, know which jurisdictions it's exposed to (based on user geography) and which rules apply. For Pattern 3 orgs (L2.1), this is a governance function responsibility. For smaller orgs, it's usually the platform team lead's job to flag features that cross jurisdictions where the rules materially differ.

Risk 4: Liability for autonomous agent actions

For organisations shipping agentic AI features (Course 2 B4.2 territory), the liability model is still evolving. If an agent takes an action — schedules a meeting, sends an email, updates a database record, executes a trade — that causes harm, who is liable? The 2026 answer is "probably you" with significant caveats. Courts and regulators are still working out the exact boundaries.

The mitigation: limit agentic features to low-stakes, reversible actions in 2026. Bet on agents for read-only tasks, draft generation, and recommendations. Avoid agents that directly execute financial transactions, legal commitments, or irreversible customer-facing actions without human confirmation. This is a conservative posture and it's the right posture until the liability framework stabilises.

---

The failure mode: "legal can't keep up"

The specific leadership failure mode in this space: treating legal as a blocker to ship around rather than a partner to brief. The pattern:

• Engineering builds AI features at frontier-velocity pace.
• Legal is asked for review at the last minute before launch.
• Legal surfaces compliance concerns that require rework.
• Engineering pushes back ("we need to ship"), legal holds firm ("this is a real exposure"), leadership is caught in the middle.
• Launch slips, team frustration grows, the next feature tries to route around legal by not telling them.
• The company accumulates legal debt that eventually hits a visible incident.

This fails because legal is treated as an approver at the end rather than a partner from the start. The fix is cultural and procedural:

The defence: bring legal into AI feature spec reviews, not just launch reviews. Give legal a named owner for AI-related compliance questions (often the same person who owns the vendor inventory). Treat the five questions from this briefing as standing items in your quarterly leadership meetings, not as one-off exercises. Legal teams that are looped in early find the concerns cheaply; legal teams that are looped in late find them expensively.

The specific test for your own org: when an engineer or PM starts thinking about a new AI feature, at what point does legal get involved? If the answer is "when the feature is ready to ship," you have the failure mode. If the answer is "during spec review, before any code is written," you have the working pattern. Teams with the working pattern ship AI features faster on average because they don't accumulate compliance debt that surfaces under deadline pressure.

---

What to decide on Monday

• Schedule a 20-minute meeting with your GC to run through the five questions. Prepare the answers in advance; the meeting is for confirming and identifying gaps.
• Produce the AI vendor inventory this week. One-page table with six columns. Assign ownership (typically your platform team lead) and review cadence (quarterly).
• Audit your features for "decisions about identifiable individuals." If any qualify, start the human-in-the-loop compliance work now. It's cheaper than responding to a complaint later.
• Ask your GC for the IP indemnity matrix. Provider → you → customer, with gaps highlighted.
• Confirm that your AI incident response plan has a named owner, tested playbook, and pre-drafted comms. If any are missing, fix within a month.
• Run the annual no-training audit — platform team walks legal through pipelines.
• Bring legal into AI feature spec reviews, not launch reviews. Make this a standing process change.
• For agentic AI features, limit to low-stakes reversible actions until the liability framework stabilises.

Next briefing, L3.3, gets more specific about one corner of this risk surface: IP, data, and what your vendors are actually doing with your inputs. The specific questions to ask vendors about data handling, the recent case law that shifted 2026 vendor contracts, and the provisions you should negotiate into every new AI vendor agreement.

---

Course navigation

📚 AI for Leaders · Course Home — 15 briefings, four modules.

---

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