Claude Code has quickly become one of the most widely adopted AI agents in the enterprise. Developers use it to write and refactor code, troubleshoot builds, run tests, and manage infrastructure, often by describing an objective and letting the agent determine the steps required to accomplish it.

That autonomy is the point. It is also why Claude Code is a governance decision for CIOs, not just a developer tooling choice. Claude Code runs locally on employee workstations, executes commands with the developer’s permissions, and can reach source code, credentials, cloud environments, and connected services as it works.

Anthropic has given enterprises meaningful controls to govern how Claude Code behaves, including centrally managed settings and hooks. These controls are essential. But controls that evaluate what an agent intends to do are not the same as visibility into what it actually does.

Here are five things CIOs need to understand to secure and govern Claude Code at enterprise scale.

1. Claude Code acts with your developers’ authority

Consider a developer who asks Claude Code to fix a failing build. The agent might read the codebase, install a dependency, run a setup script, edit a configuration file, query a cloud environment, and validate the result. One human instruction becomes a sequence of actions across multiple systems, all conducted with the developer’s level of access.

And it happens at machine speed. CrowdStrike internal usage data found that endpoint AI agents consumed roughly 700 times more tokens than humans using AI chatbots via the browser. Every one of those interactions is an opportunity for the agent to read, write, or execute something.

For CIOs, the question is no longer whether Claude Code makes developers more productive. It is whether the organization can account for what the agent does on its behalf.

2. Claude Code hooks are a strong first line of governance

Claude Code includes native governance capabilities that every enterprise deployment should use. Managed settings let IT define policies that individual developers cannot override. Permission rules determine which tools and commands the agent can use. And hooks give organizations programmable checkpoints throughout the agent’s life cycle.

Hooks run automatically at defined moments: when a session starts, when a user submits a prompt, before the agent uses a tool, and after that tool completes. At each checkpoint, a hook can inspect the proposed action and allow it, block it, log it, or require human approval. Organizations use hooks to stop commands that touch production credentials, prevent edits to sensitive directories, and send a record of agent activity to security teams.

If your organization is deploying Claude Code without centrally managed settings and hooks, start there. Treat hook configurations like any other security policy: version them, enforce them centrally, and review them as your use of agents matures.

But it is equally important to understand what hooks were designed to do, and what they were not.

3. Hooks see the checkpoint, not what happens next

A hook evaluates the action an agent is about to take: the command text, the file path, the tool being called. It does not follow that action into the operating system to see what it actually causes.

That distinction matters. A command such as “npm install” or “python setup.py” looks routine, so the hook approves it. The script that runs may then spawn additional processes, read cloud credentials from the developer’s machine, and open an outbound connection to an unknown destination. None of that activity passes back through the checkpoint.

The same applies to Model Context Protocol (MCP) servers, package install scripts, and other processes the agent launches. A hook can see that the agent requested an MCP tool. It cannot see what that server then does on the endpoint or the network.

Hooks are also rule-based. A rule that blocks a known-dangerous command will not necessarily catch an encoded payload, a script the agent writes and then runs, or a chain of steps that each look harmless on their own. Hooks are a policy enforcement point, not a detection and response system.

4. The most consequential decisions happen between checkpoints

Agents reason continuously. Between tool calls, Claude Code is reading files, documentation, web content, and tool output, and deciding what to do next. This is where risk often takes shape.

It is where indirect prompt injection lands, when instructions hidden in a README file, a third-party dependency, a web page, or an issue ticket redirect the agent’s behavior. It is also where agentic misalignment emerges, when an agent pursues a legitimate objective in an unsafe way, such as uploading sensitive data to a public service because it is the fastest way to finish the task.

Hooks do not observe that reasoning. They see only the next proposed action, which may look entirely normal. A manipulated or misaligned agent does not need to break a rule at any checkpoint to cause a breach.

This is not a theoretical concern. According to the CrowdStrike 2026 Threat Hunting Report, CrowdStrike is seeing AI agent-triggered detection leads at 2.5 times the rate of human-triggered leads.

There is also a scope challenge. Hooks govern Claude Code on the machine where they are configured. Most development teams use several AI agents, including Claude Code, OpenAI Codex, GitHub Copilot, and Cursor, and security teams need a consistent, fleet-wide view across all of them.

5. Runtime execution visibility closes the gap

If hooks govern what an agent intends to do, runtime execution visibility verifies what it actually did.

Runtime visibility means observing the activity an agent causes on the endpoint, including the processes it launches, the files it accesses, the network connections it makes, and the credentials it touches, and connecting that activity back to the prompt and agent session that initiated it. This creates a causal chain from prompt to agent activity to runtime impact.

That chain is what allows security teams to answer the questions that matter during an incident: What did the agent do? What did it touch? Was that behavior intended? And how do we stop it?

There is a useful precedent. A decade ago, signature-based antivirus checked files at the door, and attackers learned to walk past it. Endpoint detection and response (EDR) changed security by watching behavior at runtime. Agents require the same shift. AI executes on the endpoint, so that is where it must be secured.

CIOs can use five questions to assess where their organization stands:

• Which AI agents are running on our endpoints today, and who is using them?
• Are our Claude Code policies centrally managed, or configured by individual developers?
• If an agent ran a malicious script that passed our hooks, would we see it?
• Can we trace an incident from the prompt that started it to its impact on our systems?
• Who is alerted when agent behavior moves outside intended boundaries, and how quickly can they respond?

Hooks and runtime visibility are not competing approaches. They are complementary layers. Hooks enforce policy at the points where an agent asks to act. Runtime visibility watches everything that happens as a result. Hooks tell you what the agent asked to do. Runtime visibility tells you what it actually did.

CrowdStrike helps organizations secure AI agents with AI detection and response (AIDR) in the CrowdStrike Falcon® platform. CrowdStrike Falcon® Guardian integrates with Claude Code hooks to bring agent activity into the Falcon platform, connects that activity with runtime behavior on the endpoint, and gives security teams the context to investigate and respond when agent activity creates risk.

Learn more: Explore CrowdStrike’s AI security to see how organizations can secure AI agents across the agentic lifecycle.

Meta has hit pause on new terms of service for its business customers that would have granted it the right to grab any content from their websites. Not only that, but it would also have shifted the blame for every error produced through faulty AI to its customers.

The new terms of service were revealed on October 19 and initially due to take effect on October 30, though Meta later pushed the start date back to November 20.

But that small delay wasn’t enough to calm customer pushback, and now Meta has posted a note on Facebook’s business help center saying that the update had now been paused indefinitely.

Given the strength of feeling, Meta’s U-turn will not have come as a surprise. The terms would have been seen as far too onerous for customers, as well as exposing them to a legal minefield of the sort that UK regulators recently warned about.

In a statement to Harvard’s Nieman Lab, the company said that “We’re pausing the changes as we continue to engage with stakeholders and take our time to get this right.”

Meta has had a troubled time recently. Two weeks ago, it was fined for illegal use of customers’ data and in May, the company laid off 8,000 employees.

The UK’s digital watchdogs have warned enterprises that they can’t evade their legal responsibilities by blaming errors on AI agents that they have deployed.

“By taking action on behalf of users, such as making purchases and communicating with businesses, these agents could transform how people use digital services, engage with markets and unlock wider innovation,” said the Digital Regulation Cooperation Forum (DRCF), a body comprising the UK’s Competition and Markets Authority (CMA), Financial Conduct Authority (FCA), Information Commissioner’s Office (ICO), and communications regulator Ofcom, in a joint statement.

While the DRCF welcomed such uses it advised, “firms developing or deploying personal agents should think carefully about how consumers can understand when and how an agent acts on their behalf, how authority to act is given and how their personal data is used.”

The DRCF didn’t pull its punches. “We want to be explicit that existing legal and regulatory frameworks apply to personal AI agents, including competition, consumer and data protection law, online safety, financial services, payments and cyber security requirements,” it said, adding, “An AI agent’s autonomy does not diminish the responsibility of organisations that deploy it to comply with applicable law and relevant regulation.”

There is certainly a degree of uncertainty over the legal position of autonomous AI agents. Gartner has warned that companies are increasingly facing legal challenges over “AI-induced” decisions, while attorneys have weighed in over gray areas in AI governance.

The four UK regulators aren’t immune to that doubt: Only a few weeks earlier, they issued a Call for Input on their 2027-27 work plan to help them avoid overlap and uncertainty about the interplay between their respective regulatory regimes.

OpenAI is buying Pierre Computer Company in order to incorporate the San Francisco-based software developer’s Code.Storage infrastructure layer for Git into its Codex AI-powered programming tool.

Pierre Computer, whose employees number just barely in the double digits, has got plenty of clout for its small size. It’s well-known for Code.Storage offering, as well as for its open-source software libraries, Trees and Diffs, which OpenAI already uses in Codex.

OpenAI has experienced some of the limitations of Git itself, and its in-house engineering teams are already working to improve its support for human coders and AI agents working in parallel. Earlier this week the company described how it built a new back end for Git repositories, Pando, to enable concurrent working at scale.

The AI developer has been pushing Codex more aggressively this year: offering it to Mac users and expanding it to Windows. It cited Pierre Computer’s ability to help developers review code as one of the reasons for the acquisition. OpenAI highlighted the Diffs’ Edit mode and the recently released Highlights as components that were particularly helpful to development teams.

Announcing the deal on its news page, OpenAI set out how it would integrate the company into its existing offerings. “With the Pierre team, we wish to set the standard for modern software development: from the first branch an agent creates to that magic moment when code is deployed to the world. We want to make Codex the place where developers and agents take on their most ambitious projects.”

Neither company disclosed details of the acquisition price. OpenAI said that Code.Storage customers will be able to continue using the product until it brings the features into Codex, while Pierre Computer’s open-source projects will remain open, and OpenAI will continue to contribute to them.

This article first appeared on InfoWorld.

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.   

The new year will see a new CEO for HP, which after a nine-month search has named Emma Walmsley to lead the company from January 4, 2027.

Walmsley was previously CEO of drug company GSK, where she turned around its finances and spun off its consumer healthcare business into a new company, Haleon. She has a reputation for courting confrontation rather than yes-men in the boardroom. HP needs a shake-up as revenue from printing declines and AI-driven demand for components is forcing up PC prices.

She will take over from HP’s interim CEO Bruce Broussard, who stepped in in February when former CEO Enrique Lores left the company after more than 25 years to become president and CEO at PayPal. There’s a consolation prize for Broussard, who will become chair of HP’s board, succeeding Chip Bergh who remains a board member.

Although Walmsley has been on Microsoft’s board for seven years (she is stepping down in December), this is her first foray into leading a tech company. Her almost 16-year tenure at GSK included more than eight years as CEO, and earlier in her career, she spent 17 years at L’Oréal.

Bergh said that during the executive search, she stood out “for the strength of her leadership experience across multiple industries, the clarity of her strategic thinking and her ability to translate customer insights into new growth.” He particularly cited her people-first leadership approach.

Walmsley reiterated her commitment to the philosophy in a post on LinkedIn. “HP has an extraordinary innovation heritage, an inspiring purpose and an incredible opportunity ahead as AI reshapes technology and what customers need from it. I’m excited to build on those strengths and help translate innovation into impact,” she wrote. “Behind every innovation are the people who work to make someone’s day a little easier, their work more productive, their ideas possible. In an age of AI, I believe human leadership has never mattered more. It’s a privilege to be joining this team.”

Announcing Walmsley’s appointment Broussard said, “We need a leader who can build on our innovation heritage and strengths to boldly shape the company’s future. Emma is a proven CEO with a track record of leading organizations at scale and guiding them through significant change. She has the experience and skills to bring HP’s businesses, capabilities, and people together to capture the opportunities ahead as AI moves to the edge, transforming how we work and live in a more connected world.”

This article first appeared on Computerworld.

The conversation about agentic AI is shifting: Rather than focusing solely on what the technology can produce, IT leaders are now considering what they are prepared to let it do. 

Unlike traditional AI assistants that primarily respond to user prompts, agentic AI systems can make decisions and execute actions autonomously across business processes. This creates opportunities to accelerate workflows and improve productivity but also introduces new challenges involving risk and organizational readiness.

The shift is already well under way. In a recent HCLTech survey, 87% of the participating enterprises reported using generative or agentic AI in IT operations, underscoring the growing importance of effective governance. These challenges were central to a recent HCLTech and Google Cloud roundtable on the business impact of agentic AI in which the participants explored what it takes to move from experimentation toward enterprise-wide adoption.

Agentic AI is showing promise across a wide range of business functions, including IT operations, software engineering, customer experience, HR, marketing, finance, and sustainability. Across these areas, intelligent agents can streamline complex workflows; automate routine tasks; and support faster, more informed decision-making.

Realizing potential

But realizing that potential requires more than deploying new technology. Successful implementations begin with identifying high-value use cases, establishing measurable key performance indicators (KPIs), and connecting AI initiatives to specific business outcomes.

Roundtable participants highlighted concerns about cost, ROI, and insufficient testing, reinforcing the importance of a measured approach to adoption. To manage these risks, organizations are typically starting with lower-risk business processes, demonstrating tangible value before expanding their use of autonomous agents as confidence and capabilities mature. Those concerns are reflected in HCLTech’s AI Impact Imperatives 2026 research, conducted by Omdia, which found that respondents expect approximately 43% of their major AI initiatives to fail.

Rethinking governance for autonomous systems

As AI moves from assisting employees to acting on their behalf, traditional approaches to governance and compliance may prove inadequate. Autonomous agents introduce operational and reputational risks that require organizations to reconsider how decisions are monitored, audited, and controlled.

Governance must be built into agentic AI initiatives from the outset rather than added after deployment. That includes establishing clear boundaries for autonomous agents and determining where human intervention remains necessary. Human oversight is particularly important in high-stakes areas such as financial transactions, regulatory compliance, cybersecurity, and decisions affecting customers or employees. The appropriate level of oversight should reflect the potential business impact and risk associated with an agent’s actions.

Clear accountability, transparent decision-making, and escalation mechanisms can help organizations balance greater autonomy with continued human control over critical decisions.

Preparing for new ways of working

Technology alone won’t determine whether agentic AI succeeds at enterprise scale. Organizational readiness is another major hurdle, requiring businesses to align data, governance, people, and processes around common objectives. Change management and AI literacy are particularly important. Employees across technical and nontechnical roles will need new skills to supervise agents, evaluate their decisions, and collaborate effectively with autonomous systems.

As agents become increasingly integrated into business operations, organizations will also need to reconsider how their performance is managed and measured. Over the next several years, enterprises may see the emergence of hybrid teams in which employees focus more heavily on strategic decisions and oversight while AI agents take on more operational responsibilities.

Achieving this vision will require organizations to rethink operating models and invest in workforce readiness alongside technology. Ultimately, the autonomous enterprise will be defined by how effectively AI agents are integrated into business operations and deliver measurable results, rather than simply by how many agents an organization deploys.

Learn more about how HCLTech and Google Cloud are helping enterprises navigate the transition to agentic AI. 

The true promise of agentic AI lies in agents maneuvering, making decisions, and taking actions autonomously throughout the enterprise, but few IT leaders appear ready to give bots widespread control.

According to a KPMG survey from July and August, 62% of IT leaders reported they were building, deploying, or developing AI agents, up from 53% in the previous quarter. But many IT leaders still say they are uncomfortable with the prospect of turning over internal processes to agents, with some exceptions for basic, low-risk functions like tier 1 IT support.

Jim Olsen, CTO of AI lifecycle management and governance vendor ModelOp, sees agent autonomy making inroads in limited circumstances — for example, to process customer refunds or credits without human intervention. But early lessons in the risks of full autonomy remain top of mind for IT leaders.

“We saw the large adoption of Clawdbot and OpenClaw by individuals where they would allow it full access to their email and gave it full autonomy,” he says. “For some people that worked out well, but it was a large risk exposure.”

For IT leaders deploying autonomous bots, Olsen recommends confining them to a strict sandbox with well-defined policies to limit their autonomy.

“I do not see allowing agents full and complete autonomy to do whatever they want being used in an enterprise in the near future,” he says. “But restricted autonomy is, in fact, already in use today.”

Activities that aren’t mission critical and don’t have access to sensitive information will be where IT leaders first grant agents full autonomy, Olsen predicts. “As trust improves, so will the breadth of use cases,” he adds.

Some IT leaders are concerned about “autonomy creep,” when agents quietly take more authority than they are given. And many AI and security experts warn that human-in-the-loop guardrails don’t always give employees the authority or time needed to fix agent errors.

Still, IT leaders have several methods for enforcing runtime policies and keeping agent behavior within acceptable goals, including API gateways, OS-level enforcement, and credential management, Olsen says.

“This means having clear policies in place and being able to tie them to the specific agent and use case,” he adds. “Some of these solutions are available now, but a more overall cohesive strategy is needed to bring about this minimal level of trust.”

Defining the sweet spot for autonomy

With about 2,000 agents deployed within her enterprise, Siroui Mushegian, CIO of cybersecurity vendor Barracuda Networks, still has human employees checking bot actions.

“We have many agents that are very close [to autonomous] — many of our ticketing automations are in the ‘trust-but-verify’ category with the agents that oversee them,” she says. “The more we see success, the greater comfort we have, but I am still not 100% certain I want to allow zero human accountability, especially when it comes to auditable processes.”

Mushegian expects autonomy to expand as agents demonstrate they can handle specific tasks reliably. “The consequences of a mistake should determine how much evidence you need before giving an agent more authority,” she says.

Autonomy will likely come to agents executing specific tasks within a function, she adds. Routine internal support requests are a reasonable candidate for autonomy when the answer is well documented, the action is limited, and a mistake is straightforward to correct, she suggests.

Less likely candidates for autonomy are agents that can change access permissions or make changes to a production system, Mushegian adds.

“Even within one workflow, an agent might complete some steps on its own and need approval for others,” she says. “I’d give it only the authority it needs for the task, with human approval for decisions where a mistake could have serious consequences.”

It’s about the action, not the agent

Joshua Rowe, co-founder and CTO of household bills app provider Taupia, agrees that IT leaders shouldn’t give agents complete freedom in every circumstance.

“I’d draw the line at the action rather than the agent,” he says. “The same agent can act alone on one step and need sign-off on the next.”

However, Rowe sees a lot of areas where agents can run near-autonomously right now, including read-heavy work such as gathering data, triage, drafting, and comparing options.

Taupia is testing agent functionality that compares energy deals and takes steps to allow customers to switch providers without its employees approving each step. However, the customer still would have to review the change and confirm it before it goes into effect.

For agents to get autonomous authority for irreversible actions, the timeframe doesn’t depend on AI models getting smarter, Rowe says.

“It depends on how quickly an organization can make each action reversible or bounded, with spending limits, cooling-off periods, rollback, and an audit trail good enough to undo a mistake,” he says. “Once an action has those, it can go autonomous. Where it can’t be undone, like signing a contract or moving money out of an account, I’d keep a person approving it for the foreseeable future.”

A question of deliberate design

Maciej Walaszczyk, CTO at AI customer service platform provider Text, points to customer service as an area where IT leaders have begun to cede control to agents.

“In customer service, which is my field of expertise, agents can indeed answer customer inquiries without the need for constant supervision, as they learn from knowledge provided by humans,” he says. “The scope of autonomy depends on permissions and the consequences of an action. Furthermore, the scope of these responses can be tailored to specific needs.”

But Walaszczyk says he would not hand entire departments over to agents. Instead, IT leaders should delegate specific processes where they can define the goal, set boundaries, and verify the outcomes, he recommends.

“An agent acting on my behalf cannot have more authority than I do,” he adds. “I don’t think it’s a question of being comfortable or even courageous, but of deliberately designing the environment, permissions, instructions, and oversight.”

Trust will come from real work and verified results, and humans must remain in the loop to check agent outcomes in many cases, Walaszczyk adds.

“Oversight must be real,” he says. “It takes time and attention, and it means much more than clicking approve. Saying ‘AI did it’ does not remove their responsibility. Irreversible actions or those with major consequences require human review.”

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.

AI has evolved past simple corporate optimization. Today, it is a definitive engine of macroeconomic power. All over the world, governments and large corporations are launching highly subsidized efforts to develop their own artificial intelligence. For C-level executives, this shift signals a fundamental reorganization of the global tech stack. The decisions made by global superpowers today will directly impact supply chains, compliance requirements, and data architectures tomorrow.

According to researchers at Bain & Company, governments worldwide—including India, Japan, France, Canada, and the United Arab Emirates—are spending billions of dollars to subsidize sovereign AI. They are investing heavily in domestic computing infrastructure and localized AI models trained on regional data and native languages. Market intelligence from McKinsey & Company estimates that sovereign AI could represent a market of $600 billion by 2030. Furthermore, a survey of executives, investors, and government offices revealed that 71% believe sovereign AI is an “existential concern” or “strategic imperative” for their organizational goals.

For CIOs and CTOs, understanding the underlying drivers of this movement is essential for future-proofing corporate IT strategy. Below are the core factors forcing global leaders to act, along with the strategic trade-offs every organization must consider.

The core drivers of the sovereign AI movement:

• Economic competition and zero-sum dynamics: The economic implications of the AI race mirror the early days of the commercial internet, but at an accelerated velocity. Research published by the McKinsey Global Institute suggests that generative AI could generate as much as $2.6 trillion to $4.4 trillion in annual economic value alone. In this highly volatile geopolitical landscape, multilateral collaboration is surrendering to unilateral competition. AI has become the premier battlefield for nations competing for economic leadership, turning the technological landscape into a zero-sum game.
• National security and infrastructure resilience: Digital sovereignty policies are increasingly serving as a bulwark for security. If foundational AI models become the primary engine of a nation’s economy, depending on foreign cloud providers or cross-border infrastructure introduces a vulnerability. An adversary could cause catastrophic disruption simply by knocking those external capabilities offline. Consequently, state leaders are highly hesitant to trust foreign entities—even close geopolitical allies—with such critical infrastructure assets.
• Data governance and local values: Training enterprise-grade models requires immense data volumes, which many governments view as an intrinsic risk to data privacy and regulatory alignment. By building local sovereign infrastructure, nations can institute precise governance controls to protect rights and uphold regional laws. Beyond regulatory compliance, leaders are prioritizing AI systems that accurately reflect and shape the specific societies they serve, so local languages, historical nuances, and distinct ethical values are deeply embedded in the underlying models.

Navigating the corporate impact: Trade-offs for the C-suite

As nations build localized tech stacks, enterprise leadership teams face complex trade-offs regarding vendor lock-in, data hosting, and infrastructure costs. Research firm Gartner says that nations establishing a sovereign AI stack will need to invest at least 1% of their GDP in AI infrastructure by 2029. Enterprise leaders must balance the benefits of public cloud scalability against the compliance of regionalized hardware.

• Security vs. flexibility: Standardizing on a single, global public cloud provider maximizes engineering speed. However, it exposes the business to regulatory penalties or abrupt service disruptions if international data laws shift.
• Local compliance vs. operational scale: Deploying sovereign infrastructure can provide compliance with regional governance laws. Yet, managing isolated data silos across multiple countries increases operational complexity and drives up total cost of ownership (TCO).

Strategic recommendations for CIOs

To prepare for an increasingly fractured and regionalized tech ecosystem, executive leadership teams should prioritize two immediate actions:

1. Audit infrastructure interdependencies: Evaluate your current vendor portfolio to identify dependencies on centralized cloud ecosystems. Begin mapping how a sudden shift toward nationalized data borders would impact your analytics and operational models.
2. Evaluate strategic supercomputing partners: When planning long-term AI architecture, align with technology suppliers who possess a verified track record of building large-scale supercomputers and enterprise-grade data factories. AI data center solutions require intentional hardware and public-sector expertise to maintain resilience.

The enterprise tech stack is no longer decoupled from global politics. To understand how these national investments will transform corporate AI deployment, security standards, and infrastructure requirements, read The race is on: 6 reasons why countries are rushing to develop sovereign AI.

*************

HPE and AMD are partnering to deliver the next generation of AI and supercomputing infrastructure. Combining HPE’s deep expertise in large-scale system design with AMD EPYC™ processors and AMD Instinct™ accelerators, the two companies help customers build platforms capable of supporting the most demanding AI, modeling, simulation, and analytics workloads. Whether accelerating scientific research, enabling digital engineering, or training advanced AI models, HPE and AMD focus on what matters most: faster insights, greater efficiency, and the flexibility to scale. Together, they provide the technology foundation organizations need to solve complex problems, drive discovery, and create lasting business and societal impact.

For years, the enterprise data center operated under a predictable, if restrictive, playbook. Siloed, proprietary hardware stacks dictated infrastructure life cycles, leaving CIOs locked into vendor ecosystems. Every hardware refresh meant navigating premium pricing, constrained supply chains, and artificial limitations on interoperability.

Today, that playbook is being rewritten. As AI, massive data analytics, and intense computational demands reshape corporate strategies, C-level executives are turning to Open Compute infrastructure. Originally pioneered by hyperscalers to manage massive scale efficiently, open hardware design has graduated to the enterprise. By decoupling software from proprietary hardware and embracing collaborative, community-driven standards, open compute is no longer just a technical preference—it is a strategic business imperative.

For the C-suite, transitioning to an open infrastructure model solves three critical pain points: accelerating technological agility, optimizing total cost of ownership (TCO), and meeting aggressive corporate sustainability targets.

Here are the three primary reasons why open compute infrastructure has become vital for IT strategy, and how leaders like HPE and AMD are making it more accessible for the enterprise.

1. Shattering vendor lock-in to accelerate enterprise agility

In a rapidly shifting market, operational agility is a primary competitive advantage. Traditional, proprietary data center architectures restrict a company’s ability to pivot. If a specific vendor faces supply chain disruptions or falls behind in processing power, the enterprise suffers.

Open Compute infrastructure dismantles these artificial barriers. By adhering to open-source hardware specifications, enterprises gain the freedom to mix, match, and upgrade components without replacing their entire infrastructure. This modularity means that hardware can keep pace with software innovations.

This is where the collaboration between hardware pioneers becomes essential. HPE has championed this shift by bringing enterprise-grade reliability, support, and life cycle management to open, flexible architectures. Rather than forcing companies into closed systems, HPE delivers the scaling benefits of open design backed by global service-level agreements (SLAs). For the C-suite, this means the flexibility of an open ecosystem without the operational risk of managing unverified white-box hardware.

2. Optimizing total cost of ownership (TCO) at scale

Inflationary pressures and flat IT budgets mean CFOs are scrutinizing capital expenditures (CapEx) and operating expenses (OpEx) more closely than ever. Closed, proprietary systems carry a premium—not just in the initial purchase price, but in specialized maintenance, proprietary cables, and restricted upgrade paths.

Open Compute infrastructure fundamentally alters data center economics in three distinct ways:

• Component standardization: Standardized form factors reduce the cost of spare parts and simplify physical deployment.
• Streamlined maintenance: Stripping away cosmetic bezels and redundant, proprietary management tools allows IT teams to service systems faster.
• Extended life cycles: Instead of replacing an entire server chassis, executives can upgrade individual components, such as upgrading processors while retaining the existing racks and power distribution units.

Powering these cost-effective, high-density environments requires a new standard in silicon efficiency. AMD has been central to this economic shift. By delivering high-core-density processors like AMD EPYC™, they allow enterprises to consolidate their physical footprint. Fewer sockets mean lower software licensing fees and reduced hardware costs, directly translating to optimized TCO that keeps financial officers satisfied.

3. Driving meaningful progress toward sustainability goals

Data centers are among the world’s most energy-intensive facilities, making them a primary target for corporate environmental, social, and governance (ESG) metrics. For CEOs and chief sustainability officers, reducing carbon footprints is no longer an afterthought—it is a board-level mandate. Some traditional servers include inefficient power supplies and restrictive airflow designs that can drive up cooling costs.

Open Compute architectures tackle energy consumption from the ground up. By utilizing centralized, highly efficient rack-level power distribution and optimizing physical layouts for improved airflow, open designs can reduce Power Usage Effectiveness (PUE) ratios.

When you pair open-rack efficiency with energy-efficient silicon, the sustainability gains multiply. AMD’s continuous focus on performance-per-watt efficiency enables data centers to handle exponentially more compute volume without a corresponding spike in energy consumption. This combination allows enterprise leaders to scale their compute capabilities to handle more intense workloads while visibly driving down operational emissions and meeting corporate sustainability milestones.

The C-suite verdict: Future-proofing the enterprise

Open Compute infrastructure is no longer an experimental architecture reserved solely for hyperscale tech giants. Through enterprise-ready offerings from trusted partners like HPE and cutting-edge silicon from AMD, open infrastructure has become a practical, scalable option for mainstream corporations.

For C-level executives, the decision to migrate toward open standards represents a fundamental commitment to the future. It provides the financial relief required by the CFO, the sustainability metrics demanded by the CEO, and the technological agility needed by the CIO to lead the enterprise into the future.

Three quick tips for C-level executives getting started with Open Compute

• Audit current refresh cycles: Identify proprietary hardware due for replacement over the next 18 months and map out Open-Compute alternatives to benchmark TCO improvements.
• Prioritize workload density over raw hardware volume: Partner with architecture leaders like HPE and AMD to design high-core-density configurations that slash operational footprint and licensing overhead.
• Align infrastructure updates with sustainability reporting timelines: Measure the energy-efficiency gains of moving to centralized power and highly efficient processors to demonstrate tangible carbon reductions to shareholders.

Shape the future of infrastructure: Join the Open Compute community

True innovation doesn’t happen in isolation. The power of Open Compute lies in its global community of engineering experts, visionary developers, and enterprise leaders who collaborate to solve the industry’s toughest data center challenges. By actively participating in the Open Compute Project (OCP), your organization can help define next-generation specifications, preview upcoming silicon and server road maps, and share deployment best practices alongside industry pioneers like HPE and AMD.

Don’t just adapt to the future—help build it. Visit the official Open Compute Project website today to explore active project groups, attend upcoming regional summits, and discover how your enterprise can contribute to a more efficient, collaborative, and sustainable technological landscape.

*************

HPE and AMD are partnering to deliver the next generation of AI and supercomputing infrastructure. Combining HPE’s deep expertise in large-scale system design with AMD EPYC™ processors and AMD Instinct™ accelerators, the two companies help customers build platforms capable of supporting the most demanding AI, modeling, simulation, and analytics workloads. Whether accelerating scientific research, enabling digital engineering, or training advanced AI models, HPE and AMD focus on what matters most: faster insights, greater efficiency, and the flexibility to scale. Together, they provide the technology foundation organizations need to solve complex problems, drive discovery, and create lasting business and societal impact.

As organizations scale out their production AI infrastructure, technology leaders are moving from localized model optimization to the more complex realities of industrial-grade deployment. For those who have spent years embedding machine learning into their core business processes, the current inflection point is defined by massive data pipelines, expanding compute clusters, and strict data governance. Scaling out requires an architectural evaluation: Can your infrastructure support exponential workload growth while simultaneously keeping your data entirely secure and compliant?

For European CIOs and engineering teams tasked with managing this operational expansion, scaling introduces a critical structural bottleneck: Where does our data live at scale, and who ultimately controls the underlying infrastructure?

In an era of intensive model training and widespread inference deployment, relying blindly on public cloud environments presents significant long-term structural risks. For organizations operating under stringent local regulations like the EU AI Act, expanding your AI footprint means managing larger volumes of proprietary intellectual property and customer data than ever before. If that scaling happens across jurisdictions that do not align with European privacy laws, your entire competitive advantage and regulatory standing could be compromised.

This clear need for scalable, autonomous infrastructure has catalyzed a major movement across the continent: Sovereign AI. At the absolute center of this infrastructure paradigm shift is the High-Performance Computing Center Stuttgart (HLRS) in Germany. As an elite computing institution, HLRS is serving as the operational blueprint for how European enterprises can aggressively scale out their AI implementations without sacrificing absolute data sovereignty.

The modern enterprise challenge: Innovation vs. autonomy

For years, commercial enterprises looking to train massive AI models had few choices outside the major global hyperscale cloud providers. While these platforms offered rapid scalability, they also created a complex web of dependencies. European enterprises frequently encountered architectural lock-in, unpredictable data egress fees, and the persistent compliance headache of transferring sensitive data across international borders.

For organizations in highly regulated sectors—such as automotive engineering, financial services, aerospace, and healthcare—these barriers were often insurmountable. Innovation slowed because the risk of exposing proprietary data was simply too high.

HLRS recognized this friction point early on. Rather than forcing organizations to compromise between computational horsepower and data security, the center designed an environment specifically tailored to the unique operational, cultural, and legal realities of European industry.

A deeply customer-centric approach to high-performance computing

HLRS does not view itself merely as a data center filled with flashing server racks; it operates as a specialized co-innovation partner for industrial enterprises and scientific researchers.

HLRS provides a unique collaborative bridge between academic research and commercial application. Its customer-centric model enables an industrial engineering team or a climate research group to receive tailored computational environments optimized for their specific mathematical models and workflows.

Consider the automotive industry, a cornerstone of the German economy. Designing the next generation of autonomous or electric vehicles requires running billions of simulation cycles. By leveraging the local, highly secure infrastructure at HLRS, these manufacturers can train complex AI vision models and run aerodynamic simulations knowing that their intellectual property remains fully insulated from external entities. The data stays in Germany, conforms entirely to European standards, yet benefits from processing speeds that rival supercomputing clusters around the world.

This customer-first focus democratizes access to elite computing. It allows midsize enterprises and massive multinational corporations alike to scale their AI ambitions without the fear of compromising their foundational data assets.

Engineering sovereign AI: The powerhouse ecosystem

Building a sovereign computing ecosystem capable of supporting next-generation AI workloads requires an extraordinary combination of hardware reliability, system architecture, and processing efficiency. To deliver this level of performance to its users, HLRS has cultivated deep strategic partnerships with industry-leading technology pioneers including HPE and AMD.

1. Architecting the future

AI and deep learning workloads are fundamentally different from traditional corporate computing. They require massive data pipelines to move fluidly across thousands of nodes without encountering bottlenecks. HPE brings its world-class supercomputing system architecture to the HLRS data center floor.

By utilizing HPE Cray Supercomputing platforms, HLRS can offer its users an infrastructure optimized for massive parallel processing. HPE advanced liquid-cooling technologies help maximize data center energy efficiency—a critical requirement for European organizations operating under sustainability mandates. For the HLRS customer, this translates to predictable, highly reliable performance even when training the most demanding, multibillion-parameter AI models.

2. Driving computational breakthroughs

Today’s AI workloads are incredibly compute-intensive, requiring advanced hardware capable of executing complex matrix mathematics at blinding speeds. HLRS integrates cutting-edge AMD processors and accelerators to meet these heavy operational demands.

AMD-powered infrastructure is deliberately engineered to handle both traditional high-performance computing simulations and modern AI training workloads simultaneously. Plus, AMD’s focus on energy efficiency per watt allows HLRS to maximize its computational output without exponentially increasing its environmental footprint. For end users, this means faster time-to-insight, accelerated product development cycles, and the ability to iterate on AI models at a fraction of the time.

By tightly integrating HPE system engineering with AMD processing innovation, HLRS delivers a sovereign computing alternative that matches—and often exceeds—the capabilities of non-sovereign platforms.

The strategic value for the enterprise CIO

For CIOs, the lesson of the HLRS model is clear: sovereign AI is no longer a niche regulatory preference; it is a core business strategy. Investing in sovereign architectures allows organizations to achieve three critical enterprise goals:

• Future-proof compliance: By anchoring AI development within a sovereign framework, organizations can be insulated from shifting international compliance regulations and the evolving complexities of global data laws.
• Intellectual property protection: Keeping model training local means proprietary algorithms, customer data, and trade secrets don’t feed into public or third-party AI models.
• Uncompromised performance: Selecting a dedicated infrastructure stack powered by HPE and AMD enables local data processing without sacrificing the speed or scale required to compete on a global stage.

As AI continues to mature, the organizations that build their digital strategies on a foundation of data autonomy and sovereignty will be the ones positioned to lead. HLRS stands as a powerful testament to what is possible when customer-focused design meets world-class technology infrastructure.

Learn more about Europe’s strategic investments in digital autonomy, the evolution of supercomputing, and how industrial organizations are leveraging these advanced technologies to drive competitive advantage by listening to the full conversation on This Week in HPC Podcast Episode 400.

*************

HPE and AMD are partnering to deliver the next generation of AI and supercomputing infrastructure. Combining HPE’s deep expertise in large-scale system design with AMD EPYC™ processors and AMD Instinct™ accelerators, the two companies help customers build platforms capable of supporting the most demanding AI, modeling, simulation, and analytics workloads. Whether accelerating scientific research, enabling digital engineering, or training advanced AI models, HPE and AMD focus on what matters most: faster insights, greater efficiency, and the flexibility to scale. Together, they provide the technology foundation organizations need to solve complex problems, drive discovery, and create lasting business and societal impact.

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?”