Providers and deployers of AI systems: You only have a couple of weeks left until you must explicitly inform users when they are interacting with AI content.

To assist in the effort, the European Commission (Commission) has published guidelines to help AI deployers get in line with the AI Act’s transparency obligations, which will begin to go into effect on August 2.

After that, companies providing AI systems must alert users when they are interacting with AI. They must also tell users when they have been exposed to deepfakes, “emotion recognition,” or biometric categorization systems, or when they are given AI-manipulated content in matters of “public interests without human review or editorial control.”

Henna Virkkunen, the Commission’s executive VP for tech sovereignty, security and democracy, said in a statement, “with today’s guidelines, the Commission supports the smooth and effective application of the AI Act to make AI systems interacting with people such as chatbots and AI agents and AI content more transparent and trustworthy. These guidelines support providers and deployers in meeting their obligations under the AI Act, while helping citizens know when they are interacting with AI.”

Systems must include machine-readable markers to reveal such content, to reduce “the risk of deception and manipulation” and build public trust in AI.

“Generative systems have collapsed the cost of producing convincing content while the cost of judging it stands where it always stood,” said Sanchit Vir Gogia, chief analyst at Greyhound Research. This requirement is “an attempt to restore friction to that imbalance.”

A company’s non-compliance could result in fines anywhere from €750K (about $856K) to €15M (about $17 million), or even up to 3% of its total worldwide annual revenue.

Transparency requirements

The EU AI Act’s transparency requirements apply to “natural or legal persons,” public authorities, agencies, or other bodies that develop AI systems, or have them developed, and place them on the EU market or into use under their name or trademark. This means all companies, regardless of whether or not they are EU-based.

“Systems placed on the European market, put into service there, or producing outputs used there are inside the field, wherever the developer sits,” Gogia noted.

Applicable systems must be intended to interact directly with “natural persons”; these systems include AI-enabled chatbots or conversational agents, AI companions, or coding agents. However, AI-enabled tools like recommender systems, spam filters, authentication, search and retrieval, transcription, text and code auto-completion, or predictive maintenance do not fall under the rule.

Specific outputs such as AI-generated text, images, video, and audio must contain a machine-readable mark. Deepfakes and public interest-related text created by AI without human review or control must be clearly labeled, however, deepfake content that is “artistic, creative, satirical, or fictional” is largely exempt.

AI content must be marked with one of three labels: “AI,” “Fully AI-generated,” or “Partially AI-modified.” For instance, “Fully AI-generated” applies when news summaries, music, art, or videos have been created without any human oversight (apart from prompting), while “partially AI-modified” could mean a person’s face is swapped into an authentic photograph to create a deepfake.

The three icons are publicly available for free use; enterprises can download zip files in PNG and SVG formats.

Most of the Act’s transparency rules begin to go into effect on August 2. But AI systems placed on the market before then will have some leeway; they must be in compliance by December 2.

However, a four-month allowance “on one obligation, for one population of systems, contingent on one procedural step, is not a strategy,” Gogia emphasized. Enterprises should plan to comply by August 2 and “treat any relief that arrives as margin.”

A consistent code of practice

Along with the transparency guidelines, the Commission has introduced a code of practice that essentially serves as a gesture of good faith. When signed, it can provide “legal certainty” and a “simple and practical” way to demonstrate compliance with the AI Act, according to the Commission. Signatories can also collaborate through the ‘Signatory Taskforce,’ which will share practices and advance technologies around marking and labeling practices.

Providers that choose not to sign must comply through other methods and demonstrate that those methods are “adequate” through assessment by surveillance authorities, according to the Commission.

Non-signatories “keep their flexibility, and will face more case-by-case scrutiny for it,” said Gogia.

Criteria for compliance

Shashi Bellamkonda, principal research director at Info-Tech Research Group, pointed out that the transparency requirements apply to content only when three criteria are met: It has been published, is informative to the public, or is on matters of public interest.

B2B business content or blogs may not need an AI disclosure if they do not meet these criteria, he noted. Also, published text that has undergone human review or is under editorial control does not need to be labeled. Editorial control means that a person must hold the ultimate legal responsibility for the publication of the content.

Many companies like Google, Adobe, and LinkedIn have already established ways to identify images marked as AI-generated. Meta has made it a requirement, but the creator has to add the AI-generated label, Bellamkonda said.

“This is a good move for guardrails around public information, and companies with good compliance and ethical oversight may not have to worry about this,” he noted. But as a general practice, companies should disclose AI-generated content and state whether it has been human reviewed.

Creating a transparency pipeline

Establishing full transparency means identifying who carries the responsibility for the content, whether the marking survives real use, not just testing, and what evidence will defend the decision, Gogia said.

Concerns cluster around responsibility, durability and evidence. Several organizations usually touch one piece of content, and none controls the whole chain, which is why contracts become the “pressure point,” he said. Most current agreements were written to deliver software and say “almost nothing” about provenance persistence, verification access, or evidence retention.

The durability concern is the most difficult, Gogia noted, because marking performs well in controlled settings but “badly in ordinary life.” Meta, for one, said its invisible watermark was designed to survive cropping; a published test, however, found the company’s preview detector missed 55% of cropped images.

“CIOs should ask which platform can actually provide evidence before believing its dashboard,” said Gogia.

Disclosure of AI use must be “clear, distinguishable and accessible,” he emphasized. “A notice buried in lengthy terms, or reachable only through determined clicking, satisfies nobody, least of all a market surveillance authority.”

Sustained compliance is a “living control” requiring a central record of systems, duties and evidence; testing taking place where the user meets the control rather than where the developer built it; and continuous supplier assurance. Enforcement will vary by country, so keep one common baseline with local overlays, Gogia said.

His advice: Inventory every system that talks to people, generates content, or gauges sentiment; classify provider and deployer roles; place disclosures at first interaction; define substantive human review; keep the evidence.

Marks and provenance signals should be tested after content undergoes cropping, compression, translation, transcription, and other editing, Gogia said. A useful audit starts from a real output and follows its “pulse” through generation, editing and publication, identifying at “each beat” the responsible party, the surviving mark, and evidence for exceptions. Missed labels should also be traced for root cause and recurrence.

To ensure compliance, before August 2, enterprises need a prioritized inventory, live disclosures on the highest-risk use cases, and a “named owner for every control,” he noted. In the first 30 days, they should stabilize and test; in the first 90 days, push requirements into procurement processes as a standing discipline. Procurement must secure commitments on marking methods, known failure modes, and evidence access, with explicit notice if/when any of them change.

“The sensible architecture is a common transparency baseline carrying traceability, responsibility, and evidence, with jurisdictional overlays for language, sector rules, and local practice,” Gogia said.

This article originally appeared on CIO.com.

A US federal court has approved Anthropic’s $1.5 billion settlement in a class-action lawsuit in which authors accused the AI company of using their books without permission to train the AI model Claude. This is the largest such settlement to date in a US copyright case, according to Reuters.

The dispute is one of several legal cases in which copyright holders sued AI companies over how large language models (LLMs) were trained, and it is the first major AI-related copyright dispute in the US to be resolved through a settlement.

A judge had previously ruled that the actual training of AI models using books falls under the “fair use” doctrine in US copyright law. But Anthropic was found to have violated the law by storing more than 7 million pirated books in a central library, regardless of whether they were later used for AI training or not.

OpenAI has launched Presence, an enterprise service for deploying voice and chat agents that can resolve customer and employee requests, potentially automating some work now handled by frontline support teams.

The agents can answer questions and operate IT systems, and enterprises can decide what actions the agents may take and when they should seek human approval for actions or transfer a case to a human.

OpenAI is already using Presence internally for its English-language phone support channel, where it verifies callers and uses account information to complete approved actions. The company said the system resolves 75% of inbound issues without human assistance.

Another OpenAI service, Codex, can be used to monitor agents and suggest updates or improvements to processes. In OpenAI’s own tests, suggestions from Codex helped reduce handoffs to humans by 15 percentage points over 10 days, it said. Presence also includes simulation and evaluation tools that allow companies to test an agent before deployment. The tests assess whether it reaches the correct outcome, follows company policy, and hands a case to an employee when required.

OpenAI intends each Presence deployment to deal with one kind of task, for example billing issues, insurance claims, or employee IT service requests, with agents getting only the knowledge and system access required for that task.

Presence is not a self-service product: Enterprises will have to sign up for the limited availability program, with integration performed by OpenAI or selected global systems integrators.

Companies exploring or testing Presence include Spanish bank BBVA, which is evaluating the service for everyday banking support in Mexico, and Japanese technology group SoftBank, which is using it in trials involving Japanese-language customer interactions. Australian insurer IAG is assessing whether the technology can help it respond to surges in customer demand during severe weather events.

Workforce impact

OpenAI’s announcement did not address the potential effect of Presence on employment. But its claimed automation rate raises questions about how the technology could affect staffing in customer service and other support functions.

Pareekh Jain, CEO of Pareekh Consulting, said CIOs should regard the 75% figure as evidence that the technology can work, rather than as a benchmark that every enterprise can expect to reach.

Jain said OpenAI’s deployment benefits from being built around the company’s own products and data. Large enterprises may achieve lower automation rates because they must contend with fragmented legacy systems, uneven knowledge bases and more complex compliance demands.

“Most organizations should expect lower initial automation levels that improve over time as the AI agent is refined,” Jain said.

The first workforce effect is more likely to be slower hiring than immediate layoffs, according to Tulika Sheel, senior vice president at Kadence International.

“The roles most exposed are likely to be repetitive, high-volume functions such as frontline customer support and routine back-office processing,” Sheel said. “However, I would expect the first impact to be on hiring and team growth rather than immediate large-scale job cuts. Over time, enterprises may redesign roles around AI-assisted workflows, with humans focusing more on complex cases, escalation, and relationship management.”

Jain said Tier-1 support agents handling predictable queries would face the most exposure. Broader reductions would become more likely only after companies reorganize their operations around the technology.

However, Lian Jye Su, chief analyst at Omdia, said Presence is unlikely to increase the threat of job displacement because companies have used similar customer-support automation from vendors such as Genesys, NiCE, Five9 and AWS for years.

Enterprises are more likely to use Presence alongside employees, with AI handling routine requests while people remain responsible for work requiring judgment and empathy, Su said.

Cost and operational risks

Analysts said CIOs should examine whether Presence can maintain resolution quality as usage grows, since fewer human handoffs could leave employees dealing with a more difficult mix of cases.

“The key question is not simply how many tasks AI can handle, but whether it can handle them reliably at scale,” Sheel said.

The financial case will depend partly on the cost of connecting Presence to existing systems and maintaining the controls needed to govern its use, according to Jain. “Often the biggest cost of enterprise AI is not tokens but integration and governance,” Jain added.

Companies will need to determine what systems and data the agents can access, monitor their performance, and audit the actions they take. Those investments could offset early savings.

Su said the complexity of enterprise IT will make it difficult for OpenAI to automate entire workflows on its own. Enterprises will still need to work with other technology providers and human employees, while CIOs will favor systems that can be audited and integrated with existing infrastructure.

Jain said the economics could improve if companies use the same integrations and governance controls across additional workflows.

This article first appeared on CIO.

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.

Every CIO I speak with today is wrestling with some version of the same question: How do we move faster with AI and deliver on our commitments?

It’s an understandable concern. Boards and CEOs are asking about AI. Business leaders are experimenting with use cases. Employees are discovering tools daily, while technology vendors promise unprecedented gains in productivity, innovation, and competitive advantage.

After hundreds of conversations with technology executives over the past year, I’ve become convinced that speed isn’t the real issue. The organizations pulling away from the pack aren’t necessarily adopting AI faster than everyone else. They’re executing more effectively — a subtle distinction that represents one of the defining leadership challenges of the AI era.

Technology has never been the hardest part of transformation. People, priorities, culture, and operating models are the biggest challenges. The ability to translate bold boardroom aspirations into thousands of thoughtful decisions made every day by architects, engineers, product managers, analysts, and business leaders is where competitive advantage is created. AI may be accelerating the pace of change, but it hasn’t changed that fundamental truth.

I’ve met plenty of executives who are exceptional in the boardroom. They know how to frame a vision, influence a board, and build confidence among investors and business leaders. I’ve also met remarkable technologists who instinctively understand the architectural decisions, engineering tradeoffs, and implementation details that determine how great ideas become reality. Modern CIOs, however, must move comfortably between both worlds. Afshean Talasaz is one who stands out among this rare breed.

Long before becoming CIO of Colonial Pipeline, Talasaz built his career from the ground up as a business professional, data scientist, and technologist. He has designed enterprise platforms, built AI capabilities, led technology organizations, and partnered closely with executive leadership teams on business transformation. Today, as an executive in residence with our Practitioners for Practitioners (P4P) community, he helps CIOs and business leaders navigate one of the most significant technology shifts of our generation.

While Talasaz brings deep knowledge of data and AI to the table, his greatest strength is his ability to create strategy and connect it with execution. He can spend the morning discussing enterprise reinvention with the board and the afternoon debating architectural principles with the teams responsible for bringing that vision to life.

That versatility gives Talasaz a unique lens on how CIOs can deliver value with AI.

Software companies have a term for engineers who understand every layer of the technology stack: full-stack developers. Listen to Talasaz and it becomes evident that the AI era requires something similar from technology leaders: a full-stack CIO.

The full-stack CIO: Leading with clarity

A full-stack CIO understands how every layer of the enterprise influences the next. They recognize that every strategic priority becomes a portfolio investment, every investment shapes an operating model, every operating model influences architecture, every architecture choice informs product decisions, every product decision shapes engineering priorities.

The best CIOs understand both ends of that journey. The extraordinary ones understand everything in between.

And those who execute best lead with clarity, Talasaz says.

“Everyone, from executives to middle managers to the people writing code, should be able to explain what we’re trying to achieve,” he emphasizes. “Clarity isn’t that we’ve handed out the PowerPoint. It’s that people genuinely understand where we’re going and can articulate it in their own language.”

One of the unintended consequences of the AI boom is that organizations are beginning to confuse activity with alignment. They have AI councils, AI governance committees, AI innovation labs, AI centers of excellence, AI pilots, and AI roadmaps. Yet if you stop ten people in the hallway and ask a deceptively simple question, What business problem are we actually trying to solve? you’ll often hear ten different answers.

As a result, architects optimize for one objective while product teams optimize for another. Business units pursue opportunities that seem perfectly reasonable from their perspective. Engineers make thoughtful technical decisions based on the information available to them. Individually, none of those decisions are necessarily wrong. Collectively, however, they create organizational drift. AI doesn’t create that problem. It simply accelerates the consequences.

And while AI can be a force multiplier for the positive when every decision is guided by a shared understanding of where the organization is headed, it can also be a force multiplier for the negative, resulting in an organization simply moving faster in different directions.

“When we have the fundamentals right, the tech infrastructure, the operating models, the nuances of how our business actually runs, we get the impacts of AI in a positive way,” Talasaz says. “When we don’t have those in place, AI can amplify the gaps or mute the benefits.”

At a time when so much of the conversation surrounding AI is focused on algorithms, agents, and automation, it’s an important reminder that organizations don’t execute strategy; people do.

Reducing organizational friction

Most executives are familiar with the concept of VUCA that characterizes today’s business environment. But Talasaz stresses the importance of turning this concern inward: “If the world outside our organizations is becoming more volatile, uncertain, complex, and ambiguous, what are we, as leaders, doing to the inside of our organizations?”

Leaders spend enormous amounts of time helping their organizations respond to external disruption but comparatively little time asking whether they are inadvertently re-creating those same conditions internally in response to those external needs. Are we reducing uncertainty or introducing more of it? Are we simplifying work or adding unnecessary complexity? Are we helping people focus on what matters most, or asking them to navigate competing priorities and shifting expectations?

Talasaz refers to this phenomenon as double VUCA — something I’ve witnessed repeatedly while working with CIOs over the past decade. Organizations often assume they’re struggling because of technology limitations when the real constraint is organizational friction. Teams wait for decisions. Priorities shift faster than roadmaps. Governance grows heavier. New committees are formed to solve problems created by existing committees. Everyone is working harder, yet the organization somehow feels slower.

AI amplifies both outcomes. Organizations with clarity become dramatically more effective because AI accelerates good decisions. Organizations without clarity simply accelerate confusion.

Operating model as strategy enabler

AI governance is one way to achieve greater clarity, but as Talasaz says, governance shouldn’t primarily exist inside policy manuals that few people read.

Instead, AI governance should be embedded in the daily rhythms of the organization, shaping how teams collaborate, how decisions are made, how products move from ideas into production, and how innovation happens safely without requiring constant escalation. In other words, it’s all about your operating model.

“If you had to pick one thing that isn’t technology, your operating model is the most important element for executing data and AI at scale,” he says.

The best operating models create enough clarity that capable people can make thousands of decisions independently and confidently, without having to wait for permission. By embedding good governance into the way it works, the organization becomes faster.

This advice echoes something I’ve heard repeatedly from some of the world’s most respected CIOs: High-performing organizations aren’t built on tighter control; they’re built on greater trust, supported by clear principles, shared expectations, and operating models that enable responsible decision-making at every level of the enterprise.

Talasaz points out that technology leaders tend to speak in terms of transformation. He suggests CIOs consider a different word: reinvention.

As he explains, transformation implies replacing what exists today with something new. Reinvention starts with a more clear-eyed and practical premise: Some things absolutely must change; others represent years, sometimes decades, of accumulated expertise, customer trust, operational discipline, and competitive advantage.

Reinvention is about building on those strengths while also creating new ways to deliver value. The leaders making the greatest progress in their AI journeys seem to recognize that it’s less about abandoning the past than thoughtfully preparing the organization for the future.

Closing the gap between strategy and execution

Full-stack CIOs must be able to map out the various layers of execution and planning that need to be done at every level of the organization to be successful. To help with this, Talasaz has developed a data and AI framework that draws on his own experiences “from the keyboard to the boardroom.”

As Talasaz sees it, too many organizations have been doing good work in isolation. “They’re doing a lot of the right things,” he says. “They’re just not connected.”

Boards may be discussing growth while business leaders redesign customer experiences. Product teams may be prioritizing new capabilities while architects modernize platforms. Data teams may be improving quality while engineers focus on delivery. Every group makes meaningful progress within its own domain, yet somewhere between strategy and execution, the connective tissue begins to disappear. Talasaz’s framework brings those connecting points to the forefront.

Crucially, the framework doesn’t begin with technology or AI or even with data. It begins with the experiences the organization hopes to create for its customers, employees, or partners. Many AI initiatives start with the question, “What can this technology do?” And indeed, we need to be inspired by the possibilities and challenged to think differently by what the technology can do. But, Talasaz emphasizes, we also need to ask what experiences we need to deliver for our business and how the technology can make that a reality.

The framework challenges CIOs to answer that question first. Only after the experiences are clearly defined does the conversation move to the capabilities required to deliver it, the business activities that support those capabilities, the AI and data products that enable them, and finally the data foundation that makes everything possible.

This shift in perspective ensures that, rather than allowing technology investments to search for business value, the business experience defines the technology required to deliver it. For CIOs, that’s more than a planning exercise. It’s a fundamentally different way of leading.

Over the coming months, the P4P community will be convening a series of small CxO roundtables to explore these issues and work more deeply with Afshean Talasaz’s 6×6 Data and AI Framework. CIOs and other enterprise leaders interested in participating are welcome to reach out to me directly.

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

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

The 5 layers of public-sector control

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

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

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

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

Evaluating risk: Concentration, jurisdiction and shadow AI

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

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

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

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

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

Building an operational sovereignty strategy

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

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

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

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

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

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

When it comes to building an effective AI stack, context is king and power isn’t everything it’s cracked up to be.

“Smaller, smarter, safer — this is a bet our company has taken in how we deploy AI internally,” said Ricky Thakrar, head of sales and account management at Zoho, provider of a suite of popular cloud-based software solutions for sales, marketing, and finance.

“I’m on the business side, and so decisions made by our CIO and IT folks affect me directly, and my teams’ workflows and processes,” he added.

Speaking to a room of tech leaders at the CIO 100 Leadership Live New York event last week, Thakrar explained that every company wants the speed of AI-generated work wedded to the quality of human work, even though these two are diametrically opposed. No amount of model upgrades or spend will close that gap, so the only way forward is to architect your way out. Thakrar encapsulated this idea in a simple formula:

• Smaller: Stop deploying maximum firepower on every task. Many tasks don’t need it.
• Smarter: The system around the model decides more than the model does.
• Safer: Verify at the point a mistake gets locked in, not just downstream of it.

He noted that organizations that win with AI won’t be those deploying the biggest, most powerful models or the most sophisticated architecture, but the ones that figure out that the model is the easy part and the right architecture is harder. That means understanding the hardest element, and the biggest differentiator, is building a human system that learns and compounds alongside agentic systems.

To get it right, organizations need to prioritize the context layer. The size of frontier models like the GPT series, Claude, and Gemini mostly exist to compensate for missing context, Thakrar explained. Without enough context, models need to be able to reason harder and infer more about what a user actually means because it doesn’t know the user’s account, process, or history. A rich context layer makes it possible for enterprises to run workloads on much smaller, lower-power models.

“The intelligence moves from the model into the architecture around it,” he said.

A steep learning curve

One of Zoho’s earliest AI agents was a churn management agent to help the account management team detect churn in customer subscriptions. So when a subscription became inactive, the agent would collect context from notes, meeting recordings, and Zoho’s data enrichment tool, then create a summary of reasons the account might have churned, and schedule a call.

“What happened was I got this churn agent a couple months later, already embedded in our CRM, and within a week my team no longer trusted that agent,” Thakrar said. “The reason is we forgot to collect one very key point.”

In Zoho’s CRM, when a customer buys a bundle of products, that bundle is represented as a single line item. That means the status of any products the customer may have previously purchased individually changes to inactive as they’re moved to the bundle. That’s not churn, but it was interpreted it that way. Zoho fixed it in the second version of the agent.

Then a new problem arose. Many potential customers first purchase Zoho products as pilots or sandboxes. As those customers move from pilot to live instance, they close down the pilot versions. And again, the CRM would record that as subscriptions going inactive.

“The trust deteriorates again because everyone got excited for version 2,” Thakrar said.

Sometimes, a certain product might not be the best fit for a customer and Thakrar’s team will suggest the customer move to another product. That’s deliberate churn, not a churn risk.

“You may have a similar story like this where the agent sounds so good, it’s going to do something quick and add value, but it’s missing context from the account managers, and there are so many more pieces we’re still building out,” Thakrar said. “It’s been almost a year and the problem I have is my team still doesn’t trust it. They’ll see [a message from the agent] and go out and do all the research anyway to make sure it gave the correct answer.”

The team is more on top of potential churn, though, but the promised productivity gains have yet to materialize because the agent has to earn back lost trust due to a lack of context.

“My goal for this year is having an AI-assisted customer journey from sales to account management where the handoff is clean, the context flows, and every piece of information we gather about a customer is weighed, identified, and coached so the sales team can close more deals,” he said.

Zoho’s early experience with agents has led to the idea that constrained, context-rich, deterministic architectures consistently outperform expensive models bolted onto fragmented systems. It all comes down to three pillars: routing, harness, and specialization.

Routing

Routing is about sending workloads to the proper model for the job, which entails providing enough context to a given task that a small, cheap model can handle it without the need for spare reasoning capacity to fill gaps.

Frontier models are expensive and companies can burn through a year’s budget worth of tokens in months. But most tasks can be handled by much smaller, more constrained models at a fraction of the cost.

“You don’t always have to pay the frontier guys for every task,” he said. “We’ve observed with some clients that we could save them 95% with a 3 billion parameter model.”

Harness

An AI agent harness is the software infrastructure scaffolding around an LLM that differentiates an agent from a chatbot. It’s what enables an agent to act on tasks rather than simply respond to prompts. A model reasons through a problem and decides what to do about it. The harness connects the model to the tools, systems, memory, guardrails, and execution environments required to perform the actions determined by the model. The term is frequently used more or less interchangeably with orchestration layer.

“It’s the process around the model, which matters way more than the model itself,” Thakrar said.

In benchmark tests, a superior harness on a less powerful model produces better results than an inferior harness on a much bigger model.

For the best results, Thakrar said, it’s essential to understand the deterministic and non-deterministic elements of a given workload, and build that into the architecture. Machines can read, organize, and validate, and they excel at deterministic tasks. Humans, on the other hand, are exceptional at non-deterministic tasks like judging, synthesizing, and deciding.

Those non-deterministic tasks in a process are the ideal point for AI agents to incorporate a human in the loop, what Thakrar calls human harness. He pointed to a stakeholder mapping agent Zoho built for sales as an example, which takes the context of an initial meeting and third-party enriched data like a LinkedIn profile, weighs probabilities, and makes an educated guess about the stakeholder map.

“The initial goal was just to eliminate that task completely from the human workflow,” he said. “The stakeholder map is done, it’s in the folder, and you can look at it.”

But the agent would struggle to capture nuance. The meanings of titles in organizations always vary, and the politics and dynamics of any given meeting can be difficult for an AI agent to discern. Rather than keep feeding the agent data to try to make it intelligent enough to make those determinations, it was simpler and more efficient for the agent to create a proposed stakeholder map and hand it over to a human who could make changes and explain why those changes were necessary.

Ultimately, Thakrar said the agent still saved human team members time because the stakeholder map was usually pretty close, and the corrections also helped the model grow smarter by adding richer context.

Specialization

Specialization is transitioning a process from testing on a frontier model to production on a much narrower, smaller model. Once you’ve proven that an agent can do a job well, you want to stop paying master-craftsman rates to keep doing that one job well.

Specialization is all about capturing your subject matter experts’ best judgement and pattern recognition to build an open-weight, open source, trained, and fine-tuned model that can be deployed in your own data center.

“The true enterprise bet is to keep that orchestration layer, which is your IP and knowledge, in house,” Thakrar said. “You don’t want to host that on someone else’s model. The goal of everyone in enterprise should be to run, train, and host their own models.”

Over the past few years, I have learned that basic prompts produce inconsistent, hallucination-prone results that no executive would trust in production. What turned the tide was my move to advanced prompting techniques. These weren’t theoretical experiments; they became a practical foundation for reliable, measurable outcomes. I want to share the techniques that consistently delivered the biggest gains in my projects, complete with real before-and-after examples, copy-paste templates, lessons from failures and guidance on when to evolve beyond prompting to agentic systems.

Why advanced prompting still matters in enterprise settings

Sophisticated prompting remains essential for control, reliability and compliance. If you “ask nicely” and hope for the best, you need deterministic behavior, auditable reasoning and minimal risk of hallucination. Here’s what worked for me.

1. Chain-of-Thought (CoT) and its variants: Unlocking step-by-step reasoning

The problem: Models would jump to conclusions on complex analysis tasks, especially involving data interpretation or multi-step logic.

What I did: I started explicitly instructing the model to “think step by step” and show its reasoning.

Before (basic prompt): “Analyze last quarter’s sales data and recommend three actions.”

After (CoT prompt):

“You’re a senior business analyst. Analyze the following sales data step by step: [data]. First, identify the key trends. Second, calculate the rates and anomalies. Third, link findings to business context. Finally, recommend the three prioritized actions with expected impact. Explain your reasoning at each step.”  

Results: Accuracy and depth improved dramatically.

Variants that worked well: Self-consistency. I ran the same CoT prompt multiple times and took the majority consensus. This reduced variability significantly.

Template you can use:

You are [expert role]. Solve this problem by thinking step by step.

[Task or question]

For each step:

1. State your observation or calculation.

2. Explain the implication.

3. Proceed only when confident.

Final answer in this format: [structured output]

2. Tree-of-Thoughts (ToT): Exploring multiple reasoning paths

For truly complex decisions such as resource allocation or risk assessment, linear CoT isn’t enough. Tree-of-Thoughts lets the model generate and evaluate multiple branches.

Example: I was helping a client evaluate three potential vendor platforms for an AI deployment. A standard prompt gave a superficial comparison. With ToT

Prompt Snippet:

Explore three different reasoning paths for selecting the best vendor platform:

Path 1: Focus on cost and scalability.

Path 2: Focus on security, compliance and integration.

Path 3: Focus on innovation and long-term roadmap.

For each path, evaluate pros/cons against our requirements [list].

Then, compare the paths and recommend the strongest overall option with justification.

Outcome: The model surfaced nuanced trade-offs (e.g., one vendor had superior security, but higher integration cost).

When to use: Strategic planning, troubleshooting or scenarios with high uncertainty and multiple viable approaches.

3. ReAct (Reason+ Act) and prompt chaining: Moving toward agentic behavior

One of the biggest leaps I have noticed comes from combining reasoning with tool use and chaining prompts.

ReAct example: (used in data analytics workflow)

You are an AI analyst with access to tools. For the query below:

1. Reason about what information you need.

2. Choose the appropriate tool or action.

3. Observe the result.

4. Repeat until you can answer confidently.

Query: [user request]

In practice, I chained this with retrieval tools. One automated quarterly compliance reporting; the system reasoned about required data, pulled relevant records, validated them, and generated the reports.

4. Meta-prompting and self-reflection: Letting the model improve itself

Use the model to refine its own prompt. This is a huge time-saver.

You are an expert prompt engineer. Improve the following prompt for clarity, structure and effectiveness with [target model]. Make it more precise while preserving intent.

Original prompt: [paste]

Provide the improved version and explain your changes.

Self-reflection loops (asking the model to critique its own output and revise) are a game-changer for content generation and code-review tasks.

5. Multimodal and structured output techniques

With vision-enabled models, I started combining text with images (e.g., uploading architecture diagrams or dashboards).

Tip from experience: Be extremely specific in describing what the models should focus on.

Best practices I learned the hard way

• Start simple, then layer complexity: Over-engineered prompts from Day One usually backfire.
• Model specific tuning: Some models respond better to XML delimiters; others to explicit reasoning.
• Evaluation and versioning: Treat prompts like code if you track versions and run automated evals.
• Security guardrails: Always include instructions against prompt injections and respect data boundaries.
• When to stop prompting: For repetitive, high-stakes workflows, move to full agents or an orchestration framework.

Final takeaways for technical leaders

Advanced prompt engineering has now become a core competency for anyone responsible for enterprise AI outcomes. Start by picking one technique and apply it rigorously to a real business problem. Document before/ after and you will notice why it’s worth mastering.

The field continues evolving towards more automated and agentic systems, but the ability to precisely direct AI reasoning remains foundational.

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

Google CEO Sundar Pichai has sought to allay concerns over the delayed release of the Gemini 3.5 Pro large language model. He dodged questions about it in Google’s quarterly earnings call on Wednesday by focusing on the company’s next frontier AI model, Gemini 4, and plans to release subsequent LLMs at an almost monthly cadence.

His comments came a day after Google unveiled Gemini 3.6 Flash and 3.5 Flash Cyber but offered no update on the release of Gemini 3.5 Pro, the company’s delayed flagship reasoning model that many developers had expected to arrive weeks earlier.

Google introduced the Gemini 3.5 family at its annual I/O conference, promising to release the Pro model in June. That timeline has since slipped, with Bloomberg suggesting Gemini 3.5 Pro is months late because the model’s coding performance is falling short of internal expectations, especially when compared to better performance by similar models from OpenAI and Anthropic.

Instead of revisiting the Gemini 3.5 Pro timeline, Pichai used the earnings call to shift the discussion toward Gemini 4, when asked about how his company planned to navigate an increasingly competitive race to release frontier AI models by to Barclays Investment Bank analyst Ross Sandler.

“We are creating a baseline on top of which you will see us rapidly iterate on subsequent model releases. And so picking up pace and releasing models almost at a monthly cadence is part of our road map as we are building Gemini 4 as well,” Pichai said during the call.

Sandler’s question followed one from JPMorgan Chase & Co analyst Douglas Anmuth, who asked Pichai if Google was releasing frontier AI models frequently enough to keep pace with rivals OpenAI and Anthropic.

Pichai had responded to Anmuth’s question that Google remained confident of competing at the frontier and was investing heavily in a larger Gemini 4 base model.

Analysts, though, aren’t as confident as Pichai.

While delays to Google’s frontier model roadmap have not triggered an exodus of existing customers, either because of high switching costs or because many enterprises already running multi-model architectures, they have made CIOs evaluating AI platforms more cautious about making new commitments, said Bhupendra Chopra, chief revenue officer at IT consulting firm Kanerika.

A monthly model release cadence could prove to be a double-edged sword for enterprises and their CIOs.

While a monthly release cadence could help enterprises gain faster access to improvements in model performance, cost and capabilities, it will also require CIOs to invest more heavily in testing, governance and version management to safely adopt those updates, said Sanchit Vir Gogia, chief analyst at Greyhound Research.

Similarly, Pareekh Jain, principal analyst at Pareekh Consulting, said enterprises will embrace a faster release cadence only if each successive model delivers measurable improvements in performance, cost or safety, rather than simply changing version number.

The challenge for CIOs, Jain said, is not just keeping up with model releases; it’s deciding whether each new version is worth the cost of validating it.

This article first appeared on InfoWorld.

OpenAI has launched Presence, an enterprise service for deploying voice and chat agents that can resolve customer and employee requests, potentially automating some work now handled by frontline support teams.

The agents can answer questions and operate IT systems, and enterprises can decide what actions the agents may take and when they should seek human approval for actions or transfer a case to a human.

OpenAI is already using Presence internally for its English-language phone support channel, where it verifies callers and uses account information to complete approved actions. The company said the system resolves 75% of inbound issues without human assistance.

Another OpenAI service, Codex, can be used to monitor agents and suggest updates or improvements to processes. In OpenAI’s own tests, suggestions from Codex helped reduce handoffs to humans by 15 percentage points over 10 days, it said. Presence also includes simulation and evaluation tools that allow companies to test an agent before deployment. The tests assess whether it reaches the correct outcome, follows company policy, and hands a case to an employee when required.

OpenAI intends each Presence deployment to deal with one kind of task, for example billing issues, insurance claims, or employee IT service requests, with agents getting only the knowledge and system access required for that task.

Presence is not a self-service product: Enterprises will have to sign up for the limited availability program, with integration performed by OpenAI or selected global systems integrators.

Companies exploring or testing Presence include Spanish bank BBVA, which is evaluating the service for everyday banking support in Mexico, and Japanese technology group SoftBank, which is using it in trials involving Japanese-language customer interactions. Australian insurer IAG is assessing whether the technology can help it respond to surges in customer demand during severe weather events.

Workforce impact

OpenAI’s announcement did not address the potential effect of Presence on employment. But its claimed automation rate raises questions about how the technology could affect staffing in customer service and other support functions.

Pareekh Jain, CEO of Pareekh Consulting, said CIOs should regard the 75% figure as evidence that the technology can work, rather than as a benchmark that every enterprise can expect to reach.

Jain said OpenAI’s deployment benefits from being built around the company’s own products and data. Large enterprises may achieve lower automation rates because they must contend with fragmented legacy systems, uneven knowledge bases and more complex compliance demands.

“Most organizations should expect lower initial automation levels that improve over time as the AI agent is refined,” Jain said.

The first workforce effect is more likely to be slower hiring than immediate layoffs, according to Tulika Sheel, senior vice president at Kadence International.

“The roles most exposed are likely to be repetitive, high-volume functions such as frontline customer support and routine back-office processing,” Sheel said. “However, I would expect the first impact to be on hiring and team growth rather than immediate large-scale job cuts. Over time, enterprises may redesign roles around AI-assisted workflows, with humans focusing more on complex cases, escalation, and relationship management.”

Jain said Tier-1 support agents handling predictable queries would face the most exposure. Broader reductions would become more likely only after companies reorganize their operations around the technology.

However, Lian Jye Su, chief analyst at Omdia, said Presence is unlikely to increase the threat of job displacement because companies have used similar customer-support automation from vendors such as Genesys, NiCE, Five9 and AWS for years.

Enterprises are more likely to use Presence alongside employees, with AI handling routine requests while people remain responsible for work requiring judgment and empathy, Su said.

Cost and operational risks

Analysts said CIOs should examine whether Presence can maintain resolution quality as usage grows, since fewer human handoffs could leave employees dealing with a more difficult mix of cases.

“The key question is not simply how many tasks AI can handle, but whether it can handle them reliably at scale,” Sheel said.

The financial case will depend partly on the cost of connecting Presence to existing systems and maintaining the controls needed to govern its use, according to Jain. “Often the biggest cost of enterprise AI is not tokens but integration and governance,” Jain added.

Companies will need to determine what systems and data the agents can access, monitor their performance, and audit the actions they take. Those investments could offset early savings.

Su said the complexity of enterprise IT will make it difficult for OpenAI to automate entire workflows on its own. Enterprises will still need to work with other technology providers and human employees, while CIOs will favor systems that can be audited and integrated with existing infrastructure.

Jain said the economics could improve if companies use the same integrations and governance controls across additional workflows.

I have worked alongside enterprise technology for more than 30 years and watched AI evolve from a lab experiment into the modern boardroom’s core focus. However, the last few years of implementing AI alongside our customers have delivered our most profound reality checks.

The initial hype has faded, leaving CIOs to drive real enterprise value. Based on my experience implementing Google, OpenAI and Anthropic technologies, here are the fundamental, technology-agnostic lessons every leader must anchor their strategy around.

AI as a leadership multiplier

The most common tactical error we see is treating AI as an isolated technology project. What I have observed among our customers is that true success does not come from organizations that define a standalone “AI strategy,” but rather from those leaders that integrate AI into their business strategy.

When our customers isolate AI and define an AI strategy, it inevitably treats it like a “technological toy” to experiment with. This approach yields fragmented, orphaned initiatives that fail to scale because they are fundamentally disconnected from their core corporate objectives. What I learned is that AI is not the ultimate destination; it is a powerful catalyst. We have replaced “What can AI do for our customers?” with a more strategic question, “How does AI accelerate their existing business goals?”

Think of AI like electricity. No modern corporation designs a standalone “electricity strategy.” Instead, all companies route it invisibly across the entire organization to illuminate offices, power production lines and drive communication. AI must be woven into the enterprise fabric in the exact same way, acting as an underlying utility that supercharges your existing operational model.

Integrating AI into the broader business strategy also dictates how we measure success. It forces a shift away from short-term tech vanity metrics and anchors the technology into a long-term roadmap.

When AI remains trapped within the IT department of our customers, we notice that it is relegated to a mere “software experiment.” To become a true competitive advantage, we observed that AI requires intense cross-functional orchestration. This perspective does not diminish the merit of the technical team; their expertise is fundamental for establishing the architecture, data governance and tools your enterprise requires. However, while IT builds the foundational infrastructure, it lacks the organizational authority to decide what should be built on top of it. Only the CEO or the owner of the company can step in to ensure AI leaves the “toy project” phase and integrates into the DNA of the organization.

The requirement for top-down, executive ownership stems from three critical realities observed in the field:

• Silo-smashing and data collaboration: True enterprise AI is data-hungry and that data lives across disparate business lines, finance, operations, marketing and customer service. Only the CEO possesses the cross-functional authority to demand that data silos be dismantled.
• Cultural transformation and fear mitigation: AI triggers widespread anxiety over job displacement across all industries and hierarchies. When relegated to an “IT project,” resistance spikes as teams view it as a threat to their livelihoods. When I saw the CEO lead this cultural shift directly is when I noticed the best results.
• C-Suite education and strategic alignment: The mandate for AI capability cannot just be delegated downward; the transformation must begin at the very top. I have conducted more than 70 presentations for the Board of Directors and C-Level teams. These people need to be actively educated not on technical code, but on specific business use cases, return on investment (ROI) frameworks and how AI resolves core organizational bottlenecks.

PwC’s data found that only 12% of enterprises have achieved both cost and revenue benefits from AI. Those elite 12% succeeded precisely because their CEOs embedded AI extensively across strategic decision-making and cross-functional workflows. AI is simply too disruptive and too critical to be left exclusively in the hands of technical experts. If AI is not on the CEO’s weekly agenda, it is fundamentally missing from the company’s true strategy.

AI as a new operational framework

Traditional IT systems have operated on strict algorithmic certainty: if you input a specific set of data, the system executes an immutable line of code and guarantees the same, predictable output every single time.

AI completely breaks this paradigm. Because modern AI is built on probabilistic models, it does not execute static formulas; instead, it predicts the most likely correct response based on mathematical probabilities. This means that AI solutions carry an inherent, small percentage of uncertainty and variability. A prompt entered today might yield a slightly different, though contextually valid, output tomorrow.

Executive leadership and organizational cultures must be actively educated to accept and navigate this fundamental shift. Traditional quality assurance frameworks for software are designed for a 100% success rate. Applying this rigid standard to AI will paralyze your initiatives, keeping 80% of your projects trapped eternally in the pilot phase. This happened to us in a food and beverage company in Latin America a couple of years ago. After this experience, we started to include conditions in our contracts that tolerate statistical margins of error and still define the project as a success.

In terms of cost calculation, we had to teach CIOs and business managers to forget the monthly subscription model for AI and learn to manage the primary unit of exchange in modern AI: the token.

To understand AI costs, executives must understand how large language models process data. AI models do not read full words; instead, they break text, images or code down into “pieces” called tokens. As a baseline, every 100 words process as approximately 130 to 140 tokens. Because the major AI providers use the token as their currency, your business is billed dynamically based on the exact volume of tokens consumed by every query submitted (input) and every response generated (output).

Many leaders believe AI costs are fixed due to flat-rate enterprise tiers ($25–$30/user). This is a temporary illusion. These venture-capital-subsidized rates mask true operational costs and come with dynamic usage limits. Modeling long-term ROI on them guarantees a severe budget shock when true consumption pricing takes over.

The solution is not to halt AI adoption; doing so means losing your competitive edge. Instead, the cost per token must cease to be treated as a technical footnote relegated to the IT department. It must be elevated to a core business variable.

Risks in the AI adoption model

Since the beginning of the AI boom, I have seen all our customers making a critical tactical error that could cost them heavily in the medium term: they are focusing only on operational efficiency (reducing costs with AI).

I have observed that an alarmingly high percentage of companies remain trapped in pilot phases focused exclusively on short-term cost reduction. Bain & Company’s global Automation and AI Pathfinder Survey found that the largest share of companies measuring their AI initiatives (exactly 40%) realized cost reductions of 10% or less, heavily missing their internal targets. Our customers are putting too many resources and effort into marginal financial gains and in doing so, they are jeopardizing their most valuable assets: service quality, resilience and customer trust.

Utilizing AI solely to slash headcount or cut operational corners is a dangerous trap that introduces severe field liabilities. A financial service organization in Latin America announced that they saved $1 million in customer support by replacing humans with AI chatbots. However, the mid-term reality revealed a different story: a damaged brand reputation due to AI errors and an influx of frustrated clients fleeing because the automated system cannot handle special cases.

Putting a company on an extreme AI diet might make it look leaner on next quarter’s financial statement, but over-indexing on cost-cutting will ultimately leave the business too weak to compete when market dynamics shift. We are now inviting our customers to change the question from “How much money will AI save us?” to “How will we leverage AI to exponentially increase the long-term value of our enterprise?”

Deploying enterprise AI is a marathon, not a sprint, and the terrain changes with every mile. The organizations that thrive in this next era will be those that transition from fascination to discipline, treating AI not as a magic bullet for immediate savings, but as a core capability that demands rigorous governance, architectural foresight and cultural maturity. Navigating this shift requires moving past the theoretical hype and anchoring decisions in raw, field-tested reality.

As we continue to deploy these technologies across industries, the blueprint for success is being rewritten in real time. Let’s keep this conversation going as we map out the future of business intelligence together.

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

Model Context Protocol (MCP), the emerging standard for connecting AI models to external tools and enterprise data, is undergoing its biggest architectural overhaul yet.

The latest release candidate, scheduled for release on July 28, removes protocol-level sessions in favor of a stateless architecture, a change which industry experts say is intended to make MCP easier to deploy across standard cloud infrastructure as enterprises move AI pilots into production.

“The session-based model made sense when MCP servers were local processes on a developer’s laptop. In production, it became an operational tax,” said Muskan Bandta, cloud associate at ZopDev.

“When your infrastructure team asks whether MCP services can scale like other cloud applications, the answer used to be ‘not quite.’ With the move to a stateless architecture, the answer is now yes,” Bandta added.

Earlier versions of the protocol maintained information about every client connection, meaning servers had to keep track of each session throughout an interaction. While that approach worked well for local development, it complicated deployments across multiple servers because requests often had to be routed back to the same machine, limiting scalability and making MCP a less natural fit for modern cloud architectures.

“Under the new stateless design, every request contains the information needed for any available server to process it independently. Applications that need to maintain context across multiple requests can still do so, but developers must now manage that state explicitly rather than relying on the protocol itself,” she said.

This transition to a stateless design goes beyond simplifying infrastructure by fundamentally changing how AI applications manage and share context across tools, according to Amit Jena, AI development manager at IT consulting firm Kanerika.

Instead of keeping application state hidden inside protocol sessions, the new design makes it explicit, allowing AI models to access, reason over, and pass that information between tools, giving developers greater control over how context is preserved and shared across tools, Jena said.

It should also make AI workflows more portable, resilient, and easier to orchestrate across distributed environments, he said.

MCP’s new features

Other changes to MCP include the addition of a Multi Round-Trip Requests (MRTR) mechanism that changes how AI agents request additional information they need to complete a task.

Instead of relying on a persistent connection between the client and server throughout the interaction, the new mechanism lets the server request additional input through a standard request-response exchange before continuing the task, Jena said.

Routable transport headers, another addition, enable API gateways and other networking infrastructure to identify and route MCP requests without inspecting their contents.

They reduce processing overhead, lower latency, and let enterprise teams enforce routing, rate-limiting and security policies more efficiently using existing API management infrastructure, Jena said.

MCP is also getting an updated authorization framework built around OAuth 2.1 and OpenID Connect; interactive MCP Apps; and deterministic caching of tool and resource listings to improve LLM prompt-cache hit rates, potentially saving on token costs.

Rebuilding the trust boundary

The MCP release steering committee also decided to deprecate some legacy features, including Roots, Sampling, Logging, the older HTTP+SSE transport and Dynamic Client Registration, although these will continue to work in this version and any other released over the next year.

The deprecation of Sampling is likely to have the biggest impact because it changes who is responsible for interacting with foundation models, said Jena.

“Sampling let MCP servers invoke the LLM through the client, which meant the server had a callback path into the model without owning that connection. Deprecating it means rebuilding that trust boundary,” Jena said. “Your server now calls the model provider directly. That changes your network architecture, your auth model, and depending on how you’ve built cost attribution, your billing flow.”

The year-long transition period will be enough for teams to audit their sampling dependencies now, said Jena: “The risk is that teams who haven’t implemented sampling themselves won’t know if a third-party MCP server they’re depending on uses it.”

Updated MCP SDKs

To accompany the protocol update, there are updated MCP SDKs for Python, Typescript, Go, and C#. These support both the old and new protocol versions, so new clients can continue communicating with older servers, while updated servers will also support older clients, reducing the risk of immediate disruptions.

That backward compatibility should make the transition largely incremental, except for enterprises that built custom infrastructure around MCP’s earlier session-based architecture, Bandta said.

Identifying and auditing those session dependencies may not be easy, Jena warned.

“Session management complexity tends to be hidden across multiple layers — the gateway config, the deployment scripts, the monitoring dashboards. The code change is small; finding everywhere the assumption lives is what takes time,” he said.

This article first appeared on InfoWorld.

Four months of Claude Code — that’s all it took for Uber to burn through its entire annual budget for AI. Token after token, engineers embraced the platform with few control mechanisms tying costs to outcomes. The result was a budget runaway and a clear case study in how limited oversight snowballs into an AI blowout.

This is a phenomenon I like to call “shadow tokens” — AI credits paid for by the company but largely invisible to decision-makers. Too many engineers have the final say over how much they consume and, therefore, what it costs. This all-you-can-eat attitude is part of the reason why Microsoft is reportedly winding down many internal licenses across key engineering teams and why one in five organizations is missing its AI spend forecast by more than 50%.

And the trend is only accelerating. By 2028, Gartner predicts that AI coding costs (driven by this kind of ungoverned consumption) will be as much per developer as the salary companies pay that person.

LLMs and agents introduce a new class of variable cost that scales with behavior rather than headcount, putting enterprises on the hook for tools that balloon with workload. I don’t see this as enterprises overspending because they’re reckless — it’s down to a lack of managerial oversight, budget alignment that demands a proven return on investment, and engineer education on how much is too much.

Going forward, CIOs need to thread the AI needle between governance that encourages transparency and reasonable spend without stifling innovation.

When shadow tokens result in real costs

The issue is that AI isn’t a traditional line item. Previously, enterprise leaders onboarded software-as-a-service (SaaS) with a good idea of the total cost. An allocated software seat or annual contract was a known quantity. The cloud added some variation (with fluctuations depending on hosting size), but instances were still modelable. AI flips this status quo on its head — the unit of consumption is behavior and the cost is exponential.

And these specifics aren’t immediately apparent at pilot. Tools can appear inexpensive in controlled experiments yet unpredictably scale depending on session length, context window size, model selection and whether agents run in parallel. This is the fallacy of the $20-per-seat enterprise plan — tokens are charged separately at API rates with no ceiling. The final dollar value of any session is set by factors that finance can’t always model in advance, particularly when these decisions usually rest with the engineers themselves.

According to Deloitte, only 21% of organizations deploying agents have a mature governance model, a real concern because they’re token-eating machines. This is what was happening at Uber — Claude Code in agentic mode was autonomously reading codebases, planning changes across dozens of files and opening pull requests. Each step quickly adds up, with Anthropic’s own documentation noting that agents consume approximately seven times as many tokens as standard sessions.

This is shadow IT and shadow AI, evolved. This time, however, many leaders approved the tool in question without guardrails governing consumption. AI hype adds fuel to the fire and normalizes long sessions. Uber’s CTO, for example, described a company-wide shift toward “agentic software engineering” with employees “who are quietly experimenting, quietly shipping and quietly pushing things forward”. This is an exciting way to test the limits of what’s possible, certainly, but it’s also a position that goes a long way to explaining how the company spent its annual AI budget by April.

Shifting the culture from usage to yield

Engineers haven’t done anything wrong here. In fact, they’re adopting and experimenting as instructed, with Uber creating leaderboards and ranking users by token consumption. More use led to a better ranking, reflecting a culture that lauds new ways of doing things. This behavior is known as “tokenmaxxing,” and its principal knock-on effect is shadow tokens — quantity-over-quality processes that leaders struggle to control until they’re fully realized in the budget. Of course, if management treats adoption metrics as performance metrics, then engineers can’t be blamed for using more tokens. The tension is that the teams driving adoption aren’t the ones managing spend.

None of this is meant to dismiss AI’s productivity possibilities and potential return on investment. Developers save 3.6 hours per week, achieve 60% higher pull request throughput and cut onboarding time in half with automation. Meanwhile, Uber shared that roughly 11% of live backend updates were written by agents with no human in the loop. However, these wins aren’t the problem — it’s that too many teams aren’t connecting input to output. I’ve spoken to admins who discovered their token spend had tripled in a single quarter after using heavier models or accidentally doubling up on agentic applications. Nobody knew until the financial damage was done.

Automation needs to happen sustainably with an eye on the bottom line. In my view, a much better metric for achieving this is AI yield — the measurable business or engineering output generated per dollar spent on tokens. Otherwise, without a feedback loop, even genuinely productive teams are flying blind.

Stopping token waste before an AI blowout

Creating that throughline between AI investment and token consumption starts with established financial metrics. This is possible via maximum spend limits (dictated by spend tagging, workload tiering and cost-per-output benchmarks) per team or project. Then, any additional allocation requires approval, closing the loop between the engineers spending the tokens and the leaders paying for them. AI isn’t cheap and teams should demonstrate a bang for their buck.

This is something we do with our engineering team at Hexnode. Resource allocation for Claude Code and Cursor is tied directly to ROI rather than letting consumption run open-ended. Given the pay-as-you-go nature of these tools, a firm usage limit per team offers simple but essential control.

Similarly, there’s room to apply some of the governance principles IT uses for device management. Things like policy enforcement, role-based access, real-time monitoring and automated alerts can flag usage behavior in advance. Uncovering such insights at the token layer works to identify power users and prevent excessive spending.

We also need to encourage cultures that praise outputs that actually achieve efficiency. AI applications that result in shipping faster, reducing rework and cutting review cycles are gains that should be celebrated. If your company hosts leaderboards, frame unnecessary token burn as wasteful rather than valuable. The organizations creating healthier consumption habits work with their engineers to understand not just how to use AI, but what responsible use looks like and what it costs.

This is a conversation teams need to have now. Anthropic just ended flat-rate pricing for programmatic workloads from June 15. Now, agents, continuous integration pipelines and automated workflows draw from a dedicated monthly credit pool billed separately from the subscription. Once that pool is exhausted, agent tasks either stop entirely or overflow to extra billing. Work can either get very expensive or grind to a halt for teams that aren’t prepared.

Getting a grip on shadow tokens means better rules and tools connecting spend to outcomes. Only by building the financial and cultural infrastructure that encourages sustainable adoption can leaders see what they’re spending, connect it to what they’re getting and course-correct before the costs become a crisis. Ultimately, shadow tokens are only invisible if we choose not to look.

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

In August 2025, 126 malicious packages landed in the npm registry. Even after the community caught the initial wave, 80 of these hidden backdoors remained actively listed.

That was enough. Over 86,000 downloads. Malicious code in PhantomRaven, packages running in the production systems of Fortune 500 companies worldwide. And throughout the entire window, not a single EDR/XDR alert.

This happened because the attack surface has expanded to a layer EDR/XDR was never designed to see: VS Code extensions, local MCP servers, and rogue AI coding assistants that inherit your engineers’ valid credentials to steal data at machine speed.

To eliminate this structural vulnerability, Palo Alto Networks acquired Koi, an AI-native developer security product engineered for proactive, precision enforcement. Below we compiled a 2026 CISO checklist you can use to audit your environment and see how Koi automates each defense from day one.

#1. Gain real-time visibility into shadow AI & extensions

Your existing asset management tracks binaries and installers, but it cannot see local VS Code extensions, MCP servers, or ad-hoc Python scripts running on developer endpoints. This visibility gap was recently exposed by the MaliciousCorgi campaign, where two marketplace extensions with 1.5 million combined installs silently harvested every file a developer opened. Neither triggered any detection because they were not binaries, not executables, not anything your inventory was built to flag. To counter this, Koi closes the gap by analyzing what extensions actually do after installation, exposing hidden data-harvesting channels running inside your active workspace.

#2. Distinguish between human and autonomous agent behavior 

When a rogue AI agent exfiltrates your proprietary source code, it uses a developer’s valid credentials during normal working hours, making the session look entirely legitimate to standard XDR baselines. Moving beyond static permission lists, Koi deploys behavioral profiling within the workspace runtime. By actively intercepting unauthenticated background tasks and blocking unauthorized file-system reads, it stops automated data exfiltration in real time.

#3. Establish guardrails for automated package updates on endpoints

Developers prioritize speed, often allowing software packages to auto-update on their endpoints the moment a new version appears. Attackers weaponize this supply chain vulnerability, as seen in the May 2026 Team PCP attack where 3,800 GitHub repositories were compromised in just 36 minutes via poisoned auto-updates. Securing agentic endpoints against these rapid breaches requires behavior-based inspection within the active workspace context. Koi operates at this layer by providing safe deployment buffers that automate version cooldowns, blocking bleeding-edge updates until they are vetted. By continuously auditing process creation within the IDE runtime, Koi instantly drops unauthorized remote connections before malicious payloads can exfiltrate credentials from the endpoint.  

#4. Enforce principle of least privilege for AI agents

AI coding assistants inherit the privileges of whoever deployed them. In practice, that means read access to production databases, write access to core repositories, and access to every secret in environment files and configuration directories. To restrict this excessive access, Koi applies dynamic sandboxing directly to AI agent processes at the kernel level. It enforces a strict zero-trust boundary that segregates sensitive workspace vectors, preventing agents from pulling data outside their approved scope without interrupting developer workflows.

#5. Maintain continuous endpoint posture management

Signature-based scanning only stops known threats. Sophisticated repository attacks often arrive as functional, high-rated software that carries no known bad signature. Koi’s research into the DarkSpectre campaign found eight browser extensions, all carrying “featured” badges from Google and Microsoft, installed by over 8 million users, silently harvesting every conversation from ChatGPT, Claude, and Gemini in the background. Koi addresses this by operating upstream: scanning marketplace listings every hour, using LLM-driven code analysis to compare what software promises against what its code does, sandboxing it, and scoring the risk before it ever reaches the endpoint.

Summary

Securing the modern enterprise is no longer about patching individual gaps. As AI agents redefine the workforce, Agentic Endpoint Security (AES) is now a strategic imperative for every CISO. By establishing a mandatory control plane for the AI-native workspace, AES ensures that your organization can scale engineering velocity without ever compromising enterprise integrity. 

Ready to secure the future of your software stack? See how Koi Agentic Endpoint Security delivers complete visibility, risk scoring, and real-time prevention across every endpoint in your enterprise.