Who decides? The CIO's new mandate to govern AI authority in the enterprise

The article, written by Rajjie Sarmey — a technology executive with a career as CIO, CTO and chief architect in banking, financial services and telecommunications (Zions Bancorp, PNC Bank, QCR Holdings, the Federal Reserve, Bell Labs, AT&T and Verizon) — argues that classic technology governance has fallen short in the face of an AI that no longer merely recommends, but acts: it can route work, modify code, approve exceptions, communicate with customers, trigger transactions and coordinate other systems. Given that shift, he maintains that the central question is no longer what technology can do, but who — or what — has the authority to do it.

The author cites Stanford University's AI Index 2026 to illustrate the scale of the problem: 88% of the organizations surveyed used AI in 2025, while the deployment of AI agents remained in single digits across almost every business function. That gap — between adopting AI as a tool and its actual role as an actor within the operating model — is what he calls 'the enterprise authority gap': the distance between the speed at which intelligent systems can act and the company's ability to define, limit and be accountable for that action. In his view, closing that gap requires more than an AI policy: it requires an architecture of decision rights.

Sarmey argues that traditional systems execute permissions, while AI systems interpret intent, which is a change in kind. He offers the example of an agent that assesses a payment request, gathers supporting information, communicates with another system, recommends an exception and initiates the next step: each individual action may look legitimate, but the combined sequence can create an authority that no one explicitly granted. Drawing on his experience in banking and payments, he notes that the most serious risks rarely sat within a single application, but arose at the seams between business rules, identity, workflows, vendor dependencies and operational exceptions; control did not reside in the code alone, but in knowing who could act, under what conditions and under whose responsibility. AI, he says, compresses those seams and can cut across data, applications and organizational boundaries in seconds, so if the company has not made authority explicit, the system will inherit the permissions, defaults and informal practices already in place, and automation will turn ambiguity into scale.

From this he draws a principle: it should be consequence, not activity, that sets the limit of control. An agent that reschedules an internal meeting is not the same as one that changes a customer's credit decision, releases software into production or moves money; treating all AI activity alike, he warns, either obstructs low-risk work or under-controls high-risk work. The author notes that regulators and standards bodies are already moving in that direction: NIST's AI risk management framework organizes the work around governing, mapping, measuring and managing, with governance operating across the entire lifecycle; and the European Union's AI Act requires high-risk systems to allow effective human oversight, including the ability to monitor, interpret and override their operation. Even so, he insists that the operational question for the CIO remains a practical one: how to translate those principles into enforceable authority within the architecture.

To that end he proposes building an 'enterprise authority architecture' organized around four disciplines. The first is to define the decision before choosing the technology: instead of starting from a model, platform or agent and then looking for a use case, he recommends starting from the business decision or workflow, identifying its economic value, the parties affected, who currently owns the control and the consequence of a failure, and only then determining whether AI should inform, recommend or execute the action. The second is to separate capability from authority: a system may be capable of completing a task without being authorized to do it independently, and that difference must be visible in the design. Sarmey proposes a five-level progression — observe, recommend, prepare, execute within limits, and execute with exception authority — and argues that moving from one level to the next should be based on evidence (accuracy, but also reversibility, explainability, financial exposure, customer impact and recovery time), not enthusiasm.

The third discipline is making authority technically enforceable: policy statements do not stop an agent from calling an API, so authority must be expressed through identity, access rights, transaction limits, segregation of duties, approval gates, real-time monitoring and kill switches. Every consequential action must leave an attributable record of what the system knew, what rule it applied, what it did and which owner accepted that operating limit. Here the author brings in a lesson from his cloud and infrastructure transformations: the resilience of the control plane matters as much as that of the service itself, because a service can be available even though the organization has lost the ability to govern or recover it; an autonomous capability is not enterprise-ready if the enterprise cannot constrain it, observe it and regain control when the usual management path fails.

The fourth discipline is to measure the economics of authority, going beyond model accuracy and unit cost toward what he calls 'liability-adjusted autonomy': the value created by delegated execution once oversight, error correction, compliance, recovery and potential harm are netted out. A faster decision is not automatically better if it raises the cost of exceptions, shifts hidden work onto employees or creates unbounded downside risk; that is why he proposes measuring the cost per successful, governed outcome, connecting technology performance to business value without externalizing risk from the calculation.

As a concrete example, he describes a fraud alert workflow: AI can be highly effective at prioritizing cases, gathering evidence and recommending a disposition, which reduces analyst effort and improves response time; but the authority to block an account, decline a transaction or tell a customer that fraud is suspected carries a different consequence, so the architecture should assign separate thresholds, evidence requirements and escalation paths to each decision, rather than treating the whole workflow as a single automation opportunity. He extends the same logic to other sectors: in healthcare, recommending a schedule change is not the same as modifying a treatment pathway; in manufacturing, predicting an equipment failure is not the same as halting a production line; in human resources, drafting a job description is not the same as screening candidates. The relevant boundary, he insists, is not whether AI is present, but how much consequential authority the company has delegated.

In the final section, Sarmey argues that this mandate transforms the CIO's relationship with the rest of the company: decision rights cannot be owned solely by IT because the consequences do not stay in IT. Business leaders own the outcomes, risk and legal interpret the obligations, security sets the trust boundaries, human resources defines employment practices and audit checks that controls work as intended; the CIO's specific role is to make those responsibilities coherent and executable across the entire technology estate. He proposes starting with an 'authority inventory' showing where machines influence or execute consequential decisions, what identities they use, what systems they can access, who approved that access and how authority is withdrawn, noting that many organizations can produce an application inventory, and some an AI inventory, but very few can answer those questions.

He therefore poses five questions for any leadership team: which decisions AI is allowed to influence; which actions it can execute without human approval; what the maximum consequence of a wrong or manipulated action is; who is accountable when several systems contribute to an outcome; and whether the company can stop, reverse and reconstruct the decision within the time the business requires. If the answers are scattered across policy documents, vendor configurations and tacit knowledge, he concludes, the company does not yet control its own autonomy. To boards of directors he puts a related question: whether they are governing AI as a portfolio of experiments or as a new distribution of enterprise authority, since the latter view recognizes that AI can change how the company makes commitments, treats customers, allocates capital and exercises judgment, which is simultaneously a governance issue, an operating model issue and, increasingly, a fiduciary one.

The author closes with the idea that accountability cannot be added after a system has scaled, because by then the most costly decisions are already embedded in platforms, permissions and process design; authority must be designed in from the outset, tested before deployment and monitored throughout operation, and he warns that a human review at the end of a poorly bounded system is not real oversight, but often an expensive illusion. In his view, the organizations that lead the next phase of AI will not be those that automate the most decisions, but those that know which decisions deserve to be automated, what evidence justifies greater autonomy and where human judgment must remain non-delegable. The CIO, he concludes, has the opportunity to lead that transition not as the owner of every decision nor as a technology gatekeeper, but as the architect who connects intelligence to authority, authority to accountability and accountability to measurable value; and the next generation of CIO leadership will be defined not by how much intelligence the company deploys, but by how wisely it distributes authority.