Who gets to decide? The CIO and the new architecture of enterprise authority

For most of my career, technology governance began with a familiar set of questions: Is the system secure? Is it resilient? Does it meet the architecture standard? Can we afford it? Those questions still matter. But they are no longer enough.

AI is moving rapidly from producing content and recommendations to initiating actions. It can route work, change code, approve exceptions, communicate with customers, trigger transactions and coordinate other systems. In that environment, the most important question may not be what the technology can do. It is who, or what, has the authority to do it.

That distinction is becoming urgent. Stanford University’s 2026 AI Index reports that 88% of surveyed organizations used AI in 2025, while deployment of AI agents remained in the single digits across nearly all business functions. The gap matters. Enterprises have gained broad experience using AI as a tool, but many are only beginning to understand AI as an actor inside an operating model.

I call the resulting challenge the enterprise authority gap: The distance between the speed at which intelligent systems can act and the enterprise’s ability to define, constrain and account for that action. Closing that gap will require more than an AI policy. It will require an architecture for decision rights.

The authority gap is becoming an operating risk

Traditional systems execute permissions. AI-enabled systems increasingly interpret intent. That is a fundamental change.

A conventional application may allow an employee to approve a payment up to a defined limit. An AI agent may evaluate the request, assemble supporting information, communicate with another system, recommend an exception and initiate the next step. Each individual action may appear legitimate. The combined sequence may create an authority that nobody explicitly granted.

I learned a version of this lesson long before generative AI. In banking and payments environments I led, the most consequential risks were rarely contained within one application. They emerged where business rules, identity, workflow, vendor dependencies and operational exceptions met. A payment platform could be technically sound and still create exposure if decision rights were unclear during an exception, outage or recovery event. The control was not simply in the code. It was in knowing who could act, under what conditions and with whose accountability.

AI compresses those seams. It can traverse data, applications and organizational boundaries in seconds. If the enterprise has not made authority explicit, the system will inherit whatever permissions, defaults and informal practices already exist. Automation then turns ambiguity into scale.

This is why I believe consequence, not activity, should set the control boundary. The same technical action can carry very different enterprise consequences. An agent rescheduling an internal meeting is not equivalent to an agent changing a customer credit decision, releasing software into production or moving money. Governance that treats all AI activity alike will either obstruct low risk work or insufficiently control high-risk work.

Regulators and standards bodies are already pointing in this direction. The NIST AI Risk Management Framework organizes AI risk work around govern, map, measure and manage, with governance operating across the lifecycle. The European Union’s AI Act requires high-risk systems to support effective human oversight, including the ability to monitor, interpret and override their operation. These are important foundations. For the CIO, however, the operating question remains practical: How are those principles translated into enforceable authority inside the architecture?

Build an architecture for decision rights

Enterprises need an enterprise authority architecture: A deliberate model connecting business decisions, human accountability, machine autonomy and technical enforcement. I would build it around four disciplines.

1. Define the decision before selecting the technology. Teams often begin with a model, platform or agent and then search for a use case. I have found the reverse sequence to be more durable. Start with the business decision or workflow being changed. Identify its economic value, affected stakeholders, existing control owner and consequence of failure. Only then determine whether AI should inform the decision, recommend an action or execute it.
2. Separate capability from authority. A system may be capable of completing a task without being authorized to complete it independently. That difference should be visible in design. I use a simple progression: observe, recommend, prepare, execute within limits and execute with exception authority. Moving from one level to the next should require evidence, not enthusiasm. Accuracy is one input, but so are reversibility, explainability, financial exposure, customer impact and recovery time.
3. Make authority technically enforceable. Policy statements do not stop an agent from calling an API. Authority must be expressed through identity, entitlements, transaction limits, segregation of duties, approval gates, runtime monitoring and kill mechanisms. Every consequential action should leave an attributable record: what the system knew, what rule it applied, what it did and which accountable owner accepted that operating boundary. This is where architecture and operations must reconnect. In several cloud and infrastructure transformations I led, we learned that control-plane resilience mattered as much as workload resilience. A service could be available while the organization had lost the ability to govern or recover it. The same principle applies to AI. An autonomous capability is not enterprise-ready if the organization cannot constrain it, observe it and reclaim control when the normal management path fails.
4. Measure the economics of authority. Leaders should move beyond model accuracy and unit cost to what I call liability-adjusted autonomy: the value created by delegated execution after accounting for oversight, error correction, compliance, recovery and potential harm. A faster decision is not automatically a better decision. If it increases the cost of exceptions, transfers hidden work to employees or creates an unbounded downside, the apparent productivity gain is misleading.

The measurement question should therefore be: What is our cost per successful, governed outcome? That connects technology performance to business value without pretending risk is external to the calculation.

Consider a fraud-alert workflow. AI may be highly effective at prioritizing cases, assembling evidence and recommending disposition. Those capabilities can reduce analyst effort and improve response time. But authority to block an account, decline a transaction or communicate suspected fraud to a customer carries a different consequence. The architecture should assign separate thresholds, evidence requirements and escalation paths to each decision rather than treating the workflow as one automation opportunity.

The same logic applies outside financial services. In healthcare, recommending a scheduling change is different from changing a treatment pathway. In manufacturing, predicting equipment failure is different from stopping a production line. In human resources, drafting a job description is different from filtering candidates. The relevant boundary is not whether AI is present. It is how much consequential authority the enterprise has delegated.

The CIO’s next mandate is enterprise authority

This mandate changes the CIO’s relationship with the rest of the enterprise. Decision rights cannot be owned by IT alone because the consequences do not remain in IT. Business leaders own outcomes. Risk and legal leaders interpret obligations. Security establishes trust boundaries. Human resources shapes workforce practices. Audit tests whether controls operate as intended. The CIO’s unique role is to make those responsibilities coherent and executable across the technology estate.

That work should begin with an authority inventory. Most organizations can produce an application inventory, and some can produce a credible AI inventory. Far fewer can show where machines influence or execute consequential decisions, which identities they use, which systems they can reach, who approved that reach and how authority is withdrawn.

I would ask every leadership team five questions. Which decisions are we allowing AI to influence? Which actions can it execute without human approval? What is the maximum consequence of a wrong or manipulated action? Who is accountable when several systems contribute to the outcome? Can we stop, reverse and reconstruct the decision within the time the business requires? If those answers are fragmented across policy documents, vendor configurations and tribal knowledge, the enterprise does not yet control its autonomy.

Boards should ask a related question. Are we governing AI as a portfolio of experiments or as a new distribution of enterprise authority? The first view focuses on investment, adoption and risk reporting. The second recognizes that AI can alter how the company makes commitments, treats customers, allocates capital and exercises judgment. That is a governance issue, an operating-model issue and increasingly a fiduciary issue.

My experience across architecture, operations, modernization and enterprise transformation has taught me that accountability cannot be added after scale. By then, the most expensive decisions have already been embedded in platforms, permissions and process design. Authority must be designed at inception, tested before deployment and monitored throughout operation. Human review at the end of a poorly bounded system is not meaningful oversight. It is often an expensive illusion.

The organizations that lead in the next phase of AI will not be those that automate the most decisions. They will be those that know which decisions deserve automation, what evidence earns greater autonomy and where human judgment must remain nondelegable.

The CIO has an opportunity to lead that transition. Not as the owner of every decision and not as the enterprise’s technology gatekeeper, but as the architect who connects intelligence to authority, authority to accountability and accountability to measurable value.

The next generation of CIO leadership will not be defined by how much intelligence the enterprise deploys. It will be defined by how wisely the enterprise distributes authority.