A LinkedIn post about my old company, insightsoftware, popped up the other day. It was lamenting the challenge of turning 29 acquisitions and close to 80 products into one comprehensive platform. I spent years in the middle of that work, and what I know now is how much harder that consolidation is than you might think, and how much of it you only learn by getting it wrong first.
So, when I arrived at Veson in November and found a similar landscape, I felt a bit of déjà vu. A bit of “I’ve done this before, so I know what I’m doing” and a bit of “I’ve done this before and I know it’s no cakewalk.” Veson had spent the past several years acquiring a range of products like Shipfix and VesselsValue and now needed to consolidate them onto a platform alongside its flagship IMOS solution. A new variable is also now at play that changes the whole equation: the advancement of AI.
While AI may sound like a cheat code for this work, it’s very much a double-edged sword… with a grenade taped to it.
Yes, we can do some things faster and differently than we ever could a few years ago. But we’re also learning as we go and upskilling our team as we go, on a technology that’s changing under our feet.
The newness of these tools multiplies the complexity in a way I didn’t fully appreciate at insightsoftware. Back then, the tools simply didn’t exist or were just emerging. Now your platform must transform so that it thrives in the age of AI. It has to be built in the age of AI, which — depending on whose study you believe — means anywhere from 2X to 10X faster.
And then your team needs to adapt to the age of AI, which again means faster, at higher quality and producing more output. That’s a lot of spinning plates, on top of each other, none of which you’re allowed to drop.
Oh, and one other plate: this is a centuries-old industry that moves billions of dollars in freight a year and does not stop for anyone. You don’t get to tie the ship up at the dock while you rebuild the engine. Business continuity, zero migration, no breaking the thing people are already running their business on. And do it as fast as you possibly can.
Building a connected, modern platform
At Veson we had a fleet, not a unified experience. A set of strong, separate hulls, each with its own data, its own experience, its own idea of the world. A collection of great products is not the same as a cohesive foundation, and pretending otherwise is a mistake. I’ve been guilty of this myself: combining products superficially, so they sit side by side under one roof but still behave as separate entities, rather than as one integrated experience.
In fairness to my past self, before AI even that superficial stitching was slow, labor-intensive and risky, and it often used up the time and budget we’d meant for real integration. AI has worn much of that cost away. The plumbing that used to take months now takes weeks, which frees us to focus on what customers value most: products that work as one.
A platform, in 2026, is three things stacked in order. A singular data layer underneath. One experience on top. And then AI that can reason across all of it. You cannot bolt credible AI onto a flotilla; it has nothing coherent to reason over. The unglamorous work of unifying data is what makes the glamorous AI work possible.
The part I’m most wary of talking about — because I would rather not tempt fate — is doing all of this safely. Moving fast on all fronts at once is a lovely thing to say in a strategy meeting and a dangerous thing to do in production. The mistake I’ve watched happen (and, if I’m honest, helped cause) is measuring efficacy too narrowly.
If you pick only a few metrics (that you know you can nail) and tell people that’s how they’ll be judged, teams will act accordingly. The side effects get ignored or missed until it’s too late. Often that side effect is quality, discovered downstream when it’s far costlier to fix, or market fit, because value was quietly descoped to hit a date. With AI coding agents accelerating everything, I wasn’t willing to repeat that. We needed 360-degree checks and balances.
The one thing I insisted on and set up from the first week with Veson was working with the engineering intelligence platform Plandek. We measure speed, quality, predictability and focus in real time, so we can see the progress we’re making and spot the side effects before they compound.
AI let us pick up the pace; comprehensive measurement is what lets us keep it without losing sight of the risk. As a result, we get to have our cake and eat it, we upskill the team while the ship is sailing.
Ten months in, here’s what we’ve learned so far.
Product lessons we’ve learned
Don’t rebuild what already works. “Modernizing” something people rely on is the fastest way to destroy the value you paid for.
AI only counts when it functions inside a workflow people already trust. An assistant in a corner nobody visits is a demo, not a product.
Aim for a minimum lovable product, not a minimum viable one.
Continuity is a feature. The moment a customer must “migrate” to your platform, you’ve lost them.
One source of truth beats five clever ones. Data you unify late is a tax you pay forever.
Experiences from our engineering teams
Adoption will be uneven. Don’t force the sceptics; convert them with proof.
The job itself is changing from writing code to directing it — reviewing, steering and trusting AI as it writes, then verifying.
Spread what works peer to peer. A network of AI champions beats a mandate from someone who clearly hasn’t done the work.
Measure everything.
The fastest teams are the ones who trust the platform beneath them.
Faster is only a win if quality holds — protect the gates hardest exactly when the pressure to cut them is highest.
I don’t think we’ve cracked the code on this. We’re in the middle of it, plates still spinning. But this time I’m making new mistakes rather than old ones, and I’m more convinced than ever that we’re doing this the right way.
The most expensive quantum mistake a CIO could make today may not be investing too early. It may be investing in the wrong capabilities, for the wrong reasons, without understanding the architectural and economic consequences.
Over decades of leading enterprise technology, architecture, modernization, and innovation in complex, highly regulated environments, I have seen a recurring pattern: technological enthusiasm advances faster than institutional readiness. Capital gets committed. Platforms become entrenched. Dependencies multiply. Business value remains difficult to demonstrate.
Quantum computing risks repeating that pattern, but with an important distinction: The cybersecurity consequences demand action today, while the timing and economics of broader commercial quantum advantage remain uncertain.
That is the strategic tension CIOs must resolve.
Quantum readiness and preparedness is not a race to acquire qubits. It is a discipline of protecting enterprise trust, preserving strategic options and directing scarce capital toward demonstrable value.
The fundamental question is no longer whether quantum computing deserves executive attention. It is whether CIOs and enterprises can distinguish what must be protected now, what deserves experimentation and what should remain an option rather than a financial commitment.
Two quantum clocks. One enterprise balance sheet
Quantum presents two fundamentally different timelines to a CIO.
The first is the security clock.
In August 2024, the National Institute of Standards and Technology (NIST) published its first three finalized post-quantum cryptography standards, establishing practical mechanisms for protecting information against anticipated quantum-enabled threats.
This is critical because cryptography is not an isolated cybersecurity component. It underpins identities, financial transactions, digital signatures, software integrity, communications, connected infrastructure and trusted business relationships.
A sufficiently capable future quantum computer could compromise certain widely deployed public-key cryptographic methods.
The October 2026 U.S. Government Accountability Office (GAO) report, Quantum Computing: Federal Actions Needed to Prepare for Emerging Cyber Threat, reinforces the urgency. None of the 24 federal agencies examined had fully addressed all three assessed preparatory practices for migrating vulnerable cryptography.
The lesson extends beyond government: you cannot migrate cryptographic dependencies you have not discovered.
The second is the commercial advantage clock.
Quantum computing may eventually offer meaningful advantages in selected areas of chemistry, materials science, simulation and optimization. But promising research does not automatically translate into repeatable enterprise economics.
IBM’s published quantum technology roadmap targets a fault-tolerant quantum system in 2029. That is an important technological ambition, not a guaranteed date for widespread commercial advantage.
These two clocks should not share the same investment assumptions.
Security readiness is justified by exposure and risk tolerance. Commercial adoption must be justified by demonstrated advantage and economic returns.
Confusing the two creates either dangerous underinvestment or speculative overspending for the CIOs.
Architecture before acquisition
The enterprise architecture challenge is more consequential than the quantum procurement question.
For CIOs, post-quantum preparation begins with initial understanding of where vulnerable cryptography exists across their enterprise, how it supports critical business services and whether those dependencies can be changed without destabilizing operations.
For example, consider a globally distributed financial institution.
Cryptographic dependencies may span payment platforms, customer identities, authentication services, certificates, mainframes, cloud environments, third-party APIs and decades of retained information.
Replacing an algorithm is not necessarily equivalent to replacing a library.
Some changes affect protocols, hardware security modules, certificate lifecycles, application compatibility, vendor contracts and operational resilience.
This demands cryptographic agility: the ability to replace or adapt cryptographic mechanisms without rebuilding the enterprise.
The same architectural discipline applies to future quantum workloads.
Enterprises should favor modular integration, well-defined interfaces, workload portability and interoperability across classical computing, high-performance computing, AI and emerging quantum services.
Quantum will not make classical computing obsolete. The more credible architectural direction is selective integration where a quantum capability demonstrably improves a specific computational outcome.
The architectural objective therefore is not quantum dependence. It is quantum optionality.
An enterprise should be able to adopt a useful breakthrough without surrendering control of its technology economics or becoming captive to a single provider.
The missing equation: Quantum workload economics
The quantum conversation becomes strategically meaningful when CIOs stop asking what a quantum computer can theoretically perform and start asking what business outcome it can improve.
The OECD’s 2026 research, Building Business Readiness for Quantum Computing, identifies barriers including technological immaturity, uncertainty surrounding business applications, access and training costs, and shortages of specialized expertise.
These are not simply engineering obstacles. They are capital allocation constraints. This means that a quantum experiment may demonstrate technical progress while failing to establish commercial value.
For example, a proposed optimization workload should be evaluated against competitive classical algorithms, realistic datasets, operational constraints and the full cost of execution.
The comparison must include more than processing time. It should consider problem preparation, data movement, orchestration, error mitigation or correction, integration, specialized talent, assurance and recurring operating expenses.
Even an impressive laboratory result may offer little economic benefit if the end-to-end enterprise workflow becomes slower, costlier or less dependable.
I would therefore introduce a more demanding investment metric: Cost per Trusted Quantum-Enabled Business Outcome.
This proposed measure evaluates the total attributable cost of achieving a validated business result, including the controls necessary to make that result operationally acceptable.
The denominator is not the number of quantum circuits executed. It is the number of useful, verified business outcomes delivered.
Where no defensible quantum advantage exists, the responsible decision may be to continue using classical computing.
That is not technological conservatism. It is capital discipline.
Introducing the quantum capital discipline framework
I propose a six-dimensional executive framework for separating quantum preparedness from quantum speculation.
Exposure: What must we protect?Identify vulnerable cryptographic dependencies, long-lived sensitive information, critical services and contractual or regulatory obligations. Prioritize remediation by business consequence, not technology fashion.
Relevance: What problem warrants quantum?Establish a specific business problem whose computational characteristics plausibly justify quantum investigation. Scientific curiosity alone is not an enterprise investment thesis.
Advantage: What evidence proves improvement?Demand reproducible comparisons against strong classical alternatives. Evaluate solution quality, performance, operational constraints and independent validation.
Architecture: Can we adapt without lock-in?Assess portability, integration complexity, vendor concentration, reversibility and the ability to change technology choices as the market evolves.
Economics: What is the full cost of value?Measure total lifecycle costs, opportunity costs, talent requirements and credible returns. Distinguish research expenditure from production investment.
Authority: Who decides to advance, defer or stop? Assign accountable decision makers, measurable milestones, investment thresholds and explicit exit criteria. Together, these dimensions form the Quantum Capital Discipline Framework.
Its governing principle is straightforward:
Capital follows evidence. Architecture preserves options. Governance owns consequences.
Importantly, this framework does not subject essential cryptographic remediation to the same commercial-return requirements as speculative quantum workloads. Security obligations and innovation opportunities require different investment justifications.
What boards should demand from their CIOs
Quantum strategy should enter Board discussions through enterprise risk, capital allocation, resilience and competitive positioning — not promotional demonstrations.
I would encourage directors and executive committees to demand answers to five key questions:
Which critical business services and information assets face material quantum-related cryptographic exposure?
Can we modernize vulnerable dependencies without unacceptable operational disruption?
Which proposed quantum applications outperform credible classical alternatives?
What evidence would justify expanding, delaying or terminating quantum investments?
Who is accountable for the financial, security and architectural consequences?
These five questions create a practical governance boundary between preparedness and speculation. They also expose a broader institutional weakness: enterprises often approve emerging technology investments without establishing the conditions under which those investments should be reconsidered.
Quantum requires a different approach.
Investment decisions should be revisited when technical capabilities, benchmark results, standards, security exposure or business economics materially change.
Boards should insist on measurable progress but avoid manufacturing artificial deadlines for breakthroughs nobody can reliably predict.
The CIO’s next mandate: Preserve the freedom to act
Quantum computing will not transform every industry simultaneously, deliver equal advantage across workloads or reward every early investor.
Some enterprises may eventually realize significant value from specialized quantum applications. Others may encounter quantum’s most immediate consequences through cryptographic modernization, technology dependencies and the protection of long-lived information.
Both outcomes demand leadership today.
The CIO’s responsibility is not to predict which quantum architecture will prevail or which vendor will dominate. It is to ensure that today’s decisions do not compromise tomorrow’s ability to compete, adapt and protect enterprise trust.
That requires investment discipline, architectural foresight, credible experimentation and accountable governance.
The next quantum advantage may belong not to the enterprise that invests first or spends the most, but to the one that knows precisely when to act, where to invest and when to walk away.
Quantum readiness is not measured by the technology an enterprise owns. It is measured by the strategic freedom it retains, the risks it responsibly reduces and the business value it can demonstrably create.
That is the difference between quantum enthusiasm and quantum leadership.
Quantum leadership is not about predicting when the future arrives. It is about architecting the freedom to embrace it, exercising the discipline to invest in it and preserving the authority to walk away when promise fails to become value.
Over many years of working through successive waves of enterprise technology and IT architecture, including fast-moving AI, I’ve heard the same question in different forms: “How can I build my business with AI while avoiding lock-in and tech debt?”
It came up again during a recent conversation about a major technology investment, when a CIO asked, “Should we really be making this commitment if the technology is changing constantly?” That resonated with me because it reflects a pattern I have seen across technology waves: the architecture must provide stability even as the capabilities around it continue to evolve.
For decades, the goal has been to build a technology foundation that serves the enterprise for five, seven or even 10 years. With the emergence of AI, some technologies become outdated before implementation is complete.
If shorter technology lifecycles are the challenge, adaptability is the answer. Instead of asking, “What will serve us for the next decade?” CIOs should ask, “How can we remain flexible as technology changes?” That requires being deliberate about what must remain durable and where the enterprise must be ready to adapt.
Think of it like a house. The foundation, walls and furnace are built to last, while paint, furniture and bathrooms change as needs and styles evolve. Enterprise architecture increasingly works the same way.
AI is separating the experience of work from the systems behind it
I recently heard about a company that now gives new employees a single onboarding tool: ChatGPT, connected to the enterprise systems and key data sources behind it. Instead of learning multiple applications, employees simply ask for the information or support they need, without knowing which underlying system provides it.
Of course, a single interface doesn’t mean blanket access to enterprise systems. This model requires security measures that ensure employees can access only the information and capabilities they’re authorized to use: carrying each employee’s identity and existing permissions through every request, limiting access to what’s necessary, tracking where information comes from, and logging retrievals and actions. Changes with significant business consequences should also require review.
This does change how we think about work and the technology that supports it. If agents are becoming the primary interface, the central question shifts from “Which application should employees use?” to “Can our data be accessed, understood and used securely by the interfaces and agents we adopt next?”
Adaptability means running at two speeds
Some technology capabilities should endure; others should evolve quickly. The mistake is treating everything as having the same lifecycle.
The durable layer includes ERP, HCM and other core systems, along with data, security and foundational architecture. These investments remain essential, but CIOs should design them around future business possibilities rather than solely around today’s processes.
The fast-moving layer comprises agents, interfaces, analytics, workflows, AI models and tools, experiments and business-specific solutions. The CIO’s role is to distinguish this layer from the durable core and ensure that rapidly evolving capabilities can be replaced without destabilizing the durable foundation.
CIOs need practical ways to change the underlying technology without disrupting the applications the business relies on. That starts with clear, consistent rules for how systems exchange data and interact with APIs, MCP connections and AI agents, keeping the implementation choices behind those boundaries. Before changing a model, agent or application, teams should confirm existing data and integrations will keep working, test security and expected behavior, and introduce changes in stages with a rollback plan if something goes wrong.
This two-speed model is a substantial departure from traditional enterprise IT management and from the way we did things when I was coming up in the tech world. It changes how CIOs plan investments, organize technology functions, structure vendor relationships and govern the connections between durable and fast-moving capabilities.
Invest thoughtfully for both durability and adaptability
In the pre-AI era, CIOs prioritized technologies with decade-long relevance. Today, they should avoid overspending on solutions prone to rapid obsolescence and invest in business outcomes and a durable foundation for intelligence.
Projects lasting more than six months warrant scrutiny: Will the solution remain relevant, or are we embedding processes that AI may soon handle; perhaps with a single prompt?
Durability extends beyond core systems to include the organization’s capacity to understand, evaluate and adopt new technology.
Today, most companies critically underinvest in skills. Knowing how to operate ChatGPT or Claude is not the same as working effectively with AI. OpenAI’s study found that AI power users outperform average users by sixfold. Upskilling gives CIOs leverage by helping employees redesign work and use AI effectively, while stronger leadership fluency facilitates new business models rather than merely supporting existing operations.
Most companies are also underinvesting in the data foundation. In West Monroe’s recent survey of 417 business leaders, AI governance, risk and compliance ranked as the lowest investment priority for the next 12 months. Traditionally, IT addressed data operations to ensure successful ERP implementation. Now, because data quality directly impacts AI value, investing in governance and accessibility is imperative.
CIOs need practices that preserve data meaning and reliability as platforms change. Those include assigning clear ownership, establishing authoritative sources and shared definitions, tracking data lineage and setting standards for quality and access. Definitions and rules should be maintained in portable documentation and data contracts, rather than embedding them in a single AI model or vendor platform, so they carry forward as technology evolves.
Break down IT silos to encourage adaptive architecture
Typically, CIOs organize operations around disciplines such as infrastructure, data, applications and security, with IT teams choosing an application and then defining processes and architecture around it. But as future architecture becomes less certain, CIOs must instead envision future business capabilities and design for change, bringing AI and data into architectural thinking alongside traditional cloud and application expertise.
Consider a reporting process that today moves from data analysis to Excel to PowerPoint to human review before a decision is made. An adaptive architecture focuses less on preserving each of those steps and more on the outcome: turning data into intelligence that informs a decision or action. Excel and PowerPoint may still have a role, but they no longer need to be hardwired into the process.
CIOs also need to break down silos. Teams often define architecture around a single suite, such as Salesforce or SAP, without considering alternatives. While working with an energy company recently, I saw how bringing analytics teams into the discussion shifted the focus from the ERP itself to how data should be accessed and used. Small, cross-functional teams can help create that broader view and design around business needs rather than individual platforms.
Build partnerships around future business outcomes
The most effective CIOs I work with are shifting their focus from simply controlling costs to driving value, actively partnering with the business, and reimagining how functions can evolve with AI, data and IT.
As vendor offerings expand across applications, analytics, agents and interfaces, CIOs need to balance integrated ecosystems with the flexibility to combine providers. Prioritizing open standards, multi-cloud support, data portability, interoperability and adaptable contracts can help organizations use the strongest elements of core systems while integrating agents and data across systems to adapt faster as needs evolve.
CIOs should build flexibility into vendor contracts, so changing providers doesn’t mean losing access to valuable data, context or governance rules. Contracts should provide for usable exports of data and metadata, documented interfaces that vendors keep current, advance notice of discontinued features, and support for testing portability and transitioning to another provider. They should also specify security and audit obligations throughout the relationship and during the transition.
The bottom line: buy with the future in mind. Don’t just ask if an application meets current requirements. Instead, envision what future business functions should look like, then derive technology needs from that vision. Shift the mindset from using HCM checklists to driving workforce optimization, from CRM checklists to revenue management, and from ERP checklists to enterprise data and intelligence.
Find the signal in the noise
As AI gets smarter and cheaper, the challenge will shift from affording it to connecting it to business outcomes. I believe the defining constraint in 2027 will be focus, not cost: CIOs must identify the few high-leverage priorities their organizations can absorb and execute well. That’s easier said than done.
There’s no established playbook for the AI era: we’re all experiencing it for the first time. CIOs face a flood of startups, models, architectural approaches, evolving standards, vendor claims and internal requests. The task becomes curation: deciding what deserves attention. Distinguishing signal from noise is becoming an essential leadership skill.
The new long game for CIOs
I believe CIOs are at a pivotal moment. They can remain excellent IT leaders or help the business rethink work through intelligence. In that sense, the role could evolve into what I call the chief intelligence officer: the leader who helps the enterprise turn fast-changing technology into durable business value.
The hype around AI agents and the models that power them is warranted. But while they can give organizations a real competitive advantage, in reality, how much value they deliver ultimately depends on something much less glamorous: the middleware and integrations that connect agents to systems across enterprise workflows.
Enterprises have used AI in various forms for decades, but agents represent a significant shift in how we put AI to work and what we ask it to do. The first phase of AI largely focused on generating, summarizing, analyzing and recommending information. Agents go a step further by executing actions and this is where the middle layer often gets overlooked.
Without the right APIs, MCPs, data streams, tools, deterministic logic, identity management and systems of record, agents and models essentially operate in a sandbox. As enterprises adopt agents into real-world workflows, the question CIOs need to ask isn’t simply, “Which AI agent should we deploy next?” It’s, “Can our enterprise faithfully support software action on our behalf?”
The model is becoming the commodity layer
After decades of leading a technology organization and countless implementations, I’ve seen firsthand how important it is to align technology with the business problems it is meant to solve. When it comes to AI agents, one of the biggest mistakes I see organizations make is setting unrealistic expectations for how a model will operate within their existing enterprise environment.
AI agents and models are often touted for what they can accomplish, which naturally focuses attention on their reasoning and execution capabilities. But we cannot simply layer them onto existing workflows and expect them to make decisions or take consistent, repeatable action reliably.
Financial services make for a great example of this. Think about an investing agent who evaluates companies using financial data. When they need it to calculate something precise, like a company’s cash burn ratio or runway, they don’t ask the LLM to do the math. Instead, they use a modern coding language such as python or node.js to perform deterministic analysis, then pass the results to the model to interpret their meaning in the broader context of the company.
As models continue to improve, the real differentiator isn’t the model itself, but what we engineer around them to turn their reasoning into trustworthy action.
The middle layer is where agents become enterprise software
For agents and models to deliver value outside a sandbox environment, they need connectivity to the enterprise systems supporting workflows. They also need to retrieve information from these systems, pass data between them and regularly execute actions within business-critical applications.
Think of the middle layer as the connective tissue between reasoning and execution. The difference between an agent that can answer questions using information you’ve provided versus one that can retrieve a customer’s information, determine the appropriate next step and execute that action in a CRM or ERP system is fundamental. Building, managing and maintaining these connections across systems at scale requires a mature approach to integration.
Integration maturity varies across the enterprise landscape today. While some organizations have “point-to-point” technical debt, others have already developed mature AI integration infrastructure, investing in platforms such as Workato, MuleSoft or Apigee and building the engineering practices and dedicated teams needed to operate these connections. From what I’ve seen working with enterprise technology teams, it’s the latter that will find adding agents exponentially easier.
Another “gotcha” is how prominent MCP’s (Model Context Protocol) are becoming. MCP’s are quickly becoming the new standard for how Agents communicate with systems. There are hundreds already available within Enterprise AI tools such as Claude, Gemini or ChatGPT, but that still does not replace the need for an API/MCP management tool. B2B transactions will soon be performed via MCP or custom vibe-coded apps will need their own MCP to expose capabilities. Regardless, the technical requirement stays the same.
For organizations without a purpose-built foundation for connecting Agents with core systems, what starts as an AI initiative can actually turn into an integration modernization initiative. Before agents can reliably interact with systems, organizations need to connect them.
Agents will expose the technical debt we’ve learned to work around
Modernizing the connections between enterprise systems to prepare for agent integration can help us uncover critical gaps in our existing environments. We see where humans commonly pick up the slack between disconnected systems through manual processes like data unification or handoffs. Agents, however, cannot compensate for these inconsistencies in the same way.
Regardless of the type of AI model, if data is inaccessible, APIs are unreliable, business logic is undocumented or systems can’t communicate with each other, an agent’s capabilities are hindered. This doesn’t mean agents create new architectural problems; instead, they help us expose technical debt we’ve grown accustomed to. The danger is trying to recreate those human workarounds for individual agents rather than fixing the underlying problem.
As organizations deploy more agents, one-off fixes can snowball into novel integrations, data access patterns and workflows that IT teams have to maintain. Instead of reducing complexity, we risk adding another fragmented layer to the enterprise architecture.
Enterprise-grade agents require a different engineering discipline
Beyond these architectural challenges, Agentic AI integrations also inform software engineering. Unlike enterprise software, which is built around predictable inputs, deterministic logic and defined failure status, agents introduce probabilistic behavior into enterprise environments. This means that the same request can produce different outputs or actions depending on the context and information available to the model.
I’ve seen this play out in the enterprise environments we work with. Even relatively simple agentic workflows can become unreliable when connections are faulty, schedules are inconsistent or prompts drift over time. What looks straightforward from the outside can require significant engineering and oversight to operate reliably.
If a relatively simple, low-stakes workflow like this example is easily derailed, consider the engineering required when an agent is expected to take consequential action across ERP, CRM or financial systems. This is why real software engineering is necessary when integrating agents.
Enterprises can’t simply buy an agent and expect stable automation in the same way they might configure and deploy other platforms. Agents must operate as part of the whole system, often spanning multiple apps and requiring ongoing testing, monitoring and maintenance. This requires a team of dedicated engineers and developers to make agent behavior observable, recoverable and reliable enough for enterprise use.
CIOs need to build the organization around AI Agents
For CIOs, preparing your organization to scale agents requires looking beyond the technology itself. Mature integration practices and dedicated software engineering teams are important, but those capabilities need to be matched by strong technical leadership and a culture that understands software, data and calculated risk.
Strong technical leadership is especially important because, remember, not every workflow should be agentic. We need leaders to recognize where AI reasoning and adaptability create value and where conventional automation or deterministic software is the better choice. At the same time, teams need to be comfortable experimenting with probabilistic systems, learning from failures and pushing innovation without sacrificing the engineering discipline required for enterprise environments.
For CIOs, preparing your organization to scale agents requires four capabilities: mature integration practices, dedicated software engineering teams, strong technical leadership and a culture that understands software, data and calculated risk. These capabilities reinforce each other; having two or three isn’t enough. Organizations need all four to move beyond individual AI experiments and scale agents across the enterprise.
Enterprise connectivity has a new purpose
Enterprise connectivity used to enable information to move between systems. In the agentic era, it increasingly enables software to reason and act across them. Organizations can see improvement in operations and service delivery, but it depends on infrastructure that supports connectivity between systems.
With the right connections in place, agents can eliminate manual handoffs across complex workflows, accelerate decision-making and help organizations scale expertise and services without adding another layer to existing operations. That’s where I see the real competitive advantage emerging.
As agents and models become more capable and widely available, access to the technology itself will become less of a differentiator. What will separate organizations is their ability to build systems around Agentic AI, enabling it to work dependably across the systems that run their business.
The organizations that gain the greatest advantage from Agentic AI may not be those with the most agents deployed or even the best models, but those that have invested in the infrastructure, integration practices and engineering capabilities around them.
When an AI workload is not performing as expected, the obvious place to look is the GPU. Do we have enough compute capacity? Would adding more GPUs solve the problem?
Not necessarily.
The GPUs may be perfectly capable of handling the workload, but if the network is not able to move data quickly and consistently, adding more compute could result in more expense without addressing the real bottleneck.
For CIOs, this means looking beyond how much compute they have and asking whether the network and wider infrastructure can keep pace.
AI is changing what the network needs to do
Enterprise networks have always had to move data reliably between systems. The difference with AI is the volume, speed and pattern of that traffic. Large AI workloads are distributed across multiple GPUs because the processing requirements are simply too great for one processor to handle efficiently. Those GPUs need to communicate constantly, exchanging data and synchronizing their work. Training is particularly demanding because GPUs may need to exchange parameters and gradients throughout the process, creating large volumes of traffic. As the number of GPUs increases, so does the importance of the connections between them.
This changes the relationship between compute and the network. Adding more GPUs increases processing capacity, but it can also increase the amount of data that needs to move between systems. If the network can’t keep pace, it can become the bottleneck that prevents that additional compute from delivering the expected performance.
Organizations do not need thousands of GPUs before this starts to matter. Even relatively modest enterprise deployments can involve large datasets moving between storage and compute, multiple accelerators working together and applications accessing models in real time.
The important point is that AI readiness cannot be measured simply by counting GPUs. You can continue adding compute, but there comes a point where the network determines how effectively that compute can be used. If data cannot reach the GPUs quickly enough, or communication between them is slowed by congestion or latency, expensive resources can spend time waiting rather than processing.
The obvious response might be to add more network capacity. While bandwidth certainly matters, increasing it does not remove every potential constraint. AI workloads can be particularly sensitive to latency, congestion, packet loss and inconsistent performance. Cisco notes that AI pipelines create different traffic patterns across training and inference, with training requiring both high bandwidth and low latency as GPUs continuously exchange information. The infrastructure therefore needs to manage not just capacity, but how traffic moves through the environment.
That distinction matters.
Imagine hundreds of GPUs working together on the same task. Their value comes partly from their ability to operate in parallel, so if one part of the network slows communication between them, the effect can extend beyond that individual connection. GPUs may be left waiting for other parts of the workload to catch up. The fastest component in the environment is not much use if it is constantly waiting for the slowest.
Storage adds another dimension. AI depends on data, which means moving large datasets from storage systems into compute environments and, depending on the workload, moving information back again. A network that performs well for GPU-to-GPU communication could still encounter problems elsewhere in that journey.
AI infrastructure does not usually exist in isolation, either. Enterprises are introducing GPU clusters into data centers that already support conventional applications, storage platforms, cloud connectivity and other business-critical systems. AI traffic therefore becomes another part of an increasingly complex infrastructure estate.
This is where network design starts to have a direct bearing on the economics of AI.
If an organization has invested heavily in accelerated compute, it wants those resources doing useful work for as much of the time as possible. A network bottleneck that leaves GPUs underutilized is not simply an IT performance issue — it means the business is getting less value from some of its most expensive infrastructure.
You cannot fix what you cannot see
Another challenge is knowing where the problem actually is. Infrastructure teams can see whether devices are available, track bandwidth utilization and receive alerts when something fails. That remains important, but increasingly complex AI environments demand a broader view.
A switch can be working. A server can be healthy. The GPUs can be available. Storage can be online. Yet the workload can still be performing below expectations. That’s because understanding individual components does not necessarily tell you how well the overall system is working. This is where the distinction between monitoring and observability becomes useful.
Traditional monitoring generally tells teams whether infrastructure components are operating within expected parameters. Observability goes further, bringing together information from across the environment to help teams understand why a system is behaving in a particular way. IBM describes network observability as providing real-time visibility into the performance, behavior and health of the network by drawing on data from across the infrastructure, rather than focusing solely on predefined metrics and reactive troubleshooting. For AI environments, that wider view is increasingly important.
If a training job slows down, teams need to be able to establish whether the cause is compute, storage, congestion on a network path, packet loss, a degraded link or something else entirely. Looking at each device separately can make that difficult, particularly when the issue is not a complete failure but a gradual deterioration in performance. Those are often the harder problems to find. A component that fails completely usually generates an alert, but a connection that still works yet is performing badly can be much less obvious. The infrastructure is technically available, but the workload is taking longer, GPUs are being used less efficiently and costs are creeping up. End-to-end visibility gives infrastructure teams a better chance of seeing those relationships.
AI readiness is an infrastructure question
As AI moves deeper into business operations, the consequences of infrastructure performance will become harder to ignore. A bottleneck during an experiment might delay a development team, but the same problem affecting a production AI service could have consequences for employees, customers or other systems that depend on it.
This means the network needs to be considered as part of the AI investment from the outset, rather than something to revisit when performance problems appear.
That does not necessarily mean replacing the existing network or building an entirely separate environment for AI. In many cases, the infrastructure already in place may be perfectly capable of supporting the workloads being introduced. The important thing is knowing where its limits are. That requires an understanding of what those workloads actually need, where genuine constraints exist and whether IT teams have enough visibility across compute, networking and storage to spot problems as they emerge.
Ultimately, it is not how much compute an organization has that matters, but how well it can use it. If CIOs are investing heavily in GPUs, they need to make sure the infrastructure around them is not holding them back.
CIOs bring a lot to their new jobs: decades of leadership, transformation, pattern-recognition, and outcomes. But none of that matters in your new job. During a time of generalized uncertainty, your team — and every stakeholder — needs to trust you more than anything. But how do you build that trust in a new environment, and as quickly as possible? For Cengage CIO Ken Grady, the best approach is an architectural one.
What is a trust architecture, and why did you develop it?
I’ve been a CIO for almost 20 years, and when I joined Cengage six months ago, while I had roughly 7,300 days of evidence that I knew how to do this job, not one person in that building had ever seen any of it. The proof existed on my résumé. The trust did not.
On day one as a new CIO, you have no shared experience with your team, so you have no trust. Your team might have respect for your background, and hope you’ll succeed, but personal trust is something you must build from scratch.
So how do you do that when the currency of trust for your team can shift depending on the situation? Establishing trust with the people in your new business requires an intentional approach, an architecture.
What are the different currencies of trust?
The first is technical currency. My team needs to know that as a new CIO, I’ll respect their technical expertise, have enough of my own to be helpful, and engage in healthy technology discussions. To solve for that, I sat down and led an open conversation early on about whatever was on their minds, and I showed them that their technical expertise is valued.
The second is investment currency. Can I, a technology leader, speak to ROI or NPV? Can I explain why we should invest in this technology, or address this technical debt, or move from this version to that one? My team needs to respect my ability to guide our investments.
The third is human currency, which addresses the questions people are afraid to ask. Why did we move our offices? Why are we incentivized this way and not that way? IT people are people, and they have non-technical questions.
Technical, investment, and human currency get exchanged in a cadence of conversations, and that cadence almost matters more than the content itself. People value leaders who are steady.
How are you using the trust architecture now?
People have questions when a new leader comes on board, and they need a safe place to ask them. That’s why we built a monthly Enterprise Architecture Review, an open meeting with no agenda where technical people talk through hard problems concerning what we’re trying and learning, what’s working, and what isn’t.
We’ve also built a monthly portfolio review called Steps-to-Green. We talk about the yellow and red projects, and how we can help each other move them to green. There’s no punishment in this room, only encouragement. If your product is yellow, that means you’re one step closer to green.
But the fear is wondering if it’s okay to say what you really think, so the senior leadership team holds a monthly anonymous Q&A. Ask us anything, what you’re worried, frustrated, or even angry about. We might not have all the answers, but we’ll try. If you give your team that kind of safety, they’ll use it.
What’s the benefit of this safety?
You get a high-functioning team willing to challenge existing norms and continuously improve. There’s no such thing as a perfect organization, and safety creates an environment where anyone can suggest an improvement, try it, test it, and report back.
What you get with safety is democratic governance. If there’s a quality problem, anyone in IT can hit the big red button to say we’re not doing this release, we have a quality problem. Anyone on the team can know more than I do about this technology, migration, or this HR issue, and hit the button.
It doesn’t mean there’s no bandmaster. I still need to lead the band since that’s my job as CIO. But the trombone player has to trust me enough to tell me we’re not playing it right.
What advice do you have for CIOs building a trust architecture in a generally anxious workforce?
I cure prosciutto in my basement. Every time I start a new one, I remind myself it takes 18 months, regardless of how many years I’ve been doing it. Trust doesn’t care about your résumé. It’s earned, not given. Before your next conversation, ask yourself if you’re building trust in the currency this person accepts, or the currency I’m most comfortable spending.
Empathy should be your lens. With my team, I show up ready to learn something, connect with them, not to perform leadership. With my stakeholders, I understand they don’t care about my migration strategy. They care whether I’m making their life easier. With my board, empathy isn’t warmth. It’s precision on knowing they need confidence from me, not just an update.
Each direction takes a different currency for team, stakeholders, and customers. As a CIO, you can’t be comfortable in one lane and neglect the other two. You must invest in all three.
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.
I argued in my last column, The case and model for real-time AI cost visibility at the infrastructure layer, that the AI measurement problem looks to be finally solved as a technical matter, and that companies can now manage AI as a strategic investment rather than a pay-and-pray experiment. That’s the defining shift for the next era of AI, but with one clarification: it’s only true for organizations whose architecture permits it.
My work puts me inside enterprise engineering teams, helping practitioners measure and optimize their cloud and AI costs. The biggest roadblock is rarely budget or expertise. It’s that AI spend, unlike cloud spend, doesn’t attach to anything you can tag. A token call has no owner, one API key can carry a dozen workflows across several teams, and the thing spending the money is usually an agent rather than a person.
The answers these teams need are only available by looking underneath the application, where you can watch what’s running. Getting there isn’t a complex engineering project, but it does require access to the machine the workload runs on, and that access is structurally unavailable through managed services.
So, the first thing I ask now is: “What does your inference actually run on?” The response determines the accuracy, completeness and usability of the AI cost insights we can get.
The implication of the platforming decision is easy to state and expensive to reverse. You run AI either on services your cloud provider operates for you, or on compute you operate yourself, meaning VMs or container nodes you control. Almost every team picked one many months ago on platform engineering merits, for reasons that had nothing to do with AI measurement. It just wasn’t obvious then that the choice would also determine how much they could understand about their own business later.
To get ahead of claims of bias, I recommend managed services regularly. They get you to a working agent much faster, and they take scaling, patching, availability and capacity off your plate, none of which differentiates anybody. If you come to me with three engineers and an AI roadmap, my recommendation is to use serverless and managed services as much as you can. Running your own infrastructure requires a platform team and the maturity to go with it, which makes this a question of size and stage.
Those advantages are settled science. The other trade-offs materialize later, and while CIOs have weighed most of them before, they’re worth a brief mention.
The AI trade-offs you can already price
Model selection is where this shows up in dollars. Open-weight models often run on infrastructure you control, while managed catalogs can lag availability or limit model choice. That matters when a newer model materially changes inference economics or performance. If you’re using a managed service that doesn’t offer the model you want, you can’t route to it through that service.
Stripe agreed in August to buy OpenRouter for more than $7 billion, a strong indicator of what the market thinks routing is worth. Of course, you can still route between models on a managed service, but you have to build the router into your own application code and run it yourself, outside the service you bought so you wouldn’t have to do that stuff.
The provider’s schedule also determines when you get access to new capabilities. For example, plenty of teams on their own infrastructure started building against MCP within days of its release, while stateful MCP server support didn’t reach AWS’s agent runtime until this past March, more than a year later.
It’s also worth noting that agents handing off to each other can introduce another execution or initialization cost, whereas on your own nodes you can keep resources warm. Enterprise authentication is not always one of the methods on offer, so you may have to build that path yourself anyway. And in regulated industries, proving where data can be a dealbreaker.
None of this is news to anyone who has run a platform, and none of it is disqualifying. You can put a number on each and decide it’s worth paying. The next one doesn’t work that way.
AI cost visibility is a one-sided trade
Let’s start with exploring what exactly your managed service provider tells you about your AI spend. The bill arrives on the provider’s schedule and can give you a detailed view of what you spent on a service, often by account or API key. That tells you where spend went up or down. It doesn’t necessarily tell you which workflow did it, which customer or which employee triggered it (not just created it). It also doesn’t enable you to map that spend to outcomes, productivity or revenue. A bill is not a measurement of value.
Going further, an AI agent isn’t a single service either. It’s the model call plus MCP servers, vector databases, APIs, prompt management and whatever else the workflow leans on, and that supporting cast can represent a substantial share of the cost. Without the ability to review those costs in isolation, you’re evaluating on estimates. You can’t say what a feature costs to serve, which accounts are profitable at the terms you signed, or whether the expensive part is the model or everything around it. So, you ballpark, and everything downstream inherits the inevitable errors.
The standard workaround has been to instrument the application, tracking each model call and carrying cost data through the workflow. I’ve built that many times and, on infrastructure you control, it works. But inside a managed runtime, you’re instrumenting someone else’s execution model. You can track the calls you make, but you may not be able to see the initialization you’re paying for, the orchestration between steps or the retries the platform runs on your behalf. You get detailed numbers for your own code, but less visibility into everything happening around it, and that’s often where the surprises are.
The expensive AI failures are also episodic rather than steady or predictable. An agent might loop on a retrieval it can’t satisfy, a workflow could revert to an expensive frontier model or a prompt change adds context and cost to every downstream call. If you’re reviewing the bill on a monthly cadence, you see that the AI number on the bill is bigger than last month, but don’t know why.
With real-time, per-request granularity you can instantly identify the workflow that’s misbehaving and it’s usually a quick fix. It also sets how soon you can intervene.
Accessing real-time, per-request attribution
The way to get that granular, real-time view is to watch the kernel, using the same eBPF technology that security and observability tools use to see system calls without touching the applications above them. In an implementation like this, it can map compute and network activity back to the relevant process and request, then join outbound model calls to provider cost data. The advantage is that the view doesn’t depend on developers remembering to instrument every call.
The catch is that it only works where you control the host machine, a narrower set of places than most people assume. On AWS it means EC2, and container workloads on EC2-backed ECS or EKS nodes. It doesn’t mean Fargate, where you don’t control the host kernel. The same principle holds across clouds: customer-controlled VMs and Kubernetes nodes can give you access to the kernel, while serverless and fully managed runtimes generally don’t.
It’s a firm line in the sand. You either have the option, or you don’t. There are no workarounds here. That alone doesn’t make managed services a mistake, and provider telemetry and application instrumentation still matter, they just can’t give you the same infrastructure-level view. If your inference runs where you don’t control the machine, you get as much infrastructure-level visibility as your provider chooses to share, and that ceiling remains capped even as the number of agents and the value of visibility grows.
The shift to per-task pricing for agentic workflows
Today, price per token is the standard unit for AI spend, but it’s the wrong one for agents. Agents burn far more tokens than chat; input drives most of the cost, and token use on the same task swings widely between runs, so cheaper tokens can still produce more expensive tasks. Cost per completed task is what tracks value.
But pricing a task means matching spend to its specific workflow and a measurable outcome. On infrastructure you control, you can get that visibility. On a managed runtime, you’re mostly inferring from an aggregated bill.
The last two years rewarded shipping. The next phase rewards knowing what each task costs and what it’s worth, and companies that can’t see the work will be competing against ones that can.
What if the most disruptive change to enterprise software is not another application, but needing fewer humans to operate the applications we already own?
For decades, we digitized work, integrated systems and moved applications to the cloud. Now we are entering a different era: software is beginning to participate in the work itself.
This changes more than productivity. It changes architecture, economics, security, governance, and ultimately the enterprise operating model.
For most of my career, enterprise application strategy began with these four familiar questions:
What capability does the business need?
Should we build, buy or integrate it?
How does it fit the architecture?
Can we secure, operate, scale and afford it?
Those questions remain important. But they are no longer enough.
Enterprise applications have historically been places where people perform work. Employees navigate screens, enter information, reconcile exceptions, move between systems and trigger workflows.
The relationship has been remarkably consistent: The application provides capability. The human orchestrates the work.
AI and agentic AI begin to change that relationship.
The strategic question is therefore no longer simply, “What functionality should the application provide?” It is becoming: “Who or what should perform the work?”
We are moving from applications people operate toward outcomes people increasingly supervise.
I call this discipline required to manage that transition Enterprise Work Architecture (EWA): The deliberate design of how an enterprise outcome moves across human judgment, machine intelligence, applications, data and authority from intent through execution and evidence.
EWA is not another application architecture, process map or AI governance framework. It starts with the work itself.
The problem is the work between applications
Traditional architecture organizes capabilities around discrete systems: ERP, CRM, HCM, ITSM and procurement. Business outcomes rarely respect those boundaries.
Today, humans often bridge those systems, searching, reconciling, interpreting and escalating. AI Agents can now compress those seams by gathering context, interpreting intent and coordinating authorized actions. The opportunity therefore is not simply AI inside applications; it is redesigning how work travels across them.
I learned through my experience that across complex transformations, some of the greatest productivity constraints lived between systems, teams, approvals, data and exceptions.
Modernizing the platform does not necessarily modernize the work. Put an agent over a broken 12-step process, and you may simply automate the friction.
Automation without work redesign can turn process debt into machine-speed process debt.
EWA: A CIO methodology
I would make EWA discipline operational through six connected steps:
Outcome: What measurable business result are we trying to produce?
Work: Which activities are necessary, which should disappear, and which require human judgment?
Authority: What may a person, application or agent recommend, prepare, approve or execute?
Execution: Which systems, APIs, data and workflows must participate?
Evidence: Can consequential actions be observed, reconstructed, challenged and recovered?
Economics: Did redesigning the work improve time, cost, quality, risk or experience?
The sequence matters here because many AI initiatives begin in reverse: choose a model, deploy a copilot, connect applications and then search for value.
EWA begins with the outcome and designs backward.
Before and after EWA: A customer billing dispute
Consider a customer whose invoice does not match delivery.
Today, an employee moves across CRM, ERP, fulfillment and contracts, often involving finance or operations before a credit can be approved. One outcome becomes a journey across systems, teams and controls.
EWA discipline redesigns this process:
Step 1: Outcome. Resolve valid disputes quickly, accurately and within financial controls.
Step 2: Work. Machines gather and reconcile evidence; humans handle ambiguity, exceptions and consequential judgment.
Step 3: Authority. Agents recommend or execute within defined thresholds; exceptions escalate.
Step 4: Execution. Actions flow through governed APIs into authoritative systems.
Step 5: Evidence. Data, decisions, actions, authority and human intervention remain traceable.
Step 6: Economics. Measure resolution time, human touches, exceptions, rework, cost and customer impact.
That is the difference between automating a task and rearchitecting the work. And that is the EWA discipline.
The innovation is not an agent writing a faster email. It is redesigning end-to-end work while preserving the integrity of the systems underneath it.
Four disciplines make EWA scalable
Turning EWA into an enterprise capability requires four disciplines.
1. Decompose work before deploying agents
Map intent to outcome. Identify judgment, deterministic activity, waiting, handoffs, exceptions and unnecessary steps. Then decide whether AI should retrieve, interpret, recommend, prepare, execute or escalate.
Remember: Do not automate what you have not first challenged.
2. Separate engagement from systems of record
Employees should increasingly be able to express an outcome: resolve this dispute, investigate this variance, restore this service without manually navigating every underlying application.
That does not diminish ERP, CRM, HCM, SCM or ITSM. It makes their data integrity, APIs, transactional controls and resilience more important.
3. Treat agents as governed enterprise participants and not software features
Once an agent can cross application boundaries and act, connectivity is insufficient. It requires identity, delegated permissions, purpose, data boundaries, transaction limits, segregation of duties, observability, escalation and lifecycle controls.
Retrieving an account balance is not changing a customer record. Preparing a purchase order is not releasing it. Diagnosing an incident is not changing production.
Remember: Capability cannot silently become authority.
The NIST AI Risk Management Framework organizes AI risk management around Govern, Map, Measure and Manage. For CIOs, the practical implication is that as machine agency increases, controls must increasingly operate at runtime, not only at project approval.
4. Measure work redesigned — not AI deployed
Counting agents, prompts, licenses or automated tasks tells a board little about whether enterprise economics improved. Measure time-to-outcome, human touches, exception rates, rework, cost per governed outcome, control overhead and value created.
The goal is not to make every task faster, but to determine which should disappear, which should be redesigned, which machines can safely perform and which still deserve human judgment.
Applications may become less visible — and more important
This creates a paradox.
Enterprise applications may become less visible to users while becoming more important operationally. Meaning, instead of opening five applications to achieve one outcome, an employee may interact with an intelligent workspace orchestrating those systems underneath. ERP still protects financial integrity. CRM maintains customer context. HCM protects workforce records. SCM coordinates fulfillment. ITSM governs services.
What changes here is the human relationship with them.
That affects application portfolios, integration architecture, licensing economics, cyber exposure, resilience and technical debt. The modernization question becomes not simply, “Which applications should we replace?” but “Which application interactions should humans still have to perform?”
The same issue matters during M&A, where enterprises can inherit duplicate ERP, CRM, HR, identity, data and workflow estates. Agents may provide orchestration while rationalization proceeds, but can also amplify inconsistent permissions, fragmented data and unresolved control ownership.
Deloitte’s Generative AI in M&A research examines generative AI across the deal lifecycle alongside considerations including integration, security, trust and human involvement.
The CIO’s mandate is becoming the architecture of work
This cannot belong to IT alone because work does not belong to IT.
Business owns outcomes. Operations understands process reality. Finance measures enterprise economics. Security establishes trust boundaries. Risk and Legal define obligations. HR understands workforce consequences. Audit tests controls. Enterprise Architecture connects them to systems, data and execution.
The CIO’s opportunity is to make those disciplines coherent.
Start with a work inventory, and not another AI inventory.
Find where employees bridge systems, exceptions concentrate, approvals create latency, repetitive activity consumes capacity and application boundaries become organizational boundaries. Then apply EWA discipline: Outcome. Work. Authority. Execution. Evidence. Economics.”
That creates a repeatable methodology for deciding not merely where AI can be deployed, but where enterprise work should be redesigned.
Boards can then ask a more consequential question: “Are we funding AI features or redesigning how the enterprise operates?”
The first can produce a larger technology portfolio.
The second can change productivity, operating leverage, experience, risk and ultimately enterprise value.
Do not begin with how many agents you can deploy. Begin with the work your enterprise should no longer perform the same way.
Redesign the outcome. Remove unnecessary work. Define authority. Connect execution. Instrument evidence. Establish the economics. Protect human judgment where consequence demands it. Then scale.
The enterprises that lead this transition will not necessarily have the most autonomous software. They will be those that most deliberately determine where humans create judgment, where machines create leverage and where the combination creates measurable enterprise value.
The next generation of enterprise applications will not simply run the business. They will increasingly participate in running it. The CIO’s responsibility is to redesign the work without surrendering the judgment, trust and accountability on which the enterprise depends.
I spent the early part of my career building database systems, managing Oracle’s storage engine group and later helping build Aster Data. That work taught me to watch the gap between benchmark results and production behavior. When the Transaction Processing Performance Council (TPC) was formed in 1988, it was because vendors, customers and researchers lacked a common language for comparing transaction systems. The benchmarks worked, but they also created an incentive to tune configurations around the test rather than around production. The response was to add oversight through fair-use policies, peer review and independent audits.
The lesson has stayed with me: a benchmark result means something when the improvement behind it survives contact with a customer environment. Enterprise AI has reached the same point. So, we built a benchmark around the conditions enterprise AI actually has to survive.
The hardest part of enterprise AI is not making a model reason. It is giving that model the right sliver of trusted context without making it reconstruct the company every time. When we began buildingEnterprise-Bench, I expected model reasoning to dominate the work. Instead, we kept returning to the same bottleneck: assembling the right context.
The models could usually answer a straightforward business question once they had the right information. Getting them that information, with the right permissions and without drowning them in irrelevant data, was a much harder engineering problem.
Stanford’s Holistic Evaluation of Language Models (HELM) shows how public benchmarks use standardized datasets to compare model performance consistently. Inside an enterprise, even a straightforward question can be difficult to answer because the relevant data is scattered across systems, inconsistently described and governed by different permissions.
“Which customers are affected by this bug and what is its impact?” is not a math Olympiad problem. Yet the answer may require an agent to connect a support ticket to a product component, match that component to an engineering issue, identify the affected accounts in a CRM, calculate the revenue exposure and return only what the user is permitted to see.
The model can only reason about what the system can find, connect and safely expose.
Simple questions expose hard architecture
Some of the most revealing tasks in the benchmark were the ones that looked easy. Asking for the number of open tickets on an account is a lookup. Asking which priority-one tickets correspond to unresolved engineering issues, and how much customer revenue is exposed, is also a lookup. It just crosses more systems and more access boundaries to get there.
Enterprise AI evaluations often misdiagnose integration failure as model failure. A model guesses because two applications name the same product differently. It misses a customer because the relationship between a ticket and an opportunity exists only through a third object. It retrieves a stale document because the connector indexed a snapshot rather than maintaining the current state.
Buying a stronger model may improve the fluency of the answer. It does not repair the missing relationship.
Scale revealed the real failure mode
We modeled the benchmark on a synthetic midmarket payments company with 42 customer accounts, 40 product parts, five interconnected enterprise systems and 14 tasks spanning engineering, sales and support. Then we increased the surrounding data volume by up to 256 times without changing the correct answer.
At the smallest scale, about 40% of the available data was relevant to a task. At the largest, roughly 0.16% was relevant. The question did not become harder, and the answer did not change. Only the amount of noise grew.
Answer-preserving scaling exposes what smaller tests hide. If accuracy falls as irrelevant data grows, the retrieval architecture has become less effective. If an agent repeatedly fetches broad sets of records and discards the context, token costs will climb with the company.
Enterprises may hold trillions of tokens across customer, product, employee and service history. Even a million-token context window is a workspace, not organizational memory. The problem is not fitting everything into the prompt. It is identifying the smallest trustworthy set of facts needed for the decision at hand.
The harness can matter more than the model
Most enterprise AI starts federated. A model connects to a CRM, a support platform, an issue tracker and a document repository through APIs, and when someone asks a question, it retrieves from each source and assembles an answer. That works for discovery. It struggles the moment a question spans the operating model of the business, because the system has to reconstruct identity, relationships, permissions and current state on every single request.
The word “harness” can make this sound like an implementation detail. It is not. The harness is the system around the model: memory, retrieval, tools, permissions, evidence and the logic that brings context together.
In our initial comparison, we held the foundation model, tasks, data and independent judge constant. Our structured-memory system completed 94.3% of the tasks correctly, compared with 63.6% for Claude Code using the same Opus 4.8 model family. It also used about 4.4 times fewer tokens per correct answer at production scale. The same model produced materially different outcomes depending on the architecture around it.
Memory is not a bigger prompt
For decades, enterprise architecture has separated compute from state. We do not ask an application to rebuild its database every time it receives a request. We index, cache, preserve relationships and enforce access close to the data. I fully believe that enterprise AI needs the same discipline.
The split is between what is deterministic and what is not. Resolving which account a contract refers to, whether a permission applies and which version of a fact is current is work that software can do exactly. Interpreting a badly worded question, weighing ambiguous evidence and helping someone decide is work that models do well. Federated architectures blur that line and ask probabilistic inference to rebuild structures a database could simply maintain.
Useful memory is current, structured and permission-aware. It understands that the customer in a contract, the account in a CRM and the organization in a support platform may be the same entity. It keeps those relationships current, preserves provenance and knows that shared memory does not mean universally visible memory.
This is why I believe enterprises should invest in their own memory and workflow layer before trying to build or tune their own models. An enterprise strategy should outlast any single model. Models will improve, specialize and change in price, but the relationships, permissions, skills, decisions and accumulated judgment that make up a company’s intellectual property should remain under its control.
Autonomy should be earned
The benchmark also changed how I think about autonomy. The industry often presents autonomy as a feature that can be switched on. In an enterprise, it should be treated as a promotion that an agent earns.
Our framework progresses from reactive retrieval at L1 to analytical reasoning at L2, then to proactive coordination at L3, and finally to extended self-directed operation at L4. The current public suite tests only L1 and L2. We expect L3 systems to begin moving into true production over the next six months, while some more advanced enterprises are already testing them internally.
Before an agent is trusted to manage a customer escalation, renewal process or another multi-step workflow, it should repeatedly prove that it can retrieve the right facts, reconcile evidence across systems, preserve access controls, explain the basis of its answer and produce an auditable record as the work progresses.
Reliability at one level should become the entry requirement for the next. If an agent cannot read consistently, it has not earned the right to write.
What CIOs should measure
CIOs do not need another leaderboard that declares a universally smarter model. They need evaluations that reproduce the conditions under which their own AI will operate.
I would test seven things:
Hold the model constant and compare the systems around it.
Keep the answer fixed while increasing the amount of irrelevant data.
Test cross-system questions that require structured and unstructured information in the same response.
Measure token cost per correct answer, not token consumption alone.
Run the same task repeatedly, because “worked once” is not the same as “works reliably.”
Test permission failures and require evidence that an action can be reconstructed after the fact.
Require the benchmark itself to be inspectable: task definitions, scoring, traces and failure modes.
Most importantly, choose tasks that matter to the business. Ask which product problems are putting renewals at risk, what commitments were made on the last customer call, or which support cases have breached the terms of their actual service agreements. A polished demo can hide weak architecture. A question grounded in your operating reality usually cannot.
Building an enterprise benchmark changed the question I ask about AI. Instead of starting with, “How intelligent is the model?” I now ask: “Can the system assemble the right context, at the right moment, for the right person and prove that it did so?”
The trillion-dollar enterprise AI bet is not how many tokens we can squeeze into a context window. It is how few of the right tokens we need to deliver a precise, efficient and safe answer.
For CIOs, the enterprise ambition to deploy AI is outpacing execution and is impacting everything from talent to technology to operations. The challenge to deploy is not coming from the technology itself, but rather the complexity that we have built into our enterprise IT environments.
The more deeply AI becomes embedded across the enterprise, the more dependencies it can introduce. More systems, integrations and data dependencies create additional operational and security considerations that must be managed as AI scales.
I saw this firsthand when we started looking at how to simplify our technology landscape. We had more than 1,500 software applications after years of growth, acquisitions and technology investment. That created a broad estate to operate and secure, and when I speak with other CIOs, I hear similar stories.
That sprawl has always had a cost. Teams spend time maintaining applications, managing integrations and keeping systems current. Hybrid environments add another dimension as workloads operate across data centers and public and private clouds.
AI must work across that same environment.
This is why I believe complexity is the biggest barrier to effectively implementing AI across the enterprise. The models will continue to improve, but better models alone will not solve fragmented processes, poor data quality or unnecessary layers. Some of the workflows with the greatest potential for AI are also operationally intricate, which makes preparing people to work differently just as important as preparing the technology environment. Reducing the tech stack, integrating human control and ensuring strong data quality and governance are essential to overcoming this barrier.
AI inherits the complexity of the tech stack
There is a temptation to view AI as a way to work around technology debt. In practice, AI can expose it. That challenge is widespread, with 68% of CIOs reporting that technical debt from past integrations is blocking their ability to scale AI.
We have experienced this ourselves. Some of the hardest AI use cases are processes with many permutations and edge cases. If the underlying environment is highly customized or fragmented, an agent also must navigate that complexity. The operational burden can become greater than the problem AI was intended to solve.
That is why simplification has been a major focus for us.
As part of our broader transformation, we reduced our application landscape by more than 300 applications and consolidated over 40 data centers. The benefits extend well beyond the direct technology costs. A smaller estate gives operations teams less to maintain and security teams less to protect. It also creates a more manageable environment for AI.
This does not mean every enterprise should pursue a perfectly uniform architecture. That is neither realistic nor desirable.
Our own environment is hybrid. We operate workloads across data centers, multiple public and private clouds and sovereign environments. Different workloads have different requirements. Some complexity is necessary because of security, regulatory and business needs.
The important distinction is between complexity that serves a purpose and complexity that has simply accumulated.
That becomes more consequential with agentic AI. An agent may need to interact with multiple applications, retrieve information and initiate an action. Every additional dependency creates another place where permissions, data definitions or integrations must work correctly.
In addition to a hybrid environment, I also encourage teams not to begin their AI journey with the biggest and most complicated problem they can find. Start with use cases where the inputs and expected outputs are understood. Prove the technology can perform the task reliably. More complex orchestration can follow as confidence grows.
Nearly two-thirds of enterprises worldwide have experimented with agents, but fewer than 10 percent have scaled them to deliver tangible value. As organizations look to close that gap, data architecture becomes increasingly important. AI at scale depends on an information environment that can support it reliably.
For CIOs, this makes architecture part of the AI strategy. Before adding another agent to another workflow, we should understand what it will connect to, what information it needs and whether the environment is making the job harder than it needs to be. Not all AI use cases earn the infrastructure it demands.
Know when to trust the output
As AI becomes more capable, the challenge is not limited to the number of systems involved. CIOs also must manage the complexity of deciding how much authority to give the technology.
I think about that question differently depending on the workload.
Using AI to help someone retrieve information carries one level of risk. Allowing an agent to act inside mission-critical infrastructure carries another. The appropriate level of human oversight should reflect the consequences if the AI gets something wrong.
We are working through this in our own operations.
Our network and security operations specialists worked alongside the teams building the AI agents to define what technology should do and what people should continue to own. One of those capabilities is a resolution agent designed to help diagnose and ultimately resolve operational incidents. Today, we operate with a human in the loop. The AI agent can analyze information and recommend a resolution, but a human makes the final decision. Our team also records whether the recommendation was correct and what differed when it was not.
That feedback helps improve the system over time.
The long-term opportunity is greater autonomy and speed while ensuring business continuity. But mission-critical operations require an extremely high degree of certainty before we make that transition. Autonomy must be based on demonstrated performance rather than assuming an agent is ready because the technology makes autonomy possible.
This is where trust must become measurable. Organizations need visibility into what an agent is doing, what data it is using and whether it is producing the expected outcome. They also need clear access controls. We think about identity and access management for our agentic workforce in much the same way we think about it for people. An agent should have defined responsibilities and permissions appropriate to the work it performs.
It should also be possible to turn an agent off.
For CIOs, the goal should be controlled progression. Human involvement can change as technology proves itself, but autonomy should be earned through evidence.
Strong foundations make AI possible
Both issues ultimately come back to information.
AI needs context to be useful inside an enterprise. That means organizations must know what data they have, where it resides, how it is governed and what should be exposed to AI.
Strong information governance grows even more important as AI gets better at finding information. Anyone experimenting with enterprise AI has probably seen how quickly it can surface information buried deep inside an organization. That can create tremendous value. It can also reveal weaknesses in information governance.
Knowing your data is therefore becoming inseparable from knowing your AI.
Data controls and a clear understanding of how information is used have shaped our approach to AI. Before connecting a capability to enterprise information, we want to understand the data being used and the controls around it.
For sensitive information, we also need to understand where that data is processed and whether the deployment model provides the protection the workload requires.
This is one reason regulated organizations have an advantage. Many have already spent years establishing controls around sensitive information because regulation required it. Those investments can become a foundation for AI rather than a barrier to innovation.
Data quality matters as well. Agentic AI can operate on poor information, but that does not mean the result will be useful enough for the business to rely on. The stronger the information foundation, the more confidence you can have in the context being provided to AI.
The same applies operationally. Organizations need visibility into how AI is performing after deployment. We have been investing in continuous evaluation so we can understand what data contributed to an outcome, whether the result was accurate and where the technology needs to improve.
That evidence connects the foundation back to trust. If we know the information an agent is using, understand its permissions and can evaluate its performance, we can make a much better decision about how much responsibility to give it.
This is the work that will determine how quickly enterprise AI can mature.
AI will continue to become more capable, but adding more intelligence to a complex environment does not automatically make the environment simpler. CIOs need a strong foundation, first: reduce unnecessary complexity, strengthen control over information and establish clear boundaries for how AI operates.
Enterprise AI readiness comes down to reducing unnecessary complexity, understanding and governing the information AI depends on, and being deliberate about where human judgment remains essential. Do those things well, and AI has a much stronger chance of delivering measurable value at scale.
In 2012, MD Anderson Cancer Center began working with IBM on one of the most ambitious experiments in healthcare AI. The premise was compelling: combine the knowledge of a leading cancer center with Watson’s computing power and help physicians make better treatment decisions.
Five years and roughly $62 million later, MD Anderson allowed the contract to expire before Watson had been used to treat an actual patient. A university audit documented procurement problems, cost overruns and delays. TheJournal of the National Cancer Institute also described the challenge of assimilating Watson into a hospital environment where important information lived in physician notes, medical shorthand and electronic records that the system could struggle to interpret.
I take a broader lesson from that history. Intelligence can be impressive in isolation and still create little operating value when it cannot understand the information around a process, participate in the work and hand the next action to the right system or person.
The same operating challenge has returned with agentic AI. Healthcare processes can cross clinical information, coverage rules, providers, payers, care teams and multiple operating systems. AsCIO has recently noted in its coverage of enterprise architecture for agentic AI, traditional interfaces can move data between systems without supplying all the business context an agent may need to operate across them. In my experience, that is where the architecture problem begins.
The problem between the systems
Prior authorization is a useful example because it appears simple from the outside. A request is submitted and a decision comes back. Inside the enterprise, the process may depend on eligibility, clinical documentation, coverage requirements, information from a provider and a review that may require professional judgment. Each component can function well, and the overall process can remain slow because the difficult work often sits between systems.
Beginning in 2027, impacted payers face new CMS API requirements involving provider access, payer-to-payer exchange and prior authorization. TheCMS Interoperability and Prior Authorization Final Rule requires impacted payers to implement certain FHIR APIs, with API compliance dates generally beginning January 1, 2027. The Prior Authorization API must support requests and responses and communicate whether a request is approved, denied with a specific reason or requires more information.
Those connections create a foundation for a more integrated operating environment. The information still has to enter a process that understands its context and knows where the work should go next. Software may be able to complete an action in one situation, while in another case it has to reach a person.
An AI agent could retrieve a clinical record, examine a coverage rule or recommend a next action. Its contribution depends on how well that intelligence fits into the complete operating process.
That is why I would be cautious about measuring AI progress by the number of agents deployed. Giving an agent access to five applications says very little about whether the underlying process improved. If people continue moving information manually and deciding where the work goes next, the organization has gained another intelligent capability without necessarily gaining much operating capacity.
Architecture should follow the work
I have spent years looking at automation through the way businesses operate. I tend to break an organization into its functions; understand the work each function performs and examine how information and responsibility move between them. The industry may change, although the discipline remains similar: start with the work.
For a healthcare CIO, that means understanding one complete process end to end. The CIO needs to know which information the process depends on, where it originates, who touches the work, which activities are repetitive and where judgment enters. From there, the architecture has to account for the system or person responsible for the next action.
These operating questions expose the difference between automating an isolated task and changing the way a complete workflow functions.
I organize that healthcare architecture around four layers: experience, intelligence, operations and secure data. Experience is where providers, payers, patients and care teams interact with the enterprise. Intelligence interprets information and can help understand what is happening or recommend an action. Operations carries that action through the organization by executing, routing, delegating or escalating the work. Secure data provides the records, rules and trusted information those functions depend on.
Their value comes from how the layers connect around the process being performed.
In prior authorization, clinical and coverage information has to be available when it is needed. Intelligence may help determine whether the information is complete and what it means in context. Operations then moves the work according to the result. Missing information can route the request back for completion, an automated action may allow the process to continue and a case requiring clinical judgment has to reach the appropriate professional with enough context to make that judgment.
Human involvement should be designed into the architecture from the beginning. Healthcare includes administrative work that automation can handle and decisions where professional responsibility stays explicit. Security, privacy, governance, compliance and monitoring belong in the same operating design. As agents participate in more of the work, the organization should be able to understand which information was used, what action occurred and where responsibility sits afterward.
This is where I think people-in-the-loop and agentic AI-in-the-loop become a useful operating model. The balance can vary across functions because the work itself varies.
Measure what changed
The measure I use for automation is what I call flex capacity. If one employee can handle 100 transactions and automation allows that role or team to handle 250, the organization has created additional capacity without adding people at the same rate. The business result is the increase in what the organization can do.
I have seen this in our own operating experience. Work that previously required roughly 500 people has been handled by approximately 100 to 150 people as automation changed the process. Coding, testing, data entry and data analysis are examples of activities where technology can reduce repetitive effort. Better visibility can also allow experienced people to oversee more work without the same administrative layers.
I would apply that thinking to healthcare workflows by establishing the operating baseline before adding agents. That baseline should show how many people touch the process, the volume the team can handle, the time spent moving information and the points where people intervene because the system cannot determine the next step. After automation, the same operating measures show whether capacity actually changed.
Greater volume from the same organization is one useful result. Reduced administrative work is another, particularly when clinicians and experienced professionals gain more time for work that requires their judgment. A large agent count provides much less information about the health of the operation.
The architecture has to support those outcomes across systems. An intelligent workflow may examine information, predict what could happen and recommend an action. Operations then carries the work to the appropriate destination. The path can involve software, a person or several systems depending on the process.
The 2027 CMS requirements give healthcare organizations a practical reason to improve important connections now. I would use that work to examine one complete operating process; from the information it depends on through the role intelligence can play and the points where professional judgment remains necessary. The resulting action has to reach the right destination, and the organization should be able to measure the change in operating capacity.
The earlier generation of healthcare AI taught me how closely intelligence depends on operating architecture. Today’s AI is considerably more capable, and healthcare interoperability continues to improve. CIOs have an opportunity to bring those developments together around the work itself.
The next advance in healthcare AI will be defined by how effectively the enterprise can put intelligence to work.
A couple of years ago, I did some work with a client’s legacy system. But this wasn’t an ancient relic written in COBOL or Assembler; it was a relatively new C++ application. Let’s call it “App1.” So, when did App1 become “legacy?” When did my client’s relationship with it sour?
A stale relationship?
The UK Government defines legacy IT as “outdated and often obsolete technology.” Or in other words, too old. But when is an application too old?
It’s unlikely my client was bored with App1 when it was first commissioned. Even after a honeymoon period, there would have been years when things were going along just fine. But somewhere along the way, the relationship went downhill.
The Linux operating system was created in 1991, now over 35 years old. Yet it’s still a key server operating system, not exactly outdated. Java was created in 1995, but at 31 years old remains a strategic programming language. Although not a baby, App1 was younger than both: around 15-20 years old at the time. Some may be happy in a 20-year relationship; others will be ready for something else far before this.
Although something becomes legacy with time, there’s no set timeframe for when this happens. It could be 35 years; it could be one. Something happened in the past to make App1 legacy. But, what?
Money issues
The Australian government says that legacy applications can be, amongst other things, “no longer cost-effective.” Like the US government, many organizations spend a lot of their money on legacy systems. But are they really more expensive?
Many believe so. A study by banking consulting firm Digital Bank Expert states that modernizing legacy IT infrastructure has reduced banks’ TCO by up to 52%. Not everyone agrees. HPE NonStop expert Justin Simonds agrees with Rocket Software that legacy systems aren’t as expensive as many think.
Something doesn’t have to cost more to become legacy: it only needs people to believe it. My application client was aware of costs, but that didn’t seem a big deal. But it was very different for the mainframe infrastructure team and management. Multiple CIOs had set a direction to move away from the mainframe because of its perceived cost alone.
Like a frog in hot water, there probably wasn’t a particular time when my client’s legacy application costs became a problem. But at some point, they were noticed, and this crack in the relationship grew.
Misunderstood
Legacy skills are a key concern to many of my clients. They lament the lack of COBOL and Assembler programmers, and staff that understands the mainframe. Like many other clients, they have had little interest in training new graduates, despite options like those from IBM. Understanding the technology or programming language isn’t enough. Legacy systems can be complex, taking even the best experts time to understand.
My clients had lost most of their technical knowledge of App1 as older experts retired and weren’t replaced. To mitigate this, they relied on a service provider, who themselves had issues finding staff. This probably became apparent to my client when one of those staff retired, or their service provider struggled to fix a problem.
Not feeling safe
In 2022, Fujitsu announced the retirement of their legacy GS21 mainframes, ending support in 2035. Telling your partner that it’s over is unlikely to help the relationship, even if it is 13 years in the future. If GS21 clients didn’t consider their mainframe legacy before 2022, they do now.
All systems require a technology stack supported by someone providing fixes and help to keep it running: vendors or staff. But as highlighted by the US GAO, a big reason for support is security. High-profile issues like the Apache log4j vulnerability were only fixed for supported systems.
GS21 mainframes are older technology, missing basic operating system enhancements like 64-bit addressing. So, GS21 users will have considered it legacy far before 2022. Is this when something becomes legacy – when it stops changing or innovating?
App1 ran on IBM’s flagship IBM Z mainframe: hardware less than two years old. The rest of the technology stack was similar: recent versions of the z/OS operating system and CICS transaction manager with regular security patches and fixes. In fact, a 2025 survey by ITIC found that IBM Z mainframes had the lowest downtime due to security hacks of any platform. Security wasn’t an issue.
Another non-issue was an inert technology stack. The IBM Z mainframes ecosystem continues to adapt with features like onboard AI functionality, new languages like Python and Node.js, and support for Java SpringBoot applications. But the stack was still seen as legacy, and that’s all it takes.
A big issue was the application itself. There had been no major enhancements for many years, and my client had little interest in leveraging the new IBM mainframe goodies. Few changes meant that support staff had less experience in making changes, which slowly morphed into a culture where changes were resisted by the supporting teams.
At the same site, another application group was making big changes to their application: moving from a legacy file-based storage system to Db2. Despite this, that second application was also considered legacy. Innovation isn’t guaranteed protection against the legacy label.
Despite using an active and secure technology stack, App1 itself was stagnant. This didn’t happen in an instant, but was a result of ongoing management decisions, helping App1 win the legacy badge. But this wasn’t the only issue.
Not enough from the relationship
The user interface of App1 was old: old web pages, and even some 3270 screens, like relying on a UNIX Telnet screen. This was fine when the application was first created, but unpopular today. They could have leveraged some of that new IBM mainframe technology but could not get the budget. The old screens were there to stay.
Changing legacy systems is always harder than creating new ones. As it gets older, it has more history and becomes more complicated. Any change must satisfy the requirement but also avoid breaking anything else. This ‘technical debt’ can slow down changes, frustrating a business that isn’t standing still. My client felt this, with changes requiring weeks to be migrated into production. Legacy systems can be mission-critical, and there was little tolerance for an outage of App1.
No one wants a partner that they’re ashamed of taking out in public, and none saw App1 as attractive. And it’s not just the user interface. I had another client ready to move their application from the mainframe simply because of marketing: a flagship system running on the mainframe was not sexy.
When did App1 become difficult and ugly? Perhaps when the business needed a change that could not be made. Or when a manager saw the old interfaces and didn’t like them.
The moment it changes
There’s no official definition of ‘legacy,’ no metric or equation to calculate when something becomes legacy. But the answer is simple: App1 became legacy the moment my client started looking for something better. I don’t know when that was: it’s unlikely there was a ‘eureka’ moment.
Senior management fell out with App1 because of the perceived cost; the business unit because the unattractive application resisted change. The application support team was also ready to move on, with few staff capable of supporting App1.
The last time I talked with my client, the relationship hadn’t ended yet. They were on the IT application equivalent of dating apps, while their legacy relationship continued to do their critical processing. The reasons they disliked App1 weren’t enough to overcome the cost and risk of moving away.
It’s not too late for this relationship. My client could refresh it: train new staff, invest in new technologies. More likely, things will reach a breaking point, and my client will swipe right and move on.
Working with large financial institutions, I’ve watched enterprise data consumption change drastically. The old model might have had 1,000 people using the same carefully designed application. These 1,000 users could reliably and predictably work from this application, and data access would typically occur in the same way.
That change was already underway as dashboards, APIs, notebooks, microservices and specialized applications multiplied the number and variety of consumers reaching the same underlying data. Agentic AI is turning this construction on its head. Those 1,000 people could now be working from 1,000 individualized dashboards, applications or agents. That creates more paths, data combinations and entitlement decisions, and each requires reconstruction.
What gets easier and more individualized at the application layer gets harder underneath it: infrastructure and InfoSec teams must support more dynamic demand, more access patterns and more control decisions. And that challenge is becoming more pressing as agentic AI broadens: 23% of organizations report scaling agentic systems, and an additional 39% are experimenting with agents.
The result has accelerated a broader shift from relatively predictable data consumption to fluid, individualized and difficult-to-govern access patterns across the same underlying data.
In capital markets, tolerance for inconsistencies is nonexistent. This environment has been an early proving ground for architectures designed to coordinate changing consumer patterns. The lesson is not that every workload should be centralized or routed through one platform, but rather that a governed data consumption layer can provide the leverage to reduce repeated integration, protect sensitive source systems and enforce consistent access, audit and runtime controls.
I use “governed data consumption layer” here to describe the consumption-facing role of a broader data fabric. The fabric connects and contextualizes data across enterprise systems, maintains reusable state and controls and distributes that information through governed interfaces. The consumption layer is where those capabilities meet the applications, users and agents requesting the data.
However, CIOs need to evaluate where this approach may prove valuable and where direct access may remain the better choice, if they wish to manage how a growing number of human and machine consumers access, combine and act on data. The architectural question is what changes when the consumer, its query pattern and its data requirements can no longer be known in advance.
Where a data fabric creates leverage
A data fabric can create significant leverage when growing numbers of consumers would otherwise have to independently reconstruct the same context, establish their own access paths and operate their own controls. A consumer may need a current business view that combines live activity with persistent context. A credit-card authorization, for example, may need to be evaluated against available credit, merchant history, fraud scores and card status. If multiple consumers independently reconstruct that same contextualized view, they duplicate processing and create more opportunities to arrive at inconsistent answers.
A data fabric separates the primary workload from data delivery in these cases. It allows the same working set to be reused, reducing pressure on source systems and making latency more predictable. This layer is also helpful when each subsequent application requires different views of the same information, based on their fields, histories, update rates or interfaces. The objective is to deliver data at the level of freshness each workflow requires; not every consumer needs to be real-time.
That separation also preserves optionality. A new application or AI workflow can gain governed access without requiring the underlying system to be replaced, migrated or exposed directly to every new consumer. Reuse solves only one part of the challenge. As consumption becomes less predictable, the layer also must govern what each consumer receives.
One pattern I describe as the “fire-hose approach” is sending consumers a broad stream of information and expecting them to discard what they do not need. That becomes harder to justify as consumers multiply and request different fields, filters and time windows. At the consumption layer, the fabric can instead tailor delivery more precisely to what each consumer requires, reducing unnecessary movement and downstream processing.
That precision also improves governance. If the request itself defines exactly what information a consumer receives, the organization maintains a more granular record of who requested what instead of knowing only that a user subscribed to a much broader stream.
Additionally, entitlements and audit requirements would need to remain consistent across these dashboards, APIs, notebooks, services and agents that request information. As access paths multiply, observability and governance practices must scale with them. As of writing, only one-third of surveyed organizations rate themselves at least moderately mature in AI strategy, governance and agentic governance.
I’m already seeing AI change the practical meaning of entitlement. An operations employee may legitimately hold broad credentials to perform a technical role but historically lack the time or expertise to use that access to derive sensitive business information. With an AI interface, the same employee may be able to ask for something like an entire desk’s P&L in a few keystrokes. The entitlement has not changed, but what the user can accomplish with it has. Once multiple consumers depend on that shared layer, governance is not solely an access-control problem. The layer itself must be operated as critical infrastructure.
High-consequence architecture demands more than a simple check to confirm it’s running, which only confirms the pipeline is alive. CIOs must know whether the state it is distributing is current, correct and reconstructable. As consumption becomes more individualized, visibility into which consumers are driving load, what queries are becoming common and how those patterns are changing over time is also required.
An enterprise needs to be able to explain which data, state, transformation and permissions produced a result. That means making sure the information is current, explainable and traceable. Here, the leverage of the fabric once again proves valuable. It can supply evidence of what was requested, which state was used, what transformation occurred and what was delivered.
With this foundation, organizations are better equipped to enforce governance at the point where access is granted, rather than leaving it until a final review checkpoint. This includes identity, access scope, consumption limits, tool permissions and audit. As consumers become capable of doing more than retrieving information, that governance also has to follow the progression from what they may access, to what operations they may perform with it, to what actions they may execute.
In higher-risk workflows, that final stage may require a human override. I’ve seen banks use kill switches that allow humans monitoring outliers to halt automated trading when something appears wrong. As automated consumers take on more decision-making, preserving that ability for intervention becomes more important.
When governance becomes part of how the organization operates, and not just how it says it should operate, later applications can reuse connectivity, mappings, state, controls and recovery procedures and trust that they align with the overall business view, which prevents every new consumer from requiring another independent integration, entitlement model and operational path.
The fabric becomes most useful when growing numbers of consumers need the same underlying data in different and increasingly difficult-to-predict ways. It helps provide this data while maintaining oversight and protecting source systems. However, that doesn’t mean that it’s the best choice for every organization.
When predictable consumption still makes direct access the better choice
The decision comes down to a practical tradeoff: a data fabric earns its place when the cost and risk of repeatedly integrating, contextualizing, governing and operating access for individual consumers exceeds the cost and risk of introducing shared infrastructure.
This fabric concentrates responsibility. If the layer can’t process requests, update its working state or distribute information quickly enough, it can become a bottleneck. And with multiple consumers relying on it, an outage, stale working state, faulty transformation or policy error can have a larger blast radius. Under these conditions, the layer can shift into a mechanism for propagating stale working state, bad mappings or entitlement errors.
That tradeoff matters because direct access remains sensible when the consumer is bounded, demand is predictable and the source was designed to serve the workload. The case is even stronger when the data requires little transformation or enrichment, entitlements are straightforward and there is limited expectation that later consumers will reuse the connection. Under those conditions, introducing another layer can add latency, complexity and another failure dependency without creating enough shared value to justify it.
This argues for incremental adoption rather than an enterprise-wide mandate. Start with a bounded workflow where shared access, state or governance can create measurable value, establish reusable connectivity and controls, then expand only when later consumers can reuse those assets. The shared layer should earn a broader role through demonstrated reuse rather than architectural preference alone.
Rather than architectural uniformity, the goal is to encourage optionality while creating shared consumption and governance capabilities where reuse genuinely creates leverage. CIOs do not need to predict every future consumer, but their architecture should govern the conditions under which new consumers access, combine and act on enterprise data.
The cloud computing conversation has changed significantly over the past few years. Earlier, enterprises selected cloud platforms mainly for scalability, global reach, agility and cost flexibility. Today, those priorities remain important, but they are no longer sufficient. Governments, regulators, boards and customers are asking a deeper question: where does critical data reside, who can access it, who operates the infrastructure and which legal jurisdiction ultimately governs it? This is the context in which sovereign cloud has moved from a specialist requirement for governments into a mainstream enterprise architecture consideration.
Sovereign cloud refers to cloud environments designed to preserve data residency, legal control, operational independence and regulatory compliance within a defined jurisdiction. In practical terms, it is not merely a cloud region located inside a country. A mature sovereign cloud model includes a combination of local data storage, strict identity and access control, encryption key ownership, local personnel controls, auditability, contractual protections, operational segregation and, in some cases, disconnected or air-gapped deployment options. Its central purpose is to allow organizations to consume cloud and AI capabilities while reducing exposure to cross-border data transfer risk, extraterritorial access concerns and regulatory uncertainty.
Recent trends in sovereign cloud
The first major trend is the shift from data residency to full digital sovereignty. Data residency answers the question of where data is stored. Digital sovereignty goes further by addressing legal jurisdiction, administrative access, operational control, encryption key management and dependency on foreign technology providers. This distinction has become increasingly important as enterprises recognize that locating data in a domestic region does not automatically remove legal or operational exposure.
The second trend is the rapid convergence of sovereign cloud and artificial intelligence. Generative AI and large-scale analytics rely on sensitive enterprise data, customer information, intellectual property, telemetry and domain-specific knowledge. As a result, enterprises are increasingly asking whether AI training, inference, prompts, embeddings, logs and model outputs should remain within national or regional boundaries. Sovereign AI infrastructure is therefore emerging as a natural extension of sovereign cloud, especially in regulated industries and public-sector environments.
Figure 1: Data residency to digital sovereignty.
Magesh Kasthuri
In the figure above, you can see each layer builds on the ones before it, moving from a storage question to a question of legal, operational and technological independence, showing sovereignty is cumulative.
The third trend is the rise of hybrid sovereign architectures. Few enterprises can move every workload into a fully isolated sovereign environment without affecting agility or cost. Instead, many organizations are adopting a layered model. Highly regulated workloads such as citizen services, payment systems, healthcare records, defense data and critical infrastructure systems are placed in sovereign or private cloud environments, while less sensitive workloads continue to use mainstream public cloud regions. This approach allows enterprises to balance sovereignty, innovation, performance and economics.
Figure 2: Hybrid sovereign architecture model.
Magesh Kasthuri
In the figure above, hybrid sovereign architecture model is built as a layered approach that balances sovereignty, innovation, performance and economics.
The fourth trend is the growing importance of local partnerships. Hyperscale providers are increasingly working with regional telecom operators, system integrators, government-backed entities and local infrastructure providers to meet country-specific sovereignty requirements. These collaborations help address demands for local operations, domestic ownership, regional support and compliance with national security policies. At the same time, local cloud providers are refreshing their platforms to offer modern automation, cloud-native services, security tooling and managed operations.
The fifth trend is the growing use of policy-as-code and sovereign-by-design controls. Enterprises want sovereignty to be enforced through architecture, not only through contractual language. This is creating demand for region-locked deployment policies, controlled replication, customer-managed keys, confidential computing, localized identity administration, immutable audit trails and automated evidence collection for regulators and auditors.
Industry adoption of sovereign cloud
Government and public sector organizations remain the most visible adopters of sovereign cloud. Their workloads often include citizen identity, taxation, welfare, defense, justice, digital public infrastructure, border management and national emergency systems. These systems carry high public trust obligations and governments increasingly prefer cloud platforms that provide clear control over data location, local administration, audit rights and national continuity.
Banking, financial services and insurance are also strong candidates for sovereign cloud adoption. Banks handle personal financial data, payment transactions, fraud signals, credit records, trading information and regulatory reporting data. Sovereign cloud helps financial institutions align with central bank expectations, operational resilience mandates, cybersecurity requirements and audit obligations. It also enables safer use of AI for fraud detection, customer intelligence, risk modeling and compliance monitoring.
Healthcare and life sciences organizations are adopting sovereign cloud to protect patient records, clinical trials, diagnostics, genomics data, medical imaging and public health information. The sensitivity of healthcare data makes jurisdictional clarity extremely important. Sovereign cloud can support secure collaboration, research analytics, hospital modernization, AI-assisted diagnostics and telemedicine platforms while maintaining tighter data governance.
Telecommunications providers use sovereign cloud for network functions, 5G core workloads, subscriber data, lawful interception systems, edge platforms and national communication infrastructure. Because telecom networks are often classified as critical infrastructure, sovereignty requirements can influence decisions on hosting, operations, resiliency and supply-chain assurance. Here is a summarized view of various industrial adoption across different use cases.
Manufacturing, energy, utilities and transportation sectors are beginning to view sovereign cloud as part of industrial resilience. Operational technology data, plant telemetry, grid analytics, digital twins, predictive maintenance models and supply-chain intelligence are increasingly valuable assets. For these industries, sovereignty is closely tied to business continuity, cyber resilience, industrial secrecy and national economic security.
Cost implications of sovereign cloud adoption
Sovereign cloud adoption may increase cost when compared with standard public cloud deployment, especially in the early stages. Additional costs can arise from localized infrastructure, dedicated regions, private cloud environments, local operations teams, specialized compliance controls, sovereign connectivity, encryption key management, audit tooling and managed security services. In some cases, organizations may also need to redesign applications to prevent unapproved cross-border replication or dependency on non-sovereign platform services.
However, the cost discussion should not be limited to infrastructure premiums. Enterprises must compare the added cost of sovereign controls with the potential cost of regulatory penalties, reputational damage, business interruption, loss of public trust, failed audits, contractual exclusion from regulated markets and inability to use sensitive data for AI safely. For a regulated enterprise, sovereignty can become an enabler of revenue protection and market access rather than a pure compliance expense.
FinOps discipline becomes essential in sovereign cloud programs. Organizations should classify workloads by sovereignty need, avoid over-engineering low-risk applications, monitor data egress, negotiate transparent pricing, standardize deployment patterns and use automation to reduce operational overhead. A pragmatic cost model normally separates workloads into tiers: highly sovereign, regulated but cloud-friendly and general enterprise workloads. This allows the organization to apply the highest controls where they matter most.
Benefits of sovereign cloud for enterprises
The most direct benefit of sovereign cloud is improved regulatory alignment. Enterprises operating across multiple jurisdictions can demonstrate stronger control over data storage, processing, access and movement. This is especially valuable when serving government clients, regulated sectors or customers with strict data protection expectations.
A second benefit is enhanced trust. Customers, regulators and partners are more likely to support digital initiatives when an enterprise can explain where sensitive information resides, who operates the environment and how access is governed. In sectors such as healthcare, banking, public services and critical infrastructure, trust is not a soft value; it is a commercial and operational requirement.
A third benefit is stronger resilience. Sovereign cloud can support local continuity planning, controlled dependency management, regional disaster recovery and clearer operational accountability. When designed properly, it reduces the risk that geopolitical disruption, foreign legal orders, supply-chain fragility or cross-border service restrictions will affect mission-critical systems.
A fourth benefit is responsible AI enablement. Many organizations hesitate to use AI on sensitive data because of uncertainty about retention, training, inference and cross-border processing. Sovereign cloud provides a more controlled foundation for AI adoption by combining data isolation, model governance, auditable operations and policy-driven controls.
Analyst perspective on future trends
Analyst research indicates that sovereign cloud is becoming a fast-growing part of the cloud market rather than a narrow compliance niche. Gartner forecasts worldwide sovereign cloud infrastructure-as-a-service spending to reach US$80 billion in 2026, reflecting 35.6% growth from 2025 and also notes that sovereign cloud spending could shift a meaningful share of workloads from global to local providers. Earlier Gartner research also projected strong long-term growth for sovereign cloud IaaS, driven by regulatory demand, operational independence and technological autonomy.
Forrester’s recent work on digital sovereignty highlights that organizations are no longer treating sovereignty as a simple data residency issue. Its sovereign cloud platform research emphasizes that different deployment models are required for different risk profiles, ranging from public cloud with sovereign controls to private, partner-operated and disconnected environments. This reinforces an important market reality: sovereignty is becoming a design principle across the IT stack, not a single product category.
IDC’s digital sovereignty research points to regulatory compliance, national and regional legislation, protection against extraterritorial data requests, AI adoption and strategic partnerships as key forces shaping the market. IDC’s infrastructure predictions also caution that sovereignty programs can add cost and complexity, requiring stronger data classification, governance, security controls, partner ecosystems and skills development.
Everest Group’s research frames sovereign cloud as closely connected to sovereign AI, enterprise autonomy, data governance and operational control. Its European sovereign cloud analysis describes a market being shaped by geopolitical tension, stronger privacy mandates, concerns about foreign surveillance laws and the need for clearer sovereignty frameworks across data, operational and technical dimensions. Everest Group’s broader private cloud research also indicates that AI, automation, workload repatriation, hybrid-first strategies and sovereignty mandates are increasing demand for controlled cloud environments.
Conclusion
Sovereign cloud is best understood as a response to a broader shift in enterprise technology: the movement from borderless cloud consumption to governed digital autonomy. It does not reject public cloud innovation; rather, it asks cloud platforms to operate within clearer legal, operational and architectural boundaries. For enterprises, the strategic question is not whether every workload must become sovereign. The better question is which data, systems, AI workloads and business processes require sovereign protection and how that protection can be delivered without slowing innovation.
The future of sovereign cloud will likely be hybrid, policy-driven, AI-aware and industry-specific. Organizations that treat sovereignty as an architectural capability will be better positioned than those that approach it as a last-minute compliance checkbox. The winners will be enterprises that build a balanced operating model: global where possible, local where necessary and sovereign where trust, regulation and resilience demand it.
This article was made possible by our partnership with the IASA Chief Architect Forum. The CAF’s purpose is to test, challenge and support the art and science of Business Technology Architecture and its evolution over time as well as grow the influence and leadership of chief architects both inside and outside the profession. The CAF is a leadership community of the IASA, the leading non-profit professional association for business technology architects.
This article is published as part of the Foundry Expert Contributor Network. Want to join?
Artificial intelligence is still the Wild West. Every organization adopting AI is, in a sense, operating on someone else’s ranch.
Models, platforms and providers are evolving rapidly, and today’s market leader may not hold that position tomorrow. At its core, model independence recognizes that AI models are becoming interchangeable tools with different strengths, rather than technologies organizations should feel obligated to build around. The competitive advantage comes from matching the right capability to the right work at any given moment — not becoming attached to a single model or platform.
Rather than chasing every new release or trying to predict which provider will come out on top, CIOs should focus on building the capability to evaluate, route and adopt models as the technology changes. That starts with understanding how different models perform, knowing when to trust automated model selection and creating processes that can evolve as AI continues to change.
Start with the work, not the model
Model selection starts with a simple question: What am I trying to accomplish?
Every AI model is designed for different types of work, and not every task requires the same level of capability. Some models prioritize speed, while others are built for deeper reasoning. A simple factual question doesn’t require the same computing power as drafting a board memo, synthesizing several documents or optimizing a week’s worth of meetings to make the best use of an executive’s time. Many employees don’t realize those distinctions and will default to the best-known model regardless of what the work actually requires.
Anthropic’s Claude family illustrates this well. Haiku is designed to deliver quick responses to relatively straightforward requests. Sonnet balances speed and reasoning for many everyday business tasks, while Opus is intended for more complex analysis. Recognizing those differences allows organizations to match the right capability to the right work.
The same principle applies inside organizations. Leaders don’t assign every project to their most senior employee. They match the complexity of the work to the appropriate level of expertise. AI should be treated the same way.
This approach also has a direct impact on cost. Brown & Brown applies it in one of its own AI workflows. A lower-cost model orchestrates the agents that scan code to identify potential issues, while a more advanced reasoning model evaluates the highest-risk findings. Using Opus, for example, across every step of that process would be unnecessarily expensive. Instead, the organization gets the level of analysis it needs without paying for the most powerful model at every step.
Technology leaders should encourage teams to think in terms of capabilities rather than favorite models or platforms. Define the complexity of the work first; default to the least expensive model that meets the accuracy, quality and performance requirements, escalating only when additional reasoning or increased accuracy is needed. Just as importantly, evaluate success based on the accuracy and quality of the output rather than assumptions about which model should perform best.
As AI gets better at choosing models, people need to get better at judging results
One of the biggest changes in enterprise AI is happening behind the scenes.
Platforms like Microsoft Copilot and Claude feature “harnesses” that continually improve in their ability to evaluate a user’s request, determine how much reasoning it requires and automatically route it to the model best suited for the task without requiring the user to make every decision manually.
That doesn’t diminish the importance of understanding how different models behave. It changes where employees add value.
Rather than manually selecting a model for every request, employees need to recognize when the platform has made the right choice and when it hasn’t. Auto mode works well for many routine tasks, but it isn’t infallible. Users still need to evaluate whether the response meets the objective, determine when additional reasoning is warranted and recognize when the AI has misunderstood the request.
The same judgment applies as organizations build reusable prompts, AI skills and agents. For example, one of our employees learned this while using Claude to create a presentation slide. The instructions specified using a particular template, and the AI followed them exactly. The result technically met the request but produced a weaker slide than if it had been allowed to choose the format itself. The lesson was about recognizing when instructions — or assumptions — are limiting the quality of the output, not the model itself.
Organizations should also expect workflows to evolve. Model updates can change how AI responds, and accuracy, hallucinations, consistency and output quality still vary across models. Regularly comparing the same task across models, refining prompts and revisiting AI skills and agents help ensure the technology continues to produce the desired results.
As more of the model-selection process becomes automated, organizations should spend less time debating which model to use and more time developing employees who can evaluate AI output critically,recognize when intervention is needed and continually improve how AI is used.
Build an AI strategy that evolves with the technology
Periodically running the same workflow across multiple models allows technology leaders to compare output accuracy, quality, consistency, speed and cost and determine whether another model has become a better fit for a particular step in the process.
Those evaluations should extend beyond general-purpose foundation models. Industry-specific AI platforms, fine-tuned models and specialized SaaS providers may offer stronger performance for common business use cases because they have already configured model selection, data and workflows around a particular industry or function.
CIOs should look beyond the name of the foundation model and understand how vendors select, route and tweak models, how they evaluate new releases and how easily they can introduce another option. Model evaluation should remain an ongoing process, with critical workflows benchmarked regularly rather than only during the initial technology selection.
An AI roadmap should enable the adoption of stronger or more cost-effective models without rebuilding the workflows that depend on them.
Choose partners that think beyond today’s model
Most organizations — particularly small and midsized businesses — won’t build sophisticated model-routing systems themselves. They’ll rely on technology partners, SaaS providers and systems integrators instead.
When you’re evaluating an AI partner, know that the expertise behind the technology often matters as much as the technology itself. Some key ideas:
Look for partners that already support organizations larger than your own and ask how they’re approaching model independence, model selection and resiliency. Those capabilities shouldn’t be nice-to-haves; they should be requirements.
Don’t stop at asking which model they use. Ask what happens when that model changes — or when it’s unavailable.
If an AI provider experiences an outage or releases an update that affects performance, can the partner route work to another model and keep critical business processes running?
Their answers to the above may tell you far more about the resilience of your AI strategy than the name of the model they’re recommending.
In Northeast Greenland, where temperatures can plummet to -40°F, security officials rely on the Sirius Dog Sled Patrol, led by well-trained canines that guard the sprawling, weather-beaten coastline – tundra territory where snowmobiles commonly fail. Tethered together with the right harness that efficiently channels their collective energy toward a shared mission, the sled dogs are more than up to the challenge. But left to run free without the leashes and human guidance, they naturally become a pack of wild animals bent on following their instincts.
Enterprises relying on AI could learn a thing or two from this scenario. In recent years, organizations have depended on copilots and chat-based assistance designed to answer questions or summarize information. These systems have advanced to include autonomous agents increasingly capable of executing workflows, accessing tools, interacting with software and making decisions with limited human oversight. AI has been enabled to serve as a true workforce partner.
It’s an evolution that promises significant productivity gains but requires a more advanced foundation. Even the smartest agents need clear directives and the right connections to successfully maneuver sophisticated enterprise systems and maximize their potential.
This concept has been coming up pretty frequently in conversations I’ve been having with tech leaders lately. When I was in Nashville not long ago for the Insurance Innovators USA conference, and later over a few cocktails with former colleagues near San Francisco, I quickly tuned into a growing trend. Instead of talking about predictable topics like which foundation model was the most intelligent, the conversation veered toward a more thought-provoking challenge: How do we connect and amplify these increasingly autonomous AI systems to yield the greatest value more safely?
The answer to that question represents enterprise AI’s next major opportunity. Organizations are now realizing that capability and raw intelligence are only the beginning: Building the infrastructure that enables agents to perform dependably at scale matters even more.
Operationalizing intelligence
Autonomous agents are a different animal from traditional AI assistants. That’s because they don’t simply generate text; they take resonant action. A self-directed AI agent can, for instance, update customer records, trigger software workflows, initiate financial transactions and coordinate with other AI agents. These proficiencies significantly up their value and turn them into vibrant operational resources. But these assets require a structured environment to succeed. An agentic system can have the necessary tools but lack the right controls to navigate compliance and privacy rules. To tap their full potential, the architecture that effectively directs their actions must exist.
Traditional guardrails weren’t designed for this kind of autonomy. Prompt filtering, simple permissions and basic access controls do the job for conversational AI. But they don’t cut it when it comes to enabling software that makes decisions and interacts with enterprise systems independently. That requires a new level of orchestration.
Enterprises need a standardized control layer for agent behavior, regardless of which underlying model powers them. We have to recognize that intelligence by itself isn’t enough – control is just as important.
Which brings us back to those trusty sled dogs. Think of each dog as a large language model (LLM) task. We often run several LLM tasks within a harness, often involving different models, comparable to a sled team. Just as each dog is positioned for what it does best, from lead dog to wheel dog, a “mixture of experts” delegates each part of the problem to the LLM task best suited to handle it. Without a harness guiding their powerful capabilities for a common purpose and enabling better performance, those LLM tasks, like the dogs, can’t effectively pull the sled. An AI model needs this same type of surrounding governance to reliably perform enterprise work and accomplish its objectives.
An agent harness provides the necessary infrastructure to contain and channel agent capability safely. It securely defines permissions and access boundaries, determines rigid tool usage limitations, manages workflow sequencing, human approval workflows and approval logic and creates audit and observability trails. The LLMs provide raw power, but the harness enables the coordination and audit trails needed to transform AI intelligence into reliable operations.
AI tools are progressing into increasingly dynamic autonomous agents. It’s encouraging to see that organizations have mostly moved beyond experimentation and are finally incorporating AI into production workflows that impact customers and revenue. But that means regulators are paying closer attention, particularly to organizations in insurance, financial services and other highly regulated industries. The architecture facilitating these agents has to be resilient enough to both comply with requirements and foster speedy innovation.
Autonomous AI agents signal a new era of speed and capability, creating exciting prospects for executive leaders ready to scale operations. To take advantage of this momentum, they should ensure that early deployments have strategic guardrails and a clear operational runway for these agents to thrive. The right infrastructure and the ability to interact with multiple software systems enable agents to orchestrate complex, multi-system workflows with precision and high-impact efficiency. That means enterprise-grade governance around agentic systems must improve.
Major foundation model providers are increasingly implementing proprietary harness capabilities directly into their ecosystems. These exclusive harnesses often provide better performance optimization, more seamless coordination and enhanced access to model-specific capabilities. The prevailing industry sentiment is that these environments will consistently deliver the best results. Case in point: If you want the strongest performance from Claude, you’re better off using Anthropic’s surrounding ecosystem and harnessing infrastructure rather than treating the model as a standalone component.
That said, there’s also value in maintaining the freedom to jump between models on a daily basis. Most developers, me included, switch between something like six models daily, whether that’s Claude, Gemini, Muse or an open-source option, depending on the task. That flexibility gets much harder to preserve once a company builds on a provider-specific harness, such as Anthropic. While this will likely improve performance and cut costs, the trade-off is increased vendor lock-in.
This creates a strategic choice for organizations: Fully embrace a vendor ecosystem for immediate performance, or maintain ownership of your own orchestration layer? Use the harness provided by the model provider, or build your own custom harness tailored to your business requirements?
I remain hopeful that many enterprises will leverage vendor innovations, while ensuring their core business logic remains portable instead of embedded within closed proprietary systems. But only time will tell.
The many benefits of harnessed agents
A carefully designed agent harness does more than merely decrease risk. It also lays a foundation for implementing autonomous agents with better confidence. You can count on the safe deployment of autonomous agents in production environments. No more wondering whether or not an agent will exceed its authority: Your enterprise can define exactly what it is permitted to do. A robust harness also delivers fine-tuned control over agent actions and access to tools, including which APIs, enterprise systems and software resources that each agent can invoke. Compliance-ready auditability is equally important for regulated industries.
The bottom line is that you can rely on the right harness to provide better peace of mind, transforming your AI into a transparent operational system that ensures reduced operational risk while seamlessly amplifying automation. The result is scalable AI systems that companies can actually trust.
Trust isn’t guaranteed just because a model scores well. It’s earned via system predictability. As my friend and former Google colleague Ben Mathes warned me, crafting custom rules around today’s models is risky. That’s because every few months, new foundation models make yesterday’s engineering workarounds extinct. We should instead prioritize building robust frameworks that can adapt as models progress.
I believe lasting advantage comes from fat skills – modular, detailed instruction sets that tell an AI agent how to perform a specific task without cluttering its core system – and fat prompts that capture institutional knowledge, along with rigorous backends that meticulously organize enterprise data. This enables the harness to evolve alongside improving models without needing to be completely rebuilt, which means business expertise can remain the primary fuel that powers AI success.
Actionable steps for enterprises
So, what are the best practices going forward? CIOs and CTOs should treat agent governance as a core infrastructure decision. Procurement focus needs to expand from models to platforms to, ultimately, control systems. And enterprises need to understand that competitive advantage will be dependent on three factors:
Safety – Does the model safely do what you wanted to do?
Performance – Does it do it well?
Costs – Does it do it with relatively low expense?
Professionals in this space now face the strategic decision I mentioned earlier: use vendor-provided harnesses and maximize performance, or build proprietary internal harnesses to preserve flexibility and avoid vendor lock-in.
Without a resilient harness, you risk slower adoption due to security concerns. For example, Tesla is rolling out a $200 token-per-month cap on employee spending on third-party AI tools at around the same time a new Claude model debuted with lower per-request token costs. Yes, safety continues to be nonnegotiable. But once you meet that threshold, optimizing performance and expense becomes the Pareto Frontier problem your organization should be closely watching.
The AI arms race is no longer merely about smarter models. Instead, it’s about safely deploying autonomy at minimal cost. That’s why implementing an appropriate agent harness is so crucial. It becomes the critical operating layer that allows intelligent agents to reliably function inside an enterprise.
As we transition to the next phase of AI adoption, control is going to matter as much as capability to executives. The LLM also matters, of course, but without the proper framework, it can’t operate effectively. The organizations that dominate won’t necessarily have the best model; instead, they’ll have the most effective framework for deploying and governing autonomous agents.
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.
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.
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.
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.
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.
Rajjie Sarmey
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.
Across dozens of enterprise procurement reviews, I see technology executives make the same expensive mistake.
They start their cloud AI strategy with the wrong question: “Which provider offers the smartest model today?”
I sat through a meeting where a client’s leadership team listened to a slick 45-minute vendor pitch highlighting benchmark scores, processing limits and exclusive model access. By the end of the presentation, the executives were ready to sign a multi-year, multi-million-dollar commitment just to secure priority access to that single model.
I watched experienced leaders prepare to make a permanent infrastructure commitment based entirely on a temporary technological lead. Signing a long-term contract based on a six-month feature advantage treats a rapidly commoditizing utility service as a permanent asset, while surrendering control over the true intellectual property of your business.
The central strategic axiom
Raw computational intelligence is a rented utility overhead. Proprietary corporate context is owned enterprise capital. Never tie the permanent location of your corporate capital to the temporary rental location of a utility.
The economics of rented intelligence vs. owned capital
The top-performing commercial model on the market today will inevitably be matched or surpassed shortly by a cheaper, faster alternative. AsSequoia Capital detailed in its analysis of market economics, massive capital continues to pour into underlying processing infrastructure, driving the baseline cost of raw intelligence steadily downward toward commodity pricing.
When I evaluate technology investments with CFOs and CIOs, we strictly separate variable operational utilities from durable intellectual property across four strategic dimensions:
Market nature: Rented processing capabilities operate on fast-changing, highly commoditized and declining price curves. Owned corporate context forms unique, proprietary and highly defensible business positions.
Enterprise assets: Rented utilities encompass raw processing power, external models and third-party cloud infrastructure. Owned context includes customer ledgers, internal business rules, compliance frameworks and institutional memory.
Commercial strategy: Rented capabilities require a pay-as-you-go, unbundled approach that embraces maximum supplier churn. Owned context requires total asset ownership, isolated environments and zero vendor lock-in.
Financial objectives: The financial goal for rented capabilities is minimizing marginal cost per transaction. The financial goal for owned context is maximizing long-term enterprise valuation.
Raw processing power should be managed like electricity: your systems connect to the provider, consume what is required for the task and retain total freedom to switch utility suppliers if pricing or performance dictates a change.
Your corporate context, however, is a permanent capital asset. AsHarvard Business Review has demonstrated across past technology cycles, lasting competitive advantage is built on proprietary data, unique operational workflows and institutional memory (never on shared infrastructure). A commercial model possesses zero understanding of your firm’s private pricing structures, key client nuances or regulatory boundaries until you feed it your context.
The mechanics of vendor capture
In my architecture reviews, I constantly see how managed cloud platforms naturally blur the line between rented processing power and owned corporate context.
Integrated cloud environments rarely position processing power as a standalone, interchangeable utility. Instead, platform architectures naturally encourage corporate engineering teams to bundle processing power with proprietary storage formats, closed management tools and native operational frameworks.
I have watched this architectural design trap enterprise teams in three distinct phases:
Data entanglement: Corporate knowledge becomes formatted to fit a specific vendor’s environment, making future extraction costly and complex.
Workflow dependence: Business rules and approval logic are built directly into vendor-owned management software, tying daily operations to their platform.
Loss of leverage: During contract renewals, the enterprise cannot credibly threaten to switch providers because moving away requires a multi-month operational migration.
Once your business rules and customer records are deeply bound to a single vendor’s ecosystem, your negotiating leverage vanishes.
The architectural mandate: Vendor-neutral gateways
To preserve commercial leverage and maintain operational agility, I advise technology leaders to mandate an internal management layer between core corporate applications and external technology providers.Gartner’s strategic cloud planning research projects that the vast majority of enterprise organizations will require a multi-provider strategy specifically to prevent commercial lock-in and control long-term operating costs.
An internal control gateway acts as a central management point. Instead of allowing individual applications to establish direct connections to an external cloud vendor, every application communicates exclusively with your internal gateway.
This gateway enforces three mandatory executive controls:
Cost-optimized task routing: The gateway evaluates incoming tasks and automatically routes them to the most cost-effective external provider available. Routine administrative tasks go to low-cost utility systems, while complex tasks go to high-capacity options.
Centralized data protection: Before corporate data leaves the enterprise perimeter, the gateway strips sensitive customer details and logs the transaction for compliance verification.
Commercial agility: Because company applications interact solely with your internal gateway rather than directly with a vendor, you retain the ability to switch cloud providers instantly. If a vendor raises prices or a competitor releases a superior option, your team simply updates a routing rule within your internal system.
Rent the computational processing power as a temporary utility, but retain total ownership and control over the corporate nervous system.
Every enterprise AI conversation I hear eventually turns to prompts.
Which prompting technique produces the best results? Which large language model reasons more effectively? Which framework generates more accurate answers? These are worthwhile questions, and I understand why they dominate the conversation. Prompt engineering has become one of the most visible aspects of enterprise AI because it delivers immediate, tangible results. A better prompt can transform an average response into an exceptional one within seconds.
But after spending years building enterprise platforms, leading cloud modernization initiatives and operating mission-critical systems, I have reached a different conclusion.
The organizations that ultimately win the AI race will not be distinguished by who writes the best prompts. They will be distinguished by who builds the strongest enterprise platforms.
Prompt engineering can improve the quality of an AI interaction. Platform engineering determines whether AI can become a trusted, scalable capability that transforms an entire business.
This aligns with Gartner’s view that platform engineering is becoming a foundational discipline for improving developer productivity and standardizing enterprise software delivery, creating the operational foundation that AI initiatives increasingly depend upon.
Prompt engineering is only the beginning
Prompt engineering deserves its popularity. It lowers the barrier to entry for AI, allows teams to experiment quickly and helps organizations discover new ways to improve productivity. Business users can automate repetitive tasks, developers can accelerate coding and analysts can uncover insights faster than ever before.
These early successes are important because they build confidence in AI.
However, I have noticed that many organizations mistake successful experimentation for enterprise readiness.
McKinsey has reached a similar conclusion in its research on agentic AI, arguing that lasting enterprise value comes from redesigning workflows, operating models and governance around AI rather than simply deploying increasingly capable models.
Creating a useful AI demonstration is relatively straightforward. Turning that demonstration into a secure, reliable business capability is considerably more difficult.
The real questions begin after the pilot succeeds.
Where does the AI retrieve its information? How is sensitive data protected? Which systems can the AI interact with? How are responses validated? Who owns the workflow when something fails? How are changes deployed safely? How do we measure accuracy over time? How do we maintain governance while allowing innovation?
These are not prompt engineering problems.
They are platform engineering problems.
Enterprise AI is an infrastructure challenge
In my experience, enterprise AI behaves much like every major technology transformation that preceded it. Whether organizations were adopting cloud computing, enterprise integration, DevOps or platform engineering, long-term success rarely depended on selecting the newest technology. It depended on building an operational foundation that could support continuous growth.
AI follows the same pattern.
In an earlier CIO.com article, I argued that the next AI bottleneck would not be the model itself but the enterprise infrastructure surrounding it. The same principle applies here because platform teams are responsible for building that infrastructure at scale.
A large language model does not operate in isolation. It depends on APIs to access business applications. It requires secure identity management before performing actions on behalf of users. It needs clean, governed data to produce reliable responses. It relies on messaging systems, event streams, monitoring platforms, deployment pipelines and security controls to function consistently within enterprise environments.
Every AI interaction touches dozens of enterprise services that most users never see.
When AI performs well, the model often receives the credit.
When AI fails, the root cause is frequently somewhere else entirely.
I have seen situations where outdated data, unavailable APIs, inconsistent permissions or unreliable integration services create failures that appear to be AI problems but are actually infrastructure problems.
The model simply exposes weaknesses that already existed within the enterprise architecture.
Platform teams build enterprise trust
One of the most overlooked aspects of AI adoption is trust.
Employees will only embrace AI if they believe it consistently provides accurate, timely and secure information. Business leaders will only automate critical processes if they understand how decisions are made. Security teams will only approve broader deployment when governance is embedded into the platform itself.
Trust cannot be created through prompts.
It is built through architecture.
Platform engineering teams establish standardized APIs, reusable services, identity controls, deployment automation, observability, logging, auditing and policy enforcement that make AI predictable rather than experimental.
Instead of every business unit creating its own AI implementation, platform teams provide reusable capabilities that allow innovation to scale without creating operational chaos.
That is the difference between isolated success stories and enterprise-wide transformation.
Integration will separate leaders from followers
Throughout my career, I have consistently found that integration determines whether technology delivers business value.
AI is no different.
Every meaningful AI workflow eventually becomes an enterprise integration workflow.
An AI assistant may retrieve customer information from a CRM system, verify inventory through an ERP platform, initiate an approval workflow, update a service ticket, notify a collaboration platform and record every action for auditing.
None of these activities depend solely on prompt engineering.
They depend on reliable APIs, event-driven architecture, secure messaging, resilient infrastructure and well-designed automation.
Organizations that already possess mature platform engineering capabilities have a significant advantage because they can integrate AI into existing operational processes instead of building disconnected point solutions.
The conversation should no longer be, “How do we deploy another AI assistant?”
It should be, “How do we make AI another trusted service within our enterprise platform?”
Platform engineering is becoming AI engineering
I believe one of the biggest organizational shifts over the next several years will be the evolution of platform engineering.
Historically, platform teams focused on developer productivity, cloud infrastructure, automation, observability and operational reliability.
Those responsibilities are expanding rapidly.
Today’s platform teams are increasingly responsible for AI gateways, model orchestration, retrieval services, vector databases, prompt management, policy enforcement, cost optimization and AI observability.
They are becoming the teams that connect AI to the rest of the enterprise.
This evolution requires new skills, but it builds upon capabilities many platform organizations already possess.
They understand automation.
They understand reliability.
They understand governance.
Most importantly, they understand how to create standardized services that hundreds or thousands of developers can safely consume.
That expertise will become one of the greatest competitive advantages in enterprise AI.
Governance must scale with innovation
The NIST AI Risk Management Framework reinforces this approach by encouraging organizations to govern, measure, manage and continuously monitor AI risks throughout the system lifecycle rather than treating governance as a final checkpoint.
As AI evolves from answering questions to executing business processes, governance becomes inseparable from innovation.
Organizations cannot afford to treat governance as a review step that occurs after deployment.
Identity management, access controls, auditability, observability, policy enforcement and regulatory compliance must become foundational components of the platform itself.
The most successful enterprises will not slow innovation through excessive controls.
Instead, they will build platforms where secure innovation becomes the default experience.
Developers should not have to reinvent governance every time they build a new AI capability.
The platform should provide those guardrails automatically.
That is how organizations innovate at scale.
The organizations that win will think beyond models
The AI industry will continue producing larger models, better reasoning capabilities and more sophisticated agents.
Those advances will matter.
But I believe the lasting competitive advantage will belong to organizations that invest equally in the platforms surrounding those models.
Five years from now, I do not think enterprise leaders will remember which company wrote the most sophisticated prompts.
They will remember which organizations built AI platforms that employees trusted, security teams approved, developers embraced and business leaders could confidently scale across the enterprise.
Models will continue to evolve.
Prompts will continue to improve.
The organizations that separate themselves from everyone else will be the ones whose platform teams quietly made AI reliable, secure, integrated and operational.
In the enterprise AI race, that is where the real competitive advantage will be built.
Entrar
