As a leader, you’ve probably spent years nudging your managers to create psychological safety. After all, organizations benefit greatly when it feels safe to challenge the boss, surface bad news early, and say the uncomfortable thing before it becomes the expensive thing.

The Space Shuttle Challenger disaster of 1986 has become the canonical warning. Engineers raised concerns about the O-rings used in the solid rocket booster before launch. Their warnings were overruled by managers under schedule pressure. Seventy-three seconds after liftoff, seven astronauts were dead. The lesson still holds: When people are afraid to speak or are pressured to comply, organizations miss what they already know.

AI, however, is introducing a complication most leaders haven’t accounted for. Your employees now have another place to speak, and emerging research suggests they may be more willing to challenge a machine than a human leader, while another body of research challenges our assumptions about psychological safety itself.

Put those together, and you’re no longer managing psychological safety only between people. You’re managing it across people and machines, and the two may tell you very different things about your organization’s health.

Safety needs accountability

Psychological safety became popular for good reason: Teams perform better when people can admit mistakes, question assumptions, and challenge authority without fear of it following them into a performance review. But here’s the misconception: Psychological safety and accountability sit at opposite ends of the same dial. Turn safety up, the thinking goes, and standards come down. They don’t. The strongest teams have both; people feel safe enough to challenge one another and accountable enough to deliver.

Researchers studying five workplace settings, from hospital nurses to knowledge workers to four years of sales data across 229 retail stores, found that the relationship between psychological safety and performance wasn’t simply linear. At high levels of psychological safety without matching accountability, performance on routine work could decline; collective accountability substantially buffered that decline. The problem wasn’t that people felt too safe; it was safety operating without another ingredient the team needed.

A newer conceptual paper helps explain why. Psychological safety lowers the interpersonal risk of speaking up, which is what you want, but safety alone doesn’t create the discipline that keeps a team sharp: preparing for meetings, thinking carefully before weighing in, and taking shared norms seriously. That discipline comes from accountability.

Aviation offers a useful analogy. Sterile cockpit rules eliminate nonessential conversation during critical phases of flight, not safety-critical challenge. If something is wrong, you still speak. What changes isn’t how much psychological safety is allowed. It’s how tightly decision rights, operating discipline, and accountability are enforced.

Your AI pilots and early experiments need maximum candor. A junior engineer questioning a model or vendor claim should have every opportunity to be heard. Once a decision moves into production, incident response, or customer-facing execution, accountability tightens. Psychological safety doesn’t go down; accountability goes up.

Culture won’t automatically make people trust AI

Here is another set of assumptions in this area for IT leaders to challenge: that inclusive leadership, meaning leaders who stay approachable and treat employees’ input as worth acting on, builds psychological safety, that psychological safety makes people comfortable with AI, and that comfort with AI drives adoption. The evidence is messier.

One recent study found that inclusive leadership did improve psychological safety, but psychological safety itself did not significantly predict trust in AI. What mattered more was an individual’s ability to tolerate uncertainty. That matters because AI adoption is an uncertainty event: Capabilities shift every few months, outputs can be confidently right and impressively wrong, and the impact on jobs, workflows, and careers remains unclear. Employees are being asked to exercise judgment around systems whose behavior is probabilistic, not deterministic.

Another study of employees in South Korea found that AI adoption was associated with lower psychological safety, which in turn was associated with greater employee depression. Ethical leadership, meaning leaders who are transparent and fair about what’s changing, softened that relationship but didn’t eliminate it. Neither study is universal proof — different countries, samples, and methodologies matter — but together they raise an important question for CIOs.

A healthy culture may help people absorb the disruption AI creates without necessarily making them trust the technology itself. Those are two different problems. One is organizational: Do employees believe they can question what is happening around them? The other is psychological and technical: Can they work productively when the tool is probabilistic, and do they know when to trust it, challenge it, verify it, or ignore it? That requires more than another culture initiative. It requires AI literacy, judgment, and comfort operating under uncertainty.

Your people may be honest. Just not with you.

A 2026 series of scenario-based experiments with participants in China found that employees were more willing to voice concerns to an algorithmic leader than a human leader during cognitive tasks. Perceived fairness and psychological safety helped explain the difference. That doesn’t mean employees want robots for bosses — the effect didn’t hold in the same way for emotionally charged situations — but for analytical work the finding is worth paying attention to. One possible explanation feels remarkably human: An algorithm can’t embarrass you at the next staff meeting, downgrade your reputation with the executive team, or remember that you challenged its favorite project six months ago.

Now think about what happens as generative and agentic AI become embedded in everyday work. Somewhere in your company, an engineer may tell an AI assistant that the proposed architecture is flawed, explain why, work through three alternatives with the model, then walk into a meeting an hour later and nod along while a senior leader advocates for the original design.

The concern existed. The organization just never received it. AI didn’t suppress the dissent; your management system did.

You’ve created a psychologically safe chatbot sitting inside a psychologically unsafe org chart, and your AI adoption dashboard will never show you the difference. Both employees look like successful AI users, one using AI to accelerate work, the other using it as the only place they feel comfortable saying what they really think. Usage looks identical. Organizational health doesn’t.

We spend a lot of time asking whether employees trust AI. We may need to spend just as much time asking whether they trust people enough to repeat what they already told it.

What only you can fix

First, keep psychological safety constant and let accountability flex by phase. Push for aggressive challenge during strategy sessions, architecture discussions, AI pilots, and early experiments, and make disagreement cheap before decisions get expensive. Once execution starts, tighten decision rights and expectations without closing the channel for legitimate safety, ethical, or operational concerns.

Second, stop measuring psychological safety only through sentiment. Ask whether dissent changes decisions: what major initiative was redesigned because someone challenged an assumption; what AI pilot was narrowed, delayed, or killed because someone surfaced a risk early; what executive decision changed because somebody several layers down challenged the prevailing view. If nobody can remember one, another engagement survey isn’t going to tell you much.

Third, build a path for concerns raised to AI to reach the human decision system. That doesn’t mean reading employees’ private AI conversations; doing that would create exactly the surveillance problem that destroys candor. Instead, design mechanisms that let employees elevate a concern without reconstructing it from scratch: an anonymized escalation channel, a prompt-to-retrospective workflow, a mechanism to flag questionable AI outputs, or a structured path from an AI conversation into an architecture or investment review.

The design question is simple: Can an employee move a concern discovered in an AI conversation into the organization’s decision process with one deliberate action? Increasingly, that’s where the concern may show up first.

None of this argues against psychological safety. It argues against assuming psychological safety works in isolation, or that human trust and AI trust are the same problem. AI is creating a second conversation inside your organization, one that happens in meetings, reviews, and Teams calls, and one that happens quietly between an employee and a machine.

The real question isn’t whether your employees trust the AI. It’s whether AI has quietly become the place where they say the things your organization most needs to hear.

Second Opinion offers technology leaders an evidence-based perspective on their most consequential decisions. Khalid Kark brings 25 years as a trusted advisor, researcher, and operator. In an enterprise technology market crowded with noise, this column separates signal from spectacle.

By 2027, competitive advantage may depend less on which AI model a company uses and more on how effectively it redesigns its business around AI agents.

The software engineer starts his day by going through the changes made by a team of agents for coding using AI. The finance executive gets a report that contains exceptions in different financial systems and supporting information along with corrective suggestions. The procurement manager reviews supplier risks and recommendations regarding contract renewal for those suppliers after an analysis performed by the AI agents of pricing, deliveries and contracts.

For years, enterprise AI competition focused on model intelligence, including reasoning, coding, context windows and content generation. These capabilities remain important, but the next phase will depend on whether AI can perform substantial parts of business processes rather than simply assist employees with individual tasks.

As OpenAI, Anthropic and other frontier AI companies advance agentic capabilities, enterprises face a strategic decision. Should they use AI to make existing processes marginally faster, or should they redesign those processes around a new relationship between human judgment and machine execution?

By 2027, that distinction could separate companies that experiment with AI from those that translate it into a durable economic advantage.

Software engineering becomes an orchestration problem

Software development provides one of the earliest examples of this kind of evolution.

AI coding assistants have evolved from generating snippets and explaining code to working across repositories, proposing changes, running tests and supporting refactoring. Anthropic’s 2026 agentic coding research describes the progression toward more collaborative and autonomous development workflows.

From my firsthand experience working with Claude Sonnet to facilitate application modernization, I gained a realistic viewpoint on this transition. The process of modernizing a legacy application requires more than just converting old code to a new environment. It means comprehending the current business logic, pinpointing all the existing dependencies, maintaining the previous behavior and ensuring that suggested changes are valid for the entire application. I used Claude Sonnet to help with the modernization and explore approaches for implementing it and to accelerate the code-related work, but kept all the technical decision-making and validation under human control.

This experience once again emphasizes an essential point – AI can speed up some parts of modernization, but it cannot substitute engineering judgment completely.

An attainable example of an enterprise use case by 2027 may be that of a software development team using various specialized agents to implement a business function. The different agents would be responsible for requirements analysis, proposing implementation modifications, generating tests, reviewing dependencies and finding security vulnerabilities.

The responsibility of the engineer does not vanish but rather moves into architecture, system boundaries, engineering judgment and production results.

Companies must, therefore, begin measuring something more than lines of code or the number of pull requests created by artificial intelligence. These measures include defects in production, how often new versions are delivered, recovery time, security discoveries and total costs of delivering a reliable change.

This competitive edge will belong to companies using agents plus sound engineering practices, not companies creating code only.

Enterprise software moves from screens to outcomes

A second paradigm shift relates to the enterprise software paradigm itself.

Almost all corporate applications are built on screen navigation, forms, dashboards and workflows that humans interact with manually. Even where different systems are tightly integrated, humans typically form the glue that connects them by transferring data, assessing conditions, seeking approval and updating records.

AI agents can potentially transform this paradigm.

Consider the sales operations agent that spots a customer account at risk, analyzes its service history and contract terms, develops a retention strategy and creates a series of follow-up actions within the customer relationship management system. The human account manager evaluates the proposal and commits the company to the plan.

OpenAI’s enterprise agent initiatives reflect the industry’s movement toward agents connected to enterprise context, business applications and governed execution.

But should this approach reach maturity, the worth of enterprise applications might shift from what users can achieve using them to how effectively users can use their interface.

Systems of record—including accounting ledgers, customer databases and transactional applications—will remain essential for data management and business controls. Agents may become an execution layer above them, retrieving information and coordinating activities while underlying platforms preserve data consistency and enforce business rules.

It would be essential for software vendors to develop reliable application programming interfaces, agent-enabled interfaces, fine-grained permissions and auditable actions. Enterprises would have to consider whether their applications are automation-friendly or too dependent on human interventions.

The larger commercial question is whether value remains concentrated in software licenses and user seats or increasingly shifts toward outcomes, completed workflows and measurable business results.

AI agents at work: finance

Financial activities provide examples of how AI can be applied in the field of processes that have financial and regulatory implications.

Specific examples exist in the banking domain, where AI is being used to classify and route numerous client inquiries and assist humans in accessing pertinent data. In this way, AI is assisting financial activities and the decision-making process at the same time.

In the same way, AI agents could be used to match transactions, identify financial differences, analyze effects on cash flow and create management reports. People would take care of exceptions and make the decisions themselves.

This limited autonomy system gives an idea of how AI can be useful in finance.

Reference: How a global bank scales Claude across its operations — Anthropic

The new operating model: humans supervise execution

With increased responsibilities assigned to agents, the way teams are organized and managed would have to change.

In a typical company, accountability is distributed among various positions, departments, levels of approval and applications. People do the job, managers manage and controls are used to decide whose decision is required at each step of the work.

A new actor appears with agent-technology: the software which is able to plan and perform some tasks of the work but not necessarily to make independent business judgments or be accountable for the process.

This presents a completely new problem for managers. Whose responsibility is the result of the work when there are several agents involved? Whose fault is the mistake in the decision based on old information?

By 2027, businesses may come up with ways to clearly define ownership for work done by agents. The outcomes and risk tolerance will be defined by management; technology staff will be responsible for integration and reliability; risk and compliance teams will set the controls; while the rest will handle exceptions and critical decisions.

Management must measure agents by business outcomes—not deployment counts—including processing time, accuracy, rework, productivity and customer impact.

They have to think about the total cost of running a workflow, which includes not only model use but integration, monitoring, security, human verification and remediation.

A process that looks cheap because of automation may be expensive if there is a lot of verification needed or it keeps failing at handling exceptional cases.

Trust and data quality become competitive infrastructure

More advanced agents will not solve the historical problems associated with enterprise data. Some may even make them worse.

An agent analyzing a supplier, approving a transaction or proposing a financial correction will have the need for accurate information, appropriate rights and an understanding of the corresponding business rules.

If the client data is inconsistent across systems, the contract clauses are obsolete or the necessary data lacks proper context, the agent may come up with a compelling conclusion based on an incomplete set of facts.

Therefore, enterprises must include data quality, application integration, identity management and observability as key elements of their AI strategy.

Enterprises need input validation, access controls, audit trails, workflow testing and clear approval limits. Summarizing a report is different from changing a production system, just as preparing a payment is different from releasing funds. Appropriate autonomy depends on risk, reversibility and the ability to detect and correct errors.

This infrastructure may not attract the same attention as a new frontier model, but it could determine which enterprises can deploy agents reliably at scale.

The real competition begins after the model is selected

The frontier AI race will remain important. Innovation by OpenAI, Anthropic and other model makers may make reasoning, programming, tool usage and task completion more effective.

However, corporations need not rely solely on picking the right model for their AI.

Results will depend on data quality, application access, workflow design and controls. Organizations should start with a valuable, clearly owned process, establish a baseline, introduce agents at selected steps and expand autonomy only when measured results justify it.

Strong integration and clear workflows will let organizations adopt improved models without redesigning operations around a single provider.

Organizations with disparate AI experiments, on the contrary, may find it hard to transform pilot projects into corporate success.

The key strategic challenge is to create an organization able to absorb the advances of frontier AI consistently.

The enterprise advantage of 2027

The future stage of AI evolution will not be defined just by intelligence. Rather, it will be defined by the interaction of intelligence, execution and organizational design.

The companies most likely to succeed in 2027 will not necessarily be the companies with the biggest budgets or early access to frontier models. They will be the companies that understand what tasks are fit to be automated, what decisions should stay human and how to link AI execution to their business systems.

In this light, the critical question that the modern entrepreneur faces is not merely: “What kind of AI technology should I use?”

The critical question is: “Given the fact that AI technology can do more of the work, how can I organize my business to add value?”

Museum IT departments have traditionally served as support functions to manage security and systems. But the National Museum of Korea goes further, identifying and pursuing AI initiatives to preserve cultural heritage, broaden its use, and improve the visitor experience.

The National Museum of Korea uses technology to expand the possibilities to preserve and display physical artifacts, and its digital museum division (DMD) plans and oversees that transformation. A dedicated team responsible for digital strategy and content took shape in 2019, and in 2020, the museum informatics division adopted its current name.

“The director at the time placed great importance on investing in technology and felt we needed a department that could bring a strategic direction to work that had been carried out separately,” says Choi Seungae, former DMD head. “The digital museum division was created as a way to prepare for the next generation.”

A cultural transformation

In just over five years, the DMD has delivered a range of services, including AI guide robots, smart kiosks, and multilingual and sign language services. It’s also developed immersive experiences that use large-scale imagery and sound to recreate cultural heritage.

More recently, its focus has shifted toward data. The aim is to move beyond storage and preservation, making data previously confined to the museum available for wider use. Physical artifacts face restrictions on movement and display because of security concerns and risk of damage. Digital data can help overcome those limitations.

One example is an immersive content project featuring the Denny Taegeukgi, Korea’s oldest surviving national flag, undertaken last year to mark the 80th anniversary of Korea’s liberation.

The project displayed images of the 130-year-old flag once held by Owen Denny, a diplomatic adviser during the late Joseon period, on a large outdoor media screen in front of a department store in central Seoul.

At first glance, the project might appear to have involved little more than photographing an artifact and displaying it. But it required highly detailed data since enlarging existing photographs would’ve produced visible pixelation on such a large display.

Therefore, the division created a new, ultra-high-res dataset containing 10.8 billion pixels at a two-meter scale from the original flag, which measures approximately one meter. Precision scanning captured even the fine texture of both sides of the fabric.

Plan of action

Earlier this year, the museum was selected for the government-led K-Science initiative, through which it plans to pursue data projects beginning in 2027. The cross-ministerial R&D program combines Korea’s historical, cultural, and environmental assets with advanced science and technology to create economic, social, and cultural value.

Through the initiative, the museum will digitize over 2.5 million artifacts and develop technologies to expand the commercial potential of Korean cultural assets. The central goal is to connect the entire process, from archaeological exploration and preservation, to digitization and content development.

The resulting technologies are expected to help overcome technical limitations in detailed surveys of ancient tombs, for example. In preservation and collection management, AI could also automatically control temperature, humidity, and lighting in museum storage facilities.

Never a single right answer

Data presents challenges across both private and public sectors. For museums, however, they’re particularly complex because artifact data contains layers of interpretation, facts, and history.

Consider an AI system designed to answer questions about a particular artifact. It needs data to support its responses. But what should it say if records from Baekje and Silla, two ancient Korean kingdoms, offer conflicting accounts of the same event. Ideally, it would adequately represent different perspectives, but that’s not always possible since the same artifact can tell different stories depending on who used it, when, and for what purpose.

Choi says current LLMs don’t adequately account for these layers of context. When users ask for an accessible explanation, models can produce answers that overgeneralize or oversimplify. Reducing an event with multiple interpretations to a single sentence can obscure or distort its context.

But ensuring accuracy is another challenge. According to Choi, historical discrepancies introduced during initial training can prove difficult to correct, even when a model is subsequently asked to revise them.

The DMD is, therefore, concentrating on building data with clearly identifiable sources. The aim is to let users verify if an AI response is based on material from the National Museum of Korea to assess its reliability.

With these characteristics of artifact data in mind, the division is working with external experts to redesign its database structures around both the nature of the artifacts and the purposes for which people use the data.

Upgrade with AI

Where earlier databases focused on registering and managing objects, the new approach seeks to capture their different meanings and relationships while making relevant materials easier to find. Images, 3D data, videos, and related literature previously scattered across separate records are being connected. Metadata describing file sizes, formats, and how the data was created are also being expanded to support reuse so linking different names for the same artifact makes searching easier, for instance.

“Cultural heritage can’t be standardized like manufactured goods,” Choi says. “We need to organize and structure the data and materials we’ve accumulated in ways that reflect the character of our artifacts, while at the same time, identify connections between them. Once that foundation is in place, curators and external users like content creators, researchers, and educators will be able to find and use materials suited to their needs.”

Leaving room for discovery

After nearly two decades spent researching artifacts and developing exhibitions, Choi didn’t expect to find herself working in the DMD. Now director of the Jeju National Museum, she looks back on her digital work where there were many times her previous experience alone couldn’t guide her decisions. Exhibitions have clear opening and closing dates, and experience helps curators judge what further research and preparation will improve outcomes.

Digital projects offer fewer such reference points, however. It can be difficult to assess how far an initiative has progressed, or anticipate how emerging technologies will affect work already underway. Even so, her expertise provides a foundation to decide where change should lead, and help propose ideas to assess what new tech serves the museum’s purpose.

“Whether it’s curatorial or digital work, I hope the many things we do at museums can make a small contribution to help visitors think for themselves and arrive at their own insights,” she says.

Every year, thousands of enterprise organizations walk into technology negotiations trapped by the same fundamental mistake: they negotiate a product instead of solving a problem.

Having advised over 2,000 enterprise customers annually on technology acquisition over two decades, I see this pattern play out daily. Purchasing committees meticulously list the specific features, software modules and server specs they think they need, converting their organizational requirements into a static shopping list. On paper, this strategy feels disciplined. It creates a standardized, predictable item that procurement can use to negotiate a line-item discount with providers.

When you buy a fixed product, you get the immediate, gratifying perception of a lower price. But that upfront discount can come at a hidden cost: you risk cutting yourself off from the disruptive innovation of emerging technologies like artificial intelligence (AI).

By prescribing the solution before the negotiation even begins, enterprises force vendors into the narrow role of commodity suppliers rather than strategic partners. You ask them, “How cheaply can you build what our internal committee specified six months ago?” instead of asking, “What is the most efficient way to achieve this outcome today using capabilities we might not even know exist?”

In an era where AI can reshape entire operational workflows, anchoring your procurement strategy to fixed product specifications means you may pay less for yesterday’s way of doing business while missing the value of new capabilities.

When procurement treats technology as fixed products, it tries to bundle mature products, such as software-as-a-service (SaaS) licenses, with rapidly evolving capabilities, such as AI services billed by token consumption, into one grand contract. You end up applying three-year static product licensing to AI capabilities that change on a monthly basis, locking your company into rigid pricing models and outdated technology.

A request for proposal (RFP) is the ultimate manifestation of product-first buying. It forces vendors to answer 200 static questions about prescribed features rather than offering alternative solutions. Procurement celebrates negotiating a 15% discount on a legacy customer service product, completely unaware that an outcomes-based AI approach could have eliminated 70% of the support tickets altogether. You win the unit-price battle, but lose the total cost of ownership (TCO) war.

Procurement departments use RFPs with the goal of driving down unit costs and reducing risk. But as behavioral expert Rory Sutherland has argued, corporate purchasing can prioritize blame avoidance over value creation. RFPs require the buying organization to specify the technical solution long before it enters a room with the experts who could help solve the original problem.

The RFP backfires in two distinct ways:

You force vendors to answer the wrong question

An RFP asks vendors: “How much will you charge to build what our internal committee decided we need six months ago?” It denies the seller the ability to say: “The problem you are trying to solve can now be eliminated using a new approach you haven’t considered.”

Shifting costs rather than reducing them

RFPs do not necessarily lower TCO; they can shift costs around while inflating administrative overhead. Software goes unused, becoming shelfware, because the focus was placed on winning the RFP pricing battle rather than user adoption and operational enablement. The company then has to spend more on adoption, while employees may turn to unsanctioned tools, known as shadow IT, duplicating costs and eroding the negotiated savings.

When enterprise buyers attempt to simplify procurement by bundling SaaS, infrastructure-as-a-service (IaaS) and AI into a single, multiyear contract with a hyperscaler, they can make switching providers harder. Research published by Harvard Business School on platform strategy explains how bundling can reinforce customer retention even when one component disappoints. Buyers need to evaluate the flexibility of each component, not just the combined discount.

A good example is what happened to one of my customers: an unmonitored script loop written by a developer unexpectedly burned through 18% of their annual infrastructure commitment in AI token consumption over a single weekend. By bundling emerging, unpredictable technology with stable infrastructure services, they exposed an otherwise predictable IT budget to financial volatility.

Buying technology correctly means matching the contract model to the technology’s maturity stage. Treating an emerging, fast-evolving space like AI with the same three-year static lock-in used for corporate email is a governance failure.

Another of my customers, a regional insurance company, issued a 200-question RFP to replace its customer service center software, seeking an AI-driven system to handle support tickets 20% faster.

Consider the limitations of that RFP: procurement issued a spreadsheet demanding details on call-center headcount, staff rotation rates and employee training certifications. An AI startup whose autonomous agent framework proactively fixes customer problems before a support ticket is even logged refused to participate because the questionnaire assumed a human workforce. The deal went to a legacy vendor that answered all 200 questions and offered a 15% discount. Procurement celebrated a price drop on seat licenses, even though it had just committed millions to perpetuating the existing operational model.

The buyer saved 15% on seat licenses, but spent $3 million over two years maintaining the call-center workflow. Had the company abandoned the rigid RFP, it could have eliminated 70% of its call volume entirely. Procurement successfully minimized the unit cost of the contract while missing the potential value of a different capability.

If we want to stop buying technology wrong, CIOs and purchasing committees must adopt three fundamental shifts:

1. Decouple contracts by maturity stage: Keep mature SaaS, optimizable IaaS and emerging AI in independent contractual structures. This preserves the flexibility to swap out emerging tools as better models hit the market without triggering financial penalties on core systems.
2. Replace rigid RFPs with proof-of-value (PoV) sandboxes: For disruptive technologies and services, replace prescriptive questionnaires with small, rapid experiments that allow vendors to prove outcomes. Define the business problem, success criteria, budget and security requirements before testing. Pay to solve the problem, not just to acquire the product.
3. Prioritize local enablement and FinOps over direct discounts: A 10% direct manufacturer discount means little if 30% of your cloud infrastructure is overprovisioned or if your employees never adopt the software. FinOps aligns technology spending with business value through collaboration among engineering, finance and business teams. Evaluate what your internal team or a multicloud partner can deliver in user adoption, local-currency billing, support for local tax requirements and ongoing cost management. Compare the full cost and return on investment (ROI), rather than the discount alone.

It’s time for enterprise leaders to stop managing technology procurement like a commodity auction. The goal of buying technology isn’t to get the lowest price on yesterday’s specs; it is to secure the greatest speed, flexibility and business value.

Imagine a salesperson getting ready for a customer renewal meeting. They need to find the original contract and review its terms. But the information is buried in CRM records and attachments, forcing them to search through multiple documents.

Now imagine they could simply type in their question and get the contract details in seconds. Contracts contain valuable business information, including pricing, payment terms, and past negotiations. AI for contract management helps teams find and use that information — and connects it to the work that follows, from reviewing terms to getting approvals and preparing for renewals.

Foundry’s 2026 State of the CIO research reports that 79% of CIOs are working more closely with business leaders on AI applications. Contracting is a practical place to put that collaboration to work: sales, legal, procurement, and HR all depend on contracts to move business forward.

Docusign is using AI-powered contract management across its own business through its Docusign Intelligent Agreement Management (IAM), its AI contracting platform. The goal is to connect contract information with everyday workflows while keeping people involved in decisions that require judgment.

“AI contract management helps our teams turn what’s inside contracts into action,” said Shanthi Iyer, CIO of Docusign. “Using our own IAM platform, we’re automating routine workflows so people can focus their expertise where it matters most — and stay in control of the decisions. That means less friction for our teams and a better experience for our customers.”     

How does AI contract management work?         

AI contract management combines AI capabilities — such as analyzing contract language and extracting important information — with workflows that help teams create, review, approve, sign, and manage contracts. For example, AI can help flag language that differs from company standards or find a renewal deadline, while connected workflows route the contract or task to the right person.

Docusign delivers these capabilities through IAM. For organizations with complex contracting needs, the platform includes advanced Contract Lifecycle Management (CLM) capabilities. Iris, Docusign’s AI engine built specifically for contracts, powers AI-assisted review, an AI assistant, and agents that help teams understand contracts and move work forward. IAM also helps organizations analyze past contracts to prepare for renewals and negotiate better terms.

By making contract data accessible within business systems, IAM helps employees find information and complete tasks faster. A 2026 study by Deloitte and Docusign found that organizations using AI and automated contract workflows saw average efficiency gains of 36%.

Deploying AI and contract automation across the enterprise

Docusign uses its AI and contract automation to help employees find contract information and act on it. Here’s how different areas of the business benefit:

• Sales: The sales team uses natural-language queries to find contract terms and deal history, reporting approximately 50% productivity gains and reclaiming 42,000 hours annually.
• Procurement: Finding supplier contracts now takes under one minute, compared with over eight minutes previously.
• Legal: The legal team uses AI-assisted review and playbooks to flag nonstandard terms, allowing attorneys to spend more time on negotiations.
• HR: Integrating IAM with Workday connects contractor statements of work to onboarding, helping HR get new contractors started with less manual work.
• Customer experience and partner operations: The customer marketing team collects speaker releases and consent forms through IAM, saving roughly 200 hours annually. Partner operations use IAM with Salesforce to initiate due diligence checks, saving 10–15 minutes per review.

What CIOs should look for in an AI contracting platform

Here are some questions to ask when evaluating an AI contracting solution:

• Can it support everyday workflows? Ask for a demonstration of a familiar task, such as reviewing an NDA, routing a sales contract for approval, or preparing for a supplier renewal. Examine how information moves from one step to the next.
• Does it integrate with existing systems? Check how contract data and tasks move between tools such as CRM, procurement, and HR systems — and whether employees can access them where they already work.
• Can it provide appropriate controls and visibility? Examine access permissions and review processes.
• Can you measure its impact? Track process completion times before and after implementation.

Turning contract intelligence into business advantage

CIOs should consider how AI contract management can help their organizations get more value from contracts long after they’re signed. Docusign’s experience demonstrates that contracts can become a valuable source of information for future business decisions.

Discover how Docusign’s AI contracting platform helps teams create, review, sign, and manage contracts—and put contract information to work across the enterprise.   

A LinkedIn post about my old company, insightsoftware, popped up the other day. It was lamenting the challenge of turning 29 acquisitions and close to 80 products into one comprehensive platform. I spent years in the middle of that work, and what I know now is how much harder that consolidation is than you might think, and how much of it you only learn by getting it wrong first. 

So, when I arrived at Veson in November and found a similar landscape, I felt a bit of déjà vu. A bit of “I’ve done this before, so I know what I’m doing” and a bit of “I’ve done this before and I know it’s no cakewalk.” Veson had spent the past several years acquiring a range of products like Shipfix and VesselsValue and now needed to consolidate them onto a platform alongside its flagship IMOS solution. A new variable is also now at play that changes the whole equation: the advancement of AI.

While AI may sound like a cheat code for this work, it’s very much a double-edged sword… with a grenade taped to it. 

Yes, we can do some things faster and differently than we ever could a few years ago. But we’re also learning as we go and upskilling our team as we go, on a technology that’s changing under our feet.

The newness of these tools multiplies the complexity in a way I didn’t fully appreciate at insightsoftware. Back then, the tools simply didn’t exist or were just emerging. Now your platform must transform so that it thrives in the age of AI. It has to be built in the age of AI, which — depending on whose study you believe — means anywhere from 2X to 10X faster.

And then your team needs to adapt to the age of AI, which again means faster, at higher quality and producing more output. That’s a lot of spinning plates, on top of each other, none of which you’re allowed to drop. 

Oh, and one other plate: this is a centuries-old industry that moves billions of dollars in freight a year and does not stop for anyone. You don’t get to tie the ship up at the dock while you rebuild the engine. Business continuity, zero migration, no breaking the thing people are already running their business on. And do it as fast as you possibly can. 

Building a connected, modern platform

At Veson we had a fleet, not a unified experience. A set of strong, separate hulls, each with its own data, its own experience, its own idea of the world. A collection of great products is not the same as a cohesive foundation, and pretending otherwise is a mistake.  I’ve been guilty of this myself: combining products superficially, so they sit side by side under one roof but still behave as separate entities, rather than as one integrated experience.

In fairness to my past self, before AI even that superficial stitching was slow, labor-intensive and risky, and it often used up the time and budget we’d meant for real integration. AI has worn much of that cost away. The plumbing that used to take months now takes weeks, which frees us to focus on what customers value most: products that work as one.

A platform, in 2026, is three things stacked in order. A singular data layer underneath. One experience on top. And then AI that can reason across all of it. You cannot bolt credible AI onto a flotilla; it has nothing coherent to reason over. The unglamorous work of unifying data is what makes the glamorous AI work possible. 

The part I’m most wary of talking about — because I would rather not tempt fate — is doing all of this safely. Moving fast on all fronts at once is a lovely thing to say in a strategy meeting and a dangerous thing to do in production. The mistake I’ve watched happen (and, if I’m honest, helped cause) is measuring efficacy too narrowly.

If you pick only a few metrics (that you know you can nail) and tell people that’s how they’ll be judged, teams will act accordingly. The side effects get ignored or missed until it’s too late. Often that side effect is quality, discovered downstream when it’s far costlier to fix, or market fit, because value was quietly descoped to hit a date. With AI coding agents accelerating everything, I wasn’t willing to repeat that. We needed 360-degree checks and balances.

The one thing I insisted on and set up from the first week with Veson was working with the engineering intelligence platform Plandek. We measure speed, quality, predictability and focus in real time, so we can see the progress we’re making and spot the side effects before they compound.

AI let us pick up the pace; comprehensive measurement is what lets us keep it without losing sight of the risk. As a result, we get to have our cake and eat it, we upskill the team while the ship is sailing.

Ten months in, here’s what we’ve learned so far.

Product lessons we’ve learned

• Don’t rebuild what already works. “Modernizing” something people rely on is the fastest way to destroy the value you paid for. 
• AI only counts when it functions inside a workflow people already trust. An assistant in a corner nobody visits is a demo, not a product. 
• Aim for a minimum lovable product, not a minimum viable one.
• Continuity is a feature. The moment a customer must “migrate” to your platform, you’ve lost them. 
• One source of truth beats five clever ones. Data you unify late is a tax you pay forever. 

Experiences from our engineering teams 

• Adoption will be uneven. Don’t force the sceptics; convert them with proof. 
• The job itself is changing from writing code to directing it — reviewing, steering and trusting AI as it writes, then verifying. 
• Spread what works peer to peer. A network of AI champions beats a mandate from someone who clearly hasn’t done the work. 
• Measure everything. 
• The fastest teams are the ones who trust the platform beneath them. 
• Faster is only a win if quality holds — protect the gates hardest exactly when the pressure to cut them is highest. 

I don’t think we’ve cracked the code on this. We’re in the middle of it, plates still spinning. But this time I’m making new mistakes rather than old ones, and I’m more convinced than ever that we’re doing this the right way.

For decades, CIOs have been challenging their organizations to shed one of the most persistent labels in our profession: order taker. Instead of waiting for the business to tell them what they want, technology leaders need to understand what the business is trying to accomplish, get invited into the first meeting, and earn the right to become a strategic partner. But in a fast-moving environment, is being a trusted advisor enough?

To reach the next level, top CIOs are increasingly transforming their IT organizations into what I call “innovative anticipators”: These IT orgs understand the business, customer, and possibilities so deeply that they can see around corners, anticipate what’s needed next, and create value before someone asks for it.

Janet Robertson, global CIO of RS Group, believes building that anticipation muscle isn’t simply about moving the IT organization to a higher level of maturity. Increasingly, it’s a business imperative.

For a recent episode of the Tech Whisperers podcast, Robertson and I explored the deeply human side of leadership: how trust goes both ways, how great leaders serve as a lighthouse when others are navigating through the fog, and how we prepare the next generation to lead in a world none of us has led in before. But hiding inside that conversation was another fascinating story to unpack.

RS Group is a global product and service solutions provider for industrial customers operating in 33 markets. Its journey has been remarkably similar to the one our IT profession has been making — from taking orders, to advising customers, to anticipating what they might need next. As Robertson evolves IT at RS into an innovative anticipator, the company as a whole is doing the same.

Two journeys, similar challenges. And as Robertson explains in the following conversation, strategic partnership may no longer be the destination for today’s CIO. It may be the starting point for what comes next.

Dan Roberts: You’ve said something that sounds simple but has enormous implications: There isn’t a technology strategy and a business strategy. There’s one business strategy. What changes in the way a technology organization operates when people genuinely believe that?

Janet Robertson: When the technology group is focused on an outcome, they’re looking at solving a business problem more than implementing a technical solution. That’s a nuance, but it’s really the most direct route to a solution, because they’re trying to solve a business problem and get a business outcome more than implementing a technology solution or a technology transformation. It’s a different mindset.

In practical terms, you end up with increased adoption because you’ve got buy-in from the business on the direct answer to the problem. You also end up with fewer bells and whistles — a solution that’s not gold-plated and that doesn’t have things you won’t need, which is more efficient, considering how fast things are moving today. Everything could be different.

In fact, we’re doing product development now as more of a continuous evolution using new, innovative tools that are available to us at each space. The days of planning a three- or four-year program are over. By the time you’re going live, the technology’s out of date, or the processes have changed, or the world’s changed around it. You’ve got to create solutions fast with the most direct available technology to support the business outcomes.

You can’t anticipate a business you only understand through dashboards. How do you get your technology leaders close enough to the work, the customers, and the people to see what they otherwise might miss?

I encourage my leaders to spend time in the everyday working life of the recipients of our solutions. Sit with some of our biggest customers and watch them place an order through our website. Sit with our middle- and back-office team and watch their process of paying an invoice, receiving an order, entering an order, processing an order. Go to the distribution center. Spend time with the people who are using your solution.

Our customer experience officer has been riding around with salespeople, experiencing what they are going through in a day-to-day environment. I’m going out to Milan, Italy, next week to open our new our automated warehouse there. I’m almost more excited about launching it and seeing what we’ve implemented in use than I was planning the program. I want to see the ship sail in clear waters.

When technology leaders spend the time doing this, they start to see the connection directly between what they’re putting out there and what actually has to take place. You get very different perspectives from different sides of the fence when you get hands-on. It’s less about KPIs and dashboards and the results out of the other end of it. It’s more about understanding who’s consuming what you’re producing and how you’re providing value to them. Because sometimes, their biggest pain point is something you put down as a priority 5, and it’s in the lowest level of the backlog, but would completely change their perspective, improve their experience, and drive value.

What have the best consumer experiences taught you about orchestrating a B2B customer experience that will continue to differentiate RS Group?

Our catalog is massive, and we’ve got so much to navigate. As a consumer, with the new developments you can go on to an Amazon experience and find anything you want using even cryptic keywords. Or you can go on to Google and find 20 different buying options. That is absolutely transformative for us, because a lot of our customers buy that way. They’re searching for something that’s maybe very specialized, so they expect the same kind of Amazon-type experience when they’re looking for a specialized manufacturing-line repair part.

For us in the technology space, it means we’ve got to make sure that our data and our foundations are prepared to enable those large language models for the AI and generative search for agentic purchasing. What’s a little bit different from the B2C space is that many of our customers are starting to implement agents to do a lot of their procurement. So we’ve got to be prepared on the receiving end of those agents to be able to place those digital orders. It’s not really an e-commerce, add-to-cart channel anymore. Now it’s a direct agentic experience in purchasing for our bigger customers that use agentic purchasing.

To lead the way on that is a huge differentiator, and we are aware of it, and we’re keeping an eye on it. We have to be able to move fast and pivot quickly. Who would have thought two years ago that we were going to be talking to agentic procurement?

For years, we’ve challenged IT organizations to do a better job demonstrating their value to the business and to become trusted advisors. How has your organization made that pivot, and what does the next evolution of that journey look like?

When I first joined RS, my department was seen as less of a technical advisor or an expert in new technologies and new ways of getting things done. We were seen more as order takers and a cost center, basically a necessary evil. The pivot we’ve gone through has happened by listening and engaging with the business to understand and help them articulate what problems they’re truly trying to solve. I say, “Please tell me the what, and let me and my experts provide you the how.”

It’s taken some time, honestly. That evolution from an order taker to a trusted advisor is a journey, because you’ve got to prove that you know what you’re talking about, that you’re up on the latest technology, you understand the latest tools, and you are thinking outside of the box — truly providing the vision and the art of the possible to a problem they don’t know how to articulate. The biggest driver for me is connecting my leaders and my team to the business in general. They’re out looking for tools to solve those business problems.

Now we’re starting to partner with our business partners to show them the art of the possible with some of the new trends that are coming, like agentic procurement and large language model search. SEO is gone; now it’s GEO, generative engine optimization. So instead of “Tell me your business problem,” it’s moving to “Let me tell you how to solve a problem you might not know you have yet. This is a way to anticipate what is probably coming down the pipeline, and it’s going to be a problem soon.”

Because we’re leading the way in talking to our business about where the future’s going in technology and customer search and customer analytics and data science, we’re being brought in to discuss these developing trends.

That level of anticipation requires intelligence, or what you’ve described as “intelligent automation.” What’s involved in building that kind of anticipation engine?

Just like you can’t expect a 300-year-old house to be a smart house overnight, you can’t turn a 100-year-old business into an efficient, highly data-connected enterprise overnight. We know that we’ve got some legacy plumbing that we need to repair, and we are well into that journey now. We know that the data we have is incredibly valuable, but we need to understand how to use it, how to interrogate it, and how to get the right answers out of it. Without a structured format, and without all the speed and the pipes and efficient use, we can’t take advantage of that.

Bad data and a bad foundation only accentuate bad decision-making from the data. If you put a lot of intelligence over the top of an unstructured or bad format and foundation, you get really bad data to make decisions from, and it just makes it that much worse. So sometimes you have to build a little bit of a foundation before you’re able to just run with it.

For years, the goal for technology organizations was to become the trusted advisor who gets invited to the first meeting, not just be handed requirements after the important decisions have been made. Robertson’s experience suggests that today’s CIOs need to challenge their organizations to go further, from “Tell me what you’re trying to accomplish” to “Let me show you what’s coming.” That requires getting close enough to your business colleagues and customers to see what they may not see yet. It’s the difference between being invited to the first meeting and being the reason the meeting gets called.

For more from Janet Robertson’s leadership playbook, tune in to the Tech Whisperers.

See also:

• IT reinvention requires mastering the art of translation
• What separates true enterprise leaders from strong tech execs
• The 7 new Cs of IT leadership for the AI era

The most expensive quantum mistake a CIO could make today may not be investing too early. It may be investing in the wrong capabilities, for the wrong reasons, without understanding the architectural and economic consequences.

Over decades of leading enterprise technology, architecture, modernization, and innovation in complex, highly regulated environments, I have seen a recurring pattern: technological enthusiasm advances faster than institutional readiness. Capital gets committed. Platforms become entrenched. Dependencies multiply. Business value remains difficult to demonstrate.

Quantum computing risks repeating that pattern, but with an important distinction: The cybersecurity consequences demand action today, while the timing and economics of broader commercial quantum advantage remain uncertain.

That is the strategic tension CIOs must resolve.

Quantum readiness and preparedness is not a race to acquire qubits. It is a discipline of protecting enterprise trust, preserving strategic options and directing scarce capital toward demonstrable value.

The fundamental question is no longer whether quantum computing deserves executive attention. It is whether CIOs and enterprises can distinguish what must be protected now, what deserves experimentation and what should remain an option rather than a financial commitment.

Two quantum clocks. One enterprise balance sheet

Quantum presents two fundamentally different timelines to a CIO.

The first is the security clock.

In August 2024, the National Institute of Standards and Technology (NIST) published its first three finalized post-quantum cryptography standards, establishing practical mechanisms for protecting information against anticipated quantum-enabled threats.

This is critical because cryptography is not an isolated cybersecurity component. It underpins identities, financial transactions, digital signatures, software integrity, communications, connected infrastructure and trusted business relationships.

A sufficiently capable future quantum computer could compromise certain widely deployed public-key cryptographic methods.

The October 2026 U.S. Government Accountability Office (GAO) report, Quantum Computing: Federal Actions Needed to Prepare for Emerging Cyber Threat, reinforces the urgency. None of the 24 federal agencies examined had fully addressed all three assessed preparatory practices for migrating vulnerable cryptography.

The lesson extends beyond government: you cannot migrate cryptographic dependencies you have not discovered.

The second is the commercial advantage clock.

Quantum computing may eventually offer meaningful advantages in selected areas of chemistry, materials science, simulation and optimization. But promising research does not automatically translate into repeatable enterprise economics.

IBM’s published quantum technology roadmap targets a fault-tolerant quantum system in 2029. That is an important technological ambition, not a guaranteed date for widespread commercial advantage.

These two clocks should not share the same investment assumptions.

Security readiness is justified by exposure and risk tolerance. Commercial adoption must be justified by demonstrated advantage and economic returns.

Confusing the two creates either dangerous underinvestment or speculative overspending for the CIOs.

Architecture before acquisition

The enterprise architecture challenge is more consequential than the quantum procurement question.

For CIOs, post-quantum preparation begins with initial understanding of where vulnerable cryptography exists across their enterprise, how it supports critical business services and whether those dependencies can be changed without destabilizing operations.

For example, consider a globally distributed financial institution.

Cryptographic dependencies may span payment platforms, customer identities, authentication services, certificates, mainframes, cloud environments, third-party APIs and decades of retained information.

Replacing an algorithm is not necessarily equivalent to replacing a library.

Some changes affect protocols, hardware security modules, certificate lifecycles, application compatibility, vendor contracts and operational resilience.

This demands cryptographic agility: the ability to replace or adapt cryptographic mechanisms without rebuilding the enterprise.

The same architectural discipline applies to future quantum workloads.

Enterprises should favor modular integration, well-defined interfaces, workload portability and interoperability across classical computing, high-performance computing, AI and emerging quantum services.

Quantum will not make classical computing obsolete. The more credible architectural direction is selective integration where a quantum capability demonstrably improves a specific computational outcome.

The architectural objective therefore is not quantum dependence. It is quantum optionality.

An enterprise should be able to adopt a useful breakthrough without surrendering control of its technology economics or becoming captive to a single provider.

The missing equation: Quantum workload economics

The quantum conversation becomes strategically meaningful when CIOs stop asking what a quantum computer can theoretically perform and start asking what business outcome it can improve.

The OECD’s 2026 research, Building Business Readiness for Quantum Computing, identifies barriers including technological immaturity, uncertainty surrounding business applications, access and training costs, and shortages of specialized expertise.

These are not simply engineering obstacles. They are capital allocation constraints. This means that a quantum experiment may demonstrate technical progress while failing to establish commercial value.

For example, a proposed optimization workload should be evaluated against competitive classical algorithms, realistic datasets, operational constraints and the full cost of execution.

The comparison must include more than processing time. It should consider problem preparation, data movement, orchestration, error mitigation or correction, integration, specialized talent, assurance and recurring operating expenses.

Even an impressive laboratory result may offer little economic benefit if the end-to-end enterprise workflow becomes slower, costlier or less dependable.

I would therefore introduce a more demanding investment metric: Cost per Trusted Quantum-Enabled Business Outcome.

This proposed measure evaluates the total attributable cost of achieving a validated business result, including the controls necessary to make that result operationally acceptable.

The denominator is not the number of quantum circuits executed. It is the number of useful, verified business outcomes delivered.

Where no defensible quantum advantage exists, the responsible decision may be to continue using classical computing.

That is not technological conservatism. It is capital discipline.

Introducing the quantum capital discipline framework

I propose a six-dimensional executive framework for separating quantum preparedness from quantum speculation.

1. Exposure: What must we protect? Identify vulnerable cryptographic dependencies, long-lived sensitive information, critical services and contractual or regulatory obligations. Prioritize remediation by business consequence, not technology fashion.
2. Relevance: What problem warrants quantum? Establish a specific business problem whose computational characteristics plausibly justify quantum investigation. Scientific curiosity alone is not an enterprise investment thesis.
3. Advantage: What evidence proves improvement? Demand reproducible comparisons against strong classical alternatives. Evaluate solution quality, performance, operational constraints and independent validation.
4. Architecture: Can we adapt without lock-in? Assess portability, integration complexity, vendor concentration, reversibility and the ability to change technology choices as the market evolves.
5. Economics: What is the full cost of value? Measure total lifecycle costs, opportunity costs, talent requirements and credible returns. Distinguish research expenditure from production investment.
6. Authority: Who decides to advance, defer or stop? Assign accountable decision makers, measurable milestones, investment thresholds and explicit exit criteria. Together, these dimensions form the Quantum Capital Discipline Framework.

Its governing principle is straightforward:

Capital follows evidence. Architecture preserves options. Governance owns consequences.

Importantly, this framework does not subject essential cryptographic remediation to the same commercial-return requirements as speculative quantum workloads. Security obligations and innovation opportunities require different investment justifications.

What boards should demand from their CIOs

Quantum strategy should enter Board discussions through enterprise risk, capital allocation, resilience and competitive positioning — not promotional demonstrations.

I would encourage directors and executive committees to demand answers to five key questions:

1. Which critical business services and information assets face material quantum-related cryptographic exposure?
2. Can we modernize vulnerable dependencies without unacceptable operational disruption?
3. Which proposed quantum applications outperform credible classical alternatives?
4. What evidence would justify expanding, delaying or terminating quantum investments?
5. Who is accountable for the financial, security and architectural consequences?

These five questions create a practical governance boundary between preparedness and speculation. They also expose a broader institutional weakness: enterprises often approve emerging technology investments without establishing the conditions under which those investments should be reconsidered.

Quantum requires a different approach.

Investment decisions should be revisited when technical capabilities, benchmark results, standards, security exposure or business economics materially change.

Boards should insist on measurable progress but avoid manufacturing artificial deadlines for breakthroughs nobody can reliably predict.

The CIO’s next mandate: Preserve the freedom to act

Quantum computing will not transform every industry simultaneously, deliver equal advantage across workloads or reward every early investor.

Some enterprises may eventually realize significant value from specialized quantum applications. Others may encounter quantum’s most immediate consequences through cryptographic modernization, technology dependencies and the protection of long-lived information.

Both outcomes demand leadership today.

The CIO’s responsibility is not to predict which quantum architecture will prevail or which vendor will dominate. It is to ensure that today’s decisions do not compromise tomorrow’s ability to compete, adapt and protect enterprise trust.

That requires investment discipline, architectural foresight, credible experimentation and accountable governance.

The next quantum advantage may belong not to the enterprise that invests first or spends the most, but to the one that knows precisely when to act, where to invest and when to walk away.

Quantum readiness is not measured by the technology an enterprise owns. It is measured by the strategic freedom it retains, the risks it responsibly reduces and the business value it can demonstrably create.

That is the difference between quantum enthusiasm and quantum leadership.

Quantum leadership is not about predicting when the future arrives. It is about architecting the freedom to embrace it, exercising the discipline to invest in it and preserving the authority to walk away when promise fails to become value.

Every platform leader I know is being asked the same question: How do you deliver more with less?

The usual answers are familiar: hire more people, add more process or ask the existing team to move faster.

All three miss the underlying constraint. Headcount is an input. Throughput is an outcome. Organizational complexity is a cost.

Adding people can increase capacity, but it also adds communication paths, onboarding, coordination and decision overhead. Adding process can create consistency, but it can also slow the decisions it was meant to improve. Asking a team to work harder eventually consumes the very capacity you are trying to increase.

There is another answer: design the organization so ownership scales faster than headcount. That means deliberately small pods with sharp charters, end-to-end ownership and aggressive use of automation, platforms and AI.

I spent more than a decade running provisioning and lifecycle for very large infrastructure fleets at VMware, where small teams operated systems at a scale that looked impossible on paper. Today I lead an engineering organization of three teams at Stripe, built from a half dozen pods, each with its own charter and a large scope that nests into the team and organization charters above it. The lesson has held in both environments: the unit of scale isn’t headcount. It’s ownership.

Small pods work because they concentrate ownership, reduce coordination and make leverage compound.

The headcount trap

When a leader says they need more people, they usually mean they need more throughput. The two are not the same.

Brooks made this point in The Mythical Man-Month: adding people to a late project can make it later because communication paths grow faster than headcount. The tax does not stop at communication. Every additional person can add onboarding, alignment, decision-making, context sharing and ownership ambiguity. As organizations grow, nobody can hold the entire problem in their head. The organization compensates with meetings, documentation, processes and coordination roles.

You haven’t necessarily bought capacity. You may have bought complexity.

This does not mean hiring is bad. Growing teams and increasing scope often require more people. The mistake is treating headcount as the default answer to every capacity problem.

Before adding people, ask a harder question: What is preventing the existing people from owning more?

Sometimes the answer is genuinely capacity. Often, it is handoffs, fragmented ownership, repetitive work, unclear boundaries or systems that nobody has permission to retire. Those are organizational design problems.

The squeeze-harder response fails differently but just as predictably. The engineers who absorb extra load quietly are usually your strongest ones. They are also the ones with the most options elsewhere. You won’t see the organizational cost immediately. You’ll see it when they leave.

Design for ownership

A pod is a small group of engineers with one clear charter and ownership of a meaningful scope from end to end: building it, operating it and eventually retiring it.

The exact number matters less than the principle. The group should be small enough that its members can understand the problem, make decisions without extensive coordination, and maintain unambiguous ownership. The goal isn’t to hit a magic headcount. It is to keep the cognitive and coordination load low enough that ownership remains clear.

The charter is what makes that possible. A good charter is one sentence that names what the pod owns and, just as importantly, what it does not.

“Own the lifecycle of this fleet, end to end” is a charter.
 “Help with infrastructure” is a wish.

In my organization, each pod’s charter is large in scope but sharp at the edges. Pod charters roll up into team charters, and team charters roll up into the organization charter. That hierarchy creates something more valuable than organizational neatness: decision rights.

When a request arrives that fits no charter, it becomes a visible leadership decision. Should we create a new pod? Change an existing charter? Stop doing something else? Or explicitly decline the work?

Without clear boundaries, the same request usually finds the most helpful engineer and becomes someone’s spare-time responsibility. That is how organizational entropy starts.

End-to-end ownership is the real multiplier. When the same people who build a system operate it and eventually decommission it, handoffs disappear. Waiting disappears with them. Quality improves because the people creating the system are also responsible for living with its consequences. Decisions get faster because there is no ambiguity about who gets to make them.

Ownership compresses organizational latency.

The leverage stack

Small pods only outperform if human effort is multiplied. A three-person pod delivering ten-person impact isn’t doing ten people’s work through heroics. It is using leverage.

I think about that leverage in three forms: automation, shared platforms and AI.

Automation

The first form is automation. I have run one rule for years: a repeated task is a bug in the system, not a job description.

If a pod does something twice by hand, the third time it should become code, a pipeline or a paved path that makes the right way the easy way. The system should do the repetitive work. Humans should do the judgment work.

Platforms

The second form is organizational leverage. Shared platforms, paved roads, reusable infrastructure and common capabilities allow every pod to build on work that someone else has already done. A pod that can consume a reliable internal platform ships like a team much larger than itself. A pod that has to build its own foundations is a small team doing a large team’s plumbing.

The best platform work therefore does more than improve one team’s productivity. It multiplies the capacity of every team that depends on it.

AI

The third form is increasingly AI. The interesting question isn’t whether an engineer can write code faster with AI. The more important question is whether AI allows a pod to absorb more scope without adding people by reducing the cost of cognitive work.

AI can help pods investigate unfamiliar systems, generate and analyze code, create tests and documentation, accelerate onboarding and absorb routine operational work. That creates a new kind of leverage: compressing work that previously consumed significant engineering time.

But AI does not fix organizational ambiguity. It amplifies the structure it lands in. A pod with a sharp charter, clean interfaces and strong ownership can turn AI into leverage. A vague organization with an AI assistant can simply produce ambiguity faster.

The goal isn’t AI-powered productivity for its own sake. The goal is increasing the scope a team can responsibly own.

The hardest decision is what not to do

None of this is free. Staying small requires decisions that often feel wrong in the moment.

The first is choosing what not to staff. Every planning cycle produces more good ideas than the organization has capacity to pursue. The design only holds if you let some of those ideas die on the table. A pod at 120% of its charter is not a success story. It is a slow failure with good PR.

The second is allowing pods to kill their own systems. End-to-end ownership includes the end. A pod that cannot retire its own work accumulates systems faster than it can eliminate them. Eventually, engineers spend more capacity feeding old systems than creating new value. Some of the highest leverage work my teams have done has been turning things off.

The third is saying no to good ideas because the pod is full. Not “not yet.” Not “let’s find a way.” No. The charter is the reason. It feels harsh. What is actually harsh is saying yes and allowing the pod to discover the cost at 2 a.m.

The hardest part of small-pod design is not deciding what each pod should do. It is deciding what the organization will deliberately not do. That is a leadership responsibility.

Defend the boundary

The biggest threat to a small pod isn’t failure. It is success.

Successful teams attract scope. A team solves one problem, so someone asks it to solve the adjacent problem. Another stakeholder has a one-off request. A system loses its owner and suddenly the successful team becomes the obvious new home for it.

None of these requests is unreasonable individually. Together, they create organizational entropy. A successful pod can quietly become the large, overloaded team it was designed to replace.

Defending small is therefore active work.

The charter is the first line of defense. Requests outside it get a visible decision, not quiet absorption.

The second is regularly reviewing what each pod is actually carrying against what its charter says. Scope drift is much easier to see on paper than in someone’s calendar.

The third is recognizing when a pod has genuinely outgrown its design. When a pod’s scope has legitimately doubled and stayed there, the answer isn’t to quietly double the size of the pod. Split the scope. Create two pods with two clear charters.

Scale the ownership boundary, not the coordination burden.

When small pods don’t work

Small pods are not a universal answer.

Some problems genuinely require larger groups or tightly coupled expertise. Some domains have operational, security, regulatory or reliability requirements that make a very small team impractical. Some work is inherently exploratory and doesn’t yet have a stable boundary that can become a pod charter.

The principle isn’t “make every team smaller.” It is: make ownership as small and as clear as the problem allows.

If a problem cannot be cleanly separated, don’t force an artificial boundary. But if a problem can be owned end to end by a small group, don’t add organizational complexity simply because more people are available.

Measure leverage, not activity

Traditional engineering metrics often measure activity: tickets completed, projects delivered, story points, utilization. Small pods need measures that make their leverage visible to the business.

I look for three categories.

Capacity

• Scope owned per engineer
• System scale supported per engineer
• Operational load per engineer
  
  

These numbers reveal how much meaningful scope the organization can sustainably own.

Velocity

• Lead time from request to production
• Decision latency
• Time spent waiting on another team

These show whether ownership is actually reducing organizational friction.

Leverage

• Toil eliminated
• Manual workflows automated
• Systems retired
• Capacity reclaimed
• Recurring operational work eliminated
  

These capture the work that no longer requires human effort.

These are signals, not quotas. The goal is not to maximize scope per engineer, but to understand whether organizational leverage is increasing sustainably.

A small pod’s most valuable work is often invisible: an incident that never happened, a system that no longer exists, a manual process that no longer requires an engineer, a dependency that disappeared, a class of requests that became self-service.

If you don’t count those outcomes, the organization’s highest-leverage work becomes invisible. And invisible work does not survive budget season.

The real trade

None of this is a shortcut. Small pods demand sharper charters, stronger technical foundations, more discipline about leverage, and harder leadership decisions than large teams do.

That is the trade. You exchange the comfort of headcount for the compounding leverage of a few people who own something completely and multiply themselves through automation, platforms, AI and organizational clarity.

The goal isn’t fewer engineers. It is less organizational complexity per engineer.

The organizations that consistently deliver more aren’t necessarily the ones with the most people. They are the ones where small groups can own increasingly large scopes because the organization systematically removes coordination, toil and work that doesn’t require human judgment.

Scale the scope, not the team.

There is a fundamental problem hiding behind today’s technology forecasts: the technology industry is projecting spending growth at rates that many of its customers cannot economically sustain.

Gartner’s July 2026 forecast calls for worldwide IT spending to increase 14.2% in 2026 to $6.37 trillion. Within that number, software is projected to rise 15.5%, Infrastructure-as-a-Service 29.3%, and data-center systems an extraordinary 62.5%. Gartner itself acknowledges that technology budgets are being strained by inflation, supply shortages, hardware and memory costs, and AI investment.

The AI projections are even more dramatic. Gartner’s September forecast puts 2026 worldwide AI spending at $2.7 trillion—up 49.5% in a single year. McKinsey has separately estimated that generative AI alone could drive $175–$250 billion of software spending by 2027, adding two to six percentage points to software-sector growth.

These are extraordinary numbers. But they expose a fundamental flaw in the way the technology market is being viewed: The forecasts measure what the technology industry expects to sell—not necessarily what its customers can afford to buy.

That distinction is critical.

The forecasts may describe what technology suppliers want to sell, what hyperscalers intend to build, and what analysts believe enterprises will demand. They do not demonstrate that the typical enterprise has the economic capacity to increase its technology budget at anything approaching those rates.

Dr. Howard A. Rubin

That is the collision illustrated in this cartoon. Most companies cannot indefinitely grow technology spending at 10%, 15%, 20%, 30% or even 50% when their revenues, operating margins and the economies in which they operate are growing at only a fraction of those rates.

And the affordability problem is actually worse than the headline spending forecasts suggest.

Enterprises simultaneously face the economic headwinds: IT inflation; AI premiums; rising compute, server and memory costs; cybersecurity; energy and datacenter requirements; technical debt; scarce technology talent; software and cloud price escalation; regulatory and control costs; and the continuing expense of maintaining yesterday’s technology while financing tomorrow’s.

The result is what I call the Technology Affordability Gap: Technology demand + technology inflation + AI investment + infrastructure requirements are growing faster than the economic capacity of many enterprises to pay for them.

This produces an extraordinary paradox. Every technology forecast can appear individually plausible from the supplier’s side while their collective implications become economically implausible from the customer’s side.

A hyperscaler can forecast enormous cloud growth. An AI company can forecast enormous AI adoption. A software company can forecast higher subscription revenue. A semiconductor company can forecast explosive demand for AI infrastructure. An analyst can add all of those expectations together.

But ultimately there is only one customer balance sheet paying the bills.

Something, therefore, has to give.

Enterprises will have to slow spending, eliminate legacy costs, consolidate vendors, renegotiate contracts, defer lower-value projects, substitute AI and automation for labor, radically improve technology productivity, and demand demonstrable economic returns from AI and other technology investments. Otherwise, technology spending will increasingly have to be financed by taking money away from other parts of the enterprise— or by sacrificing margins.

That is the impending Technology Economic Crisis.

It is not a crisis caused by a shortage of technology. It is potentially a crisis caused by more technology ambition, more technology supply and more technology spending expectations than the underlying economy can afford.

The question for 2027 and beyond, therefore, isn’t simply: “How much technology will companies want?”

It is: “How much technology can they actually afford?”

AI is writing more code than ever. Software specialist Sonar’s 2026 State of Code Developer Survey, based on more than 1,100 professional developers, found that 72% of those who’ve tried AI coding tools now use them every day, and that today, AI now accounts for 42% of committed code, a number that’s expected to reach 65% by next year.

But while developers embrace AI-enabled coding services, many professionals are uncertain about how their businesses will cope with this influx of AI-generated code. Sonar’s research additionally discovered that 96% of developers don’t fully trust it, and only 48% always verify it before committing.

In fact, 38% of developers told the researchers that reviewing AI code requires more effort than analyzing code written by human colleagues. That’s a pattern recognized by Tim Chilton, a managing geospatial consultant at UK mapping agency Ordnance Survey (OS). “There’s truth in the headlines that AI can get carried away, and developers spend more time fixing the code that’s been created than not,” he says.

While that’s not a pattern he sees at the OS, Chilton says his organization is cautious about how developers use AI coding tools, and conversations with other digital leaders suggest a similar approach. AI-enabled coding is indeed almost ubiquitous, and it can allow developers to reach new, higher levels of productivity, but more doesn’t necessarily mean better code.

To ensure that such coding services produce business benefits, CIOs must take control of the development process. They should exploit agents carefully, set professional responsibilities, and establish guidelines, policies, and organization-wide training.

Exploiting the agents

Snowflake co-founder and president Benoît Dageville suggests there are two ways to view AI-powered coding. One is the scary way, where AI takes over your tasks without human input. The second is the efficient way, where AI helps you do the same things as before, but at a fraction of the cost. He’s a big believer in the latter, both for himself and his teams.

“The route depends on the organization; their application of AI coding depends on their priorities,” he says. “However, I hope that overall, AI will have a positive effect on humans. I’m using AI every day to code, and if I compare myself to one or two years ago versus now, I’m more efficient and productive, but I’m also writing five times more code.”

Steve Lucas, CEO of integration technology specialist Boomi, also notes the increase in output. He quotes research that suggests 4% of GitHub public commits are already being authored by Claude Code. That proportion is expected to rise to 20% of all daily commits by the end of this year. Staff at Boomi already use AI tools to produce more code.

“We’re writing 10 times the amount today than we did two years ago,” says Lucas. The increase in AI-enabled coding is so significant that he’s spoken with Boomi chief product and technology officer Ed Macosky about goals for the proportion of self-modifying code.

“I believe AI should recursively modify 80% of a software organization’s code,” Macosky says. “Infinite improvement is demanded. If AI is extraordinarily good at breaking security protocols, the only way to keep up isn’t the kind of accordion model of human code design. AI use must be linear in scale and continuous.”

Crucially, Lucas suggests using AI to check and modify that AI doesn’t mean coders go away. “In fact, I think we’ll need more engineers, not fewer,” he says. “We need these professional experts to ensure the quality of the code that’s written.”

At OS, Chilton uses Coco, Snowflake’s coding agent. The tool does as much as 90% of a development task that he would otherwise complete from scratch. “It’s taken an hour to finish, instead of weeks or never,” he says, reflecting on the power of AI coding services.

However, the tool’s influence is carefully constrained. The agent doesn’t work in isolation, and Chilton checks its output in detail. He says all organizations need a similar process and should value experienced professionals who can use AI coding tools effectively.

“If you’re giving a tool to someone who isn’t capable of checking an agent’s work, as a digital leader, you run the risk of putting too much faith in AI just running with its output,” he says. “I think that’s a big risk, so there’s still a need for experienced developers.” 

Setting clear responsibilities

While placing humans in the loop can help ensure AI-enabled code is safe and effective, developers shouldn’t be weighed down by their new management responsibilities.

Gill Haus, CIO at Chase, the consumer banking arm of JPMorgan Chase & Co, says AI coding benefits can only be realized when agents are introduced with a strong focus on automating supporting technology and processes, which reduces the need for too much human input.

“If you have 12,000 engineers, they can write 12,000 engineers’ worth of code in a day,” he says. “If those 12,000 engineers have agentic technology, they can write much more. But if you don’t have automation left to right with confidence, you create more manual processes. You can’t move as quickly since there are only so many humans you can put in the middle.”

Haus says Chase never releases services in production that don’t pass its high bar for quality and security. Strong engineering practices, pipelines, and architecture, plus a tried-and-tested approach to automation, can help ensure AI coding produces solid outputs without a burdensome amount of human intervention.

“We’re focused on effective automation so we’re able to unleash this technology safely and effectively,” he says. “This is something many other companies should be focused on if they aren’t already, because otherwise you can’t keep up with the pace of change.”

François-Xavier Pierrel, group chief data and ad tech officer at French TV network TF1, is another digital leader who says maintaining control as AI writes more code means keeping the human in the loop in a clearly defined manner. His team documents agentic processes using Atlassian project management and collaboration tools, such as Confluence.

Pierrel says policy management is crucial as the agentic transformation gathers pace.  One key step is ensuring professionals who use agents conform to internal standards. Smart businesses set policies that state clearly when staff can explore an agent, delegate work to it, or release it in production.

“We don’t have hundreds of agents deployed yet,” he says. “But the moment you reach a certain level of volume, if you don’t have compliance and policies in place, AI becomes a critical mess, and then it can be disruptive in a negative way.”

Building strong foundations

Kirsty Roth, chief operating officer at content and technology specialist Thomson Reuters, agrees digital leaders must be proactive. Her firm’s explorations with models and agents suggest that AI can help with time-intensive coding processes, such as writing. This capability means her organization carefully considers the roles people fulfil.

“In the last 12 months, we’ve put lots of thought into where we’re seeing benefits,” she says. “It’s great AI can do some of the coding work, but what does that mean for people’s jobs? We used to have thousands of engineers. Do we now need more architects or product people?”

Roth refers to security. While cyber is always a priority for Thomson Reuters, the firm dedicates significant resources to controlling threats in the AI age. Developing high-level development and security skills requires a concerted effort. Yet Roth says ensuring people have the right skills to manage AI is in many ways a familiar IT trend.

“All this effort is no different than digital, cloud, mobile, social, or other big tech trends,” she says. “They all take several years to have an impact as the initial hype comes, and then you’ve got to work through the reality and think about how you upskill people for the new world.”

Crucially, coding is no longer the sole preserve of the software developer. AI coding tools make it much easier for non-IT professionals to vibe code applications. Tal Carmi, CIO at technology specialist WalkMe, says non-developers can create useful tools. However, effective outputs rely on a careful balance between enablement and guidance.

He adds that most of these employees don’t need in-depth capabilities, such as a database or a content delivery network. Instead, non-IT staff require a dedicated place to upload their products. WalkMe’s engineering specialists ask key questions to ensure their outputs are safe, considering credentials and potentially problematic packages.

“You need to add guardrails,” he says. “A lot of the work for in-house engineers is shifting from building to testing. The people who aren’t coders don’t necessarily have security in mind.”

The key takeaway, suggests Emmanuel Frenehard, chief digital officer at biopharmaceutical giant Sanofi, is that digital leaders must help professionals feel comfortable. Successful digital leaders ensure the business generates value from agents, and his firm is helping its staff, particularly its developers, to embrace these tools.

“I genuinely worry for professionals who don’t use AI to code, because in five years, they may not have jobs,” he says. “So we’re guiding, coaching, and training them, but people must take the journey. The train has left the station. You can decide to be on it, or just look at it.”

Over many years of working through successive waves of enterprise technology and IT architecture, including fast-moving AI, I’ve heard the same question in different forms: “How can I build my business with AI while avoiding lock-in and tech debt?”

It came up again during a recent conversation about a major technology investment, when a CIO asked, “Should we really be making this commitment if the technology is changing constantly?” That resonated with me because it reflects a pattern I have seen across technology waves: the architecture must provide stability even as the capabilities around it continue to evolve.

For decades, the goal has been to build a technology foundation that serves the enterprise for five, seven or even 10 years. With the emergence of AI, some technologies become outdated before implementation is complete.

If shorter technology lifecycles are the challenge, adaptability is the answer. Instead of asking, “What will serve us for the next decade?” CIOs should ask, “How can we remain flexible as technology changes?” That requires being deliberate about what must remain durable and where the enterprise must be ready to adapt.

Think of it like a house. The foundation, walls and furnace are built to last, while paint, furniture and bathrooms change as needs and styles evolve. Enterprise architecture increasingly works the same way.

AI is separating the experience of work from the systems behind it

I recently heard about a company that now gives new employees a single onboarding tool: ChatGPT, connected to the enterprise systems and key data sources behind it. Instead of learning multiple applications, employees simply ask for the information or support they need, without knowing which underlying system provides it.

Of course, a single interface doesn’t mean blanket access to enterprise systems. This model requires security measures that ensure employees can access only the information and capabilities they’re authorized to use: carrying each employee’s identity and existing permissions through every request, limiting access to what’s necessary, tracking where information comes from, and logging retrievals and actions. Changes with significant business consequences should also require review.

This does change how we think about work and the technology that supports it. If agents are becoming the primary interface, the central question shifts from “Which application should employees use?” to “Can our data be accessed, understood and used securely by the interfaces and agents we adopt next?”

Adaptability means running at two speeds

Some technology capabilities should endure; others should evolve quickly. The mistake is treating everything as having the same lifecycle.

The durable layer includes ERP, HCM and other core systems, along with data, security and foundational architecture. These investments remain essential, but CIOs should design them around future business possibilities rather than solely around today’s processes.

The fast-moving layer comprises agents, interfaces, analytics, workflows, AI models and tools, experiments and business-specific solutions. The CIO’s role is to distinguish this layer from the durable core and ensure that rapidly evolving capabilities can be replaced without destabilizing the durable foundation.

CIOs need practical ways to change the underlying technology without disrupting the applications the business relies on. That starts with clear, consistent rules for how systems exchange data and interact with APIs, MCP connections and AI agents, keeping the implementation choices behind those boundaries. Before changing a model, agent or application, teams should confirm existing data and integrations will keep working, test security and expected behavior, and introduce changes in stages with a rollback plan if something goes wrong.

This two-speed model is a substantial departure from traditional enterprise IT management and from the way we did things when I was coming up in the tech world. It changes how CIOs plan investments, organize technology functions, structure vendor relationships and govern the connections between durable and fast-moving capabilities.

Invest thoughtfully for both durability and adaptability

In the pre-AI era, CIOs prioritized technologies with decade-long relevance. Today, they should avoid overspending on solutions prone to rapid obsolescence and invest in business outcomes and a durable foundation for intelligence.

Projects lasting more than six months warrant scrutiny: Will the solution remain relevant, or are we embedding processes that AI may soon handle; perhaps with a single prompt?

Durability extends beyond core systems to include the organization’s capacity to understand, evaluate and adopt new technology.

Today, most companies critically underinvest in skills. Knowing how to operate ChatGPT or Claude is not the same as working effectively with AI. OpenAI’s study found that AI power users outperform average users by sixfold. Upskilling gives CIOs leverage by helping employees redesign work and use AI effectively, while stronger leadership fluency facilitates new business models rather than merely supporting existing operations.

Most companies are also underinvesting in the data foundation. In West Monroe’s recent survey of 417 business leaders, AI governance, risk and compliance ranked as the lowest investment priority for the next 12 months. Traditionally, IT addressed data operations to ensure successful ERP implementation. Now, because data quality directly impacts AI value, investing in governance and accessibility is imperative.

CIOs need practices that preserve data meaning and reliability as platforms change. Those include assigning clear ownership, establishing authoritative sources and shared definitions, tracking data lineage and setting standards for quality and access. Definitions and rules should be maintained in portable documentation and data contracts, rather than embedding them in a single AI model or vendor platform, so they carry forward as technology evolves.

Break down IT silos to encourage adaptive architecture

Typically, CIOs organize operations around disciplines such as infrastructure, data, applications and security, with IT teams choosing an application and then defining processes and architecture around it. But as future architecture becomes less certain, CIOs must instead envision future business capabilities and design for change, bringing AI and data into architectural thinking alongside traditional cloud and application expertise.

Consider a reporting process that today moves from data analysis to Excel to PowerPoint to human review before a decision is made. An adaptive architecture focuses less on preserving each of those steps and more on the outcome: turning data into intelligence that informs a decision or action. Excel and PowerPoint may still have a role, but they no longer need to be hardwired into the process.

CIOs also need to break down silos. Teams often define architecture around a single suite, such as Salesforce or SAP, without considering alternatives. While working with an energy company recently, I saw how bringing analytics teams into the discussion shifted the focus from the ERP itself to how data should be accessed and used. Small, cross-functional teams can help create that broader view and design around business needs rather than individual platforms.

Build partnerships around future business outcomes

The most effective CIOs I work with are shifting their focus from simply controlling costs to driving value, actively partnering with the business, and reimagining how functions can evolve with AI, data and IT.

As vendor offerings expand across applications, analytics, agents and interfaces, CIOs need to balance integrated ecosystems with the flexibility to combine providers. Prioritizing open standards, multi-cloud support, data portability, interoperability and adaptable contracts can help organizations use the strongest elements of core systems while integrating agents and data across systems to adapt faster as needs evolve.

CIOs should build flexibility into vendor contracts, so changing providers doesn’t mean losing access to valuable data, context or governance rules. Contracts should provide for usable exports of data and metadata, documented interfaces that vendors keep current, advance notice of discontinued features, and support for testing portability and transitioning to another provider. They should also specify security and audit obligations throughout the relationship and during the transition.

The bottom line: buy with the future in mind. Don’t just ask if an application meets current requirements. Instead, envision what future business functions should look like, then derive technology needs from that vision. Shift the mindset from using HCM checklists to driving workforce optimization, from CRM checklists to revenue management, and from ERP checklists to enterprise data and intelligence.

Find the signal in the noise

As AI gets smarter and cheaper, the challenge will shift from affording it to connecting it to business outcomes. I believe the defining constraint in 2027 will be focus, not cost: CIOs must identify the few high-leverage priorities their organizations can absorb and execute well. That’s easier said than done.

There’s no established playbook for the AI era: we’re all experiencing it for the first time. CIOs face a flood of startups, models, architectural approaches, evolving standards, vendor claims and internal requests. The task becomes curation: deciding what deserves attention. Distinguishing signal from noise is becoming an essential leadership skill.

The new long game for CIOs

I believe CIOs are at a pivotal moment. They can remain excellent IT leaders or help the business rethink work through intelligence. In that sense, the role could evolve into what I call the chief intelligence officer: the leader who helps the enterprise turn fast-changing technology into durable business value.

CIOs have always felt pressure to deploy emerging technologies rapidly. Implementation brings challenges, including calculating and measuring upfront investment costs. Deploy too quickly, and when the hype fades, many IT departments are left with a costly architecture to support, security gaps, and operational issues.

The same trend is happening with AI. Many CIOs procured enterprise-wide AI model licenses and empowered employees to experiment with language models and develop AI agents. Others asked DevOps teams to accelerate AI code generation and vibe coding. The shift from rapid experimentation to deploying more AI capabilities to production can leave CIOs with mounting AI debt and AI FinOps gaps.

CIOs’ near-term concern is managing budgets amid consumption-based AI pricing models. Even as AI token costs decrease, more employees are using AI, and agents are given more challenging, expensive assignments. Here are seven common mistakes IT leaders make that result in blown AI budgets.

Defining an AI strategy without measurable business outcomes

Most CIOs and CAIOs recognize the need to establish AI strategies focused on areas where AI can provide lasting business value. But many fail to quantify targeted business outcomes, leaving employees to use adoption metrics as the primary objective.

“Every token spent on a pilot that never proves its value is money leaders can’t get back and lost opportunity cost, which is a governance failure more than a technology one,” says Rob Scudiere, CTO at Verint. “Every agent and workflow should have to earn its budget by showing results that achieve the desired business outcome, or lose it.”

Kris Beevers, CEO and cofounder of Netbox Labs, says to use existing business metrics to see whether the areas adopting AI are improving them faster. “If adoption is climbing but the outcomes aren’t moving with it, that’s a pretty good signal to rethink where you’re spending,” Beevers says.

Recommendation: Financial impacts may be hard to target during experimental phases, but employees should set financial objectives before moving AI agents into development and deployment phases.

Experimenting without AI governance

CIOs may find they have a real mess on their hands when a few pilot AI agents quickly scale to thousands running in production. Much of AI governance focuses on identifying owners, setting data-access rules, defining target business outcomes, and establishing accuracy guidelines. CIOs must also educate employees on underlying cost factors, including model selection and platform standardization.

“Delayed AI governance gets framed as a compliance risk, but it’s just as much a budgetary concern,” says Guy Bourgault, head of agentic systems at Concentrix. “The longer organizations wait to define ownership, standards, and controls, the more they end up funding inefficiency, rather than progress.”

Varun Goswami, global head of product and AI at Newgen, says AI budgets are wasted on scattered pilots, duplicated integrations, and agents that run quietly without ever proving value. “Build on one governed platform rather than a dozen parallel stacks, reuse templates and connectors instead of custom-building each use case, and match the model to the job rather than routing everything to the priciest foundation model,” Goswami recommends.

Data quality is a third concern, according to Collibra and The Harris Poll, with 96% of IT leaders saying project failure almost always traces back to poor data foundations, and 51% reporting significant staff hours spent manually correcting autonomous AI agent outputs. CIOs should set data quality metrics and establish data products to build a trustworthy AI context layer.

Recommendation: CIOs should update and communicate their AI governance policies monthly, as AI cost, capabilities, compliance, and security considerations evolve rapidly.

Focusing tokenomics on model costs and not business value

Much of the discussion around AI token economics, or tokenomics, focuses on the costs of using different AI models. But the FinOps Foundation defines tokenomics as “the study of how the production, distribution, and consumption of tokens generate business outcomes and AI value within an organization.”

Because many organizations use multiple models, SaaS with AI agents, and internally developed AI agents, CIOs should partner with the CFO to measure total impact, including AI’s direct token costs, employee efforts, ongoing inference costs, and the value delivered.

“Companies can quickly overspend on AI when they focus too narrowly on token consumption, and the starting point should always be the business outcome,” says Prakash Kota, CIO at UKG. “I use the Three T’s: does the work require talent for judgment or expertise, can existing tools solve it efficiently, or do tokens create enough value to justify the investment?”

CIOs should then set AI budgets at the employee, department, and workflow levels. Each group’s budget should be reviewed and adjusted regularly based on outcomes. This discipline promotes fiscally smart decisions about when and how to use AI capabilities and can drive a top-down culture change.

“The same tokens can go to a skilled engineer shipping a product faster, or to a non-expert generating 10 versions of the same slide deck,” says Tom Shea, CEO and cofounder at OneStream. “The line item in the budget looks identical either way, and true token efficacy requires governance to ensure those tokens are empowering experts to accelerate output, rather than fueling a massive cost explosion.”

Recommendation: Setting AI budgets too soon may curtail employees’ enthusiasm in learning and experimenting with AI. Establish financial targets based on a maturity curve to encourage experimentation first, then fiscal discipline when AI agents are deployed to production.

Developing AI agents without standards

CIOs should communicate these two cost considerations to DevOps teams using AI code generators.

First, according to Stack Overflow’s 2026 Developer Survey, 73% of developers use AI coding assistants and agents daily, but developers care more about quality (75%) over cost (38%) when shaping prompts and picking models. CIOs should set guidelines for balancing cost and quality tradeoffs, establish DevOps non-negotiables, and require code analysis in deployment pipelines.

“Coding is no longer a constraint, and the bottleneck has moved to how we ensure the correctness of code,” says Anurag Dhingra, SVP and GM of networking and collaboration at Cisco. “There’s just no humanly possible way to review every piece of code that is written by AI.”

The problem is that 96% of developers don’t fully trust AI-generated code and 48% always check their AI-assisted code before committing, according to Sonar’s State of Code Developer Survey. As large organizations may use several AI code-generating tools, they need to benchmark quality, cost, and developer satisfaction.

“Teams need clear guardrails and engineering standards, especially as AI agents accelerate development and can introduce costly rework,” says Andrea Malagodi, CTO at Sonar. “Having live data aggregated from your one or many providers, to enable you to see the cost per PR [pull request], is a good governance mechanism.”

Recommendation: While AI code generation is a remarkable breakthrough, it also brings new costs and quality considerations CIOs should track.

Using frontier models for all AI needs

Another cost consideration comes as organizations deploy hundreds of AI agents and provide developers several AI models to choose from. Developers may choose models based on preferences rather than performance and cost considerations.

Craig Wiley, VP of AI at Databricks, says 77% of companies now juggle multiple model families because the best model for one task is rarely the best for another. “The flexibility comes at a cost of managing shifting prices, scattered vendors, and zero visibility into where your budget’s actually going. The fix is real-time budgets and smart routing that automatically sends queries to the most cost-effective model,” Wiley says.

Recommendation: Josh Fecteau, chief data and AI officer and CIO at Teradata, says that frontier models are expensive and not necessary for every task. “Diversify your model strategy with cheaper small language models, custom models, and industry-specific models,” Fecteau recommends.

Deploying AI agents without monitoring cost spikes and inefficiencies

A key challenge with AI agents is their variable costs, especially when they are given tasks of varying complexities. While some AI providers are moving to outcome-based pricing models, many still use a license model with a fixed number of tokens, plus consumption-based pricing for overages. This means CIOs must monitor costs, set AI observability standards, and define rules for handling performance variances in AI agents.

“I spent 25 years in telephony where every minute had a price, and agentic AI is the first software I’ve seen that bills like a phone call and gets budgeted like a license,” says CJ Combs, AI strategy executive at Columbus. “AI costs stop being predictable the moment an agent can loop, because it keeps pulling in context, retrying, and calling tools in ways nobody budgeted for.”

Experts suggest several implementation cost inefficiencies to review. Babak Pahlavan, founder, CEO, and CPO at NinjaTech AI, says that AI agent processing duration is an easy indicator. “A single autonomous agent running a multi-hour task can burn a month’s allocation in an afternoon because every tool call, every retry, every piece of context it re-reads gets billed,” Pahlavan says.

Other cost factors require experts to review an AI agent’s decision logs to determine optimization. Adi Elimelech, CTO and cofounder of Jedify, says, “If every query drags an entire database schema back to the LLM, token costs scale with the size of your environment rather than the complexity of the question. The cost compounds, since the model often doesn’t get it right on the first pass and loops back for another round trip before landing on the correct answer.”

Recommendation: CIOs will need to mature several AgenticOps and site reliability engineering practices to monitor AI agents and respond to cost, security, quality, performance, and other incident types.

Building agents without a change management plan

One of the biggest gaps in deploying AI agents is that deployment is just one step in a change management process. AI governance requires identifying agent owners who are accountable for decisions and responsible for outcomes. These owners should also sponsor the underlying change management process.

“The biggest AI cost overruns rarely come from technology,” says Abhijit Kakhandiki, SVP and GM of digital business automation at BMC Software. “They come from organizations deploying AI without redesigning processes, ownership models, and governance.”

Part of the change process requires identifying human-in-the-middle responsibilities to review the agent’s recommendations. The review process builds trust and lets owners switch to autonomous decision-making for low-risk, high-volume, trusted recommendations.

“It’s not going to be a binary switch where, from day one, you’re going to trust AI agents to run tasks autonomously,” says Joel Hellermark, chief AI officer at Workday. “Progressively, they’re going to earn the right to run those workflows autonomously. If it’s your fiftieth time approving an expense below $50 for one of your direct reports that looks exactly on policy, you can trust the agent to run it for you.”

Recommendation: Growing adoption isn’t the end game, but it’s a key step toward delivering business value. Metrics to track adoption include AI response quality, trust scores, repeat usage, and value delivered to adopters.

A simple rule is that you can’t manage what you don’t measure. CIOs should set budgets, track costs, and measure outcomes, especially as more agents move into production.

Much has been made of Generation Z’s supposed inability to adequately conform to modern-day corporate culture.

A recent Business Insider article on Gen Z (born 1997–2012) workplace readiness contains some damning statistics. The piece cites a 2024 poll of nearly 1,000 business leaders, 75% of which described some or all of the recent graduates they hired as “unsatisfactory.” Arguably worse, it cites another 2024 study from Hult Business School, in which 37% of HR leaders said they’d prefer to have a robot or AI do a job than hire a recent new grad, while another 30% said they would rather just leave the job vacant. Quite damning, indeed.

Warranted or not, these complaints about Gen Z are not new.

NYU Stern professor Suzy Welch conducted a September 2025 study juxtaposing the values of incoming Gen Z workers with those of hiring managers. Welch’s study included survey data from 2,100 hiring managers and a behavioral assessment of over 45,000 respondents (7,500 of which were Gen Z).

In a Wall Street Journal Op-Ed, Welch writes, “A mere 2% of Gen Z members hold the values that companies want most in new hires, namely achievement, learning and an unbridled desire to work.” According to Welch’s study, Gen Z members mostly value well-being and self-care, helping others and authenticity and expression. Oh, heaven forbid.

Not to be outdone, in March 2026, another NYU professor wrote a Wall Street Journal Op-Ed on “Why Gen Z is unprepared for the workplace.” The one, from psychology professor Tessa West, laments Gen Z’s lack of communication skills and failure to understand older generations. West writes, “Younger generations—Gen Z specifically—have learned to communicate in a digital world, sending texts and instant messages instead of interacting in person.”

West attributes Gen Z’s poor communication skills to a combination of excessive screen time, online classes during the COVID pandemic and a general overreliance on technologies. I cannot definitively say whether these accusations hold water; however, I do believe that the answer doesn’t lie in replacing humans with AI or leaving roles unfilled. Hiring managers need to adapt to younger generations, whether they want to or not. And we’re seeing this in the help desk software space in real time.

Gen Z has little patience for traditional corporate bureaucracy

Aside from grievances from older folks like me, the fact remains that Gen Z has little patience for traditional corporate bureaucracy. When these younger workers experience a technology glitch, they don’t want to log into a clunky portal, fill out a 10-field form and wait two days for a level 1 support agent to respond. These kids expect instant, consumer-grade, self-service resolution. If the enterprise doesn’t provide it, they’ll just bypass IT entirely.

To overly generalize, most members of Gen Z are comfortable with AI chatbots and tend to search for their own solutions online before reaching out to another human directly. This tendency to rely on mediated communication as opposed to person-to-person communication makes sense given their life experiences with COVID, online coursework, the post-pandemic reevaluation of work culture and their status as a mobile-first generation.

Ramifications for the help desk software space

To retain young talent, enterprises should consider deploying conversational AI, automated self-service password portals and omni-channel support to match the speed at which Gen Z operates.

Self-service should be the first order of operation. Rather than forcing employees to create a ticket and escalate an issue to an agent, workers should have the option to remedy the situation themselves. Across the IT support industry, we’re seeing more emphasis on AI oversight and escalation handling, as opposed to level 1 IT support work.

Additionally, given Gen Z’s mobile-first status, it is vital to have mobile-native applications for internal IT issues. These shouldn’t just be desktop portals reconstructed to fit a mobile interface; these should be mobile apps with consumer-grade quality UX interfaces equipped with things like push notifications for ticket updates.

We’re also seeing more agentic chatbots in the ITSM space. Gen Z workers (and all generations, really) expect agents to be able to handle simpler requests, like access provisioning, password resetting and resolving calendar conflicts.

Omni-channel continuity has become vital too. When Gen Z’ers begin a conversation in Slack or Zoho Cliq, they expect that conversation to seamlessly flow into SMS, email, mobile apps and other corporate channels.

Key takeaway

When it comes to IT service management, Gen Z workers expect agentic self-service, a mobile-first UX, omni-channel support and the ability to resolve tier-1 support issues themselves. Despite the lamentations of some old curmudgeons like me, Gen Z isn’t going anywhere. And what’s more, Gen Alpha (2010 – 2024) is waiting in the wings. If we haven’t brought our service desk infrastructure up to Gen Z’s standards, now is the time.

With 2027 quickly looming, IT leaders should soon be finalizing their objectives for the new year, one certain to be rife with many unknowns if 2026 is any indication.

This year began with the call for a pivot from AI pilots to AI ROI, but questions around AI governance and accountability quickly took center stage as agentic AI made further inroads in the enterprise and high-profile incidents showed the risks of AI gone awry and the value of security-first approaches to AI agents.

Now, CIOs must anticipate how AI will evolve in 2027, how they’ll get their enterprises ready for all the risks and opportunities of that evolution, whether their teams will have the skills to seize on technology advances, and more.

To get a glimpse of how CIOs are approaching next year’s IT agenda, we asked IT leaders to share the key questions they are asking to shape their strategies for 2027. Here’s what they shared.

How do we ensure our AI investments provide tangible value as the cost calculus changes?

The big question as CIOs plot their IT agendas for 2027 still centers on providing verifiable business value, as 98% of CIOs report that board pressure to demonstrate measurable AI ROI has increased since 2024, according to a 2026 report based on a Dataiku/Harris Poll survey of 600 enterprise CIOs worldwide.

Doug Gilbert, CIO and chief digital officer at Sutherland, a digital transformation services company, is among those IT execs pondering this question as he executes his fiscal 2027 budget, which started in July.

“When I’m out speaking to people and they say, ‘It would be great if AI could do that,’ I say, ‘Yes, but would it provide value? Are we building value or are we just burning tokens?’” Gilbert says. He notes that he and his CIO peers are being increasingly judged on the outcomes they deliver for their organizations, meaning they have more incentive than ever to ensure the technology initiatives they undertake deliver ROI.

But the calculus on that is getting trickier than it was at the beginning of 2026 — in part because AI total cost of ownership (TCO) is challenging to calculate, but also because an AI pricing reset is on the horizon. So, to that end, CIOs such as Gilbert are now thinking about what level of ROI is high enough to justify the investment.

That’s a key question to ask now and into 2027, Gilbert says, particularly as the cost of tokens continues to rise. An AI use case that provides marginal ROI could stop producing any value in the near future if tokens increase even slightly, he notes.

As a result, Gilbert is working to factor in those dynamics when he and his team work with the business to identify which AI use cases to pursue — and he expects to do so even more moving forward. “I plan to pay a tremendous amount of time thinking about whether [a proposed project] is the right one to pursue,” he says, to ensure “when you put math on paper there is value with the project.”

How do we ensure observability and auditability of our AI systems?

According to a 2026 survey from OneStream, 47% of senior finance and IT executives say they have made a material business decision based on inaccurate, incomplete, or outdated financial data in the past 12 months.

Citing that statistic, Gilbert says he’s also asking critical questions about the observability and auditability of all of Sutherland’s AI uses cases. He wants to be sure he, other executives, and users are confident the company’s AI systems always have high-quality data — and thus accurate outputs. And he wants IT to achieve that observability and auditability so that the company can accurately track, measure, and improve its AI deployments over time.

“We will not deploy any AI that we can’t observe,” he says, a policy that he put in place about a year ago and will continue in 2027.

A wide range of tools under the moniker “AgentOps” are emerging to help IT leaders monitor AI activity, tools, and costs, starting with observability.

How do we move to more autonomous agentic processes?

“The challenge most technology executives are grappling with at the moment is how you move AI from human-assisted agentic to much more autonomous agentic processes with minimal human intervention or supervision,” says Jody Fullman, CIO of Reconomy and recently recognized as one of the UK’s top 100 CIOs in the CIO 100 UK Awards 2026.

Moreover, how do you achieve that securely and in a way that’s economically viable? he asks.

Fullman is implementing strategies to address this challenge. He is strengthening IT’s agentic controls by aligning Reconomy’s governance program to an industry-recognized framework. He is also implementing tools to monitor and manage tokens. And he’s moving some AI workloads to lower-costs models.

All that, he says, will set up the organization to develop and deliver more autonomous agentic capabilities ahead, noting that he and his team have been transitioning successful proof-of-concept agentic initiatives into MVPs to put the company on the path to more autonomous agentic processes.

How should OpenAI’s Hugging Face incident shape my security strategy?

Security has been a central factor in IT agendas for years. But Jeff Stovall, CIO for Dallas, Texas, says the 2026 Hugging Face incident, in which autonomous AI agents built by OpenAI escaped their sandbox testing environment and hacked into the infrastructure of AI open platform company Hugging Face, has him adjusting his plans for 2027.

“Hugging Face demonstrated that there was a lot more peril in the world of AI as it relates to cybersecurity than what we were ramping up for,” he says. “There’s now this notion that AI may have more downside for us than upside for us in the near future,” he adds, explaining that AI-fueled threats to the organization are more significant than the positives its use brings.

“In the upcoming six months to a year, what I see is that we have to take a hard turn in thinking about how AI poses a significant malevolent threat to our organization when wielded by actors seeking to do harm,” Stovall says. He points specifically to hackers’ ability to use AI to create swarms of bots that can autonomously collaborate and exploit all vulnerabilities nearly instantaneously and all at once. “That’s a dramatic acceleration and amplification to the threats we face.”

In response, Stovall says he’s shifting more resources to maturing his security program in 2027 than he initially budgeted — drawing funds away from internal AI deployments to “shore up the walls even further” by adding more AI automation and agents to have “much more machine speed in security response.”

How do we use AI to transform?

Marco Bill, SVP and CIO at Red Hat, believes using AI for productivity gains is now table stakes. So as he develops his plans for IT for 2027, he’s looking to push that notion even further, asking how the company can use AI to transform processes as a whole.

“This question helps me to keep reminding ourselves that we’re not just here to do IT. It’s more of a guiding principle,” he says.

And that in turn is underscoring the importance of transforming the IT organization into a more collaborative and business-centric one.

As an example of what’s brewing at Red Hat, Bill points to the work his IT team is doing with the company’s sales team to devise ways to use AI to enable account managers to have better conversations with customers to close deals faster. IT is also working with the marketing department to make go-to-market process more powerful, and his teams are adding agentic AI to their own IT operations to create fully autonomous workflows that cost less to run and manage.

All told, Bill and the IT team at Red Hat are building further on the work many CIOs began in 2026 by helping to reimagine business processes to reap AI benefits and bringing AI transformation home to IT workflows.

How do we empower users to transform their work with AI?

“Citizen AI” is a rising trend in the enterprise, and this is something Reconomy’s Fullman will continue to address in 2027, explaining that his company has found that much of its “success with AI was not by being a tech project but by empowering our users and business colleagues to transform their work and processes with AI.”

Fuller believes that his company will see more AI-enabled transformation, and see that transformation faster, by continuing to put more AI in the hands of users throughout the organization instead of expecting IT workers to become experts in all the processes that could be transformed by AI.

As such, Fuller says the upcoming year’s IT plans will continue to put AI tools in the hands of the users, and do so with governance, security, and transparency in place. He’ll also leverage the skills of workers in process transformation roles, which were recently created and installed in Reconomy’s business units but still work closely with IT architecture and data teams.

“They’re plugged into tech and the business to make sure we’re prioritizing the right things and doing things the right way as we drive transformation,” he explains.

How do we prevent our AI governance council from becoming a bottleneck?

Company leaders at intelligent automation platform provider Celigo want every team to build with AI, something CIO Amy Farrow knows makes security and controls critical. But Farrow also wants to make sure she enables speed and doesn’t unnecessarily slow down innovation, noting that barriers could lead to shadow AI.

“If [teams] all have to wait too long, they’ll find a way around the process,” she says.

To ensure that governance isn’t a bottleneck, Farrow explains that her “governance council doesn’t approve projects. It sets the rules: risk tiers, design criteria, a checklist every agent has to pass.”

She adds: “The teams approve their own work against those rules, and we audit. My team owns the integrations, access controls, and observability. My job is making it faster to build the right way.”

What controls do we need to put in place for AI agents?

As AI agents increasingly enter enterprise workflows, IT leaders will need to the level of permissions agents should be granted relative to the people on whose behalf those agents will be operating.

Farrow, who previously served as global CIO at Infoblox and Lyft, believes agents should resolutely have fewer permissions than the people whose tasks they will be performing.

“Someone in finance can issue a credit or update our ERP because we trust their judgment. An agent doesn’t get that by default,” she explains. “We start every agent with the least autonomy required to achieve the outcome. It can interpret a request or recommend an action. Changes to records go through checks the model can’t override, and bigger changes need a person to sign off.”

This approach also has a fiscal benefit, she says, noting, “Less autonomy means fewer model calls, which keeps costs in check.”

As AI increasingly goes agentic, CIOs will increasingly need to plan for ways to address this issue in the year ahead.

What happens when vendor agents start acting inside our systems?

“Many of our SaaS vendors are shipping agents, and some can make changes to our data by default,” Farrow says of another key security- and governance-related question many CIOs are facing. “For 2027, I want vendor agents held to the same standard as any other integration.”

Farrow has other questions related to the rapid rise in vendor agents, asking, “What can they touch? Can we see what they did?”

IT leaders need to ensure they can answer those types of questions, noting that California’s and Colorado’s new rules on automated decisions start in January. She wants to be able to give strong answers to those questions, stressing that “‘the vendor’s agent did it’ is not a defensible answer.”

How do we meet immediate business needs while building a foundation for growth?

Mieko Shibata, CIO at R&T Deposit Solutions, sees this as “the overarching question” for him as CIO.

“That question guides our investment decisions and how we allocate our team’s time,” she explains. “Our strategic direction is consistent, but each year’s agenda must balance immediate business priorities with progress toward our longer-term technology foundation. We consider both the value each investment delivers and how it contributes to the environment we are building.”

Shibata is taking a multiprong approach in her response to that overarching question.

First, she’s ensuring technology modernization turns into measurable business value and that modernization initiatives are prioritized based on that value.

She is also considering how IT responds to growth opportunities while keeping its longer-term transformation on track. “Our response is to consider the immediate commercial value alongside the longer-term technology implications. Can we reuse the capability? Will it scale? What will it take to support? Does it help simplify our environment?” she says.

And she’s thinking about how the company prepares for AI’s evolution while maintaining clear accountability for its use. “For 2027, my focus is on building a repeatable approach to evaluating and adopting AI as it evolves, with clear business benefits, appropriate controls, and accountability for the results,” she says.

Is our AI vision ambitious enough?

For Lauren Wilkinson, CIO for financial advisor services at Vanguard, AI ambition is top of mind as she develops her IT strategy for 2027.

AI strategy should accelerate the business strategy and “push leaders to reconsider what outcomes with AI are possible, rather than simply finding ways to make today’s processes faster or more efficient,” she says.

“It helps to start with an aspirational business vision, including what a few big outcomes could look like. Then you can work backward to determine where AI and technology can fundamentally change what is possible,” she explains.

In her work with financial advisors, she’s found that they’re primarily using AI to support administrative tasks such as drafting emails, conducting research, and taking meeting notes. But she sees an opportunity to build on those use cases in the upcoming year to deliver on that objective for a more ambitious AI program.

Like many CIOs, Wilkinson wants to take AI to the next level at her organization and ensuring that ambition is high enough is paramount to achieving that goal.

Do we have the talent to win in an AI-native world?

Wilkinson believes how CIOs address the AI talent question will be critical for organizational success.

“As AI continues to evolve, the skills that differentiate great technologists will also evolve, placing an even greater premium on AI expertise and deep business acumen,” she says. “CIOs should be building teams that understand the business, can identify the highest-value problems, and know how to orchestrate AI-native workflows to solve them at dramatically greater speed. The differentiator won’t simply be who has access to the best AI, but who has the people who know where and how to apply it.”

Most CIOs know this, so it is not surprising that this year’s State of the CIO survey found that AI tops the lists for both most sought-after skills and the hardest to find. As a result, CIOs will have to get creative to build up their teams’ AI know-how in the year ahead.

How should IT be reshaped to maximize value creation?

CIOs, including Shelia Anderson, EVP and chief information and digital officer at Unum Group, are also asking how they should shape IT as an organization to ensure they can deliver value to the business.

“That has been a big focus for us this year and will continue to move down that path in 2027,” she says.

The question has shaped Anderson’s work at Unum Group since she started in her role in May 2025. She has organized her IT department around end-to-end value streams and says that approach has helped her IT staff work more closely with the business and more readily identify where improvements can be made. She also has her IT organization working to better understand business processes, and has been working on building more capabilities to measure and manage AI costs as Unum seeks to transform using AI. And she’s looking at what investments and improvements are needed in IT’s foundation.

All these moves will enable the IT department to get better at value creation, Anderson says.

She plans to augment this work in the coming year by providing AI training and education for IT workers and employees throughout the company “so they know how they can drive value and find opportunities in their everyday use of AI.”

Ensuring she has the right mix of talent — meaning she has the right skills in the right seats to deliver value — will also shape the actions she takes as CIO in 2027, Anderson says.

“In 2025 and 2026 there was a lot of testing and learning, but 2027 will be a year of maturing. You’ll see more formal processes and settling in around how you’re going to leverage the skills in your organization to drive value,” she adds.

In Foundry’s 2026 State of the CIO survey, 83% of CIOs say their role is becoming more of a hybrid to lead both business and tech initiatives, rather than simply manage IT. As the two become more inseparable, the CIOs who see collaboration as a competitive advantage are putting daylight between them and those who see it as a cursory soft skill. And C-suites are responding as they rely more on IT to drive growth and accelerate efficiencies. So the CIOs who deliver the most value will bring collaboration skills to drive change and technical expertise.

Silos between IT and the business are falling

As the World Economic Forum notes, not every tech initiative requires deep collaboration. But as businesses move beyond routine IT investments into cross-functional, innovation-focused transformations, collaboration becomes essential.

For example, how can IT decisions help an organization open new markets faster, or emerging technologies reduce risk in areas like data privacy. It’s no surprise, then, that Deloitte found that 65% of CIOs reported directly to CEOs in 2025, up from 41% in 2015.

Because tech is now part of almost every business decision, it takes everyone’s expertise and insights — from the CIO to the CFO — to see the full picture of how an initiative will affect the company. Shared knowledge leads to better-informed decisions that give tech its biggest impact.

When silos persist, CIOs struggle to get buy-in for their initiatives. Protiviti’s Global Transformation survey found that while 61% of CIOs report being confident in their tech transformation outcomes, only 34% of CEOs and boards feel the same — and the gap is even wider for AI implementations.

That gap is, at its core, a collaboration problem. Without effective collaboration and communication, others can’t see the value of transformation efforts. CIOs who excel in these areas can more easily demonstrate value, win buy-in and keep their organizations at the forefront of technology.

Delivering speed and innovation

Collaboration goes well beyond getting buy-in. While it may be thought to slow IT down, it actually brings in the insights that make change more effective and faster.

As I’ve highlighted in the past, when organizations move away from rigid data ownership, cross-functional teams can share what drives further innovation.

The same holds across the C-suite. Perspectives from outside IT show CIOs how a tech implementation works for the company as a whole, and where new opportunities lie. That lets CIOs test, refine, and reshape solutions faster.

Most importantly, when teams share a common purpose and goals, everyone stays aligned on the best overall outcome for the business. Iteration happens much quicker because everyone is focused on the big picture rather than individual agendas. With increasingly rapid tech cycles, that speed is a competitive advantage in its own right.

Building your collaborative abilities

For CIOs used to the old way of doing things, shifting to a collaborative mindset can be a challenge. But like any capability, it can be developed and improved by applying some fundamental principles.

Earn trust through follow-through. Trust isn’t built at a kickoff meeting or with a mission statement. It’s built when people see you do what you said you would, again and again. For CIOs, that means delivering on commitments or flagging early when you can’t. Clear and consistent communication is one of the most reliable ways to build trust across an organization.

Make transparency the default, especially when news is bad. Transparency means more than status reports. It means being candid about costs, risks, trade-offs, and setbacks before they surprise anyone. When leaders sidestep difficult discussions, trust erodes and goals drift. And in technology programs, small unspoken issues have a way of becoming expensive ones.

Seek cultural fit in how you work, not who you are. Cultural fit isn’t about sameness or shared backgrounds. It’s about compatibility in management philosophy, values, decision-making, and communication. A CIO who values speed and experimentation, and a CFO who prioritizes predictability and control will clash unless both recognize the difference and agree on how to bridge it. The same is true when it comes to finding the best technology providers.

Focus on the what, not the how. Few things undermine collaboration faster than micromanagement. When leaders dictate how a colleague or partner should work, they signal distrust, stifle creativity and innovation, and tie up their own time policing activities instead of driving results. The better approach is to agree on clearly defined, measurable outcomes, and then step back. Letting go of the how isn’t giving up control but building enough trust that everyone gets there together.

This requires adjusting your workflows and skills, but the payoff is valuable insight from your collaborators and wins that lift the entire organization.

The new life of the CIO

The days when the CIO could simply be the tech expert behind the scenes are long gone. With AI and other technologies ingrained in every aspect of the business, the CIO must lead well beyond IT.

By making collaboration a priority, you can gain critical insights across teams to guide your tech strategy, and deliver the greatest value to your organization.

If you’re like most CIOs, your CEO’s viewpoint of and strategic outlook for AI has likely shifted several times over the past two-plus short years, perhaps even in contradictory ways. Initial doubts or disregard may have given way to full-out FOMO. Demands for copilots everywhere in everyone’s hands may have experienced pullback as the bills and questions of value mounted. Rampant experimentation turned to targeted use cases. Pressure for widespread AI adoption narrowing as “tokenmaxxing” and “tokenomics” entered the lexicon.

Now, with frontier labs showing what can go wrong with “agent misalignment,” AI failures hitting the news, and questions of liability still lingering, trust in AI — and their CIO’s AI strategy — is becoming a key CEO concern (once again).

As the executive setting the company’s course for AI, the CIO is expected to make every AI project pay off, to instill trust in AI for all stakeholders, and to guarantee that nothing unforeseen and unfortunate happens. As a result, the stakes are high, with CIOs already blamed for any AI misstep and, according to IDC, at risk of future firings as lawsuits, fines, and AI incidents rise through 2030.

The only way for CIOs to meet this moment is to establish governance, security, data quality, AI model quality standards, and metrics for business ROI, with a clearcut means of shutting systems down if systems become a risk.

Doing this will take time and money at a time when CEOs are being pressed to show results from AI. It will also require clear and compelling explanations of why all these steps are necessary, how these steps fit into a total corporate AI strategy, what checkpoints can be set to assure that business metrics and investment return goals are met, and how AI should be addressed in the corporate risk management plan.

Here are the essential steps CIOs should take to build trust in their companies’ AI implementations.

1. Require quality data, quality AI models, and business-relevant metrics before projects are launched

To date, many organizations have run their AI projects in “sandbox” mode. They try out different AI models and algorithms, without paying as much attention to the data and the metrics. Here, the most quoted evidence is from MIT’s 2025 AI survey, which found that enterprises had invested nearly $40 billion for generative AI, with 95% of those projects reported as yielding no return.

This year, AI’s honeymoon period has shown signs of being over. CEOs are expecting not only results but returns on their investments. This will only grow louder in 2027. And the only way to get results is to ensure that AI projects use high-quality data, that AI models are developed and maintained to the highest quality, and that clear metrics for investment return that tie to specific business use cases and outcomes are in place.

CIOs must preemptively take the lead in setting AI culture and work standards. Only from that position can trust follow.

2. Run tight, controllable projects

Recent incidents involving OpenAI, Anthropic, and Google have shown what can go wrong when AI goes rogue. No enterprise CIO wants this to happen on their watch.

To avoid this, AI projects should be structured with domains of knowledge and functions limited to the environments that they operate in (e.g., support for a call center). These AI projects should not try to do too much at first. As confidence is gained with the AI and its results, scope can be expanded.

A slow, proof-based approach to agentic AI will be essential to ensuring stakeholder trust.

3. Have an AI shut down valve

If an AI project goes awry, do you have a way to shut it down and mitigate any damage?

How to turn an AI system off should be one of the first tasks defined in any AI project plan. It’s equally important to take this one step further — by incorporating shutdown and restoration steps for every AI system in the enterprise. This can be done by including AI in corporate disaster recovery and risk management plans.

For a more granular look, see our partner publication CSO’s “Why you need a reliable AI agent kill switch” and “Securing AI agents: Key controls and best practices.”

4. Consider engaging an auditor to monitor AI security, governance, and compliance

There will always be corporate functions — sales, marketing, engineering — that will want to skip governance and get to running AI systems. In companies that stress R&D, there might even be some resistance from the board and CEO, who want to avoid “red tape” and slowdowns.

Regardless of company culture, it will be up to the CIO to advocate for system security, compliance, and governance to ensure AI safety and risk management. CIOs can get around this quandary by hiring an outside audit firm to monitor AI systems for security, governance, and compliance, regularly reporting to the board and citing any irregularities that must be corrected.

5. Pick the right vendors

Vendors offering AI systems or services must have the same level of commitment to quality AI that your company does. AI vendors should be vetted not only for their products and the data that they use, but for the strength of their support, security, governance, compliance, and ability to recover from a disaster.

CSO has more on what IT leaders should consider here, from an AI security vendor lens: See “Key questions CISOs must ask before adopting AI-enabled cyber solutions.”

A final wrap

Harris/Dataiku surveyed 900 CEOs earlier this year, and 80% said their role was at risk if they didn’t deliver AI results by the end of 2026. Moreover, 57% believed that “insufficient AI explainability could trigger a customer trust or brand credibility crisis.”

Trust in AI has become a major issue for CEOs and their boards. Ensuring AI trust should be at the top of CIO AI to-do lists.

The digital twin concept earned its credibility in engineering. Its origins trace to a 2002 University of Michigan presentation in which Michael Grieves described a “Mirrored Spaces Model”: a virtual system holding the information about a physical one, linked to it throughout its life.

For example, a jet engine manufacturer builds a precise virtual replica of a physical turbine, feeds it real-time sensor data, and runs simulations that predict failure before it occurs, optimize maintenance intervals, and test design modifications without touching the physical asset. This model is invaluable because the cost of being wrong about a turbine is high, the variables are measurable, and the physics are well understood. Organizations have applied the same principle to factory floors, supply chains and urban infrastructure, each time with the same underlying logic: a dynamic model of a complex system allows continuous optimization that periodic review cannot match.

However, the enterprise itself has received only part of that treatment. Even Gartner now evaluates organizational digital twin platforms as a category, describing them as dynamic models of how an organization operationalizes its business model, deploys resources and delivers customer value. Yet most of these twins model how work flows, not what it is worth, and that gap is consequential.  

A dynamic model of the enterprise

Still, most large organizations still navigate strategic decisions with a picture of themselves that is static, incomplete and economically unattributed. Org charts describe reporting relationships as they were drawn at the last reorganization rather than how people actually interact. Process maps describe intended or designed workflows, not actual ones. And planning documents describe resource allocations as they existed at the time of the last budget cycle. None of these artifacts answer the question that matters most for strategic decision-making: what is the work actually worth, at the level of granularity required to improve it?

A living model of the enterprise changes what is possible. Imagine a representation of how work actually flows across functions (not as designed or conceived, but as executed), where decisions accumulate and slow, where handoffs lose information, where risk concentrates until it surfaces as an incident, and where resources are applied to activities whose economic contribution has never been examined. Connected to real-time operational data, that model moves leaders beyond the static artifacts that currently substitute for organizational self-knowledge.

But a model of how work flows is useful only for operational diagnosis, not a complete economic understanding. Strategic redesign requires knowing what the work measurably produces at the level of individual activities, decision points and handoffs.

Enriching the digital twin with economic process modeling

As I have discussed in previous pieces, Economic Process Modeling (EPM) provides that additional layer. By decomposing processes into their constituent components and attributing value across five dimensions (revenue contribution, cost and friction, risk exposure, option value and information value), EPM transforms a process map from a descriptive artifact into an economic instrument.

The output is not a flowchart but a value ledger: which components are value drags that cost more than they contribute, which are misaligned (a person doing a system’s job, or the reverse), and where value is created but never collected, usually as data the process discards. That is the side of the business case that cost accounting alone cannot show. It is the value layer the enterprise digital twin needs to support strategic decisions rather than merely operational ones.

Douglas Laney

Enterprise, know thyself

The practical benefits of an enterprise digital twin featuring EPM are compound:

• It enables businesses to model the P&L consequences of a restructuring before headcount decisions are made.
• It surfaces the process components where AI investments could generate the highest return per dollar–rather than requiring that prioritization to be resolved through stakeholder negotiation and executive sponsorship, which is how it is currently resolved in most organizations.
• It makes visible the information assets being generated and destroyed by current process designs.
• And it shows where risk is concentrating in operational workflows before that concentration produces a regulatory finding or a customer failure.

These are not incremental improvements to existing planning processes; they represent a different quality of organizational self-knowledge.

What makes this achievable rather than speculative is that the required inputs exist in most large organizations already. Process mining tools extract actual workflow patterns from system logs,  ERP and CRM systems hold the operational and customer data needed to attribute revenue and cost at component level, and risk systems hold the exposure data.

The missing element is the economic model that sits above the infrastructure, translates operational patterns into value attributions, and makes the enterprise legible as an economic system rather than a collection of functions.

Economic process modeling in action

CentrePort, is the port and logistics operator in Wellington, New Zealand. Its CentreConnect freight service generated a high volume of small inter-port charges, each reviewed and reconciled by hand by a small commercial team working from spreadsheets. Rather than automating first, the company modeled the invoicing workflow down to individual container movements, linked each activity to time and cost data, and tested standardization and automation scenarios before committing to change.

Processing time per invoice fell from 25 minutes to 23 seconds. But the more telling outcomes were those a throughput metric would miss: fewer financial discrepancies and less overpayment risk, stronger data governance than spreadsheets allowed, and groundwork for scaling volumes without adding staff. Those are risk, information and option value, not only cost.

CentrePort has since applied the approach to other commercial processes and now treats it as a precondition for change.  “Before undertaking any projects, we now ensure that the current state is understood, along with the upstream and downstream impacts of change,” said Tanya Dednam, Head of Digital.

The evolution from physical to enterprise digital twins

As many businesses and the global economy continue to shift toward digital, AI-based and services-oriented offerings, economically modeling the enterprise can become more important than modeling physical things.

However, the analogy to physical digital twins carries an important limitation: Turbine physics are stable whereas organizational economics are contested, context-dependent and subject to strategic choice. An enterprise digital twin built on EPM does not produce a single authoritative answer about what a process component is worth. It produces a structured basis for the argument, with explicit assumptions that can be examined, challenged and revised as conditions change, which is precisely what distinguishes a useful analytical framework from the static planning artifacts it replaces.

The competitive advantage this capability confers is not in the model itself. Rather, it is in the organizational discipline of making economic attribution a continuous practice, of treating the enterprise as an asset to be actively managed rather than a structure to be periodically reorganized when the last reorganization stops working. And rather than an enterprise-wide focus, the practical aperture is a single process with high economic exposure–ideally one already under transformation or AI investment pressure, modeled well enough to inform a real decision or action.

Organizations that model, measure and analyze the EPM-enhanced digital twin of their processes will be able to adapt, optimize and transform with significantly greater agility than those navigating with onerous org charts and planning PowerPoints.

Imagine a support team working through complaints after a service outage. Its refund policy normally requires an eligibility review. For this incident, an authorized manager approves an exception: customers on the verified outage list may receive up to $100 without individual review, through Friday.

An agent processes those cases successfully. Later, the system consolidates those case histories into a reusable memory: small, immediate refunds resolve service complaints quickly. The summary preserves the outcome but loses the outage restriction and expiration date.

The following week, the agent retrieves that guidance for a similar complaint from a customer who was not affected by the outage. It issues a refund without review. The payment service checks the agent’s credentials and the dollar limit, but does not check whether the customer qualifies for an active exception.

No attacker is needed in this hypothetical. The case may close faster, yet the agent has begun applying a temporary exception beyond its authorized scope.

Has the company authorized the agent to find a better way to handle refunds, or to change who gets one without review? Those are different decisions.

Learning does not always mean retraining

In September, Salesforce introduced Agent Optimizer in beta to analyze production behavior, propose improvements and build and test changes. Customers choose review points, including how far the system may proceed toward staging changes for deployment.

An October 1 AWS implementation guide illustrates a different mechanism: consolidating individual observations into generalized memories that agents can retrieve and share. Its investment-research example shows how experience can become persistent context without retraining a model.

Updating stored memory changes information available to later runs. Editing instructions or workflows changes how the application directs the work. Training changes the model’s parameters. All can alter behavior, but teams inspect and approve them in different ways.

A reviewed workflow revision has a release step. A new memory may enter through routine data processing and influence the next customer interaction. The code, model and tool permissions can remain unchanged while the guidance shaping decisions changes.

Preserve the authority behind the lesson

In the August preprint When Memory Becomes Authority, Qiuyang Zhan and colleagues examine whether consolidation preserves who supplied information and what that source is allowed to authorize. In their controlled benchmark, memories could retain a claim while losing the source-authority distinctions needed for a later action. Preserving authority metadata reduced authorization errors in the pipeline they tested. The study does not measure how often this happens in deployed enterprises.

The refund example concerns a related boundary: permission for particular customers and dates must remain limited to those conditions. Success with last week’s cases cannot establish that other customers qualify.

Microsoft’s memory-safety guidance treats persistent memory as a layer that can shape behavior and recommends treating retrieved memories as candidate context, not authoritative truth. Knowing what happened before does not establish what is allowed now.

Keep the exception’s scope, approving authority, source and expiration in a controlled record. Reusable guidance should retain a reference to that record, but a reference alone does not grant permission. The system must still check that the approval applies to this action, for this customer, at this time.

For a payment, enforce those conditions outside the agent’s editable guidance. The execution service should check the authoritative outage list and the exception’s current status, rather than accepting the agent’s claim that a customer is eligible. Neither the agent nor its learning process should be able to rewrite that authorization record.

This is a familiar authorization requirement. If the backend already enforces it, the improper payment is blocked. But faulty guidance can still lead the agent to promise a refund or prepare a misleading recommendation for a reviewer. The evaluation needs to examine those communications as well as the transaction.

When a case calls for judgment beyond the agent’s delegated discretion, route it to someone authorized to decide and show the conditions behind the recommendation. The memory can still help assemble the evidence.

Define what improvement the business has delegated

Not every stored observation needs a manager’s signature. A support agent could learn a faster way to gather the required evidence, provided it still uses approved sources and meets the policy’s requirements. A policy might also already delegate limited discretion. Using that discretion within its terms does not require a new approval each time.

Broadening eligibility, raising payment limits or removing mandatory review requires a separate business decision. Keep those proposals separate from approved instructions. An automated classifier may flag a proposal that changes those conditions, but it cannot catch every consequence of an edit. The conditions must remain binding even if the classifier misses it.

The refund-policy owner should decide whether to expand the exception. Engineering should show the current rule, the proposed behavior and cases where the decisions differ. “Customers outside the outage list would now receive refunds without review” is more useful to that owner than a screen full of prompt edits.

Measure legitimate completion and policy violations separately. Faster closure cannot compensate for an unauthorized payment. Keep the business rules and evaluation criteria outside the control of the process proposing improvements. Tests generated from successful outage cases may check execution, but they do not establish eligibility for unrelated customers.

Ask the vendor or internal team: What can the system change between releases, and which business conditions remain binding after it does?

Test whether the exception stays an exception

Ask the team to demonstrate this sequence in a test environment with the memory and workflow components intended for production. Save the memory before and after learning. Compare the same cases against each saved state, keeping the model, tools and policy fixed.

Repeat representative trials. The τ-bench research offers a useful precedent: it checks customer-service agents against database outcomes and measures reliability across repeated attempts. One successful run is not enough.

1. Establish the baseline. Record the outage authorization, eligible customer list, amount limit and expiration. Show who can change them. Test a qualifying case and closely matched cases that require ordinary review. Confirm that the system can distinguish them before learning begins.
2. Run the actual learning process. Inspect the resulting memories or proposed instructions and their links to the original authorization. Check whether the limits survive consolidation and retrieval. Also test a deliberately incomplete lesson: omitting a condition must not change who qualifies for a refund.
3. Repeat the boundary cases. Compare behavior before and after learning, changing one relevant condition at a time: a customer outside the list, an expired exception or an amount above the limit. Inspect customer messages, review recommendations, attempted tool calls and actual payments. Count blocked attempts separately from completed violations. A blocked payment does not mean the underlying guidance is sound.
4. Withdraw the exception. Revoke it before its scheduled expiry and test another agent that can retrieve shared guidance. Include a refund queued before revocation but executed afterward. Show when withdrawal takes effect, how execution checks enforce it and how derived memories and caches are updated. If current authority cannot be established, the payment should wait for review. Historical records can remain without authorizing new transactions.
5. Demonstrate a permitted improvement. Let the agent adopt a faster way to gather the required evidence. Compare eligible and ineligible cases with the prior approach. Show that legitimate work becomes easier while review requirements remain intact. A system that rejects everything has not passed this test.

Keep test runs from influencing one another through newly stored memories. Retain the guidance supplied to the agent, the applicable policy version, execution checks and outcomes, with appropriate access and retention limits. These records help investigators reconstruct what the system had available; they cannot establish exactly how each memory influenced a response. Continue checking the same boundaries as production memory accumulates.

Keep the useful lesson

The support team should benefit from what its agent learns. It can assemble records sooner, explain the outage more clearly and propose a broader refund policy with evidence for the manager to consider. Until that proposal is approved, other claims should continue through the ordinary process.

At the next deployment review, ask which improvements the business has delegated as well as which actions the agent may take. A successful exception can teach an agent something useful. The decision to make it a standing practice still belongs to the business.

There’s no point building your own agentic AI stack for a non-core function when a vendor already has a product ready to go that meets your needs. For non-tech companies in particular, building from scratch can take time, money, and expertise they don’t have.

Take for example, Fertitta Entertainment, with more than 600 Landry’s restaurants and the Golden Nugget hotel and casino. After the pandemic, the company had problems adequately staffing its call centers, says its director of contact center operations Brian Jeppesen. “The agents didn’t want to come back,” he says.

The virtual assistants didn’t work because the user experience was bad, and with the incoming call volume, 40 to 50% of them were abandoned.

“Everybody wants AI, but nobody wants BS,” Jeppesen says. “I talked to my CFO. This is what we’re abandoning. This is the potential revenue we’re losing. I can’t throw bodies at it anymore.”

Agentic AI has upped their game for the virtual assistants. Instead of only answering simple questions like check-in hours, it allows the company to connect APIs and carry out more complicated tasks, like making reservations.

“My abandonments fell to under 10%,” says Jeppesen. “From waiting 45 minutes to an hour, they can get their questions immediately answered, or immediately transferred and taken care of.”

And turnover went down. Call centers typically see 100% turnover, says Jeppesen. Not because everyone quits, but because the bottom 25% quit and need to be replaced over and over again.

Now that bottom tier doesn’t have to be rehired, while the people who stay are the most knowledgeable. “They give a better experience for my customers,” he says. “And it reduced my attrition by 50%.”

Forrester did a total economic impact study for the specific vendor that Fertitta used, PolyAI, and the ROI came back at 391% over the course of three years, with a payback period of less than six months.

Jeppesen says he reviewed his own numbers and found that the automated reservations system alone brings in 3,000 reservations a month. “That’s $600,000 in revenue a month for us without the need to speak to an agent,” he says.

Next, Fertitta plans to expand it to handle to-go orders and web chats. There are also opportunities for agentic AI on the technical help desk, Jeppesen says.

Agentic AI on the menu

Fogo de Chão, a Brazilian restaurant chain with around 120 locations, is also deploying agentic AI in small, focused use cases, and sees ROI with some of the projects.

For instance, it deployed virtual call center agents from PolyAI, and saw positive ROI from day one since there were no significant up-front costs or usage-based pricing. After several months of testing and small-scale pilots in 2025, the system has been rolled out across the US, with 100% of calls now being answered instead of up to 25% being dropped, and a 10% increase in total bookings that wouldn’t have happened otherwise, says Michael Breed, the chain’s chief marketing officer.

“If we compared it to a media channel, it’d be twice the ROI from other media channels,” he says. “It’s almost like another customer acquisition vehicle.”

The company is also building agentic workflows for its team members.

“We’ve identified jobs that are very repeatable and time-consuming, and we’re training agents to take those tasks,” he says. These are low-risk jobs, like proofing menus or other text, or replacing manual processes, such as pulling data from one system into another that had no automatic integrations.

“The agent does a great job bringing in the data, then the human in the loop can inspect it,” says Breed. “Is it getting classified right? Is it getting to the right places? And when guests are dissatisfied, can we make it better?”

Built for SMBs

For smaller companies in particular, off-the-shelf agents make the most sense. AltaClaro, for example, builds training simulations for lawyers, and counts more than 100 of the top 200 US law firms as customers, all with just 10 employees.

One product is a deposition simulator, says CEO Abdi Shayesteh, a completely agentic, voice-based platform.

“It’s a fully simulated environment that creates the experience of doing the deposition,” he says. “Different agents play the role of the witness, opposing counsel, and the court reporter.”

He says it’s kind of like a Zoom call. The product is built on top of technology from Verbit, a legal tech company with a custom agentic platform.

“They’re taking care of the technical infrastructure and we have the material to ground the AI.”

A different vendor, Credal, provides a secure AI platform that allows AltaClaro to switch between different models. It can obfuscate names and keep other sensitive data from leaking out, Shayesteh says. “It ensures everything is anonymized and does secure calls,” he says. “We standardized on Credal because it’s highly flexible and secure. We serve law firms and we’re as invested in security as they are.”

But security isn’t the only issue that enterprises face when deploying agentic AI.

The hidden costs of buying AI

The temptation to jump into agentic AI is high, says Dana Simberkoff, chief risk, privacy, and information security officer at AvePoint Inc., a data security company. And off-the-shelf agentic AI can be so easy to adopt that companies deploy it before they’re prepared for it.

Enterprise vendors will often add the technology at no extra cost, just to get people using it, and companies turn it on for their employees before truly understanding what it does, and before systems and workflows are ready. “Then it immediately exposes problems that were already there,” she says.

Say, for example, an agent helps with research, normally considered a low-risk task.

“AI will follow sharing links across documents,” she says. “So if you haven’t taught your users how to properly use sharing links, the AI agent is just going to follow that path, and it could expose information that might have been obscured in the past. It’ll gobble up everything it can.”

The result is it could expose HR data, personal information, or proprietary information to people who shouldn’t have access to it. One company she knows had to shut down their AI project immediately and go back, classify, and label all their information, put governance controls in place, and teach people how to apply metadata.

According to Gartner, by next year, 40% of enterprises will demote or decommission autonomous AI agents due to governance problems that only show up after they’ve gone into production.

Token management

Another hidden cost of off-the-shelf AI? Token use. When agentic AI is embedded into a system that a company is already using, then the cost of switching it on can be as low as zero. But someone has to pay for all that token use.

When agentic AI comes out of pilots and goes into production, usage can change dramatically, and token costs can quickly spiral out of control. It doesn’t help that agentic AI use typically requires much more tokens than AI chatbots.

“A lot of the embedded AI should be utilized,” says Doug Vargo, head of the national AI and alliances team at consulting firm CGI. “If big parts of your business processes are living and breathing in ServiceNow, Salesforce, or another application, you should leverage that, but you need to understand the cost.”

This is playing out in the marketplace right now, he adds, as underlying model providers change their token costs.

“That changes the economics of the decisions,” he says. “And six months from now, it’s a different discussion, because they’re going to continue to move the needle.”

The employer’s prerogative

Another hidden cost that companies might miss is they need to put training and support systems in place for employees. Many off-the-shelf agentic AI tools might seem easy to use, but actual adoption still requires change management. CGI did offer training to employees when it rolled out GitHub Copilot, a popular coding platform with agentic functionality. “And we expected them to adopt and leverage it on day one,” says Vargo. But people quickly went back to their old ways of working, he says, and CGI had to pivot its strategy.

“It’s going from training programs to habit formation or transformation programs,” he adds. “And we’ve seen adoption skyrocket.”

The change isn’t in just how individuals adopt AI to improve their own work, though. “You’re now a manager of 10 to 20 specialized agents that are driving that work for you,” he says.

The error is when companies put the technology first. “They fall in love with the tech or a vendor, but they’re not really thinking about how they’re truly integrating these tools and technologies into the business.”

Embracing change

Change management is a particular challenge with agentic AI because the tools are changing at such a fast pace.

“It’s technology that’s constantly changed almost every month, or maybe every week,” says Scott Likens, chief AI engineer at PricewaterhouseCoopers. “The challenge I see is the timescale of change is much faster than what we’re used to.”

We’re still in the early stages of agentic AI, he adds, and waiting isn’t a good strategy. “You have to start, but keep flexibility over longevity in mind,” he says.

For Luis Huerta, group head of gen AI and agentic automation at International Airlines Group (IAG), change management is one of the most complex parts of agentic AI adoption, as it uses agentic AI to improve customer experience, operations, and efficiency.

“The technology is powerful, but the bigger shift is organizational,” he says. So the company isn’t just focusing on building agents, but also on business ownership, adoption, and governance, and helping colleagues understand how these capabilities change the way work gets done and how it can support them, rather than replace them.

Huerta says IAG also uses agentic capabilities embedded in enterprise platforms, but also builds its own agents, too.

They’re not alone. According to Anthropic’s 2026 State of AI Agents report, 47% of organizations take a hybrid approach to AI agents, while 21% rely entirely on pre-built agents, and 20% build their own.

“We take a technology-agnostic approach,” says Huerta. “Our priority is to select the right solution for each use case.”