You Outsourced the AI—but You Still Own the Risk

Harvard Business Review · article · 2026-07-09 source ↗ Reader 🖥️

practical · HBR management article — a diagnostic-plus-prescriptive governance essay (four named 'traps', each with a 'What to do') — Practical: it prescribes governance action for executives deploying third-party AI, not a theory of AI. Written by Harvard Kennedy School senior fellows (Paulo Carvão et al.) focused on AI governance and policy. It reasons from a pattern of real lawsuits/enforcement to a set of managerial remedies; its claims are asserted and evidenced by case citations rather than defended analytically.

Structure

Key terms

• the deployer (vs the provider) / the middle layer
  The enterprise that integrates third-party AI into its workflows and puts it in front of employees or customers — the middle of a three-layer AI supply chain — which is where 'most operational decisions are made' and 'increasingly where liability falls'; the legal classification (deployer or provider) determines where compliance responsibility sits.
• upstream opacity / the upstream black box
  The deployer's structural lack of visibility into how a third-party model was trained, how it changes and how it fails — aggravated because AI is probabilistic, context-sensitive and drifts, and vendors' model cards/accuracy figures are built for research communities, not enterprise compliance.
• customization liability / the customization boomerang
  The principle that adapting a vendor model with your own data (fine-tuning, retrieval, white-labeling) shifts legal liability toward you — the 'default assumption should be that customization shifts liability toward you' — because it makes you look more like a provider than a mere deployer under unsettled doctrine.
• AI lock-in / the illusion of the 'off' switch
  The inability to switch AI providers because the model's behavior is woven into application logic — 'not simply stored in a portable data layer' — making deployments Jenga-like (the model a load-bearing piece); more acute than classic ERP/cloud lock-in and unmitigated by any interoperability/portability standard.
• portability
  The deployer's deliberately engineered ability to migrate a deployment to a different provider within a defined window — achieved through modular architecture, vendor-neutral data/retrieval/eval infrastructure, exportable formats, and contractual export/change-notice/termination rights; 'a matter of architecture and contract', NOT delivered by a protocol like MCP (which standardizes only the connection layer).
• regulatory fragmentation / the fragmentation fallacy
  The same AI system being simultaneously governed by divergent regimes (high-risk under the EU AI Act, auditable under NYC local law, unaddressed elsewhere), and the mistake of answering each new law with a separate reactive compliance track rather than a common foundation.
• common governance foundation (NIST AI RMF / ISO/IEC 42001)
  A single, standards-anchored risk-management program — identify high-risk systems, test, document, monitor, assign accountability — adopted as the baseline onto which each applicable regulation is mapped ('what does this add to our existing program?'); the standards structure risk across the lifecycle but are 'not a substitute for legal compliance'.
• existing doctrines
  Pre-AI legal tools — wiretapping statutes, anti-discrimination law, consumer protection, the Fair Credit Reporting Act, product-liability and agency theory — that courts and regulators are already using to reach AI harms, so 'framing AI risk primarily through the lens of AI regulation is looking at the right landscape with the wrong map.'

Propositions

• explicitIn the three-layer AI supply chain, the middle-layer enterprise that integrates and deploys AI bears legal and reputational accountability when the system harms end users — even for a model it neither built nor trained — because regulators and plaintiffs look first to the organization closest to the affected person.conf: high
  extendsAddy Osmani’s Post · p6 — Scales the individual 'own what you ship — the AI did it is not a defense' ethic to its organizational/legal form: accountability for outsourced AI is non-delegable and lands on the deploying enterprise, not the upstream builder.
  extendsResearch: Why You Shouldn't Treat AI Agents Like Employees · p6 — The legal/organizational instantiation of 'today's AI cannot be held accountable, so clear human ownership is always required': because the AI itself bears no accountability, regulators and courts assign it to the enterprise closest to the end user.
• explicitCourts and regulators are not waiting for comprehensive AI law; they are already reaching AI harms through existing doctrines — wiretapping statutes, anti-discrimination law, consumer protection, FCRA, product-liability and agency theory — so executives who frame AI risk primarily through the lens of AI-specific regulation are 'looking at the right landscape with the wrong map.'conf: high
• explicitdevelopedExposure 1 — upstream opacity: because third-party models are probabilistic, context-sensitive and drift while vendors rarely supply usable documentation of training data, failure modes and updates, the deployer inherits an unmanageable black box; the remedy is to build transparency requirements (intended use, training-data categories, limitations, test results, failure modes, material updates, compatible logs) into every AI contract and treat a vendor's inability to provide them as a procurement/governance risk, not a contracting inconvenience.conf: high
  extends ←Is Your AI Training the Competition? · p4 — That piece's 'Exposure 1' remedy is generic AI-contract transparency requirements (training-data categories, failure modes, etc.); this article identifies a specific additional contractual gap — the feedback carve-out clause — that a generic transparency requirement wouldn't close on its own.
• explicitExposure 2 — customization liability: adapting a third-party model with proprietary data (fine-tuning, retrieval, white-labeling) shifts liability toward the deployer because courts have no settled theory of responsibility (agency, product liability, discrimination, FCRA all apply differently) and standard vendor contracts leave the enterprise responsible for its own applications, data and deployment; therefore customization must be governed as a legal decision — documented deployer/provider classification and indemnities aligned to where risk originates — not an engineering one.conf: high
• explicit⚡ disputed & corroboratedExposure 3 — vendor lock-in: enterprise AI deployments are not truly modular but Jenga-like, with the model a load-bearing piece woven into application logic (every prompt, workflow, safety filter and evaluation metric calibrated to one provider), so AI lock-in is more acute than classic ERP/cloud lock-in, and with no interoperability/portability standard or regulatory floor the ability to simply switch providers is largely illusory.conf: high
  supports ←AI models can disappear overnight. Is your engineering team built to survive it? · p4 — The Mythos/Fable shutdown is a concrete, real-world instance of the 'AI lock-in is more acute than classic vendor lock-in' diagnosis in the other article's Exposure 3 — a model being withdrawn by government order, not merely deprecated commercially, is an even sharper version of the risk that proposition describes.
  extends ←Cloudflare Turns CI Pipelines into TypeScript Workflows · p4 — Extends the 'AI deployments are Jenga-like, deeply-woven lock-in' diagnosis from the model-provider layer to CI/CD tooling: a working @cloudflare/ci pipeline entangles Workflows, Sandboxes, Containers, Durable Objects and R2, the same multi-primitive binding pattern.
  extends ←Git real: AI agents aren’t just for solo developers anymore · p4 — Extends the general enterprise-AI lock-in claim (model woven load-bearingly into application logic, hard to exit) to the specific mechanism of team memory/accumulated context in coding-agent platforms.
  refines ←GitLab Duo Expands Self-Hosted AI Options Through Microsoft Foundry · p3 — The Jenga-lock-in thesis claims switching AI providers is largely illusory because the model is woven into application logic; GitLab's gateway architecture is offered as a structural counter-measure (feature-level model selection, swap without workflow rebuild) — but this document's own admission that self-hosting shifts real operational burden onto engineering teams, plus the catalogue/compatibility-matrix drift risk, qualifies rather than refutes how illusory-free that switching actually is.
  contradicts ←With Foundry, Microsoft bets the enterprise AI battle is about reliability, not capability · p7 — This article's implicit premise — that consolidating runtime, tools, memory, and governance inside one vendor's platform is what enterprise reliability requires — is in tension with the established claim that exactly this kind of deep, load-bearing coupling to a single AI vendor produces acute, largely illusory-to-escape lock-in for enterprises.
  extends ←Measuring AI's Unintended Consequences · p13 — Operationalizes that essay's Exposure 3 (Jenga-like AI vendor lock-in, diagnosed qualitatively) into a concrete economic model projecting the headcount/capability tradeoff a token-price increase would force.
• explicitestablishedThe counter to lock-in is to engineer portability deliberately — architect for modularity, keep data/retrieval/evaluation infrastructure vendor-neutral, ensure exportable formats, negotiate export rights/advance change-notice/termination provisions, and run periodic portability exercises — because portability 'remains largely a matter of architecture and contract'; MCP standardizes the connection layer but not the orchestration, prompts, evaluations, monitoring or governance built around it, so a protocol does not solve lock-in.conf: high
  refinesHoward Yu's Post — American AI models went from 70% of usage to 30% in 12 months · p4 — Refines that piece's 'distribution is sticky' claim by locating enterprise AI stickiness in the integration layer (prompts, workflows, safety filters and evals calibrated to one provider) rather than the router — where a model-string swap is cheap. So capturing the cost advantage of cheap commoditized models requires deliberately engineering portability, which doubles as a liability hedge.
  extends ←AI models can disappear overnight. Is your engineering team built to survive it? · p6 — Both prescribe engineering deliberate portability/abstraction as the hedge against vendor lock-in; this article contributes the practitioner 'harness' vocabulary (tools, memory, data layer, permissions, prompts, routing, evaluations kept independent of the model) and the Claude Code 1.6%/98.4% codebase-composition statistic as concrete texture for the same abstract remedy — without resolving the other doc's own open question of whether portability is achievable enough to matter.
  supports ←Presentation: Clean Architecture for Serverless: Business Logic You Can Take Anywhere · p4 — Concretely instantiates the abstract 'architect for modularity, keep infrastructure vendor-neutral' hedge — applied here to cloud-infrastructure vendor lock-in via Clean Architecture layering and Gradle-enforced dependency direction, rather than to the AI-model vendor lock-in the other piece addresses.
  supports ←Cloudflare Turns CI Pipelines into TypeScript Workflows · p8 — Dagger's OCI-portable, vendor-neutral, content-addressed-cache design is a concrete real-world instance of the 'architect for portability deliberately' counter-strategy to lock-in.
  supports ←Git real: AI agents aren’t just for solo developers anymore · p6 — Devin Desktop's ACP-adapter-based 'neutrality' (not native integration) is a concrete instance of the claim that a protocol standardizes a connection layer without solving lock-in on its own.
• explicitExposure 4 — regulatory fragmentation: the same system can be high-risk under the EU AI Act, independently auditable under NYC local law and unaddressed elsewhere, and answering each new law reactively produces a fragile proliferation of parallel compliance tracks; because most regimes rely on the same underlying controls (identify high-risk systems, test, document, monitor, assign accountability), enterprises should build one common governance foundation and layer jurisdiction-specific requirements on top.conf: high
• explicitThe governance remedy is to adopt NIST AI RMF or ISO/IEC 42001 as the baseline and map each regulation onto it (asking 'what does this add to our existing program?' rather than 'do we need a new program?'), assign explicit written ownership for AI risk across procurement, legal, compliance and each business line, and be able to demonstrate — not merely assert — that humans can override or shut down critical systems, because regulators credit demonstrable risk programs and punish deployment without meaningful testing or oversight.conf: high
  supportsGoverning AI in the Cloud: A Practical Guide for Architects · p14 — Both conclude the hard part of AI governance is organizational: assign explicit, written ownership for AI risk across procurement/legal/compliance/business lines — 'ambiguity about who is responsible is its own form of liability' — not the technology.
• implicitdevelopedLoad-bearing premise: liability tracks proximity to the end user, not causation within the technical stack — the enterprise closest to the affected person is treated as the accountable party regardless of which layer actually produced the harm.conf: high
  extends ←What's an Orchestrator—and Why Does Software Need One? · p5 — O'Brien's 'on whose authority was this delegated intelligence operating' question is the individual-orchestrator-level version of the load-bearing premise that liability tracks proximity to the affected party/system, not technical causation.
• implicitestablishedLoad-bearing premise: portability is achievable enough, through architecture and contract, to function as a real hedge — the remedies presuppose an enterprise can meaningfully preserve the ability to switch providers.conf: medium
  supports ←Presentation: Clean Architecture for Serverless: Business Logic You Can Take Anywhere · p4 — The working live demo — the same business logic deployed unmodified to both AWS and Azure — is direct evidence that engineered portability is achievable at least at small scale, addressing a premise the other piece asserts as load-bearing but leaves unproven.
  supports ←Stranded in the Slow Zone · p7 — Confirms the load-bearing premise that portability can function as a real hedge in practice — though the portability that worked here was agent-tool portability, not architected model-agnostic modularity.

Arguments

Narratives

• Visitors to Peloton's website used a familiar third-party 'chat' widget; per a class-action complaint the vendor recorded, stored and reused those conversations to improve its ML models. Peloton neither built nor trained the system, yet a California federal judge allowed a wiretapping claim against Peloton to proceed (the parties later jointly dismissed on undisclosed terms).
  → The framing bookend of the whole piece — opens and closes it — dramatizing the thesis that the deployer owns the risk of AI it did not build, and turning an abstract accountability claim into a concrete courtroom exposure.
• A cluster of enforcement/liability cases where the deployer, not the AI provider, was pursued: the EEOC sued iTutorGroup (the employer) over an age-discriminating screening tool; the DOJ settled with an IT firm whose AI-generated job ads unlawfully excluded U.S. workers; Cigna and UnitedHealth face class actions over third-party AI in claims decisions; law firms were sanctioned for filings containing AI hallucinations.
  → Establishes the accountability-falls-on-the-deployer claim as a pattern rather than a one-off, across employment, advertising, healthcare and legal practice — evidence that regulators/courts look first to the deploying organization.
• A federal court let a discrimination claim against Workday proceed on the theory that it acted as an 'agent' of the employers using its hiring tools — despite contract language assigning hiring-decision responsibility to those employers; separately, Eightfold-style claims raise the risk that AI hiring scores count as 'consumer reports', pulling employers into FCRA obligations they never anticipated.
  → Illustrates the customization/agency mechanism by which liability crosses the vendor–deployer boundary in unpredictable ways, showing that contracts alone do not fix where responsibility lands.
• Rite Aid was banned by the FTC from using AI facial-recognition technology after deploying it without meaningful testing, risk assessment or oversight.
  → The negative exemplar for Trap 4's remedy — shows the concrete cost of deploying AI without a demonstrable governance program, motivating the NIST/ISO baseline and 'show, not just say'.

Questions addressed

• ✅ When an enterprise deploys AI it did not build, who bears the legal and reputational liability if that AI harms someone?
  The deploying enterprise — the middle layer of the AI supply chain, closest to the affected person — does, via existing doctrines (wiretapping, anti-discrimination, consumer protection, FCRA, product-liability, agency), regardless of who built or trained the model.
• ✅ Which AI risks are enterprises systematically failing to manage?
  Four: upstream model opacity, customization liability, vendor lock-in, and regulatory fragmentation — 'most organizations are not managing these deliberately.'
• ✅ What should a leader actually do to reduce exposure?
  Build transparency into AI contracts; govern customization as a legal (not engineering) decision; architect and contract for portability; and anchor compliance in a common NIST AI RMF / ISO 42001 foundation with explicit written ownership and demonstrable human override.
• ⭕ Given the article's own 'Jenga' description of AI lock-in, is the prescribed portability actually achievable — and at what cost?
  Left open. The piece prescribes 'architect for modularity' and 'run a periodic portability exercise' while simultaneously conceding deployments are Jenga-like and that MCP leaves orchestration/prompts/evals/governance to rebuild; it never reconciles the prescription with its own account of how deep the lock-in runs, nor prices the hedge.

Gaps

• incompletePortability realism vs. the article's own lock-in. Trap 3 both diagnoses AI lock-in as Jenga-deep (the model woven into application logic; MCP standardizes only the connection layer) and prescribes 'design for portability' as the hedge — without showing portability is achievable enough to matter, what fraction of the stack actually migrates, or what the hedge costs. The load-bearing 'portability is a real hedge' premise is asserted against the section's own caveats.
  Read next: Switching-cost / moat analyses specific to AI stacks; total-cost-of-ownership of vendor-neutral architecture; how much of orchestration/prompts/evals actually survives a provider swap in practice.
• incompleteOpen-weight / self-hosted AI is never distinguished from closed-API AI, yet it changes every exposure. Running open-weight models on infrastructure you control can dissolve upstream opacity (you can inspect and pin the weights), collapse lock-in (the weights are portable), and shift the deployer/provider line — but the piece treats 'third-party AI' as a monolithic closed-vendor relationship and never asks whether self-hosting is itself a structural remedy to Traps 1 and 3.
  Read next: Open-weight adoption and the engine-vs-car (harness) question; self-hosting economics and governance; data-sovereignty / on-prem deployment as a lock-in and opacity mitigation.
  closed byAI models can disappear overnight. Is your engineering team built to survive it? — That gap asked whether self-hosted/open-weight AI (vs. closed-API AI) is itself a structural remedy to lock-in and opacity, a question the other article never raised. This article's p10 (Keus/GreenPT) explicitly answers it: open-weight models let a company self-host, switch, audit, and fork without rebuilding infrastructure — though the answer here is only a single interested party's testimony, not a systematic analysis, so the gap is addressed rather than fully closed with evidence.
• incompleteSMB-vs-large-enterprise asymmetry is unaddressed. Every remedy — negotiate non-standard contracts and enforceable custom indemnities, run a per-project legal deployer/provider classification, build vendor-neutral architecture, adopt and maintain a NIST/ISO program — presupposes negotiating leverage against frontier vendors and a standing legal/compliance capacity that large enterprises have and smaller deployers do not. The piece prescribes to an implicit large-enterprise reader without saying who can actually execute this.
  Read next: Procurement leverage of small vs. large AI buyers; whether standards-based governance is feasible below enterprise scale; managed/off-the-shelf governance as an alternative to build-your-own.
• incompleteInsourcing is never weighed as the deeper remedy. The article accepts outsourced AI as the default and manages its risk downstream, but never considers building and owning the capability (or the data/eval/governance layer) as an alternative that would dissolve several exposures at once — opacity, customization-liability ambiguity and lock-in all shrink when the enterprise, not a vendor, owns the model or the surrounding stack.
  Read next: Insourcing vs. buy-and-govern trade-offs; owned AI capability (token capital) as a hedge; when repatriating capability beats contracting around a vendor's risk.

Closes gaps elsewhere

• Howard Yu's Post — American AI models went from 70% of usage to 30% in 12 months · g4 — That gap flagged 'distribution is sticky' as asserted with no mechanism and asked for a contrast against genuinely sticky layers (fine-tuning, workflow lock-in, owned data). Trap 3 supplies the mechanism: enterprise AI lock-in is acute because the model's behavior is woven into application logic — every prompt, workflow, safety filter and evaluation metric is calibrated to one provider — so switching is Jenga-like, not the low-cost model-string change a router marketplace implies.

Related documents

• Howard Yu's Post — American AI models went from 70% of usage to 30% in 12 months
• Research: Why You Shouldn't Treat AI Agents Like Employees
• Addy Osmani’s Post
• Building AI Agents For The Enterprise
  Agent Governance (Internal) Enterprise AI Adoption & Readiness MCP (Model Context Protocol) Moats & Defensibility
• Entur AS' innlegg — KI-løypa: Slik vurderer og innfører vi KI-verktøy i Entur
  Agent Governance (Internal) AI Regulation & Governance (External) Enterprise AI Adoption & Readiness
• An Evolutionary Architecture Pattern for Managing AI's Pace of Change
  Agent Governance (Internal) Enterprise AI Adoption & Readiness MCP (Model Context Protocol)
• Governing AI in the Cloud: A Practical Guide for Architects
  Agent Governance (Internal) AI Regulation & Governance (External) Enterprise AI Adoption & Readiness
• Kin Lane on AI and the Future of APIs
  Enterprise AI Adoption & Readiness MCP (Model Context Protocol) Moats & Defensibility
• AI Model Context Protocol Adds Centralised Auth for Enterprise
  Agent Governance (Internal) Enterprise AI Adoption & Readiness MCP (Model Context Protocol)
• Responsible AI Is Becoming a Growth Strategy
  Agent Governance (Internal) AI Regulation & Governance (External) Enterprise AI Adoption & Readiness