AMD executives took to the stage at its Advancing AI 2026 event in San Francisco today to detail the company’s next generation of AI infrastructure solutions, from Instinct MI455X AI accelerator GPUs and 6th Gen EPYC “Venice” CPUs, to Pensando networking, ROCm.AI software and its Helios rack-scale platform that ties it all together.

AMD has been working towards rack-scale AI system solutions for years. Its ZT Systems acquisition last year added valuable engineering talent and intellectual property that is now finally bearing the real fruits. Its Helios AI platform is a major platform evolution for AMD, with shipments scheduled to begin in the second half of this year (which is here and now).

The announcements at Advancing AI show how the company has engineered its AI platform solutions for large reasoning models, sustained inference and agentic workflows. These workloads pressure memory capacity, data movement, networking and CPU orchestration. AMD’s approach is to keep as much data close to the compute engines as possible and move it more efficiently throughout the system, but there’s deeper nuance here that’s obvious versus AMD’s chief rival, NVIDIA.  

AMD’s MI455X targets the AI memory wall

The Instinct MI455X GPU is the compute engine that fuels the Helios rack, and the first GPU based on AMD’s new CDNA 5 architecture. Built with a modular mix of 2nm and 3nm chiplets, it carries 432GB of HBM4 and 23.3TB/s of peak memory bandwidth.

Compared to AMD’s current MI355X, the MI455X offers 1.5 times the memory capacity, up to 2.9 times the peak memory bandwidth and up to four times the peak matrix performance with MXFP4 and MXFP8 data types, which are lower-precision numerical formats designed to accelerate AI processing while reducing memory demands. With MXFP6 (6-bit floating point), performance is rated at up to twice that of MI355X.

AMD also shared some actual, measured internal results using production silicon. The company claims MI455X delivers 3.8 times higher FP8 decode performance, 3.5 times more measured FP4 compute performance and between 2.5 and 3.5 times more networking bandwidth than MI355X, depending on the transfer path tested. Those figures provide more context than just numerical specifications, though they remain AMD-provided comparisons that will need independent validation.

AMD

The architectural choices behind the numbers are important. Reasoning models and long context windows require sizeable KV caches for maintaining AI attention states, while mixture-of-experts models frequently move large amounts of data across accelerators. MI455X should let more model data, activation states and cache remain local. New dedicated IP in hardware can transfer data while the GPU continues processing, and expanded cache and multicast capabilities are designed to reduce redundant data movement to further improve efficiency.

The aforementioned lower-precision formats can also raise throughput and reduce memory use, but model developers still have to determine where they can be applied without unacceptable accuracy loss.

AMD’s Helios rack takes aim at Vera Rubin

Dave Altavilla

Helios is AMD’s primary rack-scale competitor to NVIDIA’s Vera Rubin platform. Each liquid-cooled rack combines 72 MI455X GPUs, 18 single-socket Venice host CPUs and Pensando networking technologies.

In its most complete, premium configuration, AMD rates Helios for 2.9 exaflops of low-precision AI compute, with 31TB of aggregate HBM4 capacity, 1.7PB/s of memory bandwidth, 260TB/s of bidirectional scale-up bandwidth and 43TB/s of scale-out bandwidth.

These are formidable figures, but they are technical specifications rather than actual application benchmarks. The more consequential development is AMD’s move from collections of eight-GPU servers to a 72-GPU shared-memory domain. Models too large for one node can operate across the rack without treating every exchange as a scale-out networking transaction, which benefits large-model inference as well as training.

AMD uses UALink over Ethernet, or UALoE, for an open standard scale-up fabric. Each MI455X provides 3.6TB/s of bidirectional scale-up bandwidth, while the complete rack delivers all-to-all connectivity through a single switch layer. AMD also claims six times more scale-out bandwidth per GPU than MI355X when MI455X is configured with three Pensando Vulcano 800 AI NICs.

While open standards give cloud providers more control over suppliers and system design, AMD and its partners now have to prove those components can deliver the predictable performance, reliability and deployment experience customers expect from a tightly controlled, more vertically integrated platform.

Finally, AMD designed Helios with automatic rerouting around failed links, virtual rack partitions, tray-level serviceability and rack-wide power, cooling and health monitoring. Major hyperscalers and potentially large-scale enterprise customers will likely key in on these capabilities, which can affect the availability, total cost and consistency of the AI services they consume.

Kind of like cowbell, AMD Venice gives agentic AI more CPU

AMD

AMD’s agentic CPU messaging regarding its upcoming Venice-based EPYC processors is mostly marketing speak, but the underlying requirement is very real. An AI agent can invoke retrieval, databases, security checks, code execution and other tools before a GPU generates a response. Running many agents concurrently increases the amount of conventional compute requirements surrounding the accelerators.

Venice scales to 256 Zen 6 cores with support for 512 threads, 16 memory channels, up to 1GB of L3 cache per socket, along with PCIe 6.0 and CXL 3.1 connectivity. AMD is also offering several Venice configurations for other applications, including general-purpose servers, high-frequency workloads, GPU hosts and high-density CPU sandbox systems used to execute agent tools.

Treating the CPU solely as a GPU host understates its role. Gateways, tokenization, vector search, databases and short-lived code execution stress different mixes of per-core performance, thread count, memory bandwidth and I/O. Specifically, AMD’s internal testing shows Venice significantly outperforming its current EPYC 9965 Turin CPU across five parts of the agentic AI pipeline, including gateway processing, context assembly, vector search, enterprise applications and short-lived tool execution. Individual gains vary by workload, but AMD details the overall generational improvement at up to a 1.7 times lift. As with the MI455X figures though, these comparisons come from AMD and will require independent validation.

Pensando networking and ROCm software advance

Keeping GPUs fed with data and coordinating traffic across racks directly affects utilization and operating costs. In fact, GPU utilization is a pretty sad state of affairs currently for some of the major frontier model providers.

As such, Pensando networking has become central to AMD’s roadmap. Helios can connect each MI455X to as many as three 800Gbps Vulcano AI NICs, while Salina DPUs handle front-end networking and infrastructure services.

On the software side, which is an equally critical component, AMD also introduced ROCm.AI, an AI-assisted development layer due to arrive in August. It includes reusable skills for coding agents, simplified management and Hyperloom, which can profile workloads, tune serving configurations, modify kernels and validate results.

These tools address two persistent AMD challenges: developer efficiency and ease of use, and software tuning. Automated optimization still has to produce repeatable gains without creating hard-to-maintain code, however. And while ROCm has progressed significantly over the last few years, NVIDIA’s CUDA retains an advantage in maturity, tooling and developer familiarity.

Customer commitments underscore rack-scale confidence

AMD now has commitments that give its MI450 generation and Helios considerably more weight. Meta and OpenAI have announced multi-generation agreements composed of up to 6GW of AMD compute capacity, with initial 1GW deployments planned for the second half of 2026.

Oracle plans a 50,000-GPU public cloud cluster beginning in the third quarter, while Microsoft will deploy Helios for Azure AI inference. Finally, just before the AMD event, Anthropic announced a strategic partnership for up to 2 Gigawatts of AMD-fueled AI compute, with its first gigawatt expected online in the first half of 2027.

Commitments of this scale reflect confidence in more than just MI455X performance. These customers are evaluating the complete architecture, including Venice CPUs, Pensando networking, ROCm software, rack integration, serviceability and AMD’s ability to deliver and execute across multiple product generations.

There is some financial alignment behind the agreements as well. AMD issued OpenAI performance-based warrants and committed to investing up to $5 billion in Anthropic. That context matters when evaluating these deals as market validation, but these planned deployments are substantial nonetheless and put Helios on a much stronger foundation as it begins shipping.

AMD expands its robotics and embedded foundation

AMD also expanded its physical AI portfolio, building on credible traction from its Xilinx-derived Kria adaptive system-on-modules and embedded technologies that are already powering robotics, machine vision and industrial automation applications.

The new Ryzen AI Embedded X100 combines up to 16 Zen 5 CPU cores, integrated Radeon graphics, a second-generation NPU and as much as 128GB of unified LPDDR5X memory shared across its compute engines. To me this looks a lot like a repackaging and optimization of the company’s Strix Halo platform, but with specific optimizations for the embedded space. Regardless, AMD is pairing X100 with the Kria AI Robotics Developer Platform, which includes a System Module or SOM, and a new Robotics Partner Network spanning hardware, software and platform providers.

Samples began shipping in June, with full production expected in the fourth quarter. This broader objective is to give developers a path across AMD x86 CPUs, GPUs, NPUs and FPGAs for real-time autonomous systems, rather than requiring them to assemble those hardware engines and software components independently.

Execution for AMD is now the test

AMD has assembled a credible platform for the burgeoning agentic AI market that’s blowing up currently with no signs of stopping. MI455X addresses memory and data movement, Venice handles dense agentic CPU workloads, Pensando networking connects global system resources, and ROCm.AI addresses software complexity. Finally, Helios assembles these components into a true competitive threat for NVIDIA’s latest Vera Rubin platform.

AMD’s open architecture may appeal to customers seeking supplier choice, but openness must also translate into reliable deployments, competitive total cost and software that does not require a significant rip-up. NVIDIA enters this cycle with a stronger ecosystem and far more rack-scale deployment experience. The true test will be how easily and reliably customers can integrate, operate and maintain these AMD solutions at scale.

As it stands, AMD now has major customers and a clearly defined architecture with systems engineering expertise behind it. Delivering Helios on schedule and showing that its performance claims translate into a real production workload throughput advantage and total cost of ownership gains will determine how much the competitive gap narrows. And of course, this is in a market that is clamoring for ever-more compute resources with a seemingly insatiable demand for AI services and capacity. That’s an environment for big iron success. Now AMD just has to deliver optimized, turnkey AI platforms. This is far easier said than done, but time will soon tell as deployments take shape this year.

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

Foto: I Believe I Can Fly – shutterstock.com

Enterprise Architecture (EA) Tools unterstützen Unternehmen und Organisationen dabei, mit ihren IT-Strategien die Geschäftsziele optimal zu unterstützen. Sie sorgen ebenfalls dafür, dass Unternehmen ihre Roadmaps für die digitale Transformation geordnet vorantreiben können. EA Tools bieten dafür unter anderem Collaboration-, Reporting-, Testing- und Simulationsfunktionen. Mit deren Hilfe lassen sich Modelle implementieren, die Geschäfts- und IT-Prozesse gezielt verbessern.

Um die beste Lösung für Ihr Unternehmen zu finden, sollten Sie zuerst prüfen, ob sich das jeweilige Tool mit Ihrem Technologie-Stack integrieren lässt. Anschließend gilt es abzuwägen, ob die Informationen, Diagramme und Tabellen, die die Software zur Verfügung stellt, für das Unternehmen auch einen echten Nutzwert haben.

Empfehlenswerte Enterprise-Architecture-Tools

Nachfolgend finden Sie einen Überblick über die wichtigsten Enterprise-Architecture-Tools – in alphabetischer Reihenfolge. Sie stellen einen Mix aus Visualisierungs-, Collaboration- und Project-Management-Funktionen bereit und unterstützen eine Vielzahl von Enterprise Architecture Frameworks.

Ardoq

Nachdem zuerst über einfache Formulare Informationen von Usern, Entwicklern und sonstigen Stakeholdern im Unternehmen eingesammelt wurden, lässt sich mithilfe von Ardoq ein digitaler Zwilling der gesamten Organisation erstellen. Der Ansatz setzt also darauf, die Menschen, die in ihren Rollen mit den verschiedensten Systemen arbeiten, realistisch in ihrer Arbeitswelt abzubilden.

Jede Mitarbeiterin und jeder Mitarbeiter im Unternehmen kann später von den Netzwerkvisualisierungen und Datenfluss-Diagrammen profitieren, um seine eigene Rolle optimal zu unterstützen und den Arbeitsplatz immer wieder anzupassen und zu modernisieren. Das Tool lässt sich mit den wichtigsten Cloud-Plattformen integrieren. Es bietet eine API, die individuelle Anpassungen in allen wichtigen Programmiersprachen (Python, C#, Java, etc.) ermöglicht.

Wichtigste Use Cases:

• “Architektonischen Stress” bei Lastspitzen simulieren, falls größere Veränderungen bevorstehen;

• Verstehen, wie verändertes Nutzerverhalten neue Anforderungen generiert;

• Application Portfolio Management, um besser strategisch zu planen.

Atoll Group SAMU

Das EA-Tool SAMU macht die Enterprise Architecture sichtbar, indem es tiefe Verknüpfungen zwischen On-Premises-Systemen, dem Cloud-Layer und Tools für das Business Process Management aufzeigt. Das Tool der Atoll Group bietet vielfältige Integrationsmöglichkeiten, zum Beispiel mit Monitoring-Tools (etwa Tivoli, ServiceNow), Configuration-Management-Datenbanken (zum Beispiel CA, BMC) oder Service-Organisations-Tools (BMC, HPE). Alle Informationen fließen in ein zentrales Datenmodell ein, das um den zusätzlichen Input der Stakeholder weiter angereichert wird.

Wichtigste Use Cases:

• Enterprise-Architektur visualisieren;

• strategische Planungsprozesse und Architektur-Reviews mit Informationen unterfüttern;

• mithilfe einer visuellen Verständnisgrundlage die Kommunikation verbessern.

Avolution Abacus

Dieses Tool erfasst die Breite und den Umfang der Unternehmensarchitektur mit Hilfe eines auf Diagrammen basierenden Dashboards. Die Integration mit gängigen Tools wie SharePoint, Excel, Visio, Google Sheets, Technopedia oder ServiceNow vereinfacht die Nutzung. Abacus wurde inzwischen auch um einen Machine-Learning-Layer ergänzt, der es Anwendern ermöglicht, ein Modell zu trainieren, das ihnen beispielsweise hilft zu erkennen, wer im Unternehmen für welches System verantwortlich ist.

Wichtigste Use Cases:

• die IT für das gesamte Unternehmen “öffnen”, um ein allgemeines Verständnis der Datenflüsse zu erzeugen;

• umfassendes Enterprise Modeling, um eine Roadmap für künftige Entwicklungen zu erstellen;

• Business-Metriken tracken, die mit der Unternehmens-Performance zusammenhängen.

BOC Group ADOIT

ADOIT soll Teams dabei unterstützen, Ressourcen zu verwalten, Bedarfe vorherzusagen und Assets zu tracken. Dazu mappt das Tool jedes System oder Softwarepaket mit einem Objekt. Die Datenflüsse zwischen den Systemen werden in Beziehungen umgewandelt, die von diesen Objekten mithilfe eines anpassbaren Metamodells erfasst werden. Geschäftsprozesse können auf ähnliche Weise über ein gut integriertes Begleitprodukt namens ADONIS modelliert werden. ADOIT ist Web-basiert und lässt sich auch mit Tools wie Atlassian Confluence integrieren, um die Datenerfassung und -entwicklung zu beschleunigen.

Wichtigste Use Cases:

• ein unternehmensweites Modell erstellen, das bei sämtlichen Teammitgliedern ein Verständnis über den Stack schafft – und wie man diesen verbessern kann;

• vollständiger Zugriff auf EA-Daten über eine Mobile-Anwendung;

• bei Fusionen und Übernahmen den Tech-Bereich durch genaues Asset-Mapping orchestrieren.

Bizzdesign Hopex

Nach der Übernahme von Mega International zählt die Hopex-Plattform zum Portfolio von Bizzdesign. Sie soll dabei unterstützen, Unternehmensanwendungen zu modellieren und dabei ein Verständnis der von ihnen unterstützten Geschäfts-Workflows schaffen. Dabei liegt ein Schwerpunkt auf den Bereichen Data Governance und Risikomanagement. Hopex basiert auf Microsoft Azure und stützt sich auf eine Reihe offener Standards wie GraphQL und REST Queries, um Informationen aus Komponentensystemen zu sammeln. Das Reporting ist mit den Office-Tools von Microsoft sowie mit grafischen Lösungen wie Tableau und Qlik integriert.

Wichtigste Use Cases:

• datengestützte Erkenntnisse herbeiführen, um Cloud- und Anwendungsbereitstellung zu steuern;

• akkurate Nutzungsmodelle erstellen, um Architekturanforderungen zu verstehen;

• eine Bedarfsschätzung mit Umfragen und anderen Tools vornehmen, um für die Zukunft zu planen.

Bizzdesign Horizzon

Das Tool dient dazu, Business Workflows und den zugrundeliegenden Tech-Stack zu modellieren. Dazu bietet Horizzon ein Graph-basiertes Modell, das Daten von sämtlichen Stakeholdern einsammelt und diese an eine Analytics-Engine weitergibt. Im Ergebnis entstehen Diagramme, die den aktuellen Systemzustand widerspiegeln. Wichtige Schwerpunkte dieses Tools sind Change Management und Zukunftsplanung: Horizzon ist nicht zuletzt dafür konzipiert worden, die Risiken eines Redesigns zu minimieren. Das Toolset unterstützt die wichtigsten Frameworks ArchiMate, TOGAF und BPMN. Neben Mega hat Bizzdesign im Januar 2025 auch den EA-Geschäftsbereich der Software AG – Alfabet – übernommen.

Wichtigste Use Cases:

• Vorhersage zukünftiger Anforderungen durch Predictive Modeling;

• Orchestrieren von Workflows auf der Basis der technischen und der Business-Architektur;

• Antizipieren von Risiken sowie Security- und Governance-Problemen durch die Modellierung von Datensicherheitsanforderungen.

Capstera

Das Tool von Capstera fokussiert darauf, die Business Architecture selbst abzubilden. Value und Process Maps helfen dabei, die Rollen der verschiedenen Unternehmensbereiche zu definieren und nachzuverfolgen. Dabei können im laufenden Prozess Verknüpfungen mit den zugrundeliegenden Softwarprodukten und Tools hinzugefügt werden.

Wichtigste Use Cases:

• Reports erstellen, die sich erst einmal mit der Business-Architektur selbst beschäftigen;

• Beziehungen zwischen Menschen, Abteilungen und Rollen analysieren;

• die langfristige strategische Planung vorantreiben.

Clausmark Bee360

Teammitglieder, die Clausmarks Flaggschiffprodukt Bee360 (früher Bee4IT) verwenden, wollen eine einfache “Single Source of Truth” über die Workflows im Unternehmen. Ziel ist es, verschiedenen betrieblichen Rollen intelligentere Entscheidungen zu ermöglichen. Das Modul Bee360 FM (Finanzmanagement) bietet etwa die Möglichkeit, Kosten nachzuvollziehen und zuzuordnen. Die Anwender können verschiedene solcher Module miteinander verknüpfen, um EAM, Finanzmanagement, Portfolio Management und Agile Planning nahtlos zu integrieren – bei maximaler Transparenz.

Wichtigste Use Cases:

• C-Suite-Ebene befähigen, Projekte zu managen und Assets zuzuweisen;

• präzise digitale Zwillinge entwickeln, um ein Verständnis über Datenflüsse zu schaffen und künftige Erweiterungen zu planen;

• integrierte Wissensdatenbank aufbauen, um alle digitalen Workflows zu tracken.

EAS

Das Essential-Paket von EAS (Enterprise Architecture Solutions) nahm als Open-Source-Projekt seinen Anfang und hat sich inzwischen zu einer kommerziell verfügbaren Cloud-Lösung weiterentwickelt. Das Tool erstellt ein Metamodell, das die Interaktionen zwischen Systemen und Geschäftsprozessen beschreibt. Ebenfalls enthalten sind Pakete, um gängige Business Workflows wie Datenmanagement oder DSGVO-Compliance zu tracken.

Wichtigste Use Cases:

• den technischen Reifegrad der eigenen Architektur evaluieren;

• Sicherheit und Governance durch besseres Asset Tracking optimieren;

• wachsende Systemkomplexität kontrollieren und managen.

OrbusInfinity

Orbus Software hat Anfang 2025 die Akquisition seines Konkurrenten Capsifi abgeschlossen. Der Anbieter stellt mit OrbusInfinity eine Enterprise-Transformation-Plattform auf KI-Basis zur Verfügung, die schnellere, bessere Entscheidungen, Kosteinesparungen und Risikominimierung verspricht. Architecture-Teams sollen mit Hifle von OrbusInfinity mit einer Vielzahl von Stakeholdern interagieren können, um eine “digitale Blaupause” ihres Unternehmens zu generieren, die eine einheitliche Sicht auf das aktuelle und künftige Geschäft realisieren soll. Diverse Drittanbieter-Tools lassen sich außerdem mit der Plattform integrieren, darunter etwa von Microsoft, Flexera, ManageEngine oder ServiceNow.

Wichtigste Use Cases:

• Stakeholder-Management;

• Enterprise-Landschaften visualisieren;

• Entscheidungsfindung und Datenanalyse automatisieren.

Planview Enterprise One

Planview bietet eine ganze Reihe von Produkten, mit denen Unternehmen Teamwork, Prozesse und die Enterprise Architecture nachvollziehen können. Die Enterprise Tools sind in drei Kategorien unterteilt: strategisches Portfolio-Management, Produktportfolio-Management und Projektportfolio-Management. Im Zusammenspiel entstehen hardware- und Software-übergreifende Layer, die rollenbasierte Perspektiven für Führungskräfte und Teammitglieder eröffnen. Das Toolset integriert mit gängigen Ticket-Tracking-Systemen wie Jira, um Workflow-Analysen und Reports zu erstellen. Inzwischen hat Planview nach einer Übernahme neue Tools in sein Portfolio integriert, die früher unter den Namen Daptiv, Barometer und Projectplace bekannt waren.

Wichtigste Use Cases:

• eine langfristige, strategische Vision für die Architekturentwicklung aufbauen;

• Entwicklungsarbeit auf Projektebene tracken und in eine beliebige Strategie integrieren;

• mit Fokus auf die Customer Experience und die Produktstruktur den Change vorantreiben.

QualiWare Enterprise Architecture

Das Enterprise Architecture Tool von QualiWare ist Teil einer größeren Sammlung von Modellierungswerkzeugen, die darauf abzielt, sämtliche Geschäftsprozesse zu erfassen. Beispielsweise ist es möglich, einen digitalen Zwillinge zu bauen, mit dem sich Customer Journeys nachvollziehen lassen. Qualiware hat diverse KI-Algorithmen integriert, um Dokumentation und Process Discovery zu optimieren.

Wichtigste Use Cases:

• ein kollaboratives Ökosystem für Business Manager aufbauen, das ein Verständnis von der Enterprise Architecture vermittelt;

• architektonische Designelemente erfassen, um ein Wissens-Ökosystem rund um den Stack aufzubauen;

• eine breite Beteiligung in Sachen Dokumentationserstellung und -überprüfung fördern.

Quest Erwin Evolve

Das Erwin Evolve Tool von Quest hat sich von einem Datenmodellierungs-Tool zu einem System für Enterprise-Architecture- und Geschäftsprozess-Modellierung weiterentwickelt. Um die Komplexität moderner, ineinandergreifender Softwaresysteme und der von ihnen gemanagten Geschäftsprozesse zu durchdringen, können Anwender auf benutzerdefinierte Datenstrukturen zurückgreifen. Das Web-Tool erstellt Modelle, rollenbasierte Diagramme und andere Visualisierungen, die in allgemein zugängliche Dashboards einfließen. Zum Paket gehört ein KI-basiertes Modellierungs-Tool, das Whiteboard-Skizzen integrieren kann.

Wichtigste Use Cases:

• einen digitalen Zwilling für die strategische Modellierung der Enterprise Data Architecture erstellen;

• Customer Journeys verstehen;

• Services und Systeme mit Application Portfolio Management tracken.

SAP LeanIX Enterprise Architecture Suite

Die Tool-Sammlung von LeanIX umfasst unter anderem Enterprise Architecture Management und andere Bereiche, die für Aufgaben wie SaaS– und Value-Stream-Management wichtig sind – etwa um Cloud-Deployments und darauf laufende Services zu tracken. Die Daten die dabei über die IT-Infrastruktur gesammelt werden, fließen in ein grafisches Dashboard ein. Das Tool ist eng mit wichtigen Cloud-Workflow-Tools wie Confluence, Jira, Signavio und Lucidchart integriert. Das ist für Teams von Vorteil, die diese Tools bereits nutzen, um ihre Entwicklungsstrategien zu planen und umzusetzen. Seit November 2023 ist LeanIX Teil von SAP.

Wichtigste Use Cases:

• Anwendungsmodernisierung und Cloud-Migration managen;

• Obsoleszenz von Software-Services evaluieren;

• Kosten kontrollieren und managen.

ServiceNow

Die Tool-Sammlung von ServiceNow lässt sich auf verschiedene Architekturtypen herunterbrechen, darunter Assets, DevOps, Security und Service. Die Tools katalogisieren die unterschiedlichen Hardware- und Softwareplattformen, um Workflows und Datenflüsse im Unternehmen abzubilden und zu verstehen. Ausführliche Reportings und detaillierte Dashboards ermöglichen Analysen, auf deren Grundlage Risiken minimiert und die Ausfallsicherheit der Systeme erhöht werden können.

Wichtigste Use Cases:

• Tracken von Assets, Services und Systemen, die das Unternehmen ausmachen;

• Governance-Themen, Risikobegrenzung, IT-Management und Security Operations werden in einer Plattform zusammengeführt;

• durch die Integration von CRM-Tools lassen sich auch kundenorientierte Services managen.

Sparx Systems

Um Teams und Projekte verschiedener Größe und Komplexität zu unterstützen, hat Sparx vier Versionen seines EA-Tools entwickelt. Allen gemeinsam ist eine UML-basierte Modellierung, mit der sich die Komponenten komplexer Systeme tracken lassen. Eine Simulations-Engine ermöglicht “War Gaming” und vermittelt ein Verständnis darüber, wie sich Fehler ausbreiten und kaskadieren können. Sparx stellt zudem eine Vielzahl von vorgefertigten Design Patterns bereit, um Teams bei der Modellierung zu unterstützen.

Wichtigste Use Cases:

• Nachfrage- und Lastveränderungen zur Prognose künftiger Anforderungen simulieren;

• (potenzielle) Probleme durch eine Verbindungs-Matrix im Auge behalten;

• Dokumentation erstellen.

Unicom System Architect

System Architect ist eines der Angebote aus Unicoms Team Blue. Es handelt sich um ein Tool, das ein Metamodell verwendet, um automatisiert so viele Daten wie möglich über die laufenden Systeme zu sammeln – manchmal auch durch ein Reverse Engineering von Datenflüssen. Dieses systemweite Datenmodell kann über benutzerdefinierte Dashboards Teammitgliedern aller Rollen zugänglich gemacht werden. Ein weiteres erwähnenswertes Feature: Die Ressourcenzuweisung lässt sich mit Hilfe von Simulationen optimieren.

Wichtigste Use Cases:

• Was-wäre-wenn-Fragen zum Architekturmodell stellen;

• ein Metamodell von Daten und Systemen aufbauen;

• Migrations- und Transformationspläne erstellen.

ValueBlue BlueDolphin

Dieses EA-Tool sammelt Daten auf dreierlei Art:

1. Es importiert Basisdaten auf der Grundlage standardgesteuerter Automatisierung (ITSM, SAM).

2. Es arbeitet mit den Dateiformaten von Architekten und Systemdesignern – etwa ArchiMate oder BPMN.

3. Es gibt Fragebögen an andere Stakeholder heraus, die auf anpassbaren Vorlagen basieren.

Die aufbereiteten Informationen werden in einer visuellen Umgebung bereitgestellt, die Auskunft über die historische Entwicklung von Systemen gibt.

Wichtigste Use Cases:

• systemweite Daten von internen und externen Stakeholdern automatisiert und formularbasiert erfassen;

• zukunftsorientierte Reportings erzeugen, um den Change zu überwachen und voranzutreiben;

• Kooperation und Zusammenarbeit durch offenes Data Reporting fördern.

(fm)

Dieser Artikel ist im Original bei unserer Schwesterpublikation CIO.com erschienen.

Late in a large enterprise SAP transformation, the strategic governance conversations began to drift. Instead of executive decisions, we found ourselves debating whether the program needed dedicated testing, whether cutover required a full weekend, whether twenty Agile teams really needed coordination support and whether offshore resources were adding value at all.

The questions were not coming from the delivery teams. They were coming from the executive sponsor.

The sponsor had recently been elevated into a senior leadership role and had never sponsored a technology transformation at this scale. The challenge was not authority. The sponsor had every right to ask any question they wanted. The challenge was that strategic governance had quietly turned into a debate about delivery practices, because the sponsor did not yet have the transformation context to focus the conversation anywhere else.

This is not a story about a bad sponsor. The executive in this case was a capable senior leader with strong judgment and authentic intent. They had been placed into a role they had not yet been prepared for, and the pattern that followed was structural, not personal. It is one of the more common patterns I have observed across enterprise transformation programs, and one of the most consistently misdiagnosed.

Most program failures are not execution failures. They are sponsor mismatches.

When governance becomes a debate about delivery practices

When the sponsor does not understand what an enterprise transformation actually requires, governance forums stop functioning as decision bodies and start functioning as practice debates.

You see it in the questions that get asked. Why do we need a dedicated testing phase? Can the Build timeline be compressed? Why does cutover need a full weekend? Why do we need more Scrum Masters across 20 product teams? Can the US team simply work longer hours instead of using offshore resources? On one program, the sponsor suggested shifting the entire project’s working hours to India time, despite roughly 85 percent of the delivery organization being based in the United States.

None of these questions are unreasonable in isolation. Each one targets a real cost or timeline pressure. The problem is what is missing underneath them: an understanding of the operational risks the original choices were designed to mitigate.

When sponsors ask delivery-practice questions without that context, the program leadership team ends up defending the work instead of advancing it. Decision velocity drops. Trust between the program and its sponsor erodes. Senior delivery talent disengages from governance forums where the conversation never reaches the decisions they need made. What looks from the outside like an active sponsor producing engagement is, from inside the program, an active drain on the cycles needed to deliver.

The compounding cost is not unique to any single program. PMI’s research on executive sponsorship consistently identifies sponsor engagement quality, rather than sponsor presence alone, as one of the strongest predictors of project success. The visible symptom is debate. The actual cost is unmade decisions.

Authority is rarely the issue. Literacy is

When transformations stall under a mismatched sponsor, the diagnostic instinct is to question the sponsor’s authority. Are they senior enough? Do they have the cross-functional reach? Can they unblock?

In most of the programs I have led or advised, authority was not the limiting factor. The sponsor in the SAP program above had ample authority. They could unblock any decision the program needed. What had not been developed was the transformation literacy to know which decisions mattered, which were technical noise and which were execution risks that should not be optimized away.

This is what I have come to think of as the literacy problem. Sponsors elevated into transformation roles often have deep functional expertise (finance, operations, business unit leadership) but limited exposure to the distinct functions of PMO, organizational change management, agile delivery, testing and cutover, and how each one reduces a specific category of implementation risk. They are not expected to be SAP configuration experts. But they need enough transformation literacy to recognize which questions actually belong in a steering committee.

Harvard Business Review’s research on effective executive sponsorship has emphasized that sponsorship effectiveness depends as much on judgment as on authority. Judgment is where literacy becomes operational. A sponsor with authority but limited transformation literacy will optimize for speed and cost in ways that consistently underestimate risk. A sponsor with both will make the tradeoffs the program actually needs.

Prosci’s longstanding benchmark studies on change management have ranked active and visible executive sponsorship as the single greatest contributor to change success for two decades. The word that matters in that finding is active. Active sponsorship without transformation literacy can introduce real cost. Not because the sponsor is acting against the program, but because the optimization choices they make are based on incomplete information about what the program is built to protect against.

Shift the conversation from delivery practices to business risk

When the sponsor relationship is already in place and cannot be changed, the program leadership team has one move that consistently works: shift the conversation.

On the SAP program above, we stopped explaining why the testing phase existed. We started explaining the business risk of reducing it. We stopped debating the number of Scrum Masters. We started connecting delivery capacity to coordination across more than twenty Agile teams and the business cost of losing that coordination. We reframed offshore support as a way to maintain delivery momentum around the clock rather than asking the U.S. team to sustain fifteen-hour days.

The shift is from defending delivery practice to explaining business risk. The sponsor does not need to understand why testing takes the time it does. They need to understand what the program is exposed to if testing is compressed. They do not need to know how many Scrum Masters are statistically optimal for twenty Agile teams. They need to know what coordination breaks when the number is wrong.

This reframing accomplishes two things. First, it brings the conversation back to the level at which sponsors actually make decisions: tradeoffs between business outcomes and business risks. Second, it builds transformation literacy in the sponsor over time, almost as a byproduct. By the third or fourth iteration of business-risk-framed conversations, the sponsor begins to ask the right questions on their own.

In practice, this happens through small but deliberate moves. When the sponsor asks why a phase needs the time it takes, the program lead names two or three things that could go wrong if the time is cut and what each would cost the business. When the sponsor asks why a role is needed, the program lead names the work that would not get done without it. Every delivery-practice question gets converted into a business-risk answer.

The program leadership team’s job is not to make the sponsor an expert in SAP delivery. It is to provide enough transformation context so that executive decisions reflect both business priorities and implementation realities.

There are a few phrases I have used with executive sponsors over the years that capture the underlying issue. The sharpest one:

If the decision has to go above the sponsor, they are not the sponsor.

Sponsorship is defined by what the sponsor can decide without asking someone else. That is the test. Anything else is the appearance of sponsorship, not the substance.

For CIOs supporting enterprise transformation, the implication is direct. Sponsor selection, or sponsor preparation when selection is not an option, is not a hierarchy question. It is a transformation capability question. The same execution discipline that goes into defining decision rights, structuring governance and protecting delivery momentum should apply, with equal rigor, to assessing sponsor fit and building sponsor literacy before the program begins.

A sponsor does not need to be the technical expert. They do need to know when to trust the people who are.

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

What is a business analyst?

Business analysts (BAs) are responsible for bridging the gap between IT and the business using data analytics to assess processes, determine requirements, and deliver data-driven recommendations and reports to executives and stakeholders.

BAs engage with business leaders and users to understand how data-driven changes to process, products, services, software, and hardware can improve efficiencies and add value. They must articulate those ideas but also balance them against what’s technologically feasible and financially and functionally reasonable. Depending on the role, a business analyst might work with data sets to improve products, hardware, tools, software, services, or process.

The International Institute of Business Analysis (IIBA), a nonprofit professional association, considers the business analyst an agent of change, and says that business analysis is a disciplined approach to introduce and manage change to organizations, whether they’re for-profit businesses, governments, or nonprofits.

Impact of AI on business analyst role

As AI becomes commonplace in the tech industry, business analysts are embracing it as a tool to automate repetitive work in the role. AI tools can be used for workflow and diagramming, process mapping, data analysis, and to automate meeting minutes and transcribe meetings where requirements are established, all designed to speed up the process of analyzing data, creating visuals, and transcribing and writing user stories and acceptance criteria.

AI tools can also help identify patterns, insights, and unique data points that might go unnoticed by humans, and allow a faster time to generate insights for organizations.

Of course, as with all AI tools, they still require humans to oversee prompts, scripting, and evaluate AI outputs to ensure they’re accurate and valid. While they can’t replace the work of BAs, AI can help them spend more time on thoughtful analysis and decision making, rather than mundane tasks such as gathering and summarizing data, and querying.

Business analyst job description

BAs are responsible for creating new models that support business decisions by working closely with finance and IT teams to establish initiatives and strategies aimed at improving revenue and optimizing costs. They need a strong understanding of regulatory and reporting requirements, and have plenty of experience in forecasting, budgeting, and financial analysis combined with knowing KPIs, according to Robert Half Technology.

According to Robert Half, a BA’s job description typically includes budgeting and forecasting, planning and monitoring, variance analysis, pricing, reporting, and creating a detailed business analysis in an effort to outline problems, opportunities, and solutions for a business. It also says BAs should be able to define business requirements and report them back to stakeholders.

Since BAs are tasked with prioritizing technical and functional requirements, identifying what clients want, and determining what’s feasible to deliver, the role requires a deep understanding of systems, how they function, who’ll need to be involved, and the necessary steps to get everyone on board.  

The role is constantly evolving, especially as companies rely more on data to advise business operations. Every company has different issues that a business analyst can address, whether it’s dealing with outdated legacy systems, changing technologies, broken processes, poor client or customer satisfaction, or large, siloed organizations.

Business analyst skills

The BA position requires both hard and soft skills, as they need to know how to pull, analyze, and report data trends, share that information with others, and apply it to business goals and needs.

Not all BAs need a background in IT if they have a general understanding of how systems, products, and tools work. Alternatively, some have strong IT backgrounds and less experience in business, but are interested in shifting away from IT into this hybrid role, which often acts as a communicator between the business and IT sides of the organization. So having extensive experience in either area can be beneficial for BAs.

According to the IIBA, some of the most important skills and experience for a business analyst are:

• Oral and written communication skills
• Interpersonal, organizational, facilitation, and consultative skills
• Analytical thinking and problem solving
• Being detail-oriented and able to deliver a high level of accuracy
• Knowledge of business structure
• Stakeholder and cost-benefit analysis
• Processes modeling
• Understanding networks, databases, and other technologies

For a more in-depth look at what it takes to succeed as a business analyst, click here.

Business analyst salary

The average annual salary for an IT business analyst is $80,692, according to data from PayScale. The highest paid BAs are in New York, where the average salary is 14% higher than the national average. Dallas, Texas, is second, with reported salaries 6.4% higher than the national average, closely followed by Washington, D.C., where salaries are 6.3% higher than the national average.

Some skills are in higher demand than others, with the potential to boost salary. According to Payscale, these are associated with higher BA salaries. These skills, and the amount they can boost your salary, include:

For tips on boosting your salary, click here.

Business analyst certifications

Although business analysis is a relatively new discipline in IT, a handful of organizations already offer certifications to help boost your résumé and prove your merit as an analyst. Organizations such as the IIBA, IQBBA, IREB, and PMI each offer their own tailored certifications for business analysis. These include:

• IIBA Entry Certificate in Business Analysis (ECBA)
• IIBA Certification of Competency in Business Analysis (CCBA)
• IIBA Certified Business Analysis Professional (CBAP)
• IIBA Agile Analysis Certification (AAC)
• IQBBA Certified Foundation Level Business Analyst (CFLBA)
• IREB Certified Professional for Requirements Engineering (CPRE)
• PMI Professional in Business Analysis (PBA)
• Certified Analytics Professional (CAP)

For more information about how to earn one of these certifications — and how much they cost — click here.

Business analytics tools and software

BAs typically rely on software such as Microsoft’s Excel, PowerPoint, and Access, as well as SQL, Google Analytics, and Tableau. These tools help BAs collect and sort data, create graphs, write documents, and design visualizations to explain findings. You won’t necessarily need programming or database skills for a BA position, but if you already have these skills, they won’t hurt. The type of software and tools you’ll need to use, however, will depend on your job title and what the organization requires.

What is a business analyst?

Business analysts (BAs) are responsible for bridging the gap between IT and the business using data analytics to assess processes, determine requirements, and deliver data-driven recommendations and reports to executives and stakeholders.

BAs engage with business leaders and users to understand how data-driven changes to process, products, services, software, and hardware can improve efficiencies and add value. They must articulate those ideas but also balance them against what’s technologically feasible and financially and functionally reasonable. Depending on the role, a business analyst might work with data sets to improve products, hardware, tools, software, services, or process.

The International Institute of Business Analysis (IIBA), a nonprofit professional association, considers the business analyst an agent of change, and says that business analysis is a disciplined approach to introduce and manage change to organizations, whether they’re for-profit businesses, governments, or nonprofits.

Impact of AI on business analyst role

As AI becomes commonplace in the tech industry, business analysts are embracing it as a tool to automate repetitive work in the role. AI tools can be used for workflow and diagramming, process mapping, data analysis, and to automate meeting minutes and transcribe meetings where requirements are established, all designed to speed up the process of analyzing data, creating visuals, and transcribing and writing user stories and acceptance criteria.

AI tools can also help identify patterns, insights, and unique data points that might go unnoticed by humans, and allow a faster time to generate insights for organizations.

Of course, as with all AI tools, they still require humans to oversee prompts, scripting, and evaluate AI outputs to ensure they’re accurate and valid. While they can’t replace the work of BAs, AI can help them spend more time on thoughtful analysis and decision making, rather than mundane tasks such as gathering and summarizing data, and querying.

Business analyst job description

BAs are responsible for creating new models that support business decisions by working closely with finance and IT teams to establish initiatives and strategies aimed at improving revenue and optimizing costs. They need a strong understanding of regulatory and reporting requirements, and have plenty of experience in forecasting, budgeting, and financial analysis combined with knowing KPIs, according to Robert Half Technology.

According to Robert Half, a BA’s job description typically includes budgeting and forecasting, planning and monitoring, variance analysis, pricing, reporting, and creating a detailed business analysis in an effort to outline problems, opportunities, and solutions for a business. It also says BAs should be able to define business requirements and report them back to stakeholders.

Since BAs are tasked with prioritizing technical and functional requirements, identifying what clients want, and determining what’s feasible to deliver, the role requires a deep understanding of systems, how they function, who’ll need to be involved, and the necessary steps to get everyone on board.  

The role is constantly evolving, especially as companies rely more on data to advise business operations. Every company has different issues that a business analyst can address, whether it’s dealing with outdated legacy systems, changing technologies, broken processes, poor client or customer satisfaction, or large, siloed organizations.

Business analyst skills

The BA position requires both hard and soft skills, as they need to know how to pull, analyze, and report data trends, share that information with others, and apply it to business goals and needs.

Not all BAs need a background in IT if they have a general understanding of how systems, products, and tools work. Alternatively, some have strong IT backgrounds and less experience in business, but are interested in shifting away from IT into this hybrid role, which often acts as a communicator between the business and IT sides of the organization. So having extensive experience in either area can be beneficial for BAs.

According to the IIBA, some of the most important skills and experience for a business analyst are:

• Oral and written communication skills
• Interpersonal, organizational, facilitation, and consultative skills
• Analytical thinking and problem solving
• Being detail-oriented and able to deliver a high level of accuracy
• Knowledge of business structure
• Stakeholder and cost-benefit analysis
• Processes modeling
• Understanding networks, databases, and other technologies

For a more in-depth look at what it takes to succeed as a business analyst, click here.

Business analyst salary

The average annual salary for an IT business analyst is $80,692, according to data from PayScale. The highest paid BAs are in New York, where the average salary is 14% higher than the national average. Dallas, Texas, is second, with reported salaries 6.4% higher than the national average, closely followed by Washington, D.C., where salaries are 6.3% higher than the national average.

Some skills are in higher demand than others, with the potential to boost salary. According to Payscale, these are associated with higher BA salaries. These skills, and the amount they can boost your salary, include:

For tips on boosting your salary, click here.

Business analyst certifications

Although business analysis is a relatively new discipline in IT, a handful of organizations already offer certifications to help boost your résumé and prove your merit as an analyst. Organizations such as the IIBA, IQBBA, IREB, and PMI each offer their own tailored certifications for business analysis. These include:

• IIBA Entry Certificate in Business Analysis (ECBA)
• IIBA Certification of Competency in Business Analysis (CCBA)
• IIBA Certified Business Analysis Professional (CBAP)
• IIBA Agile Analysis Certification (AAC)
• IQBBA Certified Foundation Level Business Analyst (CFLBA)
• IREB Certified Professional for Requirements Engineering (CPRE)
• PMI Professional in Business Analysis (PBA)
• Certified Analytics Professional (CAP)

For more information about how to earn one of these certifications — and how much they cost — click here.

Business analytics tools and software

BAs typically rely on software such as Microsoft’s Excel, PowerPoint, and Access, as well as SQL, Google Analytics, and Tableau. These tools help BAs collect and sort data, create graphs, write documents, and design visualizations to explain findings. You won’t necessarily need programming or database skills for a BA position, but if you already have these skills, they won’t hurt. The type of software and tools you’ll need to use, however, will depend on your job title and what the organization requires.

EF Core is Microsoft’s flagship ORM (object-relational mapper), the software layer that allows .NET developers to work with relational databases. The DbContext class is the core component of the EF Core framework for managing database operations. However, the DbContext class in EF Core is not thread-safe. Hence, if you share DbContext instances between multiple threads, you will often encounter data corruption issues and the InvalidOperationException.

In this article, we’ll learn how we can execute queries in parallel in EF Core by handling thread-safety issues to avoid concurrency errors. To work with the code examples provided in this article, you should have Visual Studio 2026 installed in your system. You can download Visual Studio 2026 here.

Executing EF Core queries in parallel – the problem

When working in today’s data-driven applications, you will often need to fetch data from multiple unrelated datasets. In applications that use concurrency, thread-safety is critical to guaranteeing correct execution, avoiding data corruption and race conditions, and ensuring data consistency. Let’s understand this with an example.

Let’s say we want to populate a dashboard that displays all recently processed orders, metrics, logs, and traces, as well as your application’s performance metadata. We might write the following code.

public class Dashboard
{
    public List Orders { get; set; } = new();
    public Metrics Metrics { get; set; } = new();
    public List Logs { get; set; } = new();
    public List Traces { get; set; } = new();
}
public static async Task LoadDashboardAsync(ProductService productService)
{
    Task<List>    ordersTask  = productService.GetProcessedOrdersAsync();
    Task        metricsTask = productService.GetMetricsAsync();
    Task<List> logsTask    = productService.GetRecentLogsAsync();
    Task<List>    tracesTask  = productService.GetTracesAsync();
    await Task.WhenAll(ordersTask, metricsTask, logsTask, tracesTask);
    return new Dashboard
    {
        Orders  = await ordersTask,
        Metrics = await metricsTask,
        Logs    = await logsTask,
        Traces  = await tracesTask
    };
}

In the preceding code snippet, there are four read operations that are executed by four different Task instances. Our objective is to ensure that the database round trips run in parallel instead of in sequence. We can accomplish this by usingTask.WhenAll, which starts the four tasks, waits for every task to finish, then returns the data wrapped inside a new Dashboard instance.

If we executed these queries sequentially, the user would have to wait until each query completed its execution in turn—for a total wait time equal to the sum of the times for all four queries. However, by running these queries in parallel, we reduce the wait time considerably. The user will need to wait only as long as it takes for the slowest of the four queries to complete its execution.

However, there is a danger with the above approach. If you run multiple operations on the same DbContext instance, you will see an InvalidOperationException with the following message:

A second operation started in this context before the previous operation was completed. This is usually caused by multiple threads using the same DbContext instance; instance members are not guaranteed to be thread-safe.

Databases such as SQL Server, PostgreSQL, and Oracle Database follow a request-response communication model at the connection level: a single connection can process only one command at a time. Hence, you cannot run multiple queries concurrently using the connection. If you await several operations using the same connection, EF Core detects the overlapping use of a non-thread-safe context and throws an InvalidOperationException. To run queries in parallel, you must give each task its own connection or context.

Why DbContext isn’t thread-safe – and how to work around it

The DbContext class in EF Core is designed to manage a single unit of work. To be more precise, EF Core does not provide support for running multiple operations on the same DbContext instance. This design approach creates inherent challenges when you use the same DbContext instance across multiple threads. If DbContext were thread-safe, extensive locking would be required, which would degrade data access performance.

This stateful design of DbContext makes it unsuitable for concurrent access patterns that involve loading, modifying, or tracking different sets of data simultaneously, because it needs to maintain the internal representation of database state.

The change tracker is one of the most important components of DbContext in EF Core. It monitors all entities loaded into memory and detects any changes made to them after they have been loaded. It keeps track of the original, current, and changed values of the entities, thereby enabling the EF Core runtime to know the current state of these entities when you call the SaveChanges() method on the DbContext instance.

To implement thread-safety when working with DbContext, we must write our code to ensure that each concurrent operation gets its own copy of a short-lived instance. Now, we could accomplish this by wrapping a shared DbContext instance inside a thread-safe block using the lock keyword, so that all calls to the database take place using one and only one thread at a time. This approach is illustrated in the code snippet below.

using Microsoft.EntityFrameworkCore;
public class Product
{
    public int Id { get; set; }
    public string Name { get; set; } = string.Empty;
    public decimal Price { get; set; }
    public int Quantity { get; set; }
}
public class AppDbContext : DbContext
{
    public AppDbContext(DbContextOptions options) : base(options) { }
    public DbSet Products => Set();
}

However, while the above approach gives us the thread-safety we need, it can degrade data access performance considerably. A better approach is to use IDbContextFactory , which creates fresh DbContext instances on demand. Calling its CreateDbContext() method is cheap and produces a fresh, isolated context every time.

The following code snippet shows how you can register an instance of type IDbContextFactory as a singleton. You can safely call this code from any thread.

builder.Services.AddDbContextFactory(options =>
    options.UseSqlServer(
        builder.Configuration.GetConnectionString("Default")));

Executing EF Core queries in parallel – the solution

Now let’s see how we can put IDbContextFactory to work. The following code illustrates a class named ProductService that uses a factory to create DbContext instances for each scope of work.

public class ProductService
{
    private readonly IDbContextFactory _factory;
    public ProductService(IDbContextFactory factory)
        => _factory = factory;
    public async Task GetByIdAsync(int id)
    {
        await using var context = await _factory.CreateDbContextAsync();
        return await context.Products.FindAsync(id);
    }
    public async Task UpdateStockQuantityAsync(int id, int updateQuantity)
    {
        await using var context = await _factory.CreateDbContextAsync();
        var product = await context.Products.FindAsync(id);
        if (product is null) return;
        product.Quantity += updateQuantity;
        await context.SaveChangesAsync();
    }
}

Note that ProductService has two methods, GetByIdAsync and UpdateStockQuantityAsync. An instance of the DbContext class is created locally in each of these methods. Now, suppose you have two threads, T1 and T2, that execute these methods concurrently. That is, thread T1 executes the GetByIdAsync method while thread T2 executes the UpdateStockQuantityAsync method. Because each of these methods is executed in isolation, they will have their own context, connection, and change-tracking information, and there will be no mutable state, so you don’t need to implement thread synchronization in either of these methods.

Consider the following code that executes a read operation and an update operation in two separate tasks.

public static async Task RunMethodsInParallelAsync(ProductService productService)
{
      Task readTask = productService.GetByIdAsync(1);
      Task updateTask = productService.UpdateStockQuantityAsync(3, 5);
      await Task.WhenAll(readTask, updateTask);
      Product? product = await readTask;
 }

The Task.WhenAll method runs the two tasks in parallel and waits until both have finished. The reason this approach is thread-safe, and will not create concurrency errors, is that each of these two methods creates its own DbContext instance internally. Therefore the read operation and the update operation use independent DbContext instances.

Use DbContext pooling to reduce allocation cost

Although creating DbContext instances is not that costly, you should consider using pooled contexts in applications that require high scalability and high performance. The following code snippet shows how you can register a pooled context.

builder.Services.AddPooledDbContextFactory(options =>
    options.UseSqlServer(connectionString));

A call to AddDbContext() will register a DbContext instance as scoped per HTTP request. Each request will run on a different thread and each will have its own context. However, keep in mind that the default scoped registration of the DbContext will not always suffice.

You will need a factory to create instances of DbContext when you’re using a background service, or performing some work inside a particular request, or running some business logic operation over multiple contexts.

Key takeaways

• If you use EF Core in the data access layer of your application, you must implement thread safety measures whenever you run your queries in parallel.
• You cannot execute multiple queries in parallel in EF Core using the same DbContext instance.
• The IDbContextFactory enables you to create a DbContext instance for each thread, thereby enabling you to work with these instances in isolation.
• Although using a DbContext pool involves a small allocation overhead, it becomes a non-issue if you need high throughput.

Late in a large enterprise SAP transformation, the strategic governance conversations began to drift. Instead of executive decisions, we found ourselves debating whether the program needed dedicated testing, whether cutover required a full weekend, whether twenty Agile teams really needed coordination support and whether offshore resources were adding value at all.

The questions were not coming from the delivery teams. They were coming from the executive sponsor.

The sponsor had recently been elevated into a senior leadership role and had never sponsored a technology transformation at this scale. The challenge was not authority. The sponsor had every right to ask any question they wanted. The challenge was that strategic governance had quietly turned into a debate about delivery practices, because the sponsor did not yet have the transformation context to focus the conversation anywhere else.

This is not a story about a bad sponsor. The executive in this case was a capable senior leader with strong judgment and authentic intent. They had been placed into a role they had not yet been prepared for, and the pattern that followed was structural, not personal. It is one of the more common patterns I have observed across enterprise transformation programs, and one of the most consistently misdiagnosed.

Most program failures are not execution failures. They are sponsor mismatches.

When governance becomes a debate about delivery practices

When the sponsor does not understand what an enterprise transformation actually requires, governance forums stop functioning as decision bodies and start functioning as practice debates.

You see it in the questions that get asked. Why do we need a dedicated testing phase? Can the Build timeline be compressed? Why does cutover need a full weekend? Why do we need more Scrum Masters across 20 product teams? Can the US team simply work longer hours instead of using offshore resources? On one program, the sponsor suggested shifting the entire project’s working hours to India time, despite roughly 85 percent of the delivery organization being based in the United States.

None of these questions are unreasonable in isolation. Each one targets a real cost or timeline pressure. The problem is what is missing underneath them: an understanding of the operational risks the original choices were designed to mitigate.

When sponsors ask delivery-practice questions without that context, the program leadership team ends up defending the work instead of advancing it. Decision velocity drops. Trust between the program and its sponsor erodes. Senior delivery talent disengages from governance forums where the conversation never reaches the decisions they need made. What looks from the outside like an active sponsor producing engagement is, from inside the program, an active drain on the cycles needed to deliver.

The compounding cost is not unique to any single program. PMI’s research on executive sponsorship consistently identifies sponsor engagement quality, rather than sponsor presence alone, as one of the strongest predictors of project success. The visible symptom is debate. The actual cost is unmade decisions.

Authority is rarely the issue. Literacy is

When transformations stall under a mismatched sponsor, the diagnostic instinct is to question the sponsor’s authority. Are they senior enough? Do they have the cross-functional reach? Can they unblock?

In most of the programs I have led or advised, authority was not the limiting factor. The sponsor in the SAP program above had ample authority. They could unblock any decision the program needed. What had not been developed was the transformation literacy to know which decisions mattered, which were technical noise and which were execution risks that should not be optimized away.

This is what I have come to think of as the literacy problem. Sponsors elevated into transformation roles often have deep functional expertise (finance, operations, business unit leadership) but limited exposure to the distinct functions of PMO, organizational change management, agile delivery, testing and cutover, and how each one reduces a specific category of implementation risk. They are not expected to be SAP configuration experts. But they need enough transformation literacy to recognize which questions actually belong in a steering committee.

Harvard Business Review’s research on effective executive sponsorship has emphasized that sponsorship effectiveness depends as much on judgment as on authority. Judgment is where literacy becomes operational. A sponsor with authority but limited transformation literacy will optimize for speed and cost in ways that consistently underestimate risk. A sponsor with both will make the tradeoffs the program actually needs.

Prosci’s longstanding benchmark studies on change management have ranked active and visible executive sponsorship as the single greatest contributor to change success for two decades. The word that matters in that finding is active. Active sponsorship without transformation literacy can introduce real cost. Not because the sponsor is acting against the program, but because the optimization choices they make are based on incomplete information about what the program is built to protect against.

Shift the conversation from delivery practices to business risk

When the sponsor relationship is already in place and cannot be changed, the program leadership team has one move that consistently works: shift the conversation.

On the SAP program above, we stopped explaining why the testing phase existed. We started explaining the business risk of reducing it. We stopped debating the number of Scrum Masters. We started connecting delivery capacity to coordination across more than twenty Agile teams and the business cost of losing that coordination. We reframed offshore support as a way to maintain delivery momentum around the clock rather than asking the U.S. team to sustain fifteen-hour days.

The shift is from defending delivery practice to explaining business risk. The sponsor does not need to understand why testing takes the time it does. They need to understand what the program is exposed to if testing is compressed. They do not need to know how many Scrum Masters are statistically optimal for twenty Agile teams. They need to know what coordination breaks when the number is wrong.

This reframing accomplishes two things. First, it brings the conversation back to the level at which sponsors actually make decisions: tradeoffs between business outcomes and business risks. Second, it builds transformation literacy in the sponsor over time, almost as a byproduct. By the third or fourth iteration of business-risk-framed conversations, the sponsor begins to ask the right questions on their own.

In practice, this happens through small but deliberate moves. When the sponsor asks why a phase needs the time it takes, the program lead names two or three things that could go wrong if the time is cut and what each would cost the business. When the sponsor asks why a role is needed, the program lead names the work that would not get done without it. Every delivery-practice question gets converted into a business-risk answer.

The program leadership team’s job is not to make the sponsor an expert in SAP delivery. It is to provide enough transformation context so that executive decisions reflect both business priorities and implementation realities.

There are a few phrases I have used with executive sponsors over the years that capture the underlying issue. The sharpest one:

If the decision has to go above the sponsor, they are not the sponsor.

Sponsorship is defined by what the sponsor can decide without asking someone else. That is the test. Anything else is the appearance of sponsorship, not the substance.

For CIOs supporting enterprise transformation, the implication is direct. Sponsor selection, or sponsor preparation when selection is not an option, is not a hierarchy question. It is a transformation capability question. The same execution discipline that goes into defining decision rights, structuring governance and protecting delivery momentum should apply, with equal rigor, to assessing sponsor fit and building sponsor literacy before the program begins.

A sponsor does not need to be the technical expert. They do need to know when to trust the people who are.

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

Earlier this month, Nokia provided an AI-RAN platform update that brings an AI-native and programmable compute which is projected to double spectral efficiency by 2028. This increases speed, but more importantly, it can allow mobile operators to create some actual monetization beyond connectivity.

With this release, Nokia is introducing what it calls the industry’s first commercial AI-RAN platform, built on its AI‑native anyRAN software and Nvidia’s Aerial AI-RAN stack running on merchant GPU-based accelerated computing. The company is already seeing more than 20% gains in spectral efficiency from AI-driven radio algorithms, with a roadmap to reach 50% by 2027 and more than 100% by 2028, effectively doubling capacity on existing spectrum in dense cells.

Legacy RAN infrastructure enables connectivity but not much beyond that. The AI-RAN makes the network intelligent and extends AI into the physical world, enabling telcos to get more from their infrastructure investments, including providing a path to 6G. The partnership with Nvidia brings CUDA and AI into mobile environments.

For Network World readers, the headline isn’t just that Nokia got to market first with AI‑RAN—it’s that the company is using AI and GPUs to break the historical coupling between radio performance and custom silicon refresh cycles, and to turn the RAN into an application platform.

What AI-RAN actually is

At a technical level, Nokia’s AI‑RAN is a software‑defined baseband architecture that runs Layer 1/Layer 2 RAN functions and AI models on accelerated compute, primarily GPUs, instead of being locked into fixed‑function ASICs. Udayan Mukherjee, Nokia’s CTO for RAN and core, summarized the vision in the analyst briefing: “AI‑RAN is essentially a platform that turns the radio network into a true AI‑native programmable platform… one software detached from the hardware, defining flexible hardware deployment configurations, including part of the AI grid.”

Several pillars stand out:

• AI‑native design: Algorithms move from traditional linear models to increasingly nonlinear techniques (e.g., advanced channel estimation, deep receivers/transmitters, RKHS-based methods), which demand tensor-heavy compute best delivered by GPUs.
• Software-defined RAN: The same anyRAN software stack runs across different hardware configurations—plug‑in cards, standalone AI‑RAN nodes, and COTS/cloud RAN—so innovation comes via software releases rather than baseband card swaps.
• Programmable “D‑apps” layer: Nokia is pushing a new real‑time E3 interface from Layer 1/2 into an application layer for distributed apps (D‑apps) that can tap IQ samples, channel estimation and scheduling data for use cases such as sensing and location services.
• Crucially, this isn’t meant to replace all custom silicon overnight. Mukherjee was explicit: “We are not dropping the purpose‑built product… but we want to also get to merchant silicon, because that’s the future as we want to develop bigger models and AI elements and value‑added services on top of it.” The result is a hybrid era where AI‑accelerated platforms coexist with existing basebands but begin to shoulder the most compute‑intensive workloads.

Why AI-RAN matters for operators

Nokia and its early operator partners are trying to solve three perennial problems: finite spectrum, changing traffic patterns, and the drag of hardware refresh cycles.

First, spectrum constraints. Aji Ed, Nokia’s head of AI‑RAN and cloud RAN, called spectrum “the first constraint everybody has,” noting that operators have paid “huge amount of money” for bands and now need to “get up to the 2x spectrum” in terms of usable capacity. By running more complex AI models for multi‑user MIMO pairing, channel estimation, carrier aggregation and deep receiver/transmitter functions on GPUs, Nokia believes it can unlock those gains where traditional platforms simply run out of compute headroom.

Second, traffic is shifting. Generative AI and distributed inference workloads are driving more uplink-heavy, latency‑sensitive patterns that current RANs weren’t designed for. AI‑RAN’s ability to adapt scheduling, beamforming and resource allocation dynamically via AI models deployed at the baseband is meant to keep up with this shift.

Third, innovation cadence. In Ed’s words, “hardware upgrades can’t keep up with the innovation… we can’t really have a silicon refresh cycle linked with every three‑year cycle.” Nokia’s subscription‑based software model is designed to deliver new AI algorithms, spectral‑efficiency improvements and network optimization features continuously, without requiring “forklift” hardware replacements.

For operators, the message is attractive: comparable TCO and power to existing basebands, “no hardware premium” for GPU adoption, but higher capacity and a path to new services. Nokia told analysts it has reached performance, price and energy efficiency parity between its custom GridShark silicon and GPU-based systems, while moving the baseband roadmap to merchant silicon.

Nokia’s differentiation strategy

Every major RAN vendor is talking about AI‑enhanced radio, but Nokia is drawing a line between incremental gains and what it claims is a platform shift. When asked why its 2x spectral efficiency ambition is so much higher than the ~20% numbers competitors discuss, Ed pointed to the underlying architecture: “We are able to bring much more complex algorithms into this compute infrastructure… all of these require much higher compute, which is exactly what is coming from the accelerated computing.”

Several differentiators emerge:

• Aggressive spectral roadmap: Nokia is targeting 1.5x by 2027 and 2x by 2028, across TDD massive MIMO and FDD scenarios, with a feature roadmap built jointly with Nvidia and other partners.
• Single code base, three deployment paths: The same anyRAN software stack runs on (1) a GPU‑powered AirScale capacity plug‑in card, (2) a high‑capacity standalone AI‑RAN node, and (3) GPU‑based COTS/cloud RAN servers. This lets operators modernize “at their own pace” and mix brownfield evolution with greenfield AI-native deployments.
• Open ecosystem with D‑apps: Nokia is leaning into ORAN compliance (front‑haul, O1/O2) and actively championing the E3 interface and D‑apps concept within ORAN and AI‑RAN alliances, with Bell Labs and at least two external partners already building sensing and location applications on the platform.
• Software subscription tied to value: The commercial model builds on existing software subscriptions but ties pricing more explicitly to delivered value, such as spectral efficiency improvements and new AI services, rather than pure license metrics.

Mukherjee emphasized the openness angle in the briefing: “We see a lot of third‑party applications, whether it’s improving spectral efficiency or location service or sensing, can be developed on this platform… any AI‑powered services from us in Nokia or from ecosystems can be actually developed on top of it.” For operators burned by closed optimization stacks, that’s a notable pivot.

How AI-RAN unlocks new revenue

Most operators will sign off on AI‑RAN if the capacity and TCO story holds, but the more strategic question is monetization beyond connectivity. Nokia’s spokespeople spent considerable time on this in the analyst call, pointing to several classes of services that are difficult or impossible to deliver without AI running in the RAN itself.

Examples include:

• Integrated sensing: Turning the RAN into a distributed sensor grid that can support applications such as 3D mapping, gesture recognition and environmental monitoring, using the same RF infrastructure. Mukherjee noted, “We have at least two to three partners developing sensing applications on top of it… as well as two other companies developing location services.”
• Physical AI and location services: For factories, logistics hubs and smart cities, AI‑RAN can provide high‑precision positioning and real‑time telemetry for robots, drones and autonomous systems by fusing radio data and AI models at the edge.
• Distributed AI infrastructure: Operators exploring “AI‑native cities” can use AI‑RAN nodes and COTS GPU servers as a distributed inference fabric for applications that need tight latency to endpoints—think AR/VR offload, real‑time video analytics or interactive generative AI experiences.
• Premium connectivity tiers: With fine‑grained, AI‑driven control over uplink/downlink scheduling and QoS, operators can create differentiated SLAs for enterprise slices, mission‑critical IoT and AI workloads, charging for guaranteed performance rather than best‑effort connectivity.

Ed framed the opportunity as a continuum: Superior connectivity from 2x spectral efficiency creates “space for new AI workloads and other use cases,” while the D‑apps ecosystem and subscription model provide a mechanism to package and sell those capabilities. In practice, that could look like:

• Industrial sensing-as-a-service, where Nokia and partners supply D‑apps for integrated sensing and positioning, and operators monetize them per site or per device.
• Network‑exposed APIs for inference, location and RF sensing, integrated into operators’ broader network API portfolios as they pursue “network-as-a-platform” strategies.
• Sector‑specific AI‑native services, such as stadium analytics, transportation corridor monitoring, or drone traffic management, built by ISVs on top of Nokia’s exposed E3 data.

For operators that already use Nokia’s MantaRay and SMO stacks for cross‑network optimization, AI‑RAN essentially becomes the local real‑time execution environment, while R‑apps/X‑apps continue to orchestrate macro-level behaviors. Mukherjee described this layered architecture as “DU and CU on the platform running D‑apps using E3, interfacing to X‑apps and R‑apps through E2SM and connecting to the overall management system/SMO for lifecycle management.”

Adoption path and reality check

Nokia is not promising instant transformation. AI‑RAN pilots are slated for late 2026, with commercial availability on card‑based systems in 2027 and AirScale-based systems around 2028, all driven from a single software stack that supports 4G, 5G and is upgradable to 6G. The company already has trials and collaborations underway with T‑Mobile US, SoftBank, Indosat Ooredoo Hutchison, BT, Elisa, Vodafone, Orange, NTT Docomo, Deutsche Telekom and others.

There are still open questions around 3GPP vs ORAN standardization of E3, the maturity of the D‑apps ecosystem, and how operators will digest yet another subscription layer tied to radio software. But Nokia’s move puts a stake in the ground: in the AI era, the RAN is not just a throughput engine; it’s a programmable AI computer that can be monetized.

For Network World readers evaluating vendor roadmaps, this launch suggests a clear directional change. If Nokia hits its targets, AI‑RAN could mark the point where baseband becomes less about hardware SKUs and more about an AI platform strategy—one where spectral efficiency and new services are rolled out at “software speed,” as Ed described it, rather than at the pace of the next card generation.

AMD executives took to the stage at its Advancing AI 2026 event in San Francisco today to detail the company’s next generation of AI infrastructure solutions, from Instinct MI455X AI accelerator GPUs and 6th Gen EPYC “Venice” CPUs, to Pensando networking, ROCm.AI software and its Helios rack-scale platform that ties it all together.

AMD has been working towards rack-scale AI system solutions for years. Its ZT Systems acquisition last year added valuable engineering talent and intellectual property that is now finally bearing the real fruits. Its Helios AI platform is a major platform evolution for AMD, with shipments scheduled to begin in the second half of this year (which is here and now).

The announcements at Advancing AI show how the company has engineered its AI platform solutions for large reasoning models, sustained inference and agentic workflows. These workloads pressure memory capacity, data movement, networking and CPU orchestration. AMD’s approach is to keep as much data close to the compute engines as possible and move it more efficiently throughout the system, but there’s deeper nuance here that’s obvious versus AMD’s chief rival, NVIDIA.  

AMD’s MI455X targets the AI memory wall

The Instinct MI455X GPU is the compute engine that fuels the Helios rack, and the first GPU based on AMD’s new CDNA 5 architecture. Built with a modular mix of 2nm and 3nm chiplets, it carries 432GB of HBM4 and 23.3TB/s of peak memory bandwidth.

Compared to AMD’s current MI355X, the MI455X offers 1.5 times the memory capacity, up to 2.9 times the peak memory bandwidth and up to four times the peak matrix performance with MXFP4 and MXFP8 data types, which are lower-precision numerical formats designed to accelerate AI processing while reducing memory demands. With MXFP6 (6-bit floating point), performance is rated at up to twice that of MI355X.

AMD also shared some actual, measured internal results using production silicon. The company claims MI455X delivers 3.8 times higher FP8 decode performance, 3.5 times more measured FP4 compute performance and between 2.5 and 3.5 times more networking bandwidth than MI355X, depending on the transfer path tested. Those figures provide more context than just numerical specifications, though they remain AMD-provided comparisons that will need independent validation.

AMD

The architectural choices behind the numbers are important. Reasoning models and long context windows require sizeable KV caches for maintaining AI attention states, while mixture-of-experts models frequently move large amounts of data across accelerators. MI455X should let more model data, activation states and cache remain local. New dedicated IP in hardware can transfer data while the GPU continues processing, and expanded cache and multicast capabilities are designed to reduce redundant data movement to further improve efficiency.

The aforementioned lower-precision formats can also raise throughput and reduce memory use, but model developers still have to determine where they can be applied without unacceptable accuracy loss.

AMD’s Helios rack takes aim at Vera Rubin

Dave Altavilla

Helios is AMD’s primary rack-scale competitor to NVIDIA’s Vera Rubin platform. Each liquid-cooled rack combines 72 MI455X GPUs, 18 single-socket Venice host CPUs and Pensando networking technologies.

In its most complete, premium configuration, AMD rates Helios for 2.9 exaflops of low-precision AI compute, with 31TB of aggregate HBM4 capacity, 1.7PB/s of memory bandwidth, 260TB/s of bidirectional scale-up bandwidth and 43TB/s of scale-out bandwidth.

These are formidable figures, but they are technical specifications rather than actual application benchmarks. The more consequential development is AMD’s move from collections of eight-GPU servers to a 72-GPU shared-memory domain. Models too large for one node can operate across the rack without treating every exchange as a scale-out networking transaction, which benefits large-model inference as well as training.

AMD uses UALink over Ethernet, or UALoE, for an open standard scale-up fabric. Each MI455X provides 3.6TB/s of bidirectional scale-up bandwidth, while the complete rack delivers all-to-all connectivity through a single switch layer. AMD also claims six times more scale-out bandwidth per GPU than MI355X when MI455X is configured with three Pensando Vulcano 800 AI NICs.

While open standards give cloud providers more control over suppliers and system design, AMD and its partners now have to prove those components can deliver the predictable performance, reliability and deployment experience customers expect from a tightly controlled, more vertically integrated platform.

Finally, AMD designed Helios with automatic rerouting around failed links, virtual rack partitions, tray-level serviceability and rack-wide power, cooling and health monitoring. Major hyperscalers and potentially large-scale enterprise customers will likely key in on these capabilities, which can affect the availability, total cost and consistency of the AI services they consume.

Kind of like cowbell, AMD Venice gives agentic AI more CPU

AMD

AMD’s agentic CPU messaging regarding its upcoming Venice-based EPYC processors is mostly marketing speak, but the underlying requirement is very real. An AI agent can invoke retrieval, databases, security checks, code execution and other tools before a GPU generates a response. Running many agents concurrently increases the amount of conventional compute requirements surrounding the accelerators.

Venice scales to 256 Zen 6 cores with support for 512 threads, 16 memory channels, up to 1GB of L3 cache per socket, along with PCIe 6.0 and CXL 3.1 connectivity. AMD is also offering several Venice configurations for other applications, including general-purpose servers, high-frequency workloads, GPU hosts and high-density CPU sandbox systems used to execute agent tools.

Treating the CPU solely as a GPU host understates its role. Gateways, tokenization, vector search, databases and short-lived code execution stress different mixes of per-core performance, thread count, memory bandwidth and I/O. Specifically, AMD’s internal testing shows Venice significantly outperforming its current EPYC 9965 Turin CPU across five parts of the agentic AI pipeline, including gateway processing, context assembly, vector search, enterprise applications and short-lived tool execution. Individual gains vary by workload, but AMD details the overall generational improvement at up to a 1.7 times lift. As with the MI455X figures though, these comparisons come from AMD and will require independent validation.

Pensando networking and ROCm software advance

Keeping GPUs fed with data and coordinating traffic across racks directly affects utilization and operating costs. In fact, GPU utilization is a pretty sad state of affairs currently for some of the major frontier model providers.

As such, Pensando networking has become central to AMD’s roadmap. Helios can connect each MI455X to as many as three 800Gbps Vulcano AI NICs, while Salina DPUs handle front-end networking and infrastructure services.

On the software side, which is an equally critical component, AMD also introduced ROCm.AI, an AI-assisted development layer due to arrive in August. It includes reusable skills for coding agents, simplified management and Hyperloom, which can profile workloads, tune serving configurations, modify kernels and validate results.

These tools address two persistent AMD challenges: developer efficiency and ease of use, and software tuning. Automated optimization still has to produce repeatable gains without creating hard-to-maintain code, however. And while ROCm has progressed significantly over the last few years, NVIDIA’s CUDA retains an advantage in maturity, tooling and developer familiarity.

Customer commitments underscore rack-scale confidence

AMD now has commitments that give its MI450 generation and Helios considerably more weight. Meta and OpenAI have announced multi-generation agreements composed of up to 6GW of AMD compute capacity, with initial 1GW deployments planned for the second half of 2026.

Oracle plans a 50,000-GPU public cloud cluster beginning in the third quarter, while Microsoft will deploy Helios for Azure AI inference. Finally, just before the AMD event, Anthropic announced a strategic partnership for up to 2 Gigawatts of AMD-fueled AI compute, with its first gigawatt expected online in the first half of 2027.

Commitments of this scale reflect confidence in more than just MI455X performance. These customers are evaluating the complete architecture, including Venice CPUs, Pensando networking, ROCm software, rack integration, serviceability and AMD’s ability to deliver and execute across multiple product generations.

There is some financial alignment behind the agreements as well. AMD issued OpenAI performance-based warrants and committed to investing up to $5 billion in Anthropic. That context matters when evaluating these deals as market validation, but these planned deployments are substantial nonetheless and put Helios on a much stronger foundation as it begins shipping.

AMD expands its robotics and embedded foundation

AMD also expanded its physical AI portfolio, building on credible traction from its Xilinx-derived Kria adaptive system-on-modules and embedded technologies that are already powering robotics, machine vision and industrial automation applications.

The new Ryzen AI Embedded X100 combines up to 16 Zen 5 CPU cores, integrated Radeon graphics, a second-generation NPU and as much as 128GB of unified LPDDR5X memory shared across its compute engines. To me this looks a lot like a repackaging and optimization of the company’s Strix Halo platform, but with specific optimizations for the embedded space. Regardless, AMD is pairing X100 with the Kria AI Robotics Developer Platform, which includes a System Module or SOM, and a new Robotics Partner Network spanning hardware, software and platform providers.

Samples began shipping in June, with full production expected in the fourth quarter. This broader objective is to give developers a path across AMD x86 CPUs, GPUs, NPUs and FPGAs for real-time autonomous systems, rather than requiring them to assemble those hardware engines and software components independently.

Execution for AMD is now the test

AMD has assembled a credible platform for the burgeoning agentic AI market that’s blowing up currently with no signs of stopping. MI455X addresses memory and data movement, Venice handles dense agentic CPU workloads, Pensando networking connects global system resources, and ROCm.AI addresses software complexity. Finally, Helios assembles these components into a true competitive threat for NVIDIA’s latest Vera Rubin platform.

AMD’s open architecture may appeal to customers seeking supplier choice, but openness must also translate into reliable deployments, competitive total cost and software that does not require a significant rip-up. NVIDIA enters this cycle with a stronger ecosystem and far more rack-scale deployment experience. The true test will be how easily and reliably customers can integrate, operate and maintain these AMD solutions at scale.

As it stands, AMD now has major customers and a clearly defined architecture with systems engineering expertise behind it. Delivering Helios on schedule and showing that its performance claims translate into a real production workload throughput advantage and total cost of ownership gains will determine how much the competitive gap narrows. And of course, this is in a market that is clamoring for ever-more compute resources with a seemingly insatiable demand for AI services and capacity. That’s an environment for big iron success. Now AMD just has to deliver optimized, turnkey AI platforms. This is far easier said than done, but time will soon tell as deployments take shape this year.

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

Defense research agency DARPA made its largest quantum computing award ever this week, with a $125 million agreement announced on Wednesday. The same day, the White House announced an additional $5 billion for the Genesis Mission, which focuses on AI for science but also includes technology to accelerate quantum computing and quantum sensors.

“Taken together, these announcements signal that U.S. quantum strategy is shifting from supporting individual research projects to building the infrastructure needed for a quantum-enabled economy,” says Heather West, research manager in the infrastructure systems, platforms, and technology group at IDC.

None of the individual quantum announcements are surprising, she says. But the level of coordination is new. “Government investment is expanding beyond foundational research toward commercialization, manufacturing, and deployment,” she says.

“The US government has been signaling that quantum computing is a priority,” says David Mooter, an analyst at Forrester Research. Part of it is the desire for the US to be a leader in quantum, as it has been in other high-tech areas, he says. And part of it is because the government itself can take advantage of quantum computers.

“Spy agencies would love to use them to decrypt intercepted messages, including messages they intercepted years ago and saved,” he says. And other departments could use quantum computers or networks for energy-related research, for supply chain optimization, and for secure communications. 

Quantum computing is accelerating, he says. “I would not be surprised to see a general gate-based quantum computer that’s good enough to provide commercial value for limited use cases by 2030.”

DARPA’s Quantum Benchmarking Initiative

DARPA’s Quantum Benchmarking Initiatives was launched in 2024, and 18 companies were selected in April of 2025 for Stage A of the project, with awards of up to $1 million each. The companies were to use the money to provide details of their concepts and show how they could lead to a functional, fault-tolerant quantum computer in under a decade.

Then, in November of 2025, DARPA chose 11 companies for Stage B of the project, with awards of up to $15 million for developing their research plans.

To date, only two companies have been chosen for Stage C: PsiQuantum and Microsoft. PsiQuantum announced $32 million of DARPA funding for testing and evaluation in September of last year. This week’s $125 million award will expand the scope and pacing of the validation and verification work. Stage C awards can go up to $300 million, according to DARPA.

This past May, PsiQuantum also announced $100 million from the Department of Commerce, part of the CHIPS and Science Act, to accelerate domestic manufacturing of critical quantum computing components.

Microsoft and PsiQuantum are both in Stage C, bypassing the sequential path that other companies are expected to follow, because they were both part of DARPA’s predecessor to QBI, the Underexplored Systems for Utility-Scale Quantum Computing program.

Genesis Mission

Genesis Mission was launched in late 2025 with the goal of using AI to accelerate scientific breakthroughs, and it now includes more than 15 government agencies.

As part of the Genesis Mission, quantum computing and sensing company Infleqtion announced three projects for the Department of Energy on Wednesday. The three projects focus on quantum circuit design for nuclear applications, atomic quantum sensing, and nuclear fusion energy research.

This announcement did not include the total monetary value of the projects, but, in May, the company announced a separate agreement with the Department of Commerce for $100 million to accelerate Infleqtion’s neutral-atom technology roadmap.

Other quantum-related Genesis Mission projects announced this week include $1.5 million for a BlueQubit quantum error correction project with Microsoft and other partners, a Stanford effort to model the behavior of electrons at quantum scale, an MIT quantum sensing project, Argonne National Laboratory projects on quantum circuit design and quantum sensors, Brookhaven Lab quantum sensor projects, and quantum computing projects at Northwestern University.

IBM, one of three dozen private companies that are part of the Genesis Mission Consortium, announced that it will be leading a project to support more effective quantum applications, and will contribute up to $50 million of quantum compute access for the Genesis Mission.

Enterprise priorities

This week’s quantum announcements aren’t a sign that enterprises need to run out and buy quantum computers, says IDC’s West. But they do need to start preparing for the quantum era — such as by identifying business areas where quantum computing could become a competitive differentiator over the next decade.

But the most immediate threat is that of adversaries using quantum computers to break current encryption standards. Organizations should be inventorying cryptographic assets and developing a roadmap for the migration to quantum-proof algorithms, West says.

The point of no return is closer than ever, and many major players in the encryption and communication space, including Google and Cloudflare, have been accelerating their timelines. In fact, this Wednesday was the federal deadline for naming their post-quantum cryptography migration leads under a June executive order.

“The preparation that needs to be done to prepare is to implement post-quantum cryptography yesterday,” says Forrester’s Mooter.

However, according to a survey released by DigiCert this morning, while 87% of organizations are planning, testing or implementing PQC initiatives, only 7% of organizations have deployed quantum-safe or hybrid cryptography across most of their digital certificates.

Revenue from IBM’s z mainframe portfolio declined 42% in the quarter ended June 30, dragging infrastructure revenue down 7% compared to the year-ago quarter. But Big Blue executives remain positive on the mainframe’s role as an important AI platform.

After warning of an earnings shortfall, IBM lowered its full-year forecast. It now expects 2026 revenue to grow between 4% and 5%, rather than its previous forecast of more than 5% growth. Some parts of its business did well: Software revenue grew 5% in the second quarter to $7.76 billion, fueled by 11% growth in hybrid cloud, 18% growth in data, and 3% growth in automation.

On the infrastructure side, IBM posted second-quarter revenue of $3.8 billion, which is down 7%. Within that business, distributed infrastructure grew 37%, but those gains were offset by a 10% decline in hybrid infrastructure and IBM Z’s 42% drop.

In a July 14 letter to investors released prior to IBM’s July 22 earnings call, CEO Arvind Krishna warned of the earnings shortfall and laid out current challenges. He related the infrastructure performance shortfall to “wrapping on the launch of z17 in the second quarter” and stated: “Given this was the strongest start to a mainframe program in our history, we expected Infrastructure revenue to decline low-single digits for the year, beginning this quarter. What played out was worse than our expectations, driven by a shortfall in our Z performance and the associated software stack, primarily in Transaction Processing.”

In the last few weeks of June, customers shifted capex spending and started purchasing more AI infrastructure components in the form of servers, storage, and memory “to secure supply-constrained infrastructure ahead of expected price increases,” Krishna stated. “This dynamic impacted client buying patterns. While we anticipated some supply chain related impact in our expectations, we did not anticipate the magnitude of the capex reprioritization.”

Yet despite challenges this last quarter, z17 remains at nearly 130% growth program-to-program, according to IBM. That’s “well ahead of z16, which was our strongest program on record, with clients representing 85% of installed MIPs maintaining or growing capacity,” the July 14 letter stated.

Mainframe infrastructure momentum is expected to continue, and IBM is anticipating strong workload growth and AI-driven capacity expansion as clients modernize mission-critical systems and emphasize resiliency and security, Krishna said during the company’s Q2 2026 earnings call on July 22.

“AI is driving incremental capacity growth and new workloads as clients look to run AI closer to their most sensitive data,” IBM senior vice president and CFO James Kavanaugh said in the call. “We are seeing strong early adoption of our AI innovations with nearly 50% of z17 customers investing in AI capabilities with Spyre AI accelerator, and clients deploying Watson X Code Assistant for Z are growing MIPS capacity three times faster than those who are not.”

“In a world where infrastructure costs are rising and efficiency matters more than ever, IBM Z offers a compelling economic advantage,” Kavanaugh continued. “Depending on the size and complexity of workloads, clients can realize a 2 to 15x total cost of ownership benefit versus moving these workloads off the platform, reinforcing why the platform remains central to their operations and positioning us to capture additional value as AI workloads grow.”

“We see no evidence of clients moving off mainframe,” Kavanaugh added. “Clients continue to invest in IBM Z to modernize mission-critical workloads with a focus on resiliency and security.”

In responding to an analyst question, Kavanaugh said three key things drive mainframe demand and purchasing requirements:

“One is capacity workload. It’s the most important determinant. 85% Of the installed MIPS capacity out there in the marketplace today running all those core mission critical workloads are either stable or growing. Clients are adding capacity and workload to mainframe, the viability. And by the way, that’s coming in new AI workloads, analytics workloads, Linux-based workloads, and those MIPS are growing program to date over 15 to 20% installed capacity,” Kavanaugh said.

Number 2 is economic factors. “We don’t talk a lot about this, but I think it’s important for our investors to understand things like total cost of ownership. Depending on the size and complexity of the workload, we have anywhere from a 2 to a 15x TCO advantage running on the mainframe [over smaller server systems]. Again, we do not see any evidence of clients migrating off mainframe and lease propensity, which is a great indicator,” Kavanaugh said.

The third driver is AI. “When you look at it, applications, data security, all on the platform, we do 450 billion inferences per day at 1 millisecond with 8 nines availability,” Kavanaugh said. “We’ve got clients that have already purchased over 50% of our Spire inferencing, and those clients that have purchased that are growing MIPS capacity, the way [we monetize value], by over three times faster than others.”

Google’s AI offerings span its internal and cloud offerings. Its data centers are processing seven times more AI tokens compared to last year. To keep up, Google is upgrading its data-center hardware and software technologies at a faster clip. It plans to raise $80 billion to build new data centers. (See related story: Google transforms its data center architecture for agent era)

Network World spoke with Mark Lohmeyer, vice president and general manager of AI and computing at Google, about how the company’s infrastructure is keeping pace with AI demand.

Network World: What is the primary shift in infrastructure needs?

Mark Lohmeyer: We’ve seen the rise of agents and agentic use cases. Years ago, it was the chat phase: Ask a question, get an answer. Now we’re in the agentic era, where you express your intent, agents spin off multiple sub-agents, working in parallel, preserving state. This is a radical shift in what infrastructure needs to do; make them fast, cost effective, secure, reliable. We’re delivering infrastructure optimized for the age of agents.

NW: What’s the goal of the infrastructure buildout, and what should customers expect regarding costs?

ML: Ultimately, it’s about enabling customers with leading-edge capabilities and models at scale cost-effectively. With agents, inference transactions increase by 50x, 100x versus non-agentic workloads. We’re driving the cost per transaction down exponentially. In our latest platforms, we reduce the cost by almost 2x for the same work. Customers serve twice the number of users at the same cost, directly driving profitability.

NW: How are you addressing energy efficiency?

ML: Energy is a critical resource, and Google has optimized for years. We design data centers and compute [to drive] high PUE (power usage effectiveness). We introduced liquid cooling over five years ago, and these latest systems are all liquid cooled. For agentic workloads, CPUs come to the forefront… orchestrating agents, calling tools, doing evaluation loops in reinforcement learning. Our latest Axion-based CPU platform called N4A has energy efficiency and is significantly better than the prior generation and x86 comparables.

NW: How do you think about token efficiency as you build-out systems?

ML: Performance and efficiency gains are powered by co-design of the model and infrastructure. Gemini is trained on TPUs, primarily served on TPUs with high frontier model capability, in a token and cost-efficient way. This stems from co-design across the full stack.

NW: How do you project what infrastructure will be needed years in advance?

ML: Hardware cycles deliver a new next generation roughly every year, but design cycles are two years or more in advance. We work with DeepMind doing core research, to application teams taking models into production, to billions of users, to our team building infrastructure. We work upstream with DeepMind and application teams to understand what’s coming. Agents weren’t being broadly spoken of externally, but internally we had those insights around what they would need. That shows up in hardware design. We hit the timing right — these platforms are built for agents.

NW: What’s the eighth generation TPU platform?

ML: We deliver new platforms every year, and ones launched years ago are close to 100% utilized because demand for AI-optimized compute is high. The eighth-generation TPU platform is the first delivering two complete systems, from the chip all the way up to the network and storage and software, that are optimized.

TPU-8t is optimized for training, and TPU-8i is optimized for inference. For TPU-8i, we increased SRAM on the chip to 384MB — three times the prior generation — and increased the HBM by 50%.

NW: How are you approaching GPU and TPU compatibility?

ML: People in a single cluster do not commingle GPUs and TPUs. We offer both options based on specific workload needs. We’ve been investing on the TPU side in using software frameworks customers are comfortable with on GPUs and enabling those on TPUs. For example, PyTorch and vLLM. Customers could have a pool of GPUs and TPUs, running vLLM on top of that. Start with a workload on TPUs, but if the TPU pool is fully utilized, spill to GPUs or vice versa. This works because it’s all leveraging the same compatible software layer on top.

NW: How has the orchestration platform changed for agents?

ML: Kubernetes is becoming the orchestration platform of choice for AI. Google is transforming GKE [Google Kubernetes Engine] into an agent-native orchestration solution. When expressing intent to an agent and it spins up multiple sub-agents, compute needs to spin up rapidly — TPUs or GPUs — without long delays, then run and spin back down. We’re optimizing at every layer of the GKE stack: significantly improving node startup time and how rapidly we start and stop containers. Lovable demonstrates this with GKE, spinning up hundreds of sandboxes for live coding sessions on their platform in parallel, paying for infrastructure when needed.

NW: What is the role of the network and storage infrastructure?

ML: The network is critical for AI. This requires creating large-scale clusters of GPUs or TPUs and enabling them to talk to each other in a high-performance way. We created the Virgo network — a collapsed network architecture, non-blocking within a data center, where multiple pods or NVLink72 domains connect together.

In TPU8T, we can connect over a million TPUs together leveraging Virgo, creating large-scale, high-performance, reliable clusters that shrink innovation cycles. Storage is equally critical. In large-scale clusters, something is always failing. The ability to take snapshots and go back to a checkpoint is important.

We’ve introduced Managed Lustre 10T, with 10 terabytes per second of bandwidth, 18 petabytes of storage in single clusters. This is 10 times faster than last year and 20 times faster than competition. We have Rapid Bucket, low-latency storage backed by Google storage systems. Both are impactful in large-scale training environments.

NW: How does KV cache strategy differ between training and inference?

ML: For TPU-8i, we increased SRAM on the chip to 384 megabytes — three times the prior generation — and increased the HBM by 50%. Storing KV cache directly in chip memory allows responding to inference requests much more rapidly and cost-effectively than going to an external system. For inference workloads, storing as much KV cache as possible on-chip is critical.

We’re introducing a dedicated KV cache storage subsystem that works across GPUs and TPUs. As KV caches get larger, being able to fall back to this dedicated subsystem becomes critical. Loading model weights rapidly is important in dynamic inference environments where accelerators switch between models hour by hour.

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

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

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

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

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

Competitive differentiation was never about the tools

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

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

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

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

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

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

Building a contextual AI fabric

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

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

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

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

Proprietary by design

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

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

From context to coordinated action

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

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

The leadership question behind the technology question

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

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

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

When Anthropic unveiled Project Glasswing and the Mythos model, much of the discussion focused on the capabilities themselves.

Security leaders debated what these systems could mean for vulnerability discovery, exploit development and the pace of offensive innovation. Researchers examined technical benchmarks. Industry observers questioned how quickly these capabilities might fall into attackers’ hands.

Those conversations are important. They also point to a larger question that predominates my discussions with CISOs: How much time do we have?

Over the past year, conversations about AI in cybersecurity have changed noticeably. Twelve months ago, security leaders wanted to understand whether AI could meaningfully improve security operations. They wanted to know whether it could accurately investigate alerts, reduce analyst workload and operate reliably in production environments.

Today, security leaders are asking about timelines, implementation, how quickly AI is changing the threat landscape and what that means for how security teams operate.

Anthropic’s Mythos and Glasswing, OpenAI’s Daybreak and advances in DeepSeek accelerate those conversations. Each development provides another glimpse into the pace at which AI capabilities are advancing.

AI now reasons through security problems that historically required highly specialized expertise. The implications span vulnerability discovery, attack-path analysis, reconnaissance, social engineering and security operations.

The shift reflects a broader reality: cybersecurity is entering a period where the pace of adaptation may matter as much as the quality of defenses themselves. AI is accelerating both offense and defense simultaneously. Organizations are quickly redesigning security operations around that reality.

One consequence is becoming increasingly visible. For years, cybersecurity teams invested enormous effort in discovering threats, identifying vulnerabilities, gathering telemetry and collecting intelligence. AI is accelerating many of those activities simultaneously. Visibility is improving. Discovery is accelerating. Investigations are becoming faster and more comprehensive.

The bottleneck is beginning to move. The challenge increasingly centers on how quickly organizations can act on what they know. The organizations that gain an advantage may not be the ones with the most information. They will be the ones who can operationalize that information the fastest.

The timeline is compressing

Cybersecurity has experienced many major technology transitions. Cloud computing changed infrastructure. Mobile devices expanded the attack surface. Digital transformation connected systems that were previously isolated.

AI introduces a different dynamic.

Most technology transitions unfolded over years. Organizations had time to evaluate, pilot, deploy and gradually adapt operating models.

The current AI cycle moves at a different pace.

Capabilities improve continuously. New models arrive every few months. New research emerges every few weeks. Security teams absorb developments at the same time attackers do.

Vulnerability discovery provides a useful example. Security teams have long operated around a familiar cycle of discovery, validation, remediation and protection. AI systems accelerate every stage of that process. Similar patterns exist in phishing, reconnaissance, social engineering and attack planning.

A vulnerability that once moved through that cycle over weeks increasingly now moves through those stages in days or, in some cases, hours.

Attackers are already operating at the speed of AI. Defenders are now focused on reaching the same level of operational speed.

This shift is changing the questions CISOs ask.

Early discussions focused on capability. Could AI investigate alerts accurately? Could it operate reliably in production environments? Could it be trusted with meaningful security work?

As organizations gained experience with AI, the discussion shifted toward implementation. Security teams began evaluating where AI could create operational leverage and how quickly they could deploy it into existing workflows.

Today, many CISOs are focused on timing.

The pace of advancement is influencing planning horizons, budget decisions and operating-model discussions. Security leaders are evaluating how quickly they can introduce AI into investigations, threat hunting, detection engineering and response workflows. Boards are asking questions. Executive teams are paying attention.

Security programs that once viewed AI as a future initiative increasingly view it as a current operational priority.

The industry is moving from evaluating AI as a technology to incorporating AI as a security capability.

The timeline compression creates pressure on the traditional security operations model. Investigation speed, response speed and defensive coverage increasingly determine whether organizations can keep pace with adversaries operating with AI assistance.

Security operations are entering a new phase

The impact of AI is becoming particularly visible inside the SOC.

Many security operations centers were built around a straightforward assumption: alerts flow to human analysts who conduct investigations. Operational capacity scales primarily through hiring.

The volume of security data, the number of alerts and the complexity of modern environments have steadily increased. Security teams have responded by building processes, adding tools and creating specialized analyst roles.

AI introduces a new source of operational capacity.

Investigations that require analysts to examine dozens or hundreds of artifacts across endpoint, identity, cloud, network and email systems can now be performed in minutes. Analysts gain access to investigative depth and consistency that would be difficult to achieve manually at scale.

Many security leaders now view this capability through the lens of operating model design. They are examining how investigations are performed, how work is distributed and where human expertise creates the greatest value.

The evolution of the analyst role

One of the most important developments emerging from early production deployments is the evolution of analyst responsibilities.

Security analysts remain central to security operations. Their expertise becomes even more valuable as AI systems take on larger portions of investigative work.

Threat hunting, detection engineering, response strategy, governance and oversight are receiving increased attention. Analysts spend more time shaping how investigations are conducted, evaluating outcomes and improving overall security operations.

Many organizations are already beginning this shift.

Teams are investing more heavily in proactive security activities. Detection engineering programs are expanding. Threat hunting is becoming more accessible. Analysts are spending more time improving systems and less time repeating investigative tasks.

These changes create what I think of as an analyst-amplified SOC: an environment where AI expands the reach of security professionals and enables deeper security work across the organization.

Trust is critical and it doesn’t have to compromise speed

Faced with a compressing timeline, the instinct is to treat speed and trust as a trade-off, i.e., move faster, verify less. That trade-off feels inevitable. It isn’t.

You don’t trust AI in the abstract. You trust that a system understands your tools, your telemetry and the edge cases that only exist in your network. The problem was never speed. It’s speed without context. The faster a context-blind system runs, the more decisions you’re left unable to verify.

The tension eases when the system is quick to deploy and tunes to your environment once it’s there, rather than treating every network the same. Speed stops being the thing you trade against trust. The more it learns about your environment, the sharper and more trustworthy it becomes, so the two compound rather than compete. Trust still develops through operational evidence such as measurable outcomes, visibility into decisions and consistent performance. But where that evidence accrues matters.

The organizations making the fastest real progress understand this. They don’t compromise quality and trust for speed. They invest in AI that earns trust inside their own environment, so they don’t have to choose.

Leadership during a period of rapid change

The conversations surrounding Mythos and Glasswing reflect a broader reality facing security leaders.

AI is becoming part of both offense and defense. Security teams are incorporating it into investigations, detection engineering, response workflows and threat hunting. Attackers are incorporating it into their own operations.

Security leaders have an opportunity to modernize operating models, expand defensive capacity and build organizational experience while these capabilities continue to evolve.

The organizations making progress today are investing in readiness. They are building experience, adapting workflows and preparing teams for a new model of security operations.

The next phase of cybersecurity will be defined by how effectively organizations combine human judgment with machine-scale execution.

The question facing security leaders is increasingly clear: How quickly can their organizations adapt to a continuously changing threat environment?

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

A client called me last week with a problem I have been hearing about more often lately. They had made significant reserved instance commitments with a major cloud provider, overbuying for what they thought would be heavy AI training workloads. Now they were sitting on thousands of dollars in idle capacity every month. Their plan was simple: resell it to someone else. Except they couldn’t.

I have been doing cloud consulting for a long time, and this situation once had a straightforward solution. You went to the marketplace, listed your unused reservations, and found a buyer. The process was a bit clunky, but it worked. These days, the answer is far more complicated, and my client learned this the hard way.

AI has made this problem increasingly common. Companies initially committed to compute capacity based on ambitious training plans. Prototype projects were expected to scale, and inference workloads were projected to grow substantially. Then reality hit. Some projects did not materialize. Some models trained faster than expected. Some inference patterns were lighter than anticipated.

Many organizations now hold reserved capacity they can’t use, discard, or share without a complex, increasingly restricted process. This reality is something every company with significant cloud spend needs to clearly understand.

The history of cloud resale

There was once a functioning resale market for cloud reserved instances. AWS, for example, maintained a Reserved Instances Marketplace where companies that had purchased reserved capacity could sell those reservations to other AWS customers. This was a legitimate, AWS-sanctioned process. Companies would register as sellers, list their unused reservations with pricing and terms, and if a buyer appeared, the marketplace would facilitate the transaction.

The resale market was useful for companies that had overestimated their needs or whose business changes reduced their cloud consumption. Instead of simply absorbing the cost of unused commitments, they could recoup some of that investment by selling to other organizations with unmet demand. It created a secondary market that added liquidity to what was otherwise a rigid financial arrangement.

My client had some experience with this resale market a few years ago and assumed they could use it again. They were unpleasantly surprised to learn that the rules had changed.

AWS changes the rules

In January 2024, AWS implemented a significant policy change that effectively shut down the resale of EC2 Reserved Instances on its platform. AWS stopped allowing companies to resell their unused reserved capacity through the Reserved Instance Marketplace or any other official channel. If you have a reserved instance commitment with AWS, you are essentially stuck with it unless you can use it yourself or modify your reservation.

This change had a real impact on companies that had relied on resale as part of their cloud financial management strategy. It reduced flexibility and increased the risk of long-term reserved commitments. When I explained this AWS policy change to my client’s representatives, I could hear the frustration in their voices. They had made their commitment in good faith, carefully modeled their expected AI workloads, and now faced the reality that there was no easy exit.

The reasoning behind this change is not entirely clear, but AWS likely viewed capacity resales as something that complicated their billing and commitment models without providing enough benefit to the overall ecosystem. Regardless of the company’s reasons, the primary resale path for the largest cloud provider has been effectively closed.

What options still exist?

What can companies do now when they find themselves with reserved capacity they no longer need? The first possibility is to work directly with the cloud provider to modify or exchange the reservation if it is convertible. Some reservation types allow modifications, such as changing the instance type, region, or tenancy. This will not eliminate the commitment, but it may help companies better align their reservations with actual workload needs.

The second option is to use third-party brokers and marketplaces that operate independently of the cloud providers. Although AWS has shut down its official resale channel, brokers and marketplaces still facilitate resale arrangements for other cloud providers and for some AWS scenarios. These arrangements can be more complex and carry more risk, but they remain a possibility for companies determined to move unused capacity.

The third alternative is to optimize usage. Companies can invest in better utilization monitoring, workload placement, and automation to ensure that reserved capacity is used as efficiently as possible. This does not recover the money already spent, but it reduces future waste.

My client explored all three alternatives and found that each had significant limitations. Modifications were possible, but only within a narrow range. Third-party brokers were interested, but the process was opaque and uncertain. Optimization helped, but it could not eliminate the fundamental overcommitment they had already made.

The broader implications

Cloud commitments are more rigid than many enterprises initially realize because they lack a liquid market and because providers control modifications, transfers, or cancellations. Right now, I see this pattern most often in the AI space. Companies commit to massive amounts of compute for training and inference based on projections that rarely reflect the actual workloads. Then they are surprised to find themselves locked into payments. The AI boom has led to significant overcommitment because enterprises remain unaware that the resale mechanisms that once existed have been largely shut down.

This is why cloud financial management has become such an important discipline. Companies need to be far more thoughtful about how they commit to cloud resources, how they model their future consumption, and how they build flexibility into their cloud strategies. The days of assuming you can always resell your way out of an overcommitment are effectively over, at least with AWS.

For Azure and Google Cloud, the resale landscape is slightly different, but the same general principles apply. These providers have their own capacity transfer policies and, like AWS, those policies can change at any time. Companies should understand their options before making large, committed purchases and build contingency plans in case their actual usage diverges from their projections—or if resale policies change.

The bottom line is that reselling unused reserved cloud instances is far more complicated than it sounds. The market is not as open as it once was, the options are limited, and the providers themselves hold most of the cards. My client got burned, and I doubt they will be the only one. Companies that want to optimize their cloud spending should focus on accurate forecasting, thoughtful commitment sizing, and ongoing optimization rather than relying on resale as a safety valve. That approach worked at one point, but those days are largely gone.

If you ask us in an official setting, our official position is that software engineering norms still apply. Rigorous CI/CD pipelines, elegant architectural patterns, and an unyielding commitment to maintainable code remain the standard. We will use weighty words like “determinism,” “scalability,” “idempotency,” and “domain-driven design.”

But behind closed doors, late at night, bathed in the glow of a dark-mode IDE, a different and more sordid reality is exposed. Hunched over the console with a manic gleam in the eye, the programmer has become power-drunk on LLMs. Like mad wizards casting spells, we summon the awesome powers of models and agents to satisfy our every programming whim—and commit acts of software engineering that would make Fred Brooks blush.

Let’s just be honest about what is actually happening.

Esoteric knowledge is superfluous

Forget OOP and FP. Forget the CAP theorem, the holy crusade of DRY, and the design patterns. Honestly, you can even forget what frameworks, runtimes, and deployment platforms you are using. The AI will figure out what is best to use and understand what is already in place. We have more mental bandwidth for working on our side project (a novel about AI taking over the world). 

Of course, I exaggerate. A little.

The docs are dead to us

We still say RTFM, but the truth is, we haven’t really read a page of vendor documentation since 2023. Stack Overflow, once our Internet Mecca, is a husk. When a package throws a weird exception, we don’t trace the execution path or read the release notes. We highlight the red text, copy the entire 200-line stack trace, dump it into the chat, and wait for the machine to spoon-feed us the solution.

Better yet, we just have the agentic IDE spot the error, divine a solution, and ask us if it’s OK. We might glance at the problem-solution description, if we have gone around the circle on the problem for a few cycles. Maybe. If we don’t have the agent set up for auto-confirm.

We used to buy heavy tomes like “Rust In Action” that were more like masonry blocks than literature. Now? We just ask an AI to transliterate our JavaScript logic into Rust. We are no longer engineers methodically learning a system. We are glorified copy-paste orchestrators hoping that the stochastic parrot behind the prompt guesses the syntax correctly.

We ignore how the back end is wired

We act like we meticulously designed the data flows, carefully crafted the relational constraints, and mindfully mapped the API relationships. The reality is rather more disturbing: We asked the AI to scaffold a modern deployment, hooked it up to a back-end database, and just sort of… ran it.

It created security rules we don’t fully understand. They do seem to work, however, which is nice. 

It generated a schema that we skimmed for about four seconds. It looks reasonable.

It wrote infrastructure-as-code scripts that provisioned cloud resources we are hoping don’t blow a hole in the budget. Presumably, whoever is in charge of that will manage it by stuffing the metrics into another chatbot.

We nodded, committed the code, and went to lunch. If management asked us to manually deploy the stack from scratch, configure the environment variables, and wire the API routes without our chat window, we would give them a vacant stare.

We understand that management is also using AI to manage the project.

Our tests are uncomfortably incestuous

Test-driven development (TDD) used to be a beautiful dream, ever just beyond reach. It made us feel glorious and despondent at turns. It would burden us with sprawling dependencies if implemented too religiously. (See The Grug Brained Developer in this regard.)

But now we can attain 95% test coverage almost effortlessly. Why not just add them in while we are auto-generating everything else?

We can now wax at length to anyone who will listen about our astounding test coverage and our automated quality assurance. Unit tests, integration tests, smoke tests, you name it. What we conveniently leave out is that the AI wrote the complex application logic, and then we asked the exact same AI to write the test suite to validate the code it just dreamed up.

It is a hermetically sealed loop of algorithmic self-congratulation. The mocks, the edge case, and the assertions are an echo chamber of the model’s original assumptions. The machine is grading its own homework, giving itself an A+.

And we are happy to accept this because, beautifully, when the code has to change, the AI will effortlessly hallucinate new tests to adapt to the churn.

We pass off the AI’s architecture as strategy

AI can produce astonishing design documents. Truly breathtaking. They are cogent, they’re beautifully formatted, and they seamlessly bridge the gap between high-level business goals and granular technical specs. They even include those auto-generated sequence diagrams that wow management.

When we present these spotless architectural proposals in the Tuesday sprint planning meeting, we lean back, take a long sip of coffee, and humbly wave away the team’s praise.

What we don’t mention is that we spent exactly four seconds generating it.

Are these AI-generated documents just as liable as human ones to hide severe, mortal flaws in scope and alignment? Absolutely. They might contain a foundational logic bomb that will eventually doom the entire project. But the markdown is so crisp, and the bullet points are so persuasive, that the eye just glides right over it. We will never truly know the depth of the disaster until it is far too late. But hey, we’ll burn that bridge when production catches fire. Until then, we are strategic visionaries.

We’re addicted to vibe coding (but only in secret)

We loudly mock the term on social media. We roll our eyes in Slack channels when the kids on TikTok talk about vibe coding their new startups. We fiercely cling to our identities as hardened, serious developers who understand memory management, garbage collection, and bitwise operators. We are professionals, damn it.

But late at night, when the managers are asleep and no one is looking? We absolutely love it. We love just throwing a chaotic, half-baked thought at the canvas, pouring a drink, and watching the AI magically build a functioning user interface based entirely on our long-deferred whims. I may finally build that working Ultima V clone. The thrill of typing “Create an app that tracks my cryptocurrency portfolio but makes it look like the interface from Neuromancer” and having it appear 30 seconds later is heady stuff.

The more deeply rooted in the hard, old-school realities of programming, the more profound is the joy the developer finds in the possibility of AI coding. 

We beat the problem into submission with prompts

Like Adam Sandler in “Uncut Gems,” we are convinced the next round will fix everything. This is us with prompts. When things are going really off the rails, instead of putting our boots on and wading into the brambles of complexity, we resort to tonal adjustments. These range from the condescending:

This problem is not fixed. Look at it closely. The error is right here.

To the desperate:

We have been working on this same problem for hours now!

To the pathetic:

Can’t you find a different approach to try?!

The astonishing part? It often works.

But there is no poetry left at the bottom of the rabbit hole; it is verbal warfare. When the context window collapses, when the regressions start cascading, and when the AI stubbornly refuses to follow the most basic rules of temporal logic, the mask of professionalism drops away and something far more atavistic makes its appearance. We stop asking nicely, stop trying to understand the why, delete the pleasantries, and capslock our intent.

What we have here is a failure to communicate!

We feed the same failing stack trace back into the prompt over and over and over again, aggressively hammering the constraints, explicitly forbidding certain libraries, and pasting in release notes just to confirm that the AI lacks the latest APIs. We force the model down a narrower and narrower path until the code finally stops throwing errors. We don’t actually debug anymore, trace variables, or step through functions. We just apply relentless, iterative pressure until the machine surrenders. We beat it into submission. And then, we push to production.

In fact, there is a real skill here—a sheer “will to completion” that remains in the act of building software. We invest just as much time, energy, and heart wrestling the bot as we ever did emitting syntax.

A blacker box

The only profession more given over to using AI like a cursed Level 13 artifact than programming is writing. Writing of course is far more open to public scrutiny than code.

And while my tongue has been firmly in my cheek here, my faith in coders as good guys makes me more curious to see what we create than troubled by the dangers. 

It was once the case that only other programmers could understand what programmers were doing, what they were producing. Now not even that is true. Only the machine knows what the machine is doing. We just keep it tethered to our aims. Hopefully.

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

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

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

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

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

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

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

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

Fragmented command: The structural vulnerability AI exploits

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

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

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

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

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

Unified command: From org chart to battle plan

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

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

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

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

Field manual: What winning institutions do differently

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

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

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

For the past three years, the AI conversation has been dominated by scale. Bigger models, bigger compute clusters, bigger headlines. But the next wave of competitive advantage won’t come from who can rent the biggest model; it will come from who can build the smallest one that knows their business.

That model is the small language model (SLM): Compact, purpose-built, trained on an organization’s own data and run under that organization’s own governance. And it is about to become one of the most consequential strategic assets available to both the private and public sector.

The problem with renting intelligence

Right now, most organizations consume AI the way they once consumed electricity from a single utility by plugging into a handful of frontier models built by a small number of global vendors. These models are extraordinary generalists. They are also, by design, generic. They are tuned to be safe, broad and useful to everyone, which means they are optimised for no one in particular.

That’s a problem for any organization trying to build genuine differentiation. If every competitor in your sector is calling the same foundation model with the same prompts, the model itself is not your edge. Your edge is what only you know, your proprietary data, your institutional judgement, your operating history. A generic model can’t see any of that unless you keep feeding it to them, turn after turn, at cost, with no lasting memory and no guarantee of where that data ends up.

An SLM flips that equation. Trained on an organization’s own document libraries, case histories, policy archives, transaction data and operational know-how, it becomes a model that thinks the way your organization thinks, because it was built from your organization’s accumulated judgement. It doesn’t need to be the smartest model in the world. It needs to be the most useful one for you.

I’ve seen this play out directly. At one of Australia’s largest integrated tourism and cruise businesses, simultaneously a B2C retailer, a B2B distributor to thousands of agency and wholesale clients globally, an aggregator marketplace for more than 1,800 independent tourism operators, and a cruise operator with offshore shared services spanning finance, customer contact and content management. The constraint wasn’t a lack of access to large general-purpose models. It was that none of them understood the business: 1,800 different operator catalogues, each with its own pricing logic, inventory quirks and content conventions; years of customer contact history with its own vocabulary and escalation patterns; a marketplace search experience that needed to reason over the business’s own product taxonomy, not the open web’s.

Models trained and tuned on that proprietary data, operator listings, historical tickets, booking and pricing data delivered results a generic model never could. Domain-tuned content drafting cut operator listing time by 70% and eliminated a 23-day onboarding backlog outright, taking new-operator time-to-live from 23 days to three. A semantic search model trained on the marketplace’s own product catalogue lifted booking conversion by 24%. AI-driven triage trained on the business’s own contact history cut Tier 1 escalations by 34%. None of this came from a smarter foundation model. It came from a smaller, more specific one that knew the business.

Why “small” is the strategic choice, not the compromise

There’s a temptation to treat SLMs as the budget option, what you build when you can’t afford a frontier model. That’s the wrong frame. The evidence is already compelling: Microsoft’s Phi-4 family of small models, released in early 2025, demonstrated that a 14-billion-parameter model can match or exceed the performance of models many times its size on complex reasoning and domain-specific tasks while running at a fraction of the compute cost and on-premise, entirely within an organization’s own infrastructure. Smaller, domain-trained models are increasingly outperforming general-purpose giants on narrow, high-value tasks, with far tighter control over data residency, security and explainability.

For a CIO or CTO, that combination of lower cost, tighter governance, higher task-specific accuracy is rare enough to demand attention on its own. But the deeper value sits one layer up, at the operating model. An SLM trained on your service history can sit inside claims processing, citizen services, clinical triage, asset maintenance scheduling or M&A due diligence quietly compounding institutional knowledge into a reusable asset rather than letting it walk out the door every time someone retires or resigns.

That is the real shift: AI capability stops being a subscription and starts being a balance-sheet asset. It can be valued, protected, audited and improved because it belongs to you.

The public sector’s hidden advantage

Nowhere is this more obvious than in government. The public sector sits on some of the richest, least-exploited data and institutional knowledge in the country: Decades of policy outcomes, service delivery history, regulatory precedent, infrastructure records and frontline expertise. Most of it has never been put to systematic use because no commercially available model was ever trusted to touch it, and rightly so.

A small, sovereign, purpose-built model changes that calculus. Trained, hosted and governed entirely within government infrastructure, an SLM doesn’t require sensitive citizen or policy data to leave a secure perimeter. The Australian Government has already recognised this direction: The APS AI Plan, released in November 2025, commits to expanding the GovAI platform to provide all public servants with secure, sovereign AI tools operating entirely within Australian Government infrastructure. SLMs tuned to individual agency mandates are the logical next step and a more powerful one than any generic government-wide tool can deliver.

Rather than each agency independently negotiating with the same handful of overseas vendors, a coordinated approach of common standards for model governance, shared security architecture, common evaluation frameworks and pooled infrastructure investment would let agencies build and reuse SLM capability horizontally, the way shared services and common ICT platforms have been built before. Each agency gets a model genuinely tuned to its mandate, but the security model, audit trail and assurance framework are consistent, government-backed and independently verifiable.

Done well, this isn’t just an efficiency play. It’s a sovereignty play. As GovTech Review has noted, large language models hosted offshore create data flows that extend beyond Australia’s borders in ways that are rarely transparent, a risk that is simply untenable for government. Sovereign, purpose-built models keep Australian public data, public knowledge and the resulting capability uplift inside Australian hands, rather than exporting both the data and the long-term value to offshore platforms.

Why this belongs in the innovation budget, not the IT budget

The instinct in many organizations is to treat AI spend as an IT line item, something to be minimised, benchmarked and squeezed for cost efficiency. SLMs deserve a different treatment. They are closer to R&D than infrastructure: An investment in converting accumulated institutional knowledge into a durable, defensible capability.

That argument holds in the private sector too. A PE-backed portfolio company, a regulated financial services firm, a healthcare provider — each has years of proprietary operating data sitting idle in case files, transaction logs and service records. An SLM built on that data is a way of turning a sunk cost, decades of operational history, into a forward-looking asset that compounds with every additional case it processes.

Boards and executive committees that are still asking “what is our AI strategy?” as a single, undifferentiated question are asking the wrong thing. The better question is: Which parts of our operation are rich enough in proprietary data and judgement to justify owning the model outright, rather than renting someone else’s?

The opportunity in front of us

The first wave of enterprise AI adoption was about access: Getting a capable model into people’s hands quickly. The next wave will be about ownership: Who controls the model, who controls the data it was built on, and who captures the long-term value of the institutional knowledge it encodes.

Australia, with a public sector rich in data and a private sector with deep vertical expertise in financial services, resources, healthcare and logistics, is well placed to lead on this if it treats small, sovereign models as a genuine national capability question, not a procurement footnote. The organizations, and the country, that move early will not just save money. They will own something their competitors can’t easily replicate: An AI that knows them.

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

Site reliability engineers (SREs) have the tough assignment of resolving thorny performance and reliability issues. But their primary mission is to provide devops teams with operational insights and to suggest implementation improvements on business system performance, security, and overall robustness.

Google introduced its SRE playbook in 2003, but it took some time for the role’s definition, tools, and techniques to become mainstream. Startups were the first to adopt observability for cloud-native applications and create dedicated SRE positions. As tools matured and SRE responsibilities became more clearly defined, larger enterprises assigned SREs to work as a bridge between devops and IT ops teams to improve resilience across a wider range of applications, APIs, and data pipelines.

SRE is a career path for multidisciplinary engineers with strong investigative instincts, sharp data analytics skills, and the temperament to perform under pressure. It has become a critical responsibility as tech became mission-critical for enterprises, and it is a growing role in the genAI era as more businesses deploy AI agents.

But the critical need for resiliency and greater technological complexity brings new challenges for SREs. According to the 2026 State of Production Reliability and AI Adoption report, 44% of respondents experienced an outage linked to ignored or suppressed alerts in the past year, and 35% report their engineers occasionally ignore or dismiss alerts due to alert fatigue. More than 70% of alerts received are not actionable, according to 57% of organizations.

So, is AI making the SRE’s role easier and helping businesses run more reliable technology operations? On the other hand, AI is also driving complexity, as companies deploy genAI tools and AI agents across more business functions and seek to automate more decision-making across operations.

AIops and agentic ops aid SREs

Over the past decade, SRE responsibilities have become somewhat easier through improvements in monitoring platforms, observability practices, tools for centralizing operational data, and AI applied in IT operations (AIops). But during the heat of resolving an outage or performance issue, it’s not easy to correctly identify what system triggered the issue versus other downstream systems impacted by it.

According to the Komodore 2025 Enterprise Kubernetes Report, 79% of production incidents originate from recent system changes, including deployments and changes to compute environments. But the other 21% of incidents stem from issues outside of the business’s control, including network failures, third-party changes, and cloud provider failures.

“SREs using AI capabilities succeed or fail in the moment an incident unfolds, when engineers are deciding what to investigate next,” says Itiel Shwartz, CTO at Komodor. “If the system streamlines root cause detection, connects signals to recent changes, and explains its reasoning in a way engineers recognize, it earns trust. If it adds uncertainty or demands extra validation, it gets sidelined, regardless of how bespoke the model behind it may be. What’s less obvious is what it takes to make AI for SREs work in production, and how different that reality is from prototypes, demos, or early internal builds.”

AIops is not a new capability, especially in using machine learning to correlate logs, metrics, and traces across monitoring and alerting systems. IT service management and SREs have been using AIops to reduce the mean time to resolve incidents and to perform accurate root cause analysis (RCA) efficiently. Agentic ops is the next wave of genAI operational capabilities, including tools for monitoring AI agents, managing their access rights, and detecting AI model accuracy drift.

 “AI is useful during major incidents because it can pull together a lot of context into a few clear sentences, which is exactly what an SRE needs in the moment,” suggests Shani Shoham, chief revenue officer at OpenObserve. “The complexity of architecture and the different tooling make it easier for AI than for a human, but autonomous resolution is still a way off.”

AI’s impact on people and burnout

The business pressure to keep systems up, secure, and performing well is a 24/7 stressful responsibility. According to The SRE Report 2025 from Catchpoint, 36% of SREs often or always experience elevated stress during an incident, and 28% said the stress persists even after the incident is resolved. AI capabilities may prove to be a game-changer in helping SREs avoid burnout and reduce stress.

“AI can improve RCA by taking in a much larger incident context than any engineer can hold at 3am, reasoning across traces, logs, metrics, deploys, config changes, alerts, ownership, and recent production behavior,” says Noam Levy, founding engineer and field CTO at Groundcover. “Beyond attempting a full RCA, its immediate value is distilling the signals that actually matter, reconstructing a clear timeline of cause and effect, and helping engineers separate correlation from likely causality. Once a fix is deployed, agents can also verify remediation by comparing pre- and post-fix behavior, but this depends on broad access to rich, correlated production signals and a cost model that does not discourage adoption or experimentation.”

Not only are incidents resolved faster and with less stress, but AI can also free up SRE time to focus on proactive work and create a career path for junior developers into SRE roles. Quais Taraki, CTO at EDB Postgres AI, adds, “AI reduces toil by automating repetitive tasks while accelerating incident resolution through copilots that correlate signals across distributed systems, allowing SREs to focus more on resilience strategies like chaos engineering and failure analysis.”

AI can have long-lasting operational impacts, especially for organizations looking to deploy more mission-critical technology and AI capabilities. Two longer-term benefits of AI for SREs are reducing the number of bridge calls needed for incident response and the number of engineers required in “war rooms” to coordinate root cause analyses.

“When something goes wrong, AI that guides SREs can do the full analysis, get to the root cause, and perform the remediation,” says Spiros Xanthos, founder and CEO of Resolve AI. “AI also helps avoid many escalations, and when escalations are needed, it targets the right people from the network, infrastructure, and the application teams. AI for SREs centralizes operational intelligence, exposes tribal knowledge, and can guide more junior developers.” 

AI agent reliability

While AI capabilities have been a net positive in helping SREs improve system reliability, the growth of AI code generators, vibe coding, and spec-driven development is adding to their workloads. According to one study, 41% of all global code is now AI-generated, and Gartner predicts that 40% of new enterprise production software will be created using vibe coding techniques by 2028.

But coding velocity is creating new issues for SREs as AI pull requests have 1.4 times more critical issues and 1.7 times more major issues, according to CodeRabbit. “AI-assisted development has created an unprecedented velocity of code reaching production, expanding surface area, edge cases, and failure rates faster than traditional SRE practices can absorb,” says Vinod Jayaraman, cofounder and CTO at NeuBird AI. “The speed of shipping has far outpaced the speed of understanding what breaks in production. To close this loop, SREs need enterprise agents that can capture precise diagnostic context, including correlated traces, service dependencies, and anomaly timelines, and structure it as actionable input for the engineers and AI coding tools responsible for the fix.”

The growing number of AI agents deployed to production creates new challenges. AI agents are not just code; they have multiple failure points. They are built using language models, connect to proprietary sources for context, and integrate with Model Context Protocol servers to support more complex workflows. Changes are ongoing and not deployment events, so the SRE’s job of identifying the source of performance and accuracy drifts isn’t trivial. 

“Traditional SRE was built for systems that fail in reproducible ways, but agents fail differently and drift when a model provider pushes an update, and behavior shifts silently with no baseline for comparison,” says Mohammed Aboul-Magd, vice president of product at SandboxAQ. “Most organizations can’t even answer the basics: how many agents are running, what they have access to, and whether they’re still doing what they were built to do.”

“Every time a senior engineer leaves, they take years of learned failure patterns with them, and the next outage starts from square one,” adds Ronak Desai, cofounder and CEO at Ciroos. “Using AI for compounding operational memory changes that, and every incident your system resolves, the AI learns it.”

SREs should take a leadership role in emerging best practices, including defining their standards for AI agent non-functional acceptance criteria, observability practices, and release-readiness criteria. SREs should update their service-level objectives (SLOs) and define error budgets for AI agents in production.

Ryan Downing, vice president and CIO of enterprise business solutions at Principal Financial Group, says, “Standard SLOs and error budgets give teams the guardrails, and AI helps interpret the telemetry against those targets, reducing noise so engineers can get to the real issue faster and automate parts of remediation before customers are impacted.”

AI raises the SRE’s business impact

The more dramatic shift in site reliability engineering is an evolution of its business scope. IT leaders focus on uptime, performance, and issue resolution, as well as understanding their impacts. Business leaders will look to IT and SREs to identify, determine root cause, and remediate a broader class of issues, including rogue AI agents and the impacts of rapidly deploying new agentic capabilities. 

“AI agents are handing SREs categories of problems they’ve never had to solve before, specifically failures defined in business terms, not technical ones,” says Blake Sherwood, distinguished technologist for AI and platform strategy at Smarsh. “Traditional reliability engineering is built around latency, errors, and crashes, but agents now fail due to skipped compliance steps or outcomes that looked fine technically but were wrong contextually. Most SRE teams aren’t wired for that yet.”

The question is whether SREs with AI-augmented tools can keep up with the velocity, complexity, and business urgency of deploying new AI business capabilities.

Every enterprise AI conversation seems to begin with the same question: Which model should we use?

I understand why. Models are visible. They have names, benchmarks, release notes, pricing pages and impressive demos. They are easy to compare in a leadership meeting. One model promises better reasoning. Another offers a larger context window. Another appears faster, cheaper or more specialized.

But after years of working around enterprise platforms, integration layers, cloud migration, middleware, production operations and mission-critical systems, I see the AI conversation differently.

The model matters. But it is not where most enterprises will struggle next.

The next AI bottleneck is the infrastructure behind the model.

I do not mean only GPUs, cloud capacity or data storage. I mean the full enterprise operating layer that allows AI to work safely in the real world: data pipelines, identity, APIs, messaging, observability, security controls, deployment automation, cost governance, auditability, support ownership and recovery design.

That layer is what determines whether AI remains an exciting experiment or becomes a trusted business capability.

Pilots hide the hard part

Most organizations can build an impressive AI pilot. A small team can connect a model to a dataset, create a workflow and show a use case that works well in a controlled setting.

The harder part starts when that pilot moves into a real production process.

That is when practical questions show up. Who owns the data quality? What systems can the AI access? How do we trace which prompt, policy or retrieval flow produced a specific answer? What happens when an API slows down, a queue backs up or a downstream system is unavailable?

To me, these are not model problems. They are infrastructure problems.

This is where many enterprises are now headed. The first phase of AI was experimentation. The next phase is operationalization, and that is where the real gap becomes clear.

McKinsey has made a similar point in its work on agentic AI, noting that the next phase of value depends less on isolated tools and more on redesigning workflows, operating models and enterprise execution around agents.

AI pilots can survive on enthusiasm. Production AI requires architecture.

AI is becoming an integration problem

The more I look at enterprise AI, the more it feels like an integration challenge.

In large organizations, I have seen how messaging platforms, integration gateways, deployment pipelines, monitoring tools and cloud infrastructure can decide whether a digital capability succeeds or fails. AI will be no different. Even the strongest model will struggle if the data, middleware, identity layer and operational controls around it are weak.

AI does not work in isolation. It needs context from systems of record, clean data from different business areas, secure access to APIs, event streams, workflows, knowledge repositories, monitoring tools and legacy systems.

That is why the CIO question is changing.

It is no longer just, “Which AI tool should we buy?”

It is becoming, “Can we safely operationalize intelligence across the business?”

This is where agentic AI matters. Autonomous AI only creates real value when the architecture around it can make its actions safe, traceable and useful.

A model can generate an answer. Infrastructure determines whether that answer is secure, timely, explainable, governed and connected to the right workflow.

For example, an AI assistant that summarizes customer or order information may look like a model use case. But underneath, it depends on access control, fresh data, reliable APIs, logging, encryption, monitoring and policy enforcement.

If the answer is wrong, people may blame the model. But the real failure may have started with stale data, weak integration, poor access design, missing observability or an unreliable downstream system.

That is why CIOs should not judge AI only by model capability. The enterprise system around the model matters just as much.

Latency will become a trust issue

In traditional technology operations, latency is often treated as a performance metric. In AI-enabled workflows, latency becomes a trust issue.

When an employee asks an AI assistant for help and the response takes too long, the employee stops using it. When a customer-facing workflow becomes slow, the customer abandons it. When an AI agent waits on multiple backend calls, the entire business process feels unreliable.

This becomes even more important as organizations move from simple chat interfaces to agentic workflows. A single AI-driven action may include identity checks, context retrieval, policy validation, model reasoning, API calls, business-rule execution, logging and human approval.

Each step adds latency. Each dependency adds a possible failure point.

A model may be fast in a benchmark but slow inside an enterprise process. That difference matters.

This is where platform engineering becomes essential. Enterprises need reusable patterns for AI workloads: approved connectors, secure retrieval methods, queue-based decoupling, caching strategies, deployment pipelines, monitoring dashboards and standard rollback procedures.

Without those patterns, every AI initiative becomes a custom build. Custom builds may work for pilots, but they do not scale across a large enterprise.

Observability has to expand

Traditional monitoring tells us whether infrastructure is healthy. Is the server up? Is CPU high? Is memory exhausted? Is the application returning errors?

AI needs that, but it also needs more.

We need to know what data was retrieved, which model was used, which prompt version was active, which user initiated the request, which policy was applied, how long each step took and whether the output passed validation.

We also need to detect new forms of risk: unusual usage patterns, repeated failed tool calls, unexpected cost spikes, sensitive data exposure, weak retrieval results or an AI workflow attempting actions outside its intended boundary.

In production AI, observability is not only about uptime. It is about confidence.

If a business leader, auditor, regulator or security team asks why an AI system made a recommendation, the answer cannot be, “The model said so.” The enterprise needs traceability. It needs evidence. It needs operational context that engineers, risk teams and business owners can understand.

This is one of the biggest gaps I see in AI strategy. Many organizations are investing in models and use cases, but not enough in the control plane required to manage them.

Data readiness is still underestimated

AI has exposed an uncomfortable truth: many enterprises are not as data ready as they think.

Data is often duplicated across platforms, described differently by each team, governed inconsistently and refreshed on different schedules. Access rules may be clear in one system but unclear in another. Even basic business definitions can change from department to department.

AI does not fix that automatically. In many cases, it makes the problem more visible.

A bad report may be questioned. A bad AI answer may sound confident enough to be trusted.

That is a real risk.

Being data-ready for AI is not just about connecting a vector database or indexing documents. It requires clear ownership, lineage, classification, quality checks, retention rules, access boundaries and a shared understanding of which data should be used for which purpose.

The same principle applies to resilient cloud-native design. In my IEEE TechRxiv paper, “Enabling Fault-Tolerant Multicast in Cloud-Native Architectures” I explored how reliability, observability and fault tolerance become foundational requirements when critical workloads stretch across hybrid and multi-cloud environments.

CIOs already understand this because they have lived through enterprise resource planning programs, cloud migration, integration modernization, cybersecurity transformation and analytics initiatives. The lesson is familiar: technology cannot outrun data discipline forever.

Security cannot be added later

As AI moves from answering questions to acting, security becomes much more important.

An assistant that summarizes information carries one level of risk. An agent that can open a ticket, update a record, trigger a workflow, approve a request or contact a customer carries a very different one.

The more AI can do, the more identity, authorization, least privilege, separation of duties and human approval matter.

Enterprises should be careful not to grant AI broad access just to speed up a pilot. That may seem harmless in development, but it can become dangerous at scale.

AI access should be treated like any other privileged enterprise capability: limited, logged, reviewed and easy to revoke.

The NIST AI Risk Management Framework is a useful reference point here because it frames AI risk as something organizations must govern, map, measure and manage continuously rather than something handled only at the end of deployment.

Security teams should be involved early, not at the end. The goal is not to slow innovation. The goal is to build a platform where safe innovation becomes repeatable.

The CIO has to define the operating model

AI is creating pressure from every direction. Boards want productivity. Business teams want automation. Employees want better tools. Vendors are pushing new features. Security teams are watching risk. Finance teams are watching cost. Customers expect faster, smarter experiences.

The CIO sits in the middle of all of it.

That is why the CIO’s role cannot stop at choosing tools or approving pilots. The CIO has to define how AI will actually operate across the enterprise.

That means answering practical questions. Which architecture is approved? Which data sources can be trusted? How are AI workflows deployed, monitored, supported and governed? How are costs controlled? How do teams reuse common patterns instead of rebuilding the same foundation each time?

This work may not be as exciting as a model demo, but it is what separates sustainable AI from short-term experimentation.

The winning organizations will not be the ones with the most pilots. They will be the ones with the strongest AI operating layer.

They will build reusable platform patterns, strengthen data governance, design access properly, monitor AI behavior end to end and measure success by business improvement, not only model performance.

The model still matters. But the enterprise behind the model matters more.

A powerful model on weak infrastructure will eventually disappoint the business. A capable model on strong infrastructure can deliver real value because it can be trusted, secured, scaled and improved.

That is the shift CIOs need to lead.

The next AI bottleneck is not the model. It is whether the enterprise behind the model is ready.

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

Dubbed the “Genius Hacker,” Park Chan-am began his white hat hacker journey at the precocious age of 11, winning awards at domestic and international hacking competitions since his teenage years.

He has since served as a cybersecurity advisor for various Korean government agencies, including the National Police Agency, and has played a key role in the country’s defense against Democratic People’s Republic of Korea (DPRK)-affiliated cyberattacks.

At a seminar held this month as part of the 15th Information Security Day event hosted and organized by government agencies including the Ministry of Science and ICT and the Korea Internet and Security Agency (KISA), Park, now CEO of security firm Steelion, explained the changes in the security environment in the AI ​​era and the priority response tasks for information security organizations under the theme of “Major AI Threats and Security Priorities.”

“While AI is a new technology, the core of security ultimately lies in access control, supply chain management, and human verification,” he said.

Like many security experts, Park sees AI fundamentally changing the speed of cyberattacks. In the past, infiltrating a corporate network required significant time analyzing a range of software systems to find exploitable vulnerabilities — a task that the use of AI has significantly accelerated.

“In the past, it took at least four weeks to find vulnerabilities, but now it takes less than a day,” he said. “In the era of AI, all software installed within a company becomes a much more critical target for attacks.”

As a result, securing internal software and the software supply chain are paramount — and require a different perspective on accountability, Park noted.

“Clients often ask, ‘Isn’t this just a product made by the vendor?’” he said. “From the moment it is installed in the company system, that software is no longer a vendor issue but part of the corporate system.”

“We are now in an era where third-party issues can no longer be attributed solely to vendor responsibility,” he stressed.

MCP under threat

Park also sees authorization management as a key challenge security teams will face in the agentic era. For example, companies have been increasingly utilizing Model Context Protocol (MCP)-based AI agents to read emails, analyze documents, and connect internal systems with various business tasks. But as the workload handled by AI agents increases, every step an AI agent takes, reading external documents and interacting with internal systems, can become a potential attack vector.

Prompt contamination through malicious documents and the leakage of internal information via agents with excessive privileges are quite realistic scenarios, Park said. In particular, he pointed out that issues that previously ended as minor problems, such as residual privileges left by former employees or outsourced personnel, could escalate into major incidents as AI automatically links these elements together.

“When introducing AI, permissions must be designed before functions,” he said. “The entire MCP process must be approached as a single attack path.”

The ever-widening blast radius of AI testing

Local AI testing environments are becoming a dangerous security blind spot that information security leaders often overlook. Rapid experimentation with open-source AI, such as LLaMA-based models, on personal or work PCs often results in servers or ports being left open, and if vulnerabilities are discovered, intrusion pathways immediately open up.

“When the [Ollama] remote code execution vulnerability was discovered in 2024, there were over 1,000 servers exposed to the internet, but recently in 2026, it has been confirmed that over 300,000 servers from the same targets are exposed,” said Park, adding that “the act of testing AI itself can become a new security risk.”

Vulnerability management on notice

Security operations must also change, Park stressed, noting that the number of alerts that security personnel must handle has increased tenfold, and in some cases up to a hundredfold, making it virtually impossible to respond to all vulnerabilities using the same standards.

As a solution, Park sees the Common Vulnerability Scoring System (CVSS) being insufficient for determining priorities. Instead, he suggested that vulnerability response priorities be determined by utilizing the Exploit Prediction Scoring System (EPSS), which predicts the actual likelihood of exploitation, along with the US government’s Known Exploited Vulnerabilities (KEV) list.

For example, if a vulnerability’s CVSS score is 7.5, it is not classified as critical, so it is likely to be pushed down the priority list. But the response priority changes completely if the same vulnerability is listed on the KEV list, has been exploited in actual ransomware attacks, and the probability of an attack based on EPSS has skyrocketed from 1% to 90% within two months. “You must consider these factors together to identify the vulnerabilities that actually need to be patched first,” he stressed.

“Amidst the vast noise known as the AI s​lop, the criteria for deciding what to patch first is now becoming a core competency for security personnel,” he added.

Park also presented new defense techniques applicable to the AI ​​era, such as methods to detect automated attacks by analyzing behavioral differences between humans and AI attackers, and proof of work (PoW) challenges that intentionally impose computational load on AI attackers to slow down their attacks. A prime example is filtering out abnormal access by analyzing mouse movements, keyboard input, and scrolling patterns.

“It is a more realistic strategy to reduce the burden on security teams by filtering out at least some attacks, rather than trying to block them 100%,” he said.

Even in the age of AI, technology alone cannot ensure complete security, he noted. “While AI can scan for threats broadly and quickly, verifying and confirming them ultimately falls to humans,” he said. “Humans are still important.”

Microsoft has issued a warning about a recent surge in ACR Stealer activity that uses ClickFix-style social engineering to steal credentials, browser data, and sensitive business documents.

In a new report, Microsoft researchers detailed two separate campaigns observed between late April and mid-June 2026 that use different execution techniques for the same theft.

The campaign was seen tricking users into executing malicious commands to resolve a fake issue. Once the malware is executed, it extracts browser-stored credentials, session tokens, and documents, which can potentially allow attackers to access cloud services, impersonate users, and conduct follow-on intrusions across enterprise environments.

Nick Tausek, lead security automation architect at Swimlane, thinks attackers could be using two distinct chains to trick defense tuned on individual indicators.  “By changing the delivery and execution patterns, attackers can evade defenses tuned to one known chain and make related incidents appear disconnected,“ he said. “Security teams may split the activity across separate investigations, delaying recognition of the shared malware and objective.”

ACR Stealer is an information-stealing malware family Microsoft believes is offered through a malware-as-a-service (MaaS) model, with possible links to the Amatera Stealer.

WebDAV and MSHTA-based chains

Although both campaigns begin with ClickFix lures, Microsoft’s analysis shows they diverge after initial execution. One attack chain uses WebDAV-hosted DLLs, PowerShell, Python loaders, scheduled-task persistence, and even blockchain-based infrastructure called the “EtherHiding” technique, to complicate detection and command and control (C2) discovery.

The second chain uses MSHTA, heavily obfuscated PowerShell, stenography, and predominantly fileless, in-memory execution to minimize forensic trails.

“The most troubling part of ACR Stealer is the flexibility surrounding the theft. One chain invests in persistence and layered infrastructure, while the other favors memory execution and fewer forensic traces,” Tausek said. “Those approaches look different to defenders, yet both turn a simple ClickFix lure into stolen credentials, tokens, and business documents.”

Microsoft researchers said protections against these campaigns have now been added to Defender. “Microsoft Defender for Endpoint can help surface both campaigns through behavioral coverage for living-off-the-land execution, suspicious WebDAV and MSHTA activity, obfuscated PowerShell, scheduled-task persistence, in-memory payload execution, and browser credential theft,” they said.

Mitigations include ClickFix-targeted detections

The report highlighted that neither of the campaigns exploits any software vulnerability, depending solely on ClickFix-based social engineering.

Microsoft warned its Defender customers that ClickFix attacks are on the rise and shared XDR queries to identify suspicious commands executed through ClickFix-based activity observed while delivering the ACR Stealer.

Microsoft also recommended, as general defense, monitoring for suspicious PowerShell activity, MSHTA execution, WebDAV connections, and attempts to access browser credential stores, while also enabling Microsoft Defender SmartScreen and Attack Surface Reduction (ASR) rules to block common malware delivery techniques.

“The campaigns do not need to directly aid one another to be effective. Together, they create ambiguity and stretch limited SOC resources,” Tausek explained. Security teams need enough visibility to correlate endpoint, identity, and network activity as one evolving intrusion, he added.

Microsoft also shared a list of C2 addresses and payload hosting domains for defenders to add to their detection.

Enterprise AI is entering a new phase. While the first wave of generative AI focused on human productivity and content creation, the next wave — agentic AI — will fundamentally change how organizations operate. Agentic AI systems are capable of reasoning, planning, making decisions and executing actions across applications, workflows and business processes with minimal human intervention.

As organizations move toward agentic frameworks that can independently resolve customer issues, optimize supply chains, manage infrastructure, coordinate workflows and even operate IT environments, one reality becomes clear: The network becomes the nervous system of the autonomous enterprise.

The infrastructure requirements of agentic AI differ dramatically from those of traditional applications. These systems are highly distributed, continuously exchanging information, interacting with APIs, accessing multiple data sources and making decisions in real time. The performance, security, visibility and adaptability of the network will directly determine the effectiveness of AI agents. Organizations that view AI readiness solely as a compute or data challenge risk overlooking one of the most critical enablers of future success — the network itself.

From AI-ready networks to autonomous networks

The long-term destination is the autonomous network: A network capable of self-monitoring, self-optimizing, self-healing and self-securing through the use of AI and automation. However, autonomous networking will not emerge overnight. The investments enterprises make today to support agentic AI are the same foundational building blocks required for tomorrow’s autonomous operations.

In many ways, agentic AI serves as both the driver and beneficiary of network transformation. AI agents require networks that can dynamically adapt to changing demands, while autonomous networks will increasingly rely on AI agents to manage and optimize themselves. The result is a reinforcing cycle where AI and networking evolve together.

The core characteristics of the network of the future

One of the most critical requirements for AI-ready networks is real-time observability and telemetry. Agentic AI thrives on context, and AI agents must continuously gather information from users, applications, devices, clouds, security systems and operational platforms. Future-ready networks must provide end-to-end visibility across campus, branch, cloud and data center environments. High-fidelity telemetry streams, real-time performance monitoring, application-aware analytics, AI-aware analytics and unified operational visibility are essential. Without comprehensive visibility, AI agents operate with incomplete information, limiting their effectiveness and increasing operational risk.

Another cornerstone is intent-based automation. Traditional networks are configured manually, often requiring administrators to define thousands of individual settings. In contrast, autonomous networks operate according to business intent. Enterprises increasingly need to define desired outcomes — such as maintaining application performance, optimizing user experience or automatically isolating compromised devices — rather than micromanaging configurations. The network continuously adjusts itself to achieve those objectives, providing the foundation upon which AI agents can make decisions safely and consistently.

Agentic AI also introduces entirely new traffic patterns that require AI-optimized connectivity. Large language models, retrieval systems, vector databases, cloud AI services, edge inference platforms and multi-agent orchestration frameworks create significant east-west and cloud-bound traffic. Future networks must provide low-latency connectivity, high-capacity fabrics, dynamic traffic engineering, edge-to-cloud optimization and policies that identify and prioritize AI workloads. The organizations that can move data efficiently will gain a competitive advantage in AI execution speed and responsiveness.

Security is another non-negotiable element. Agentic AI expands the enterprise attack surface because AI agents increasingly access sensitive systems, interact with APIs, consume proprietary data and execute actions across business environments. Future-ready networks must embed zero trust security into their architecture, with continuous identity verification, fine-grained access controls, microsegmentation, policy-driven authorization and continuous risk assessment. Security can no longer be bolted onto the network; it must be integral to its design and AI agents need to adhere to their own identity rules.

Finally, distributed intelligence across edge and cloud environments is essential. Many AI use cases require decisions to occur close to the source of data. Manufacturing systems, healthcare environments, retail operations, transportation networks and smart facilities often cannot tolerate the latency associated with centralized processing. Future networks must support edge AI deployment, distributed processing architectures, local inference, hybrid cloud operations and intelligent workload placement. The ability to move intelligence closer to users, devices and operational environments will become increasingly important as agentic AI expands across the enterprise.

Human expertise remains essential

Despite rapid advances in AI, the future will not eliminate the need for human expertise. In fact, it may increase its importance. One of the most significant misconceptions surrounding AI is that automation eliminates the need for skilled professionals. The reality is that autonomous systems require expert oversight, governance, validation and continuous optimization.

As AI systems become more capable, enterprises will need professionals who understand network architecture, security policy, AI governance, operational risk management, data quality, regulatory compliance and human-in-the-loop decision frameworks. The challenge is compounded by the unprecedented pace of AI innovation. New models, architectures, orchestration frameworks, security concerns and governance requirements emerge almost monthly. Most enterprise IT teams cannot be expected to independently evaluate every development while simultaneously modernizing infrastructure and maintaining day-to-day operations.

Organizations need access to experts who continuously track technology evolution, understand emerging best practices and can help translate innovation into practical deployment strategies. These experts provide not only implementation support but also ongoing operational guidance, helping enterprises maintain appropriate human oversight as AI capabilities expand. The future is not fully autonomous decision-making without people; it is intelligent automation operating under expert human governance.

5 actions enterprises should take now

Organizations should be preparing for the autonomous future right now. The following investments deliver immediate value while laying the groundwork for long-term AI transformation:

1. Modernize network observability. Establish comprehensive visibility across users, applications, devices, clouds and infrastructure. Rich telemetry and operational data will become the fuel that powers both Agentic AI and autonomous network operations.
2. Build an automation-first operating model. Identify repetitive operational processes and begin automating them. Automation maturity is a prerequisite for autonomous networking and creates the operational foundation AI agents will eventually leverage.
3. Adopt zero-trust principles across the enterprise. Implement identity-centric security controls, segmentation and continuous policy enforcement. As AI agents gain access to enterprise systems, security architectures must evolve to leverage the same identity controls.
4. Design for edge-to-cloud AI workloads. Evaluate network architectures for latency, bandwidth and resiliency requirements associated with distributed AI. Future AI deployments will span data centers, public clouds, branch locations and edge environments.
5. Invest in skills and strategic partnerships. Develop internal expertise while leveraging partners that possess deep networking, automation, security and AI knowledge. Human expertise remains one of the most important success factors in building AI-ready and autonomous infrastructures.

The road ahead

Agentic AI is poised to transform enterprise operations in much the same way cloud computing transformed infrastructure and the internet transformed business itself. But AI agents cannot operate effectively without a modern network foundation. The enterprises that succeed will recognize that AI readiness extends beyond models and data. It requires networks that are observable, automated, secure, intelligent and increasingly autonomous. The investments made today in AI-ready networking are not merely infrastructure upgrades — they are strategic building blocks toward the autonomous enterprise of the future, where AI agents and autonomous networks work together under human guidance to deliver unprecedented levels of agility, efficiency, and innovation.

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

For diversified enterprises, few operating model questions are as persistent or polarizing as centralization versus decentralization. Decentralization promises speed, ownership, and local responsiveness. Centralization promises efficiency, standardization, and leverage. Both can be right. Both can be wrong. The challenge is that many organizations end up with both models operating at once, without enough clarity about why.

The result of fragmented systems, duplicated capabilities, inconsistent data, rising IT spend, and a complexity tax that compounds over time is familiar to many CIOs. What starts as autonomy can become architectural sprawl. What starts as enterprise leverage can become bureaucracy. And as companies modernize core platforms, integrate data, and scale capabilities like AI, the tension becomes harder to ignore.

Paul Krebs has lived that tension from multiple vantage points. Most recently as CIO and chief transformation officer at Koch Industries, and previously a technology and transformation leader at The Coca-Cola Company, he’s worked in environments where business units value autonomy, enterprise scale matters, and the wrong operating model can slow progress just as easily as the wrong technology architecture.

His conclusion isn’t that CIOs should pick a side, but they need a more intentional form of centralization, one that starts with business architecture, clarifies decision rights, and continually revisits where capabilities should sit as the organization matures.

Centralization: a design choice, not a doctrine

In diversified organizations, decentralization often starts as the default because it aligns with how the business creates value. Local businesses understand their customers, markets, regulatory environments, and operating realities, and giving them decision rights can increase speed and accountability.

In Krebs’ experience, the default model often leaned toward decentralization, he says, with the belief that optimizing for customers and markets would allow different businesses to be as responsive as possible to the specific customers and markets they served. But that logic isn’t complete. Leaders also need to ask whether there’s a compelling case where a more centralized approach can generate additional value, accelerate progress, or optimize investments.

Digital transformation created one of those moments. Krebs recalls around 2016 when Koch challenged its businesses to build multi-year digital transformation roadmaps. The ambition was there, but the capabilities to execute at the necessary pace weren’t evenly distributed. In response, the organization invested more aggressively from the center, building shared services and centers of expertise in areas such as business transformation, enterprise applications, and data and analytics.

The purpose was acceleration, not control. Centralizing those capabilities helped accelerate learnings, capability building, and their ability to deploy new solutions at scale. But the move wasn’t treated as permanent. “There was always a belief that the centralization push should be re-looked at on a regular basis, not thought of as a forever decision,” he says.

Know what belongs at the center

Over time, Krebs learned that  the capabilities most likely to remain centralized were those where scale, consistency, and risk management mattered more than local differentiation. Infrastructure, collaboration platforms, cybersecurity, cloud management, FinOps, and the help desk were natural candidates to remain shared services.

Other areas were more nuanced. Some application capabilities moved back into the businesses as local maturity increased. Many data and insights capabilities also moved closer to the business once teams had built enough muscle to own them. Meanwhile, certain emerging capabilities such as spatial technologies like AR/VR remained centralized because it didn’t yet make sense for each business to build them independently. Many companies have lived this journey as well, for example, with gen AI, which often started with a center of excellence, and then evolved into a more decentralized approach, enabling teams across the business to innovate quickly.

That distinction avoids the trap of treating the enterprise as one uniform operating model. “Both models can be successful, and both have advantages,” he says. “That’s what makes the balance so difficult.”

Centralization provides a clearer path to execution at scale and cleaner decision rights, but it requires change management and careful attention to bureaucracy. Decentralization provides ownership and speed, but it can also over index toward preference versus real differentiation, he adds, while making architecture harder to scale later.

Don’t confuse standardization with centralization

One of the most important distinctions Krebs makes is between centralization and standardization. Many organizations treat them as interchangeable, but they’re not.

“You can have a centralized team that can manage the nuances of different requirements,” Krebs says. “You can also have a centralized standard platform that can be used in a decentralized manner.”

That distinction opens up more operating model choices. A company may centralize a platform but decentralize how business teams configure or use it. It may standardize process patterns while keeping execution close to the region or business unit. It may also centralize architectural governance while allowing local teams to move quickly within defined guardrails.

This is especially important in global organizations, where regional needs are real but not always unique. Krebs advises leaders to examine whether local requirements can be made more generic and reusable. The risk is solving each local requirement as a one-off, so the better path is to understand the underlying requirement, build it in a way that can scale, and still allow local teams to execute within the standard model.

Let business architecture lead technology architecture

Few topics expose the centralization tension more clearly than ERP consolidation. Many diversified companies, particularly those shaped by acquisition, end up with dozens or hundreds of ERP instances. Some leaders push for massive consolidation. Others prefer to build integration layers on top of the existing environment.

Krebs’s starting point is neither technology nor cost. It’s business architecture. “The easiest and most effective path is when the IT or systems architecture follows and aligns to the business architecture,” he says.

If the business is truly going to operate processes separately, separate systems may be appropriate. But if the organization has numerous teams, processes, and tools, leaders need to ask whether there’s enough differentiation and value to justify that complexity.

The same logic applies to M&A. Companies can get into trouble when integration synergies are held hostage by ERP migration timelines. Instead, Krebs advises starting with the business integration strategy. Understand where the synergies are, how the business architecture should come together, and then decide whether the IT architecture needs to be fully integrated, or whether a data layer, reporting platform, or other integration approach can deliver value faster.

Make the cost of complexity visible

CIOs in decentralized companies often face a frustrating dynamic. The business wants autonomy and speed, but the same leadership team still questions why IT spend is high relative to benchmarks. Krebs says the answer starts with cost alignment and visibility.

In environments with a mix of centralized and decentralized services, Krebs saw centralized capabilities like infrastructure, help desk, and security perform well on benchmarks. More decentralized areas, such as BI, reporting, and commercial applications, often had more redundancy and higher cost.

The point isn’t to blame the business but make the economics of complexity visible. CIOs need to show how flexibility in one area may require multiple systems, data stores, or teams elsewhere. “I understand we want flexibility here,” Krebs says. “But leaders must see when that flexibility may cost the company money, and be clear on whether the value justifies it.”

That shifts the conversation from IT cost to business service economics. A single aggregate IT spend number is rarely useful in a decentralized environment. More helpful is a capability-based view that shows which areas are scaled efficiently, which are fragmented, and where the business architecture is driving the technology cost structure.

Revisit the model as maturity changes

For a new CIO entering a decentralized environment, Krebs cautions against immediately declaring that too many things need to be centralized. The better starting point is curiosity. “I would begin with just trying to understand why they’ve made the decisions they have,” he says.

From there, CIOs can engage leaders in a conversation about the target operating model, connecting business architecture to technology, data, and organizational capabilities. Once the direction is clear, he advises CIOs to work with the willing. Find the parts of the organization that already see the need for change, prove the model there, and scale from demonstrated success.

Regardless of execution, though, the right model changes over time. A low-maturity capability may benefit from centralization because the organization needs to build talent, avoid reinventing the wheel, and accelerate learning. As maturity grows, decentralization may make more sense because business teams need flexibility to adapt quickly. Once maturity is high and patterns stabilize, the organization may be ready to centralize again to leverage scale.

“Once I’ve decided I’m going to start with centralized or decentralized, you don’t necessarily need to stay in that model,” Krebs says. “You need to be continually revisiting the operating model as your organization matures and evolves.”

That may be the heart of smart centralization. It rejects the false permanence of operating model decisions, and recognizes that autonomy and scale are both valuable, but in different places, at different times, for different reasons.