Who Is Accountable When AI Acts | AI Strategy

Enterprise AI is in production. Companies deploy it, employees rely on it and boards ask about it, while vendors sell agents and business units wire automations into tools they already own. Awareness stopped being the constraint some time ago; the harder thing to find now is control over what has been deployed.

A year ago an executive could spend a meeting debating which pilot to run. The harder question today is which systems already shape decisions, and who answers when those systems get something wrong, run up costs or reach customers without a clear owner.

Recent studies point at the same pressure. Stanford Human-Centered AI Institute (HAI)'s 2026 AI Index shows broad organizational adoption but limited agent use in most functions. A 2026 National Bureau of Economic Research (NBER) firm survey finds many companies running AI while the weekly executive hours spent on it stay modest. IBM's 2026 technology-leader study notes that CIOs and CTOs are held accountable for systems they don't fully control. Deloitte's 2026 agent survey finds mature governance rarer than experimentation, and McKinsey's 2026 trust survey records gains in responsible-AI maturity alongside continuing shortfalls in strategy, governance and agentic controls.

The strategic risk is having enough AI to create obligations without enough control to manage them.

Accountability rises faster than oversight

Successful technology waves eventually push responsibility toward the top of the organization. A tool begins as a convenience, dependence on it grows, and outside parties start relying on its output. At that point the organization often discovers that the named owner was given a budget line and an optimistic narrative, and no real way to oversee the system.

AI speeds this up because the same tool can draft, recommend and act. A spreadsheet macro could corrupt its own file. A deployed agent can reach tickets, invoices, customer messages, code and internal approvals, so a failure spreads much further, and an accountability model that does not widen to match exists only on paper.

Treating this as an IT inventory problem misses most of it. A tool list says nothing about which decisions a system affects. Procurement records will not tell you which employee connected a model to a workflow last Tuesday, and even a well-drafted compliance policy is no evidence that a business unit can halt a faulty automation before it reaches customers.

Where the control gap shows up

The control gap is the distance between what the company must answer for and what it can actually observe, govern, fund, reverse or explain. It appears in the same places again and again.

Control area	What breaks	Owner question	Minimum control
System Visibility	Teams deploy assistants, agents, prompts, connectors, and vendor features faster than central teams can see them.	Which AI-enabled workflow is live, and who knows it exists?	A living registry by workflow, model or vendor, data class, business owner, and deployment state.
Action Authority	AI moves from suggestion to action without a matching authority boundary.	What can the system read, write, send, spend, approve, or change?	Permission tiers, human checkpoints, revocation paths, and audit records for each action class.
Financial Exposure	Usage grows through tokens, retries, long context, agent loops, and premium model defaults before value is measured.	Who owns the AI bill, and what business result justifies the run rate?	Budget caps, model-routing rules, unit-cost dashboards, and value milestones before scale.
Incident Response	Failures are corrected manually but not converted into system changes, stop rules, or doctrine.	Which incident would force a pause, downgrade, or redesign?	Severity definitions, response owners, containment time targets, post-incident learning, and release gates.
Business Accountability	Technology leaders inherit risk while business units keep the benefit narrative.	Which executive owns the workflow outcome, not just the tool?	A named business owner, technical owner, risk owner, finance owner, and final stop authority.

Why manual governance fails

Committees, approvals, policy pages, human review and spreadsheet trackers are reasonable at the pilot stage. They weaken once agents multiply and the number of small decisions outruns the attention people can give in occasional bursts. Someone can still approve a vendor. The same person cannot review every retrieval, tool call and retry across hundreds of workflows that run continuously, and pretending that they can produces false comfort.

People remain essential, but their authority has to be exercised at specific decision points. Executives do not need to inspect every output. They need to decide which classes of action require review, which incidents trigger a shutdown, which costs need approval, which data stays off limits and who in the business owns each outcome.

Those decisions have to be built into the systems where the work happens: identity, access, logging, model routing, approval steps, cost ceilings, release gates and incident records. A quarterly policy deck cannot enforce any of them.

AI spending hides in usage

The gap is a finance problem as well as a safety one. IBM's 2026 study shows AI taking a larger share of IT budgets while many technology leaders still lack real-time visibility into that spending, which gives CFOs good reason to get involved.

Traditional software spend shows up as seats, contracts and renewals, whereas AI spend leaks out through usage: extra prompts, longer context, retries, pricier models and overlapping subscriptions, each small until a workflow becomes routine. By then the bill reflects a new way of operating, which is much harder to change than a model invoice line renegotiated once a year.

Price each workflow before expanding it; cutting AI funding across the board is usually a poor first move. Support agents that close costly tickets may justify premium inference, and generic summarizers often won't. Compliance workflows may need expensive logging and review, while brainstorming tools may need a cheaper tier and a hard cap. With an accountability table, these stop being internal arguments and become budget decisions someone can defend.

Controls decide which uses can reach serious work

McKinsey treats AI trust as something that enables the business, and I think the framing holds up. Trust comes from deployment choices, and it determines whether a company can put AI into higher-stakes work without improvising a new emergency process each time.

Companies with weak controls can still run plenty of pilots. What they struggle to do is move into consequential workflows, because every new case reopens the same concerns about data exposure, bad outputs, unclear accountability, cost growth, regulatory exposure and reversibility, and those concerns get louder as the stakes of the use case rise.

Good controls also make it easier to say yes or no. A narrow agent with a defined scope of action, a known owner, a cost cap and an incident plan can be approved. A broad assistant that sees too much, acts too freely and leaves no measurable record can be rejected, and the narrow agent can then scale without anyone mistaking the broad one for strategy.

What executives should do first

Start with the ten AI-enabled workflows most likely to have external, financial, legal, security or customer consequences, and leave the ten flashiest demos for later. For each one, fill in the accountability table: visibility, action authority, financial exposure, incident response and business accountability. Then give each workflow one of four statuses:

Green: controls match the consequence, so the workflow can scale.
Yellow: it continues under a cap while the missing control is added.
Red: stop or shrink it, because the company cannot manage the downside.
Grey: there is too little visibility to classify it. That is itself a control failure and gives no grounds to keep shipping.

The result is a shorter AI roadmap. Work with adequate controls goes ahead, and work whose benefit does not justify the uncontrolled obligation pauses. Some work has to be rebuilt around a different model, vendor, data scope or human handoff before it earns another quarter of budget.

For the next phase, control has to stay ahead of accountability, and in practice that means keeping a sheet. Any system that can affect customers, money, compliance, security, employee work or institutional memory belongs on it. If it cannot be seen, bounded, priced, stopped and owned, it should not become infrastructure, however good the demo looked.