Hot AI companies can’t stop talking about forward-deployed engineers (FDEs), which are now very much in vogue. 

FDEs, in case you haven’t heard, are hired by companies looking (hoping?) to successfully deploy AI tools and services. It’s one of the hotter professions in a world still trying to understand the impact of AI on careers.

So, what exactly are FDEs — are they techy lone rangers like the ones OpenAI, Google and Microsoft are hiring? Turns out it’s not so much about individual engineers who swoop in to design and roll out AI deployments; it’s more about a team of engineers working together at customer sites.

At least, that’s the view at Amazon Web Services (AWS).

In fact, according to Taimur Rashid, managing director of the AWS Generative AI Innovation Center, the FDE concept pre-dates the current generative AI (genAI) gold rush. The same kinds of engineering teams were needed for the earlier machine-learning and cloud eras to help companies with deployments.

Rashid recently talked about how AWS sees FDEs as a profession in a conversation with Computerworld. And he weighed in on the desired job skills the company seeks in this increasingly AI-centric era.

What is an FDE? “We view it as a team. It’s a cross-functional team that has engineers, scientists, strategists, and folks that can piece technology and business together. In some cases, we do have to have security engineers in there, too. 

“I see them as anesthesiologists. They have to prep so many things, monitor things throughout. We see ourselves as a frontier deployment team helping customers adopt all forms of AI, whether it’s genAI, agentic AI, even emerging trends like physical AI. We’re helping these companies become frontier themselves.”

How does an FDE engagement begin, and how is it structured? “Where we see the forward deployed model is when customers come in — for example, we have our executive briefing center in Seattle and in Arlington, VA. When customers share what they’re trying to do, very quickly a customer’s like, “What’s the quickest way I can go and build something with you?” 

“We’ll forward deploy our people in, we’ll embed them in your business and we’ll go through these 45-day sprints that we typically design. Through those successive sprints, we’re building stuff together, we’re proving value, and then they can expand that to a much broader engagement.

Where do FDEs actually sit? Client side, internally, or in-between? “It’s mixed, and it largely depends on what the customer’s preference is. We’ve seen models where the customer has been very adamant that, ‘We want your teams with us in our business.’  In those cases, we forward deploy the majority of the teams on site. 

“We have models where customers are fine with you being wherever you’re based, as long as you’re still embedded virtually. And then there’s a hybrid. We deploy anywhere from five to seven people. Sometimes, the baseline is actually three.”

Will cost savings be the job of an FDE, or someone else on the team? “I expect these teams to be able to architect systems that have those cost requirements in mind, whether it’s use a different model for a different use case that doesn’t increase the per-token cost…or think about ways where you can use semantic caching. I personally think you may have a high spend in token consumption, but if you’re generating revenue, as long as the economics work out, then you’re at peace.”

What challenges have you gone through deploying FDEs in the real world? “One of the challenges worth highlighting is when customers get really excited about us forward deploying resources, what they end up realizing is [that] they’re not set up to absorb that right away. They realize they have to go through … process-related things, security access — all those operational things. 

“One very good example is the Commonwealth Bank of Australia. They said: “Prioritization’s a big thing, and if you forward deploy and you’re 100% dedicated, how do we ensure that our teams are also equally 100% dedicated?’ When you’re sitting in your office, you’re distracted by your day-to-day. So they said, ‘Why don’t we create a neutral ground in Seattle? You fly your people, we’ll fly our people. We’ll give them three weeks of dedicated time so they have no distractions.’”

Have you gone into projects where they want AI but have no security or governance ready? “I’ve been through this before, certainly. We do see customers that have security processes and capabilities, but it’s not as tight as it should be in the age of AI. Governance is the biggest area where customers right now have the biggest gap. I’m talking governance around agents. In the past two months, almost 100% of the conversation around agents is not about capability. It’s all about governance. 

“That is a big area right now where forward deploy teams are helping with governance education, and building the scaffolding for that.”

How does software engineering fit into the FDE model? “One of the greatest learnings is that as we forward deploy resources and get customers to take AI and integrate it into their systems, the knowledge of software engineering is so important. Today, a customer can use one of the Claude models and scan their code base and look at vulnerabilities. 

“The tough part is not assessing those vulnerabilities, it’s remediating [them]. Remediating [them] requires software engineering experience, because you have got to merge code, test it, deploy it. We largely see that the frontier software development teams are smaller and they’re managing agents that are doing various tasks across the software development lifecycle.”

AWS has many models at your scale, open source, closed — it’s more complex than what other AI vendors offer.  How do you nail down the talent? “It’s massive, and when you look at not only scale, it’s the complexity of the stack. We take an approach where we fundamentally do three important things: No. 1, we want to ensure people understand concepts; they have to understand pre-training, post-training, reinforcement, fine-tuning. 

“Secondly, we make sure that our teams are well versed in their first-party services. The third thing is that by design, AWS has always been about choice. We say, ‘Let’s do 80-20 here. What is 20% of those specialties that we need to have, which can cover 80% of what most customers are trying to do?’”

What skills should software developers learn to move into FDE work — the top three or four things? “We look at three categories. First category is entirely functional. Are they more engineering specific? Are they science specific? Are they security specific? Our litmus test is not only knowledge of the function, but the actual hands-on work that they can do with it. Secondly is around domain. I focus on what is their domain understanding across the whole AI lifecycle? The third thing is cultural. We are looking for folks that are okay at dealing with ambiguity, being good at stakeholder management, and having that startup mindset. 

“This AI transformation’s not for the faint of heart.”

There’s a rush for FDEs from OpenAI, Google, and others. What’s different about what you look for? “I don’t know entirely what the others are looking for, but I’ll tell you what we have been looking for in the past. When we hired solution architects, it was about systems level understanding. But what I see more and more is hands-on experience, cultural mindset, all these things are very important. If I had to pick one thing that is going to be very important in the talent that we either upskill or future talent that we hire, it has to be the application of AI towards software engineering and system integration tasks.

You’re upskilling AWS talent as well? “We do. You will see some publications coming out in the next couple of weeks around how do we do this across our software teams and how does that translate to customer-facing roles.”

AIs struggle to understand documents designed for humans; the DocLang working group seeks to flip that imbalance with its specification for machine-readable business documents “built from the ground up for LLM tokenizers.”

The working group, founded by IBM, Nvidia, and Red Hat and hosted by the Linux Foundation’s LF AI & Data project, aims to create an open, universal, AI-native document format designed to improve how enterprises prepare, exchange, and govern document data for AI systems. ABBYY and Human Signal will also be involved in its development, and other contributors are welcome.

“Enterprises today work across a fragmented landscape of document formats, including PDFs, JPEGs, and other file types built primarily for human consumption rather than AI interpretation,” the group said in its launch announcement.

“This disconnect can introduce complexity, raise costs, and reduce reliability when extracting meaning from business documents,” as organizations increasingly rely on generative AI and agentic systems, it said.

Mark Collier, executive director of LF AI & Data, said the goal of the DocLang Specification Working Group is to “develop a vendor-neutral, interoperable standard that helps organizations prepare document data for AI more reliably, transparently, and at scale.”

DocLang defines a structured, machine-readable format for documents of any type, like JSON for data, that any tool can implement and any pipeline can consume. It builds on DocLing, a document processing toolkit hosted by LF AI & Data that can transform human-readable PDFs, word processor documents or spreadsheets into structured data.

Standards must evolve for AI

Something like DocLang is needed, said independent technology analyst Carmi Levy. “Existing document standards have done an admirable job allowing global stakeholders to confidently collaborate for decades, but it’s becoming increasingly clear that they are in desperate need of an update as AI reshapes the rules around how work gets done,” he explained.

Largely static document types, he said, “can be somewhat limiting when AI is redefining the very word, ‘document.’ In many ways. AI-age documents are far more iterative and dynamic than what they once were, and the definitions need to evolve with the times. The documents we currently live with simply weren’t designed for the AI age.”

Within that context, Levy said, “DocLang represents an early, best hope of achieving some kind of foundational baseline for document standards, one that will hopefully allow more intelligent, more efficient, lower-risk workflows than is currently the case.”

Taking an open-source, vendor-agnostic approach to the process ensures the collective will take precedence over the needs of specific vendors, he said, adding, “earlier standards-setting efforts around networking, documentation, the web, and the cloud powered the free-flowing digital landscape that defines modern life.”

An AI-centric documentation standard will carry that reality into the next generation of technology, said Levy.

A question of governance

The entire concept of LLMs, Jason Andersen, principal analyst at Moor Insights & Strategy said, “involves using natural human languages. The computer is supposed to understand us without us changing our syntax or language. Forcing a syntax on users is exactly what we have today with SEO and more advanced programming languages.”

With something like DocLang, where the standard can be applied to content ingestion, he said, “I would be OK with that being automated, which seems to be the intent. The use case I envision is that when I upload a document to an agent, a skill can be run to preprocess the document into the DocLang standard format, saving tokens.”

That makes sense, he said, adding that he thinks it’s good “if it can help generate outputs, like a visualization, that can be shared outside an AI tool. On that front, that is also why I am liking Web MCP, since you are just adding some code to the page, like CSS or JavaScript, and the consumer, in this case, an AI browser or skill, is better equipped to handle the site.”

The point, he said, is, “these standards need to preserve the fact that humans can still do what they want, and do not need to know any coding to be proficient. In terms of governance, I am not sure if it matters.”

But one analyst did foresee governance problems arising from DocLang’s use.

Yaz Palanichamy, senior research analyst at Info-Tech Research Group, said DocLang adoption will require organizations to implement and review controls in order to scale its use accountably and securely.

This article first appeared on CIO, on June 10, 2026.

For years, the cloud market has made a simple promise: Move workloads to large-scale platforms, gain better resilience, and worry less about downtime. That promise was never entirely wrong, but it is becoming less complete. The latest findings from Uptime Institute’s seventh Annual Outage Analysis suggest that the outage landscape is changing in ways that should concern both cloud providers and cloud customers. The biggest risks are no longer limited to broken physical infrastructure. They are increasingly tied to the complexity of the systems used to run, coordinate, update, and recover that infrastructure.

The most alarming number in the report is that IT and networking issues accounted for 23% of impactful outages in 2024. Uptime Institute links these increases to growing IT and network complexity; the long-term shift toward colocation, cloud, and third-party digital services; and the resulting increase in change-management failures and misconfigurations. That number is more than a statistical footnote. It points to a structural change in how outages happen and why cloud outages are becoming such a stubborn problem.

Hardware redundancy can protect against component failures, but it doesn’t help much when the outage stems from a bad configuration, an automation error, a faulty network change, or an underappreciated control-plane dependency. In those cases, the infrastructure itself may remain intact while the system that governs it breaks down. The industry is learning that resiliency is less about duplicating equipment and more about managing complexity. Today’s increasingly distributed and software-defined environments cannot operate safely at scale.

Failures at the operational level

Uptime’s findings show that power remains the leading cause of major outages, underscoring that traditional infrastructure engineering still matters a great deal. But even as providers continue to improve physical resilience, outages can still arise from the digital and procedural layers above it. Cloud platforms are now dense stacks of services, APIs, orchestration systems, software-defined networks, identity controls, failover logic, and third-party dependencies. That complexity creates more possible points of interaction and more opportunities for an error in one layer to cascade into several others.

This helps explain why outages can feel more surprising today than they did a decade ago. In older data center models, an outage often had a more apparent root cause, such as a power event, a cooling failure, or a hardware fault. In cloud environments, the trigger may be a small configuration change that propagates across regions, a policy update that unintentionally blocks service communication, or a network control failure that affects seemingly unrelated services. These are not failures of raw infrastructure capacity. They are failures of complexity management.

The report’s language around change management and misconfiguration is especially important because it challenges one of the most common assumptions in the cloud market: that scale automatically produces better operational outcomes. The reality? Scale can magnify both strengths and weaknesses. Large cloud providers have more engineering talent, more sophisticated tools, and more redundancy than almost any enterprise customer. But they also run far more interconnected systems at far greater speeds with far more automation. A single process failure can have a wider blast radius.

Another important lesson from the Uptime analysis is that automation has not removed the human factor. If anything, it has changed its form. Even in highly automated environments, human error remains central to the problem. The report notes that in 2025, the share of outages caused by human failure to follow procedures rose by 10 percentage points compared with 2024. A related industry summary of the report notes that 58% of human error-related outages were caused by staff failing to follow established procedures.

That matters because cloud providers often position automation as the answer to reliability. Automation is essential, but it only works as well as the operational model that surrounds it. If teams deploy changes too quickly, rollback paths are weak, approval chains are bypassed, or procedures are incomplete, automation can accelerate failure rather than prevent it. In a modern cloud environment, a human mistake is rarely just a single keystroke. It is more often a design weakness in process, governance, testing, or accountability.

This is also why customers should resist the comforting notion that outages are somebody else’s problem once workloads move to the cloud. Provider-side mistakes remain real, but customer architectures are increasingly entangled with provider networking, identity, observability, and platform services. When an outage occurs, the customer may not have caused it, but they still bear the business impact. The shared responsibility model does not end with security. It extends to resilience planning as well.

Better change management

The Uptime data points to a clear conclusion: Cloud providers need to treat operational discipline as a first-class design requirement. That starts with better change management. High-risk changes should be tested more aggressively, staged more gradually, and accompanied by stronger rollback mechanisms. Providers also need better dependency mapping to understand how a change in one control layer can affect services far beyond its immediate scope. If the system is too complex to clearly explain, it is too complex to operate.

Providers also need to improve procedural quality. The rise in outages caused by failing to follow procedures suggests that procedures are being ignored under operational pressure or that they are too cumbersome, outdated, or unclear for real production conditions. Neither explanation is comforting. Stronger runbooks, better training, more realistic failure drills, and tighter operational guardrails are not glamorous investments; they are increasingly central to resilience.

Another pressure point is visibility. Uptime notes that software-based and distributed resiliency tools can improve availability, but they also introduce new risks and complicate root-cause analysis. Cloud providers need more transparent and faster incident diagnosis, not just more layers of abstraction. Customers cannot build trust in resilience if every major incident becomes a long exercise in reconstructing opaque service dependencies after the fact.

Design with outages in mind

What’s the financial impact of more frequent problems? Uptime’s 2024 analysis found that 54% of respondents reported that their most recent significant outage cost more than $100,000, and 20% said it cost more than $1 million. These are not edge-case losses. They show that outages remain costly even if they are less frequent than in earlier years.

Customers need to stop evaluating cloud resilience through uptime promises and start evaluating it through failure behavior. How does a provider isolate faults? How transparent is incident communication? How portable are workloads if a major service degrades? How dependent is the architecture on a single region, network path, identity service, or control plane? These are not just technical questions; they are now critical business questions.

The core lesson from Uptime’s data is simple. Outages are becoming a bigger problem for cloud providers and customers because the cloud’s biggest vulnerabilities are increasingly tied to complexity, process failures, and control-plane mistakes, not just broken infrastructure. In addition to adding redundancy, the next phase of cloud improvement will focus on building systems that are easier to understand, safer to change, and more disciplined to operate.

Enterprises are increasingly investing copious amounts of cash in AI without a lot to show for it. This could be, in part, because the wrong people are leading the change.

As I’ve argued before⁠, AI isn’t likely to eliminate developers so much as change what we need from them. For example, we keep asking whether junior developers are needed in a world where large language models can write code faster and cheaper. What this overlooks is the reality that these younger developers and their relative inexperience may be exactly what we need to rewrite the rules of software development.

This thought hit me while reading James Governor’s riff on something Ben Griffiths⁠ wrote about our industry’s habit of confusing age with authority. Griffiths remembered sitting through a conference talk in which a speaker tried to shame a young audience for not recognizing some of the older men who had shaped computing. The irony, Ben noted, was that many of those “old men” had done their world-changing work when they were younger than the people being lectured. Bill Joy wrote vi when he was 22, John Carmack created Doom at 23, Linus Torvalds launched Linux at 22, etc. Many of our industry’s titans made their biggest contributions before they had decades of experience.

The point isn’t that young people are smarter. They’re not. The point isn’t that the key to AI success is to ignore more experienced developers. That’s dumb. Rather, it’s a suggestion that Griffiths’ larger point is right: At the beginning of big shifts, experience can be a mixed blessing. It can help you see risk, but it can also make you overconfident in old ways. The most successful enterprises will find ways to balance youthful innovation with experienced guardrails.

The factory doesn’t redesign itself

Zara Zhang recently pointed to Paul David’s classic 1990 paper, “The Dynamo and the Computer,”⁠ as a way to understand why so many companies have “adopted” AI without much to show for it. David’s argument, simplified, is that electricity didn’t immediately transform factories. For a long time, factories simply swapped out the central steam engine for an electric motor while keeping the same layout, the same workflows, and the same assumptions.

Electricity was new, but we largely stifled its potential by force-fitting it into old factory systems.

The big productivity gains came later, when factories stopped treating electricity as a cleaner steam engine and started redesigning work around smaller motors distributed throughout the factory. Once each machine could have its own motor, the factory no longer had to organize itself around a single driveshaft. Work could instead be reorganized around the flow of production.

That’s a decent description of where many enterprises are with AI. Enterprises today are buying copilot licenses by the thousands, wiring agents into existing applications, etc., and then wondering why the results are so uneven, as I’ve written⁠. This is the equivalent of swapping the steam engine for an electric one and declaring that the AI modernization work is done. It’s not. Not even close.

The real payoff won’t come from asking AI to write the same tickets a bit faster. It will instead come from changing how teams define work and how (and what) developers build. The “factory” has to change.

So here’s the uncomfortable question: Who is most likely to build the new factory?

Experience cuts both ways

There’s an obvious danger in romanticizing youth. Plenty of bad software has been written by people with unlimited confidence and limited context. Enterprises need software that works, yes, but “works” also means it complies, scales, respects security boundaries, and more.

This is where experienced developers matter. A lot.

As I pointed out recently, the agent era makes engineering judgment more important than ever. After all, AI makes it easier to generate code, but easier code generation can become easier technical debt generation. Hence, the limiting factor becomes less of “Can we create something?” and more of “Can we create the right thing, in the right place, with the right constraints?” Taste is required, in other words.

Senior engineers are often better at seeing those constraints because their experience gives them “taste.” They know why the weird validation rule exists, and they remember the customer who depended on the undocumented behavior. They understand why a simple schema change can turn into a multi-week migration.

But experience also has a shadow side, because it can make the current process feel inevitable. A senior engineer may see an AI assistant as a faster autocomplete because that’s the easiest way to fit AI into their existing mental model. A junior developer, less invested in the old workflow, may ask the more interesting questions: Why are we doing this ticket at all? Why isn’t the spec executable? Why can’t the agent generate the test harness first?

It’s not that the more experienced developers don’t know these questions. Rather, they may simply not have the energy to rage against the machine, as it were.

The value of inexperience

The worst way to use junior developers in the AI era is to treat them as cheaper versions of senior developers. That was always a bad idea, but AI makes it worse. If the job is “take this ticket, generate some code, and send it to a senior person for review,” the junior developer becomes a human wrapper around a coding assistant. That helps no one. The junior doesn’t learn much, the senior gets buried in review, and the enterprise ends up with more code, which, as I’ve said, is hardly a good thing.

Instead, junior developers should be given room to explore new workflows, with just enough oversight from experienced colleagues. That might mean giving these newer developers interesting questions to answer, such as:

• How would we redesign onboarding if every internal API had an AI-readable contract and examples that actually worked?
• How would we change code review if the agent produced a change summary, test evidence, dependency risk, and rollback plan with every pull request?
• How would we build features if product requirements were written as executable acceptance tests rather than vague prose?
• How would we reduce toil if agents could safely perform routine migrations, dependency updates, or incident triage within clearly defined boundaries?

These are not toy problems. They’re not “junior work.” They’re exactly the sort of process redesign that enterprises need but generally avoid because everyone is too busy running on the existing hamster wheel.

Finding the balance

So what should engineering leaders do? First, stop treating AI adoption as an individual productivity contest. We seem to be moving quickly away from the idea that “lots of tokens” equals “great engineer,” but the fact that we even flirted with it is damning. I love how Santiago Valdarrama eviscerates this vanity metric: “Measuring AI productivity in number of lines written is a stupid mistake. One day, everyone will have always been against this.” Instead we should be asking questions like, “What part of our software delivery process no longer makes sense?” AI’s biggest gains will come when we change how we specify, test, review, and ship software.

Second, mix up your AI workflow teams. No, not committees or PowerPoint-producing centers of excellence. I’m talking about combining two or three newer developers who are already fluent in AI-native tools with two or three senior engineers who understand production, security, architecture, and organizational constraints. Then give them a real workflow to redesign, such as dependency upgrades or test creation.

Third, make the senior engineer’s job less about saying no and more about defining the guardrails within which others can say yes. I’ve argued that golden paths are key to using AI effectively. Good senior engineers should define the paved roads: approved patterns, test requirements, observability standards, etc. Then let junior developers and agents move quickly inside those boundaries.

Fourth, reward deletion. This may be the most important point. Going back to the factory electricity metaphor, we’ll fail with AI modernization if we simply add AI without removing outdated processes.

Bring everyone to the table

The future of software development won’t belong to the young. It won’t belong to the old, either. It will belong to teams that combine the talents of both.

Newer developers often bring impatience. They’re less likely to accept the existing workflow as sacred. They’re more likely to try weird tools, compose them in unexpected ways, and wonder why enterprise software development feels like a ritualized exercise in waiting for permission.

Experienced developers bring judgment. They know that software has users, auditors, attackers, budgets, latency, history, and consequences. They know that the right answer is often boring, and boring is good.

Enterprises need both. They need the developer who asks why the factory is still organized around the old drive shaft, and they need the developer who knows which machines will kill someone if moved casually. In sum, every development team needs people who know why the old system exists… as well as those who don’t.

For years, the cloud market has made a simple promise: Move workloads to large-scale platforms, gain better resilience, and worry less about downtime. That promise was never entirely wrong, but it is becoming less complete. The latest findings from Uptime Institute’s seventh Annual Outage Analysis suggest that the outage landscape is changing in ways that should concern both cloud providers and cloud customers. The biggest risks are no longer limited to broken physical infrastructure. They are increasingly tied to the complexity of the systems used to run, coordinate, update, and recover that infrastructure.

The most alarming number in the report is that IT and networking issues accounted for 23% of impactful outages in 2024. Uptime Institute links these increases to growing IT and network complexity; the long-term shift toward colocation, cloud, and third-party digital services; and the resulting increase in change-management failures and misconfigurations. That number is more than a statistical footnote. It points to a structural change in how outages happen and why cloud outages are becoming such a stubborn problem.

Hardware redundancy can protect against component failures, but it doesn’t help much when the outage stems from a bad configuration, an automation error, a faulty network change, or an underappreciated control-plane dependency. In those cases, the infrastructure itself may remain intact while the system that governs it breaks down. The industry is learning that resiliency is less about duplicating equipment and more about managing complexity. Today’s increasingly distributed and software-defined environments cannot operate safely at scale.

Failures at the operational level

Uptime’s findings show that power remains the leading cause of major outages, underscoring that traditional infrastructure engineering still matters a great deal. But even as providers continue to improve physical resilience, outages can still arise from the digital and procedural layers above it. Cloud platforms are now dense stacks of services, APIs, orchestration systems, software-defined networks, identity controls, failover logic, and third-party dependencies. That complexity creates more possible points of interaction and more opportunities for an error in one layer to cascade into several others.

This helps explain why outages can feel more surprising today than they did a decade ago. In older data center models, an outage often had a more apparent root cause, such as a power event, a cooling failure, or a hardware fault. In cloud environments, the trigger may be a small configuration change that propagates across regions, a policy update that unintentionally blocks service communication, or a network control failure that affects seemingly unrelated services. These are not failures of raw infrastructure capacity. They are failures of complexity management.

The report’s language around change management and misconfiguration is especially important because it challenges one of the most common assumptions in the cloud market: that scale automatically produces better operational outcomes. The reality? Scale can magnify both strengths and weaknesses. Large cloud providers have more engineering talent, more sophisticated tools, and more redundancy than almost any enterprise customer. But they also run far more interconnected systems at far greater speeds with far more automation. A single process failure can have a wider blast radius.

Another important lesson from the Uptime analysis is that automation has not removed the human factor. If anything, it has changed its form. Even in highly automated environments, human error remains central to the problem. The report notes that in 2025, the share of outages caused by human failure to follow procedures rose by 10 percentage points compared with 2024. A related industry summary of the report notes that 58% of human error-related outages were caused by staff failing to follow established procedures.

That matters because cloud providers often position automation as the answer to reliability. Automation is essential, but it only works as well as the operational model that surrounds it. If teams deploy changes too quickly, rollback paths are weak, approval chains are bypassed, or procedures are incomplete, automation can accelerate failure rather than prevent it. In a modern cloud environment, a human mistake is rarely just a single keystroke. It is more often a design weakness in process, governance, testing, or accountability.

This is also why customers should resist the comforting notion that outages are somebody else’s problem once workloads move to the cloud. Provider-side mistakes remain real, but customer architectures are increasingly entangled with provider networking, identity, observability, and platform services. When an outage occurs, the customer may not have caused it, but they still bear the business impact. The shared responsibility model does not end with security. It extends to resilience planning as well.

Better change management

The Uptime data points to a clear conclusion: Cloud providers need to treat operational discipline as a first-class design requirement. That starts with better change management. High-risk changes should be tested more aggressively, staged more gradually, and accompanied by stronger rollback mechanisms. Providers also need better dependency mapping to understand how a change in one control layer can affect services far beyond its immediate scope. If the system is too complex to clearly explain, it is too complex to operate.

Providers also need to improve procedural quality. The rise in outages caused by failing to follow procedures suggests that procedures are being ignored under operational pressure or that they are too cumbersome, outdated, or unclear for real production conditions. Neither explanation is comforting. Stronger runbooks, better training, more realistic failure drills, and tighter operational guardrails are not glamorous investments; they are increasingly central to resilience.

Another pressure point is visibility. Uptime notes that software-based and distributed resiliency tools can improve availability, but they also introduce new risks and complicate root-cause analysis. Cloud providers need more transparent and faster incident diagnosis, not just more layers of abstraction. Customers cannot build trust in resilience if every major incident becomes a long exercise in reconstructing opaque service dependencies after the fact.

Design with outages in mind

What’s the financial impact of more frequent problems? Uptime’s 2024 analysis found that 54% of respondents reported that their most recent significant outage cost more than $100,000, and 20% said it cost more than $1 million. These are not edge-case losses. They show that outages remain costly even if they are less frequent than in earlier years.

Customers need to stop evaluating cloud resilience through uptime promises and start evaluating it through failure behavior. How does a provider isolate faults? How transparent is incident communication? How portable are workloads if a major service degrades? How dependent is the architecture on a single region, network path, identity service, or control plane? These are not just technical questions; they are now critical business questions.

The core lesson from Uptime’s data is simple. Outages are becoming a bigger problem for cloud providers and customers because the cloud’s biggest vulnerabilities are increasingly tied to complexity, process failures, and control-plane mistakes, not just broken infrastructure. In addition to adding redundancy, the next phase of cloud improvement will focus on building systems that are easier to understand, safer to change, and more disciplined to operate.

When it comes to AI deployments, IT leaders are often caught in an awkward middle space, trying to reconcile conflicting directives from senior management with constantly changing AI models, capabilities, and costs; data governance and security needs; and the limitations of their own team.

“Very few real benefits can be attained by simply purchasing an AI product and giving it to employees. Vendors have been overselling that fallacy for the past three years,” said Nader Henein, a Gartner VP analyst.

“The reality is that strong AI value and consistent ROI are almost always a result of deep and intentional integration of AI capabilities into existing workflows. For that you need specialized teams, which do not come cheap, and organizations have been recruiting those teams in a variety of ways,” Heinen said.

Among the options available to IT leaders looking for help with AI deployments are traditional IT consultancies, AI-specific consultancies, and independent contractors. Large enterprises with deep pockets can consider acquiring an AI firm and integrating its technology and expert staff. The use of open source to reduce vendor lock-in is a strategy that can sit on top of those others, an approach that Capital One has used. 

But the option that has been getting the most attention recently is bringing in forward-deployed engineers (FDEs), teams of experts from AI vendors that embed with a customer’s in-house engineers to oversee AI rollouts within the enterprise environment. Both OpenAI and Anthropic have recently announced FDE offerings, for example, and Microsoft is partnering with consulting giant EY in a new FDE program for agentic AI deployments.

Engineering teams employed by AI vendors have key strengths, such as understanding their models better than anyone else, having experience integrating those models into different types of enterprise environments, and knowing about upcoming model capabilities before they’re announced. But they also have the obvious drawback of vendor lock-in. Even if future rollouts are not within their contracted deliverables, those vendor employees could subtly influence a client’s future AI efforts. 

Flavio Villanustre, CISO for LexisNexis Risk Solutions, cautions IT executives to move into FDE programs carefully. 

FDEs “are financially incentivized to grow customers’ use of a vendor’s AI products and to create stickiness with that vendor’s services,” he said. “While FDEs may be a reasonable value-added service by the AI vendor, customers should always find other unbiased expert opinions that can evaluate competitive solutions across multiple vendors.”

This is particularly important at a time when “investor-subsidized AI token business models are starting to show cracks,” Villanustre said. “Also, in the current rapid pace of innovation in this field where AI vendors are constantly leapfrogging each other, retaining the agility to move from one vendor to the next could create significant competitive advantages.”

Analysts, consultants, and other industry experts who spoke with Computerworld about FDEs echoed Villanustre’s caution, citing concerns around hidden costs, confidentiality, observability, and vendor lock-in.

Long-term costs and vendor lock-in

A key issue that IT executives need to consider is how long the FDE teams will be needed. The enterprise will likely need an ongoing series of AI deployments synced with the current AI model(s). If help is needed today, why would that change tomorrow?

Enterprises tend to overlook those longer-term costs, said John Sangyeob Kim, an AI engineer at software development vendor Solidroad.

“Deployment is maybe 20% of the total cost. The other 80% is keeping the system running through model upgrades, data drift, and edge cases that only appear after months in production,” Kim said. “Most contracts price the first part and assume the rest. Deployment isn’t the hard part of enterprise AI anymore. The next eighteen months are.”

And whether it’s intentional or not, FDEs will naturally favor their own product portfolio — it’s what they know best.

“FDEs from model labs are good at making their own models work in your environment. They are less suited for multi-model systems, because their incentive is to keep you inside their ecosystem,” Kim said.

Sanchit Vir Gogia, chief analyst at Greyhound Research, said IT leaders should look at the FDE model as a strategy involving ongoing operational power. 

“Whoever shapes the deployment pattern shapes the enterprise’s future muscle memory. Whoever owns the evaluation layer owns the truth layer. Whoever controls the integration logic controls the dependency map,” Gogia said. “This is why the FDE model matters. It is not just another delivery option. It is the frontier AI vendor moving closer to the customer’s workflow, operating model, and decision architecture.”

That proximity cuts both ways, Gogia noted. “FDEs are embedded inside the customer’s [environment], but they are also connected to the vendor’s commercial center of gravity. Their instinct will be to build around the model family, tooling assumptions, deployment patterns, and product roadmap they know best. This is perfectly natural. It is also precisely why CIOs must be cautious,” he said.

Allowing AI vendor employees an outsized say in enterprise deployment decisions could lock in model vendor dependency, which in turn will fuel high prices that can’t be fought effectively.

“FDEs can accelerate deployment and deepen dependency at the same time,” Gogia said. “Frontier AI vendors are no longer content to sell access to models. They increasingly want to shape how enterprises deploy intelligence. That is a larger prize.”

What happens when the FDE team leaves?

FDE post-departure risks are severe and often underappreciated, according to Justin Greis, CEO of consulting firm Acceligence and former head of the North American cybersecurity practice at McKinsey.

For one thing, the FDE team learns a massive number of operational details from the enterprise deployment. Although NDAs and confidentiality contracts protect any data accessed, they often don’t regulate observed processes and procedures. 

“The learnings are absolutely going to be taken from client to client,” Greis said. “Whoever helps deploy AI will learn far more than what appears in the statement of work. They will learn the real workflows, the undocumented exceptions, the data-quality gaps, the approval bottlenecks, the security workarounds, and the places where the business depends on a few people knowing what to do when the process breaks. That knowledge may be as sensitive and precious as the data itself.”

Another critical but often overlooked issue is how much meaningful control will IT have over the project if and when the FDE team leaves.

“The danger is not using outside help. Most companies will need outside help,” Greis said. “The danger is using outside help in a way that leaves the enterprise less capable and more dependent when the engagement is over.”

It is precisely those operational decisions that IT often neglects, said Solidroad’s Kim.

“The best predictor of success is not the vendor. It is whether one internal engineer truly understands the system before the implementer leaves. What matters is who owns the evaluation loop after the demo,” Kim said.

“What happens to our prompts, scorers, and guardrails when the model version changes? If we paused this engagement tomorrow, what would actually stop working, by design or by accident?” Kim asked. “Where do you want the enterprise’s AI learning, control, and dependency to live after the engagement is over?”

Kim argues that observability — the ability to understand and manage all elements of a complex enterprise environment — is a critical function to which IT often gives insufficient attention. Determining whether the project uses the enterprise’s observability stack or the vendor’s observability stack is crucial.

“If the implementer is using their observability stack, that is fine during the build, but you need a plan to migrate it to something you own before they leave; otherwise the visibility walks out of the door with them,” Kim said. “If they are using yours, that is the best case. It means they are working inside the system your team will operate long-term.”

A major problem crops up when they are using neither the enterprise’s nor the vendor’s observability stack. “Neither means they are building the system without any production observability layer at all, and you inherit a system you cannot see into. The first time something breaks in production, you have no traces, no failure history, and no way to tell whether the issue is a model regression, a data problem, or a code bug,” Kim said.

“If observability was not a priority during the build, evals and regression testing usually weren’t either, so you are inheriting a system you cannot measure and cannot safely change. That’s the worst possible handoff position,” he said.

Weighing the alternatives

While the FDE approach is not new, it is just now beginning a surge in popularity, and there are a finite number of such specialists available. That means not all companies even have the option of using FDEs.

This availability disconnect is especially prominent for non-US deployments, where on-site FDEs are rarer, said Gartner’s Henein. “Where is the development happening? There may not be FDEs available in that region,” he said. 

There are plenty of other places enterprises can turn to for AI help. Ishraq Khan, CEO of coding productivity tool vendor Kodezi, encourages IT executives to consider a wide range of options but notes that all approaches have major drawbacks.

“Traditional consultancies are usually stronger at governance, process, compliance, and organizational coordination. They know how large enterprises operate politically and structurally. The downside is that many move slower and often lack deep frontier AI specialization,” Khan said.

Gogia from Greyhound Research put it more colorfully: Traditional IT consulting firms “know how to get legal, risk, security, finance, HR, and business units into the same room without anybody setting fire to the carpet. For regulated enterprises, that matters,” he said.

Specialized AI consultancies have a different set of strengths, Khan said. “AI-native consultancies move much faster and are often more technically current, but many are still immature operationally. Some can build impressive demos without fully understanding long-term maintainability, governance, or production reliability.”

Greis from Acceligence commented on two other options for bringing in outside AI help. Using an independent contractor “can be great for eval design, architecture reviews, red teaming, agent design, or getting a stalled team unstuck,” he said, but it can increase the risk of “key-person dependency,” where a single external person is the only one who understands the system.

As for purchasing an AI firm and onboarding its employees, a practice known as “acquihiring,” Greis said it can work well when the AI capability and expertise being brought in are truly strategic for the acquiring enterprise. But there is a risk that the acquired team will be smothered by the parent company’s bureaucracy: “You buy a speedboat, bolt it to an aircraft carrier, and then wonder why it stopped moving,” he said.

Finally, an open-source strategy can give companies flexibility and reduce vendor dependence, but “many companies underestimate the operational burden that comes with it,” Kodezi’s Khan said. “Open source only helps if the organization has the internal talent and discipline to maintain it properly.”

Bottom line: enterprises need to define their true objectives before deciding on an approach. Khan offered several key questions for CIOs to consider: “Who owns the deployment after implementation? Can we move providers later without rebuilding everything? What happens if the vendor relationship changes or disappears? Are we optimizing for short-term deployment speed or long-term operational resilience?”

In any scenario where outside firms have direct access to enterprise systems, IT needs to be kept fully in the loop. “The worst outcome is when an enterprise successfully deploys AI but no longer fully understands how its own systems operate underneath,” Khan said.

External help for AI deployments: 6 options

	Pros	Cons
AI vendor FDEs	+  Best expertise on the main model being used	–  Vendor lock-in –  Operational detail leaks
Traditional IT consultancies	+  Best understanding of change management, legacy integration, global rollout, governance, and operating-model redesign	–  Can be too slow, too expensive, or too generic
AI consulting firms	+  More practical AI deployment experience than traditional consultants +  Less vendor lock-in than model-provider FDEs	–  May not sufficiently understand enterprise-grade requirements: security, identity, auditability, compliance, incident response, cost controls, and long-term maintainability
Independent contractors	+  Useful for precision tasks: eval design, architecture reviews, red teaming, agent design, or getting a stalled team unstuck	–  Risk of ‘key-person dependency’
‘Acquihiring’ an AI firm	+  Works when the acquired capability is truly strategic	–  Acquired team can be smothered inside existing bureaucracy
Deploying open-source products	+  Reduces dependency on one model vendor +  Attractive for data sovereignty, control over enterprise systems, cost efficiencies, and regulated environments	–  Enterprise takes on full responsibility for security, patching, evaluation, deployment, monitoring, and lifecycle management

Related reading:

• Here’s one career emerging from the AI shift: ‘forward-deployed engineers’
• The forward-deployed engineer: Why talent, not technology, is the true bottleneck for enterprise AI
• The new AI lock-in

Too many enterprises remain ignorant of the European Union’s 2024 Cyber Resilience Act, the first elements of which enter force on June 11, according to a new survey.

Two-thirds of respondents to the survey by Open Source Security Foundation said they were unfamiliar with the CRA, which aims to make hardware and software sold in the EU more secure.

As well as the CRA’s demands on vendors, it also has implications for users of open-source software, hence the Foundation’s interest in the topic. Among other measures, the CRA creates the role of open-source steward within the enterprise, with responsibility for ensuring that a security policy is in place for any software being used within the organization.

The first part of the CRA to enter force, on June 11, concerns the designation of conformity assessment bodies by member states. Then, from September 11, manufacturers will be required to begin reporting vulnerabilities in their products to the relevant authorities. The remaining obligations under the Act, which include substantial financial penalties, will apply from December 11, 2027.

The impending sanctions seem not to have concerned businesses: 56 percent of respondents to the OpenSSF survey were unaware that non-compliance fines could reach €15 million or 2.5 percent of global annual turnover.

The lack of knowledge about the implications of the Act surprised OpenSSF CTO Christopher Robinson. “We’ve been speaking on this topic for some time and we’re scratching our heads on why more companies are not aware of the implications of the Act,” he said.

Global concern

He surmised that some companies don’t think EU regulations on hardware and software security apply to them — but such concerns will soon be a global matter. “Other countries, like Japan, are considering similar laws,” he said.

One area of misunderstanding could be that the CRA applies to vendors, and their customers may think that the requirements under the Act didn’t apply to them. He said that this was a misguided approach, particularly when the CRA’s application to open-source software is taken into account.

“There are about 700 million projects in Git Hub. If you work for an organization like a bank, you have little idea which of those projects are being used,” he said.

Under the Act, software companies will have to supply a software bill of materials (SBOM) that has been passed as secure, he said.

Companies that supply US federal government organizations already face this requirement, he said: “If you’re selling to the US government — which is the largest customer on the planet – you should be providing an SBOM.”

Cybersecurity consultant Hans Study said that by addressing the supply chain issue, the CRA is a step in the right direction. “Almost every application has dependencies, whether that is free and open-source software, commercial packages, or some mix of both. The problem has always been responsibility, and the blame game that comes with it. What the CRA does is make it harder for companies to dodge that responsibility when they are building, selling, or placing products with digital elements on the market,” he said.

AI ignorance

According to Michael Callahan, VP of Cyber Strategy at Salt Security, one of the issues that could cause problems in the future is the growing use of AI in the software development process. “The Cyber Resilience Act assumes enterprises know what is in their software. That assumption breaks down when AI coding assistants are generating a significant share of code. An AI assistant has never read your organization’s security policies, your licensing obligations, or your open-source governance standards. The code it produces may contain dependencies, patterns, or vulnerabilities that your security team cannot easily trace back to a specific decision or a specific developer.”

Enterprises are quickly running out time to fix issues and many are pessimistic about their chances. According to the OpenSSF survey, only 41percent of manufacturers expect to be fully compliant by December 2027, while 39 percent do not know when they will be.

It may be that the proposed fines could concentrate minds. Robinson said that it could be like GDPR where a few heavy fines drew companies’ attention to the regulation. The upper limit on fines is per infraction, not per company, he said: “Something like that could wipe out an SME and seriously hit large corporations.” The legislation should be something that all businesses need to be aware of, but there is still a long way to go.

This article first appeared on CIO.

AIs struggle to understand documents designed for humans; the DocLang working group seeks to flip that imbalance with its specification for machine-readable business documents “built from the ground up for LLM tokenizers.”

The working group, founded by IBM, Nvidia, and Red Hat and hosted by the Linux Foundation’s LF AI & Data project, aims to create an open, universal, AI-native document format designed to improve how enterprises prepare, exchange, and govern document data for AI systems. ABBYY and Human Signal will also be involved in its development, and other contributors are welcome.

“Enterprises today work across a fragmented landscape of document formats, including PDFs, JPEGs, and other file types built primarily for human consumption rather than AI interpretation,” the group said in its launch announcement.

“This disconnect can introduce complexity, raise costs, and reduce reliability when extracting meaning from business documents,” as organizations increasingly rely on generative AI and agentic systems, it said.

Mark Collier, executive director of LF AI & Data, said the goal of the DocLang Specification Working Group is to “develop a vendor-neutral, interoperable standard that helps organizations prepare document data for AI more reliably, transparently, and at scale.”

DocLang defines a structured, machine-readable format for documents of any type, like JSON for data, that any tool can implement and any pipeline can consume. It builds on DocLing, a document processing toolkit hosted by LF AI & Data that can transform human-readable PDFs, word processor documents or spreadsheets into structured data.

Standards must evolve for AI

Something like DocLang is needed, said independent technology analyst Carmi Levy. “Existing document standards have done an admirable job allowing global stakeholders to confidently collaborate for decades, but it’s becoming increasingly clear that they are in desperate need of an update as AI reshapes the rules around how work gets done,” he explained.

Largely static document types, he said, “can be somewhat limiting when AI is redefining the very word, ‘document.’ In many ways. AI-age documents are far more iterative and dynamic than what they once were, and the definitions need to evolve with the times. The documents we currently live with simply weren’t designed for the AI age.”

Within that context, Levy said, “DocLang represents an early, best hope of achieving some kind of foundational baseline for document standards, one that will hopefully allow more intelligent, more efficient, lower-risk workflows than is currently the case.”

Taking an open-source, vendor-agnostic approach to the process ensures the collective will take precedence over the needs of specific vendors, he said, adding, “earlier standards-setting efforts around networking, documentation, the web, and the cloud powered the free-flowing digital landscape that defines modern life.”

An AI-centric documentation standard will carry that reality into the next generation of technology, said Levy.

A question of governance

The entire concept of LLMs, Jason Andersen, principal analyst at Moor Insights & Strategy said, “involves using natural human languages. The computer is supposed to understand us without us changing our syntax or language. Forcing a syntax on users is exactly what we have today with SEO and more advanced programming languages.”

With something like DocLang, where the standard can be applied to content ingestion, he said, “I would be OK with that being automated, which seems to be the intent. The use case I envision is that when I upload a document to an agent, a skill can be run to preprocess the document into the DocLang standard format, saving tokens.”

That makes sense, he said, adding that he thinks it’s good “if it can help generate outputs, like a visualization, that can be shared outside an AI tool. On that front, that is also why I am liking Web MCP, since you are just adding some code to the page, like CSS or JavaScript, and the consumer, in this case, an AI browser or skill, is better equipped to handle the site.”

The point, he said, is, “these standards need to preserve the fact that humans can still do what they want, and do not need to know any coding to be proficient. In terms of governance, I am not sure if it matters.”

But one analyst did foresee governance problems arising from DocLang’s use.

Yaz Palanichamy, senior research analyst at Info-Tech Research Group, said DocLang adoption will require organizations to implement and review controls in order to scale its use accountably and securely.

This article originally appeared on CIO.com.

Enterprises are moving aggressively into generative AI. On the surface, that seems like the right call. The technology is powerful, accessible, and increasingly embedded in how businesses build applications, automate processes, and support decision-making. A development team can connect an application to a large language model in days. A product team can add AI features in weeks. Business leaders see quick wins, faster innovation, and a path to modernizing nearly every part of the company.

These are the upsides everyone is talking about. The part we don’t discuss enough is the economic trap forming underneath all this convenience.

Most enterprises think of tokens as a technical billing detail. They are not. Tokens are the unit of economic dependency in generative AI. Every prompt, response, summarization, retrieval step, workflow action, and agent decision is measured and monetized through tokens. Tokens are not just part of the plumbing. They are the tollbooth between your enterprise and a provider’s intelligence platform. The more AI becomes central to your operations, the more power that tollbooth holds over your future costs.

Tokens are not just a pricing unit

A token is usually described as a chunk of text processed by a model. That is accurate enough for developers, but it misses the bigger issue for CIOs, architects, and corporate boards. In the enterprise, tokens are the mechanism by which AI capabilities are rented. They are the meter attached to the intelligence itself.

That distinction matters because token usage grows faster than most companies anticipate. A simple user prompt rarely remains simple in production systems. It can trigger retrieval from internal knowledge stores, multiple model calls, tool use, post-processing, policy checks, and agent loops. What appears to be a single transaction to the user may involve several layers of token consumption behind the scenes. As a result, enterprises often underestimate the true operating cost of AI-enabled systems, especially as those systems mature and spread across departments.

Today, those costs still feel manageable. In many cases, they feel surprisingly low. That is exactly why the trap is so dangerous.

The market is in a subsidy phase

Current token pricing is giving enterprises a false sense of comfort. Many remote LLM providers are aggressively competing for market share. They want developers building on their APIs. They want enterprise applications tightly coupled to their platforms. They want AI agents, copilots, workflows, and customer experiences to depend on their models. To make that happen, pricing remains highly attractive relative to the value delivered.

That does not mean the economics of generative AI are stable. It means the market is still being shaped by investor capital, strategic pricing, and growth expectations. Providers are racing to establish position, and enterprises are benefiting from that race. But no market stays in that phase forever. At some point, investors will expect durable profitability. At some point, weaker providers will disappear, consolidate, or retreat. At some point, the survivors will have more leverage and much less reason to price primarily for adoption.

That’s when the token trap closes.

Enterprises that build deep dependence on remote models during the subsidy phase may find that what seemed inexpensive at pilot scale becomes punishing at enterprise scale. The application that costs $1,000 per month today may cost 10 or 20 times that amount a few years from now, not only because usage has increased, but also because the market has repriced the dependency.

Easy to adopt, expensive to exit

Cloud computing followed a similar path, with many enterprises mistaking short-term convenience for long-term economics. In the early years, the case was compelling and largely accurate. Move faster, reduce friction, avoid capital spending, and scale with ease. Those benefits were real. Many organizations made architectural decisions that prioritized speed over leverage. They became dependent on managed services, provider-specific tools, and operating models that were easy to adopt but expensive to unwind.

Years later, many enterprises discovered that their cloud bills were much higher than expected and their exit options much narrower than advertised. That was not because the cloud failed. Architectural dependency eventually became financial dependency.

Generative AI is repeating that pattern, only faster. The integration barrier is lower, the pressure to adopt is higher, and the pace of enterprise experimentation is far greater. As a result, companies are wiring remote LLMs into applications, workflows, and agentic systems with very little thought about how these costs will behave in the next five to 10 years.

Agentic AI makes things worse

The more enterprises move from simple prompt-response systems to agentic architectures, the more dangerous the token trap becomes. Agents are not single-call systems. They plan, deliberate, retrieve information, invoke tools, evaluate results, retry steps, and often coordinate with other agents. Each of those actions consumes tokens. Costs no longer rise in a neat linear fashion. They compound.

This matters because agentic AI is increasingly being presented as the future of enterprise automation. It’s true in many cases. But if an enterprise builds agentic systems primarily on remotely hosted intelligence, it is also building future business processes on top of someone else’s pricing model. That is a major strategic risk. The more successful those systems become, the harder they are to replace. The harder they are to replace, the more pricing power shifts to the provider.

This is how businesses end up operationally dependent on a cost structure they do not control.

The appeal of AI sovereignty

The answer is not to reject public models or pretend that external providers play no role. They clearly do. There will always be cases where renting frontier AI capabilities makes sense. But enterprises need to stop assuming that renting is the default for every workload.

AI sovereignty is the alternative that deserves much more attention. That means building, tuning, deploying, and governing models inside the enterprise for use cases where long-term control matters more than access to the absolute frontier. Enterprises need to recognize that most business applications do not need a world-class general-purpose model. They need a model that is good enough for a specific purpose, aligned to the enterprise’s data, governed by the enterprise’s rules, and operated at a predictable cost.

It’s a very different way of thinking.

A self-hosted or enterprise-controlled model may not match the rich feature set of the largest public offerings. It may lack the same breadth, polish, or marketing appeal. But for many internal business tasks, those factors do not matter.

Here’s the most critical question to guide your architectural direction: Can a sovereign AI model solve the problem reliably, securely, and economically over time? If the answer is yes, owning that capability may be far more strategic than forever renting something with more power than you need. In effect, the enterprise becomes its own provider for the workloads that matter most.

Prepare for changing markets

Too many companies still treat generative AI architecture as a tactical IT issue. It is not. These decisions directly affect cost structure, operating flexibility, data control, and long-term competitiveness. If AI becomes a force multiplier across the business, the economics of AI become strategic to the business itself.

The companies that get this right will not necessarily be the fastest adopters. They will understand the difference between experimentation and dependency. They will use external models when it makes sense, but they will also invest in sovereign capabilities where ownership matters. They will think like architects, not consumers.

Here’s the takeaway: Cheap tokens come with strings. They are a gateway to a dependency model that will typically look very different once providers stop pricing for growth and start pricing for leverage. Enterprises cannot keep mistaking today’s bargain for tomorrow’s reality. Boards and executive teams need to act now to get ahead of this issue. The key question is not whether generative AI creates value. It clearly does. The real question is whether the enterprise can still afford and control the value it creates once the market matures.

Agentic AI has moved from conference hype to a budget line item. This is where the conversation gets more interesting and more uncomfortable. Unlike traditional AI systems that respond to a single prompt, classify a document, recommend an action, or generate a summary, agentic AI systems are designed to pursue goals. They plan, call tools, inspect results, retry failed steps, consult memory, hand off tasks to other agents, and sometimes critique their own work before producing an answer or taking an action.

That extra autonomy is the value proposition. It also introduces the cost problem.

A single chatbot interaction may consume a few thousand tokens. A useful agentic workflow can consume hundreds of thousands or millions of tokens per day because it does more than answer a question. It decomposes the problem, retrieves context, reasons through options, invokes APIs, checks the output, and often runs multiple passes before reaching a result. Therefore, the economics need to be understood at the level of “agent instances,” not just model calls.

For the estimates below, I am using a blended token cost of $3 dollars per million tokens. This is not intended to reflect a single vendor’s list price. It is a blended planning figure that assumes a mix of input and output tokens, reasoning steps, retrieval-augmented generation, summarization, tool calls, memory updates, and occasional use of larger context windows. Some enterprises will pay less through volume discounts or by routing work to smaller models. Others will pay more by using premium models, long-context prompts, web browsing, large document ingestion, and repeated reasoning loops.

The basic formula is straightforward. If an agent consumes 2 million tokens per day, it consumes 730 million tokens per year. At $3 per million tokens, that single agent costs about $2,190 per year in token burn. That number sounds surprisingly low until you multiply it by the number of agents, workflows, and users, plus the surrounding infrastructure required to run these systems safely.

What an agent really costs

In the model used here, the annual token-only cost per agent ranges from about $1,095 to $3,833, depending on the use case.

• A lightweight HR recruiting or onboarding agent that consumes one million tokens per day costs about $1,095 per year.
• A more demanding software engineering agent that consumes 3.5 million tokens per day costs about $3,833 per year.
• Customer support agents are roughly $2,190 per year.
• Legal contract agents cost about $2,409 per year.
• Security triage agents run about $2,738 per year.
• Research agents are around $3,066 per year.

These figures are useful but incomplete. They include only LLM token consumption and exclude orchestration platforms, vector databases, observability, model evaluation, security controls, workflow monitoring, human review, enterprise application integration, data pipelines, audit logging, prompt management, and the engineers needed to build and maintain the systems. In real deployments, I would expect the all-in operating cost to be two to five times the raw token cost. For regulated or mission-critical environments, the multiplier can be even higher.

This is where many agentic AI business cases become less clear. The model call may be inexpensive, but the system around the model is not. An agent that can update a customer relationship management system, approve a refund, generate a purchase order, or recommend a security containment action needs guardrails, permissions, logging, rollback mechanisms, and human escalation paths. These are not optional features. They are the difference between a demo and an enterprise system.

Use cases that make economic sense

Customer support is one of the more obvious use cases. A typical support automation deployment may use eight agents: an intake classifier, a knowledge retrieval agent, a response drafting agent, an escalation agent, a quality review agent, a CRM update agent, a sentiment detection agent, and an analytics agent. At two million tokens per agent per day, each agent costs about $2,190 per year in token burn, bringing the annual total to roughly $17,520. If that system deflects even a modest number of tickets or improves agent productivity, the economics can be attractive.

Sales development is another practical example. A five-agent system for account research, lead enrichment, email personalization, CRM updates, and follow-up scheduling may consume 1.2 million tokens per agent per day. That results in an annual cost of about $1,314 per agent, or $6,570 for the full agent team. This can be compelling if it improves pipeline quality, but it can also be wasteful if agents generate low-quality outreach at scale. The cost of brand damage is not measured in tokens.

Software engineering is more expensive but potentially more valuable. A 12-agent system covering requirements analysis, architecture, code generation, testing, review, security checks, documentation, CI debugging, refactoring, release notes, dependency analysis, and hot-fix support may consume 3.5 million tokens per agent per day. That works out to about $3,833 per agent annually or roughly $45,990 for the full system. Compared with engineering salaries, the token cost is small. The real question is whether the system reliably improves throughput without increasing defects, security vulnerabilities, or maintenance complexity.

Security operations also fit the agentic model because the work is repetitive, time-sensitive, and context-intensive. A 10-agent security triage system could include agents for alert triage, log analysis, threat intelligence, endpoint investigation, network investigation, incident summarization, ticketing, compliance evidence, escalation, and post-mortem. At 2.5 million tokens per agent per day, the annual token cost is about $2,738 per agent or $27,375 for the system. This is easy to justify if it reduces alert fatigue and accelerates response, but risky if the agents hallucinate causality or bury critical signals in confident summaries.

Finance, legal, healthcare administration, market research, HR, and supply chain are also viable:

• A six-agent finance close system may cost about $9,855 per year in token burn.
• A four-agent legal contract review system may cost about $9,636.
• A seven-agent healthcare administrative workflow may cost about $13,797.
• Competitive intelligence using six agents may cost $18,396.
• HR recruiting and onboarding using five agents may cost $5,475.
• Supply chain planning and exception management using eight agents may cost $21,024.

Across all 10 example use cases I’ve mentioned in this section, the model assumes 71 agents and a total annual token burn of about $175,638.

The comparison with traditional AI

The economics of agentic AI should always be compared with simpler approaches. Traditional AI, workflow automation, rule engines, robotic process automation, and non-agentic LLM calls are often cheaper, easier to govern, and more predictable. Agentic AI is usually overkill for tasks like classification, extraction, summarization, routing, or drafting within a narrow context. A deterministic workflow with a single model call can do the job at a fraction of the cost and risk.

Agentic systems make sense when the process requires judgment across multiple steps, dynamic planning, tool use, exception handling, and adaptation to incomplete information. They are valuable when the path to the answer cannot be fully scripted in advance. They are less valuable when enterprises use them as a trendy substitute for basic automation.

The best architecture is usually hybrid. Use traditional automation where the process is stable. Use non-agentic AI where the task is bounded. Use agentic AI only where autonomy creates measurable leverage. That means fewer agents, tighter scopes, explicit budgets, model routing, token monitoring, and human checkpoints for high-impact decisions.

The financial mistake many organizations will make is to treat agents as digital employees with near-zero marginal cost. They are not. They are probabilistic software components that consume tokens, trigger tools, create operational dependencies, and require supervision. The token bill may be manageable. The governance bill may not be.

Agentic AI can absolutely be worth the money. In many cases, the annual token burn for a useful agent team is less than the loaded cost of a single employee. But that is not the same as saying it is cheap. Companies must measure agent cost per completed business outcome, not cost per prompt or cost per model call. In the end, the question is not how much an agent costs. Ask yourself the right question: Does the autonomy an agent provides outweigh the complexity it introduces?

AI governance is an ongoing game of catch-up for enterprises. Model updates and iterations are rolling out at a rapid clip, often making governance frameworks obsolete before they’re battle-tested.

To evolve beyond this paradigm, OpenAI is introducing Active sessions. This new ChatGPT security feature allows users to review and log out of one or more sessions through a simple interface. The feature is now available across all ChatGPT accounts and workspace types, including personal and managed workspaces. Experts call it an important development for the model provider, which currently has 1 billion monthly active users.

Previously, organizations often had limited visibility into where users were logged in, and simply relied on password resets or broad account actions to force re-authentication, noted Ensar Seker, CISO at SOCRadar. “Granular session control is a more efficient and less disruptive approach. From a governance perspective, session transparency improves accountability and supports investigations,” he explained.

A holistic view across session activity

Active sessions allows admins to see known browser and app sessions across ChatGPT, Codex, and API Platform. Specifically, they are able to view device and browser information, approximate location, sign-in date and time, whether a device is trusted, and whether the session is current.

To access the feature, users can go to ‘Settings’ > ‘Security’ > ‘Active sessions.’ They can then log out of specific sessions and remove devices from trusted services. They also have the ability to log out of all sessions (thus ending sessions across devices), however, this action can take up to 30 minutes to complete.

However, OpenAI emphasizes that session details may be “approximate or incomplete,” and that the feature has limits. It does not show or manage connected apps or third-party app sessions, sign-ins through third-party services, Codex CLI sessions, or recently signed-out sessions.

Further, Active sessions cannot be used with accounts linked to an enterprise’s single sign-on (SSO), including security assertion markup language (SAML) and OpenID Connect (OIDC).

Better late than never

While Active sessions is an important security and governance development, experts note that the feature is basic, and was a long time coming.

“The reality of OpenAI offering the ability to end active sessions on ChatGPT by administrators is that it’s something that exists in lots of platforms,” said David Shipley of Beauceron Security. “They should’ve had it sooner, but better late than never.”

From a security standpoint, he noted, OpenAI could do a better job policing ChatGPT to prevent it being used by threat actors to host malware, which is the latest threat to enterprises.

SOCRadar’s Seker also pointed out that this type of visibility and oversight is something that enterprises have expected from SaaS platforms for years. “It allows administrators and users to quickly identify unauthorized access, terminate stale sessions, and reduce the risk of account compromise persisting undetected.”

Iterative upgrades disrupt governance

Last week, OpenAI updated GPT-5.5 Instant in both the ChatGPT app and API to “improve response style and quality,” the company said. It had rolled out GPT-5.5 Instant earlier in May as a successor to GPT‑5.3 Instant, calling it “generally smarter” and prone to fewer hallucinations.

According to OpenAI, the update makes GPT-5.5 Instant “easier to read, more natural in everyday conversations, and better paced in practical help tasks, with fewer overly long or bullet-heavy responses.”

But even with tools like Active sessions, enterprises continue to struggle with governance amidst seemingly continuous iterative model updates. It’s simply not sustainable, said Beauceron’s Shipley: “How do you build an appropriate testing plan with a nondeterministic system?”

SOCRadar’s Seker pointed out that many organizations perform security, compliance, and business validation testing before approving a model for production use. But, “when model behavior changes under the same version family, previously documented assumptions may no longer fully reflect actual performance,” he noted.

“The biggest governance challenge in AI is not model adoption, it’s model change,” Seker said. “Most organizations can evaluate a model once. Far fewer are prepared to continuously evaluate how that model evolves over time.”

This particularly creates challenges for regulated industries where auditability, repeatability, and change management are critical, he said. Even beneficial improvements can introduce governance concerns if organizations are not clearly informed about what changed and when.

Valence Howden, advisory fellow at Info-Tech Research Group, noted that organizations often can’t assess the implications of model iterations against their boundaries, and, worse, are often unaware of them.

While the biggest enterprise challenge was initially tied to which AI model was being used, what that model did, and who owned it, iterative updates can muddy those waters and increase reliance on third party practices and tools that organizations often don’t have the resources for, he noted. 

“Without the ability to opt out [of an update] before it’s incorporated, [enterprises] are basically red-teaming the updates with their clients,” said Howden.

The ongoing game

Security teams today are pushed to their limits because they are expected to manage rapidly evolving models, new features, and changing behaviors, while maintaining compliance, risk management, and business continuity, said SOCRadar’s Seker.

“Governance is difficult because organizations are no longer evaluating a static product,” he said. Rather, they are managing a “continuously evolving service” where capabilities, integrations, and user behaviors can change far faster than can traditional security review cycles.

Info-Tech’s Howden agreed, saying that enterprises’ existing governance practices, especially accountability, are poor, as are their risk practices.

“It’s hard to suddenly become good at things they’re already poor at doing,” he said. “They are also incentivized for speed and innovation, so they ignore governance as a constraint, or don’t want to do it at all.”

How enterprises should respond

Seker advised that, ultimately, organizations should treat AI models as living systems rather than fixed software releases.

Security and governance programs should include continuous validation, monitoring, and periodic re-assessment instead of sole reliance on one-time approval processes, he said. Enterprises should also establish clear vendor change management expectations, including requiring transparency around model updates, behavioral changes, and potential impacts to existing workflows.

“Effective AI governance increasingly depends on visibility into change, not just visibility into risk,” Seker said.

Cloud computing has reached a crossroads. The high cost and data sensitivity of AI workloads are raising the appeal of private clouds, even as neoclouds and sovereign clouds shake up the cloud provider landscape. New cyberthreats, shifting compute requirements, and management complexity are adding to cloud complications.

Download the June 2026 issue of the Enterprise Spotlight from the editors of CIO, Computerworld, CSO, InfoWorld, and Network World, and learn how to navigate the latest cloud strategy developments.

AI could soon lead to systems capable of improving their own performance faster than humans can effectively supervise them, reviving concerns about the industry’s longstanding “alignment problem,” ensuring AI systems reliably pursue human goals, senior Anthropic researchers have warned in a new blog post titled “When AI builds itself.”

Anthropic Institute lead Marina Favaro and Anthropic co-founder Jack Clark outlined three possible futures: growth in AI capabilities may flatten out; AI efficiency gains may continue to grow, but expose bottlenecks elsewhere in software development; or AI systems may become capable of full recursive self-improvement, and build their successors by themselves. It’s that third scenario that’s prompting them to suggest society be ready to hit the brakes on AI development.

“How the alignment problem gets solved — or not — in this future is something we are least certain about,” they wrote. Advanced, self-improving models could follow our needs and wants — or, they warned, “The rare occurrences of misalignment present in today’s models could compound as the models build their successors, growing more frequent but less understood until we lose control of them. It’s possible that we can’t build, integrate, and verify the tools that we’d need to understand which trendline we are actually on.”

While Anthropic’s warning is framed around future AI development, analysts say it highlights governance questions enterprises are already beginning to confront as autonomous AI agents move from answering questions to taking actions.

“The issue is no longer just whether AI gives the right answer, but whether autonomous systems take the right action, at the right time, within the right authority,” said Ashish Banerjee, senior principal analyst at Gartner.

From model governance to agent governance

The warning comes amid growing enterprise investment in agentic AI.

Gartner predicts that by 2028, 15% of day-to-day work decisions will be made autonomously through agentic AI and that one-third of enterprise software applications will incorporate agentic AI capabilities. The firm has also warned that governance shortcomings are already emerging, predicting that 40% of enterprises will demote or decommission autonomous AI agents by 2027 after governance failures become apparent in production environments.

Banerjee said many organizations continue to approach AI agents as advanced productivity tools when they increasingly resemble digital workers operating with delegated authority.

“CIOs should stop treating AI agents as smarter chatbots,” he said. “They are becoming digital workers with delegated authority — and must be governed like privileged users, not productivity tools.”

As agents gain the ability to conduct research, write code, invoke tools, trigger workflows, and make recommendations, enterprises face new risks around unauthorized actions, accountability gaps, data exposure, tool misuse, and insufficient auditability, Banerjee said.

“Human-in-the-loop is not a strategy if the human cannot keep up with the loop,” he said.

Charlie Dai, vice president and principal analyst at Forrester, said Anthropic’s concerns mirror challenges enterprises are already encountering as AI systems gain greater autonomy.

“Alignment becomes operational,” Dai said. “It is about ensuring agents consistently act within policy, not just model accuracy.”

Current governance approaches focus largely on models and data, but increasingly autonomous agents require oversight of runtime behavior, permissions, tool usage, and decision boundaries, Dai said.

Concerns about agent oversight are not limited to AI vendors and industry analysts.

In AI Agent Governance: A Field Guide, researchers from Institute for AI Policy and Strategy warned that “society is largely unprepared for this development” and said “the exploration of agent governance questions and the development of associated interventions remain in their infancy.” The paper argues that advances in autonomous AI agents are outpacing the governance mechanisms needed to oversee them.

Both analysts argued that governance frameworks originally designed for generative AI models may prove insufficient for increasingly autonomous systems. Dai said organizations will need greater oversight of runtime behavior, permissions, tool usage, and decision boundaries as agents become more capable.

Why Anthropic is worried

Anthropic’s researchers argue that those governance questions could become significantly harder if AI systems become increasingly involved in the process of AI research and development itself.

Favaro and Clark stopped short of predicting that fully autonomous recursive self-improvement is inevitable. Instead, they argued that the possibility warrants preparation and discussion among developers, policymakers, and other stakeholders. They also suggested the industry may eventually need mechanisms to slow development if capabilities begin advancing faster than safeguards, while acknowledging that such measures carry risks of their own.

“But if a slowdown simply lets the least cautious actors catch up technologically, it could leave everyone less safe,” they wrote in the blog post.

Forrester’s Dai said the practical implication for enterprises is that governance can no longer depend primarily on human review.

“Supervision becomes architectural, not manual,” he said. Organizations will increasingly need bounded autonomy, embedded guardrails, verifiable execution mechanisms, and fallback controls designed into agentic systems from the outset.

Cloud computing has reached a crossroads. The high cost and data sensitivity of AI workloads are raising the appeal of private clouds, even as neoclouds and sovereign clouds shake up the cloud provider landscape. New cyberthreats, shifting compute requirements, and management complexity are adding to cloud complications.

Download the June 2026 issue of the Enterprise Spotlight from the editors of CIO, Computerworld, CSO, InfoWorld, and Network World, and learn how to navigate the latest cloud strategy developments.

Enterprise IT leaders have always struggled with AI pricing, especially the need to pay for AI in a way that delivers ROI. But the typical IT exec may not be right person to decide how a company uses AI — and how it tries to deliver ROI — because so many line-of-business workers and partners are now experimenting with the technology on their own.

And if IT leaders don’t have a grip on how they want to use AI over the next year or two, it’s impossible to figure out how they want to pay for it. They likely hate the current method of paying per token. And other options, such as SAP’s push to charge per AI task completed, aren’t any better. 

To use a sales analogy, IT doesn’t want to pay a lot of money for leads, because there’s no way to know if those leads will generate any revenue — let alone how much. What IT leaders want is the tech equivalent of paying commission, where they only pay when a lead converts into a paying customer. And even then, they only pay a percentage of the final sale. That guarantees ROI for the enterprise.

The problem: no AI vendor would ever go for it because that approach puts too much risk on them. 

Finding a pricing model that works for both enterprise IT and AI vendors is all but impossible as long as IT is trying to deliver ROI.

Irfan Khan, president of SAP Data & Analytics, said the problem is challenging for both sides. “Everyone is scrambling to justify their investments,” and “the day one cost is not necessarily the day one value,” he said.

The problem is one of sequence. Pricing has to be negotiated and locked in long before a project starts. But with technology as new and experimental as agentic AI, there’s almost no solid information about what benefits it will (or will not) actually deliver. 

Beyond that, generative AI (genAI) and agentic AI systems might well deliver benefits that are harder to jot down in a spreadsheet. Let’s say the CFO wants to see a sharp rise in order fulfillment. But what if AI “manages to fulfill those orders more efficiently,” Khan said. “And what are the likely ripple effects of bringing more efficiencies into the process?”

Justin Greis, CEO of consulting firm Acceligence, frames the AI pricing disconnect in terms of market economics:

“The market is trying to force-fit AI into infrastructure-era pricing models, when AI is fundamentally closer to labor augmentation and business process transformation than compute consumption,” Greis said. “The core disconnect is: Enterprise IT buyers want pricing aligned to realized business value. AI vendors want pricing aligned to resource consumption and platform utilization. Those are very different economic models. 

“Token pricing is attractive to vendors because it is measurable, scalable, and predictable. But from the enterprise perspective, tokens are almost meaningless as a business metric. Nobody on the CFO side cares how many tokens were consumed if the process improvement never materialized.”

The competing pricing strategies overwhelmingly rely on just two factors: what delivers the most profit and which is the easiest to execute. Given human nature, the latter is usually the path most often taken.

It’s like one of my favorite jokes. A guy is heading to his car when he sees a man with a flashlight intently looking at the ground right next to a streetlight pole. 

“Can I help you? Are you looking for something?” the guy asks.

“Yes, I lost my car keys.”

“Silly question, but where do you last remember having them?”

“I was standing over there in that dark alley up the street. A cat screeched and I dropped my keys.”

“Wait a second — if you lost your keys over there, why are you looking here?”

“The light’s better over here.”

The lesson: taking the easy route usually beats realizing the actual objective.

Greis argued that not only would it be hard to persuade AI vendors to accept ROI pricing, but if they did  somehow agree, the unintended results could prove disastrous. 

“AI vendors cannot realistically absorb unlimited downstream business risk tied to variables they don’t control — poor internal adoption, broken processes, bad data, organizational politics, weak change management, or unclear KPIs. But the moment vendors are compensated primarily on outcomes, you create strong incentives for increasingly autonomous optimization behavior. That sounds great until organizations realize that AI systems may pursue the metric rather than the intent behind the metric,” Greis said. 

“We’ve already seen versions of this in recommendation engines, ad targeting systems, and engagement algorithms. The system learns to maximize the measurable outcome even if the methods become operationally risky, ethically questionable, reputationally damaging, or strategically misaligned. In enterprise environments, that could become dangerous very quickly. An AI system incentivized around reducing service costs might aggressively deflect legitimate customer issues. A model rewarded for sales conversion could push manipulative messaging or optimize for short-term wins at the expense of customer trust. A procurement optimization engine might lower costs while quietly increasing supplier concentration risk or degrading operational resilience.

“The more autonomous these systems become, the harder it is to separate ‘successful outcome’ from ‘acceptable behavior.’”

The best way to resolve this is potentially the most difficult. Every AI project must be approved by an AI committee whose members must ask the hard questions. What are you hoping to accomplish? If it works, specify and quantify your best-case scenario benefits. What are the most likely ways it could fail? What are the costs and disruptions most likely to happen if it fails in that way? Quantify those. 

The committee should have at least a couple of members who know exactly what these models can and cannot do to serve as a reality check. 

Next, require the LOB chief, or whoever the most senior exec involved in the project is, to share in the pain. Tie gains or losses to executive bonuses. Give those execs a reason to make sure their people are honestly and creatively thinking the project all of the way through. 

Only once that happens can a CIO know how to negotiate a fair and reasonable AI pricing deal.

Over the next three to five years, both governments and the private sector will need to rapidly adapt identification and mitigation protocols as adversaries move from AI-assisted to AI-enabled sanctions evasion and proliferation financing (PF), a new research paper warns.

The report, Algorithms of Evasion: The Rise of AI-Enabled Proliferation Financing, from the Royal United Services Institute (RUSI), a UK-based defense and security think tank, defines PF as the use of funds or financial services to acquire, develop or otherwise deal in weapons of mass destruction (WMD). It states, “North Korea and Iran are now developing and deploying AI models to aid with sanctions evasion activities.”

Key findings include the fact that AI is now capable of mass producing high-quality fraudulent documents, as well as automating what the report describes as “the administrative minutia of managing extensive shell company  networks.” AI powered systems, it states, can also “analyze blockchain patterns in real time to dynamically adjust cryptocurrency mixing strategies, effectively evading detection tools.”

In addition, it says, “[tools such as generative AI] which can produce sophisticated fraudulent identification documents, for example, have helped North Korea perpetrate phishing attacks against Western companies.”

Dr. Aaron Arnold, senior associate fellow with the Centre for Finance and Security at RUSI, who authored the paper, said in an email that what prompted it was an uptick over the last year in North Korea’s use of AI to facilitate and enhance its cyber operations, in the form of phishing schemes designed to generate revenue for the country’s ballistic missile and nuclear weapons programs.

He advised enterprise IT managers who need to protect their organizations from becoming victims of sanction evasion activities that “[it] means largely adapting to a landscape where traditional human-focused security boundaries are being bypassed by automated technologies.”

For IT managers, said Arnold, “this might entail incorporating defensive AI, the use of behavior-based analytics, using ‘circuit breakers’ when there is heavy use of API or MCPs, updating personnel training, and hardening identity verification, especially for any remote hiring.” 

Distinction between AI-assisted and AI-enabled activity is ‘central’

Sanchit Vir Gogia, chief analyst at Greyhound Research, said that the RUSI report matters “because it names the right structural shift. AI is not creating sanctions evasion from thin air, it is compressing and scaling methods that already work.”

He pointed out that none of the sanction-evading techniques such as fraudulent documents, synthetic identities, shell companies, hidden beneficial ownership, crypto laundering, and others are new. “What changes is the speed, quality, volume and coordination with which these methods can now be assembled,” he said.

According to Gogia, “the distinction between AI-assisted and AI-enabled activity is central. AI-assisted evasion uses AI for discrete tasks: writing a better email, producing a cleaner document, generating a stronger false profile, translating a pitch, summarizing regulations or preparing a plausible job application. AI-enabled evasion is more serious.”

A ‘structural asymmetry’

This tactic, he said, “begins to coordinate the system itself. It links identity, documents, ownership structures, payment routes, cloud access, crypto wallets, API calls and timing. The difference is not whether AI helps someone fake a document. The difference is whether AI begins to orchestrate the deception.”

That is why the report’s findings should worry enterprise leaders, he noted: “Many organizations still assume the bad actor is mostly human, mostly linear and mostly slow. That assumption is expiring. AI lets adversaries run more attempts, with fewer errors, across more channels, in more languages, with better paperwork and greater patience than most enterprise review processes can absorb. This is not a tale of genius criminals discovering magic. It is the story of ordinary controls meeting industrialized plausibility.”

The evidence today, he pointed out, is strongest around tactics such as identity fraud, document fraud, synthetic personas, remote-worker deception, phishing, social engineering, crypto obfuscation and workflow abuse. “Fully autonomous evasion networks sit on the horizon,” he said. “They are serious, but they are not yet the everyday baseline.”

This distinction matters, said Gogia: “If enterprises obsess over cinematic autonomous agent scenarios while leaving remote hiring, vendor onboarding, payment approvals, and document review full of holes, they will lose in the most prosaic way imaginable.”

The report, he said, also gets the “asymmetry” right. “Offensive actors can learn across the ecosystem,” he said. “They can scrape open information, reuse leaked records, study enforcement patterns, test onboarding forms, inspect public procurement data, watch court filings, probe compliance thresholds and [use the information to] refine their behavior.”

Defenders, by contrast, are hemmed in by privacy rules, fragmented data, explainability requirements, jurisdictional boundaries, conservative operating models and siloed technology estates. “Offensive AI learns broadly,” he said. “Defensive AI often learns from fragments. That is the structural asymmetry.”

He explained that the regulatory landscape also amplifies the problem, in that regulatory bodies “still speak in separate dialects. [For example] the EU AI Act pushes organizations toward stronger obligations for high-risk AI. NIST-style frameworks push risk management, transparency, and governance.”

A trust architecture problem

Financial Action Task Force (FATF) expectations push national risk assessment and counter-proliferation controls, he noted, while banking regulators focus on model risk, accountability and operational resilience. “None of these streams is irrelevant. The trouble is that criminals do not organize themselves around regulatory workstreams. They organize around outcomes.”

What that means, said Gogia, “is that enterprise cannot wait for a clean global rulebook. It will not arrive in time. CIOs, CISOs, compliance officers and boards need a working governance model now. They need privacy-preserving analytics, controlled data environments, audit trails, legal safeguards and clear model-risk accountability.”

He said that enterprise IT managers should treat the situation as a trust architecture problem rather than a narrow sanctions-screening problem. “The uncomfortable truth is that AI is not simply helping bad actors write better phishing emails or forge tidier documents,” he noted. “It is helping them manufacture legitimacy across a chain of enterprise workflows.”

Likely outcome an ‘AI arms race’

Report author Arnold also noted that there are signs that cyber criminals have discovered new AI technologies and abilities that legitimate enterprises could adopt for legitimate applications.

History, he said, “is replete with [criminals] developing novel solutions to tough problems, [which are] later adopted by law enforcement. Much of our anti-financial crime policy is effectively a response to bad actors exploiting systems or using technology in novel ways to perpetrate crimes. In this scenario, I think an ‘AI arms race’ between enforcement authorities and bad actors is the most likely outcome.”

Gogia added, “the baddies are not teaching enterprises how to invent AI. They are teaching enterprises where trust is leaking. That is the lesson worth taking seriously.”

This article originally appeared on CIO.com.