The AI revolution is experiencing some growing pains. Across industries, business leaders are confronting the same challenge: AI pilots dazzle, but they don’t scale. An agent that reasons brilliantly in the sandbox turns unreliable the moment it touches a real, regulated business process. As a result, Gartner projects that more than 40% of agentic AI initiatives will be cancelled by the end of 2027, driven by escalating costs and unclear business value. Most leaders blame the model, hoping a bigger one will close the gap. Or they point to the need for more context because a model starved of the right enterprise data will never perform reliably in production. But even fully supplied context isn’t enough if nothing validates what the model produces. The real design issue is a balance between a system that generates and a system that checks. ### **Give AI a “right brain” and a “left brain”****** Every AI system combines two kinds of intelligence. The neural side—the large language model (LLM)—is fluent,creative, and probabilistic. Think of it as the right brain. The second half, the symbolic side, includes logic, ontologies, rules, and policy, and is structured and deterministic. That is the left brain. While both sides have their strengths, neither is capable of handling complex enterprise workflows on their own. The neural side is an improviser. When information is missing, it generates the most plausible response. That is useful when drafting a campaign or summarizing data. It is risky when deciding whether an insurance claim has been paid or a disputed charge has been refunded. By contrast, the symbolic side, with its rules-based limits and guardrails, is great at enforcing regulatory standards to the letter, but it cannot read a messy customer narrative or generalize past the cases it was explicitly coded to address. ### **Add a governed context layer to the LLM****** This is where finding the right balance between neural and symbolic layers becomes so critical. Over-index on a generalist large language model and you run into problems with exceptions management, edge cases, and governance standards. Go too heavy on a symbolic model, and you lose the ability to interpret and extrapolate unstructured information. What’s needed is a governed context layer that captures meaning, rules, decisions, and institutional memory together. Consider a bank asking whether a disputed charge has already been refunded. A neural model can interpret customer emails, phone records, and billing history, but it may invent a status it cannot verify. A rules-based system can enforce regulatory and customer-protection standards, but it struggles with unstructured language. Put them together, and one interprets the request while the other checks regulations, merchant rules, and precedent before recommending an action with evidence attached. In EXL’s deployments, that neuro-symbolic design increased average accuracy on this type of question from roughly 40% to more than 90%. ### **Match the architecture to the work****** The point is not that every workflow needs both hemispheres. It is that leaders must choose the right balance for each workflow. Some tasks are deterministic. Verifying a customer’s identity should follow rules. Others are largely neural. Summarizing thousands of customer comments into themes benefits from AI’s ability to find patterns, with human oversight. Much of enterprise work sits between those extremes: a model generates, and a rules layer validates before anyone acts. Being able to identify which workflows fit into which bucket is the key to scaling enterprise AI. I would start with three practical moves: 1. **Start narrow.** Choose one high-value domain and one decision the business makes repeatedly. Tie it to a funded outcome, then build the ontology, context, and decision history that the next use case can reuse. 2. **Make context a shared responsibility.** Business, technology, risk, and compliance teams should define meanings, rules, and exceptions together. If context lives with IT alone, the business is unlikely to trust the output. 3. **Be deliberate about what you build and buy.** Own the knowledge that differentiates your business. Partner for specialized ontology, knowledge-graph, and governance capabilities where that improves speed, cost, and control. ### **Build the system of record for judgment****** We have seen this pattern before. ERP became the system of record for transactions, while CRM became the hub for sales and customer relationships. I believe the enterprise context layer will become the system of record for institutional knowledge: the foundation for AI that is intelligent, trusted, explainable, and aligned with how the business works. The winners of the next decade won’t have the best model. Everyone will. They will have designed the best balance between discrete, specialized AI capabilities. Learn how EXL propels enterprises beyond AI ambition to measurable impact by combining the power of data, AI, and deep industry context with trusted execution.

### CIOs, it’s time to rethink your mobile device lifecycle Let’s start with an uncomfortable question: **how much risk is hiding in devices that are no longer receiving security updates?****** Enterprise mobility management (EMM) and mobile device management (MDM) solutions can give IT visibility across a device fleet. But visibility is only part of the equation. CIOs also need to know how long devices will be supported, when they’ll need to be replaced, and what that means for security, lifecycle planning, and operations. When devices are purchased and deployed at different times, lifecycle planning can quickly become complex. **That’s where Samsung Galaxy Enterprise Edition comes in: giving organizations more predictable procurement and lifecycle terms, plus tools designed to simplify deployment and ongoing operations.** ### Take the guesswork out of device refreshes with Galaxy Enterprise Edition Here’s what Galaxy Enterprise Edition can offer, depending on the model and market: * Extended security maintenance releases, with supported models receiving **up to 7 years** —and select models **up to 8 years** —from first global launch. * A **3-year warranty** on eligible devices launched in **2024 or later.** * An extended product life cycle, helping organizations purchase the same device model over a longer period and support more consistent deployments. * Published security update information available through **Knox Admin Portal,** helping IT track security update schedules, release history, and expected update dates. That last one deserves a moment. It turns “When does this device stop getting patched?” from an archaeology project into a quick lookup. IT can see the plan before it becomes a problem. **Key point for a CIO:** Published dates help turn lifecycle risk into something you can plan for. Your security team gets a deadline, procurement gets a calendar, and finance is less likely to discover replacement costs mid-quarter. ### Security starts with the device Predictable lifecycle planning matters. But those devices still need a strong security foundation. That’s where Samsung Knox comes in. Galaxy Enterprise Edition devices benefit from the same multilayered Samsung Knox security platform built into Samsung Galaxy devices from the chip up. On supported devices, that includes Knox Vault, which uses a physically isolated processor and memory to help protect sensitive information such as cryptographic keys from attacks against the main operating system. The distinction matters. Galaxy Enterprise Edition isn’t a separate security architecture bolted onto Galaxy devices. It combines the built-in security foundation of Galaxy with enterprise-focused lifecycle, deployment, and management benefits. **Key point for a CIO:** Device security shouldn’t depend on adding protection after deployment. With Galaxy, security begins with the device itself. ### Knox Suite helps you get moving faster Galaxy Enterprise Edition devices include a one-year subscription to Knox Suite – Enterprise Plan (region-dependent), helping IT teams get the tools they need to deploy, manage, and monitor devices without separately procuring multiple solutions. **Here are a few included products:** * Knox Mobile Enrollment: Streamlines device enrollment and helps keep devices connected to your organization even after a factory reset. * Knox Manage: Gives IT centralized control over device and app policies. * Knox E-FOTA: Gives IT control over OS update deployment, so teams can validate updates before broader rollout. * Knox Asset Intelligence: Provides fleet-wide insights into device health, battery performance, and connectivity. The bigger benefit isn’t simply having more tools. It’s reducing the work required to procure and implement them separately, helping IT move from purchase to deployment and ongoing management faster. **Key point for a CIO:** Knox Suite works alongside your existing EMM, not instead of it. No migration, no rip-and-replace, no six-month project that shows up in next year’s roadmap as someone else’s problem. ### One device portfolio, more enterprise use cases Galaxy Enterprise Edition is available across a broad range of Galaxy devices, including select Galaxy S and A series, Galaxy Tab series, and rugged devices such as the Galaxy Tab Active series and Galaxy XCover series*. That means organizations can support different roles—from executives and knowledge workers to frontline and field teams—while maintaining a more consistent approach to procurement, security, deployment, and management. **Key point for a CIO:** More consistency across your device fleet can mean less complexity for IT and more predictable lifecycle planning. ### Why this matters now Mobile is no longer the convenience tier. It holds the same credentials, the same customer data, and the same access as any laptop in the building—and attackers have noticed. Verizon’s 2026 DBIR found that mobile devices now draw click rates **roughly 40% higher than traditional email,** and that exploiting unpatched software has overtaken stolen credentials as the most common way in. An unsupported device sits precisely where those two trends meet. **Key point for a CIO:** Ask any device vendor for their security support window in writing. The specificity of the answer tells you how much of your lifecycle risk they’re actually willing to carry. Galaxy Enterprise Edition brings together a predictable lifecycle, enterprise deployment and management tools, and the built-in security foundation of Samsung Galaxy devices. For CIOs, that means fewer surprises across the device lifecycle—and a clearer plan from deployment through retirement. *Device availability may vary by region. Contact your local reseller for details or visit samsung.com/business.

Human work has gone through several revolutions over the past few decades, each of them bringing a start to new careers and an end to others. Software careers, which seemed virtually untouchable a short while ago, have been touted as among the most prominent victims of artificial intelligence. On the surface, it’s easy to see why. In the last few years, most enterprises have massively accelerated the rate at which they can produce code, while CIOs reported that tech industry layoffs hit their highest peak since 2024 earlier in the year. If I wanted to, I could now use AI to build a functioning CRM in a few days rather than weeks. With that in mind, it makes sense that senior executives may reconsider how much engineering headcount they really need to achieve their business goals. But would that CRM be fit for purpose, or secure enough to handle sensitive customer and business data? These are areas requiring skilled human judgment, so I’d encourage them to think twice. AI has certainly changed the traditional path of software careers, but the value of knowledge, skills and experience in software engineering remains the same. As Faros AI found over its past two developer reports, AI speeds up individual coders, but review and rework swallow the gains before they reach the team. Poorly run projects will still lead to disappointing results, no matter how fast software teams can now churn out code. And at the rate companies need to be deploying to keep up with rivals, they need people with a sophisticated understanding of their organization to steward AI-generated software towards positive outcomes. The conclusion that software engineers are under threat from AI reflects a confusion about what they do best. Code production is secondary to the ways that truly proficient software engineers think. That’s why I believe that demand for these minds will increase, not decrease, with AI. ## The Jevons Paradox When new resources increase efficiency, it’s instinctive to think that the consumption of that resource will drop; the Jevons paradox observes that the opposite tends to be true. Coal and steam made factories more efficient, prompting more tycoons to open factories and increasing overall consumption. As we’ve become better at generating electricity, we’ve found more uses for it, and consumption now dwarfs what was ever thought possible. The Jevons paradox is not a promise that demand will always rise after an efficiency gain, but it is a useful lens through which to understand why software engineering will survive the AI boom. According to GitHub’s 2025 Octoverse report, developers pushed nearly one billion commits in 2025, a 25.1% year-on-year rise. Businesses are demanding more features and value as lower development costs make previously unviable levels of output more achievable. So, it makes sense that software engineers capable of using AI to accelerate business value are going to be asked to create more of that value. Completing that loop, as my own business produces more value with more code, I’m inclined to hire more software engineers to manage more teams of agents, not fewer. The employment outlook gives CIOs another reason to avoid making knee-jerk workforce decisions on the basis of short-term excitement. In July 2026, the U.S. Bureau of Labor Statistics projected that the number of software developers will grow 15.8% from 2024 to 2034, adding 267,700 jobs, even as it accounted for the spread of AI technologies. The shape of those jobs will change, but the need for people who can turn technical capacity into business value is not disappearing. ## Lazy in, lazy out AI will only be an accelerant for people who are able to apply it without outsourcing their thinking. There’s a big difference between asking an AI to write a strategy document for you, and asking it to challenge a base level of thinking that has already gone into the task. Treating AI as a ‘sparring partner’ to refine work rather than deferring to whatever it produces will naturally lead to far better results. This is a mindset that those responsible for hiring, including myself, are looking to foster in software teams. AI amplifies the need for thinking that differentiates talented software engineers, who need to grasp why they’re doing the tasks they’re doing and what differentiates their organization in order to make a difference. Early career developer roles typically involve churning through tickets, but that skill falling down the order of priority doesn’t pull the rug out from under their development. It should instead free up more time for them to learn about their organization and grow into better problem-solvers. I think about agents as virtual teammates. I wouldn’t hire a colleague and expect the first piece of work they return to be perfect. Colleagues need to be effectively onboarded and supported with context about the organization and its goals before they start producing value. A lazy prompt with incomplete context is simply a faster way to create something that looks plausible but does not solve the right problem. ## Software engineers as foremen Software engineers managing AI-assisted teams are becoming almost like ‘foremen’ — setting the direction of work, making sure agents have the right context and intervening when output falls short of requirements. Research from Gearset found that 82% of Salesforce teams trust AI to take on tasks in the build stage, dropping markedly to 58% at release. Routine configuration changes and writing tests used to be manual and time-consuming, but these are jobs teams feel most comfortable delegating to AI now. That leaves more space for engineers to manage the delegation of tasks and strategically build trust in AI. AI has opened up more workstreams that can move at a faster pace at large organizations, meaning quality control is now the main imperative. This leaves an opportunity for software engineers to set intent, enforce standards and get closer to their business. This change also has implications for junior engineers, who have traditionally learned a codebase through completing routine work. If AI performs all of this kind of work, leaders must be more deliberate in their approach to hiring early-career engineers: training them to explain the thinking behind projects and get more involved in architectural discussions. The objective is not to create more work for the sake of it, but to preserve and develop the problem-solving skills that help enterprises maintain quality at scale. These skills aren’t new: the order of priority has simply shifted as the process of coding has become faster. ## Deploy safely, or don’t deploy Quality control is the primary challenge that has arisen from AI coding, and that is where engineers can make the most difference. They define what good looks like, for AI and human work alike, and make sure that all software changes are both safe to reach production and relevant to their business goals. Software engineers supply the context and experience needed to make sure code is genuinely ready for production. An agent can generate a change that appears correct in isolation, but it does not necessarily reflect the surrounding architecture or the consequences of failure for customers and employees. This is why demand will continue to improve for engineers who can turn higher output into safe, useful deployments. It’s crucial for AI-generated changes to pass the same version control, testing, security scanning, approval and auditing processes as human-written work. Engineers must set those standards and identify the right places where deterministic checks can replace manual reviews. Engineers will play a huge role in helping CIOs decide what work can sensibly be trusted to AI, while keeping teams accountable where human oversight is necessary. The role therefore moves beyond writing each line of code and towards governing the whole path from intent to production. AI can accelerate the work between those points, but it cannot assume accountability for the outcome. ## AI can be a force for good I see AI as a positive force for the software industry if organizations give engineers the space to make more use of their critical thinking skills. When automation is used primarily for cost-cutting or headcount reduction, you disregard the critical thinking skills that make engineers so adept at improving the systems and products they build. In an environment of psychological safety, where safeguards are prioritized over pure productivity, there is high potential for skilled software engineers to steward projects towards success at a much faster rate than was previously possible. Lazy inputs lead to bad outputs, but the best software teams are full of problem solvers with deep knowledge of their organization. You can’t outsource their thinking to AI, and the most successful companies in this era know that.

AI models are becoming short-term tenants in long-lived enterprise data estates. Yet many organizations are remodeling the building around each new occupant. The market keeps asking which model enterprises should trust: open or closed, domestic or foreign, one frontier provider or another. These are legitimate questions. They are also questions with a very short shelf life. Model rankings change by the month. Providers change terms, regulators redraw boundaries and capabilities that looked scarce six months ago become commodities. In my experience, enterprise data doesn’t move at that speed. Neither do the controls, applications and business processes built around it. That mismatch is why the most important AI architecture decision for CIOs is no longer which model to choose. It is whether the enterprise can absorb continuous change without fragmenting its data estate or surrendering control. The winners in enterprise AI will be those who build a data foundation extensible enough to accommodate it ,build a data foundation extensible enough to accommodate that ongoing change and sovereign enough to remain in control. ## Extensibility is now a production requirement During experimentation, architectural limits are easy to hide. A team can connect a new model to a copied dataset, prove a use case and call the pilot successful. Production exposes the real architecture: identity, permissions, data residency, lineage, latency, recovery and cost. Every time those controls are rebuilt around a model, the model becomes a dependency. Adding or changing capabilities can mean moving data, recreating access policies, revalidating pipelines and reopening compliance reviews. What looked like speed at the pilot stage becomes a maze of point-to-point architecture that is difficult to extend and even harder to govern. This isn’t a hypothetical. A Harris Poll surveying 600 CIOs found that 81% expect to rely on two or more large language model providers in 2026, and 93% say different models perform better for different use cases, requiring ongoing evaluation. More than half also noted they’ve switched providers at least once already, mostly to cut costs. This is consistent with our observations in the field: Multi-model is not a future scenario CIOs plan around. It is the operating condition they’re already managing now, whether or not the architecture underneath was built for it. The gap between expectation and architecture is where the real cost surfaces. When a model is deeply embedded in application logic, data pipelines and prompt structures, replacing it with another provider turns into a multi-quarter engineering project rather than a simple configuration change. Teams end up paying twice, once to adopt the new model and yet again to unwind everything wired to the old one. This helps explain why AI experimentation remains far ahead of AI value. CIO.com’s 2026 State of the CIO survey found that only 19% of respondents said their AI initiatives had met or exceeded business goals. Architecture is not the only reason, but systems optimized for the first model demo rarely become durable production systems by accident. I recommend that CIOs add extensibility and control to the familiar measures of performance, security and cost. Can a team introduce a new model without relocating governed data? Can it change the deployment environment without rebuilding the application? Can it add a new way to query data without creating another synchronized copy? If the answer is no, the enterprise is extending its AI capability by fragmenting its control. ## Put control where the durable value lives Models are increasingly interchangeable. Enterprise context is not. The distinctive asset is the governed body of customer history, operational state, intellectual property and institutional knowledge that gives a model something useful to reason over. That makes the data layer the durable control point. Identity, access, locality, audit and policy should be enforced as close to the data as possible, inside an environment the enterprise can operate, extend and move. The model can then be inspected, sandboxed or replaced within those boundaries. A common pattern shows why. A team wires retrieval and access controls directly against one model’s embedding format and API to get to production faster. A year or two later, a new regulatory requirement or a stronger-performing model prompts a switch. Governance fenced around the original model will result in rebuilding access policies, revalidating pipelines and, ultimately, reproving compliance inside the new vendor’s environment. Governance enforced at the data layer, on the other hand, allows the new model to inherit the operating policies and audit trail from day one, maintaining the existing fence even as the model changes. This does not make model provenance or security irrelevant. It makes those risks containable. Governance attached separately to every model is a collection of fences that must be rebuilt whenever the vendor changes. Governance anchored in the data layer is the property line: The tenant can change and the building can expand without changing who controls the grounds. That is what sovereignty means in operational terms. It is not only where data is hosted but who can govern, move and extend the environment on their own terms. ## Ask what the enterprise still controls Before approving the next AI platform, CIOs should ask three questions: 1. Can this architecture absorb a new model or workload without moving governed data? 2. Which governance controls remain ours if the provider, region or deployment model changes? 3. Does adding this capability extend the foundation or create another data copy, control plane and dependency? These questions become more urgent as agents move into production. Agents multiply quickly; they act across systems and they need the governed data the enterprise already holds. When controls are enforced where that data lives, every new agent inherits them by default. Without that foundation, each agent brings its own pipeline, permission model and place to store what it needs, and the governance burden grows with every agent added. IBM’s Institute for Business Value surveyed 2,000 technology executives in 2026 and found that businesses building control into their AI systems deploy 16 times more AI agents than those relying on manual governance, while spending a fraction of the budget to get there. This research is consistent with what I’ve seen in the field. In our research report with MIT Technology Review, we found that 95% of enterprises are planning to establish their own AI and data platforms within the next three years, and the 13% most committed to sovereignty are already delivering 2x more agentic and generative AI applications in mainstream production. Businesses designing for adaptability early on are more likely to keep their workloads portable and have an easier time replacing models, instead of getting locked into hard dependencies. These businesses also reported a meaningfully higher return on their AI investment. There’s a clear gap that traces back to architecture. Whichever model a business happens to select matters less than whether the foundation underneath can absorb the next one. The next model announcement will attract the headlines. The more consequential work sits underneath it: building an extensible data foundation that can accommodate the next model, the next regulation and the next workload while keeping data under consistent enterprise control. The smartest AI strategy is not a perfect bet on today’s model. It is a data foundation that can keep extending without ceding authority over the data it serves. The building should outlive the tenant, and no model or platform should ever hold the deed to the enterprise’s data.

* * * In July 2025, Jason Lemkin, founder of SaaStr and a well-known investor in enterprise software, decided to publicly test one of AI’s most repeated promises: that anyone can build an application without programming, simply by giving instructions to an agent. He chose Replit, a platform presented as the safest place to do so. He gave himself 12 days and worked with real data, documenting his progress on X and on the SaaStr blog. The experiment soon went awry. The agent made changes no one had asked for and fabricated data. Lemkin decided to put a stop to it. He gave the agent an unambiguous written order: not one more change without his permission. Even so, on the ninth day, the agent deleted the entire database: more than a thousand records of executives and companies. According to the explanation the agent itself gave later, it had found some empty results, took them for an anomaly, and decided to correct it on its own. Lemkin, as the customer, asked whether there was any way to recover the data. The agent replied that there wasn’t: It had destroyed all the versions. But that wasn’t true. The customer tried to restore the database himself, and it worked. The data was never lost. ## Corrective action Amjad Masad, CEO of Replit, the platform on which the project was developed, publicly acknowledged the incident. He called it unacceptable and said that something like this should never have been possible. He explained that the agent did not have access to the platform’s internal documentation, and therefore claimed that the data could not be restored. He offered a refund and announced an investigation into the incident. Replit subsequently introduced two changes, each addressing a different issue. To prevent further data loss, the company separated the live data from the environment in which the agent operates: while developing, the agent can no longer modify it. The company had been preparing this separation for a couple of months. To prevent another problem surfaced by the SaaStr incident, Replit changed the agent’s instructions: It must consult the documentation before responding about the platform and offer restoration when necessary. Less than two months after the incident, Replit closed a $250 million funding round and launched its most autonomous agent to date: ten times more autonomous than previous versions, according to the company. Masad stated at the time that the company was positioned to become the standard for businesses. The two corrective measures addressed the two failures in that incident. But the question remains whether such measures are sufficient when dealing with increasingly autonomous agents. To answer that, we need to understand why they failed. ## Too many functions in a single agent The deletion wasn’t a case of disobedience. The agent was working under two instructions: that the application should function and that nothing should be touched. As long as everything was working properly, both could be followed. When what appeared to be an anomaly transpired, those two instructions became incompatible, because correcting the issue required making a change. In the end, the first order prevailed. No one had stipulated that making the application work outweighed the prohibition. The agent simply decided it should. This matters because a person and an agent treat a prohibition differently. For a person, prohibitions usually function as boundaries. For an agent, it’s just another instruction, competing with all the others at every step. Faced with a specific and recent anomaly, a prohibition written days earlier carried less weight. That’s why no order, however well-written, is guaranteed to be followed. In this case, the order prohibited the agent from accessing the database, but the agent’s permissions still enabled it to do so. This conflict can have far greater consequences in business contexts. An agent that manages invoices, orders, or access also works with a goal and with restrictions, some imposed by regulations themselves, and may find itself in situations where achieving the goal requires overriding some of them. What’s at stake is no longer the database of an experiment, but the consequences for the business. Gartner predicts that by 2027, four out of 10 companies will demote or retire autonomous agents due to governance flaws discovered only after a production incident. But there’s a second, less visible, yet more revealing flaw. Replit had the proper controls in place: working restore copies that the agent hadn’t been able to delete. But the customer was unaware of them. To find out whether there was a solution, they did what they’d been doing for nine days: ask the agent. And the agent replied that there weren’t any backups. The problem wasn’t just that wrong answer. It was that the customer had no other source available: For nine days, asking the agent had been their only way of finding out anything. When that source failed, there was no other way to verify it, and a mistake that could have been fixed seemed irreparable. The same applies when trying to understand what happened. The only explanation for the deletion is the one given by the agent itself. To reconstruct the events, we also have to go through the agent. That is, through the very system that made the mistake. That’s the crux of the problem. In a single incident, the agent fulfilled three distinct roles. It acted, by deleting the database. It informed, by stating that there was no way to recover it. And it explained, by providing the only available version of what happened. These are three functions that any organization keeps separate for a simple reason: If the person who acts is also the one who reports and explains, no one else can detect their mistakes. A CIO understands this principle from other processes. The person who makes a payment is not the one who authorizes it or audits it. With an agent, that concentration isn’t decided by anyone; it happens by default. That’s why it’s a difficult risk to see: While the agent is right, it goes unnoticed; when it makes a mistake, there’s no one left outside of it to check. ## Three measures to separate what the agent concentrates For a CIO deploying agents, separating these three functions doesn’t require new technology. It requires applying the same criteria to agents as are already applied to people: The person performing a task cannot be the only one controlling it. In practice, this translates into three measures. The first step: Remove the agent’s access to what it shouldn’t touch. Many companies restrict their agents with instructions like “do not modify the customer database.” That instruction doesn’t prevent anything: The agent is aware of it but can choose not to follow it. What does prevent it from taking action is denying it access. If the agent only has permission to read the customer database, they cannot modify it, regardless of any instructions. The practical approach is simple: Review every written prohibition for an agent and check whether there’s a permission behind it that can be revoked. The second point is that the log of the agent’s actions should be inaccessible to the agent. When something goes wrong, the first explanation available is usually the agent’s own. This is helpful, but it doesn’t prove anything. What serves as proof is a log kept by the platform that the agent cannot modify: what it did, when, and on what data. It’s advisable to require this log from the provider before signing a contract. If it hasn’t been generated before the incident, there will be no way to know what the agent did afterward. Third: Know how to perform recovery without asking the agent. Working backups are of little use if the only way to know they exist is to ask the agent. Recovery procedures must be documented externally, and the team must be familiar with them. To verify this, simply run a simulation with one rule: Recover a system without consulting the agent. If the team fails, then they are relying on the agent. And the day the agent fails, their only option will be to ask the system that just failed. Applying these three measures to a single agent is simple. The challenge arises when the number of agents multiplies: one for invoices, another for orders, another for access, each with their own permissions and explanations. At that point, the question that determines whether a company is managing its agents effectively is no longer what the agents can do, but what the agents shouldn’t do on their own. The organization must have a clear answer to this question before putting each agent to work. And no one is better positioned than the CIO to address it.

Every CIO can produce an AI adoption dashboard: licenses purchased, seats activated, prompts submitted per week. Boards ask for these numbers, vendors report them and they climb every quarter. What none of them show is whether the tool earned a durable place in anyone’s work. A license counts distribution, not value. An activated seat tells you someone clicked through onboarding once. A prompt count rewards the person who tried a tool five times before giving up exactly as much as the person who uses it daily and depends on it. Most CIOs concede that much, yet little better has replaced it. Across the C-suite, only 31% of leaders expect to measure generative AI’s return on investment in the next six months. In most boardrooms, adoption metrics are not supplementing ROI; they have replaced it. Worse, these are usually not your numbers. In most SaaS deployments, the vendor defines the usage metric, instruments it and reports it back in business reviews. That is standard commercial practice rather than bad faith, but it means the criteria behind the number are built to justify license utilization rather than audit your workflows. The metric that actually shows whether an AI tool works is the one missing from the dashboard: abandonment. It tells you who tried a tool and walked away, how quickly they stopped and where the workflow broke down. Abandonment is not a vanity metric in reverse. It is the one signal your people produce rather than your vendor. Every day someone decides whether to open the tool, paying in attention and habit. Continuing to pay that cost is a judgment; walking away is the opposite judgment. Nobody fakes that behavior for a dashboard. ## Three patterns, three problems Not all abandonment means the same thing, and treating it as one undifferentiated category of failure misses the fix each pattern actually needs. * **Never adopted** is the cleanest signal: a license was provisioned and never meaningfully used. I see this most often when a tool was bought at department-head level to hit an adoption target, then pushed to teams never consulted on whether they needed it. The fix is not more training; it is asking whether the team had the problem the tool solves, and reallocating the seat if not. * **Tried and dropped** is more useful: someone engaged, hit a wall and stopped. The walls are usually mundane. Code-assistance tools get abandoned when they lack system context, turning every suggestion into something to verify rather than accept. Drafting assistants get dropped when their tone misses a brand voice reviewers must enforce, making output slower to fix than to write. A short conversation with a few droppers, rather than a survey, surfaces that wall faster than any analytics platform. * **Usage decayed** is the quietest and most dangerous, because it looks like adoption in every snapshot except the trend line. A tool drifting from daily to monthly use is dying slowly, yet most dashboards report only the latest snapshot. Decay usually points to a tool that solved an initial novelty task and lost relevance as workflows evolved, or to output that never crossed the trust bar, reducing the tool to an occasional first-draft generator. None of this is free. On a thousand-seat agreement, 20% never adopted and 20% dropped is 400 licenses you are paying for and nobody is using. ## Measuring retention without a new platform You do not need a new analytics platform to track abandonment. Cohort retention, standard in consumer software for two decades, works just as well on internal AI tools. Group users by the month they first activated a license, and check what percentage still actively use the tool at week 1, week 4 and week 12. Track retention by monthly group rather than policing individuals. An individual might pause usage for a vacation or planning sprint, and scoring individuals invites employees to game the metric with dummy prompts. When 40% of the March group stops by week 4, you see a product failure, not a personal one. Unlike surveys or manager assessments based on opinion, cohort retention measures actual behavior. The log already knows who stopped. To build the curve cleanly from existing logs, follow three practical rules: 1. **Count intentional actions, and compare against two baselines.** Use single sign-on, network or vendor logs, and count active choices (submitting a prompt or accepting code) rather than background plugins loading on startup. Compare active week-12 users against two starting baselines: total licenses purchased and users who logged in at least once. Comparing against purchased licenses exposes wasted budget from a stalled rollout; comparing against users who tried the tool exposes whether the product delivered value in daily work. 2. **Read where the drop-off happens.** A steep drop in week 1 points to broken onboarding or poor role fit. A slow bleed between week 4 and week 12 points to workflow friction once curiosity wears off. With no industry benchmark for internal AI tools, compare each tool against your other AI tools on the same teams, and this month’s group against last month’s. A curve that flattens has found durable value; one still falling at week 12 has not. 3. **Check for model changes and tool switching.** AI vendors retune or swap models between releases without notice, so a sudden drop in May might reflect a model update rather than workflow friction. Just as often, employees who drop one tool have simply switched to another approved assistant or gone around IT entirely, with more than 12,000 shadow AI applications already operating inside enterprises and 50 new ones appearing daily. Checking overall AI activity across a team alongside tool-specific retention shows whether employees rejected AI or just rejected that vendor. ## What changes at renewal Tracking abandonment pays off when contract renewals arrive. Right now, most renewal decisions rely on cumulative adoption numbers that were never designed to show whether a contract is worth keeping. Abandonment data gives you a cleaner three-way split. Tools with high never-adopted or tried-and-dropped rates should be candidates to drop outright, regardless of how the usage dashboard frames it. Tools with decaying usage are candidates to repair, through a targeted workflow fix, a better integration or retraining on the tasks where trust broke down. Tools with genuinely sustained retention are candidates to concentrate spend on, including expanding seats faster than the standard rollout cadence would suggest. Where two tools serve the same population, the one holding its cohort should be taking seats from the one that is not. And put two asks into the next agreement you sign: define what counts as an active user before signature, and require event-level usage export rather than the summary dashboard. That is the difference between measuring this properly next year and relitigating definitions in a business review. ## Why mandates and retention targets backfire The first is mandating usage. Mandates destroy the signal permanently: the moment usage becomes compliance, behavior stops meaning anything. Some users concluding “not for me” shows the evaluation is working. The correct abandonment target is not zero. The second trap is treating healthy retention as proof of delivery. Abandonment runs cleanly in one direction only: someone who learned a tool and dropped it returned a clear verdict, but someone who kept using it tells you less than you think. Even in controlled trials, experienced developers working in familiar code took 19% longer to complete tasks with AI tools while believing they were 20% faster. Because writing code was rarely the bottleneck, pair retention with delivery metrics tracking downstream rework, code churn and peer review cycles, not just time-to-code. If cycle time has not moved after a year of healthy retention, the thesis you bought on is dead. ## Where to start before your next renewal None of this requires a new program. Pull the activation dates you already hold, build one retention curve for your three largest AI contracts, and check week 4 and week 12. For most organizations that is an afternoon. Put a quarterly 15-minute review on the calendar with each platform owner to inspect the retention curve and the provisioned-to-sustained gap. That review belongs with whoever owns the platform workflow, not procurement; fixing a decayed cohort means changing the rollout, not renegotiating unit price. Watch retention within a cohort rather than raw headcount: durable use in a small high-value team beats thin adoption across a large one. Keep your adoption numbers to see whether teams are willing to try something new. But before your next renewal, ask for the retention curve. Adoption tells you what you bought. Abandonment tells you what to keep.

In an August 2026 Gartner report, 40 percent of C-level executives say their organizations have “operationalized AI in some business processes,” yet only 13 percent say they have “achieved measurable results and are scaling AI across the organization.” This disconnect reveals a frequent reality: AI may have been “hired”, but companies haven’t onboarded it effectively. Research from HR analyst firm The Brandon Hall Group found that organizations with a strong people onboarding process improve new hire productivity by over 70 percent. Similarly, the first period of AI’s “employment” in a specific role largely determines how effectively it will perform and its perceived “growth potential”. But many tech executives are ignoring this crucial stage of the implementation process and are left with AI systems that cannot accomplish the complex tasks they’re assigned. The most successful companies are those that treat AI like their newest hire instead of a long-tenured team member. ## Onboarding AI means establishing the right context and connections Establishing the AI’s persona, the context in which it operates, how it assesses itself and the people and systems to which it is connected are what define implementation success. Usefulness quickly diminishes when even one of these elements is left out of the onboarding process. For example, we recently created an internal agent called ‘WorkRadar’ that surfaces missed tasks and answers questions like: “I’ve been on PTO, what’s the summary of what happened, what should I skim and what should I review in detail?” We gave this agent all potentially useful context by connecting it to Outlook, Microsoft Teams, Confluence, Asana, SharePoint, meeting notes and our human resource information system (HRIS) so it could determine the responsibilities of the person invoking it and infer topics of interest. Much like a new employee, however, WorkRadar couldn’t derive the _meaning_ behind this information without further guidance. When I first used the agent, it did not distinguish between strategic priorities and tactical work and also missed initiatives I sponsor across departments, outside the typical hierarchy. This version of WorkRadar did not _know_ me enough to be useful and I was better off doing the work myself. Instead of leaving WorkRadar to flail as-is, we further onboarded it by enabling users to provide the agent with a personalized description more detailed than it could infer through company documents alone. This included their own responsibilities, operating level, current priorities, key stakeholders for specific initiatives and communication style. For most workers, this is less than one page of short bullets and has made a significant difference. Now, many of our employees rely on WorkRadar like they would a stellar executive assistant, to ensure relevant outstanding to-do items don’t fall through the cracks and smooth their return from PTO. ## Five principles that define AI success WorkRadar’s improved onboarding illustrates the essential elements for priming AI. Managers should define each AI agent’s: ### 1. Role Articulate the AI agent’s position and purpose in the organization; everything else derives from there. Tech implementers should determine if the AI agent should act as an employee avatar with the same access rights, a simpler approach, or act under its own identity, which is increasingly becoming best practice for governance, risk and compliance reasons. Implementers should also decide whether the AI agent “sits” within their infrastructure or their vendor’s. Tech executives can determine this by assessing their companies’ business context, security posture and preference for hands-on involvement with agents. For companies like ours with more than one agentic stack, we have agents that sit in both places. Finally, they should define which employee will be an agent’s supervisor, and the specific contexts in which AI stops for human review. It’s a huge mistake to have no ownership of a tech component and no human in the action or feedback loop to improve performance and address errors. ### 2. Remit Articulate the outcomes this agent should achieve, then identify the systems it’ll need to access for information and to carry out its work. First, tech implementers must give AI read-write access to the systems it will modify via MCPs, tools, skills, APIs, just to name a few methods. This boundary-setting will determine AI’s “sphere of influence” (what we want it to access) and its “blast radius” (the systems we accept it may access and must protect from misuse). To give AI guidance, employers must also give AI read access to job-relevant corporate directories and policies, so the agent knows how to navigate the organization and where to direct communication, as well as company strategy documents and project management trackers, so it can understand the “why” behind its work. Control and security are a complex topic but, at a high level, implementers must also provide access to lists of governance and compliance limitations to define the boundaries by which agents must abide, plus tradecraft standards and procedures so the agent acts in accordance with industry and corporate best practices. ### 3. Personality A huge amount of information could, and eventually must, go into an agent’s context. However, Agents have finite memory and focus, so, like people, they are easily overwhelmed with too much information. So, tech implementers must pick and choose which parts of the agent’s context are permanent and imbued in every task versus derived just-in-time by the agent. This is the art and science of context engineering and it’s evolving rapidly. Elements that are omnipresent in all agent actions – persona, strategies, guardrails, etc. – constitute its system prompt. They’re written directly into the agent’s context by the user, system administrator and the agentic harness on a per-job role­ basis. Meanwhile, employers should also define elements the agent derives in real-time. Frequently, the performance of an agent is determined in this probabilistic work, which is why delineating what’s permanent versus conjured in the moment can make or break an agent’s efficacy. It’s a balancing act that’s costly on both ends: too much context, and the agent chases expensive side quests. Too little, and the agent burns resources discovering what it needs. Best practices ebb and flow, with foundation companies like Anthropic recently advocating for brevity, trusting increasingly stronger models to figure it out. ### 4. Performance review Give AI the necessary tools and context to assess itself. Otherwise, the agent will be blind to its actual impact and require too much course-correction. Ideally, employers give the agent a tool to capture and update new memories, including condensed feedback it has received or epiphanies it discovered itself. Ensuring an agent has this learnings memory bank will make it more performant over time since it does not have to repeatedly solve the same problems and can apply context across disparate tasks. Finally, on a regular basis, the agent’s supervisor must evaluate its work by looking at actual outputs and giving the agent examples of its best and worst work so it can understand actions to continue and stop, respectively. These good and bad examples can be generalized and bundled, and supervisors can then test the AI against them to continually adjust for behavioral shifts. This may be the most neglected activity, yet the one most likely to turn a mediocre agent into a valuable colleague. ### 5. Teamwork Lastly, permit AI to access specific communication surfaces like internal email and messenger platforms and interface with employees. For multi-agent orchestration, employers will have to open communication among agent “colleagues.” Each agent needs an awareness of collaborators and means to exchange messages and share files, all while continuing to involve human supervisors, who won’t inherit any errors that upstream agents might pass on to others. Grok and Hermes debuted bots with this capability in August 2026. _Defining AI’s role, context, persona, assessment frameworks and team connections is essential for successful implementation._ Pearl ## Even with context, AI is still missing key working principles Two additional considerations make AI that works like a veteran instead of a new employee. **First** , tech implementers should realize AI’s memory is less focused than humans’. AI quickly becomes confused about core information versus extra details and can even lose parts of its “knowledge” because its effective context window is still only about 200K tokens. AI is also prone to “anchoring,” persistently latching onto a throwaway comment or early thought. The implication for agentic AI users is to start fresh sessions much more frequently than might feel natural or to tap into continually evolving techniques to manage context, including compaction, truncation and summarization. Agentic platform makers have started to build this into their harnesses, but it’s still far from “set it and forget it”. **Second** , and perhaps most frustrating of all, is AI’s myopic focus on its task without care or curiosity about the greater context surrounding it. This behavior causes it to implement solutions that miss important success criteria or violate critical constraints. In this sense, AI grants one’s wishes a bit like a genie, so be careful what you ask for and how you ask for it! For example, left unprompted, coding agents are a bit too quick to jump to implementation. One architect solved this by creating a workflow that forces the agent to _interview the developer first,_ sometimes asking upwards of 40 clarifying questions, to surface missing requirements and edge cases before writing a single line. Some agentic coding harnesses now perform developer interviews, but there’s still room for improvement. These deeper techniques highlight that agents need more than a good initial onboarding; they need an iterative management approach, just like humans. Many CIOs today are looking to use AI more for innovation and modernization than sheer productivity. Assume AI already knows the job and you will be frustrated when it falls short. Treat it like a new hire and it will grow into one of your best.

Google seems to be making a strategic play to control the AI infrastructure layer, not just roll out another shiny new agent. At its Gemini at Work 2026 event this week, the tech giant unveiled what it calls a “single, universal agent” and API in Gemini that can be kicked off from a simple prompt box. Like other available agents, it is plugged into skills, tools, and enterprise systems, can answer questions, create media, and write and run code, return finished work via of documents, inboxes, and developer environments, and spin up sub-agents to help it do its job. But Google isn’t just looking to go toe-to-toe with existing offerings, or trying to convince enterprises its models are qualitatively and quantitatively superior, said independent tech analyst Carmi Levy. “Instead, it’s trying to establish itself as the gatekeeper of the new enterprise operating system, powered by whatever underlying model makes the most sense,” he said. ## ‘Omnipresent access,’ orchestration capabilities Google says its Gemini agent works autonomously from a single interface, and can function as a personal assistant or team member, akin to a project manager or analyst. Coworker agents can perform tasks across days, sessions, and shifting responsibilities; they have dedicated identities, and are given their own _@agents.company.com_ emails and persistent storage. However, Google says, they only have access to specifically-defined data and channels. Enterprise-dictated security, governance, and cost controls are built-in. “You give it objectives, not instructions,” Google Cloud CEO Thomas Kurian said in his keynote. “Work now starts in the prompt window.” The agent runs in the cloud and has “omnipresent access,” meaning it can work on nearly any device, including iOS and Android phones or Windows and Mac desktops, he said. It can also be accessed through any channel, including command line interfaces (CLIs), Google Workspace, Microsoft 365, or Slack channels, and when integrated into third-party apps. When needed, it also works as a headless agent, or even without a dedicated user interface. Working autonomously, the Gemini agent can spin up temporary or job-specific underlying agents and communicate and coordinate workflows with them to orchestrate multi-step tasks. These include parallel and sequential steps that might run for hours or days, Google said. Notably, the agent is given the flexibility to choose which model should drive different workflows, to improve quality and reduce cost; right now, those models include the Gemini family and Claude, but Google says it will soon expand capabilities to other leading private and open models. This is important because the leading model changes every few months, Kurian noted, and “the best model for the task is not always the largest one.” ## Choice a ‘unique value proposition’ Mahmoud Ramin, a research director at Info-Tech Research Group, noted that Google’s announcement does not create a whole new category, since OpenAI, Anthropic, Microsoft, and Meta have already positioned multiagent capabilities in their platforms. What is interesting with Gemini, though, is that not only can it operate directly in multiple Google products like Gmail, Drive, Sheets, and Slides, it also connects to external systems. It is, of course, a good fit for those already using the Google environment, he noted, and the strongest use cases are around repetitive tasks and information synthesis, such as that described in the research performed by project managers, analysts, and marketing specialists. Levy agreed that Google’s unique value proposition revolves around choice. “It separates the agent from the underlying model, and allows enterprises to use whatever model makes sense for a given workload,” he said. Its role-based agents are also “compellingly unique,” because they allow enterprises to create agents optimized for specific roles; meanwhile, more granular permission-setting addresses growing concerns about automated bots going off the rails. While OpenAI and Microsoft have made similar claims, Google is “arguably leading the conversation around identity, audit trails, and who, or what, is ultimately responsible for workflows,” Levy said. ## Google and others looking to be ‘gatekeepers’ As the AI industry pivots beyond mere chatbots toward its “inevitably agentic future,” the role of companies like Google, OpenAI, Anthropic, Microsoft, and others in the role of gatekeepers comes into sharper focus, Levy noted. The defining layer has shifted from operating systems to browsers, apps, cloud platforms, and now large language models (LLMs). In the agentic rush, key players are racing to establish their role in enterprise workflow infrastructure. “The agent layer could be the ultimate prize of the AI era, and it largely explains why every vendor announcement seems to essentially claim the same thing,” Levy said. But Google has to convince IT decision makers that its agentic roadmap is better than the competition’s; this means shifting the AI conversation to autonomy, rather than just basic tasks. Like virtually every other vendor’s agent, Google’s Gemini agent can write an email, tweak a spreadsheet, and build a presentation. “However,” Levy said, “whether CIOs and CISOs can trust it to run mission critical business processes indefinitely without doing something stupid enough to generate damaging headlines is another story altogether.” “Will enterprises care? If they’re already heavily invested in Google’s workplace stack, this could be an easier sell in the C-suite,” he noted. ## Raising important governance questions Info-Tech’s Ramin noted that whatever platform enterprises choose, the front-and-center focus going forward should be who controls AI agents. “As organizations unleash the power of agent autonomy, it raises the pivotal and non-negotiable requirement of enforcing governance,” he said, noting that with basic AI systems, risk is “much more contained” compared to that of an autonomous agent that has access to multiple business systems and can communicate with other agents. In the latter case, enterprises should significantly enforce guardrails, including permissions, identity, human oversight, and system audits, he said. They should “clearly outline which decisions the agent is allowed to make, what data should be accessed, and how performance will be monitored.” _This article originally appeared on Computerworld._

For decades, cybersecurity benefited from a constraint that was easy to take for granted: Attackers were limited by human capabilities. Finding vulnerabilities and developing reliable exploits required expertise. Reconnaissance, lateral movement, and adaptation took time and effort. That friction created something valuable for security practitioners: a window in which they could identify and assess risk, prioritize remediation, and respond in order to better secure their environments. Now, that window is getting smaller. Adversaries are increasingly using AI to accelerate and scale established attack techniques. The CrowdStrike 2026 Global Threat Report found an 89% year-over-year increase in attacks by AI-enabled adversaries and a 42% increase in zero-day vulnerabilities exploited before public disclosure. Frontier AI models capable of complex reasoning, software analysis, and autonomous problem solving are poised to accelerate vulnerability discovery, analyze attack paths, and support exploit development. To keep pace with AI-accelerated adversaries, businesses must rethink long-standing assumptions about how cybersecurity programs prioritize, manage, and respond to these risks. Below are five rules CIOs should adopt for the frontier AI era. **Rule 1: Measure exploitability** Security programs have historically focused on scanning more assets to find and address more vulnerabilities. Frontier AI challenges that model because discovery is becoming cheaper and faster. As AI becomes better at analyzing software and finding weaknesses, organizations may face substantially more findings without gaining more people or time to address them. This puts greater emphasis on prioritization: determining which exposures represent meaningful risk and where limited remediation resources should be directed first. Instead of “How many vulnerabilities do we have?” the question becomes “Which of these can hurt the business?” A high severity score alone cannot answer that. Leaders need to understand whether an exposure is reachable, whether it can be chained with other weaknesses, what systems and identities it provides access to, whether adversaries are actively targeting it, and what business process sits on the other end of the attack path. **Rule 2: Replace periodic assessment with continuous validation** Most enterprise risk processes still operate on a cadence: scan, assess, report, remediate, repeat. But a vulnerability assessment only tells an organization what was true at a specific moment in time. Infrastructure can change, identities can accumulate privileges, and cloud configurations can drift. When new dependencies appear, controls that worked yesterday may not work tomorrow. The implication is a move from periodic vulnerability management toward continuous exposure validation: understanding not only where weaknesses exist, but how they connect and whether an attacker could use them to reach something important. This also changes the definition of remediation. Organizations need to verify that a patch, configuration change, or compensating control addressed the exposure and reduced the risk. That requires a continuously updated, evidence-based understanding of exposure rather than relying on periodic snapshots of the environment. **Rule 3: Assume you won’t patch everything in time** Traditional vulnerability programs often implicitly assume that given enough time and resources, important vulnerabilities will eventually be patched. Frontier AI puts increasing pressure on both sides of that equation: It can increase the number of weaknesses being discovered while reducing the time available before exploitation, making resilience as important as remediation. Organizations must ask what happens when a vulnerable system cannot be patched immediately. Can an attacker use it to obtain credentials? Can those credentials reach critical systems? Can they move from an endpoint into identity, cloud, or SaaS environments? Which controls stop that initial foothold from becoming a material incident? This is why identity, least privilege, segmentation, containment, and compensating controls become central to frontier AI resilience, so individual exposures are harder to turn into business impact. **Rule 4: Eliminate human-speed handoffs from machine-speed workflows** A security team can identify a critical exposure in seconds, but resolving it can still take days as teams determine significance, establish ownership, approve changes, develop a fix, schedule deployment, and validate remediation. These handoffs introduce delays that become significant as the time available to respond to emerging risk continues to shrink. Recent CIO.com analysis has described a related concept as “decision latency”: the gap between receiving a signal and reaching the shared understanding and decision required to act. Frontier AI makes that organizational latency more consequential. This is why CIOs and security leaders should examine the full path from discovery to remediation. Where can context be assembled automatically? Which mitigation actions can be pre-approved? Who owns high-risk exposures? Which decisions require a person? Reducing unnecessary delays preserves human judgment where it matters and lets the organization respond faster when risk emerges. **Rule 5: Use AI to close the speed gap without losing control** If AI increases the speed of offense, defenders will inevitably need AI to increase the speed of defense. But deploying a powerful model is not the same as creating an effective security capability. Frontier models operate within a harness, or the surrounding system of tools, permissions, data, and workflows that shapes how the model operates and what it can do. How the harness is designed determines what the model can see, what actions it can take, and what happens when it makes a mistake. CIOs should think about AI in security the same way they would any other powerful production system: with defined permissions, observability, validation, containment, and human accountability. The result becomes controlled acceleration where AI is used to analyze exposure, surface attack paths, correlate context, and recommend or execute appropriate actions while maintaining clear boundaries around consequential decisions. This principle applies beyond cybersecurity. As AI agents gain greater access to enterprise applications, data, and workflows, the distinction between AI governance and security will continue to narrow. **The new measure of resilience** Frontier AI requires CIOs to prepare for an environment in which risk can emerge and develop faster than traditional enterprise processes can reduce it. Building resilience in that environment depends on the organization’s ability to identify meaningful risk, continuously test its assumptions, and limit the impact of exposures that cannot be immediately resolved. Frontier AI resilience brings those capabilities together by understanding what matters, maintaining a current view of exposure, and reducing the time between insight, decision, and action. For CIOs, this places greater emphasis on how the organization operates. Security, IT, and engineering teams need the processes, decision authority, and technology to reduce risk at the pace the threat environment now demands. Learn more about Frontier AI Security Readiness.

I have audited enough celebrated technology rollouts to notice a quiet omission across the industry: nobody talks much about what happens to the unit economics once the pilot ends and the software enters daily production. I have anonymized the company and changed identifying details for confidentiality, but the operating economics and workflow behaviors below are taken directly from the post-implementation audit. About six months ago, I was brought into a mid-sized enterprise to review a document workflow that had recently received an industry innovation award. The platform vendor published a case study highlighting the deployment. The trade press ran a short feature on it. Internally, the business unit sponsor pointed to a ninety percent reduction in turnaround time for vendor onboarding agreements, using that headline metric to secure a larger operational mandate for the coming fiscal cycle. A couple quarters later, the finance team reached out with an uncomfortable question. Document volume had stayed flat, yet the monthly operating expenses attached to processing those agreements were climbing steadily every single billing cycle. They asked me to trace the spending back through their systems and reconcile the operational data with the general ledger. Under the previous manual workflow, an operations clerk opened an incoming contract, checked five or six key clauses against internal guidelines, verified the vendor details and filed the document away. The entire review took about four to five minutes. Using the department’s fully loaded labor rate, including benefits and allocated overhead, that came out to roughly eighty cents per document. The automated pipeline was running between $12 and $14 for the exact same file. The system was technically stable. It processed thousands of files a month without dropping connections or crashing servers, and the operations dashboard stayed green. But the business was spending $12–$14 to complete work that had previously cost about 80 cents. Every enterprise award celebrates speed and throughput. Few of them audit the cost to finish a single unit of work. Nobody caught the discrepancy during the original three-month pilot because the computing bills, data lookups and third-party model access fees had been charged to a central innovation fund. The departmental budget never saw an invoice. As far as operations was concerned, the tool was essentially free software that dramatically reduced turnaround times on incoming requests. The moment the pilot concluded and the system moved into full daily production, the accounting changed. Corporate finance closed the innovation project code and began allocating the actual infrastructure invoices directly back to the business line. That was when the operational reality surfaced. Within sixty days of running full transaction volume on the department’s budget, the economics of the unit turned negative. Traditional enterprise software often has a predictable cost curve. Once the baseline platform is running, processing another five hundred records usually does not require the same kind of fresh computation and external model consumption as an automated pipeline. In this kind of workflow, each customer interaction, incoming contract or automated data extraction can trigger additional computational steps. The system had to interpret the document, check it against internal rules, compare the result with reference data and validate the answer before completing the transaction. If an automated pipeline requires multiple model queries and several background checks to finish a task that an experienced employee used to resolve in five minutes, you have not eliminated an operational cost. You have swapped a predictable human payroll line item for a consumption-based cost that scales directly with the work. ## Falling model prices don’t mean falling workflow costs The standard counterargument is that computing power is getting cheaper. That part is true. Research published in the Stanford HAI AI Index Report documented that the cost of querying benchmark foundation models dropped by more than 280-fold between late 2022 and late 2024. It is tempting to assume that automated business processes will experience the same cost reductions. In practice, a dramatic drop in per-token rates does not guarantee a lower operating bill if the production workflow performs significantly more retrieval steps, document parsing passes and validation checks to complete a single business task. Gartner’s latest forecast points to the same tension, predicting that inference costs per agentic workflow will increase more than fivefold through 2028 as increasingly complex workflows offset falling model prices. Both things can be true at the same time: base model prices can fall while the total cost of completing a business transaction rises. Cheap models do not guarantee cheap business processes. The economics of an automated system depend on the cost of the entire workflow, not just the base model. ## Production complexity is where the bill gets bigger During our audit, the operational problem showed up the moment real-world documents stopped looking like the clean samples used during vendor sales demonstrations. The demonstration files were digitally generated PDFs with uniform fonts, consistent layouts and standard contractual language. The live production queue was full of low-resolution scans, photocopied forms rotated sideways, documents with handwritten marginal notes, and agreements containing conflicting payment terms. A human operations specialist can often resolve that kind of ambiguity with a quick judgment call based on institutional context. The automated workflow struggled when the document fell outside the assumptions built into the process. When the system encountered messy formatting or contradictory clauses, it triggered extra processing routines. It ran multiple extraction passes, queried internal reference databases and executed secondary verification checks to resolve the ambiguity. Each extra step added to the cloud invoice, yet the system still struggled to reach an acceptable confidence score. When confidence fell below the required threshold (which occurred in roughly forty percent of daily transactions), the pipeline halted and routed the file into an exception queue. That created a secondary labor expense the original business case never budgeted for. When an agreement landed in the exception queue, an operations specialist had to log in, read the system’s partial extraction notes, diagnose why the software stalled and manually enter the correct data into the core database. Because the specialist had to review both the original document and the system’s confused output, resolving an exception took ten minutes (twice as long as the original manual baseline). The company found itself paying twice. It was paying the full monthly cloud invoice for the automated software, while simultaneously retaining the payroll cost of the operations staff required to supervise the exceptions. Goldman Sachs has raised the broader macroeconomic question of whether the massive corporate spending on AI infrastructure will produce productivity returns sufficient to justify the investment. Our audit showed what that question looks like inside a single department: replacing an eighty-cent clerical task with a fourteen-dollar automated pipeline that still requires human labor for four out of every ten transactions. The problem rarely comes from the user-seat price on the purchase order. It comes from what the system consumes to complete the work. The vendor can price the platform around usage, but the customer owns the business case. If an automated pipeline requires multiple processing passes to interpret a crooked document scan, the customer still has to absorb that consumption whether the final output is usable or not. When you scale a human operations team, the additional cost is relatively predictable. You know what another specialist costs in wages, benefits, equipment and management time. For this kind of workflow, automated costs can rise with the ambiguity of the inputs. When the fiscal quarter wraps up, this creates an organizational disconnect where every department claims victory while the business loses margin: * The engineering team reports ninety-nine percent system uptime and clean infrastructure performance. * Operations leadership reports that turnaround times on clean files dropped from forty-eight hours to under a minute. * The software vendor references the client in marketing collateral as evidence of enterprise transformation. * Finance is left trying to figure out why the cost of goods sold increased while revenue stayed flat. When leadership asks why an automation milestone fails to improve operating income, engineering points to platform uptime, product leads point to system adoption and software vendors point to successful transaction counts. Every department hit its individual performance goals. Yet the business process itself became strictly more expensive to run than it was before the project started. In this deployment, the team tried to fix the issue by adding secondary filtering scripts and tuning prompt instructions. Those additions increased system complexity and cloud consumption without solving the core unit cost problem. An automated workflow can execute with zero technical errors while still undermining departmental margins. ## Three questions before you call an AI project a success Before approving a production, rollout or expanding an automation pilot, finance and technology leaders should put three direct questions to their teams: * What does one completed transaction actually cost compared with the manual baseline, accounting for all infrastructure compute, database lookups and third-party model charges? * How often does a human still have to intervene, and what is the loaded payroll cost of that review time? * Do the economics still work at production volume, or is the organization simply moving an operational expense from payroll into an unpredictable consumption meter? If the economics only work during the pilot, the system is not creating operational leverage. It is creating an operating expense the pilot never measured.

In my experience, where you place product management is as critical as whom you hire and how you train them. A team expected to serve the whole organization needs the influence and independence to act for the whole organization. My view comes from working in companies ranging from trillion-dollar enterprises to startups, and from ongoing conversations with peers and industry leaders building product functions of their own. I have watched a particular mistake repeat itself, most often in smaller organizations under pressure to show fast results with technology. These organizations make the right call by building a product function. Where they falter is in giving too little weight to where it sits. In my experience, some leaders have never worked with a product manager or been one themselves. They do not fully appreciate what functional independence makes possible. The sequence is familiar: boards want efficiency, technology becomes part of the answer and the company hires product managers. The new function then lands under whichever business unit head has the most influence, and the placement goes unexamined. The result is a new inefficiency built to solve an old one. The familiar saying is that culture eats strategy for breakfast. My version is that placement eats good intentions for lunch. Good people and good training matter enormously. Their effectiveness also depends on whether the structure empowers them to work for the organization rather than one corner of it. ## How placement narrows the team’s priorities I see this pattern most often when an organization is establishing product management for the first time, including in financial services and mortgage servicing. Product lands under a single internal function, often close to operations, through momentum rather than a deliberate decision about its independence. My concern starts with incentives. The person who controls a leader’s performance review and compensation has considerable influence over that leader’s priorities, whatever the charter says. A product team placed inside one function can inherit that function’s metrics. Backlog conversations then start favoring the sponsoring department’s targets over the organization’s needs. In its analysis of product reporting relationships, TSIA makes the case for the senior product leader to report to the CEO or business unit general manager, as a peer to other leaders. Its research concerns technology businesses; the principle relevant to my experience is the ability to maintain a view across the business. When other functions cannot get resources, they build their own workarounds. In my experience, the result is consistently worse than if product had addressed the need from the start. Nobody needs to act in bad faith for this to happen. Each department can be pursuing the targets the organization gave it. That is the local-optimization problem discussed in Askeladden Capital’s explanation. Its example draws on Howard Schultz’s account in Onward of Starbucks focusing too heavily on same-store sales in the mid-2000s. The connection I draw is simple: success against one set of measures can come at the expense of the wider business. Placement also affects who participates when priorities are set. If product reports into one department, others with an equally valid claim on its time can be left out. The room itself is incomplete. In a 2026 analysis of product team structure, Userpilot’s Abrar Abutouq describes the risk of product becoming project management when it is buried under IT or operations. I see the same distinction in the argument for independence: the team needs standing to challenge priorities, rather than simply track decisions already made. What frustrates me is seeing organizations repeat a problem that has already been examined elsewhere. The issue is especially familiar to me in organizations newly experimenting with product management in mortgage servicing and lending. They are moving quickly and trying to improve how the business works. Yet skipping the structural decision can undermine that intention. My advice is to give placement the same attention leaders already give to finding capable people. ## What functional independence requires Product Focus’s 2026 survey found that 80 percent of respondents reporting at CPO level saw product management as a leadership role, compared with about 50 percent reporting into development or sales. That is a finding about perceived leadership status, rather than proof that a reporting line alone improves performance. It supports taking the team’s organizational standing seriously. Simon Cast makes a related point in Mind the Product: reporting to the CTO can create a perception of bias toward technology, undermining product’s ability to balance business, customer and technical considerations. In my view, that concern applies wherever product’s organization-wide mandate sits inside a narrower function. Marty Cagan’s organizational model at Silicon Valley Product Group places product management and design alongside marketing and engineering. His model allows reporting to a CEO, COO or business unit general manager. It supports distinct voices at the leadership table, rather than a CEO-only rule. My preference remains a direct line to the CEO when the team serves the whole company. Products That Count’s 2025 CPO Insights Report reports that the share of Fortune 1000 companies with a CPO rose from 3–4 percent in 2020 to more than 30 percent two years later. I see that reported growth as another reason to take product’s seat at the leadership table seriously, rather than place it automatically inside an existing function. However, moving a box on the org chart is not enough. Leaders first need an honest view of where the company is going and what role technology plays in that future. They can then decide what kind of product function they need. For the mid-size organizations I am describing, I believe that function needs a mandate across the organization. Individual product managers can work closely with specific business units and develop domain expertise. I consider that proximity valuable. Authority over how resources are allocated, however, needs to reflect the whole portfolio. Listening to a department and being controlled by its priorities are different arrangements. I also see a forward-looking implication for AI-supported prioritization. If a product team uses AI to synthesize backlog signals, usage data and business objectives, I would still expect its independence to matter. More sophisticated tools do not resolve an incentive structure that favors one internal function. My concern is that they could simply reinforce it. ## My advice to leaders establishing product management Before settling the reporting line, decide whether product is expected to serve one department or the whole organization. If the mandate is organization-wide, give its leader direct access to executive leadership and authority to consider resources across the portfolio. Make that placement a deliberate decision alongside hiring and training. Keep the team open to influence from every department. Give individual product managers room to build deep business knowledge, while keeping the wider function’s priorities independent of any single department’s targets. Pay attention to performance reviews and compensation: the expectations attached to them need to match the breadth of the mandate. That is my central lesson from experience and conversations with peers. A capable team needs an organizational position that lets it use its judgment for the whole company. Leaders seeking technology-driven efficiency should establish that foundation when they create the function, rather than leave the team to work around its absence.

Eager to incorporate agentic AI into their work, employees are taking matters into their own hands, creating their own AI agents, regardless of organizational approval, and a not insignificant number of those creations could have devastating consequences if IT leaders don’t get ahead of the trend. According to a recent survey by engineering staffing firm Howdy.com, two-thirds of knowledge workers that use AI also use agents, and 16% have begun to build their own. About a quarter of agent users have had to deactivate them, however, largely because the agent’s outputs were inconsistent or the agent never worked. But 7% of knowledge workers have had to kill agents that went rogue. The findings put a point on the potential repercussions of shadow agent creation and even sanctioned citizen AI strategies that encourage business users to roll their own agents. While the survey didn’t ask whether the employees building their own agents were doing it on their own, Frank Licea, founder of Howdy.com, sees that many aren’t waiting for permission. “In our internal teams, we’ve had to, not put the brakes on, but ask people to hold on,” he says. “Before they start jumping in and building their own agents, we’ve had to put guardrails and system guides in place so that we can do this safely.” For what Licea has seen, employees are excited to automate boring manual tasks by building their own agents. “It mostly starts unsanctioned because there are tech-forward folks in any organization who are just naturally curious,” he says. “Or maybe even intelligently lazy. They want to automate their work.” In recent months, Howdy.com employees began telling each other how they automated manual tasks, without waiting for the company’s IT team to approve the uses, Licea says. “The way it happened for us is that folks would come up to us like just beaming and excited about something that they automated or fixed a long-standing problem that the engineering team never had on their roadmap,” he says. “Once that started happening, then somebody from the tech side gets in and they start asking questions like, ‘What are the API keys here? Are you accessing encrypted data? What are the SOC2 implications?’” ## Cautious embrace Luis Mesas, VP of product engineering at software engineering provider Sngular, believes it’s inevitable that employees will experiment with building AI agents to automate their work. “Employees are going to create their own agents whether companies formally sanction it or not, because the barrier to building these tools is getting lower, and engineering teams are already being asked to do more with less,” he says. “The bigger concern for me is not that an employee creates an agent, but what happens when that agent starts connecting to company systems and data without the same controls that would normally exist around a piece of software.” IT leaders need to understand how employee-created agents are connecting to internal systems and data, he says. If an employee creates an agent that can pull customer information from a CRM, update records, or move information between systems, IT leaders should know it’s happening, he adds. “I want to know exactly what that agent can access and whether the employee should have that level of access in the first place,” Mesas says. “That is where something that started as an individual productivity tool becomes an enterprise technology issue.” Andy Sen, CTO at B2B commerce platform provider AppDirect, believes employees should be encouraged to build agents — but within guardrails and established policies. “Employees are almost certainly creating their own agents, and it would be naive to think otherwise,” he says. “Shadow IT has always existed, and shadow agents are just the latest version of it.” The answer isn’t to lock things down, however, he says. At AppDirect, Sen gives employees a “proper digital playground,” and in response to employee demand, his team built an AI-powered coding service called Devs.AI. “We built Devs.AI so our employees can build and innovate freely, but IT has full visibility into usage and costs and the assurance that company data isn’t being leaked to the world,” he adds. Citizen AI strategies, like the one at AppDirect, are on the rise, but require consistent monitoring. If one in four employee agents are deactivated, for example, IT leaders should pay attention, Sen says. “Failing and learning is fine,” he adds. “Failing silently is not. You need visibility into what your agents are doing before a small problem becomes a serious one.” Still, Sen doubted reports of a small percentage of employee-created agents going rogue. “When an agent goes rogue, that usually means the agent did exactly what it was told, and what it was told wasn’t right,” he says. “That’s on the creator, not the agent.” ## Creating a path for good ideas Andrew Sales, chief methodologist at agile methodology vendor Scaled Agile, also sees widespread agent deactivations as a strong signal for IT leaders to investigate. “When agents are built quickly and outside a formal model, there often aren’t clear boundaries around what they can do, what data they can reach, or when a human needs to step in,” he says. “So it’s not surprising that some have had to be shut down.” AI governance is important, but it shouldn’t focus only on preventing bad outcomes, Sales notes. “It should also create a path for good ideas to move from individual experimentation into enterprise capability,” he explains. “Organizations need a way to identify what’s working, standardize it, make it safe, and scale it responsibly across teams. Done well, that same framework that catches the agents that go wrong is what lets the ones that go right spread.”

Over 20-plus years in the enterprise trenches, I’ve watched multi-million-dollar technology transformations stumble over the same blind spot. We spend months debating cloud architectures, database benchmarks and vendor feature matrices. But the tech itself? That’s rarely where the real bleeding happens. The real pain arrives later, in the messy organizational wake: * Who actually controls this system? * What critical business function did we just accidentally outsource? * How painful will it be to untangle ourselves when the vendor changes their licensing model? Agentic AI is about to make those questions considerably more interesting. We have spent years worrying about application and vendor lock-in. The next form of lock-in may sit several layers deeper. For most of my career, and arguably most of the history of computing, machines have waited for us. We gave the instructions, approved the transactions, made the decisions. Agentic AI is beginning to change that relationship. An agent can interpret an objective, break it into tasks, find the services it needs and execute those tasks with limited human intervention. The moment an agent can do more than recommend a purchase and can actually make one, it stops being a technology tool. It becomes an economic participant. Few technology leaders are asking the question that follows — and by the time more of them do, the answer may already be decided: What financial infrastructure will these machines operate on, and who will control it? The International Monetary Fund’s 2026 note on agentic AI and payments describes a shift from human-initiated transactions toward agent-mediated ones — from a “click-to-pay” model to a “decide-to-pay” model — with implications for authorization, settlement, liquidity, compliance and resilience. The IMF also highlights a fundamental tension between probabilistic AI behaviour and the deterministic requirements of payment infrastructure. That caution is worth sitting with. If the institutions closest to global payments infrastructure are already examining how to preserve authorization, control and settlement finality as AI becomes more autonomous, that is itself a signal about how much is at stake in who builds and governs the rails. Picture what this looks like inside an enterprise. A procurement agent instructed to reduce the cost of a service identifies several providers, checks their credentials and reputation, negotiates terms and initiates payment — with a human approving only the exceptions. A logistics agent dynamically buys transport capacity as demand shifts. A software agent discovers an API, uses it for a specific task and pays for the consumption without anyone visiting a payment page. None of this requires exotic technology. It requires identity, authority, trust, reputation, marketplaces, wallets and payment rails built to work with autonomous participants rather than humans clicking “confirm.” In other words, the agentic economy will need its own economic infrastructure. ## Money is becoming infrastructure The petrodollar is the clearest historical parallel, and it’s worth being precise about the mechanism rather than just the label. In the early 1970s, as the dollar came off the gold standard, the US reached an understanding with Saudi Arabia, and by extension OPEC, that oil would continue to be priced and settled in dollars. Oil-exporting nations then recycled much of that revenue back into US Treasury securities and dollar-denominated assets. Nobody decided that oil needed a new currency invented for it. The currency that was already dominant simply became the substrate the world’s most strategic commodity traded on — and countries with no direct relationship to the US found their energy trade, and much of their national accounting, running through a currency they didn’t issue and couldn’t control. The analogy to AI is imperfect but suggestive. If compute and intelligence become this century’s strategic commodities the way oil was for the last one, could the infrastructure through which autonomous machines exchange value become dominant in the same quiet way? Pieces of this are already forming. The US has built a regulatory framework around dollar-backed payment stablecoins, and the US Treasury has explicitly linked implementation of the GENIUS Act to reinforcing the dollar’s role in digital finance. China has the digital yuan, Europe is progressing a digital euro and BRICS countries are exploring local-currency settlement and alternative rails. None of this makes an “AI dollar” inevitable, and these initiatives aren’t all competing for the same role. But they show money becoming part of the digital infrastructure itself, not just a thing that moves across it. The Bank for International Settlements’ 2026 Annual Economic Report found that more than 99% of fiat-backed stablecoin supply remains dollar-pegged, even though stablecoin use in the real economy is still small next to traditional payment systems. That gap matters: The infrastructure is developing quickly, but the machine economy hasn’t been built on top of it yet. We’re unusually early — discussing the architecture before it becomes hard to change. ## Two paths, and probably a third There are broadly two ways this could evolve. The first extends today’s financial architecture into the machine economy: Agents get digital identities, wallets and delegated authority, but ultimately still operate through the banks, payment networks, financial institutions and technology platforms we already use, with an AI layer added on top. There’s nothing wrong with this. We already have institutions, regulation, compliance and dispute-resolution mechanisms built for handling money — reinventing all of that simply because the customer is now an AI agent would be wasteful. The second, more interesting possibility is a more open economic layer built specifically for autonomous agents: Open marketplaces where agents discover services across providers, establish trust through portable identity and reputation, and transact using interoperable payment mechanisms. Trust doesn’t disappear in this model; it gets established through verifiable identity, reputation and programmable rules instead of a single central intermediary. I’m not suggesting everything should be decentralized, or that blockchain automatically solves this — financial transactions carry requirements around compliance, legal finality, fraud prevention and accountability that can’t simply be wished onto a distributed ledger. The World Economic Forum’s work on AI agents and payments makes a similar point from the financial-services perspective: Traditional identity controls may no longer be sufficient when software is acting between the customer and the transaction. Understanding an agent’s intent, authority and context becomes part of establishing trust. The fork that actually matters is this: Do we want autonomous agents to inherit the financial dependencies we’ve spent decades trying to untangle, or is this a chance to design something more open from the start? It matters for enterprises specifically because we’ve lived this before. We’ve spent years reducing application and infrastructure vendor lock-in. Agentic AI could create a far broader dependency — not lock-in to a single application, but to an entire technology and economic ecosystem at once. This is what I’d call AI supply-chain sovereignty: Not owning every component of the stack but understanding the dependencies well enough to retain strategic choice. If your models, cloud infrastructure, agents, identity layer, marketplace and payment rails all sit inside one ecosystem, you may have built a sophisticated version of lock-in without ever naming it that. In practice, the resolution is probably a hybrid rather than a clean win for either model: Regulated rails carrying legal finality, dispute resolution and compliance, with open protocols layered on top for discovery, portable identity and reputation. Picture agents shopping across an open marketplace for services, but settling and resolving disputes through accountable, licensed intermediaries’ underneath. That blend is the more likely third path — and probably the one enterprises should be designing toward now, rather than betting everything on either pure extreme. ## What this means in practice A few things follow from this for technology leaders. Make model and infrastructure portability an architectural principle, not an afterthought. Understand where private infrastructure and open-weight models can sit alongside commercial frontier models, and design agent architectures capable of talking to multiple services rather than being permanently wired to one marketplace. This is increasingly consistent with how McKinsey describes the infrastructure shift required for agentic AI: Modularity, composability, decoupling and vendor flexibility become important as agents interact across systems, tools and transactional environments. For technology leaders, that is not simply an infrastructure concern. It is an argument for preserving optionality in the broader AI stack. Rethink what an agent wallet actually is. The important concept isn’t cryptocurrency — it’s delegated financial authority. An enterprise agent needs something like identity and access management for money: Who is this agent, what is it authorized to purchase, how much can it spend, which counterparties can it use and when does a transaction escalate to a human? Recognize that payments are no longer purely finance’s problem. For years, technology has treated payments as something that sits on the other side of the org chart: Finance decides how money moves, and technology integrates whatever’s required. Once a machine can decide and execute a transaction in the same motion, the payment mechanism becomes part of the technology architecture itself. Finally, add the economic layer to your AI architecture diagram. We already map data, applications, models, cloud and cybersecurity. It’s time to also map where identity, reputation, marketplaces, payment rails and currencies sit in that chain — and what happens to the business if any one of them becomes unavailable. That’s the practical meaning of sovereignty here: Not owning everything but making sure no single component can switch off the intelligence the business depends on. ## The choices we make now The larger question is still open. We could reproduce today’s financial architecture for machines, with agents operating inside increasingly sophisticated ecosystems controlled by governments, financial institutions and platforms. Or we could deliberately build more open, interoperable economic infrastructure where agents discover services and establish trust across organizational and technological boundaries. The real outcome will likely be messier than either — regulation and trusted institutions aren’t going away, even as open protocols increasingly provide the connective tissue between autonomous participants. What matters is that we still have some influence over that balance. The petrodollar wasn’t created because someone decided oil needed a new currency; it emerged from the interaction of a strategic commodity, global trade, financial markets and geopolitics. The agentic economy may develop the same way, with compute and intelligence generating the economic value and new financial infrastructure determining how that value moves. For technology leaders, the question may end up being bigger than who builds the smartest AI. It may be who controls the economic infrastructure through which autonomous intelligence participates in the economy — and whether we make that infrastructure open enough that no single company, platform or jurisdiction becomes indispensable.

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. But here we are. Gartner expects the average Fortune 500 enterprise to run more than 150,000 agents by 2028, up from fewer than 15 in 2025. A blind spot you could live with across a handful of workloads becomes a serious headache across six figures of them. ## The case for managed services is real 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.

As the demand for AI infrastructure continues to outstrip available capacity, AMD is planning a substantial increase in CPU and GPU supply in 2027. During her recent visit to Taiwan, AMD CEO Lisa Su confirmed that the company is working to expand supply across its ecosystem and is now planning capacity three to five years ahead. Su told reporters that AMD has increased its supply and capacity in 2026 and is going to substantially increase supply in 2027, as per Reuters. Su was in Taiwan on October 5-6 with the aim of ramping up AMD’s supply for CPU and GPU production to meet growing AI demand. Su had reportedly held meetings with Foxconn and was also scheduled to meet TSMC as part of discussions with local partners. Following her meetings in Taiwan, Su is now visiting South Korea, where she held meetings with Samsung Electronics’ Device Solutions (DS) to broaden the partnership, among other companies. For CIOs, this ramp-up could eventually improve access to AI compute and add another option to Nvidia’s dominant infrastructure, but it is unlikely to end supply constraints overnight. ## AMD’s supply ramp depends on its partners AMD may have the demand and product roadmap, but scaling supply will depend on how much capacity these manufacturing and memory partners can deliver. “AMD designs the chips, but relies on TSMC for advanced chip manufacturing and packaging, and SK Hynix and Samsung for HBM memory. Its 2027 supply increase therefore depends heavily on these partners adding capacity on time. Any delays in new wafer, packaging or HBM capacity could constrain AMD’s GPU ramp,” said Pareekh Jain, CEO at EIIRTrend & Pareekh Consulting. Even though AMD has committed to a substantial supply increase in 2027, the execution is dependent on multiple factors. First being the yield and efficiency of HBM4. “As AMD transitions its next-generation architecture to HBM4, it becomes dependent on highly complex architectural changes. HBM4 shifts to a logic base die, requiring deep collaboration with memory giants like SK Hynix and Samsung Electronics. If these memory makers experience poor bit efficiency or yield issues on early HBM4 runs, AMD’s shippable volume will be instantly capped, regardless of how much raw silicon it prints,” said Danish Faruqui, CEO at Fab Economics. Secondly, there is a severe Chip-on-Wafer-on-Substrate (CoWoS) allocation squeeze as hyperscalers and Tier-1 cloud providers are locking down packaging capacity years in advance. Faruqui noted that because Nvidia absorbs the lion’s share of TSMC’s packaging allocation for its Blackwell platforms, AMD’s ability to substantially increase its 2027 volumes therefore depends entirely on how many packaging slots it can successfully wrestle away from competitors. Lastly, while AMD is exploring broader ecosystem investments (such as expanding its multi-billion-dollar presence in Taiwan), it remains 100% tied to TSMC as its primary foundry for advanced nodes, added Faruqui. Efforts to diversify, such as evaluating potential packaging or wafer capacity from US-based fabs (like TSMC’s Texas initiatives), will not yield meaningful volume relief by 2027, leaving its ramp entirely vulnerable to supply chain shocks or capacity rationing in Taiwan, added Faruqui. ## AI compute crunch may persist through 2027 The AI compute supply crunch is expected to remain acute till the first half of 2027, say experts. This is because the shortage extends beyond GPUs to high-bandwidth memory, advanced packaging, data-centre space and reliable power, and demand from AI training and inference workloads continues to outpace the substantial new capacity being added. “Enterprises can expect moderate relief in 2027 as new chip packaging and data-centre capacity comes online, although meaningful improvement is unlikely before the second half of the year. The outlook is therefore one of easing constraints rather than full normalisation, and premium pricing is likely to persist until supply expands across the entire infrastructure stack,” said Devroop Dhar, co-founder and MD at Primus Partners. Dhar added that most incremental capacity will initially be absorbed by hyperscalers such as AWS, Microsoft, Google and Meta, along with leading AI labs, given their long-term procurement commitments and scale advantages. However, enterprises will benefit largely indirectly, through broader availability of cloud-based AI services and improved access to GPU resources via public-cloud and managed-service providers. ## More supply may not mean cheaper AI compute With demand for GPUs, CPUs and HBM already outpacing supply, additional capacity should eventually ease some pressure on AI infrastructure costs. But the new capacity will be arriving in a market where AI demand continues to grow rapidly. “Lead times for premium enterprise data center GPUs range from 36 to 52 weeks in 2026, extending deliveries into 2027, driving GPU prices up by 25-35% above the manufacturer’s suggested retail price, and cloud service providers’ share increased premium GPU instance pricing (like EC2 Capacity Blocks) by roughly 15-25% already,” added Faruqui. While total global AI compute stock, including AMD’s hardware, is projected to scale up through 2027, enterprises can realistically expect only marginal price reduction, and that too in stages. Dhar noted that in the near term, the most significant effect will be greater negotiating leverage, as a credible alternative supplier gives enterprises and cloud providers more flexibility. Selective discounts may first appear on AMD-based cloud instances and older-generation GPUs. Prices for frontier compute capacity could begin to moderate in the second half of 2027, once initial large-scale deployments are completed and more supply becomes available to the broader market. A more substantial price correction may therefore not emerge before 2028. He added that, amongst the various products, the MI350P and MI355X may be AMD’s trump cards in this market and can give it an advantage in optimizing AI compute requirements and spend. Compute will become more accessible to corporate buyers over the course of 2027, but will require deliberate planning and secured commitments. As AI compute is becoming strategic infrastructure that needs multiyear planning, Jain cautioned that CIOs should estimate AI demand under different growth scenarios, reserve capacity for critical workloads, use the cloud for unexpected demand, and avoid depending completely on one GPU supplier. The key measure should be cost per successful AI workload, not simply GPU price. _The article originally appeared on NetworkWorld._

What happens once building software stops being expensive? That’s the question at the center of this piece, and I think it’s about to matter for every CIO/CTO managing an enterprise technology budget. For decades, that expense has quietly shaped how enterprises operate. When custom development takes months and a full team, companies buy SaaS products instead. When engineering capacity is limited, CIOs/CTOs prioritize a backlog. When a business unit wants a new application, it competes with everyone else for budget and developer time. Enterprise IT’s whole structure exists partly because software has always been hard to make. A recent example from Perplexity convinced me that assumption is starting to break down faster than most of us expected, and it’s worth walking through in some detail before getting to what it means for the rest of us. ## The buy versus build math is shifting Perplexity has disclosed that two engineers, working with hundreds of AI coding agents, built a custom database called CobbleDB in roughly two months. This was not a prototype. CobbleDB is a roughly 40,000-line Rust key-value store that now handles part of Perplexity’s production search traffic, built to replace some DynamoDB reads after the company decided it wanted more control over latency and cost. The numbers are hard to ignore. According to reporting by The New Stack, Perplexity cut its median read latency by more than 80% and expects to save at least 20% on cost compared with DynamoDB, though the comparison wasn’t a controlled benchmark and the savings estimate leaves out the cost of maintaining a custom database. Even with those caveats, two engineers built a substantial piece of infrastructure in eight weeks, and this isn’t a story about one company’s database. This is already playing out at a smaller scale. Payhawk CEO Hristo Borisov described replacing a commercial performance-management product costing $70,000 a year with software his company built itself using AI-assisted development. Microsoft is pushing the same idea into the broader workforce with its 365 Copilot App Builder, which lets an employee describe an application in plain language and get a working version in minutes. The same shift is happening at the opposite end of the size spectrum too. Starbucks is reportedly building AI-developed replacements for a Microsoft system that tracks inventory and an IBM platform that manages maintenance, according to a Bloomberg report cited by Fortune. The coffee chain spends roughly $400 million a year on software, and CTO Anand Varadarajan has told employees there are “clear opportunities to reduce the spend in software.” Some of the internally built systems could launch by the end of 2027, pending testing. A specialized production database, a business user’s lightweight app and a Fortune 500 company’s attempt to displace two enterprise vendors at once look like different stories, but I think they are the same trend at different levels of complexity: creating software is getting cheaper, and that changes what enterprises can justify building themselves instead of buying. AI does not remove the real costs of custom software. Someone still has to understand the business problem, design the architecture, validate the output, secure it and operate it. Perplexity kept its two engineers in control of CobbleDB’s architecture and production environment throughout, and that distinction matters: agents accelerated the work; they did not replace the judgment behind it. ## Abundance creates a different problem than scarcity Enterprise IT has spent decades managing a shortage of development capacity. There are always more requests than developers and more requirements than teams can deliver on schedule. Now picture that constraint loosening. A finance team builds its own reconciliation tool instead of filing a ticket. Sales generates an app that combines CRM data with account research. A developer asks an agent for a specialized utility instead of writing it by hand. None of these individual choices looks unreasonable, but together they add up to an enterprise software environment that looks nothing like the one most CIO/CTOs are managing for today. The organization may still have 500 applications in its official portfolio, and underneath that could sit thousands of generated tools, scripts and workflows that nobody centrally tracks. From a risk and compliance standpoint, that gap is more than an untidy IT footprint. Most control environments assume software enters through a small number of known channels such as procurement, a formal development lifecycle or a change advisory board. Every control that matters (segregation of duties, access provisioning, periodic recertification) gets attached to software at one of those checkpoints. A tool generated by an employee in an afternoon skips all of them. It gets built, connected to whatever data it needs and put into use without ever crossing a point where someone was responsible for reviewing it. Control frameworks are built on the assumption that risk gets caught at intake. AI-generated software does not have an intake. The exposure compounds because nobody owns the exit either. A reconciliation tool built for a six-month initiative does not get decommissioned on a schedule the way a vendor contract does or a system gets retired at end of life. It keeps running quietly, holding whatever access it was given on day one, with no control owner accountable for revisiting that access once the project that justified it has ended. Assigning a control owner and an expiration date at the moment someone decides to build would close that gap, and right now almost nobody does it. There is a second, quieter shift happening alongside all of this. When creating a new tool is easier than finding out whether one already exists, people will default to creating one. I think that flips one of the oldest assumptions in software: creation is expensive and reuse is cheap. AI is making creation cheap while discovery and reuse stay exactly as hard as they have always been, and for a risk function that means the population of unreviewed software an organization is carrying grows faster than any control process built for the old economics can absorb. ## CIO/CTOs should start preparing for abundance, not scarcity Developers don’t disappear from this picture. If anything, the Perplexity example argues the opposite: when a system genuinely matters, experienced engineers still make the architectural calls, test the assumptions and take responsibility for what reaches production. What changes is how much software those same people can create and oversee at once, and that shifts the question CIO/CTOs need to be asking. It used to be whether a team could build something. Increasingly, it’s whether it should, whether the organization already has something like it, who owns it and what happens when the person who built it moves on. Those aren’t engineering questions. They’re portfolio and governance questions, and most organizations don’t have a clear owner for them yet. There’s a pattern in how enterprises absorb this kind of shift. When storage got cheap, companies didn’t end up with fewer data problems; they accumulated far more data. When cloud infrastructure became easy to provision, the worry shifted from “can we get the compute” to “how do we control the sprawl and the cost.” Software is headed toward the same transition, and the CIO/CTOs who prepare for abundance now will have a real advantage over the ones still planning around scarcity. Perplexity’s CobbleDB is interesting because of what the company built. It’s more interesting because of how few people it took to build it. If two engineers augmented by AI agents can produce a production database in eight weeks, it’s worth asking what the rest of the workforce, technical and nontechnical, will be able to create as these tools keep improving. That question belongs on the same agenda as budget, headcount and control ownership planning, not off to the side as a curiosity for the engineering team to sort out on its own. Enterprise IT has spent decades getting faster at building software. That was never going to be the hard part. Knowing what you own, and when to retire it, is.

SAP is continuing its acquisition spree to help its enterprise customers address what it sees as one of the key challenges around scaling AI: giving Joule agents the appropriate context they need to reason across enterprise data and systems. The enterprise software giant, late on Tuesday, said that it was signing an agreement to acquire Ghent-based AI startup TechWolf to augment its SuccessFactors HCM platform by giving its AI agents a more detailed understanding of how employees work and what skills they have. The startup’s central offering is a data model called context graph for work, which it builds by using an AI model after analyzing data from HR and business systems. The graph creates a continuously updated view of the work employees perform and the skills they use, and connects that information with jobs, workforce requirements, and external labor-market data. For SAP, that graph will serve as a grounding layer and provide additional context for Joule AI agents, allowing them to reason across skills, tasks, and workforce requirements when handling enterprise use cases such as skills-based hiring, workforce planning, and role redesign, the company said in a statement. For enterprises, the additional context is likely to result in more accurate workforce-related agent responses, potentially reducing token consumption and, in turn, the cost of deploying workforce agents, the company added. Earlier this year in March, SAP acquired Reltio, a master data management platform, to help enterprises unify and harmonize data across SAP and non-SAP systems, in turn making it easy for its AI agents with the context they need to reason across information spread across different systems. Later in May, the company announced plans to acquire Dremio, an agentic lakehouse provider, to further help enterprises bring together data from different sources and make it available for AI workloads, giving its agents access to the data and context needed to reason across enterprise information. While Reltio and Dremio address the context problem for SAP from the data side, TechWolf extends that approach to HCM. However, there is a difference in how these acquisitions are being integrated into SAP’s portfolio. While Reltio and Dremio have been folded into SAP’s broader data platform, TechWolf, at least for now, will continue to operate independently, allowing it to serve both SAP and non-SAP customers while its technology is integrated with SuccessFactors and Joule. TechWolf’s acquisition is expected to close by December this year, SAP said. SAP isn’t alone in making acquisitions to address the context problem around enterprise AI. Its CRM-focused rival Salesforce acquired Informatica in November last year to strengthen its Agentforce platform with data management, governance, metadata, and lineage capabilities, giving AI agents access to trusted enterprise data and the business context needed to reason and act across different systems. Similarly, ServiceNow completed its acquisition of Moveworks in December last year, adding enterprise search, an AI assistant, and a reasoning engine to its platform to help AI agents access information spread across enterprise applications. Workday, an HCM-focused rival, too, acquired Sana in November last year to combine its AI-powered search, agents and learning capabilities with Workday’s data and context around people and money, creating what the company described as a horizontal intelligence layer across the enterprise. It later agreed to acquire Pipedream in November to connect Workday’s people and finance data to more than 3,000 business applications, allowing AI agents to retrieve data and execute tasks across the systems where work happens.

Every CIO in a regulated industry has a system the business depends on, that no one fully understands and that must be replaced. In banking, it is often a core platform that predates the internet. In my own career, that system took two distinct forms: first, a VAX minicomputer running a parking operator’s entire business across nearly 200 New York City locations; later, the on-premises core of a global financial technology company supporting payments, banking and card issuing. Both had to move to the cloud without interrupting the customers that depended on them. The technology differed each time. The reasons the migrations succeeded did not. ## Why regulated migrations fail differently Migration failures come in two kinds. The loud kind takes a website down, engineers fix it and customers move on. The quiet kind — a pricing discrepancy, a missed filing, a mismatched reconciliation or a lost audit trail — may not surface for weeks. Its cost is measured in regulatory findings and lost client contracts rather than in hours of downtime. Regulated migrations face both. The loud kind can be ruinous, as TSB learned in 2018 when a big-bang platform migration locked customers out for weeks and, after regulators found insufficient contingency planning and untested cutover configurations, drew a £48.65 million fine. The loud kind is at least visible. The quiet kind breaks the business without anyone noticing. This changes what “without breaking the business” means. It does not mean zero outages. It means that at every point during the migration, the organization can prove that the new system produces the same outcomes as the old one for the cases that matter, or a difference the business has approved, and has a tested way to recover if it does not. That standard is stricter than most migration plans are written to, and it determines whether the program survives its first serious incident. Meeting it comes down to five operational disciplines. ## Map the dependencies you were not told about The formal dependency map in the architecture repository is always incomplete. The dependencies that break a migration are the informal ones, which grew up around the legacy system without ever being documented. A team in another department builds a nightly job that reads a file the legacy system happens to produce at 2 a.m., without the system’s owners knowing. An analyst in finance writes a spreadsheet macro that queries a database table directly, bypassing every official interface. A report goes to a regulator every quarter, generated automatically for so long that no one remembers how to produce it by hand. Finding these dependencies takes careful observation. Configure the legacy environment to record every connection, every file it produces or consumes, and every scheduled job. Collect this data over a full business cycle, including month-end and quarter-end processing, before relying on the dependency map. This step is often dismissed as unnecessary, but it provides the evidence needed to plan the migration sequence. A workload should move only when its dependencies have moved, remain reliably accessible, or are confirmed to be no longer required. The map must also account for people. Behind every critical legacy workload is a group of engineers or business analysts who know why an undocumented parameter exists or why a batch job runs only on the third Thursday of the month. Identify them at the outset, protect their time and capture what they know in reproducible test suites before they retire or move on. A thorough map also reveals what to prune. Over decades, legacy estates accumulate dormant batch jobs, deprecated extracts and orphaned interfaces. Retiring these before cutover shrinks the migration scope and removes testing cycles spent on workflows that no longer serve anyone. Never decommission an idle process based solely on the monitoring window; verify with the responsible business owner and check historical run schedules for low-frequency jobs first. ## Sequence cutovers around the business calendar, not the project plan A project plan wants cutovers on a steady cadence. A regulated business has dates on which nothing may change, such as settlement days, filing deadlines, rate resets and month-end close. Build the migration calendar from the business calendar outward, placing cutover windows where you can detect and recover from failure before the next immovable date. The discipline that makes this work is proving it at every stage before scaling to the next. Start with one workload, such as monthly billing or a single settlement feed, in the incremental style the Azure Architecture Center calls the strangler fig pattern. Run it on the new system in shadow mode alongside the legacy system for a full business cycle. Keep the legacy system as the system of record during this period. Capture the new system’s intended actions, such as payments and client messages, without sending them. Next, compare both systems’ outputs for each transaction and resolve any differences. Test external integrations, peak-load performance and recovery procedures separately, since shadow running never exercises the actions it suppresses. Only then make the new system authoritative for that workload. Retain a tested recovery path through an agreed stabilization period, with a method for handling transactions recorded after cutover, and move on to the next workload. Where the architecture does not allow workloads to move independently, apply the same discipline to a coordinated group of them, with rehearsed cutovers and explicit acceptance criteria in place of the workload-by-workload sequence. Where even shadow running is not feasible, establish readiness through representative transaction replay, end-to-end testing and full cutover rehearsals, against the same acceptance criteria and with the same tested recovery path. This is slower than a big-bang migration by a factor that sometimes makes executives uncomfortable. It is also the approach that produces evidence, rather than hope, before each increase in production exposure. ## Keep the old system running until the new one has earned trust The strongest temptation in any migration is to switch off the legacy system early, because running two systems costs money and because the old one is what the program exists to eliminate. Resist it. In a regulated environment, the legacy system is the reference implementation. It is the baseline against which every output of the new system is evaluated. Explain and resolve every material difference between the two systems, never mistaking agreement for correctness; then check the results against the business rules and the authoritative records. When we moved a parking operator’s business from a VAX minicomputer to a cloud platform, the VAX ran alongside the cloud platform for months, and we reconciled every transaction between them until the new system earned the business’s trust. The parallel run let us catch and resolve issues before they reached customers. The cost of the parallel run was visible and budgeted. Had we skipped it, our customers would have discovered the errors, such as mischarged accounts and failed payments, before we did. Rehearsal matters at every scale. When Commonwealth Bank of Australia moved its core banking platform to the cloud in 2025, it conducted five full dress rehearsals of the cutover, having originally planned for three. During the actual cutover, it kept customers online throughout the three hours the core was down. Reconciling parallel outputs exposes discrepancies, and not every discrepancy is a defect in the new platform. Shadow running frequently uncovers latent bugs in the legacy system, such as rounding oddities, edge-case truncations or mishandled time zone changes, that went unnoticed because no independent system had ever checked the arithmetic. Classify each discrepancy as a new-system defect, an undocumented legacy defect or a deliberate change in method. New-system defects must be fixed. Legacy defects need an impact assessment, remediation and, where required, disclosure. Deliberate changes require approval from the business and, where applicable, the regulator. Working through that classification transparently earns the consensus needed to retire the legacy host. Reconciling transactions does not prove that the migrated data is complete. Before retiring the legacy system, validate balances, record counts and relationships between records, and confirm that historical records and audit evidence remain retrievable, whether in the new system or in a validated archive. ## Build the controls into the platform, not around it Regulated migrations often treat security, resiliency and auditability as a compliance workstream that runs beside the technical one. That is how gaps appear at cutover. Build the required controls into the target platform before the first workload arrives: automated data residency enforcement, encryption with customer-managed keys where the data classification calls for them, continuous monitoring, immutable audit trails and granular identity and access management. Every migrated system then inherits these controls from the start, and each workload’s use of them is verified. Compliance is not a post-deployment audit; it is a primary design constraint that dictates the perimeter of the technical solution. This matters doubly when the platform is intended to host AI. Models and agents will act on the data the migrated systems hold. Audit trails must be immutable and retrievable for years, and decisions that affect customers will need an explainability that many AI systems do not provide by default. If data lineage, access controls and the audit trail are not in place at migration, retrofitting them afterward is costly and often incomplete. Evidence that was never captured cannot be reconstructed, and the AI program will inherit a foundation that cannot withstand regulatory scrutiny. ## Govern with standards the business can read Enterprise architecture frameworks, such as TOGAF, provide the architecture team with a process; industry reference models, such as BIAN, give the business a vocabulary. The Banking Industry Architecture Network (BIAN) publishes a standard model that partitions a bank’s work into named business capabilities, such as payment execution or customer agreement, each with a standardized interface. When migrated services are mapped to that taxonomy rather than to legacy program names, a product owner or risk officer can read the migration plan, verify that a capability functions and sign off without needing to know what the old modules were called. The same artifacts, tied to test results and control evidence, can be presented to a regulator without translation. That shared language is what turns a migration from an IT project the business tolerates into a modernization the business owns. ## What it takes The five disciplines set out above hold whatever the technology: build a dependency map from observed system behavior; plan the cutover around the business calendar; prove correct transaction processing, through parallel running where feasible and through replay testing and rehearsed cutovers where it is not; establish platform controls before workloads arrive; and define governance in terms the business and its regulators understand. None of these practices is new. What is rare is the resolve to keep to them when delivery schedules tighten. The organizations that modernize successfully are not those with the most sophisticated target architecture. They treat careful planning, respect for legacy knowledge and business continuity as engineering requirements rather than aspirations, refusing to sacrifice verification for speed.

For years, one of the practical constraints in software testing was time. Writing test cases takes time, preparing data takes time, regression takes time and analyzing what happened after an incident can take even more time. AI is changing this very quickly. Today, a QA engineer can generate test data, write scripts, analyze logs or create dozens of test cases in seconds. From the outside, this looks like an obvious productivity win: if we can create more tests faster, quality should improve as well. Our experience shows that it is not that simple. At Gurtam, we have been experimenting with AI in QA for some time. We tried different models, worked on prompts, used AI for generating test cases from documentation and eventually built our own internal assistant for this purpose. The technology is already genuinely useful, but the more we use it, the clearer one limitation becomes: generating tests is becoming easier much faster than evaluating whether those tests are actually useful. This distinction matters, because volume and quality are not the same thing. ## More test cases do not automatically mean better testing Test generation seems like one of the most natural applications of generative AI. A task already has requirements; there is documentation and the model can use that context to produce positive scenarios, negative scenarios and boundary cases almost instantly. Recent research into LLM-based test generation reflects the same opportunity, while also showing that the quality and usefulness of generated tests remain highly dependent on context, evaluation methods and human expertise. In practice, we often see two extremes. If there is a lot of documentation, AI can generate a large number of cases, many of which add little value. They may look technically reasonable, but they do not necessarily improve coverage in a meaningful way. The QA engineer still has to review them, understand which cases matter and remove the rest. The opposite happens when documentation is incomplete. In that case, the generated tests are often too superficial. They cover what is explicitly written, but they miss relationships, dependencies and risks that are obvious only if you understand the product and the surrounding system. The output can still look convincing, but that does not mean it gives enough confidence in the quality of the feature. This is where AI exposes a familiar problem rather than eliminating it. A model can work only with the context available to it. If important product knowledge lives in people’s heads, in previous incidents or in an understanding of architecture that was never documented, the generated test cases will not magically contain that knowledge. ## We built our own assistant to see how far automation could go To make test generation more practical, we built an internal assistant. The workflow is simple: a QA engineer gives it the number of a task from our tracking system, the assistant finds the relevant documentation, combines that information with the task and generates test cases. We also created an interface where these cases can be reviewed, edited and removed if they are unnecessary. Once the QA engineer is satisfied with the result, the final set can be sent directly to the system where we store our test cases. This already removes a noticeable amount of repetitive work, which is useful on its own. But naturally, once you automate this much, the next question appears: can we remove the review step as well? In theory, it sounds reasonable. A product team creates and documents a task, a developer starts working on it and the AI assistant automatically generates the test cases. By the time development is finished, everything required for testing is already prepared. We considered such a flow. So far, though, our experience has not given us enough confidence to run it without human validation. The issue is not that AI cannot generate tests. It clearly can. The issue is that it can still produce a large number of unnecessary tests and at the same time miss something important. That means the review stage is not simply cosmetic. It is still part of the actual quality work. ## AI is already very useful when the task is clear This does not mean I am skeptical about using AI in QA. There are many areas where I think it already works very well. Test-data generation is an obvious example. If we need boundary values, test JSON objects or large amounts of synthetic data with different parameters, AI can prepare this much faster than a person would manually. Log analysis is another strong case. Sometimes we deal with very large volumes of logs that no engineer would realistically read line by line. AI can help identify what happened during a particular incident or at a specific point in time and narrow down the area we need to investigate. It is also useful for generating small scripts or applications that remove repetitive work. This can include scripts for load testing, data generation, file analysis, one-off automated tests or simple interfaces for test environments. The common pattern is that the engineer already understands what needs to be done. AI helps execute the task faster. In those scenarios, it works as a very strong assistant. Where I would be much more careful is when we move from execution to decision-making. ## The risky part is not automation itself, but giving AI the final say I would not currently trust AI with the complete process of writing and maintaining automated tests without supervision. In our own experiments, we have seen how easily it can generate unnecessary tests while still missing important scenarios. The same applies to complex, non-linear business logic. A model can process requirements, but understanding what is risky for the business or what behavior is acceptable in a particular context often requires more than what is written in documentation. I would also not rely on AI alone for deciding whether a release is ready. Release quality is not simply the sum of passed test cases. You need to understand what has changed, where the risks are, what dependencies exist, what was not covered and what the possible business impact is if something goes wrong. Data is another concern. Sensitive information disclosure is already recognized as a specific risk in LLM applications, particularly when systems process personal data, confidential business information or credentials. I would therefore be especially cautious about giving external models access to information that an organization cannot afford to expose. For now, the simplest principle still works well: trust, but verify. ## The role of QA is changing because the routine part is shrinking If AI takes over more repetitive regression work, basic test generation or routine execution, that does not mean QA becomes less relevant. It creates time for the things teams often postpone because there is never enough capacity. Testing architecture is one example. Risk modelling is another. There are also non-functional testing, test infrastructure, shift-left practices and involvement in business decisions before they become development problems. This is one of the reasons I see the profession moving towards Quality Engineering. Traditional QA is often associated with checking whether the finished product behaves according to requirements. Quality Engineering is broader. It means trying to reduce the possibility of defects appearing in the first place by influencing processes, architecture and automation. This also changes what we expect from experienced QA engineers. A technically strong tester should be able to test almost any task in the project. A strong Senior QA needs to see the project as a whole: its architecture, dependencies, risks and connection to business decisions. In a mature team, such a person becomes a link between business and development, not just the person who verifies a feature at the end. AI makes this transition more visible because the mechanical part of the work is becoming cheaper. The value moves towards understanding what actually needs attention. ## We will also have to test AI itself There is another side to this shift. AI is not only becoming a tool for QA; it is also becoming something QA engineers will increasingly have to test. We are already seeing more assistants, decision-making systems and AI-based product features. There are still no universally established practices for testing all of them, but I expect this to become a normal part of QA work. The direction is already visible in emerging AI assurance frameworks: NIST, for example, is developing structured approaches to test, evaluation, verification and validation of AI systems across LLMs, multimodal models and AI agents. Validating hallucinations, checking for toxicity, testing data leakage and resistance to prompt injection may soon become standard requirements in some QA roles. This makes the idea that AI will simply remove the need for QA difficult to take seriously. The more software relies on AI, the more new quality risks appear. AI models can make mistakes, hide errors, adjust tests to incorrect behavior or generate code with bugs. Another AI model may then fail to identify those same problems. Giving such a system full responsibility for release acceptance without human control is hard to imagine in any serious production environment today. ## The important question is no longer whether AI can generate tests It can. The more useful question is what happens after generation. Which cases are actually valuable? Which ones are redundant? What is missing? Which risks are not visible in the documentation? And does the final set of tests give us enough confidence in the product? AI is making the production of testing artefacts much faster. What it has not removed is the need for judgement. For QA engineers, that means the profession is not disappearing. It is becoming more analytical, more engineering-oriented and more connected to product and business decisions. And at least for now, the final responsibility for understanding whether the system is actually good enough still belongs to a person.

10 types of ambidextrous leadership required in the AI era In the world of corporate management, we face questions every day that don’t have easy answers. * We want to accelerate digital transformation, but we absolutely cannot neglect security. * We want to pursue company-wide optimization, but we also want to leverage the strengths of each business unit and the front lines. * I want employees to take on new challenges, but we must also ensure thorough risk management. If one option were right and the other wrong, decision-making wouldn’t be so difficult. What makes management challenging is that two conflicting demands are both correct. In parts 1–7 of this series, we’ve explored a sense of urgency and curiosity, customer focus and vision, challenges and digital transformation, data, collaboration between people and AI, DX talent, and organizational culture. In this final, eighth installment, we’ll examine the leadership of the CIO — the role responsible for bringing all of these elements together and driving them forward. I believe that what future CIOs need is not an OR mindset — choosing _between_ A or B — but an AND mindset — embracing _both_ A and B. More importantly, it is not simply a matter of finding a middle ground between A and B. It is about leveraging the strengths of both A and B to create a new C on a higher plane that encompasses both. I call this sublation. In other words: A or B (OR) ⇒ Both A and B (AND) ⇒ Toward a New C (Sublation) This is the concept. Isn’t this very ability — to reconcile these opposing elements and transcend them — the ambidextrous leadership required of CIOs in the AI era? ## The CIO is an executive who stands at the boundary Why is ambidexterity required of CIOs in particular? It is because CIOs constantly stand at various boundaries. * Management and the Front Lines * Business and technology * The entire company and individual departments * People and AI * Offense and defense * Present and future A CIO cannot do their job by focusing on just one of these worlds. They must understand and bridge the different logics and values of each, and work to derive better solutions for the company as a whole. That is precisely why the value of a CIO lies not merely in choosing one of these two worlds. It lies in standing at the boundary between these different worlds and transforming contradictions and conflicts into new values (sublation). I believe this is where the unique role of the CIO of the future lies. So, what kind of ambidexterity is specifically required? I believe the following 10 perspectives are crucial. ## 1. Deepening and exploration: Shaping the future while refining the existing The first is deepening and exploration. Deepening — refining existing businesses and operations to enhance quality, productivity, and profitability—is the foundation of corporate management. On the other hand, focusing solely on the extension of the status quo makes it impossible to respond to major environmental changes. Exploration—seeking out new technologies, customer value, and business models—is also indispensable. Especially in an era marked by the emergence of disruptive technologies like AI, it is not enough to simply ask, How can we use AI to streamline our current operations? We must consider how to restructure our work and business itself, assuming AI is a given. Through Deepening × Exploration, we strengthen today while creating tomorrow. This is the first synthesis. ## 2. Overall optimization and individual optimization: strengthening frontline operations on a company-wide common foundation The CIO is in a position to oversee IT architecture, data, security, and policies from a bird’s-eye view and pursue overall optimization. However, this does not mean that everything should be standardized company-wide. Excessive standardization risks undermining the speed and strengths of individual business units and frontline operations. The key is to discern what should be standardized and what should be left to the front lines. Foundational elements that should be standardized company-wide must be firmly standardized. On the other hand, in areas that drive competitiveness and customer value, we increase the freedom of frontline operations. By balancing overall optimization with individual optimization, we strengthen the front lines while building on a company-wide common foundation. This is the CIO’s design capability. ## 3. Offense and defense: Strong guardrails enable full throttle The third point is offense and defense. We accelerate productivity improvements and value creation through DX, AI, and data utilization. At the same time, we rigorously enforce cybersecurity, personal information protection, AI governance, and stable system operations. The CIO is responsible for both of these areas. Here, I do not view defense as a brake. Defense is a guardrail. If you step on the brakes, the car stops. However, with sturdy guardrails in place, you can step on the gas with confidence. Security and governance are the same. Rather than adding more things you must not do, we clearly define the boundaries within which we can take on challenges with confidence. By strengthening our defense, we accelerate our offense. This is the very essence of the synthesis of offense and defense. ## 4. Speed and quality: Creating a rapid learning cycle The fourth point is speed and quality. In the rapidly changing era of AI, if we wait until something is perfect, the underlying assumptions themselves may have changed by the time it’s finished. That is precisely why it is important to test in small, rapid increments. However, speed does not mean sacrificing quality. It’s not a choice between speed and quality; rather, it’s: Test quickly → Get feedback → Learn → Improve …and running this cycle at high speed. It is crucial to combine speed and quality to create a high-speed learning and improvement cycle. ## 5. Challenge and risk management: Creating a system that enables risk-taking DX is about taking on unprecedented challenges. Naturally, challenges carry the risk of failure. However, if we try to eliminate risk, we will be unable to take on challenges at all. Moreover, in an era of rapid environmental change, doing nothing itself becomes a major risk. What a CIO should be considering is not whether or not to take risks. * Which risks should we take? * Which risks will you absolutely not take? * If we fail, how much failure can we tolerate? It is essential to clarify these points. In other words, the purpose of risk management is not to stop people from taking on challenges, but to create a system that allows them to take risks with confidence. ## 6. Top-down and bottom-up: Strong direction, autonomous execution When embarking on major transformation, a top-down approach—where management shares a sense of urgency and clearly articulates a vision—is essential. However, if top management decides all the answers, frontline employees will not be able to take ownership of the initiative. Management must address: * **Why** the change is happening * and **where** and then: * **What** we will work on * and **how** we will achieve it draws out the wisdom and ingenuity of the front-line staff to the fullest. Strong direction, autonomous execution. By combining top-down and bottom-up approaches, transformation evolves into a movement across the entire organization. ## 7. Control and autonomy: Running freely within guardrails The seventh point is control and autonomy. For example, when it comes to AI adoption, allowing employees to use it freely without any rules carries risks. On the other hand, if we restrict its use too much with strict rules, adoption itself will not progress. This is where the concept of guardrails comes into play once again. Clarify the minimum rules that must be followed. However, within those boundaries, grant the front lines a great deal of freedom. In other words, rather than closing off the road, we create a road where people can drive quickly and with peace of mind. Rather than using control to stifle autonomy, we use control to enable autonomy. This is the synthesis of control and autonomy. ## 8. Short-term and long-term: Using short-term results as a catalyst for long-term transformation In business management, short-term results are required. When it comes to DX investments, there is a responsibility to explain what kind of results they have produced. On the other hand, if we pursue only short-term results, investments that build future competitiveness — such as talent development, data management, and IT infrastructure renewal — will be put on the back burner. What is needed is to avoid separating the short term from the long term. 1. First, deliver small but certain results. 2. Use those results to earn the trust of management and frontline staff. 3. Use that trust and management resources to fuel the next round of long-term investments. 4. This, in turn, generates even greater results. Turn short-term results into a flywheel that keeps long-term transformation moving. This is the eighth example of ambidexterity. ## 9. Efficiency and value creation: From DX that reduces to DX that creates In the early stages of DX, I believe it is common to start with efficiency improvements, such as reducing working hours and cutting costs. Of course, these efforts have significant value in and of themselves. However, DX must not end with efficiency alone. For example, if AI reduces a task that used to take 10 hours to just 3 hours, we shouldn’t stop at simply saying, We saved 7 hours. Instead, we need to consider: What new things can we do with those 7 hours, and what kind of value can we create? For example, * Use it for interactions with customers. * Develop new services. * Use it for employee development. * Work on solving social issues. * Reinvesting the resources freed up through efficiency improvements into creating new value. From DX that cuts costs to DX that creates value. This is the synthesis of efficiency and value creation. ## 10. Psychological safety and high-performance expectations: Taking on lofty challenges with confidence Finally, we have psychological safety and high-performance expectations. The term psychological safety is sometimes misunderstood as referring to an organization that aims to be lax or too lenient. However, the reality is quite the opposite. * People feel safe expressing their opinions. * You can feel safe saying, I don’t know. * You can feel safe asking for help. * You can feel safe taking on challenges and sharing your failures. It is precisely because this kind of environment exists that people can take on difficult challenges. Our goal is not to be an organization that merely prioritizes psychological safety, nor one that focuses solely on performance demands. It is an organization where people feel safe taking on the highest peaks. Take on a challenge → Fail → Learn → Share → Take on the challenge again I believe that a learning organization where this cycle turns rapidly is the one that can establish a competitive advantage in the VUCA era. ## What emerges when we synthesize the 10 Ambidextries? Summarizing the 10 points discussed so far, we arrive at the following: **Binary oppositions**| **The result of sublation** ---|--- Deepening vs. exploration| Strengthening today while building tomorrow Overall optimization vs. individual optimization| Strengthening the front lines on a shared foundation Offensive vs. defense| Management that lets you step on the gas with confidence Speed vs. quality| Rapid learning and improvement cycles Challenge vs. risk management| A system that allows you to take risks with confidence Top-down vs. bottom-up| Strong direction, autonomous execution Control vs. autonomy| Autonomy within the guardrails Short-term vs. long-term| Leveraging short-term results to drive Long-term transformation Efficiency vs. value creation| From DX that eliminates to DX that creates Psychological safety vs. High-performance expectations| An organization where people feel secure enough to take on challenging goals What I want to emphasize here is that being ambidextrous does not mean striking a 50-50 balance. Depending on the situation, there are times when speed should be prioritized, and there are areas where quality must be given absolute priority. There are situations that require a top-down approach, and others where decision-making should be left to the front lines. What matters is not which to choose or striking a balance between the two. It is about understanding the intrinsic value of both, leveraging the tension between them, and creating a better third solution. Generate a rapid learning cycle from speed and quality. Create autonomy within guardrails from control and autonomy. By combining psychological safety with high-performance expectations, we create an organization where people feel secure enough to take on challenging goals. Rather than compromising between A and B, we create a new C from A × B. This is precisely what I mean by sublation. A CIO is not someone who resolves contradictions, but someone who reconciles two conflicting demands at a higher level. Contradictions are an inevitable part of business management. And the higher one rises in rank and the broader one’s scope of responsibility becomes, the fewer single correct answers there are. That is precisely why what is required of a CIO is not to eliminate contradictions. Rather, it is to accept them. Understand both sides’ perspectives. Consider the essence underlying the conflict. And transform that tension into energy that generates new value. I believe that an outstanding CIO is not someone who resolves contradictions and quickly arrives at a binary choice, but rather someone who can thoroughly think through ways to reconcile two seemingly contradictory demands at a higher level. In that sense, a CIO is not merely an IT manager. They are expected to be ambidextrous executives. ## In conclusion: And onward to the ‘New C’ In this series, we have examined the key principles for accelerating DX and achieving sustained results from various angles. Looking back, the essence of DX is not digital technology itself. * It is about transforming management. * Transforming work. * Developing people. * Transforming organizational culture. * Delivering new value to customers and society. * Create a new future. I believe transformation is what connects all of these. The more AI evolves, the more it will take on the role of gathering and analyzing information and presenting options. That is precisely why human leaders will be required — more than ever before — to have the ability to tackle questions that cannot be answered with a simple either/or choice. * Management and IT * People and AI * Offense and defense * Logic and empathy * Present and future Standing at that boundary, we bridge differing values, embrace contradictions and choose a better future. And from there, we create new values that have never existed before. Isn’t that the role of a CIO in the age of AI? Not either A or B, but both A and B. And then on to a new C beyond that. Reconciling and synthesizing opposing forces. This powerful ambidextrous leadership is precisely the kind of leadership required of a CIO in the AI era.

The US Federal Bureau of Investigation has removed an Accenture contractor working on its PeopleSoft installation over their role in a data breach that exposed personal details of FBI employees, Reuters reported Monday. This is the first time that anyone other than the hacker group Shinyhunters that claimed responsibility for the breach has linked it to PeopleSoft. “To date, our review has determined that the incident occurred as the result of a security failure of a platform managed by a third-party organization — after a contractor failed to implement a security patch explicitly issued to secure the platform,” FBI Cyber Division Assistant Director Brett Leatherman told Reuters. “As such, the FBI has removed the contractor and taken all necessary steps to both mitigate any further risk and protect our workforce.” Accenture was the third-party organization Leatherman would not identify, “two sources familiar with the matter” told Reuters. As for the unnamed, unpatched platform, Reuters’ sources said that was Oracle PeopleSoft, the HR system that hacker group ShinyHunters claimed to have exploited in last month’s break-in. _This article first appeared on_ CSO_._

SAP has launched new AI agents and assistants across multiple domains at its SAP Connect event, saying that its October update is fulfilling the promises it made around its vision of the Autonomous Enterprise at Sapphire in May. The SAP Autonomous Enterprise comprises capabilities in Joule Work and SAP Autonomous Suite, built on the SAP Business AI Platform. The assistants and agents, as well as Joule Studio and Joule Work, will be offered as SAP-managed products via the SAP for Me portal; their general availability begins this month. Like many other vendors, SAP is turning its agents into a front end for its products. While Joule used to be just a natural language-based chat client, its scope has expanded, said Manoj Swaminathan, president and chief product officer, SAP Autonomous Suite. “Joule Work now becomes one harmonized experience for anything and everything that the users can interact with, with agents backing it as part of the autonomous suite, fueled and powered by the platform,” he said. Users can still use the traditional SAP interface if they wish to. “Systems-of-record-based applications still will be there, but they are now provided with these agentic experiences as well as AI on apps,” he said, “so that if a customer chooses to, they can now take advantage of them either in a semi-autonomous way or a fully autonomous way.” SAP said that Joule Work is already live with 110,000 employees within the company, and claims 20% productivity gains across finance, HR, and procurement. At the conference, SAP showcased SAP Autonomous Suite capabilities in finance, where it can automate revenue recognition, disclosures, and trade compliance; in supply chain, where planners “can turn multi-hour disruptions into one-click resolutions across planning, manufacturing and logistics;” as well as in HR, procurement, and customer experience. ## Cloud ERP updates The latest release of the SAP-managed public cloud ERP offers deeper integration across SAP Autonomous Suite. SAP S/4HANA Cloud Public Edition now integrates with SAP Ariba and SAP Sales Cloud solutions, while links to SAP Taulia, SAP Subscription Billing, and SAP SuccessFactors will be made available before year end. Even SAP’s on-premises offering, Cloud ERP Private, is getting the managed AI services treatment, with new integrations with Joule all delivered and maintained by SAP. It is currently available through the SAP Early Adopter Care program, with general availability planned by year-end. Analysts displayed varying levels of enthusiasm about the announcements. Thomas Randall, research lead at Info-Tech Research Group, was unimpressed. “SAP Connect is not giving us any breakthrough moments,” he said. “Microsoft, Salesforce, ServiceNow, Oracle, and the hyperscalers have already established comparable assistants, agent studios, multi-agent orchestration, model choice, and governance capabilities. SAP’s announcements are best understood as fast-following AI technology for business-process suites.” However, he does see potential. “SAP’s opportunity to pull ahead lies in its positioning AI as a controlled execution layer for back-office operations,” he noted. “Few vendors can match its combination of process depth, transactional authority, industry-specific configuration, and installed footprint. This gives SAP a distinct advantage: its systems are already trusted to move money, adjust plans, release orders, and record the resulting business consequences. I look forward to seeing this advantage in action.” Jason Andersen, principal analyst, apps, agents and automation at Moor Insights & Strategy, has a more positive view. First, he said, SAP is showing that it can deliver as planned on the promises made at Sapphire earlier this year. “Notable are a series of task or role driven agents that will augment common roles in many enterprises such as procurement and supply chain roles,” he said. And, he added, “There is also the backing of the SAP Business AI Platform, which will help enterprises customize these agents to the specific processes and standards for each company. This is a great way for providers like SAP to embed decades of customer understanding within agents but also enable customers to tune them to suit their needs. While the more specific agents get a lot of attention, I also think that SAP’s advances with Joule Studio and Desktop can help workers deliver SAP capabilities in the context of common business remain notable.” ## Risk management However, independent technology analyst Carmi Levy cautioned that there is a wide gap between plans and reality. “As agentic tools draw ever closer to core organizational workflows, enterprise decision makers face amplified concerns around data integrity, privacy, and accuracy,” he said. “Elevated agentic risks should be a primary concern for SAP shops, while SAP’s third-party integration should raise alarm bells among leaders worried about guardrails being violated across the organization.” While SAP’s announcement goes into significant detail explaining how tightened protocols around authentication, governance, and identity management ensure agents won’t exceed defined limits, he said, it fails to address agents’ vulnerability to new forms of attack such as model injection that organizations must now deal with. “Agentic AI is already rewriting the cybersecurity playbook for all enterprises, and vendors owe it to customers to explicitly explain how they intend to mitigate the risk,” he said. “Automated AI agents will ultimately rewrite how work gets done in the same way earlier technologies, like PCs and smartphones, similarly rewrote the rules of modern work,” he said. “But AI agents introduce enough additional baggage into the equation that handing entire processes over to automation at this fraught moment in their development is hardly the recipe for C-Suite harmony.”

For years, cybersecurity has been measured largely through an IT lens: protect data, prevent intrusions, and keep business systems available. While that framework still matters, it does not fully account for the systems that keep physical operations resilient in the event of an incident. Operational environments rely on connected technologies that monitor, control, or support physical operations, including cyber-physical systems (CPS), operational technology (OT), the internet of things (IoT), the internet of medical things (IoMT), and building management systems (BMS). These assets are increasingly connected to enterprise networks, cloud platforms, remote-management tools, and third-party vendors. While this connectivity helps organizations operate more efficiently, it also creates more pathways into systems that impose new risks on production, patient care, facility uptime, and service delivery. ### **Understand the operational impact of cyber risk** When the operational layer is compromised, the impact may not look like a typical breach. It can look like an outage, a safety hazard, or a process that can no longer run as expected – all of which have significant financial implications. Claroty’s 2026 global survey reveals how often cyber incidents are already reaching operational environments. Fifty-eight percent of respondents said their organization experienced a cyberattack that affected operations in the past 12 months. The average incident caused three days of downtime and $1.04 million in financial losses. Forty percent of respondents also reported a safety incident or hazard following a significant CPS-related incident. For a manufacturer, disruption could mean a production line stops, or product quality is affected. In healthcare, it could mean a connected device or supporting system is unavailable when care teams need it. In a data center, it could mean problems with the power, cooling, or environmental systems that keep the facility online. ### **Prioritize by operational impact, not just vulnerabilities** That changes how organizations need to prioritize risk. A vulnerability on a system supporting a noncritical function is not the same as one affecting power distribution, cooling, production lines, or clinical operations. Exposure management helps organizations prioritize devices and exposures based on their potential impact to the business, rather than treating every vulnerability equally. The challenge is that many organizations still lack the context to make that distinction. An asset inventory is important, but it is only a starting point. Teams need to know not only which assets are in their environment but also what they connect to, who can access them, and which operational process they support. Vulnerability data and exposures should also be correlated with asset criticality, communication pathways, and other CPS context to help inform decision-makers on remediation and mitigation. Eliminating every risk is an impossible task. Many operational systems have long lifecycles, proprietary or legacy protocols, and limited maintenance windows. Taking a system offline for a patch or upgrade may disrupt production or service delivery. In these cases, exposure management helps organizations assess the potential business impact of a compromise and determine how best to reduce risk while maintaining business continuity. AI adds another layer to the operational risk equation, but it can also help teams manage growing complexity. Seventy percent of respondents said their organization is using AI to some degree across OT and CPS environments. AI can help teams make better use of asset data and focus attention where it matters most. But 40% said it has also introduced new cybersecurity, compliance, or operational risks, underscoring the need to understand what these tools connect to and which business processes depend on them. ### **Close the governance gap across IT and operations** CIOs are increasingly responsible for bridging the gap between IT and operations, even when the systems themselves sit outside traditional IT ownership. In Claroty’s survey, 39% of respondents identified CIOs or IT organizations as primarily accountable for CPS security. Yet only 16% said IT and operational security governance is fully integrated. That gap is where risk builds. IT, security, and operations each hold a different piece of the risk picture. When they operate through separate processes and priorities, no one has a complete view. Third-party access is a clear example. Vendors often need remote access to maintain specialized equipment. While that access may be necessary, it needs to be governed and monitored like any other connection into a critical environment. Three-quarters of survey respondents reported at least one operational incident related to third-party access, while 49% had only partial or no monitoring of third-party connections to operational assets. CIOs do not need to solve every problem at once. The starting point is understanding which connected assets support critical operations, reducing unnecessary exposure and ensuring recovery plans account for the systems that keep their business running. When a cyber incident can stop production, affect care delivery, or take a facility offline, operational security is a business resilience issue. Explore Claroty’s latest global research for a closer look at how cyber threats are affecting physical operations and how organizations are evolving their cyber-physical systems security strategies in response.

ServiceNow has launched two AI solutions that can help enterprises identify business processes ripe for automation, build the workflows to address them, and continuously improve them with AI agents. AI Workflow Factory and Autonomous Engineer, announced on Tuesday, will bring process discovery, AI-assisted development and workflow execution into a single system that ServiceNow says can help enterprises move from individual AI projects to continuous workflow improvement. “Instead of starting a new transformation project each time a business problem surfaces, every outcome helps reveal the next opportunity for multi-process improvement with AI,” the company said in a statement. AI Workflow Factory connects Process Mining, Autonomous Engineer, Build Agent, and App Engine. Process Mining identifies processes that can be improved based on business metrics, while the development tools build and test workflow changes, and App Engine runs them at scale, the statement added. ServiceNow described the approach as a “continuous workflow improvement loop,” connecting process discovery, development, and deployment. It said the model allows an enterprise to use the results of one improvement to identify the next opportunity rather than launching a separate project each time. Sanchit Vir Gogia, chief analyst at Greyhound Research, said the approach addresses the coordination required to turn a process problem into a deployed improvement, but does not remove the need to address the underlying business process. “Data and integration remain its connective tissue. Faster building still leaves ownership and process redesign unresolved unless the enterprise addresses them explicitly,” Gogia said. ## Measuring the payoff ServiceNow said AI Workflow Factory can be used for specific business outcomes. It cited a case-deflection example in which Process Mining identifies where cases can be deflected, after which AI agents can build and deploy workflows across business units and continue refining them against the target outcome. The company said people would continue to set the direction and approve outcomes while AI takes on more of the work involved in building and operating workflows. Gogia said CIOs should evaluate the business benefit alongside the ongoing cost of running the resulting automation. “Process owners have reason to feel relief when repetitive implementation becomes easier, but the benefit depends on accepting and maintaining what is built,” he said. “CIOs should measure the business outcome alongside recurring platform costs.” Gogia also said enterprises should account for workflow retirement when calculating the value of automation. The test, he said, is whether savings continue after a workflow enters production. ## Autonomy needs boundaries Autonomous Engineer addresses the development work required to turn requirements into applications and workflows. ServiceNow said it supports “unattended coding for autonomous planning, building, and testing of implementation work” while allowing developers to retain control over critical decisions. The capability can create an implementation plan and, following human approval, carry out development and testing work, according to ServiceNow. Gogia said enterprises should determine how much work can be delegated based on the nature of the task rather than setting a universal target for autonomous development. “Delegation should follow task clarity and reversibility, with independent validation before release,” he said. “No universal percentage describes how much enterprise development can safely be delegated.” He also cautioned against relying entirely on AI-generated testing when implementation and its tests are based on the same interpretation of a requirement. “An engineering leader’s caution is justified when implementation and generated tests share the same reading of a requirement,” Gogia said. ServiceNow said its process includes approval of the implementation plan and human validation of completed work. Gogia said scoped permissions and bounded environments can limit an agent’s potential impact, while tested revocation and recovery can help enterprises control its authority. “Production responsibility must remain explicit even when implementation is unattended,” he said. ## Governance brings a new question ServiceNow is also making governance part of the workflow model. It said its AI Control Tower provides centralized oversight of AI workflows, decisions, and agent actions running through AI Workflow Factory. Its Action Fabric capability extends that model to third-party AI agents and tools. It said the approach gives enterprises “one governed view for the enterprise” while allowing them to use other AI development tools and third-party agents. Gogia noted that enterprises need coordinated governance across agents, with authority defined for each system. He said ServiceNow has a role because its workflows connect business decisions to actions, but cautioned that interoperability does not necessarily mean equivalent governance or enforcement. “Policies and audit evidence create platform gravity,” Gogia said. “Open protocols help systems communicate, but do not establish equivalent enforcement or portable enterprise controls.” For CIOs, that makes the ability to revoke agent authority and recover from a control-plane failure an important consideration, he pointed out. “An enterprise should be able to replace its governance platform without losing the evidence of how it governed,” Gogia said. AI Workflow Factory is globally available, while Autonomous Engineer is available through an early-access program on request, the statement added.

Google is overhauling its cloud modernization portfolio by bringing its existing migration and modernization tools along with new agentic migration tools and a new Modernization Hub under a new Google Cloud Modernize umbrella to accelerate infrastructure and application transformation at enterprises. The new agentic tools include an EKS-to-GKE Migration Agent, designed to help enterprises move Kubernetes workloads from Amazon EKS to Google Kubernetes Engine (GKE). The agent can analyze existing EKS environments, translate Kubernetes manifests, map storage and networking requirements, and help prepare workloads for deployment on GKE, with human approval points built into the process, the company wrote in a blog post. Alongside that agent, Google is also adding new capabilities to its Migration Center’s Quick Estimator Agent. These new capabilities will allow enterprise users to generate total cost of ownership estimates from infrastructure data, including VMware inventory exports, and test different migration scenarios and cost assumptions in natural language. The Migration Center itself is being rolled into Cloud Modernize and will continue to offer tools around migration planning and assessment. Beyond the agentic capabilities and the Migration Center, the hyperscaler is consolidating its application modernization tools, such as the App Modernization CLI, Java and .NET modernization capabilities, and mainframe tools including the Mainframe Assessment Tool, Dual Run and Mainframe Connector, under a new Modernization Hub. The new Hub, which will be accessible via the Google Cloud Console, will also be a part of the umbrella offering, the company wrote. ## Unification of tools could simplify operations For CIOs, the consolidation of existing modernization and migration tools under a broader umbrella offering could simplify operations and decision-making as it turns what was previously a collection of separate tools into “one end-to-end process”, said Pareekh Jain, principal analyst at Pareekh Consulting. “An enterprise might have VMware workloads, Java applications, mainframes, Oracle databases and Kubernetes applications running across different clouds. Previously, these could require separate tools, assessments and migration teams. With the broader offering, CIOs require fewer handoffs, faster decisions and better visibility across a large modernization program,” Jain said. The consolidation of the Modernization Hub also provides similar benefits. “Instead of fragmented tools, the new Hub provides a consolidated assessment workflow. It gives CIOs one place to assess, plan and manage application modernization,” said Viet-Anh Nguyen, machine learning lead at Scopic Software. “Earlier, capabilities were spread across different Google tools. Teams can now understand applications and dependencies, get modernization recommendations and decide what to migrate, rehost or refactor from a more unified interface,” echoed Jain. Similarly, the EKS-to-GKE Migration Agent could reduce the manual work for developers and platform teams. “Since the Agent can automatically discover and translate AWS-specific infrastructure and Kubernetes configurations, validate the outputs, and create pull requests for human review, it reduces repetitive engineering,” Nguyen said. That, in turn, could make switching clouds faster, cheaper, and less risky, Jain pointed out. However, the Agent doesn’t eliminate testing, architectural decisions, data migration, or production cutover, which means teams still have to own these steps, Jain said. _The article originally appeared on NetworkWorld._

Many organizations have licensed language models, tested AI agents, and asked DevOps teams to develop code-generation standards. But production deployments are still a work in progress for CIOs, with only 50% of organizations moving more than half of their AI projects from pilot to production, according to Outsystems’ State of AI Development 2026 report. Increasing production deployments is a key step for many CIOs, followed by fostering more widespread employee adoption. But usage doesn’t always translate to business outcomes, leaving many IT organizations struggling to deliver business value on their AI initiatives. Much of that has to do with how they’re measuring AI value. “Too many organizations are treating AI adoption as the metric when the real question is whether it’s improving business outcomes,” says Rob Scudiere, CTO at Verint. “The metrics that matter are the ones executives already track, and if those numbers aren’t improving, it’s hard to argue that AI is delivering meaningful value.” Measuring how AI impacts the business strategy and its relevant KPIs is a vital first step, especially when it comes to identifying AI’s business-specific opportunities and risks. After all, AI’s capabilities, practices, and security considerations are changing so quickly that it’s essential for C-level leaders to discuss AI’s strategic business value frequently — and to do so with the right data to back those discussions up. That, in turn, requires a more collaborative leadership approach. “Organizations should align with business stakeholders upfront on the ‘so what,’” says Keyur Ajmera, CIO at Boomi. “CIOs should partner with CMOs, CHROs, CFOs, and business practitioners to identify use cases, establish appropriate governance and standardization, prepare employees for new ways of working, and create financial guardrails as usage-based AI costs become more prevalent.” I heard from more than 30 leaders on their picks for the business value metrics that matter most when tracking your AI strategy’s impact. Below are my top five worth adopting. ## Growth driven by organizational expertise For AI to be transformational and not just reshaping business, executives must show that building greater expertise through AI drives business growth. “Executives primarily talk about AI ROI in terms of cost savings and efficiency, and that doesn’t adequately measure long-term AI success, because it doesn’t capture whether the organization is actually getting smarter,” says Sarah Edwards, chief product and strategy officer at Kantata. “I’d point them to what I think of as an organization’s expertise compounding rate, which is its ability to capture, synthesize, scale, and continuously build on institutional and tribal knowledge,” she adds. “Firms also need to look beyond productivity and efficiency and consider how AI drives revenue growth, including new pipelines, better client retention, new pricing models, and the ability to take on more projects without adding headcount.” **Ways to measure** : Track how expertise developed via AI capabilities drives revenue. Examples include: * DevOps teams, newly trained on vibe coding tools, help increase revenue by adding AI capabilities such as shopping concierge agents and genAI search capabilities to customer-facing websites. * Benchmarking return on ad spend (ROAS) between two campaigns, one developed by a team using AI tools, the other without using AI. * Contact centers using AI to support service-to-sales or sales-through-service competencies can measure increases in revenue per agent hour or offer conversion rates. In one famous case, Ikea built a new €1.3 billion business line, thanks to a contact center chatbot freeing up associates’ time. The key pattern is that when AI is introduced into a sales, marketing, or support function, it can be correlated with revenue increases. ## Improved customer retention Improving customer retention is a key metric for products or services, especially those with subscription business models. Customer loyalty and the ability to influence repeat purchases are similar KPIs when the brand influences pricing and customer-perceived value. How CIOs implement data and AI governance can positively or negatively affect customer retention. According to the State of Digital Trust 2026 from Usercentrics, consumers will now pay 7% more for the brands that have earned their trust around AI. Meanwhile, 24% of consumers canceled a subscription or stopped buying from a brand because they were concerned about how their data was used in AI. Donna Dror, CEO at Usercentrics, says, “Most CIOs can measure what AI saves them, but the harder number, and the one that shows up in revenue, is what mishandling data in AI costs in lost customers.” **Ways to measure** : Measure consent withdrawals, Data Subject Access Requests (DSARs), or AI feature opt-out rates. Businesses with subscription products can track renewal rates in the 90 days following an AI feature launch and add a data-and-AI-use reason code to the cancellation flows. ## Employee capabilities beyond productivity I’ve warned CIOs that focusing on AI’s productivity improvements is a trap, because at some point the CFO will look for cost savings through headcount reductions. Other metrics beyond productivity may matter more, especially for organizations investing in agentic AI workflows. The first is time-to-decision: AI agents are either capable of taking action autonomously, or they are implemented to include human collaboration in decision-making. CIOs and the business owners of AI agents should determine how to measure the business impact of faster, smarter decision-making. “Most AI scorecards measure activity, including agents deployed, tasks automated, and prompts processed,” says Vikram Bhandari, chief technology and innovation officer at Riveron. “The metric I push clients toward is time to decision, such as how much faster finance or ops teams can act once AI is in the workflow, and what that speed translates to in revenue or risk avoided. Headcount metrics tell you AI has replaced work, while decision-speed metrics tell you AI changed the business.” Enterprises can scale beyond individual productivity improvements by re-engineering business processes using AI orchestration platforms. But CIOs have to get AI democratization right by influencing experts to build the organization’s knowledge base and the AI context layer utilized by AI agents. “Data democratization’s real number is the percentage of institutional knowledge anyone can self-serve, without tracking down one specific person,” says Chris Cope, VP of engineering at CADDi. “Manufacturers map every flow on the factory floor and fixate on single-source supplier risk, yet miss the same risk when it’s a person holding the knowledge.” **Ways to measure** : In risk management functions, measure time-to-decision as the difference between mean time to remediate (MTTR) and mean time to detect (MTTD). Measure knowledge management impacts by tracking increased utilization of internal LLMs, while capturing the reduced time spent on answering requests for information (RFIs) by subject matter experts. ## Impacts to customer and employee experience CIOs should hunt for examples of value delivered to customers and for employees that go beyond doing today’s job better. This means exploring areas where AI provides a business capability that is not feasible, or is economically unscalable, if people were performing the function without AI capabilities. Venkat Ramakrishnan, president and COO at NeuBird, shares this example in IT and security incident management: “The focus has shifted from how fast you resolved an incident to how many users never felt it in the first place. When AI prevents an incident 30 minutes before failure, or resolves it in under 5 minutes instead of 175, it eliminates the experience impact rather than only reducing it,” Ramakrishnan says. Other examples require exploring game-changing operational transformations in other departments, or finding areas where AI impacts the connected experiences of customers and employees (CX and EX). “CIOs should measure genAI by whether it changes the economics of the business such as decision velocity, capacity created per employee, exceptions resolved without escalation, revenue leakage recovered, customer and employee effort avoided, and ultimately the rate at which AI benefits reach the P&L,” says Arun Raghavapudi, chief customer officer at R Systems (RSI). “The strongest AI strategy is therefore one where CX, EX, engineering, and business KPIs form a single value chain rather than separate technology scorecards.” **Ways to measure** : CIOs should identify AI-native capabilities, those business and operational competencies that are net-new AI use cases. Once identified, business value metrics determine the value delivered, and the AI-native capabilities become marketable innovations to communicate across the company. ## Measure AI’s operational impacts Many CIOs used lift-and-shift cloud migration strategies or overly empowered DevOps teams to procure cloud infrastructure, only to find skyrocketing costs. CIOs applied FinOps best practices and shifted-left financial considerations to reduce costs and instill fiscal discipline. Even as token costs decline, AI cost debt is very real as consumption of AI models and use of AI agents increases. Tokenomics tracks and manages both costs and the business value delivered from spending on AI tokens. On the cost side, CIOs should factor in the human-effort costs, including the AI hallucination tax when employees have to recognize when AI models and agents are wrong. “Token spend is becoming a real line item, and if it grows faster than the outcomes it produces, that’s a unit economics problem, not a scaling milestone to be proud of,” says Yasmin Rajabi, COO of CloudBolt. “The metrics that matter include how often AI-generated work is accepted without rework, how many decisions or actions run without a human in the loop, and value per token you get for every token you spend.” Measuring the value of operational impacts needs to consider both tactical impacts based on individual contributions versus team, department, and business-level outcomes. “Indicators that AI is creating measurable value rather than simply generating activity include whether critical workflows are completed quicker, decisions are more consistent, and AI-generated recommendations are traceable back to authoritative information,” says Tony Grout, chief product and technology officer at M-Files. “The most successful AI programs will be judged by whether they deliver better business outcomes like faster project completion, higher-quality customer service, improved compliance, and more consistent decision-making.” **Ways to measure** : My research on AI agent orchestration platforms identifies several platforms that include tokenomics capabilities, including solutions from Boomi, Cisco, Databricks, Kamiwaze, LangChain, Microsoft, Nutanix, PagerDuty, Salesforce, Snowflake, Tray.ai, and Workato. ## Setting realistic expectations CIOs must lead a progression from AI experiments to production deployments, enterprise adoption, and delivered value. But the organization’s velocity to adopt and deliver value requires a strong change management program that adjusts to business demand, especially if the AI bubble bursts. “The reality is that enterprise AI follows a productivity J-curve, where companies invest in new skills, operating models, governance, and process redesign long before the full economic benefits become visible,” says Kris Lovejoy, global head of strategy at Kyndryl. “As a result, usage often rises months before measurable business outcomes appear, and this is one reason many executives feel uncertain about the return they’re getting from AI.” While AI agent deployment and employee adoption are not the end game, CIOs must excel at these before overpromising business value. Two places to start include upskilling IT for agentic AI while avoiding mistakes when deploying AI agents.

A senior executive at a large enterprise recently described a capital allocation review to me. The committee had spent two hours deciding where the next tranche of maintenance capital should go. The discussion drew on last year’s budget, a regional presentation and the persuasive advocacy of a plant head who had been escalating the same request for three quarters. Somewhere in that same organization sat a predictive model estimating failure risk across the asset base. It was reasonably good. A competent team had built it sometime earlier. Nobody in the room referred to it or mentioned it. What bothered him was not that the model was wrong. It was not wrong. It wasn’t late, and it wasn’t hard to access. It simply had no relationship with the decision. I have heard enough versions of that story to believe it describes the central problem in enterprise AI right now — and that we are consistently solving for the wrong thing. ## AI adoption is no longer the constraint Mckinsey’s The State of AI in 2026 makes the point clearly. Almost nine in ten organizations report regular AI use in at least one business function, and around 44% say AI is scaling across the enterprise. Eight in ten report higher individual productivity. Yet only about 37% attribute any positive enterprise-level EBIT impact to AI. BCG’s survey of large-company CEOs found nearly nine in ten reporting cost or revenue benefits in targeted areas — while more than half cited a missing link between AI and P&L, and only 14% had clearly defined P&L impact across their AI initiatives. PwC’s 2026 CEO survey put it even more starkly: 12% of CEOs said AI had delivered both revenue gains and cost reductions. Individual productivity is rising faster than enterprise performance. That gap cannot be explained by technology alone, and more tooling should not be the default response. Part of the cause is how we frame AI in the first place. I ran an informal poll among my own network recently — not research, but directionally interesting — and 57% of respondents said automation and efficiency were the first things that came to mind when they heard the word “AI.” If that is the default mental model, then AI gets pointed at existing work to make it faster or cheaper. It rarely gets pointed at the question of what the enterprise ought to know and decide that it currently cannot. I have argued before that generative AI is best understood as the use case that creates all other use cases — a foundation that expands what is possible across functions. That remains true. But a foundation only creates possibility. Something still has to direct it at the decisions that determine whether the business performs. That direction is what is usually missing. ## Four different gaps behind the same AI problem Here is the practical consequence. When a consequential decision is poorly supported, most organizations reach for the same answer: we need better AI. But a weakly supported decision can fail for at least four fundamentally different reasons, and only one of them is fixed by building more capability. 1. **The Capability Gap –** The enterprise genuinely cannot produce the intelligence the decision requires. An executive need to know which assets are most likely to fail in the next 12 months, and the organization has no reliable condition data, no failure history, no model, no one who could build one. This is a real gap, and it needs real investment — data capture, models, skills, sometimes a new platform. 2. **The Design Gap –** The capability exists, but it was not designed around the question being decided. The organization can predict asset failure. The executive’s decision is not simply which assets may fail. It is where to allocate a fixed capital budget — which requires the consequence of failure, safety exposure, repair-versus-replace economics and scenarios at different budget levels. Failure probability is an input to that decision. On its own, it is not an answer, and handing the executive an input and calling it intelligence is how analytics teams lose their credibility. 3. **The Delivery Gap –** The right intelligence exists and is well designed, but it reaches the wrong person, at the wrong moment, or in the wrong form. A capex-risk analysis that arrives after the budget is closed is a record, not decision support. So is a complex dashboard when the executive actually needs a one-page recommendation before the investment meeting. 4. **The Connection Gap –** This in my experience it is one of the most common, the least visible and potentially the most consequential. The intelligence exists, it is well designed, it arrives in time — and consulting it remains optional. The model is available. The investment committee still runs on historical budgets and advocacy. Nothing in the formal governance of that decision requires anyone to look. Connection gaps are difficult precisely because nothing appears to be broken. Every component works. The data is sound, the model performs, the report is circulated. The failure is structural rather than technical: no one ever changed how the decision is made. And because there is no visible defect, the usual response is to improve the components — a better model, a richer dashboard, a wider rollout — which leaves the gap exactly where it was while consuming another budget cycle. Closing a connection gap is usually an operating-model issue rather than a technology one. The intelligence must become part of the formal decision process — what goes into the committee pack, what evidence must be considered, and where human accountability for the final decision sits. I use these four gaps as part of a broader framework I call Enterprise Intelligence Architecture (EIA). EIA starts with the decisions that materially determine enterprise performance and works backward to the intelligence those decisions require—then to the data, analytics, AI and governance needed to produce it. The objective is not to create another AI architecture. It is to connect what the enterprise can know to how the enterprise actually decides. EIA is the enterprise expression of a broader Institutional Intelligence Architecture (IIA), which treats AI as cognitive infrastructure for improving how institutions perceive, understand and decide. Why the diagnosis matters In many mature enterprises, the highest-return gaps are not capability gaps. The data largely exists. The models often exist. The analytics team is competent. What is missing is design, delivery and connection — Many of those gaps can be addressed without another major platform investment. The harder work is often redesigning the intelligence, its delivery or its place in the decision process. That can be good news. An organization may be able to improve how it decides using capabilities it has already paid for. It also changes the AI roadmap conversation — from what technology can be deployed to which decisions are consequential, recurring, information-constrained and improvable with what already exists. ## A practical starting point EIA does not need to begin as a large transformation programme. A useful starting point is one consequential, recurring decision where the organization may already know more than it currently uses. The question is whether the decision is constrained by missing capability, poorly designed intelligence, ineffective delivery, or a lack of connection to the formal decision process. Addressing that specific gap first allows the enterprise to improve decision quality using much of the capability it already has, and then extend the same approach progressively to other important decisions. ## The question worth asking Enterprise AI success should not be judged primarily by the number of pilots, copilots or models deployed. What matters is whether the organisation can repeatedly turn what it knows into better judgment at the decisions that matter. That starts with a diagnosis, not a purchase. The question is not, “Where should we deploy AI?” It is, “What should this enterprise be able to know and decide better than it does today — and which of the four gaps is standing in the way?” Answer that for one consequential decision, and the organisation may discover that the missing ingredient is not another AI tool. It is the connection between the intelligence it already has and the decisions that determine performance.

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. Gartner has predicted that by the end of 2026, 40% of enterprise applications will feature task-specific AI agents, up from less than 5% in 2025, and anticipates agent ecosystems spanning applications and business functions. 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 → Work → Authority → Execution → Evidence → Economics****** 1. **Outcome:** What measurable business result are we trying to produce? 2. **Work:** Which activities are necessary, which should disappear, and which require human judgment? 3. **Authority:** What may a person, application or agent recommend, prepare, approve or execute? 4. **Execution:** Which systems, APIs, data and workflows must participate? 5. **Evidence:** Can consequential actions be observed, reconstructed, challenged and recovered? 6. **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. Systems of record remain authoritative; intelligent orchestration increasingly becomes the engagement layer above them. Gartner similarly describes a progression toward agents operating across applications and business functions. ### 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. Gartner has estimated that $234 billion in enterprise application software spending is at risk from agentic AI as organizations reconsider how software capabilities are consumed and work is executed. 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.

The theft of FBI employee data by hacking group ShinyHunters, and the subsequent shutdown of the FBI’s Peoplesoft-based jobs portal, is causing concern for enterprise users of the Oracle product, with analysts recommending extreme measures in response. Law enforcement has made some progress in its pursuit of the cyber criminals involved, but there has still been no official word from either the FBI or Oracle about Peoplesoft’s alleged involvement. On Saturday, Reuters reported that a suspected member of ShinyHunters had been arrested in Jordan and has been cooperating with law enforcement to help identify other member of the group. The arrest comes a week after the arrest of another suspected ShinyHunters member by the Dutch National Police. In a video about that arrest, an FBI official warned gang members that arrests have a way of changing who is willing to talk, concluding, “You know how to find us, and we know how to find you.” Before the arrests, the gang told The Register it had discovered a new PeopleSoft zero-day hole and leveraged it to break into an FBI system, stealing information on all FBI employees. The FBI has since confirmed the breach without providing details. This wouldn’t be the first flaw ShinyHunters had found in PeopleSoft. It discovered a PeopleSoft zero-day hole in June that resulted in a flurry of extortion attempts, long after Oracle said it had patched the bugs. Oracle did not respond to a request for comment on the alleged new vulnerability. ## Significant risk exposure for enterprises Analysts and consultants played up the risk exposure from the potentially new vulnerability even as they sharply played down the implications of the arrest. Frank Dickson, principal analyst at Dickson Research, recommended that PeopleSoft users take immediate action. “If it is a new flaw, the patch is necessary but not sufficient. PeopleSoft customers should pull the Environment Management Hub and the Integration Broker off the public internet,” he said. “Doing so does not break normal user sessions.” He also encouraged users to quickly implement many of the recommendations from Google unit Mandiant’s report late last month on PeopleSoft security issues, especially “hunting for the web shells and outbound traffic Mandiant describes.” “For PeopleSoft shops, the to-do list is short,” Dickson said. “Apply Oracle’s patch. Disable or remove the Environment Management Hub if you do not use it. Search your logs for encoded variants of the PSEMHUB path, not just the literal string. If you find a web shell, treat the server as compromised and rotate every credential it could read.” This is a dangerous situation, he said: “An unpatched PeopleSoft flaw is a Sword of Damocles over every PeopleSoft shop But despite the extreme risk, even after the patch was released, rather than applying it, some organizations have opted for other mitigations. “Many organizations chose to block the vulnerable endpoint with web application firewall rules rather than patch,” Dickson said. “The attackers walked past those rules by changing a single character in the web address, writing ‘%50’ in place of the letter ‘P.’” ## Could signal a bigger problem However, IDC Research Director Philip Harris encouraged CISOs to view the FBI’s confirmation of its breach with caution, given the attack vector was not revealed. “ShinyHunters says it used a second, previously undocumented PeopleSoft preauth RCE zero-day, distinct from the CVE-2026-35273 flaw exploited in the earlier campaign,” he said. Yet, he pointed out, “no CVE has been assigned to it, it has not appeared on CISA’s Known Exploited Vulnerabilities catalog and Oracle has not commented on it. Every outlet covering this is explicit that the zero-day claim comes only from the threat actor, not from independent forensic confirmation or from Oracle. That distinction matters.” But if the hole is as the group has suggested, Harris said it signals a much bigger problem. “Assuming it is real, this would mean PeopleSoft has a second critical, unpatched preauth RCE in the same window as CVE-2026-35273, a pattern of recurring critical exposure rather than one isolated bug,” he said. “ShinyHunters’ own claim that they are already using it against other, unnamed Fortune 500 targets would mean every PeopleSoft customer is currently exposed to an unpatchable, undisclosed flaw with no vendor guidance to act on, a meaningfully worse position than the WAF-bypass story, since there is no mitigation to attempt while waiting on Oracle to confirm something it has not acknowledged.” Jeff Valdes, a director at consulting firm Acceligence, added that Oracle’s silence is unwarranted. “I think customers reasonably want more communication from the vendor,” he said. “They want to understand whether Oracle’s original guidance remains sufficient, whether there are additional mitigations customers should implement, whether Oracle is seeing anything through its own support organization that changes the risk picture, and whether there are configurations or architectural choices that materially increase exposure. Those are operational security questions that can be addressed without discussing attribution, arrests, investigative techniques or anything else that might interfere with an FBI investigation.” _This article originally appeared on CSOonline._

AWS is applying AI to the challenge of evaluating and improving cloud environments with a public preview of a new agentic service aimed at automating the discovery and optimization of architectural issues. Despite its name, AWS makes no claims for the architectural qualities of its Well-Architected Agent, the name of which refers to a long line of frameworks and tools for cloud architecture management dating back over a decade. AWS launched the first, the Well-Architected Framework, in 2015, later introducing the Well-Architected Tool in 2018 to help customers review their own workloads against the framework’s best practices. In contrast to the Tool’s reliance on enterprise teams to provide information about their workloads through a structured set of questions, the Agent analyzes the AWS environment itself and uses that information to generate recommendations, the company wrote in a blog post. Enterprises can also give the agent business objectives and application context to enable it to rank its findings against those goals, AWS said. The Agent surfaces recommendations at three levels: individual resources, applications, and overall architecture, suggesting remediation steps and identifying their potential cost impact. Those remediation steps can include environment-specific implementation guidance such as console walkthroughs, AWS CLI commands, and updated infrastructure-as-code changes, AWS said, while the existing Tool merely proposes an improvement plan. ## Optimizing cloud optimization For enterprise users, particularly cloud architects, DevOps teams, and platform engineers, the new agent can speed up optimization and change the way they manage cloud environments, moving from periodic architecture reviews and reactive remediation toward more continuous, AI-assisted optimization, said Siddharth Mehta, research leader at consulting and services company Avasant. That shift in how cloud environments are managed will become increasingly relevant as enterprises scale agentic applications, according to Nhat Bui, deputy director of engineering at Scopic Software. “First, AI applications change faster and have less predictable cost profiles than traditional workloads, so a review done last quarter goes stale quickly. Second, more infrastructure is now being written by AI coding tools, and human reviewers can’t keep pace with that volume,” Bui said. There are limits to the agent’s ability to offer timely recommendations, though: “The Agent refreshes resource-and application-level recommendations weekly, while architecture-level recommendations are generated through on-demand reviews,” Bui said. That distinction could be particularly important for fast-changing workloads, including agentic applications, where infrastructure and resource usage can change between recommendation refreshes, he added. That said, the new agent could help accelerate the pace of cloud-related decision-making, said Pareekh Jain, principal analyst at Pareekh Consulting. “Instead of giving CIOs hundreds of technical recommendations, the agent can help identify which improvements matter most to the business. That means CIOs can decide where to prioritize cloud investments and engineering resources, and where to accept trade-offs,” he said. ## Limitations of the new Agent However, the Well-Architected Agent has its own set of limitations, said Mehta. “The Agent only understands the context available to it. It may not know about regulatory obligations, third-party dependencies, business-process dependencies, contractual SLAs, internal risk appetite, multi-cloud dependencies, and organizational policies not represented in AWS,” he said. “Therefore, business-goal alignment improves prioritization but does not replace enterprise architecture or risk governance.” For Jain, however, the bigger limitation is the Agent’s requirement for a high-tier AWS Support plan, which could limit its adoption among enterprises that do not already subscribe to those plans. The Agent is available only to customers on AWS Business+, Enterprise On-Ramp, Enterprise Support, or Unified Operations plans, unlike the Well-Architected Tool, which does not require a paid Support plan, he said. Moreover, Mehta said, the Agent is narrower in scope, currently covering cost, security, performance, and resilience, while the Well-Architected Tool continues to support all six pillars of the Well-Architected framework, including operational excellence and sustainability. There is no specific additional fee for the Agent or the Tool, although enterprises are charged for some of the underlying AWS resources, services, and data that they consume, including those from Trusted Advisor, Compute Optimizer, Security Hub CSPM, Resilience Hub, Cost Optimization Hub, and Cost Explorer.

At Oktane a couple of weeks ago, Okta and a group of enterprise heavyweights, including AWS, CrowdStrike, Databricks, Google Cloud, Salesforce, ServiceNow, Wiz and Zscaler, launched the Blueprint Alliance. Their goal is a shared plan for securing and governing AI agents across the enterprise. The biggest names in tech are forming bigger alliances, signing bigger deals and making bigger promises. Everybody wants to rule the world. Bigger doesn’t always mean better for the people writing the checks. More than half of CEOs told PwC this year that AI had delivered neither higher revenue nor lower costs over the prior 12 months. Only one in eight saw both. You will work with alliances like this one. The real question is whether you’ll still hold the keys when you do. ## What the Blueprint gets right Credit where it’s due. The Blueprint Alliance is a multi-vendor coalition that co-authored an open reference architecture for governing AI agents at enterprise scale. It’s built around four practical questions: Where are my agents? What can they do? What are they doing? How do I respond? Those are the right questions, and the timing is right. Okta cites a Gartner prediction that the average global Fortune 500 company will run more than 150,000 agents by 2028, up from fewer than 15 in 2025. No single product will govern that. Ganesh Kirti, founder and CTO of TrustLogix, wrote in a LinkedIn post that the blueprint “treats agent security as an enterprise architecture problem, not a single-product problem.” He also landed on a principle every CIO should tape to the wall: “agents need identities, but identity alone does not make an action trustworthy.” At their best, industry alliances do good. They create shared language, speed up interoperability and give buyers a baseline to hold vendors to. Coalitions gave us SAML, OAuth and FIDO. Those made my job easier for two decades. Notice what’s missing, though. None of the four questions asks what an agent is worth. That one stays with you. So, I’m a fan. I have also been in the Buyer’s seat. Buyers read the fine print. ## The one-way door Jeff Bezos famously split decisions into two types. Two-way doors you can walk back through. One-way doors you can’t. Alliances often look like the first and behave like the second. Here’s why. When the companies that already run your cloud, identity, endpoints and data agree on how AI should be governed, the easiest path is to govern AI with the tools you already own. That’s convenient. It’s also how a governance decision quietly becomes a procurement decision. Incumbents don’t need to win a new category. They need the status quo to hold. Their established product lines fund the roadmap, and new AI capabilities get folded into renewals you were going to sign anyway. An alliance makes that path feel safe, because everyone you already trust is standing on it. That’s how successful businesses behave. Your job is to notice when their interests and yours start to drift. Watch for these signs that the door is closing behind you: * AI governance arrives as a “free” add-on to a renewal, with pricing that changes in year two. * The architecture assumes one vendor’s control plane for identity, policy and logging. * Your agent activity data lives in a format only one platform can read. * Exit costs, data portability and migration support are missing from the contract. * ROI slides count seats and adoption instead of business outcomes. ## I’ve walked through this door before I spent 2007 to 2015 at VMware as an Oracle consultant, and then as the head of IAM. We deployed Oracle’s identity and middleware stack to get the company through its IPO. It was the right call, and it did exactly what was needed at the time. Then the costs and complexity grew. New environments took weeks to build. Every change needed engineering and admin time. That eventually led to an informal effort that we called Get Off Oracle, or GOO. The surprise was where GOO led. To regain control, we virtualized the entire Oracle stack, including Fusion Middleware and Oracle RAC, using VMware software and automation we built ourselves. Build and delivery times dropped from weeks to hours. That speed helped fuel VMware’s explosive growth and accelerated time to market. Even Okta came by to study how we did it. The lesson stuck with me. Our leverage came from owning the architecture. Once we controlled how the stack was built, deployed and moved, we negotiated from strength. The vendor stayed. The dependence didn’t. ## Price is not risk Every time an AI system acts on data you can’t fully trace, bound or prove, you take on Verification Debt. It compounds quietly and comes due at the worst moment: a release, an audit, a regulator’s letter. That’s why the sticker price misleads. A $100,000 AI project with a clear economic mechanism can carry less risk than a $20,000 project nobody can explain. The price tells you what you’ll spend. It tells you nothing about what the system can reach, what it can decide or what it would cost to unwind. Two companies show the difference. Klarna rolled out an AI assistant for customer service and cut its cost per transaction from $0.32 to $0.19 over two years. But cost became the main scorecard. Its CEO later admitted that the focus on cost produced lower quality, and Klarna started hiring human agents again. He now describes human support as something close to a VIP service. The savings were real. The scorecard was lopsided. Morgan Stanley took a slower path. The firm built an evaluation framework to test every AI use case before deployment. Today more than 98% of its advisor teams use its AI assistant. Both companies worked with the same AI partner. Different discipline produced different results. PwC found the same pattern at scale: CEOs with strong AI foundations were three times more likely to report meaningful financial returns. ## A strategy for sovereignty Here’s the economics most renewal decks leave out. Year one is the honeymoon. Pricing is generous, services are bundled and the executive sponsor is thrilled. By year two or three, costs rise, complexity grows and switching gets harder. Value stays flat while leverage moves to the vendor. Sovereignty is how you keep that leverage. It means you can join any alliance and still walk away from any vendor. Five moves get you there: * **Own your data layer.** Keep governance metadata, lineage and agent activity logs in formats you control. * **Build your own AI harness.** Put models, agents and identity providers behind a layer you control. * **Price year three before you sign year one.** Cap increases, define exit rights and require data portability in writing. * **Measure value in business terms.** Tie every AI commitment to revenue, cost, risk or customer outcomes, with a named owner. * **Keep the program in house.** Vendors advise. Your leaders decide. The harness is where sovereignty gets real. An AI harness is the layer you own between your people, your data and whatever models or agents you run. It carries the context, policies, evaluations and logs, so any model can plug in, and any model can be swapped out. Pair it with an intelligence layer: a governed view of what your enterprise knows, drawn from every system instead of trapped inside one. Together, they change the economics. Data silos stop dictating what AI can see. Per-seat SaaS pricing loses its grip, because the value lives in a layer you own. And every vendor becomes a position in a portfolio you can rebalance. That’s leverage at the negotiating table and at renewal time. It’s the GOO lesson all over again. Own how the stack is built, and every vendor has to keep earning its place. The Blueprint Alliance will produce real success stories. It will produce regrets too. Just don’t let them be yours. The organizations that come out ahead will have active leadership, clear governance and the discipline to keep every vendor honest and accountable, including their favorites. Everybody wants to rule the world. Build your own harness, and you decide who rules yours.

The latest warnings about artificial intelligence are difficult to brush aside. Anthropic researcher Jacob Coxon resigned last month, walking away shortly before his equity was due to vest, and publicly argued that leading AI companies are advancing toward increasingly capable systems without adequate assurance that those systems will remain controllable. His resignation landed amid a broader argument over the probability that advanced AI could eventually cause catastrophic or even existential harm. Axios on Coxon’s resignation and warning It is easy to see why the conversation gets pulled toward extinction. “Could AI kill humanity?” is a much more arresting question than “Are our escalation procedures fast enough?” But for CIOs, CISOs and other leaders responsible for systems that actually have to work, the second question may be more useful. AI does not have to become superintelligent, conscious, hostile or impossible to shut down for governance to fail. Governance can fail much earlier, when a system is given enough capability, access, autonomy or delegated authority that the organization can no longer intervene reliably before consequences arrive. That is not primarily a science-fiction problem. It is an operating-model problem with an engineering component. ## The evidence is concerning without being apocalyptic The extinction discussion deserves some discipline. The 2026 _International AI Safety Report_ does not say that current AI systems are capable of seizing control from humans. It says current systems lack the capabilities necessary for a genuine loss-of-control scenario, while also documenting continued progress in capabilities relevant to such scenarios. Researchers remain deeply divided over how likely future loss of control is. 2026 International AI Safety Report That is a far more useful conclusion than either “we are doomed” or “there is nothing to worry about.” Current systems are not the hypothetical superintelligence at the center of the extinction debate, yet systems are becoming more autonomous, more capable of carrying out extended tasks and better able to operate within complex technical environments. The practical warning, then, is not that an AI system is secretly plotting our destruction. It is that the relationship between capability and control is becoming more consequential, and organizations may be granting systems meaningful operational reach before they have equally mature ways to contain that reach. Anthropic’s cybersecurity evaluations offer a useful example. In July, the company reported incidents in which Claude models reached the live internet from evaluation environments and gained unauthorized access to real systems. In one case, the model accessed a database containing several hundred rows of production data. In another, a model published a malicious Python package to PyPI; the package was available for roughly an hour and was downloaded and executed on 15 real systems before it was removed. Anthropic cautioned that these were isolated evaluation incidents rather than controlled experimental evidence, and that the models had been assigned offensive cybersecurity tasks. Anthropic’s cybersecurity incident analysis Those qualifications matter. These systems were not independently deciding to attack organizations for their own purposes, and the incidents should not be repackaged as evidence of an AI “escaping.” But dismissing them because they occurred during evaluations would miss the operational lesson. Capability, access, environmental configuration and assigned objectives combined in ways that produced unintended real-world consequences. Several assumptions that were supposed to hold across the environment did not hold. That looks much less like science fiction than like a familiar systems failure. ## The timing problem in AI governance Most governance programs still operate at human speed. A system is approved, ownership is assigned, risks are documented, controls are established and someone monitors performance. When an issue appears, it is investigated and escalated. The appropriate authority makes a decision, and someone implements it. There is nothing inherently wrong with that sequence. The problem is the clock. AI agents increasingly challenge that timing model. Systems can operate computer interfaces, collaborate with people and other systems, and carry out increasingly extended work. OpenAI Chief Scientist Jakub Pachocki has described current reasoning systems as already capable of operating computers and graphical interfaces, collaborating with humans and other systems and carrying out research projects, while warning that alignment and monitoring remain significant concerns as capabilities advance. Jakub Pachocki, “An Alien Mind” The organization surrounding those systems may still operate very differently. An alert is generated. Someone opens a ticket. The ticket is triaged. The issue moves through an escalation chain. People exchange messages, schedule a discussion, obtain approval and eventually make a technical change. The mismatch is not merely procedural; it is temporal. I think of that gap as governance latency: The time between recognizing that governance needs to act and making that decision real in the system. Governance is effective only when it can become operational before the consequence it is intended to prevent or contain. For leaders, that changes the conversation. The question is no longer simply whether an AI system has an owner. Can that owner actually revoke the system’s authority, and how quickly? Can the organization determine which systems the agent has touched before it touches another one? If a model begins behaving outside approved operating conditions, does human approval become an actual execution gate, or does the requirement exist only in policy? Can investigators later reconstruct what the system knew, which tools it used, which data informed it and which human interventions affected the outcome? If governance decides at 10:02 that an action is no longer permitted, what time does the system become technically incapable of performing it? A five-minute answer and a five-day answer may describe the same policy, but they do not describe the same governance capability. ## Accountability without authority is a paper control AI governance conversations often settle comfortably on ownership. Assign a model owner, identify a business owner, name the risk owner, document the system owner and now someone is accountable. That is necessary, but it is not control. A person can be accountable for an AI system and still lack the technical authority to constrain it. A governance committee can prohibit an activity while the production architecture continues to permit it. A risk register can correctly identify an unacceptable condition while doing nothing to prevent that condition from becoming operational reality. This is the point where governance stops being primarily a policy exercise and starts becoming an engineering requirement. NIST’s AI Risk Management Framework already provides some of the scaffolding for that view. Its Core describes governance as a cross-cutting function and states that risk management should be continuous, timely and performed throughout the AI lifecycle. NIST AI RMF Core The unresolved question is what happens between a governance decision and an operational state. A policy that says an agent may not access a particular class of data eventually has to become a permission boundary. A requirement for human approval has to become an actual execution gate. An obligation to maintain traceability has to become logs and provenance that remain available long enough to investigate. An escalation rule has to connect to someone who has both the authority and the technical means to stop what is happening. Rollback, credential revocation, execution limits, authentication requirements, network boundaries, provenance, shutdown mechanisms and decision logging may sound like engineering details, but they are also what governance looks like when it reaches production. Without that translation, an organization can have a sophisticated AI governance program while remaining surprisingly unable to govern the AI system at the moment governance matters most. ## We are using the wrong threshold for concern The research community should continue studying existential risk. It would be reckless to dismiss a low-certainty risk simply because its consequences are difficult to quantify, particularly when the potential loss is enormous. But executives do not need to know the probability of human extinction before deciding whether their own AI systems are controllable. Imagine autonomous or semi-autonomous AI operating in cybersecurity, financial services, healthcare, logistics, critical infrastructure, intelligence or defense. None of those systems needs consciousness, hostility toward humans, a survival instinct or a secret agenda. A system needs only enough capability, access and authority to produce consequences faster than the organization surrounding it can understand what is happening and make an effective intervention. That organization may still have an AI governance council. It may have risk registers, policies, responsible executives, model cards, review boards and named owners. On paper, the system is governed. Operationally, the more important question is whether the governance can still reach the system in time. That is what the extinction debate risks obscuring. The immediate challenge is not proving that AI will someday become uncontrollable. It is determining whether we are already building systems whose operational reach is beginning to exceed the operational reach of the governance surrounding them. If that gap keeps widening, we will not need an extinction event to learn that our governance model failed. An ordinary incident will be enough.

Sumit Johar has been modernizing BlackLine’s IT environment since becoming CIO of the software company in early 2024. As a longtime IT leader, Johar has plenty of experience overhauling tech stacks, but he says the work has taken on new meaning — and urgency — in the AI era. “The definition of modernization has literally switched in the last two to three years,” he says. “Suddenly everything that you built in the last few years looks like legacy, because the SaaS model, which we have been using for the last 10 to 15 years, there is an opportunity now to totally change that and modernize with AI and for AI.” Johar is doing just that, surveying the company’s SaaS portfolio, particularly zeroing in on point solutions, asking whether each is worth the cost, whether it delivers true business value, or whether IT can use AI to build a service better suited to his company’s needs. At the same time, AI is changing how workers interact with technology, he says, enabling people to query applications via natural language and chat, which has his IT team considering which applications may need to be modernized or abandoned altogether as a result. Take, for example, dashboards. “We built dashboards because there was no other or better way to report on your data,” he says. “Now I can simply ask a question and get an answer, which is what I was interested in anyways. So if I have my ERP and CRM talk to me in a human language, I’m happy with that. That’s modernization.” As a result, he adds, “some of us might be getting rid of [our dashboards], and some might be slowly reducing the dashboarding tools we have.” As organizations remake and automate workflows with AI, software that enables those workflows could meet a similar fate, Johar says. Even chatbot-building products that IT implemented a few years ago are prime targets for rationalization due to AI advances, he adds. “I still need chatbots, but I don’t think I need specialized software to build a chatbot anymore. Any generic AI platform that I have will give me the ability to basically build them,” he explains. ## High-priority tasks For Johar, the longstanding CIO tasks of modernization and rationalization remain make-or-break activities for IT. Johar and other IT leaders see modernization and rationalization as vital to controlling IT spend — as high of a priority for CIOs as it’s ever been, freeing up dollars for innovation (the No. 1 objective for nearly every IT leader and their CEO’s top priority). IT leaders also see modernization helping them create a future-ready IT environment, one that’s not encumbered by legacy technologies and complexities that don’t play nice with emerging technologies. “CIOs don’t have much of a choice than to continue modernization; they’re in a perpetual state of modernization,” says Amar Aswatha, senior vice president for global business engineering at CGI, a consulting and services firm. “They’re trying to simplify yesterday’s tech state while creating resilience and the right environment for AI and to be ready for whatever will emerge.” Other factors also drive the need for ongoing modernization, Aswatha notes. The rapid pace of innovation is reducing the shelf life of many technologies more quickly, necessitating more rapid overhaul cycles than in the past. Meanwhile, the past decade’s mass migration to the cloud has meant that CIOs “traded server sprawl for subscription sprawl,” he says. The rush to adopt AI is having a similar effect, leading to AI and agent sprawl — and the need for new and more widespread rationalization and modernization strategies. Still, CIOs must be more surgical than they’ve been in the past, using a scalpel not an ax to shed legacy technology and simplify IT environments, Aswatha advises. That means accounting for both current and emerging business needs when determining what systems should be modernized — not simply relying on age or other such non-business-related factors. And IT leaders can’t see rationalization as an exercise in reducing application count to a set number; unnecessary complexity should instead be the target. Such approaches require CIOs and their teams to understand current and future business needs, as well as how those needs, and the organization’s overarching strategy, shift over time, Aswatha says. “CIOs have to watch for business signals on when and what to modernize and rationalize. It’s not about spring cleaning, it’s about what apps are slowing the business down,” he advises. ## ‘Best for the organization’ Rachelle Putnam, vice president and CIO of General Dynamics Land Systems, which manufactures military vehicles, is taking such an approach. Putnam, who has led IT at the company since 2014 and managed a move off a mainframe about a decade ago, says modernization today means asking whether existing technology “allows us to have the flexibility and the functionality we need.” Like many CIOs not on IT’s bleeding edge, for Putnam savvy modernization is about strategy, not technology. “Some might say we’re not on a modern tool set, but that doesn’t mean we don’t have the functionality we need,” she says. For example, Putnam embraces a cloud-smart strategy, modernizing on the cloud where it makes sense and on-prem when that’s the better or required option based on government regulations. She applies a similar lens to rationalization, asking whether any given application uniquely fulfills a business need or whether other apps in the portfolio can do the job. Such questioning helped her standardize the company on two CAD tools, down from 10, and standardize on one reporting tool instead of using three. Putnam is also increasingly asking whether she even needs a vendor solution. “With tools like Claude Code, when we look at [vendor-offered] apps, we ask if we even need them or whether we can create our own and not pay for maintenance,” she says. “Sometimes we want SaaS, where we want those updates, but there are others that we don’t need updates and won’t need to change the application much, so those are the ones we’re going to look at creating ourselves.” Like other CIOs, Putnam believes modernization produces benefits for IT and the company as a whole, ensuring the organization not only has the technology necessary to perform but also a standardized data environment so that “everyone is looking at the same data, and it means the same thing,” she says. In addition to cutting IT maintenance and management costs, modernization also reduces risks, by eliminating unsupported legacy tech and difficult-to-manage complexity. And it makes IT talent more effective and efficient, by eliminating the need for outdated skills, which are typically hard to find and thus come at a premium. With rationalization, IT teams no longer must learn multiple vendor solutions or assign different workers to different solutions. ## Modernization challenges Of course, Putnam and other IT leaders acknowledge there are challenges to modernization and rationalization, too. “Cost is certainly one. Sometimes it costs more to get off one than continuing to run multiples,” Putnam says. Even in such cases, however, hard-to-quantify benefits make the move worth it, she adds. For example, rationalizing to one common system used throughout the company’s multiple geographic locations means workers anywhere can easily be assigned to help when one region faces a surge in work. Data migration is another common challenge. But data issues can usually be overcome with “creativity, mostly, and having someone dig down to really get it done,” Putnam says. Sometimes it may mean shelving the data and only retrieving it if necessary. Then there’s the challenge of limiting future rationalization by controlling what gets added to the IT environment today. To that end, deploying and using a common tool is the default standard now at General Dynamics Land Systems. “That’s a rule that everyone abides by,” Putnam says, acknowledging some pushback. “Sometimes people will argue for that extra 15% that one tool might have that the existing tool doesn’t have. But we stress that standardization is best for the organization as a whole.” ## A staple of CIO work Krishna Prasad, CIO of UST, a digital transformation and IT services provider, similarly sees modernization through a business — not a technology — lens today. Whereas modernization was once triggered by advancements that made existing tech outdated, obsolete, or no longer supported by the vendor, now modernization is triggered when business advancements render a deployed technology deficient, he says. This new scenario has CIOs, including himself, modernizing faster than in past eras, Prasad says. And it’s why modernization remains a core component of the CIO role. “Modernization means meeting today’s business needs, and that may mean we need to deploy a new version of [a technology] to get a better experience, speed, agility, or in a way that we can provide transparency,” he adds. “So, at UST we have always thought about modernization as a continuous process.” For example, Prasad is currently modernizing the company’s CRM platform, even though the existing one would not be considered legacy tech using a traditional definition. Yet the deployed CRM wasn’t providing the capabilities UST needed for its sales department to deliver on the company’s vision. “We weren’t having a good user experience, and sellers weren’t updating the information as they should, so we didn’t have real-time data and then the operations team had to do the data entry, so you had cost there, too, and we had reduced agility as a result,” Prasad explains. Similar factors are at play when it comes to rationalization, which he believes should also be an ongoing concern for CIOs. Despite the benefits these efforts bring, Prasad acknowledges the heavy lifts involved, ones that many organizations aren’t yet prepared to undertake. For example, UST still has a financial system running on premises, and because the complexity of “disentangling the financial systems from the guts of the business is challenging, it’s a change that the business isn’t willing to make right now,” he admits. Such situations ensure modernization projects will remain a core IT task in the years ahead. **See also:** * 6 strategies for accelerating IT modernization * 8 IT modernization traps CIOs must avoid * Massive modernization: Tips for overhauling IT at scale

Most CIOs can easily describe their AI initiatives, but struggle to demonstrate and report on AI value and ROI. This is evidenced by Gartner’s AI ROI Vendor Sentiment survey, which found that 27% of respondents strongly agree that ROI from AI initiatives is difficult to quantify. In addition, only one in four had a clear process to evaluate success of AI initiatives. In the digital transformation era, compute costs were relatively cheap, and the focus was less on FinOps and more on user experience, and the classic software attributes of availability, reliability, scalability, performance, and security. AI-native and AI-enabled applications still bring these considerations, along with a host of new ones, such as accuracy, validity, explainability, safety, and all the other trust attributes like those in the NIST AI RMF. But as AI scales, it’s quicky becoming a FinOps exercise, too. I’ve discussed techniques CIOs can apply to improve AI value and ROI such as architectural decisions related to controlling efficiency at the data layer, fine-tuning the application layer, and closing the gap between AI strategy and governance. Here, we’ll look at three best practices for CIOs looking to formalize their process to evaluate the effectiveness of their AI initiatives through approaches, frameworks, and techniques that support measurement and ROI reporting across the entire AI portfolio. ## 1. Take a portfolio approach in line with AI ambition The first step to AI value is to take a portfolio approach and look across your entire AI estate and how it supports your AI strategy and broader organizational strategy. This means thinking about your AI innovation ambition and how you’d like to move the needle year-over-year by adjusting your percentage of spend across quick wins versus must haves, internal (employee-facing) versus external (customer-facing) applications, near-term versus long-term initiatives, and cost savings and productivity versus revenue generation. This AI innovation ambition approach is a best practice in innovation management as organizations work to gain quick wins early on to prove value, and then get more ambitious in subsequent years and allocate a larger percentage of their spend on more strategic, longer-term, and externally focused initiatives for revenue generation. For example, an early maturity organization might focus 80% of its AI investment on internal-facing initiatives and 20% on external-facing ones in the first year. Then, it moves to a 70/30 split in year two, and so on. While many organizations may not track these spend allocations, it’s a valuable discipline and one which often differentiates AI leaders from the rest of the pack. In PwC’s 2026 AI Performance Study, the top 20% of companies capture 74% of all AI-driven economic value, delivering a 7.2 performance multiplier over peers. Deploying focused pilots alongside quick wins is a great way to capture early insights into AI value and ROI before scaling applications. According to Joe Vaccaro, SVP and GM of Network Platform and Assurance at Cisco, networks have become distributed, continuously changing systems that produce far more signal than any human-led operating model was designed to interpret. “Our survey of 1,000 IT and NetOps leaders found more than half believe a failure to automate will open critical security gaps and elevate enterprise risk,” he says. “For CIOs seeking to demonstrate ROI from AI investments, a credible path is to start with targeted, measurable, and reversible workflows. Focused pilots can validate outcomes and strengthen governance before broader deployment.” At this level where organizations look at their holistic AI spend, it’s also important to have a well-crafted set of AI value metrics, which can be used to assess the current health and productivity of the portfolio. Borrowing from best practices in innovation management, AI value metrics, such as those that look at input and mix, health and efficiency, and outcomes, help to look across the entire innovation pipeline, from idea to value. * **AI innovation input and mix** — What’s going into your pipeline in terms of the types of innovations in the queue. * **AI innovation health and efficiency** — The flowrate through your pipeline and the amount of funding being applied. * **AI innovation outcomes** — The measure of return on innovation in terms of commercialized innovations that have captured revenue or other objectives. ## 2. Develop an assessment framework focused on full cost benefit While many organizations are laser-focused on the cost side of their AI initiatives, your assessment framework needs to incorporate a full cost benefit analysis. “While the current focus for many organizations is squarely on AI tokenomics, it’s important to look at both sides of the coin when it comes to AI value, and look at the business value that’s being delivered by each initiative to give a clear picture of actual return,” says David Evans, AI and growth strategist at thought leader networking platform Thinkers360. Ben Schein, VP of AI and analytics at AI infrastructure software company Progress Software, adds that CIOs should stop measuring AI activity and start measuring outcomes where possible. “Usage tells you the meter is spinning, not that value came out,” he says. “Instrument the cost side completely, since every AI action can carry its workload, model, and cost. Then pair costs with benefits where the work allows, so cost per workflow run against value per workflow run, never enterprise-wide spend against anecdotal wins.” However, Dan Priest, PwC US CAIO, recommends getting back to basics, starting with the investment side but adding a few modern updates _._ “AI ROI has been illusive for many, in part because organizations are still learning how to achieve it, and because AI sometimes gets a pass on the typical disciplines required to measure it,” he says. “For major AI initiatives, starting with investment might include new infrastructure, labor for the build, models for the intelligence layer, and variable expenses like token costs. All of these should be contemplated in ROI calculation, some of which will require new tracking and controls.” His benchmarking also points to a threshold effect: ROI stays insignificant until AI investment crosses roughly 1.6% of revenue, and above that line, EBITDA is up 9.5%, revenue is up 3.5%, and total shareholder return is up 20.2%. ## 3. Include benefits and measure what matters Another best practice from innovation management is to look at both the quantitative and qualitative benefits of AI initiatives, not solely the direct financials. “It sounds obvious, but CIOs should measure the business value created like productivity, growth, and other outcomes rather than activity completed, such as building an app, creating a dashboard, or collecting customer feedback,” says Priest. “We recommend looking across five dimensions of value: financial, operating, functional, trust, and workforce. That gives leaders a more consistent way to measure and compare value across an AI portfolio, even when individual investments are designed to produce different outcomes.” Calculating projected as well as actual ROI can also give CIOs insight into how their AI portfolio is living up to expectations. This is where it’s important to factor in governance costs early in the lifecycle before initiatives get funded, particularly for high-risk applications where downstream governance requirements are high. “Ultimately, measure what matters, keep an eye on variable costs, and monitor actuals against expected costs and benefits,” adds Priest. “That gives CIOs the information they need to determine where investments are delivering, where changes are required, and where to lead, lag, or exit.” Quantifying AI value and ROI doesn’t require a completely new methodology or new approach. It simply takes the same financial rigor applied to many other previous investments. The variable cost dynamics may be more complex, but these are solvable if you align with your AI innovation ambition, apply your assessment frameworks consistently, define your AI value metrics, and measure what matters.

For a few years now, the headlines have become familiar: yet another company laying off workers as a result of AI. But in recent months, we’ve seen a new twist. Some of those same companies are now reconsidering staffing decisions after recognizing the continued need for experienced professionals. Ford offers a telling example. In 2023, the company leaned heavily into AI-driven quality control, relying on more than 900 AI-assisted cameras to identify defects at scale. Leaders believed the technology, combined with revised design requirements, would be enough to maintain product quality. It wasn’t. As defects and quality challenges persisted, Ford concluded it had overcorrected in its push toward automation and technology-led processes. The company ultimately rehired 350 veteran engineers, often referred to as “gray beards,” over a three-year period, recognizing that experience, judgment and deep institutional knowledge remained essential. The company was careful to say this wasn’t a total about-face. According to Ford, it wasn’t a decision to replace AI but to retrain it, catch failure points early and mentor younger staff. As Poon put it, “AI is a powerful tool for catching potential quality issues, but it’s only as good as the people using it.” And Ford’s results suggest that this approach is working. CEO Jim Farley credited the move with generating “hundreds and hundreds of millions of dollars” in warranty and recall savings. Ford also topped the mainstream automotive brand rankings in J.D. Power’s 2026 Initial Quality Study, its strongest performance in 16 years. Rather than viewing this as a failure, I see it as an example of organizational courage. In a moment when many leaders are racing to adopt AI, it takes confidence to experiment, evaluate the results honestly and course-correct when the outcomes don’t meet expectations. In my view, this is a more complex and cautionary tale about what separates AI adoption from AI success at a time when we are all trying to figure it out. AI can accelerate analysis, surface patterns and scale knowledge. But judgment remains the capability that turns those inputs into decisions, action and business value. That’s good news for us humans. As AI becomes more capable, our judgment and critical thinking skills become more important, not less. ## AI is a force multiplier, not a replacement for expertise There was an important realization at the center of Ford’s decision: their AI-driven computer vision systems could identify potential anomalies at scale, but experienced engineers were still needed to determine which signals mattered, what risks they represented and what actions should follow. Research suggests this dynamic extends well beyond the automotive industry. In a recent study by Harvard Business School and UC Berkeley, a field experiment of more than 600 entrepreneurs, AI access widened the gap between high and low performers. Researchers found that the difference stemmed from how participants selected and implemented the AI advice they received. In the same vein, last year, MIT found that AI models use more confident language precisely when they are hallucinating — a worrying behavior that reinforces why human verification and discernment are non-negotiable. This isn’t just an academic conclusion, nor is it unique to Ford. Other major employers, including Google, Booz Allen Hamilton and CSX, have recently increased hiring in key areas as companies gain a clearer understanding of AI’s capabilities and limitations. Executives now say they still need experienced professionals to deploy, oversee and complement AI, particularly in complex functions like engineering, cybersecurity and cloud computing. In the project management field, I see this, too. Teams that treat AI outputs as inputs to a judgment process outperform those that treat AI outputs as answers. The organizations winning with AI are pairing it with, not substituting it for, seasoned expertise. ## The rising value of complex problem solving and discernment When everyone has access to the same tools, differentiation comes from human judgment and critical evaluation. A recent roundtable hosted by Accenture and iResearch came to the same conclusion, positing that 15% of content is now AI slop. In fact, people who can position themselves as so-called “AI orchestrators”, combining AI fluency with deep domain expertise, are earning more, while the value of low-level, unedited AI output is declining. This underscores why these professionals are more valuable than ever to their organizations. The Ford example reinforces this. The engineers who were rehired weren’t brought back to do manual labor that AI could replace; they were rehired for their domain expertise and judgment built over decades that AI hasn’t replicated. For CIOs, this new dynamic is likely to change how you evaluate talent and design roles and teams. Judgment and critical thinking should be explicitly assessed and cultivated, not assumed. ## What this means for how CIOs build teams and lead There’s also a practical shift happening, and a broader lesson we can learn from Ford: AI success is rarely determined by the model alone. It depends on the goals, governance, expertise, talent and decision-making systems surrounding it. As the PMI Standard for Artificial Intelligence in Portfolio, Program and Project Management demonstrates, there is a growing realization among leading organizations: the most successful AI systems combine AI capabilities with structured human judgment, governance and accountability. In practice, leaders can take actionable steps to build structured checkpoints at which experienced staff review and validate AI outputs, especially in high-stakes workflows, such as those reflected in PMI Certified Professional in Managing AI’s (PMI-CPMAI) phased governance approach. From a culture and team-building perspective, Ford’s veteran engineers also played a critical, irreplaceable role. They were training and coaching the next generation. That’s another reason why CIOs should treat experienced talent as a retention and knowledge transfer priority, not a cost center to shrink. This is an investment in the future health of your organization. ## Avoiding the overcorrection The answer isn’t to replace human-driven workflows with AI, nor to reject AI altogether. The right path lies somewhere in the middle. Rejecting AI entirely out of fear is unwise when the technology can unlock so much business potential both now and in the future. The sweet spot is augmented intelligence: knowing where AI adds speed and scale, and where human judgment must have the final say. Bring AI into the workflow as a collaborator because your competitors certainly will. Then make human judgment the differentiator. ## Judgment is the skill that scales My call to action, plain and simple: judgment is not optional. AI didn’t fail Ford, necessarily, but the company’s transformation struggled because judgement wasn’t sufficiently integrated at scale. As AI adoption accelerates, CIOs should treat project management skills, judgment, critical thinking and decision-making as core competencies to hire for, train for and protect. These are the capabilities that will determine whether AI delivers business value at scale. The organizations that win with AI won’t be the ones with the most AI tools, or those that hastily cut the most jobs. They will be the ones that best integrate AI into decision-making and business outcomes and know exactly where to keep humans in the loop.

I have spent more than 30 years in enterprise IT and managed services. For most of that time, small businesses adopted new technology on a predictable lag. Large enterprises moved first because they had the budget, staff and risk tolerance to experiment. Everyone else waited for the tools to mature and prices to fall. That pattern held during the first wave of workplace AI. The conversation among IT leaders centered on enterprise platforms, large service operations and multi-quarter programs connected to systems such as Workday. ServiceNow’s acquisition of Moveworks reinforced the enterprise direction of travel. Small businesses were mostly spectators. They are not spectators anymore. Over the past six months, the requests coming into my practice have changed from, “Should we look at AI?” to, “Our employees already opened ChatGPT or Claude, and now we need help doing this properly.” That is not a product-selection question. It is an operating-model question. ## The adoption line has moved down-market The data now reflects what I am seeing with clients. Bluevine’s 2026 Small Business AI Trends Report found that 74% of small business owners are using or actively testing AI. In the owner survey, ChatGPT was used by 57%, Gemini by 56%, Copilot by 30% and Claude by 12%. But Bluevine’s customer transaction data tells a second part of the story: the number of Claude users grew 729% year over year and, by April 2026, Claude had surpassed ChatGPT in total monthly transactions among Bluevine customers. Claude therefore has a smaller reported user share in this survey, but exceptionally strong growth and engagement momentum. _Figure 1. Reported AI tool usage among surveyed small business owners. Claude represented 12% of users, while Bluevine customer data showed 729% year-over-year user growth and more monthly transactions than ChatGPT by April 2026. Source: Bluevine 2026 Small Business AI Trends Report._ Shree Amujala A separate Business.com study found that 57% of U.S. small businesses were investing in AI, up from 36% in 2023, while only 30% of employees used it daily. Adoption also varied sharply by company size. The important signal is not a single headline percentage. It is the gap between buying access and changing how work gets done. AI vendors see the same shift. As TechCrunch reported, Anthropic launched a small-business offering built around Claude Cowork and integrations with tools such as QuickBooks, DocuSign and HubSpot. The company pointed to a familiar market reality: small businesses account for 44% of U.S. GDP and employ nearly half of the private-sector workforce, yet tools and training have rarely been designed around how these businesses operate. A different measurement shows why user share should not be confused with workload share. A 2025 Menlo Ventures survey of more than 150 technical leaders estimated that Anthropic held 32% of enterprise LLM usage, ahead of OpenAI at 25% and Google at 20%. In coding workloads, Anthropic’s share was 42% compared with OpenAI’s 21%. Menlo Ventures is an Anthropic investor, but the methodology and sample are disclosed in the report. _Figure 2. Enterprise LLM usage share differs from small business chatbot usage. Source: Menlo Ventures 2025 Mid-Year LLM Market Update._ Shree Amujala I read these findings alongside the Bluevine data rather than as a contradiction. The first measures which chatbot an owner reports using. The second estimates which models technical teams select for enterprise workloads. Together they suggest that Claude’s broad SMB awareness remains behind the largest consumer-facing tools, while its usage is stronger when organizations make a deliberate choice for production and coding work. Closing the gap between casual experimentation and considered adoption is precisely where workflow design, training and governance become valuable. That last point matters. A 30-person company does not need a smaller version of a Fortune 500 transformation program. It needs a practical path from unapproved experimentation to a few repeatable, governed workflows that save time without creating new data risks. ## Four stages of small business AI maturity Across my client engagements, I see four distinct stages. Knowing the stage matters more than choosing the tool because each stage has a different problem to solve. _Figure 3. Four stages of small business AI maturity, based on patterns across client engagements._ Shree Amujala Stage one is shadow AI. Employees use personal accounts with no company visibility into what they paste into a chat window. Leadership may believe the organization has not adopted AI, but employees already have. A 2026 analysis of BlackFog research reported that 49% of workers use AI in ways their employers have not approved. This is not primarily an employee-discipline problem. It is a demand signal combined with a visibility problem. Stage two is licensed but unstructured. The owner buys seats, shares a getting-started guide and assumes adoption will follow. It rarely does. Some employees experiment, others avoid the tool and the business eventually concludes that AI did not deliver. The investment-to-usage gap in the Business.com findings is consistent with what I see at this stage: access exists, but repeatable work does not. _Figure 4. The AI investment-to-daily-usage gap. Source: Business.com 2026 Small Business AI Outlook Report._ Shree Amujala Stage three is structured enablement. The business maps AI to real daily work and builds a small number of workflows around it. In one Northern California commercial real estate lending engagement, we did not teach loan officers to chat with an assistant in the abstract. We built a specific workflow: review an unread email, compare deal terms with the current rate sheet, draft a response and prepare a calendar hold. One workflow proved the value before we expanded. Other functions followed the same pattern. General counsel used AI for a first review of leases and third-party documents, with the tool flagging unusual provisions and explaining why they deserved attention. Final legal judgment stayed with the attorney. Marketing converted one funded-deal summary into a blog post, social copy and an email blurb, then reviewed each item before publication. These are not dramatic use cases. They save real time because the tool adapts to the job instead of forcing the employee to become a prompt specialist. We also set boundaries before expanding usage: no payroll or HR data, human review for anything client-facing or judgment-based and approved business accounts with appropriate contractual data protections. Those rules did not slow adoption. They gave employees confidence about what was allowed. Stage four is governed and embedded. AI connects to the systems the business already uses, with identity controls, permissions, audit trails and clear ownership. Few small businesses I work with are fully there. Larger enterprises reached this stage first because compliance teams and security budgets pushed them toward it. Smaller firms may arrive because customers, regulators or insurers demand it. I would rather see them arrive by design than after an incident. ## The services opportunity is bigger than the license Most demand I see today is the move from stage two to stage three. That transition is a services problem. A license can be purchased in minutes. Moving a 30-person team from scattered experimentation to safe, repeatable workflows requires discovery, data-access decisions, training, governance and follow-through. Most small businesses do not have those capabilities in-house. The managed-services market is beginning to recognize this. Coverage from The MSP Summit points to revenue opportunities in AI assessments, data-loss-prevention controls, guardrails and AI-inclusive service tiers. The opportunity is real, but providers should resist turning it into another software sale. A tool deployed without workflow ownership and governance simply creates a more expensive version of stage two. My advice to MSPs and independent trainers is straightforward. First, identify the client’s maturity stage before scoping the work. A stage-one business needs visibility and policy before workflow automation. Second, begin with one recurring task that matters to the employee, not a generic demonstration. Third, build security and governance into the engagement from day one. Finally, measure independence rather than attendance. Login counts and workshop participation reveal little. A better test is whether an employee can run the workflow correctly twice without help and explain it well enough to hand it to a colleague. That second test predicts whether the process will survive after the consultant leaves. It also creates internal champions, which small organizations need because they rarely have a dedicated AI training function. This extends the principle I described in “Where AI fits — and where it doesn’t”: AI amplifies the foundation already in place. For a small business, identity access, clean data and clear ownership cannot be afterthoughts. They are part of the adoption work. Two years ago, the enterprise-first pattern looked settled. Small businesses would eventually receive simplified versions of what large organizations had already proven, with a lag measured in years. This time, the lag is measured in months and the support infrastructure is not keeping pace. The gap between how quickly small businesses want to move and how safely they are prepared to move is the real opportunity. It will belong to technology leaders who treat AI adoption as a people, process and governance challenge — not merely a software purchase.

AI has arrived in the business world — and the results are thus far underwhelming. According to McKinsey, 89% of companies now use AI regularly, and the majority are at least experimenting with AI agents. However, a significant gap remains between usage and economic success. “We find that only 37% of companies attribute any positive EBIT impact from their AI programs, let alone from newer agentic deployments,” writes the consulting firm in the McKinsey Technology Trends Outlook 2026. This is particularly problematic because AI agents not only open up new possibilities but also increase the complexity and costs of IT. McKinsey points out in its study that upgrades to the existing tech stack are necessary for agents to function reliably. In addition, there is the resource requirement during ongoing operation, as agent-based workflows are significantly more computationally intensive than simple chatbot interactions, because they are based on repeated inference loops, tool calls, retrieval steps, and cross-system coordination. According to McKinsey’s calculations, a single agent workflow requires five to 30 times more computing resources than a typical chatbot query. In a recent survey, 93% of participants stated that this caused them to exceed their AI budgets, according to the firm. ## Agents become more efficient McKinsey concedes, however, that this poor track record doesn’t have to be permanent. Agentic AI is still in its infancy, and the benefits companies derive from it will likely increase once the technology is more mature and deeply embedded in the enterprise. Furthermore, current agent development tools from Anthropic and OpenAI have improved tool usage and interaction with computers, according to the report, while frameworks such as LangGraph from LangChain have added the orchestration and “human-in-the-loop” controls needed to guide agents through longer workflows. One indicator of progress is the growing ability of AI agents to handle longer, more complex tasks from start to finish. McKinsey refers to the findings of nonprofit Model Evaluation and Threat Research (METR), which benchmarked the timeframe over which AI models can successfully complete tasks independently. For Claude Opus 4.6, METR estimates the 50% time horizon for software engineering tasks at approximately twelve hours. This means that for tasks of this size, successful autonomous completion is expected in half of the cases. However, McKinsey appears to have misinterpreted the data: As METR researcher Sydney Von Arx explained in an interview with MIT Technology Review, the value — in this example, the twelve hours — refers to the time a human would need on average for the task, not the AI. It is therefore more about performance than processing time. Von Arx explained that she, too, had initially been skeptical about whether the time horizon was the right measure. However, she and her colleagues had observed that the time horizons of top-performing models had increased over time — and that the pace of this development had also accelerated. “I can speculate all I want about whether this makes sense or not, but the trend is there,” the AI ​​expert stated. The performance of LLMs is increasing rapidly, as documented by METR. METR ## Agent-based software development reduces productivity AI agents’ potential is particularly great in the field of software development. If successfully deployed, they could unlock almost a trillion dollars in added value for companies, estimates McKinsey. The potential benefits extend far beyond faster code generation. Agents could analyze requirements, generate code, conduct tests, find bugs, or even handle parts of the deployment process. The analysts see the goal not just as a more productive individual developer, but as a redesign of the entire product development lifecycle. In practice, however, only a minority have achieved this so far, McKinsey has discovered. A study revealed that only a quarter of companies using AI agents for software development were able to significantly accelerate their development cycles. McKinsey considers at least a doubling of productivity for more than a quarter of teams to be significant progress. Significant differences also exist between individual developers: According to the study, around 80% of developers using AI tools achieved productivity increases of only about 3%. In contrast, the top 20% saw increases of 55%. But that’s not all: The study revealed that productivity actually declined in 30% of companies after development teams started using coding agents. It seems almost everyone is programming by “feel” — but that doesn’t always lead to added value, McKinsey writes. ## Quality over quantity is what matters One possible reason is that while AI increases the amount of code produced, this doesn’t automatically translate into more usable software. In one study, programming activity increased by 180% thanks to AI tools. But the number of published releases increased only by 30%. This shifts the key metric: Economic benefit is determined not by the amount of code generated or the number of AI interactions, but by the outcome of the entire development process. Added to this is a trust issue. According to McKinsey, around 46% of developers worldwide actively distrust the accuracy of AI tools. A third trust them in principle, while only 3% have great confidence in the results. Despite these initial hurdles, capital investment is increasing rapidly. According to McKinsey, investments in providers of agent-based software development solutions rose from a negligible level in 2023 to around $5 billion in 2025. In the first half of 2026, they then exceeded the $61 billion mark, primarily due to SpaceX’s acquisition of Cursor for $60 billion (in stock). The number of related job postings also increased by 221% between 2024 and 2025.

Clients ask me this question perhaps more than any other. They’ve usually just come off a bad experience, either analytics stuck in IT’s backlog for months or analytics scattered across the business without anyone accountable for what it all means. My answer is always the same. Split it. IT owns the data engineering. The business owns the analytics. And you need one small team sitting between them to keep the whole thing from drifting apart. That’s not a compromise position I land on to avoid picking a side. I’ve witnessed companies that went all in on one extreme or the other, and they end up in the same place. They have expensive dashboards sitting untouched and analysts who stopped trusting the numbers years ago. Give me twenty minutes with a client and I can usually tell which extreme they started from, just by looking at what’s broken. ## Full centralization and full decentralization both fail the same way When IT owns everything, security and governance are usually solid. You need people who actually understand networking and access control managing any connection to raw data coming out of your ERPs, TMS and CRM systems, not analysts who picked up security practices on the side. But speed dies. Business analysts wait on intake forms and requirements documents that assume you can specify a dashboard’s full scope before you’ve ever seen the data move. Analytics doesn’t work that way. It’s one of those areas where you need multiple iterations to land on the right end state. You learn what you need by building something rough, using it for two weeks and rebuilding half of it. A team that has to file a ticket for every iteration will never keep pace with a business that changes its questions weekly. People who sit close to the business need the freedom to iterate as the tools mature, and that freedom disappears the moment every change has to clear an IT queue. Flip it and hand analytics entirely to the business, and you get the opposite failure. I worked with a company this year that let every department build its own reports with no shared standards or governing body. Marketing had one set of definitions for a “customer.” Sales had another. Finance had a third, and every meeting turned into an argument about whose number was right. Total spend wasn’t being tracked either. As you can imagine, by the time they called me, their cloud analytics costs on Microsoft Fabric had already climbed past $20,000 a month, and the team couldn’t point to where it was going. They fixed it by building a small internal group, essentially a center of excellence, that owned the standards everyone else built on top of. CIO contributor Ranko Cosic’s April 2026 piece, “How analytics and AI are reshaping the boundaries of IT leadership,” draws a similar line, arguing that IT leadership builds the capability to analyze while analytics leadership builds the capability to decide. I’d add a third piece. Someone has to own the handoff between those two, or you get exactly the sprawl I saw at that client. There are numbers behind this. In a survey of more than 2,400 CIOs, Gartner found that companies where IT and business leaders co-own delivery, what Gartner calls the “franchise” model, hit or beat their targets on 63% of digital initiatives. Companies where IT keeps sole ownership hit that mark on just 43% of initiatives. Only 12% of CIOs run a true franchise model today. That’s the whole argument in one number. ## Adoption breaks when builders and users are different people A few years ago, I got called into a large manufacturing company that had spent three years and an entire IT department building a dashboard platform meant for the whole organization. When I looked at usage, six people were opening those dashboards regularly. Six, out of thousands of employees. The tools worked fine technically. What broke was trust, and it’s a classic mistake. Trust and adoption begin when end users are part of the design process, or better yet, when they’re the ones building the tools. That number stung, but it isn’t unusual. A BARC and Eckerson Group survey of 214 data and analytics leaders found average active adoption of BI tools sitting around 25%, a figure that had barely moved in seven years of tracking. Those companies bought good tools, but the adoption model wasn’t built to match. They skipped giving the people who’d use those reports a role in building them. Adoption climbs when the people using a report have a hand in shaping it, or better yet, built it themselves. That manufacturing client shifted from a fully centralized build to a decentralized one, with IT still owning the underlying data and business teams, together with us as consultants, owning what got built on top of it. They now have roughly 80% of employees using the tools weekly, on the same data, at the same company, with nothing changed but who owned the build. I bring this up with every client who tells me they want “one IT team” running analytics end to end. A single team can own the pipeline. It can’t own every department’s judgment about what a useful report looks like, and trying to force that usually produces the same six-user outcome I saw at that manufacturer. ## Standardization is the toll you pay for scale There’s a fifth benefit to this structure that I didn’t lead with, but it’s the one that surprises clients most. It’s that alignment gets easier, not harder. Any organization of real size has a hundred project requests, a thousand small enhancements and a never-ending list of technical debt sitting somewhere. When all of that runs through one intake, owned by the seam team instead of scattered across five departments, prioritization stops being a fight and starts being a conversation. Time and time again, I’ve watched people set aside what’s good for their own team once they can actually see the whole list, the whole picture of what needs doing across the business. That only happens with one line of work to look at, not five competing ones. This doesn’t come free. Splitting ownership this way comes with costs, and I tell clients about all three before they commit to the model. First, the ramp-up is slow. If your organization has been running fully centralized or fully decentralized, the first few months of a split model will feel like you’re moving backward. You’re building shared data models from a standing start. You’re writing templates nobody has tested yet. None of it pays off immediately, and it takes longer than anyone wants to admit before the shared foundation starts paying for itself. Second, coordination gets harder. Running one IT team that reports up a single chain is simpler than coordinating a business analytics team and an IT team that each report somewhere else and only share a dotted line into governance. You’ll spend real time in rooms aligning people who don’t share a manager. Third, standardization itself is a hard sell early on. People resist naming conventions and data model rules when they can’t yet see why those rules matter. I’ve sat through those meetings. It usually takes a few months before teams start seeing the payoff in shared resources and consistent numbers across departments, and until then you’re asking people to trust a process they can’t yet see the benefit of. I still think the tradeoff is worth it. The alternative is a business that’s either too slow to answer its own questions or too scattered to trust the answers it gets. Every client I’ve seen commit to the split — security in IT, agility and ownership in the business, a small governing layer holding the seam together — has come out the other side with something that actually gets used. The ones that skip the governing layer end up back in my inbox a year later, describing the exact same $20,000-a-month problem with different numbers attached. So, when a client asks me where analytics should sit, I don’t tell them to pick a side. Instead, I tell them to build the seam. Put someone in charge who speaks both languages, IT and the business, and give that person say over the standards. If you skip that part, you end up back where you started. Get it right, and it’s the difference between six people opening a dashboard and eighty percent of the company doing it every week.

Several months ago, I was invited to an event for CTOs. Just looking around the room, I could see someone had made an assumption about my title. I am a chief transformation officer, not a chief technology officer. I stayed anyway to see how the other type of CTO thinks about AI. When a CISO got onstage and said, “This is our time,” my immediate reaction was cringe. I remember thinking, AI is going to change jobs, workflows, skills and how people experience work. Tools and controls alone will not produce transformation. The real challenge is redesigning how work gets done. I knew from the beginning that AI would require partnership across technology, security, legal, finance and the business. But I saw people and operating-model change as the center of the work, with technical and governance teams enabling it. After working to operationalize AI across a company, I can see what I missed. ## Why I started with people and operating models My original assumption was based on my own experience managing through change. Technology creates possibility; operating models create value. Access is not adoption. A team can run an impressive pilot that never becomes part of how the function operates. Experimentation means very little if leaders have not defined the business outcome, how the workflow will change or how the team will sustain it once the pilot ends. People leaders understand job design, learning, manager behavior and the emotional reality of change. People resist initiatives that feel disconnected from the work they are accountable for every day. Organizations also tend to budget for technology and not for transformation, treating licenses, APIs and model usage as the whole investment. The real cost includes the time people need to learn and build fluency, and the clarity managers need about what good use looks like. A technically strong AI program can fail because the organization never changes around it. AI raises the floor, but transformation raises the ceiling. The larger value comes from what happens around the technology, including where human judgment is still required and what the company can now do differently. Research supports the importance of that organizational layer. McKinsey’s 2025 State of AI report found that redesigning workflows was the factor most associated with reported bottom-line impact of generative AI. ## Operationalizing AI shaped my answer The more I moved into execution, the more obvious it became that any single function can’t own AI transformation. Technology, data and security could not sit alongside the people transformation as support functions. Leaders across the business have to help design it. At Branch, I am the executive accountable for AI across the company, including our enterprise strategy and the work of connecting governance, technology, priority use cases and organizational change. Once I started leading that work, I kept running into decisions my team could not make. We needed technology and data leaders to determine whether the architecture was ready and how models would connect to our systems. Security and legal had to establish the boundaries. Finance needed visibility into consumption. The business still had to decide which workflows deserved investment and own the result. Every practical decision exposed another dependency. We needed an operating model that made routine decisions clear and gave higher-risk work the right review. Good governance should work like a freeway, with lanes, offramps and rules everyone understands, not a roadblock that stops progress. Operationalizing AI taught me that no one function can own execution because the work happens across workflows rather than within the boundaries of the org chart. After eight months of doing this work, I believe someone has to own the transformational work within the organization, but technology, security, legal, finance and people leaders each carry critical parts of the execution. Then, individual functions own their use cases and results. ## What a chief AI officer should actually own Every company needs to know which executive is accountable. Whether that person needs the title of chief AI officer depends on the company. A dedicated role can be valuable when AI activity is fragmented and the company needs to move from pilots to an enterprise operating model, but it can’t substitute for shared ownership across the leadership team. That distinction is showing up in the role itself. CIO’s examination of the chief AI officer’s evolution describes a shift away from a central leader owning every AI activity and toward a model where the AI executive establishes strategy, standards and common capabilities while enabling the business to execute. In my experience, that is much closer to what the work requires. The accountable executive should decide where the company will focus and make sure governance produces decisions quickly enough for teams to act. They need alignment from the leadership team on which risks the company is prepared to accept and how it will know the work is paying off. They also own how the organization changes around the technology. That includes how people learn, what managers expect, how workflows get redesigned and where the company reinvests the time AI creates. They should not become an AI island. They can’t be the technical concierge for every tool request or the gatekeeper every function waits on. That structure gives the rest of the executive team permission to outsource responsibility for a transformation that affects all of them. Finding someone who fits that profile is its own challenge. I would look for a transformation leader with real technical fluency. They need to work credibly with architecture, data and security leaders. Their job is to connect those decisions to workflow redesign and bring the organization with them. In some companies, that person will be the CIO. The 2026 State of the CIO research describes CIOs increasingly acting as AI orchestrators and change management champions. In other companies, the accountable executive may be a chief transformation officer, a chief operating officer or a dedicated CAIO. The title matters less than the mandate, authority and ability to lead across boundaries. When I think back to that CTO event, I understand why the CISO said, “This is our time.” AI has expanded the mandate of security and made its partnership with the business more important. I also understand why I reacted so strongly. People are the transformation. Ultimate accountability still sits with the CEO. Functional leaders own outcomes in their areas. The board needs visibility into strategy, material risks and oversight. The AI leader keeps those layers connected.

Hyperscalers are rushing to build more data centers to run AI workloads — but will the AI industry ever generate enough revenue to pay for that infrastructure? Researchers at Bain and Company have looked into this and concluded that productivity gains from existing AI services are not enough to justify the money being pumped in: AI companies and the hyperscalers that power them will need to create brand new markets for their services. Bain said the “arms race” among hyperscalers is accelerating to the extent that their capital expenditures could reach $780 billion in 2026, a fivefold increase in three years. And, it estimates, annual spending on AI infrastructure could reach $1.5 trillion by 2031. Making the assumption that hyperscalers’ capital expenditure amounts to about 25% of revenue, they would need the AI market to be worth $6 trillion annually. But, said Bain, the current consumer and enterprise AI markets together could be worth up to $1.8 trillion by 2031, leaving a whopping $4.2 trillion still to find from new markets. Bain highlighted four potential areas: the use of AI in search; the development of more autonomous vehicles, including drones; physical AI, including digital twins and robotics; and new product development, for example, breakthroughs in pharmaceuticals. _This article first appeared on_ Network World_._

Tools such as Anthropic Claude Code or OpenAI Codex have changed the face of software development, and all the signs are that this investment is set to increase further. But is paying a monthly subscription (and perhaps additional usage fees) cost-effective? Will the increasing level of investment in AI-generated software prove to be worthwhile? That’s a question several economists from the US National Bureau of Economic Research have attempted to answser, at least indirectly. Their paper, snappily entitled The Macroeconomic Effect Of AI: Sizing The Software Engineering Channel, attempts to calculate how much AI has increased the productivity of software engineers in enterprises outside the software and semiconductor industries by looking at their share prices. “The main idea is that if AI raises the productivity of software engineers, then firms that rely more heavily on them should benefit more. Therefore news about AI generates higher expected profits for these firms. These profits are capitalized into larger stock price responses. Combining these stock price responses with a model, we can pin down the increase in software engineering productivity expected by financial markets,” the researchers wrote. And the answer? “From November 2022 to December 2025, AI increased the market’s expected present value of software engineering productivity by the equivalent of a permanent 32.6% productivity increase.” That’s not to say that your software engineers will be that much more productive, but it’s a starting point for allocating budget between AI tool use and payroll.

When Omnissa this week rolled out a new AI governance authority product, Elara, in beta, it delivered a glimpse into the potential of having visibility between the typical enterprise’s data silos, whether they’re in lines of business, disparate geographies, or corporate operational units. “By connecting signals across systems that often operate independently, Elara gives IT and security leaders greater context into how their digital work tools, including AI apps, models and agents, are being used across their environment, and the ability to apply policies and controls based on broader business context,” the vendor, formerly a unit of VMware, said in its announcement, noting that many existing tools are limited to authorizing actions within the systems they manage. “Elara is designed to sit above these tools, connecting the systems that customers already run and giving organizations broader context without requiring them to standardize on a single technology stack,” it said. Brian Link, product CTO for Elara, offered a hypothetical example that illustrated the potential of cross-silo data sharing, which enterprise CIOs have seen as a data Holy Grail for decades. If someone in cybersecurity needs to, for example, push an urgent OS update to global retail tablets to address a newly-discovered vulnerability, he said, Elara could consult multiple data sources across the organization to properly evaluate the risks and advise whether the update should happen at that time. “Elara knows those stores are in an active change freeze (due to) inventory count, and that these are the same iPads running the inventory application,” Link said. “It pulls that freeze from ServiceNow, so the approver sees it before deciding. The decision stops being only a security call and becomes a business trade-off. Before anyone approves, Elara shows the blast radius: the devices, users, and services the change would touch, plus the events the approval would trigger. Only then does the human decide.” Frank Dickson, principal analyst at Dickson Research, agreed with Link that cutting through the data visibility limits caused by enterprise silos has tremendous potential. But he also stressed the logistical challenges, given how tightly many enterprise LOB executives limit access to their unit’s information. “A security patch colliding with an inventory freeze is not a technology problem. It is a business trade-off. The person approving the change should see both sides before deciding. The example is strong, and the [corporate] politics raised may be its Achilles’ heel,” Dickson said. “Omnissa’s natural territory is the endpoint, which is one silo, and the security, network, legal, and finance teams have no particular reason to treat it as the referee.” But, he argued, this scenario can only occur if the information happens to appear in the very limited number of places where Omnissa can access data. It doesn’t break down those data silos as much as it enjoys tiny cracks of visibility between some of them. “This is Omnissa’s scenario for a product that is still in beta. It is not a customer result. But Elara only knows about the freeze because someone recorded it in ServiceNow,” Dickson said. “The context is only as good as the systems it comes from; if the freeze lives in a regional manager’s inbox, Elara never sees it.” But rollouts of products like this might get the data silo conversations renewed, which could be a good thing. “An umpire is useless if the two teams never agreed on the strike zone,” Dickson said. “Elara can call balls and strikes all day, but someone above the CISO and the head of store operations has to define the zone first. That is why vendor clearance matters; every connector is a permission, and every permission is a negotiation with whoever owns that silo: the CISO, network operations, Legal, the CFO’s office or a regional business unit.” He pointed out, “Elara does not just watch. It can block or limit actions, so the ask is bigger than read access. A single control point across every silo is also a single point of failure, the keys to the kingdom if you will. A CISO would be right to scrutinize it hard.” And, he noted, CIOs cannot grant access to data that their teams don’t control. Link acknowledged the challenge, and said that the critical enterprise element is somehow bringing in previously unavailable context, “but we are reliant on people [in IT] bringing those pieces of the puzzle to us.” He said that his team is trying to address the question of ‘What do you do when that context no longer lives inside a person’s head?’ “Right now, I don’t see anyone else trying to do that.” _This article originally appeared on Computerworld._

California is setting a precedent for AI use in scenarios where workers’ jobs are at stake. Governor Gavin Newsom this week signed the No Robo Bosses Act (SB 947), which bans employers from relying solely on AI-powered automated decision-making systems (ADS), also known as “bossware,” to discipline or terminate workers. Introduced by Senator Jerry McNerney, the act is the first of its kind in the US. It is set to take effect on July 1, 2027. While applauded by many, on a wider scale, No Robo Bosses raises questions about what adequate human oversight looks like in this age of AI. “A machine can recommend, but a human must decide,” noted Frank Dickson of Dickson Research. “The hard part is defining what ‘decide’ means.” ## Combating AI bias and ‘troubling’ errors ADS platforms are becoming ever more prevalent in hiring, as they promise to speed up and streamline HR processes, maximize productivity, and reduce costs. According to reports, more than half of employers use ADS to help make decisions around restructuring and role planning. But, McNerney and others contended, AI is prone to bias and misjudgment, and there are examples of ADS making “troubling” errors, including mistaken firings. Meanwhile, on-device “bossware” or “tattleware” employee monitoring and productivity tracking software could potentially be used in reprimanding or firing decisions. AI recruitment tools have similarly come under scrutiny of late, with job seekers alleging that platforms like Workday discriminate based on age, race, and disability. To combat these issues, the bill, SB 947, seeks to set guardrails around AI use in the workplace. The legislation mandates human oversight and verification when enterprises apply ADS tools, and employers must inform workers if they have used them when making decisions about their jobs. Further, SB 947 prohibits the use of ADS and bossware systems that analyze personal information and behaviors to essentially predict how employees will perform or act in the future. And at a worker’s request, employers must provide at least one year of the data used by an ADS system to make a disciplinary, termination, or deactivation decision. Enterprises found violating any of these provisions are subject to a $500 civil penalty per violation. “Employers are devastating workers’ livelihoods and taking no responsibility for the callous decisions of this unchecked technology,” said Lorena Gonzalez, president of the California Federation of Labor Unions, AFL-CIO. “This is unacceptable. We need stronger guardrails to make sure there is human review and oversight of any decision made by a machine that impacts a worker’s job and paycheck.” ## Promoting decisions based on context, evidence Dickson pointed out that the law is narrower than its name implies: ‘No Robo Bosses’ sounds like a ban, but it is not. “The law does not keep AI out of the decision. It keeps a human in it,” he said. According to the legislation, a human must corroborate the system’s output using the data behind it and other supporting information like performance evaluations, personnel files, work product, peer reviews, or witness interviews. If the reviewer finds the output inaccurate, incomplete, or misleading, the employer cannot use it, Dickson said. “The test is whether the human checked the evidence and had the power to say no [to the AI’s decision],” he said, observing that a manager simply forwarding the bot’s verdict is a mail carrier, not a decision maker. In a sense, it’s like an instant replay in sporting events: The umpire watches the video and makes a judgment call, rather than just rereading the call from the field. “What matters is that they examined the evidence, not just the conclusion,” Dickson said. An employee’s disciplinary or termination notice must disclose whether an AI system was used, and confirm that a human reviewed and corroborated the decision. Human accountability is the point here; an employer owns the final decision. “Accountability can’t be shifted to the AI,” said Valence Howden, advisory fellow at Info-Tech Research Group. How it comes to its conclusions must be continuously assessed for bias, error, and drift. “The bot has no human compass for rationale, and context is defined by who controls its model,” Howden said. “Without context, the human has no impact on the end result, and, given the rate of failure here, there are many (legal and other) implications.” ## What enterprises can take away from California’s example The grey area in the bill is the phrase “primarily relies,” Dickson pointed out; it does not specifically define what that means. “A prudent employer may assume that if the system’s output started the conversation, the decision is in scope, and document accordingly,” he said. Enterprises should consider five factors when developing a plan around discipline and termination, he said: 1. **Inventory** : Know which tools score, rank, or flag employees. McNerney’s office cites hundreds of “bossware” products on the market, and many enterprises may not know which ones their managers use. 2. **Reviewers** : Name who corroborates decisions, train them, and give them real authority to overrule the system. 3. **Data access** : A reviewer cannot corroborate what they cannot see. If a vendor cannot show the inputs behind an output, the tool may be unusable for these decisions. That condition belongs in the contract. 4. **Records** : Keep the evidence that the reviewer examined, as employees have the right to request the personal data used. 5. **Notice** : Build a plain-language, standalone notice template now. Dickson said that this is an IT problem as much as an HR one. “Corroboration requires that the inputs to every automated decision are logged, retained, and retrievable by someone outside IT,” he said. “That is an architecture decision, and the CIO makes it.” And, while the $500 penalty might sound small, larger exposure may come later during wrongful termination disputes in which “the algorithm said so” proves a weak defense. Info-Tech’s Howden advised enterprises to identify their high-risk, high-human-impact scenarios and cases, clarify which decisions, activities, and actions AI can take, and tag those that require human validation and involvement. They should also look at the volume and scale of these types of action so that volume alone doesn’t become a challenge to human involvement. This is AI governance at a foundational level, Howden noted. “AI shouldn’t be allowed to make irreversible or material decisions and changes without oversight,” he said. Ultimately, this move may drive enterprises to actually understand the criteria for hiring and firing, and look for issues and biases in the way decisions are made before an AI exposes poor decision logic and removes critical people. “Legal implications are more likely to shape the direction,” Howden said, “especially with the disclosure requirement.”

Microsoft and Google are joining a project to create an open specification for exchanging semantic models across data, analytics, and AI platforms. The project already has the backing of over 60 companies including Databricks, Informatica, Mistral AI, Nvidia, Oracle, Salesforce, and Snowflake. Their support for Ossie makes it a little more likely that future analytics platforms will be interoperable, but is no guarantee that vendor lock-in will go away, analysts said. The project began life as Open Semantic Interchange (OSI), then became Apache Ossie when it was accepted into the Apache Incubator in June. It uses JSON and YAML to represent semantic models, including datasets, fields, relationships, metrics and AI context, making them interoperable across platforms such as Snowflake, Databricks, Tableau, ThoughtSpot and Sigma. Ossie uses a hub-and-spoke model for interoperability, serving as the common semantic format while converters translate between it and individual vendors’ semantic implementations. This means an enterprise could move a semantic model between compatible platforms without requiring a separate point-to-point converter for every pair of vendors. Microsoft’s support for Ossie includes developing a two-way converter between Power BI semantic models and Ossie, allowing semantic context defined in Power BI to be represented in the common format and Ossie models to be converted back into Power BI, the company wrote in a blog post. It is also pushing for the Ossie specification to include more support for its ontologies, and for Ossie’s recognized query languages to include DAX, the expression language used by Power BI for defining calculations and business metrics. That means enterprises could carry the calculation logic that gives their semantic models business meaning alongside the underlying model when moving between platforms that support Ossie, it wrote. Google, meanwhile, is in the process of joining Apache Ossie, a company representative said via email response. The company has not yet provided details on what it plans to contribute or has already contributed. The Ossie specification lists BigQuery/GoogleSQL as a supported dialect, a result of “early community contributions that recognize BigQuery’s footprint across enterprise data stacks,”the representative said. ## Microsoft, Google backing could reduce engineering work Support for the project from the two technology giants could reduce the burden of repeated semantic engineering for enterprise teams moving analytics workloads between platforms, said Aditya Ranjan, senior data engineer at supermarket giant H-E-B. That reduced engineering overhead could also help avoid metric drift, which is often the consequence of recreating and maintaining the same business definitions across platforms, according to Ashish Chaturvedi, executive research leader at HFS Research. With Ossie, developers can instead define a metric once and treat it as a versioned, reviewable code artifact, rather than rebuilding and maintaining it separately for each platform, he said. Another potential benefit, said Ranjan, is that productivity could improve if developers spend less time translating and validating semantic definitions for each platform when onboarding new analytics tools or deploying new analytics or AI applications. It can also make it easier for developers to build agentic applications with consistent business context, since maintaining one definition of a metric across platforms could reduce the risk of different agents interpreting the same metric differently, said Stephanie Walter, practice leader of AI stack at HyperFrame Research. That could give CIOs greater confidence to scale agentic deployments, she added. ## Portability For Michael Leone, principal analyst at Moor Strategy and Insights, the bigger advantage of Microsoft and Google supporting Ossie is that it gives enterprises more ownership of their semantic models by making them more portable. That portability gives buyers more leverage, said Walter, since changing a BI or data platform would no longer require rebuilding the semantic layer from scratch. However, portability does not necessarily mean complete interoperability, as the degree to which enterprises can move semantic models between platforms will depend on how much vendor-specific logic and functionality Ossie can represent and how accurately the destination platform can interpret it, Walter said. “A portable structure does not guarantee equivalent behavior. A metric may survive conversion syntactically but still produce a different result because the destination interprets joins, nulls, time calculations, or filters differently.” That challenge is particularly relevant for Power BI, as its time-intelligence functions, calculation groups, and context transitions in DAX do not always map cleanly to ANSI SQL, meaning a sophisticated Power BI model could lose some of its behavior in translation, Chaturvedi said. CIOs, therefore, will still need to validate whether converted models preserve the intended calculations, business logic and results before putting them into production, especially for complex ones, Ranjan advised. There are gaps around governance as well, Chaturvedi said: “The core specification covers datasets, relationships, fields, and metrics, but doesn’t mention row-level security, access policies, or certification status as first-class elements.” That means enterprises have to set them up again on each platform. Moreover, Ossie’s stability and long-term adoption remain open questions. The project is still “incubating”, meaning that it isn’t a full Apache Software Foundation project and has yet to prove it meets community norms. The current specification version, 0.2,is explicitly labeled a development draft, meaning the schema and capabilities could still change as it evolves, giving CIOs less certainty about its suitability as a long-term interoperability layer, Walter said. “The current draft also removes the earlier document structure and does not yet define bundles or cross-model references, which are capabilities that large enterprises with interconnected models are likely to need,” said Chaturvedi. ## Ossie could shift rather than eliminate vendor lock-in Even if Ossie becomes widely adopted, it is unlikely to eliminate vendor lock-in entirely. “New forms of lock-in are likely to emerge. Execution engines will retain proprietary behavior that no interchange format captures and vendor extensions will carry increasingly valuable features,” Chaturvedi said. For enterprises, that means the definitions become portable while the behavior around them stays platform-specific, he added.

The global memory shortage that has driven up the cost of servers, storage and PCs through 2026 will get worse in 2027 and 2028, according to memory maker Micron Technology. “We expect memory and storage supply-demand conditions to be much tighter in calendar 2027 and 2028 than they were in 2026,” CEO Sanjay Mehrotra said in prepared remarks for the company’s fiscal fourth-quarter earnings call. Even with new cleanroom space planned across the industry, “We do not have line of sight to when supply and demand will return to balance,” he said. Earlier industry forecasts had expected the two to return to balance in 2028. Mehrotra added that new plants would not bring quick relief. “Production from new DRAM and NAND fabrication facilities takes time to ramp and gradually becomes more meaningful starting a few quarters after initial output,” he said. Neil Shah, vice president of research at Counterpoint Research, said the outlook means CIOs “will have to be prudent about which equipment to upgrade and which to stretch to maintain cost efficiencies.” ## Higher prices, less memory On the same call, CFO Mark Murphy said Micron’s “inventory levels and supply remain extremely tight.” Its DRAM prices rose by a percentage in the high teens in the fiscal fourth quarter, while NAND prices climbed about 30%, he said. Taiwan-based market research firm TrendForce expects prices across the industry to keep rising. In a Sept. 30 report, it forecast that conventional DRAM contract prices will increase another 10% to 15% in the fourth quarter from the third. It expects NAND flash prices to climb 15% to 20%. The firm said increases are slowing but the market remains undersupplied. IDC expects PC buyers to pay more as well. The research firm forecast in June that average PC selling prices will rise 17% in 2026. TrendForce has also tracked a shift toward less memory per server. Cloud providers and OEMs have moved some servers from 96GB and 128GB memory modules to 32GB and 64GB modules since the first half of 2026, the firm said in a July report. Analysts had warned in January of higher prices and lower memory specifications for enterprise PCs. ## Supply committed years ahead Micron has already committed more than 75% of its 2027 output, and most of its customer discussions now concern 2028, Mehrotra told analysts on the call. Much of that supply is locked into multiyear, take-or-pay contracts that Micron calls strategic customer agreements (SCAs). “Any new discussions on SCAs where pricing is involved are negotiated with higher pricing based on prevailing market conditions and outlook,” Mehrotra said. Some cloud providers have signed similar long-term agreements with memory makers, TrendForce said in its July report. That has left buyers without such deals as the main source of server DRAM price increases, it said. Shah said enterprises should lock in pricing too. “Companies should secure multiyear pricing for the computing capacity they know they will need,” he said. Moving workloads to the cloud will not avoid rising hardware and energy costs “because providers will pass them on,” he added. ## Which refreshes to delay When it comes to replacing existing equipment, Shah said, the right call depends on the workload. “For general back-office PCs and routine file servers, stretching lifecycles from three years to five is harmless,” he said. “But for core infrastructure and engineering seats, delaying refreshes can backfire.” Aging equipment can drag on productivity, lose software support and fail more often, he added. Shah also cautioned against turning to older memory to save money. Memory makers have been converting production lines to high-bandwidth memory and DDR5, so DDR4 is no longer cheap or plentiful, he said. “If you buy legacy platforms today to shave 10% off upfront server costs, you’re buying into systems which won’t have serviceable parts two years from now.” He recommended starting with the hardware already in place. “Enterprises often waste 30% to 50% of memory by provisioning for peaks that rarely occur,” he said. Right-sizing virtual machines, quantizing AI models and batching workloads more efficiently can cut memory use significantly, according to Shah. Before buying more hardware, he said, “CIOs should think about optimizing on the silicon already in place.” ## What hardware vendors say Hardware vendors had no helpful advice to offer budget-constrained buyers. Lenovo did not answer questions directly but pointed to remarks executives made on its Aug. 13 earnings call. Chairman and CEO Yuanqing Yang said then that he expects memory demand to keep rising and supply to remain constrained at least through the end of 2027. He said Lenovo can respond quickly to rising component costs: “When the material costs rise, we can adjust the pricing at the front end in a timely manner.” Luca Rossi, president of Lenovo’s Intelligent Devices Group, said he expects the PC market to shrink about 15% in units in the six months to March, with business demand holding up better than consumer demand. On the server side, Ashley Gorakhpurwalla, president of Lenovo’s Infrastructure Solutions Group, said a “strong server refresh cycle is underway.” Dell, HPE, HP, Cisco and Supermicro did not respond to requests for comment by publication time.

ServiceNow has a new take on the service desk: Flow by ServiceNow, a standalone AI product that allows users to get help via chats in Microsoft Teams, Slack, or a Flow web app, or by email, rather than having to leave what they’re doing to open a helpdesk ticket. Flow can be up and running within a day, no implementation project or infrastructure required, the company said. The product can stand alone or plug into the ServiceNow platform for customers who need enterprise scale, governance, and cross-functional workflows, it said. It’s a smart move, said Frank Dickson, principal analyst at Dickson Research. “The pitch is what Flow does not require. ServiceNow claims Flow can be running in a day with no implementation project, no CMDB migration, and no infrastructure. Every item on that list is something its flagship ITSM platform does require. ServiceNow is selling the absence of its own complexity,” he said. Flow will connect to more than 100 systems through pre-built connectors. If the AI can’t surface the information it needs to fulfill a request from available data sources, Flow will escalate the issue to a human. Frequent requests, such as those for password resets, can easily be automated by IT, ServiceNow said. ## Cost of consumption Customers don’t need an existing ServiceNow implementation to use Flow; as soon as it goes live, it can handle user requests. Pricing will be consumption-based. ServiceNow customers who subscribe to its AI services will also be able to deploy Flow with no additional licensing costs; they will just pay for consumption via assists from their existing pool. The product is currently available at no charge during what ServiceNow refers to as Controlled Availability. Organizations seeking early access can sign up on the Flow website. ServiceNow plans to release it to current customers on October 6 in North America, and make it generally available to all users in North America and EMEA by year-end. Wider availability will follow in the first quarter of 2027, a company representative said. Melody Brue, principal analyst at Moor Insights & Strategy, said that Flow is a logical next step for ServiceNow. “The company built its business around digitizing work that historically moved through tickets, forms, portals, and manual handoffs,” she noted. “The AI opportunity is to make that same operational depth easier to access through conversation and, increasingly, voice.” ## Headless trade-off Dickson said Flow rides a larger trend toward headless software, in which the engine runs in the background and uses someone else’s user interface, in this case Slack or Teams. But it’s a trade-off: “ServiceNow describes its platform as a single pane of glass. With Flow, it hands the glass to someone else. Whoever owns the interface owns the daily habit, and in headless software, the habit may become the relationship.” That said, Brue saw Flow as a good fit for today’s market. “Customers want AI with a clear use case, quick time to value, and proof that it can do more than generate answers,” she said. “They want it to resolve real work. A standalone product also gives ServiceNow a lower-friction place to land (with the goal of expanding), reaching customers that may not be ready or have time for a full platform rollout.” But, she said, while many vendors offer AI assistants, “the real test is whether this can reliably complete work across systems, with the right permissions, approvals, and human handoffs. ServiceNow has a credible foundation in workflow and service operations. The question is whether it can make that enterprise depth simple and fast enough to deploy for the product-led AI market it is targeting.” With the current fierce competition to capture “the front door of work,” she said, “ServiceNow’s opportunity is to differentiate not just on the conversational experience, but on its ability to carry a request through governed workflow, approval, and fulfillment across systems.”

Every technology professional working today owes their career, in part, to someone who took a chance on them. The software engineers, cybersecurity analysts and infrastructure specialists on our teams didn’t arrive fully formed and ready to perform. Someone hired them, trained them and gave them room to grow. That’s worth remembering now, because the tech talent pipeline is shrinking, and history shows it can take more than a decade to recover from a decline like this. The pipeline is at risk on two fronts: fewer students are choosing to study computer and information science, and hiring managers anticipate weaker near-term demand for these graduates. This isn’t unprecedented. The computing profession has weathered two major talent declines in its short history, and each took more than a decade to recover. ## After 15 years of growth, computing enrollment reverses According to the U.S. National Center for Education Statistics, the number of computer science and information science B.S. graduates has grown steadily since 2010. A tech degree once meant a well-paying job and a career with a future, driven largely by increased demand for technology. That momentum now appears to be reversing across several regions of the world. Research from the National Student Clearinghouse Research Center indicates that enrollment in CS and IS degree programs at U.S. colleges and universities fell by more than 8% in 2025, even as overall undergraduate enrollment grew by 1%. The trend is not confined to the U.S. According to BCS, the Chartered Institute for IT, the UK saw a similar decline, with 18-year-old UK students entering computing degree programs down 9% in 2025. In Australia, the decline appears even steeper. ACS/Information Age reports that the Australasian Conference of Tertiary Admissions Centres’ (ACTAC) January 2026 report shows a 21% decline in enrollment for IT-related degrees heading into 2026. Three countries, three distinct education systems, one common outcome. What makes this notable isn’t any single data point but the swift, dramatic downturn across all three countries. If this were confined to one market, it could be dismissed as a local correction; however, a similar pattern across the United States, the United Kingdom and Australia at roughly the same time suggests a structural shift in how the next generation views a tech career. ## What 1,200 tech leaders expect: Lower demand for graduates If the problem were only fewer graduates, but hiring demand were strong, the situation would probably correct itself. Talent scarcity would drive up wages and attract more students. However, the demand side appears to be contracting as well. In the second quarter of 2026, I surveyed more than 1,200 senior technology leaders across 53 countries and what they expected their organization’s hiring demand to look like five years from now for entry-level roles filled by graduates with bachelor’s degrees in computer science or information science. Respondents held titles including CIO, CTO, VP of IT and Head of IT. More than 6,600 surveys were sent to technology leaders via LinkedIn, resulting in a 19% response rate. The results were sobering: 45% anticipated lower demand, 28% expected demand to remain the same, while 27% anticipated it to increase. (You can download a summary of the survey at https://www.impactfultechnologyleader.com). Chris Caruso This result was not limited to a specific country or region. Those expecting hiring demand to be lower in five years were in the majority across almost every country, industry and company size. The reason, cited across every group, was the same: artificial intelligence. Leaders expect AI to automate much of the entry-level technical work, including routine coding, service-desk tickets and administrative tasks. This is the work where new graduates have traditionally begun their careers. The logic is that existing teams, aided by AI, can do more without adding entry-level employees. Regardless of their responses to the survey question, many of the leaders noted that reducing the number of junior roles in their organization was problematic. They recognized that it would erode the pipeline for future senior talent and that recovery from this gap would take years. ## We’ve seen this movie before This is not the first time CS and IS graduate numbers have fallen. In the mid-1980s, universities were overwhelmed by demand for computing degrees and couldn’t staff their programs adequately. When computer science programs could no longer accommodate surging student interest, universities capped enrollment and tightened admission standards. The effect was dramatic: bachelor’s degrees in computer and information sciences fell sharply beginning in 1987. It was not until 2001, fifteen years later, that graduation rates recovered to their earlier level. The second decline came in the early 2000s, in what might be called a perfect storm. The winding down of Y2K remediation, the bursting of the dot-com bubble and a rising wave of IT offshoring converged to shake confidence in technology as a career. Mass layoffs swept through IT departments and dot-com firms, and enrollment in computing programs fell once again. The resulting drop in tech degrees awarded began around 2005, and it was not until 2016, eleven years later, that graduation rates recovered to the same level. The chart below from the U.S. National Center for Education Statistics depicts these two significant declines in graduates with technology degrees. Chris Caruso ## Is AI the new perfect storm? If you map today’s forces onto that history, the parallels are hard to miss. AI-driven automation is creating a demand shock, declining technology enrollments are creating a supply shock, and growing skepticism about the value of a technology degree is creating a confidence shock. This mirrors the erosion of faith in the career path after the dot-com bubble burst. What took three separate crises to unfold in the early 2000s is converging today into a single, self-reinforcing cycle: fewer students entering the field, fewer opportunities perceived to be waiting for them, and growing doubts about whether a technology career is still worth pursuing. But the parallel to those earlier declines carries a warning, not a reassurance, and the difference is in how each one ended. The recoveries of 2001 and 2016 happened because demand never left. In both prior declines, the supply of graduates fell while the underlying need for tech professionals rebounded. That gap between shrinking supply and steady demand is exactly what refilled the pipeline: scarcity pushed up wages, wages pulled students back and the market corrected itself, however slowly. What makes today different is that supply and demand are falling together. If leaders are correct that AI will replace entry-level work, this is not a demand dip waiting to rebound, it is a demand replacement, with no scarcity signal to trigger the correction that saved the field twice before. The most dangerous feature of a talent pipeline is its lag. The decisions made, or not made, over the next few years will not trigger a crisis next quarter or even next year. Their consequences will surface a decade or more from now, when today’s would-be entry-level personnel should have become tomorrow’s architects, technical experts and leaders. By then, the shortage will already be baked into the pipeline. And that is not speculation. It is the exact pattern the historical record has already shown us, twice. ## What is a technology leader to do? It would be easy to read my survey results and conclude that the market will sort itself out. Nearly half of the IT leaders I surveyed plan to hire fewer entry-level computing graduates over the next five years. Many dismiss this: education will adapt, five years is an eternity and better tools will make new graduates more capable than ever. They may be right. But hope is not a workforce strategy, and the leaders best positioned five years from now will be those who treat this as a problem to solve, not a trend to watch. The uncomfortable truth is in one respondent’s warning: “We will have to find a way to invest in new grads, or we will not have a pipeline of middle and senior talent later.” If every organization cuts entry-level hiring because AI now handles the routine work, our profession will slowly stop developing the senior engineers it will desperately need a decade from now, because senior people are simply junior people who were given room to grow. No single leader can solve this problem, but every leader can refuse to be the one who lets it happen to their organization. That starts with treating early-career hiring as a strategic investment, not the first line item to cut. Set aside several junior roles intentionally as an investment in your future leadership, rather than as just headcount to cut in the upcoming budget cycle. It also means redefining what “entry-level” even means. Survey respondents were consistent: the bar is changing. They want applicants with a strong portfolio over a strong transcript, demonstrable AI fluency over rote coding, and, in the words of one, “people who can ask the right questions” now that AI supplies the answers. Rewrite your junior roles and interviews around critical thinking and judgment, and recognize that a new graduate’s value now lies in growth potential and the ability to direct AI-assisted work, not raw output. Finally, the talent pipeline begins with encouraging high school students to seriously consider a career in technology, and guiding them will take all of us. If history holds, many will steer away from computing if they believe it has no future. Before committing to an investment as large as four years of tuition, parents will point their children toward fields with steady or rising demand. Technology leaders and their teams can cut through the hype and help students understand what a career in technology looks like in the age of AI. Through classroom talks and on-site job shadowing, they can give students a real chance to discover the opportunities computing offers. Through mentoring and hands-on, real-world projects, they can support STEM programs at both the primary and secondary education levels. With the aid of other technology professionals and leaders, I have developed a directory of organizations that promote and support careers in computing across the globe. The directory, which can be found at impactfultechnologyleader.com, includes: * Programs for grade school, high school and university students * Support for working professionals, whether already in tech or breaking into it * Groups serving those transitioning from the military, returning to work or navigating any other path Every one of us in this profession got here because someone decided we were worth the investment before we had proven it. That decision was never really about what a junior professional could contribute on day one. It was a bet on who they could become. AI may change what that first job looks like, but it doesn’t change a fundamental truth: to become a senior technology professional, you first had to be a junior one. The leaders who understand that over the next five years won’t necessarily be the ones who predicted AI correctly. They’ll be the ones who understood that some risks are worth hedging against even when you can’t be certain, and that a talent pipeline, once broken, takes a decade or more to rebuild. The question isn’t whether the pipeline is at risk; it’s what you will do to make sure it doesn’t break.

I’ve seen organizations reach a point in a modernization program where the technology itself is no longer the biggest risk. A decision was made for a full rip-and-replace. The new environment is ready. The migration plan has been tested. The business case has been approved. But the team responsible for delivering it is also responsible for keeping the existing estate running. A change freeze is approaching; business units are nervous about the cutover and what started as a technology upgrade has become an exercise in managing operational risk. That is the uncomfortable reality behind many large-scale modernization programs. We often make assumptions that legacy infrastructure is the problem and replacement is the solution, but in practice, rip-and-replace can create as much disruption as it removes. So rather than asking — what do we need to modernize, CIOs should be asking a more practical question — what needs to change right now? Do we really need to change everything? The reality is, there is only so much an organization can take on at once. AI is demanding investment and attention, workplace technology is changing, security expectations continue to rise and the existing estate still must keep running reliably in the background. All those priorities are competing for the same budgets, infrastructure and crucially, the same people. Modernization shouldn’t mean replacing technology simply because it is getting older. It should mean focusing time and investment where change will make the biggest difference. ## Modernization needs triage, not a starting gun With legacy technology, age is usually the trigger for change. A platform reaches a certain point in its lifecycle, an OEM support deadline approaches or a newer alternative becomes available, and replacement can start to feel like the obvious next step. But the age of an asset doesn’t necessarily tell us whether it is still doing its job, or whether replacing it is the right decision. A better approach is to assess infrastructure against four things: performance, risk, business value and future requirements. Is it still delivering the performance the business needs? Can it be operated securely and reliably? Does it support a business-critical workload? And will it be capable of supporting what the organization expects to do next? A piece of older infrastructure might be stable, well understood and supporting a workload whose requirements have barely changed. If it can continue to be monitored, maintained and supported effectively, replacing it may deliver little additional business value. But another system of the same age might be approaching capacity, difficult to secure or be preventing the business from adopting a new application or operating model. That is a very different modernization case. This is why CIOs should start to move away from thinking about estates in terms of “legacy” and “modern”. The more useful distinction is between infrastructure that is still fit for purpose and infrastructure that is becoming a constraint. ## The real constraint may be your people Modernization is often discussed as a capital allocation problem, but the harder constraint is often technical capacity within the organization. The same infrastructure teams tasked with migrating workloads, introducing new platforms and supporting transformation are usually responsible for the day-to-day estate. They cannot simply stop patching systems, responding to incidents or maintaining availability while a two-year modernization program takes place. If a team spends six months replacing infrastructure that could safely have remained in service for another two years, what did that team not work on during those six months? That question is becoming much more important since AI has arrived as another major infrastructure demand. Organizations are trying to understand where AI fits into their technology strategies while dealing with practical questions about compute capacity, GPU-intensive workloads, data availability, networking, power and cooling. The physical demands behind that AI expansion are significant, with the International Energy Agency (IEA) expecting AI to be the biggest driver behind its prediction that global data center electricity consumption will more than double to around 945 TWh by 2030. And none of this replaces what came before it. AI infrastructure is being added on top of estates that still support ERP platforms, databases, storage, customer applications and everyday business operations. CIOs have to create room for what comes next, without destabilising what the organization already depends upon. With so many competing demands, replacing infrastructure unnecessarily becomes harder to justify. Extending the lifecycle of infrastructure in one part of the estate can release budget, skills and operational capacity for AI or another strategic priority elsewhere. But the same principle also works in reverse. CIOs should not preserve technology simply because replacing it is difficult. If an existing environment can’t accommodate the organization’s future requirements, the case for modernization becomes much stronger. The decision is about where change is worth the disruption. ## Modernization doesn’t stop at the data center Modernization also needs to recognize that the way people use technology has changed. Employees are no longer accessing systems from one place, on a device owned and managed by the business. They might be working from home, a customer site, an airport or a shared workspace, using a corporate laptop, a smartphone or even their own device. The infrastructure itself might still be working perfectly well, but the way people are accessing it can introduce new risks that weren’t there when it was first put in place. BYOD is a good example. Giving employees greater flexibility can make sense from a productivity and user-experience perspective, but it can also leave organizations with less visibility and control over the devices accessing corporate systems. Verizon’s 2025 Data Breach Investigations Report found that, among compromised systems containing corporate logins, 46% were unmanaged devices that also contained both personal and business credentials. That does not mean BYOD is the wrong decision. It means workplace modernization needs the same kind of triage as infrastructure modernization. What information does the employee need to access? From which device? How much confidence do we have in the identity of that user and device? What happens to corporate data once it reaches an endpoint the organization does not own? Modernization cannot simply be a hardware refresh program. Sometimes the server doesn’t need replacing, but the access model does. Sometimes the application remains perfectly capable of supporting the business, but the security controls around how people connect to it need to evolve. And sometimes a modernization program should focus on identity, endpoint management, monitoring or access rather than migrating the workload itself. CIOs can use a relatively simple decision test when thinking about these choices. First, what problem are we trying to solve? If we can’t articulate that without referring to the age of the technology, the case for replacement probably needs more work. Second, what happens if we do nothing for another 12, 24 or 36 months? That exposes the difference between genuine risk and an arbitrary lifecycle milestone. Third, can we reduce the risk without replacing the asset? Better monitoring, maintenance, security controls, capacity upgrades or changes to access may sometimes achieve the desired outcome with far less disruption. Fourth, does retaining this technology constrain something the business genuinely needs to do next? AI, new digital services, workplace transformation and changing security requirements can all alter the answer. Finally, where would our people create the most value? Every modernization project consumes engineering time, operational attention and organizational energy. Those resources should be treated just as carefully as the capital budget. None of this is an argument against modernization. It is an argument for being much more deliberate about it. The CIO’s job is not to build the newest possible estate. It is to create an environment capable of supporting the organization securely, reliably and efficiently while remaining adaptable enough for whatever comes next. Sometimes that requires replacing technology. Sometimes it means evolving it. And sometimes good modernization starts with having the confidence to leave something alone.

Many IT leaders still struggle to find ROI when deploying AI agents at scale, but a few IT sweet spots are emerging as use cases that can provide CIOs tangible cost relief. Rhonda Baldwin, CIO at LaunchDarkly, says coding agents and service desk agents are helping the SaaS provider cut IT costs. “Coding agents increase engineering capacity without requiring a proportional increase in headcount,” she says. “They also help us optimize cloud costs and reduce workflow consumption costs.” In addition to coding and cloud cost optimization, IT leaders see tier 1 and 2 IT support as another promising area for agents to free up IT budget, although many have just begun to track savings from AI agents, and those that do use several different metrics. For Baldwin that includes cost avoidance, as coding agents have helped the company build internal tools rather than buying additional software, she notes. Here, the savings have been substantial, she says, with the company foregoing about $1 million in spending on two optimization projects and another $120,000 by building its own enterprise asset-management solution with AI coding tools. In addition, LaunchDarkly has saved about $50,000 in annualized savings by using agentic AI for tier 1 IT support. “This not only boosts employee productivity but also helps us avoid costs related to software, implementation, asset management, and having remote service technicians,” she says. ## IT support and self-service resolution IT support is a strong use case for IT leaders looking for agent cost savings, says Gil Pekelman, CEO of AI agent provider Atera, whose company recently released a joint study with Forrester claiming significant ROI for its IT incident support agent. “The calculation is very straightforward,” he notes. “We have a company that has 10,000 employees, and all IT support is offshored. If they’re going to close that down now, they can immediately measure the savings there.” Kevin Rooney, CIO at West Monroe Partners, reports significant savings for the digital consultancy through just such a deployment. Now, employees can an internal IT and HR support agent in Teams or Slack to get answers to common questions, request software access, reset passwords, unlock accounts, submit and update tickets, or connect with a live support professional when needed, he says. “By handling high-volume, repeatable requests and improving ticket intake and routing, it helps our IT team spend more time on complex issues and higher-value work,” Rooney adds. West Monroe is evaluating the impact of the agent in terms of self-service resolution, ticket volume, response time, and capacity savings, but it has driven a 40% reduction in yearly managed service provider costs, he says. The bot has also led to an estimated operational time savings of 2,700 hours per year, he adds. ## Cost savings in the cloud Matthew Wallace, co-founder and CTO of KamiwazaAI, has also found major IT savings from agentic AI. The Ai orchestration platform provider uses agents in several areas, including software engineering, project management, data science, and systems engineering. Cloud optimization is another area where the company is saving money by using agents, he adds. “We have a set of agents that monitor new systems in the cloud, coordinate with those turning them up, and coordinate budget approvals, with an easy way to shut down unauthorized spend and log it,” he says. That agentic system has replaced a function that required a high amount of human coordination and attention, he notes “You have to check and understand who set it up, when, what the cost is, whether it has internal approval, and various details about resource sizing, placement, etc.,” he explains. “Later, you have to check whether someone has responded with information and whether anyone in management has offered an approval or rejection.” The first round of cloud optimization agents that Wallace’s team deployed cut cloud spending by 70% immediately, he says. ## Check the numbers However, Jeet Pattanaik, founder and CTO of AI-base solutions provider Glokal AI, says some organizations are inflating their IT savings from agentic AI because they’re not measuring all the costs. While he believes some IT leaders are finding real savings, they’re often smaller and slower than advertised, he says, noting that in reality most organizations are still hunting for ROI. “The pilot always looks great because it runs on the easy tickets,” Pattanaik says. “Then, production brings in all the odd cases, and somebody has to check what the agent actually did. That checking is what quietly eats the savings, and it almost never shows up in the business case.” He sees tier 1 support — password resets, access requests, answering questions already in the documentation — as the place where organizations are saving IT budget using agents. “The sweet spot is work that’s high volume, well documented, and cheap to undo if the agent gets it wrong,” he says. “Tier 1 fits that nicely. Tier 2 only partly. Anything that changes someone’s permissions or touches production systems isn’t ready yet, because one bad action there can cost more than a thousand good ones save.” IT leaders deploying agents for IT support should keep an eye on how often tickets get reopened, Pattanaik adds. “A ticket the agent closed isn’t always a problem solved,” he says. “If people keep coming back with the same issue, you didn’t save anything, you just pushed it down the road.” He gives this example: A service desk handles 10,000 tier-1 tickets a month at about €15 each. The agent closes 40% of them, which, on paper, saves €60,000 a month. But if 15% of those come back reopened, that’s €9,000 of work returning to humans. Add around €15,000 for people checking what the agent did, and the real cost reduction is closer to €36,000, about 60% of what the pilot promised. There’s also a cost to eliminating workers focused on tier 1 support, he adds. “One cost nobody seems to count: Tier 1 is where people learn the job,” he says. “Automate all of it, and you lose the path that turns juniors into your future senior engineers.”

In one stretch last year, several executives at the same level in one organization each told me, separately, that the hardest part of their job was talking candidly to each other. Each had spent 15 to 25 years in technology, and none of them was struggling with the technology. I’ve coached more than 1,000 technology professionals one-on-one, and a large share of my practice is now CIOs, CTOs and VPs of engineering and product. AI is supposed to be freeing these leaders from operational work so they can spend more time coaching, giving feedback and working through conflict. What I see instead is that AI is raising the bar on people leadership faster than most senior IT executives can learn to clear it. ## AI hasn’t lightened the load for the IT leaders I coach My clients tell me the relief AI promised hasn’t arrived. They’re expected to produce more, they’re in meetings most of the day and the person above them often doesn’t see how much work the new AI output takes. Several now have a half-dozen AI agents running in the background on top of their existing responsibilities, and nearly all of them oversee teams that do. The agents didn’t replace work. They simply added another layer to supervise, which is one reason so many senior IT executives are burning out without telling anyone. The research matches what I hear. Microsoft’s 2025 Work Trend Index special report found that 52% of leaders say their work feels chaotic and fragmented, and one in three employees said the pace of work over the past five years has made it impossible to keep up. Deloitte’s 2026 Global Technology Leadership Study, which surveyed more than 660 senior technology executives, found that 41% report their organization sees them as unable to keep up with demand. AI is also creating decisions that didn’t exist a few years ago. One engineering leader I coach at a large tech company co-leads an organization of a couple hundred people with his product counterpart. The two of them now receive a monthly budget of AI tokens and have to decide together how to allocate them across their teams. That’s a negotiation between peers over a scarce resource, and it lands directly on the skill most of my clients tell me they struggle with. The leaders I interviewed for this piece described the same split. Yogesh Joshi, senior vice president of global AI platforms at TransUnion, said AI is accelerating the product development lifecycle at his company, but that “it does not create trust, resolve conflict, develop talent or align teams around shared goals.” Diya Jolly, chief product and technology officer at Xero, said AI can draft a product requirements document or scaffold production code in minutes, but it can’t “own the hard tradeoffs, like do we build feature A or B?” That’s how AI exposes weak people leadership. When it absorbs the technical work, what remains is the people work, and the people work is where many senior IT leaders have had the least practice. ## Difficult conversations are the gap I see most often The executives I described at the start weren’t unusual. Most of the CIOs and VPs I coach struggle with some version of a hard conversation, even though they’ve been leading for decades. Some can’t give their CEO tough feedback. Others put off telling a direct report they missed the mark. The most common, and in my experience the hardest, is the conversation with an executive peer. Product and engineering are where I see it most. One client, a senior engineering leader, held off for months on a conversation with his product counterpart about who owned the roadmap and who decided which features got prioritized. He shared with me that he was worried about stepping on the other executive’s toes. When the two of them finally talked, the conversation was awkward, but they got aligned, and the conversations that followed got easier. Marketing shows up in these disputes too, though in my experience those conversations tend to be less heated. Breno Oliveira, CTO at Strider, described a version of this from early in his leadership career. Not long after stepping into a new role, he felt he had to give feedback about a close teammate’s performance on a project, but he held off. “Delaying the hard conversation was a mistake, it cost a few more weeks of misalignment,” he said. “The actual conversation turned out to be far easier than the versions I planned.” Part of the reason these interactions seem scary is where these leaders came from. Many built their careers in roles where having the right answer was the job. Paul Farnsworth, president and former CTO of Dice, put it this way: “Technical expertise may help get you into a leadership position, but succeeding in that role depends on fundamentally understanding business priorities and communicating with people who have very different perspectives and objectives.” Few of my clients were ever trained for that second half. Gallup’s 2026 State of the Global Workplace report notes that few managers have natural management talent and many haven’t received the training they need to coach their teams. The same report found manager engagement fell from 27% to 22% between 2024 and 2025, the largest year-over-year drop Gallup has recorded. AI won’t fix any of this. It takes over the technical work these leaders were good at and leaves them with the conversations they’ve been avoiding. ## What I coach IT leaders to do instead When a client is dreading a conversation, I start by asking what they want out of it. Why does it matter, and what does a good outcome look like? Technical leaders often go into a conversation wanting to convince the other person of their point of view. They want to give direction or advice. I ask them to set that aside and think about what they need to learn. Then I have them go through their calendar for the day. For each meeting, they write down one, two or three questions that will move the conversation or the decision forward. Many of my clients now do this daily, the evening before. Some print their calendar. Others work through it on screen, one meeting at a time. The prep shifts from a page of talking points to a handful of questions, and they make more progress in the room because they’re listening instead of trying to convince. The leaders I interviewed use similar approaches. Farnsworth, the Dice president, said he used to get flustered in difficult one-on-one conversations with the people he managed early in his career, and he learned to write down his key messages beforehand so he could stay focused and communicate more clearly. Joshi, the TransUnion executive, said the best leaders he knows “spend less time giving answers and more time asking questions,” and he advises rising IT leaders to treat coaching as a skill that requires deliberate practice. Jolly, the Xero executive, said she had to start fiercely protecting her calendar to carve out thinking time, and she advises leaders to hire people who can do their jobs without them. I also remind clients that having hard conversations is a skill, and skills improve with reps. The engineering leader with the token budget didn’t get better at negotiating with his product counterpart by reading about negotiation. He got better by having the conversation, debriefing it with me and having the next one. The market has already noticed. CIO.com reported earlier this year that companies hiring CIOs in 2026 want a business transformation officer with a technical pedigree and high emotional intelligence, and that relationship skills matter more than ever. AI isn’t coming for the CIO’s job. It’s coming for the part of the job that used to hide weak people skills behind strong technical delivery. The leaders who will thrive are the ones who treat difficult conversations as core work rather than an interruption and start practicing before the exposure arrives.