You Can Outsource AI Development, but You Cannot Outsource Accountability

Buying an AI capability can transfer development work. It does not automatically transfer responsibility for what that capability does inside your business.

M. Alejandra Parra-Orlandoni and Paulo Carvão raise this issue in their Harvard Business Review article, You Outsourced the AI, but You Still Own the Risk, published on 9 July 2026. Its publicly accessible summary highlights the legal and operational exposure that can accompany third-party AI, even when the deploying company has limited visibility into the underlying model.

This is independent practitioner commentary prompted by that summary, not a reproduction of the subscriber-only article or an HBR endorsement. My argument is that enterprise AI accountability needs an operating model, not just a contract.

The organisation choosing where AI enters a customer journey must understand its authority, identify who owns the outcome and ensure that failures can be detected and corrected. Those decisions remain important whether the technology is built internally or supplied by someone else.

Outsourcing technology is not the same as assigning responsibility

An enterprise AI service may involve a model provider, a software vendor, a cloud provider, a systems integrator and several internal teams. Each contributes something different. A model generates outputs. Software connects those outputs to a workflow. Infrastructure hosts data and execution. An integrator configures the service. Business teams decide what it should achieve.

Responsibilities should therefore be mapped rather than collapsed into a single label such as “the AI vendor”.

A supplier may owe contractual commitments around availability, security, processing or defects. An integrator may be responsible for agreed implementation work. Internal teams may own policy, customer communications and approval decisions. Legal obligations and liability depend on the activity, jurisdiction, contractual terms and parties involved. Suppliers are not automatically exempt, and the enterprise is not necessarily the only liable party.

But shared responsibility can still become operational confusion. When a customer is harmed, somebody needs authority to stop the workflow, investigate what happened and organise remediation while contractual questions are resolved.

I would establish that authority before launch. A service-level agreement cannot substitute for an internal owner who understands the business consequences of the system.

Autonomy changes the control requirement

There is a meaningful difference between an assistant answering a question and an agent acting on that answer.

A proposed response can be checked before it reaches a customer. An executed instruction may change a record, issue compensation or initiate another workflow before anyone reads the explanation. Several individually modest actions can also accumulate into a consequential outcome.

Not every agent is autonomous. Some only retrieve information or draft suggestions. Others operate within tightly defined permissions. Governance should follow the actual capability, not the product label.

My preferred starting point is to specify what the system may observe, recommend and execute separately. Then define approval thresholds, action limits, audit trails and escalation routes for each level.

This is a planning aid, not a universal risk classification. A seemingly simple recommendation can be high impact if it affects access to an essential service. The consequence matters as much as the number of steps.

Three hypothetical customer-service failures

The following scenarios are hypothetical illustrations, not accounts of client deployments. They show why chatbot accuracy alone is an incomplete measure of operational readiness.

A. A confident answer about the wrong entitlement

Imagine a customer asks whether cancellation is permitted without a charge. An assistant retrieves an outdated policy and supplies a confident answer that does not apply to the customer's contract.

The immediate issue is incorrect information. The underlying ownership questions are broader: who maintains the knowledge source, who defines which contract takes precedence, and who approves how uncertainty is communicated?

A useful response policy would require the assistant to identify relevant conditions, avoid unsupported assurances and escalate ambiguous cases. The organisation also needs a correction process when an incorrect answer has already influenced a customer's decision.

That process should protect the customer rather than simply amend the knowledge base. Business and legal teams may need to review the consequences of the information supplied. Better retrieval does not, by itself, settle those consequences.

B. A complaint that disappears into the wrong queue

Imagine an AI service categorises complaints, recommends priority and suggests resolution routes. It mistakes a vulnerable customer's urgent complaint for a routine enquiry and sends it to a low-priority queue.

The text classification might look plausible in isolation. The service outcome could still be unacceptable: an escalation is missed, a deadline passes, or customers using less familiar language are consistently deprioritised.

I would assign ownership of the routing policy to the relevant service team, with compliance input where needed. Test cases should include ambiguity, repeat contacts, language variation and signals that require escalation. Mandatory deadlines should be enforced independently of a model's interpretation.

Monitoring should examine who waits, which cases are rerouted and whether human reviewers can recover a misclassified complaint. A queue allocation is a business decision, not merely a convenient AI label.

C. An authorised action with an inappropriate result

Imagine an agent can update customer records and issue compensation for approved service incidents. It receives a request containing misleading instructions and attempts to apply a credit beyond the intended limit.

The agent may possess valid credentials while the proposed transaction remains invalid. Authentication answers who is acting; it does not establish that every action is appropriate.

Controls should validate account identity, incident eligibility, permitted fields, transaction limits and cumulative compensation. Higher-value actions can require a separate approval. Record updates should be traceable, and retries should not duplicate a payment or credit.

The relevant outcome measures across these scenarios include resolution quality, repeat contacts, escalation accuracy, compliance and customer harm. Containment rate or reduced handling time can conceal a service that answers quickly but resolves poorly.

Keep business rules outside probabilistic judgement

I do not think responsible deployment requires abandoning AI. It requires being precise about which work benefits from probabilistic interpretation and which work needs enforced rules.

AI can interpret an enquiry, assemble evidence, recommend a next step or coordinate a sequence. Deterministic services should enforce permissions, eligibility conditions, transaction boundaries and other non-negotiable constraints.

For example, a model might propose a service credit with supporting evidence. A separate transaction service can verify the account, consult the applicable policy, calculate the permitted amount and reject an unauthorised request. The model's explanation should not be its own authorisation.

This hybrid architecture also makes responsibility easier to inspect. Business teams own the policy. Engineering owns its implementation. The model contributes interpretation without becoming the sole source of truth about what is allowed.

The agentic AI control plane explores the execution boundary in more detail. Here, the organisational question is equally important: who can change that boundary, and what evidence must justify the change?

Embed governance throughout the lifecycle

Governance should influence selection, integration, operation and improvement. Purchasing a governance feature is not the same as running a governed service.

I would expect a proportionate deployment plan to address:

• Access: least privilege, scoped credentials, tenant isolation and explicit separation between read and write authority.
• Data: minimisation, classification, retention, residency requirements and clarity about what leaves the enterprise boundary.
• Change: evaluation of model and version changes before wider release, with a record of the configuration actually used.
• Knowledge: named owners, authoritative sources, freshness expectations and a route for correcting conflicting information.
• Execution: validation outside the model, transaction and spending limits, approval thresholds and safe handling of retries.
• Evidence: useful traces, tool-call records and audit trails, with access and retention controls for sensitive content.
• Intervention: humans with time, context and authority to challenge a recommendation or stop an action.
• Recovery: containment, independent suspension, rollback where feasible, incident response and customer remediation.

Prompt instructions can express policy, but they are not technical enforcement. Telling an agent not to exceed a spending limit is different from refusing the transaction at the execution layer.

Equally, a human approval button does not create meaningful oversight if the reviewer lacks the evidence, expertise or time to assess the decision. Controls need to be usable under ordinary workload and during incidents.

None of these measures makes AI risk-free. Their purpose is to constrain exposure, make decisions inspectable and support recovery.

Treat vendor due diligence as an ongoing activity

The initial supplier assessment should establish what is being purchased and which dependencies sit behind it. I would ask concrete questions rather than accept a broad claim that the product is “enterprise ready”.

Where is data processed and hosted? What is retained, and can inputs or outputs be used for training? Which subprocessors participate? How are model changes communicated? What evaluation evidence and audit access are available? How are security incidents reported?

For agentic capabilities, I would also ask whether permissions can be restricted by action and tenant, whether execution limits are enforced outside the model, and whether the enterprise can suspend the service independently.

Contracts should reflect the answers through appropriate commitments, notification provisions, responsibilities and remedies. Legal and procurement specialists should assess the terms relevant to the actual use case.

However, assessment cannot end at signature. A supplier may change a model, add a dependency or alter an integration. The enterprise may expand the workflow beyond the original scope. Both can change the risk without changing the product name.

Reassessment should therefore be triggered by material changes and incidents, alongside scheduled reviews. Supplier evidence supports the enterprise's decision; it does not replace evaluation of the integrated service.

A six-dimension accountability framework

I would organise the operating model around six dimensions. This is my practical structure for connecting business responsibility to delivery decisions, not a legal compliance standard.

1. Ownership

Name the business owner, technical owner and supplier responsibilities. Identify who accepts residual risk, approves changes, handles customer consequences and can suspend the service. An ownership chart should lead to an available decision-maker, not only a committee.

2. Risk classification

Assess the potential impact of wrong answers, inappropriate actions, data exposure and unfair treatment. Consider reversibility and affected people. A low-impact internal draft, a customer-facing recommendation and an account-changing workflow should not receive identical oversight.

3. Control design

Translate the classification into permissions, approval thresholds, validation rules and recovery mechanisms. Specify the evidence that each control should produce. If a consequential action has no enforceable boundary, a policy document is not sufficient.

4. Validation

Evaluate the integrated workflow against normal cases, exceptions, misuse and failure conditions. Include domain specialists and test the handover to humans. Define release criteria before seeing the results. My article on AI agent evaluation develops the testing discipline.

5. Monitoring

Track customer outcomes as well as technical performance. Set thresholds for investigation and suspension, and make alerts somebody's responsibility. Preserve enough evidence to distinguish a knowledge problem from a model, integration or policy failure.

6. Continuous improvement

Feed incidents, complaints, policy changes and supplier updates into controlled changes. Re-evaluate before expanding authority. Update the knowledge base, controls and ownership model together rather than repeatedly patching prompts around a recurring operational problem.

Apply these dimensions proportionately. Low-impact drafting may need lightweight sampling and review. Medium-impact recommendations may require stronger evaluation and escalation monitoring. High-impact execution may warrant independent validation, restricted rollout and tighter approval boundaries. The organisation should define those bands for its own context.

The voluntary NIST AI Risk Management Framework is a useful wider reference for incorporating trustworthiness into design, development, use and evaluation. It is not legislation or a guarantee of compliance; the six dimensions above are my working arrangement, not a claim to reproduce NIST's framework.

Accountability can support commercial discipline

Clear ownership and controlled execution can make enterprise AI easier to assess and operate. Teams can agree where experimentation is acceptable, what evidence permits expansion and how a service will be stopped if outcomes deteriorate.

That clarity can support procurement decisions, more focused incident response and a credible discussion with customers about the service's limits. It may also reduce repeated disputes between business, engineering and suppliers about who should act.

These benefits are not automatic. Evaluation, monitoring and oversight consume money and time. Some use cases will not justify that investment, and conventional automation may remain the better choice.

I would judge governance by whether it enables a useful service within an acceptable risk boundary, not by the volume of documentation produced.

Let autonomy and accountability evolve together

Outsourcing can be a sensible way to obtain specialist capability. The mistake is treating the purchase as the final decision about responsibility.

Before extending AI authority, ask three questions: who owns the outcome, what prevents an unacceptable action, and how will the organisation detect and correct a failure?

Those answers should become more specific as autonomy increases. Contracts, technical architecture and organisational oversight need to evolve together.

The objective is not to promise that AI will never fail. It is to ensure that the business remains capable of understanding, controlling and responding to the technology it chooses to deploy.

Further Reading and References

• Harvard Business Review: M. Alejandra Parra-Orlandoni and Paulo Carvão, You Outsourced the AI, but You Still Own the Risk, 9 July 2026. The introduction refers to the publicly accessible summary; the full article is subscriber-only. This commentary is independent and is not endorsed by HBR or its authors.
• NIST: AI Risk Management Framework. Voluntary risk-management guidance, not legislation. NIST's overview also notes that AI RMF 1.0 is being revised.
• Related on this site: The agentic AI control plane, AI agent knowledge readiness and AI agent evaluation.
• Reading path: Agentic AI.