For most of the last three decades, the technology organization’s authority rested on something simple: it held capabilities nobody else had. If the business wanted software, it came to IT. That arrangement no longer holds. A marketing team can now assemble a working customer-facing prototype over a long weekend using three AI tools, including some IT never evaluated, and the CMO can demo it Monday morning.
The common reading of AI’s effect on technology organizations is that engineers got faster. The more consequential reading is that the entire enterprise has become more capable – in a survey of 20,000 knowledge workers, 58 percent of AI users say they now produce work they couldn’t a year ago. Many will build without much regard for the estate their work has to live in. Meanwhile, the technology organization is still measured by uptime and cost to serve and is increasingly held accountable for the sprawling portfolio of AI tools used across the organization. The growing risk is that the technology organization is circumvented altogether, and core technology decisions migrate to people who now feel technically capable of making them, even if they don’t have the necessary context.
As the AI landscape evolves and brings more people into the technology conversation at a record pace, the CIO’s role shifts to cut through the noise. The new mandate expands on leading a sound technology strategy to providing increased clarity, rigor and disciplined judgment on where AI can catalyze growth. CIO-led initiatives should focus on compounding enterprise growth through AI, rather than allow a series of expensive experiments that distract and add bloat to an organization already on overdrive.
What has shifted
Build capacity grew, shifting IT’s focus from velocity to value
Increased technical capability has enabled teams to generate significantly more output, but product management, design, governance and stakeholder alignment have not scaled at the same rate. The constraint moved from the ability to build to the ability to align on what to build. To address this, we have seen some organizations add product managers to help rationalize demand, while others push product judgment to engineering teams, which often resurfaces as a sequencing discussion. Sometimes companies do both simultaneously, a sign that the question was never settled.
Automation moved up the value chain but never resolved the accountability question
A 1979 statement widely attributed to IBM held that “A computer can never be held accountable; therefore, a computer should never make a management decision.” Fast-forward nearly half a century, and systems now generate options, run variations and analyze outcomes at a pace that would have taken a competent analyst days. What they cannot do is be accountable for the result. A model can produce the recommendation, but it cannot be the name on the decision when a regulator asks. The work does not disappear as automation climbs; it concentrates into deciding and answering for it. AI automation is a technology and data question first, and technology leaders are best positioned to determine which decisions a model can safely make.
The SaaS reckoning is an architecture problem before it is a cost problem
A decade of SaaS tool proliferation has left most enterprises with overlapping applications and fragmented data, and the instinct is to hand rationalization to procurement and bank the savings. That instinct is expensive right now because the same fragmented estate that inflates license spend also makes enterprise AI underperform. An agent is only as good as its ability to get a consistent answer about a customer, and in most estates, there is no consistent answer to get. The accumulation of new, uncoordinated AI solutions risks compounding tech sprawl on an already fragmented foundation.
Separately, each is a familiar problem. Together they change the altitude at which the CIO org operates. IT’s response shifts from determining when something can be delivered to whether it should be built. IT identifies which decisions can be automated and which should remain in a human’s hands. Finally, the CIO’s team maintains the integrity of the enterprise’s estate by governing the pathways through which it evolves.
What only technology can hold
As the entire enterprise becomes more technically capable, IT’s role evolves to coach and advise where teams should build and how. IT might decide to build most things, partner only on select initiatives or federate altogether – but IT should maintain the keys to what enters the technology estate. While prioritization, accountability and architecture are not new concepts for a CIO and their team, today’s environment requires a different approach.
1. Judgment about what is worth building
Scarcity used to supply the discipline: when engineering capacity was the limit, prioritization was resolved through the queue. When a perfectly reasonable series of viable requests arrives, each with its own sponsor and business case, someone must maintain a position on what is worth building. This is a fundamentally different question for technology leaders to answer, and it puts strategy and enterprise capability ahead of capacity or technical capability. A PMO can sequence a list of projects and perhaps flag dependencies, but it cannot usually flag system incompatibility or tell you that something already exists two systems over. Technology sees all of it, which is the vantage point the strategic portfolio question requires.
Cheap to attempt is not cheap to own. While build cost may collapse, the cost of running, securing, supporting and eventually retiring a thing is not, and it is paid every year afterward by a team that did not choose it. The question was never whether it could be built. The discipline that maintains the estate’s integrity is declining things that are individually reasonable. This was easier when the answer was that there was no capacity. Now a “no” must be a judgment about the request itself, and that is harder to do when a seemingly viable demo already exists. This is technology’s to own, because only someone looking across the estate can see where the sum of sensible local choices stops working.
What to do: Identify the decision types that gate the most work in your organization; these usually involve data access, exceptions to standards and production promotion. Establish the standards that inform the judgment, then empower a cross-functional governance forum to apply them consistently. While most enterprises have or plan to have a forum, only about half have a formal process for approving AI work. Define that process and hold the entire enterprise to that decision logic, whether the answer is yes or no.
In operating model work with large matrixed organizations, the measure that moves leadership is decision latency. No one team owns the delay, so it never lands on any single scorecard. Measure it end-to-end and put the number in front of the executives whose calendars it is on.
What to measure: median days from question raised to decision committed; share of proposals declined, because a forum that approves nearly everything is sequencing the queue rather than setting the portfolio
2. Governance as a lever for enterprise speed
Across many enterprises, we have found versions of citizen AI development already underway, and ungoverned, before anyone had decided whether to allow it. IBM’s 2026 breach research found the share of incidents involving shadow AI more than doubled in a single year. The CIO’s role is to ensure AI experimentation and development occur somewhere visible, on supported foundations and with measurable outcomes. A clear process in place, assets available for reuse and a track record of enabling speed and scale give the business a reason to come to you first.
That makes speed of commitment the thing to design for. Enterprise speed is now set by how quickly the organization can align and commit, and most companies treat that as culture when it is a property of the operating model. Reaction time is the version the business feels: having watched a function stand something up over a weekend, it measures technology from request to outcome against what it believes it could have done itself.
What to do: Establish clear tiering that governs use case development based on risk, security, architecture and data impact, and be explicit about what the business may build, with what data and what must come through technology. Most people only need to use what has been published, a smaller group configures from approved patterns, and an even smaller group still builds things that write to production systems. Each tier carries its own training and its own standard of accountability, which is also where the line sits between what a model can decide on its own and what needs a person’s name on it, which most organizations still could not demonstrate under audit. Tiering earns readiness rather than granting permission, so work moves into the appropriate lane instead of being gated on the same criteria.
Then make the sanctioned path the fastest one and stock it with a component library, reference implementations, pre-cleared connectors and evaluation harnesses. Guardrails alone will not hold the line, because a control the business experiences as friction is an argument for going around it. And none of it works on publication alone, so treat enablement as part of shipping the path.
What to measure: share of new business-built solutions running on the sanctioned path; share of new builds drawing on at least one published asset
3. The digital harness the enterprise builds on
When everyone across the business can build, the question stops being who writes the code and becomes what all of it runs on. Security, privacy, data quality, automated testing and observability used to be properties of individual systems, owned by whoever built them, which usually meant IT. They now must be properties of enterprise platforms, supplied centrally and inherited by default. A dashboard built on published data shouldn’t be governed by the same policy as an agent that writes to a customer record, but each needs a clear pathway to its intended impact. Architectural coherence is achieved here as well, so that the same customer identifier retains its meaning across dashboards and autonomous agents alike.
Without a harness, IT’s bottleneck does not disappear when the business starts building; it relocates. That prototype ready to demo on Monday waits three months for a security review, a privacy assessment, a data quality fix and someone to write the tests and monitoring nobody considered at the start of the effort. Technology becomes the constraint again, only later in the cycle, more visibly and with less goodwill than it had when the queue formed before anything was built.
What to do: Build identity and access patterns that apply to anything the business stands up, quality thresholds on the data domains that matter most, testing written on the assumption that some code was machine-generated, and observability covering agents as well as applications. Align this with the tiers identified in the governance exercise so that efforts are right-sized for the initiative. The same foundation should govern what you retire, because rationalization decisions should lighten the architectural overhead as well as the license bill.
Then, resource the harness appropriately. Keep a person where the call requires judgment or where someone must be answerable for it, and let the rest run. Review, not build, is the scarce resource now, and knowledge workers already rank it first among the skills AI makes more important. Finally, develop talent proactively for review, as the repetitive work that built that capability is now being automated. Organizations that leave that to talent strategy rather than to the operating model will find their bench thin in three years.
What to measure: share of AI solutions meeting the production-readiness bar by default; share of critical data domains with a single system of record that everything reaches the same way
Start by writing the mandate down
Most of what is above takes quarters to put in place, but one thing can be done this month. Write down what the technology organization owns, what it enables, what it orchestrates with peers and what it no longer does, then work with the rest of the executive team to generate buy-in. Reduce ambiguity about IT’s role wherever possible.
The old model was simple: marketing had an idea, and IT built it. The emerging unmanaged model is just as simple: marketing builds it, and technology is asked to make it safe afterward. The ideal target is different: marketing still builds it, but on IT-enabled foundations that make it safe, scalable and supportable.
In Microsoft’s 2026 Work Trend Index, organizational factors like culture, manager support and talent practices accounted for more than twice the reported AI impact of individual effort. The operating model will change either way, and what remains open is whether it changes by design and whether CIOs spend the coming decade shaping the enterprise’s AI agenda or executing someone else’s.