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.

The traditional methods of measuring success no longer tell the full story. Here’s what should replace them — and why.

In brief:

• AI is transforming software as a service (SaaS), and the old ways of keeping score no longer apply.
• Smart companies are evolving new metrics that provide deeper insight into how AI-native software is performing in a new marketplace.
• These changes impact everything from pricing to valuations.

The transformation of the software-as-a-service (SaaS) industry toward AI-native operating companies is rapidly changing the unit of value across the industry.

The traditional metric of seats — which measured access — is rapidly giving way to credits designed to measure work performed. This evolution is upending the industry in multiple ways, impacting everything from pricing to enterprise valuations.

While many companies still cling to seat-based metrics to measure growth, efficiency and durability, the future is likely to be one in which companies utilize a credit-centric metrics framework, with seats and outcomes as the bookends of a spectrum.

Why do software companies need new metrics?

Why the rethink, and why now? There are five major forces that are driving this shift:

1. The unit of value is changing. Seats measured who could access software, and credits measure what the software actually does. But in an AI-native world, agents don’t have seats; they have workloads. Over the past 18 months, every major SaaS platform has moved to some forms of credit or consumption unit.
2. The cost of goods sold (COGS) is exploding. AI inference adds real per-unit costs that scale with usage. In an AI-native world, software companies can’t scale to infinite users at near‑zero marginal cost as before.
3. Buying is moving up the org chart. AI-native applications shift purchasing to higher-level operators — such as line-of-business leaders or chief operating officers — which expands the market from software budgets to labor budgets. And because AI agents replace services as well as software, the total market opportunity is 3x to 10x larger than traditional SaaS.
4. Time to value (TTV) is collapsing. With AI-native tools, customers start seeing meaningful results in weeks rather than quarters. Onboarding and setup are fast, workflows are pre-built, and there’s no need for extensive customer success or professional services — dramatically reducing implementation time and costs.
5. Retention is bifurcating. AI forces clarity in a way that traditional SaaS couldn’t. Products that can provide value become even “stickier” and retain customers. Those that don’t churn faster. In an AI-native marketplace, the middle disappears.

How this shift is impacting pricing

Given how AI-native software is transforming the market, the shift to more variable pricing options is inevitable.

Seats won’t go away completely. Subscription pricing based on the number of users is stable and predictable and will continue to work for some customers. Tokens — the use of pass-through pricing for underlying compute — will fit those customers where the AI feature is commoditized or the buyer wants transparency into costs.

Credits will likely become the dominant architecture because they provide a simple metric for both customers and providers. The vendor sets the conversation ratio between credits and underlying compute, shielding the customer from inference cost details. Credits are easy to understand and can be packaged into annual contracts for multiple features and products.

Finally, the industry will likely see some move toward outcome-based pricing for results such as resolved tickets, recovered revenue or qualified leads. This strategy will mostly be limited to verticals where it is easy to prove AI impacted the result.

Where a software vendor sits on this spectrum is a signal of differentiation and pricing power. Credits are where most defensible AI-native businesses are landing because they balance customer predictability with vendor margin control.

How AI upends classic SaaS metrics

When SaaS was in its infancy, companies settled on key metrics designed to answer a small set of core questions. Are we growing? Are customers using the product? Are we retaining and expanding accounts?

But as AI upends software itself, it is also requiring companies to adopt new metrics to track success. These new metrics fall into three primary buckets, rebuilt around the pricing spectrum described earlier and the trend toward credits as the primary frame:

Revenue composition

• Committed credit annual recurring revenue (ARR) vs. burndown ARR: Measuring the credits sold on annual commitment vs. those consumed and replenished. This is the single most important split for valuation. Committed credits behave like subscription and burndown behaves like usage.
• Credit utilization rate: The percentage of purchased credits consumed per period. This is a leading indicator of renewal sizing.
• Credit burn velocity: How fast is a customer consuming their credits, and is that consumption increasing or decreasing quarter over quarter? This metric predicts expansion or contraction before it shows up in ARR.
• Effective price per credit: The real revenue per credit after discounts, overage and rollover, which can detect revenue leakage and help companies set smarter guide rails.

Margin reality

• Credit margin: The gross profit the company earns per credit after subtracting inference costs. This is the core economic unit for AI-native, usage-based businesses — the replacement for gross margin per seat used in SaaS.
• Inference-adjusted gross margin: By carving out AI inference costs separately in the P&L statement, you can see true AI margins, avoid hiding deterioration inside blended SaaS margins, and clearly distinguish AI economics from legacy SaaS economics.
• Compute leverage ratio: This metric measures how efficiently the business converts compute spend into revenue. It shows whether your AI margins are improving as you scale.
• AI-adjusted “Rule of 40”: This updated metric recalibrates the traditional growth and profitability benchmark to account for AI’s lower gross margins and variable inference costs, giving a more accurate picture of business health for AI-native companies.

Behavioral and value signals

• Time-to-first outcome: Replaces traditional onboarding metrics. Tracks how fast a customer reaches their first measurable result.
• Adoption: AI-native adoption is measured by workflow penetration and active agent density, not seat count. As AI replaces human-driven usage, the unit of adoption shifts from people to automated workflows and agents.
• Net credit retention (NCR): Credit-volume retention across the customer base, tracked separately from net recurring revenue to avoid price-change impact.

Along with these new metrics, the industry’s transformation is prompting companies to retire or recalibrate old SaaS measures, including per-seat ARR as a primary key performance indicator (KPI), traditional magic number calibrated to subscription dynamics, unadjusted Rule of 40, customer success metrics tied to human touchpoints, and blended gross margin without AI COGS carve-outs.

What does this mean for enterprise value calculations?

As the internal metrics of success change, so do the ways the investment community measures growth and long-term viability.

Increasingly, a company’s valuation multiple depends on whether its revenue behaves like committed subscription ARR or volatile usage ARR, and the commit‑to‑burndown ratio is the metric investors use to decide where the company fits.

For example, a business with 80% committed credit ARR could trade closer to subscription comps and one with 80% burndown could trade closer to usage comps even though both have the same types of customers. Being able to proactively explain the commit‑to‑burndown mix can help companies avoid undervaluation.

In addition, utilization is expected to replace net promoter scores and seat usage as the primary predictor of churn or expansion. Low utilization guarantees downsizing at renewal, so companies must track utilization cohorts the same way SaaS tracks logo retention cohorts today.

We’re also seeing an inversion of the operating model, with R&D and COGS moving up the P&L and sales and marketing (S&M) and customer success (CS) moving down or sideways. The net operating leverage profile is structurally different from classical SaaS, and the cost-to-scale curve looks different too.

Finally, credit margin engineering is a hidden value-creation lever. The gap between price per credit and cost per credit is set by the software vendor and can be optimized. Most operators have barely started managing this rigorously, and the ones who do will pull away on margin.

What this means for leaders, boards and investors

The shift from classic SaaS metrics to new AI‑native measures isn’t cosmetic. It represents the seismic change the industry is experiencing as AI matures and transforms products and organizations.

While these metrics — and perhaps others yet to be determined — may evolve over time, there is no doubt they are already changing how AI companies allocate capital, price products, incent sales teams, evaluate performance and communicate with investors.

It’s important to remember that SaaS metrics were practical tools for a specific era of software. As that era draws to a close, winning companies will choose new metrics that shape behavior and drive smart decision-making.

The views reflected in this article are the views of the author and do not necessarily reflect the views of Ernst & Young LLP or other members of the global EY organization.

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

Cloudflare recently beat Q1 2026 earnings. Revenue up 34% year over year. EPS ahead of consensus. Full-year guidance raised. Then, in the same breath, they announced 1,100 layoffs, 20% of the company. CEO Matthew Prince’s explanation: “The way we work at Cloudflare has fundamentally changed.”

Block did the same thing. Beat guidance, raised outlook, cut 4,000+ jobs. Both framed it as architecting for the AI era.

This is not a contradiction. This is the new math boards are running. And if you’re a CIO who hasn’t started running it yourself, you’re behind.

The benchmark has moved

AI-native companies have quietly reset what “efficient” means for a technology organization. Midjourney generates over $500M in revenue with roughly 160 employees, over $3M per head. Anthropic hit a $14B annualized run rate in early 2026 with fewer than 3,000 employees. Across the top AI-native startups, the average revenue per employee is $3.48M, nearly twelve times the traditional SaaS benchmark of $300K.

Boards aren’t comparing you to your 2019 self anymore. They’re comparing you to Anthropic.

This is the pressure Cloudflare and Block are responding to. They’re not cutting people because the business is struggling. They’re cutting because investors have internalized a new denominator. Headcount is no longer a proxy for capacity; it’s a liability on the efficiency ratio.

For CIOs, this creates a hiring problem that looks nothing like the cloud or mobile talent gaps of the past decade. Those gaps were about volume: hire 100 cloud engineers, absorb the cost, build the capability… This one is about density; you’re not looking for 100 people. You’re looking for 10 who can deliver what 100 couldn’t, and justify $1M or more in value per seat.

Finding bodies to fill seats has never been easier. Finding people who operate at that level of leverage is a different problem entirely.

‘Acqui-hires’ are a shortcut with a hidden cost

Companies have figured out that recruiting AI-native talent one by one is too slow and that it’s faster to buy a team. Google’s acquisition of the Windsurf founders, Meta bringing in the Scale AI team, Accenture’s string of AI-focused acquisitions: these are acqui-hires dressed up as M&A. The premium on experienced AI talent is high enough, and the urgency real enough, that organizations are skipping traditional hiring loops entirely and buying their way in.

I’ve been on the other side of this. My company, MadKudu, was acquired by HG Insights specifically to bring AI-native capability into an established enterprise business. HG needed change agents who had already figured out how to build and ship in this new era, not just people who’d read about it. That’s the thesis behind most of these deals.

But there’s a cost that doesn’t show up in the acquisition price.

AI-native teams are fast because they operate with a different set of defaults: full access to tools, minimal governance layers, the ability to experiment and ship without a six-week approval cycle. That operating model is not a perk; it’s the fundamental mechanism. It’s why a team of 10 can do what an enterprise team of 100 can’t.

When you acqui-hire that team and then slot them into your existing approval processes, you’ve bought the people and killed the engine. The change agents you paid for become change-frustrated. The attrition that follows is expensive and predictable.

The harder realization: acquiring an AI-native team means accepting how they work. That requires deliberately carving out space for them to operate differently, not just tolerating it but institutionalizing it. The acquisition is an organizational change program, not just a hiring event.

The CIO’s real problem

The governance stack most enterprise organizations run was designed for a headcount world. Every tool vetting cycle, every vendor review, every security approval was calibrated assuming you were managing a large team where consistency and control were the primary objectives.

That calculus breaks when your goal is talent density. The same approval processes that protect against data leaks are now the reason your best people can’t do their best work. When it takes six weeks to approve a tool that your competitor’s team is already shipping with, you’ve traded velocity for the perception of safety.

The practical fix is structured experimentation: clear guardrails, defined boundaries, but explicit permission to try tools before deciding whether to roll them out broadly. Gating everything prevents you from ever discovering what 10x productivity looks like.

The skills inventory question is also more nuanced than it sounds. Job titles won’t tell you where the leverage is. You need to map the actual tasks within each function and assess which can be automated or augmented with AI. That’s where you find the people who, with the right tools, become your $1M/employee talent, not because you hired differently, but because you enabled better.

This is also where the build-versus-buy question gets genuinely tricky. As AI reshapes how products are built and delivered, your internal operating model — how you work, how fast you ship, how you use data — is becoming core IP. Outsourcing delivery means outsourcing the part of the organization where your competitive advantage is now being built.

Closing the gap without slowing down

The AI talent wars are not primarily a recruiting problem. They’re a rethinking of what organizations are supposed to look like.

Boards have a new benchmark. Cloudflare, Block, Amazon, Meta and others have already started restructuring to meet it, publicly, painfully, even while beating their numbers. The question for CIOs isn’t whether this pressure arrives; it’s whether you’re ahead of it or behind it when it does.

The organizations that navigate this well won’t win by outbidding competitors for a handful of elite engineers. They’ll win by designing operating systems that amplify the leverage of the talent they do have, by enabling their best people rather than constraining them, and by treating AI fluency as a core organizational capability rather than a niche specialization.

Talent density is the new headcount model. The sooner your governance, your tooling and your board conversations reflect that, the better positioned you’ll be when the next efficiency report lands.

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

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?

Predicting an outage is tricky business, but CIOs might want to circle Oct. 11, 2026, through Jan. 11, 2027, for likely trouble of a potentially widespread and puzzling nature.

That’s because a relatively trivial update to DNSSEC on Oct. 11, one that will take full effect by Jan. 11, is likely to deliver a series of seemingly unrelated system outages. This will come from oceans of dependencies from third-party, shadow, agentic, gen AI, SaaS, homegrown, and legacy apps — among many other quiet executable hiding spots, including virtual environments and containers.

Sai Joshitha Kathari, senior site reliability engineer at payment card giant Visa, says most enterprises have far more DNS-related exposure than they realize because of these many dependencies.

“This has the potential to create real downstream destruction when unresolved failures sit underneath important business functions,” Kathari says. 

The danger is that so many of these issues are either unknown to IT or handled by a third-party vendor and no one in IT has had reason to ask those vendors about DNS updates. 

“The risky areas are usually not the obvious managed DNS services. They are the older internal applications, hardcoded resolvers, containerized workloads, sidecar configurations, custom scripts, partner integrations, VM images, stale base images, and service-to-service dependencies that nobody has touched in a long time,” Kathari explains. “These systems can keep working quietly for years, then fail during a DNS or certificate-related change because they bypassed the normal platform standards.”

Independent technology analyst Carmi Levy says that CIOs need to take this event very seriously. 

“The two-pronged deadline — October 11, 2026, when the new Key Signing Key (KSK) begins signing the root zone, and January 11, 2027, when the old key is retired — should be marked in red on everyone’s calendar, just as December 31, 1999, once was,” Levy says. “Failure to comply could result in websites, critical business applications, and related resources dropping off the face of the Earth once the transition is complete.”

Levy adds: “Custom-built code that lives outside conventional support mechanisms may or may not function when the DNS changes go into effect.”

The DNSSEC update itself is straightforward, but it is also the first significant DNSSEC change — specifically a change in the trust anchor — since 2018. 

The rollout statement noted that “the trust anchor is formally known as the Domain Name System Security Extensions (DNSSEC) root zone Key Signing Key (KSK). The KSK is the cryptographic key at the core of the DNSSEC trust anchor and is used to verify that DNS responses are legitimate and have not been modified in transit.”

Expect nearly every enterprise to be impacted

Kim Davies, vice president of IANA Services and president of public technical identifiers at ICANN, says the extent of the impact on enterprises is unknowable, given the nature of shadow IT and other edge cases. 

But based on the massive number of dependencies both known and unknown in the typical global enterprise, Davies guesses that just about every enterprise will be impacted, to varying degrees. 

“In highly complex organizations, it is very likely there will be some impact in the corners, in the margins, of the organization,” Davies tells CIO. “DNS is such a core technology that underpins everything.”

As the updates propagate, hiccups will materialize, Davies notes. “When the system cannot validate the [DNS] information, it will treat it as suspect and DNS lookups will fail.”

Visa’s Kathari says, “Enterprises should expect some secondary DNS-related glitches when major DNSSEC-related changes happen, not necessarily because the core infrastructure teams will ignore the update, but because large environments have many hidden dependency paths.”

Making this problem far worse, Kathari notes, is that the glitches will likely initially look like anything other thana DNS glitch. That will force IT staff to waste a vast number of hours chasing causes that ultimately prove to be unrelated to the incidents. 

“The impact for CIOs is that DNS failures rarely announce themselves as DNS failures. They look like application timeouts, broken logins, failed API calls, queue lag, payment failures, partner connectivity issues, or random regional instability,” Kathari explains. “That makes troubleshooting slower because teams may spend hours looking at the application, database, network, or cloud provider before realizing name resolution is part of the failure path.”

Sanchit Vir Gogia, chief analyst at Greyhound Research, agrees that IT will likely spin its wheels chasing the wrong ghosts.

“A validation failure rarely stays in its lane. It surfaces as an application error, an API timeout, or a reachability problem, which turns a resolver fault into a coordination failure,” Gogia says. “The application team blames the network, the network team blames the cloud, and the user simply watches work stop.”

“Images and templates are the frontier most teams miss,” Gogia adds. “A resolver fixed in summer can be broken again in October the instant a stale golden image is redeployed, because automation no longer lets configuration drift slowly. It restores yesterday’s assumptions at machine speed.”

It is widely expected that enterprises will not have any problems executing the change or, more likely, relying on their hyperscalers to properly handle the change. That is the concern. 

“CIOs are being distracted so much with AI and this is such a deep in the weeds infrastructure issue that this can and willcatch people off-guard,” Justin Greis, CEO of consulting firm Acceligence, tells CIO. “I think we’ll see a meaningful number of enterprise disruptions associated with the DNSSEC trust anchor rollover. Not because the update itself is especially difficult, but because it will expose weaknesses that already exist inside many organizations.”

Most enterprise IT operations have had no reason to compile a comprehensive list of all DNS dependencies, but many will be instantly discovered in January. 

Potentially widespread fallout

A major retailer, for example, might suddenly be unable to connect with FedEx to arrange for deliveries or a hospital may find that test results are no longer being shared with patient portals. It might manifest as an assembly line that halts because an IIoT component can no longer share files with its vendor system or a truck fleet that stops being tracked. 

“There will almost certainly be systems that fall through the cracks. Some will be legacy applications that rely on outdated DNS configurations that have not been updated in years,” Greis says. “Others will be business-unit-developed tools, contractor-built solutions, embedded systems, manufacturing and industrial systems, or highly customized workloads that operate outside normal IT oversight. These are the types of systems that often surface during infrastructure events like this.”

Greis adds that many enterprises will discover in January problems created by their own automation.

“Over time, enterprises build layers of processes, templates, and deployment mechanisms that are reused across teams and environments,” Greis notes. “Even after DNS infrastructure is updated correctly, older settings can inadvertently be reintroduced through routine updates and system changes, creating intermittent and difficult-to-diagnose failures.”

The good news from this situation is that enterprises are not going to likely lose all DNS access if any of these glitches occur. But that may be of no comfort because even if the disruptions are only with small edge cases, that can still cause massive operational disruptions.

Cricket Liu, EVP and chief evangelist at Infoblox, gives the example of a DNS server that responds to factory-floor system queries.

“Or let’s say this disrupts [an enterprise’s key] SaaS application. All name resolution may stop and it will show a server failure. It will not deliver a response whenever I look anything up. That’s not subtle at all,” Liu says. “It’s highly likely that companies are going to see some effects.”

Back in 2017, the switchover was relatively uneventful, giving some CIOs hope that January 2027 will also be a non-event. But given the technology advancements in the last 10 years and the resulting tidal wave of new enterprise tech dependencies, few are realistically expecting no problems this go around. 

Impossible to predict what will happen

One of the top network experts on DNS effects in enterprises is Geoff Huston, chief scientist at the Asia Pacific Network Information Centre (APNIC), the regional Internet Registry administering IP addresses for the Asia Pacific region.

Huston says it is difficult to project what will happen in January until it happens.

“Just like the last time, we are flying blind with this key roll. Because nothing really terrible happened last time, there is some confidence that nothing terrible will happen this time, but we just can’t tell in advance as there are no good measurement approaches that allow us to peek inside the trust state of recursive resolvers,” he says.

As for potential edge-case glitches, Huston says it is possible, but if third-party vendors do not properly handle the update, there will be other issues as well, as the KSK cryptographic key used within DNSSEC signs and validates the keys that protect DNS records. 

“If it is not standards-compliant, then you have more problems than just the KSK roll,” Huston says, “as it raises the obvious question of ‘What else is not correctly implemented in the DNS resolver that I’m running?’”

As a silver lining, Acceligence’s Greis says any hiccups that result from the DNS KSK update may be a gift in disguise for CIOs. 

“The irony is that some of the most business-critical components in the technology stack are often the least visible because they work in the background,” Greis says. January “may reveal how much modern business resilience depends on infrastructure that many organizations rarely examine until something breaks. For CIOs, that’s the real lesson. This is not fundamentally a story about a DNS update. It is a story about operational visibility, resilience, and governance. Organizations that treat the rollover as a routine infrastructure task will likely complete the update and move on. Organizations that use it as an opportunity to understand and strengthen the foundations of their technology environment may gain far more value than simply avoiding an outage.”

For CIOs, learning from the startup ecosystem has never been more critical.

As pressure mounts to transform business operations with AI and agentic systems, IT leaders should be looking to those on the AI vanguard for insights into the strategic and technical decisions necessary to launch, grow, and thrive in today’s AI-disrupted business environment.

So why not immerse yourself in Silicon Valley’s most famous firehose of hyper-accelerated fail-fast and dream-big culture by registering for TechCrunch Disrupt 2026?

Three packed days of 200-plus sessions across six stages will spark new ideas for reshaping your AI strategy, provide fresh perspectives on the architectural, workflow, and resource decisions involved in moving AI from pilots to scale, and give you a sneak peek of business disruptions to come.

Get 10% off your TechCrunch Disrupt pass with the exclusive code CIO10. 

This year’s TechCrunch Disrupt, held Oct. 13-15 at San Francisco’s Moscone West, will feature big-picture conversations on what’s next in AI; discussions on how AI agents are rewriting SaaS, enterprise workflows, software pricing, and security; and demonstrations of AI’s future across robotics, manufacturing, defense, and industrial operations; and more.

Over 10,000 attendees will hear from 250-plus startup founders, technology executives, and enterprise IT leaders about how the future of programming is being rewritten, what enterprise AI security requires, how startups are orchestrating workloads across models while managing cost and reliability at scale, why creating a safety culture is essential for AI deployment, and how startups are deciding what work humans should own versus what should be delegated to AI as they work to build hybrid teams without losing speed, accountability, or culture.

And of course, the rising tide of enterprise-focused startups will be there seeking to bring agentic systems to your business workflows, as well as vendors familiar to your enterprise IT portfolios, such as AWS, Google, and Databricks, and enterprise IT colleagues creating mutually beneficial partnerships with the startup community, such as American Express.

That’s not to mention TechCrunch Disrupt’s signature Startup Battlefield, in which 200 standout companies showcase their innovations to compete for a $100K equity-free prize. The battlefield will give CIOs a rapid-fire, broad view of what’s possible — and a possible early look at the next big enterprise player. After all, Dropbox, Trello, and Cloudflare, among others, roamed that same battlefield before the world knew their names.

And with M&A now an early-stage startup strategy for many from day one, TechCrunch Disrupt’s exhibition floor provides IT leaders not just an opportunity to discuss the nuts and bolts of innovation architecture or how an upstart product can enhance your workflows, but a chance to find your next innovation partner, or more.

Leading-edge startups are figuring out how to make AI work at scale. Shouldn’t you be?

Don’t miss your chance to experience TechCrunch Disrupt 2026. Book your pass today and use the exclusive code CIO10 to save 10% before prices increase.

For CIOs, learning from the startup ecosystem has never been more critical.

As pressure mounts to transform business operations with AI and agentic systems, IT leaders should be looking to those on the AI vanguard for insights into the strategic and technical decisions necessary to launch, grow, and thrive in today’s AI-disrupted business environment.

So why not immerse yourself in Silicon Valley’s most famous firehose of hyper-accelerated fail-fast and dream-big culture by registering for TechCrunch Disrupt 2026?

Three packed days of 200-plus sessions across six stages will spark new ideas for reshaping your AI strategy, provide fresh perspectives on the architectural, workflow, and resource decisions involved in moving AI from pilots to scale, and give you a sneak peek of business disruptions to come.

Get 10% off your TechCrunch Disrupt pass with the exclusive code CIO10. 

This year’s TechCrunch Disrupt, held Oct. 13-15 at San Francisco’s Moscone West, will feature big-picture conversations on what’s next in AI; discussions on how AI agents are rewriting SaaS, enterprise workflows, software pricing, and security; and demonstrations of AI’s future across robotics, manufacturing, defense, and industrial operations; and more.

Over 10,000 attendees will hear from 250-plus startup founders, technology executives, and enterprise IT leaders about how the future of programming is being rewritten, what enterprise AI security requires, how startups are orchestrating workloads across models while managing cost and reliability at scale, why creating a safety culture is essential for AI deployment, and how startups are deciding what work humans should own versus what should be delegated to AI as they work to build hybrid teams without losing speed, accountability, or culture.

And of course, the rising tide of enterprise-focused startups will be there seeking to bring agentic systems to your business workflows, as well as vendors familiar to your enterprise IT portfolios, such as AWS, Google, and Databricks, and enterprise IT colleagues creating mutually beneficial partnerships with the startup community, such as American Express.

That’s not to mention TechCrunch Disrupt’s signature Startup Battlefield, in which 200 standout companies showcase their innovations to compete for a $100K equity-free prize. The battlefield will give CIOs a rapid-fire, broad view of what’s possible — and a possible early look at the next big enterprise player. After all, Dropbox, Trello, and Cloudflare, among others, roamed that same battlefield before the world knew their names.

And with M&A now an early-stage startup strategy for many from day one, TechCrunch Disrupt’s exhibition floor provides IT leaders not just an opportunity to discuss the nuts and bolts of innovation architecture or how an upstart product can enhance your workflows, but a chance to find your next innovation partner, or more.

Leading-edge startups are figuring out how to make AI work at scale. Shouldn’t you be?

Don’t miss your chance to experience TechCrunch Disrupt 2026. Book your pass today and use the exclusive code CIO10 to save 10% before prices increase.

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?

Predicting an outage is tricky business, but CIOs might want to circle Oct. 11, 2026, through Jan. 11, 2027, for likely trouble of a potentially widespread and puzzling nature.

That’s because a relatively trivial update to DNSSEC on Oct. 11, one that will take full effect by Jan. 11, is likely to deliver a series of seemingly unrelated system outages. This will come from oceans of dependencies from third-party, shadow, agentic, gen AI, SaaS, homegrown, and legacy apps — among many other quiet executable hiding spots, including virtual environments and containers.

Sai Joshitha Kathari, senior site reliability engineer at payment card giant Visa, says most enterprises have far more DNS-related exposure than they realize because of these many dependencies.

“This has the potential to create real downstream destruction when unresolved failures sit underneath important business functions,” Kathari says. 

The danger is that so many of these issues are either unknown to IT or handled by a third-party vendor and no one in IT has had reason to ask those vendors about DNS updates. 

“The risky areas are usually not the obvious managed DNS services. They are the older internal applications, hardcoded resolvers, containerized workloads, sidecar configurations, custom scripts, partner integrations, VM images, stale base images, and service-to-service dependencies that nobody has touched in a long time,” Kathari explains. “These systems can keep working quietly for years, then fail during a DNS or certificate-related change because they bypassed the normal platform standards.”

Independent technology analyst Carmi Levy says that CIOs need to take this event very seriously. 

“The two-pronged deadline — October 11, 2026, when the new Key Signing Key (KSK) begins signing the root zone, and January 11, 2027, when the old key is retired — should be marked in red on everyone’s calendar, just as December 31, 1999, once was,” Levy says. “Failure to comply could result in websites, critical business applications, and related resources dropping off the face of the Earth once the transition is complete.”

Levy adds: “Custom-built code that lives outside conventional support mechanisms may or may not function when the DNS changes go into effect.”

The DNSSEC update itself is straightforward, but it is also the first significant DNSSEC change — specifically a change in the trust anchor — since 2018. 

The rollout statement noted that “the trust anchor is formally known as the Domain Name System Security Extensions (DNSSEC) root zone Key Signing Key (KSK). The KSK is the cryptographic key at the core of the DNSSEC trust anchor and is used to verify that DNS responses are legitimate and have not been modified in transit.”

Expect nearly every enterprise to be impacted

Kim Davies, vice president of IANA Services and president of public technical identifiers at ICANN, says the extent of the impact on enterprises is unknowable, given the nature of shadow IT and other edge cases. 

But based on the massive number of dependencies both known and unknown in the typical global enterprise, Davies guesses that just about every enterprise will be impacted, to varying degrees. 

“In highly complex organizations, it is very likely there will be some impact in the corners, in the margins, of the organization,” Davies tells CIO. “DNS is such a core technology that underpins everything.”

As the updates propagate, hiccups will materialize, Davies notes. “When the system cannot validate the [DNS] information, it will treat it as suspect and DNS lookups will fail.”

Visa’s Kathari says, “Enterprises should expect some secondary DNS-related glitches when major DNSSEC-related changes happen, not necessarily because the core infrastructure teams will ignore the update, but because large environments have many hidden dependency paths.”

Making this problem far worse, Kathari notes, is that the glitches will likely initially look like anything other thana DNS glitch. That will force IT staff to waste a vast number of hours chasing causes that ultimately prove to be unrelated to the incidents. 

“The impact for CIOs is that DNS failures rarely announce themselves as DNS failures. They look like application timeouts, broken logins, failed API calls, queue lag, payment failures, partner connectivity issues, or random regional instability,” Kathari explains. “That makes troubleshooting slower because teams may spend hours looking at the application, database, network, or cloud provider before realizing name resolution is part of the failure path.”

Sanchit Vir Gogia, chief analyst at Greyhound Research, agrees that IT will likely spin its wheels chasing the wrong ghosts.

“A validation failure rarely stays in its lane. It surfaces as an application error, an API timeout, or a reachability problem, which turns a resolver fault into a coordination failure,” Gogia says. “The application team blames the network, the network team blames the cloud, and the user simply watches work stop.”

“Images and templates are the frontier most teams miss,” Gogia adds. “A resolver fixed in summer can be broken again in October the instant a stale golden image is redeployed, because automation no longer lets configuration drift slowly. It restores yesterday’s assumptions at machine speed.”

It is widely expected that enterprises will not have any problems executing the change or, more likely, relying on their hyperscalers to properly handle the change. That is the concern. 

“CIOs are being distracted so much with AI and this is such a deep in the weeds infrastructure issue that this can and willcatch people off-guard,” Justin Greis, CEO of consulting firm Acceligence, tells CIO. “I think we’ll see a meaningful number of enterprise disruptions associated with the DNSSEC trust anchor rollover. Not because the update itself is especially difficult, but because it will expose weaknesses that already exist inside many organizations.”

Most enterprise IT operations have had no reason to compile a comprehensive list of all DNS dependencies, but many will be instantly discovered in January. 

Potentially widespread fallout

A major retailer, for example, might suddenly be unable to connect with FedEx to arrange for deliveries or a hospital may find that test results are no longer being shared with patient portals. It might manifest as an assembly line that halts because an IIoT component can no longer share files with its vendor system or a truck fleet that stops being tracked. 

“There will almost certainly be systems that fall through the cracks. Some will be legacy applications that rely on outdated DNS configurations that have not been updated in years,” Greis says. “Others will be business-unit-developed tools, contractor-built solutions, embedded systems, manufacturing and industrial systems, or highly customized workloads that operate outside normal IT oversight. These are the types of systems that often surface during infrastructure events like this.”

Greis adds that many enterprises will discover in January problems created by their own automation.

“Over time, enterprises build layers of processes, templates, and deployment mechanisms that are reused across teams and environments,” Greis notes. “Even after DNS infrastructure is updated correctly, older settings can inadvertently be reintroduced through routine updates and system changes, creating intermittent and difficult-to-diagnose failures.”

The good news from this situation is that enterprises are not going to likely lose all DNS access if any of these glitches occur. But that may be of no comfort because even if the disruptions are only with small edge cases, that can still cause massive operational disruptions.

Cricket Liu, EVP and chief evangelist at Infoblox, gives the example of a DNS server that responds to factory-floor system queries.

“Or let’s say this disrupts [an enterprise’s key] SaaS application. All name resolution may stop and it will show a server failure. It will not deliver a response whenever I look anything up. That’s not subtle at all,” Liu says. “It’s highly likely that companies are going to see some effects.”

Back in 2017, the switchover was relatively uneventful, giving some CIOs hope that January 2027 will also be a non-event. But given the technology advancements in the last 10 years and the resulting tidal wave of new enterprise tech dependencies, few are realistically expecting no problems this go around. 

Impossible to predict what will happen

One of the top network experts on DNS effects in enterprises is Geoff Huston, chief scientist at the Asia Pacific Network Information Centre (APNIC), the regional Internet Registry administering IP addresses for the Asia Pacific region.

Huston says it is difficult to project what will happen in January until it happens.

“Just like the last time, we are flying blind with this key roll. Because nothing really terrible happened last time, there is some confidence that nothing terrible will happen this time, but we just can’t tell in advance as there are no good measurement approaches that allow us to peek inside the trust state of recursive resolvers,” he says.

As for potential edge-case glitches, Huston says it is possible, but if third-party vendors do not properly handle the update, there will be other issues as well, as the KSK cryptographic key used within DNSSEC signs and validates the keys that protect DNS records. 

“If it is not standards-compliant, then you have more problems than just the KSK roll,” Huston says, “as it raises the obvious question of ‘What else is not correctly implemented in the DNS resolver that I’m running?’”

As a silver lining, Acceligence’s Greis says any hiccups that result from the DNS KSK update may be a gift in disguise for CIOs. 

“The irony is that some of the most business-critical components in the technology stack are often the least visible because they work in the background,” Greis says. January “may reveal how much modern business resilience depends on infrastructure that many organizations rarely examine until something breaks. For CIOs, that’s the real lesson. This is not fundamentally a story about a DNS update. It is a story about operational visibility, resilience, and governance. Organizations that treat the rollover as a routine infrastructure task will likely complete the update and move on. Organizations that use it as an opportunity to understand and strengthen the foundations of their technology environment may gain far more value than simply avoiding an outage.”

Over the past year, I had the same conversation with almost every team starting an AI initiative. Should we build on Semantic Kernel, AutoGen or Foundry?

At first it felt like the most important architectural decision we’d make. Each framework had its own philosophy, each promised to be the foundation for enterprise AI, and picking the wrong one felt like an expensive mistake. I spent a lot of time helping teams weigh the trade-offs.

Looking back, I think we were asking the wrong question. I certainly was.

I watched teams spend months debating SDKs while the decisions that actually decided whether their applications survived production went unexamined. Some built elaborate orchestration layers for workflows that a few deterministic functions would have handled. Others avoided agent frameworks entirely and later found they’d designed themselves into a corner.

Then Microsoft settled it for us. It introduced the unified Agent Framework, quietly moved Semantic Kernel and AutoGen into maintenance mode, and the debate I’d spent months refereeing was suddenly over. Turns out the answer to “which of the three” was “none of the three, here’s a fourth.” The framework hit version 1.0 and general availability in April 2026, stable across .NET and Python.

What surprised me wasn’t the decision. It was how fast a debate that had eaten so much of our attention stopped mattering. Microsoft changed the menu.

It didn’t change the meal.

The framework was never the hard part

Framework selection dominated almost every early conversation I had about enterprise agents. Which SDK do we standardize on? Which orchestration model gives us the most flexibility? Which one is Microsoft actually betting on?

Fair questions. But after a year of watching these projects play out, I’ve slowly come around to a different view. Those weren’t the questions that decided anything.

The first question I ask now is much smaller. Does this thing actually need an agent?

It sounds obvious, and I still get it wrong sometimes. But it’s the mistake I see most. On one project, a team spent weeks designing a multi-agent workflow for a process that ran the same four steps every time: read a document, validate it, call an API, send a notification. The diagrams looked great. The system in production didn’t. A few well-tested functions would have been easier to build, easier to maintain and a lot easier to trust.

Part of this is just that “agent” has become the word everyone reaches for. Sometimes it’s the right call. Sometimes it’s a workflow we already knew how to build, wearing a newer label. An agent earns its complexity when it genuinely has to decide things you can’t predetermine, choosing between tools, adapting to what it finds, working out its own next step. If you already know every step, you have a workflow, and a workflow is usually the better engineering choice. The consolidation didn’t change that. It just made it easier to see.

What building production agents actually taught me

Once I stopped fixating on frameworks, the same three problems kept showing up. None of them had anything to do with the SDK.

Context beats model choice

Early on I spent a lot of time comparing models, the way you’d agonize over a restaurant menu and then order what you always order. Now I spend most of it thinking about context, which is far less fun and far more useful.

I’ve watched good models fail because they were handed too much, not too little. One team I worked with gave the model access to nearly every internal document they had on the theory that more information meant better answers. It went the other way. Responses got slower, less consistent and sometimes skipped right past the thing that actually mattered. When we cut the context down to only what the task needed, the quality jumped almost immediately. I didn’t predict that. It taught me to be suspicious of “just give it everything.”

The best agent systems I’ve worked on weren’t the ones with the biggest context windows. They were the ones careful about what reached the model, and when. That’s not something the framework hands you.

Failure is where the real work is

Most agent demos look great because they’re built around the happy path. Production doesn’t extend that courtesy.

I remember a project where everything held up in testing. Then a downstream API timed out after the agent had already completed several earlier steps. We couldn’t just restart, because part of the business process had already gone through. We ended up spending far more time on recovery logic than we ever spent on prompts. That project changed how I think about this work. The hard part was never getting the model to make a decision. It was making sure the system didn’t fall apart when reality refused to follow the script.

Tool calls fail partway through. APIs return inconsistent data. Models call the same tool over and over because the last answer wasn’t what they wanted. That’s not the exception; that’s a normal Tuesday. Whether you retry, roll back, pause for a human or push on with partial results is a judgment call, and no framework is going to make it for you.

Identity is the real security boundary

This one surprised me most. The moment an agent stops being a chatbot and starts touching real business systems, identity matters more than orchestration.

Every project gets to the same question eventually. Who is this agent actually acting as? The developer’s credentials? A service account? The user who asked? Get it wrong and you’ve built something autonomous running with more access than any single person should have, which is exactly the kind of thing that looks fine until an audit. The Agent Framework, like most modern tooling, makes it easier to wire agents to tools through standards like the Model Context Protocol. That helps. But where human approval belongs, what needs extra authorization, how much rope to give the thing, those are still yours to decide.

The surprises weren’t technical

Here’s what I didn’t see coming. The hardest part of last year wasn’t technical at all. It was organizational. The moment a team heard “agent,” expectations shifted under everyone’s feet. Business stakeholders started expecting full autonomy. Developers assumed the thing could reason its way through anything. People started designing for flexibility before we’d even agreed on what problem we were solving. The word did damage before any code did. I found myself spending as much time resetting expectations as I did discussing architecture.

Build for change, not for today’s winner

I don’t think the teams that struggled last year picked the wrong framework. Semantic Kernel was reasonable. AutoGen was reasonable. Foundry made sense for plenty of cases. I’d have signed off on any of them.

The ones that got hurt put all their eggs in one framework, treating it as the foundation of the whole system instead of as one more dependency. Microsoft provided a migration path. But teams that had tightly coupled their applications to framework-specific abstractions discovered that migrating and rewriting are not the same thing. That wasn’t Microsoft’s doing. It was their own architecture’s. The teams that moved easily had kept their business logic, prompts and orchestration loose enough to evolve independently of any one SDK. For them, the change was a manageable project, not a teardown.

For what it’s worth, nobody I work with is treating this as an emergency. Most are moving the smaller workloads first, watching how they behave and leaving the production-critical systems alone until they actually understand the new abstractions. That’s the right instinct. And I doubt this is the last consolidation we’ll see, the ecosystem is still young, frameworks will keep absorbing each other and over time the differences between them will be operational more than architectural.

I don’t regret the framework debates, honestly. They were reasonable at the time. What changed wasn’t Microsoft’s roadmap.

It was mine. Watching these systems run in production taught me that the framework is the easiest piece to swap out. Recovery logic, context management, security boundaries, the business workflow itself, those stay with you long after today’s SDK gets replaced by tomorrow’s.

So, Microsoft made one decision easier by turning three frameworks into one. Good. Five years from now we’ll be on different tools, and we’ll still be asking the same handful of questions.

Does this actually need an agent? Does it have the right context? Can it recover when something breaks, because something will? Is it acting as the right person?

Those questions outlast every rewrite. That’s where I’ve learned to put my effort.

Frameworks come and go. Good architecture has to survive all of them.

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

Cloudflare recently beat Q1 2026 earnings. Revenue up 34% year over year. EPS ahead of consensus. Full-year guidance raised. Then, in the same breath, they announced 1,100 layoffs, 20% of the company. CEO Matthew Prince’s explanation: “The way we work at Cloudflare has fundamentally changed.”

Block did the same thing. Beat guidance, raised outlook, cut 4,000+ jobs. Both framed it as architecting for the AI era.

This is not a contradiction. This is the new math boards are running. And if you’re a CIO who hasn’t started running it yourself, you’re behind.

The benchmark has moved

AI-native companies have quietly reset what “efficient” means for a technology organization. Midjourney generates over $500M in revenue with roughly 160 employees, over $3M per head. Anthropic hit a $14B annualized run rate in early 2026 with fewer than 3,000 employees. Across the top AI-native startups, the average revenue per employee is $3.48M, nearly twelve times the traditional SaaS benchmark of $300K.

Boards aren’t comparing you to your 2019 self anymore. They’re comparing you to Anthropic.

This is the pressure Cloudflare and Block are responding to. They’re not cutting people because the business is struggling. They’re cutting because investors have internalized a new denominator. Headcount is no longer a proxy for capacity; it’s a liability on the efficiency ratio.

For CIOs, this creates a hiring problem that looks nothing like the cloud or mobile talent gaps of the past decade. Those gaps were about volume: hire 100 cloud engineers, absorb the cost, build the capability… This one is about density; you’re not looking for 100 people. You’re looking for 10 who can deliver what 100 couldn’t, and justify $1M or more in value per seat.

Finding bodies to fill seats has never been easier. Finding people who operate at that level of leverage is a different problem entirely.

‘Acqui-hires’ are a shortcut with a hidden cost

Companies have figured out that recruiting AI-native talent one by one is too slow and that it’s faster to buy a team. Google’s acquisition of the Windsurf founders, Meta bringing in the Scale AI team, Accenture’s string of AI-focused acquisitions: these are acqui-hires dressed up as M&A. The premium on experienced AI talent is high enough, and the urgency real enough, that organizations are skipping traditional hiring loops entirely and buying their way in.

I’ve been on the other side of this. My company, MadKudu, was acquired by HG Insights specifically to bring AI-native capability into an established enterprise business. HG needed change agents who had already figured out how to build and ship in this new era, not just people who’d read about it. That’s the thesis behind most of these deals.

But there’s a cost that doesn’t show up in the acquisition price.

AI-native teams are fast because they operate with a different set of defaults: full access to tools, minimal governance layers, the ability to experiment and ship without a six-week approval cycle. That operating model is not a perk; it’s the fundamental mechanism. It’s why a team of 10 can do what an enterprise team of 100 can’t.

When you acqui-hire that team and then slot them into your existing approval processes, you’ve bought the people and killed the engine. The change agents you paid for become change-frustrated. The attrition that follows is expensive and predictable.

The harder realization: acquiring an AI-native team means accepting how they work. That requires deliberately carving out space for them to operate differently, not just tolerating it but institutionalizing it. The acquisition is an organizational change program, not just a hiring event.

The CIO’s real problem

The governance stack most enterprise organizations run was designed for a headcount world. Every tool vetting cycle, every vendor review, every security approval was calibrated assuming you were managing a large team where consistency and control were the primary objectives.

That calculus breaks when your goal is talent density. The same approval processes that protect against data leaks are now the reason your best people can’t do their best work. When it takes six weeks to approve a tool that your competitor’s team is already shipping with, you’ve traded velocity for the perception of safety.

The practical fix is structured experimentation: clear guardrails, defined boundaries, but explicit permission to try tools before deciding whether to roll them out broadly. Gating everything prevents you from ever discovering what 10x productivity looks like.

The skills inventory question is also more nuanced than it sounds. Job titles won’t tell you where the leverage is. You need to map the actual tasks within each function and assess which can be automated or augmented with AI. That’s where you find the people who, with the right tools, become your $1M/employee talent, not because you hired differently, but because you enabled better.

This is also where the build-versus-buy question gets genuinely tricky. As AI reshapes how products are built and delivered, your internal operating model — how you work, how fast you ship, how you use data — is becoming core IP. Outsourcing delivery means outsourcing the part of the organization where your competitive advantage is now being built.

Closing the gap without slowing down

The AI talent wars are not primarily a recruiting problem. They’re a rethinking of what organizations are supposed to look like.

Boards have a new benchmark. Cloudflare, Block, Amazon, Meta and others have already started restructuring to meet it, publicly, painfully, even while beating their numbers. The question for CIOs isn’t whether this pressure arrives; it’s whether you’re ahead of it or behind it when it does.

The organizations that navigate this well won’t win by outbidding competitors for a handful of elite engineers. They’ll win by designing operating systems that amplify the leverage of the talent they do have, by enabling their best people rather than constraining them, and by treating AI fluency as a core organizational capability rather than a niche specialization.

Talent density is the new headcount model. The sooner your governance, your tooling and your board conversations reflect that, the better positioned you’ll be when the next efficiency report lands.

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

The traditional methods of measuring success no longer tell the full story. Here’s what should replace them — and why.

In brief:

• AI is transforming software as a service (SaaS), and the old ways of keeping score no longer apply.
• Smart companies are evolving new metrics that provide deeper insight into how AI-native software is performing in a new marketplace.
• These changes impact everything from pricing to valuations.

The transformation of the software-as-a-service (SaaS) industry toward AI-native operating companies is rapidly changing the unit of value across the industry.

The traditional metric of seats — which measured access — is rapidly giving way to credits designed to measure work performed. This evolution is upending the industry in multiple ways, impacting everything from pricing to enterprise valuations.

While many companies still cling to seat-based metrics to measure growth, efficiency and durability, the future is likely to be one in which companies utilize a credit-centric metrics framework, with seats and outcomes as the bookends of a spectrum.

Why do software companies need new metrics?

Why the rethink, and why now? There are five major forces that are driving this shift:

1. The unit of value is changing. Seats measured who could access software, and credits measure what the software actually does. But in an AI-native world, agents don’t have seats; they have workloads. Over the past 18 months, every major SaaS platform has moved to some forms of credit or consumption unit.
2. The cost of goods sold (COGS) is exploding. AI inference adds real per-unit costs that scale with usage. In an AI-native world, software companies can’t scale to infinite users at near‑zero marginal cost as before.
3. Buying is moving up the org chart. AI-native applications shift purchasing to higher-level operators — such as line-of-business leaders or chief operating officers — which expands the market from software budgets to labor budgets. And because AI agents replace services as well as software, the total market opportunity is 3x to 10x larger than traditional SaaS.
4. Time to value (TTV) is collapsing. With AI-native tools, customers start seeing meaningful results in weeks rather than quarters. Onboarding and setup are fast, workflows are pre-built, and there’s no need for extensive customer success or professional services — dramatically reducing implementation time and costs.
5. Retention is bifurcating. AI forces clarity in a way that traditional SaaS couldn’t. Products that can provide value become even “stickier” and retain customers. Those that don’t churn faster. In an AI-native marketplace, the middle disappears.

How this shift is impacting pricing

Given how AI-native software is transforming the market, the shift to more variable pricing options is inevitable.

Seats won’t go away completely. Subscription pricing based on the number of users is stable and predictable and will continue to work for some customers. Tokens — the use of pass-through pricing for underlying compute — will fit those customers where the AI feature is commoditized or the buyer wants transparency into costs.

Credits will likely become the dominant architecture because they provide a simple metric for both customers and providers. The vendor sets the conversation ratio between credits and underlying compute, shielding the customer from inference cost details. Credits are easy to understand and can be packaged into annual contracts for multiple features and products.

Finally, the industry will likely see some move toward outcome-based pricing for results such as resolved tickets, recovered revenue or qualified leads. This strategy will mostly be limited to verticals where it is easy to prove AI impacted the result.

Where a software vendor sits on this spectrum is a signal of differentiation and pricing power. Credits are where most defensible AI-native businesses are landing because they balance customer predictability with vendor margin control.

How AI upends classic SaaS metrics

When SaaS was in its infancy, companies settled on key metrics designed to answer a small set of core questions. Are we growing? Are customers using the product? Are we retaining and expanding accounts?

But as AI upends software itself, it is also requiring companies to adopt new metrics to track success. These new metrics fall into three primary buckets, rebuilt around the pricing spectrum described earlier and the trend toward credits as the primary frame:

Revenue composition

• Committed credit annual recurring revenue (ARR) vs. burndown ARR: Measuring the credits sold on annual commitment vs. those consumed and replenished. This is the single most important split for valuation. Committed credits behave like subscription and burndown behaves like usage.
• Credit utilization rate: The percentage of purchased credits consumed per period. This is a leading indicator of renewal sizing.
• Credit burn velocity: How fast is a customer consuming their credits, and is that consumption increasing or decreasing quarter over quarter? This metric predicts expansion or contraction before it shows up in ARR.
• Effective price per credit: The real revenue per credit after discounts, overage and rollover, which can detect revenue leakage and help companies set smarter guide rails.

Margin reality

• Credit margin: The gross profit the company earns per credit after subtracting inference costs. This is the core economic unit for AI-native, usage-based businesses — the replacement for gross margin per seat used in SaaS.
• Inference-adjusted gross margin: By carving out AI inference costs separately in the P&L statement, you can see true AI margins, avoid hiding deterioration inside blended SaaS margins, and clearly distinguish AI economics from legacy SaaS economics.
• Compute leverage ratio: This metric measures how efficiently the business converts compute spend into revenue. It shows whether your AI margins are improving as you scale.
• AI-adjusted “Rule of 40”: This updated metric recalibrates the traditional growth and profitability benchmark to account for AI’s lower gross margins and variable inference costs, giving a more accurate picture of business health for AI-native companies.

Behavioral and value signals

• Time-to-first outcome: Replaces traditional onboarding metrics. Tracks how fast a customer reaches their first measurable result.
• Adoption: AI-native adoption is measured by workflow penetration and active agent density, not seat count. As AI replaces human-driven usage, the unit of adoption shifts from people to automated workflows and agents.
• Net credit retention (NCR): Credit-volume retention across the customer base, tracked separately from net recurring revenue to avoid price-change impact.

Along with these new metrics, the industry’s transformation is prompting companies to retire or recalibrate old SaaS measures, including per-seat ARR as a primary key performance indicator (KPI), traditional magic number calibrated to subscription dynamics, unadjusted Rule of 40, customer success metrics tied to human touchpoints, and blended gross margin without AI COGS carve-outs.

What does this mean for enterprise value calculations?

As the internal metrics of success change, so do the ways the investment community measures growth and long-term viability.

Increasingly, a company’s valuation multiple depends on whether its revenue behaves like committed subscription ARR or volatile usage ARR, and the commit‑to‑burndown ratio is the metric investors use to decide where the company fits.

For example, a business with 80% committed credit ARR could trade closer to subscription comps and one with 80% burndown could trade closer to usage comps even though both have the same types of customers. Being able to proactively explain the commit‑to‑burndown mix can help companies avoid undervaluation.

In addition, utilization is expected to replace net promoter scores and seat usage as the primary predictor of churn or expansion. Low utilization guarantees downsizing at renewal, so companies must track utilization cohorts the same way SaaS tracks logo retention cohorts today.

We’re also seeing an inversion of the operating model, with R&D and COGS moving up the P&L and sales and marketing (S&M) and customer success (CS) moving down or sideways. The net operating leverage profile is structurally different from classical SaaS, and the cost-to-scale curve looks different too.

Finally, credit margin engineering is a hidden value-creation lever. The gap between price per credit and cost per credit is set by the software vendor and can be optimized. Most operators have barely started managing this rigorously, and the ones who do will pull away on margin.

What this means for leaders, boards and investors

The shift from classic SaaS metrics to new AI‑native measures isn’t cosmetic. It represents the seismic change the industry is experiencing as AI matures and transforms products and organizations.

While these metrics — and perhaps others yet to be determined — may evolve over time, there is no doubt they are already changing how AI companies allocate capital, price products, incent sales teams, evaluate performance and communicate with investors.

It’s important to remember that SaaS metrics were practical tools for a specific era of software. As that era draws to a close, winning companies will choose new metrics that shape behavior and drive smart decision-making.

The views reflected in this article are the views of the author and do not necessarily reflect the views of Ernst & Young LLP or other members of the global EY organization.

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

hasan as’ari – shutterstock.com

SAP-Anwenderunternehmen stehen unter Druck, auf SAP S/4HANA zu wechseln, weil die Mainstream-Wartung für SAP ERP (SAP ECC 6.0) Ende 2027 ausläuft und die bis Ende 2030 geltende erweiterte Wartung kostenpflichtig ist.

Zwar stellt SAP mit der „SAP ERP, Private Edition, Transition Option“ eine weitere Wartungsverlängerung bis 2033 in Aussicht. Da diese einer Neuimplementierung gleichkommt, bleibt SAP-Kunden mehr Zeit für die Planung, die Analyse und das Changemanagement. Der Nachteil: Wer diese Option nutzt, läuft Gefahr, technologisch ins Hintertreffen zu geraten, da Innovationen nahezu ausschließlich für SAP S/4HANA bereitgestellt werden.

Zögerliche SAP-S/4HANA-Transformation trotz Wartungsdruck

Obwohl der Druck hoch ist, hat eine große Zahl der SAP-Bestandskunden die Transformation auf die seit 2015 verfügbare ERP-Suite offenbar noch nicht vollzogen. Eine COMPUTERWOCHE-Expertenrunde zeigte, wo die größten Hürden liegen und was erfolgreiche Projekte auszeichnet.

Warum etliche Unternehmen die Transformation vor dem regulären Wartungsende scheuen und stattdessen zwei Prozent Mehrkosten für die erweiterte Wartung einkalkulieren, brachte ein Teilnehmender auf den Punkt: Firmen haben über Jahrzehnte in ihre SAP-ERP-Lösung investiert und sie an individuelle Prozessanforderungen angepasst, damit die Abläufe entlang der Supply Chain reibungslos laufen. Er habe daher in den vergangenen zehn Jahren keinen Kunden erlebt, der freiwillig umsteigen wollte. Alle hätten gesagt, dass sie müssen.

Nach Erfahrungswerten eines weiteren Experten nutzen erst rund 20 Prozent der SAP-Kunden SAP S/4HANA als Kernapplikation produktiv, unter anderem, weil entsprechende Transformationsprojekte auf sieben bis neun Jahre angelegt sind.

Altlasten bremsen die SAP-S/4HANA-Transformation

Unternehmen, die sich für den Wechsel entscheiden, verzichten häufig auf jede Modernisierung. Sie vollziehen einen Eins-zu-eins-Umstieg ohne Code-Modifikation, sei es in Form einer System Conversion (Brownfield-Ansatz) oder per Lift and Shift in SAP Cloud ERP Private (früher: SAP S/4HANA Cloud Private Edition). Dabei ist eine große Zahl von SAP-ERP-Installationen gar nicht zukunftsfähig, weil sie auf Prozessen aus den 1990er Jahren basieren und im Lauf der Jahre durch zahlreiche Eigenentwicklungen erweitert wurden.

Nicht selten gibt es bis zu mehrere tausend kundeneigene Programme im Z/Y-Namensraum, die zum Teil nicht mehr genutzt werden und das System unnötig belasten. Die Experten waren sich einig, dass eine solche rein technische Migration, bei der Altlasten wie ABAP-Eigenentwicklungen mitgeschleppt werden, keinen Mehrwert für das Unternehmen bringt.

Es muss geprüft werden, welche Eigenentwicklungen beibehalten werden, weil sie wettbewerbsdifferenzierend und damit geschäftskritisch sind, und welche gelöscht werden müssen, weil sie nicht genutzt werden oder weil es dafür inzwischen SAP-Standardfunktionen gibt. Handlungsbedarf besteht auch bei einer dreistelligen Anzahl von Buchungskreisen, von denen niemand weiß, welche noch benötigt werden, oder bei zahlreichen Dubletten in den Kreditoren- und Debitorenstammdaten.

Migrations-Tools und KI-Agenten beschleunigen den Umstieg

Um diesen Prüf- und Bereinigungsaufwand zu bewältigen, bietet SAP mehrere Tools, um die Transformation auf SAP S/4HANA zu vereinfachen: darunter SAP Activate, SAP Cloud ALM, Migration Cockpit, Readiness Check, Custom-Code-Check oder Modifikationsabgleich. Ergänzt werden sie durch Lösungen wie Signavio für die Prozessanalyse. Die Experten schätzen den Effizienzgewinn durch solche Migrationswerkzeuge auf 30 bis 50 Prozent.

Zusätzliche Produktivität versprechen KI-Agenten, die Altsysteme automatisiert analysieren, Code bereinigen und Datenflüsse transformieren. Das reduziert den Migrationsaufwand und beschleunigt den Umstieg.

Scope-Management als Schlüssel für den Projekterfolg

Einig waren sich die Teilnehmenden, dass SAP-S/4HANA-Transformationsprojekte in der Regel nicht an der Technologie scheitern, sondern an einer mangelhaften Scope-Definition und am unzureichenden Changemanagement.

Ein Scope-Management vor dem Projektstart, das berücksichtigt, wie viel Veränderung der IT-Organisation und den Fachbereichen zugemutet werden kann, sei essenziell für den Erfolg, sagte einer der Teilnehmenden. Es erfordert die Fähigkeit zu priorisieren und ein iteratives Vorgehen, bei dem zunächst geschäftskritische Must-haves und Quick Wins umgesetzt werden. Weniger wichtige Nice-to-haves folgen später. Wer dagegen in der Konzeptionsphase bereits den großen Wurf anstrebt, wird voraussichtlich scheitern. Als Beispiel wurde der direkte Umstieg auf ein SAP-S/4HANA-Kernsystem genannt, das nach dem Clean-Core-Ansatz von nicht mehr lauffähigen Programmen und obsoleten Erweiterungen bereinigt ist.

Genauso wichtig ist ein Change-Management, das Mitarbeitende von Beginn an einbezieht, die nötige Akzeptanz schafft und vom Top-Management aktiv unterstützt wird, sowie eine verbindliche Governance mit klaren Zielvorgaben. Unverzichtbar ist auch die Einbindung der Fachbereiche. Sie stellt die größte Herausforderung dar, da Unternehmen befürchten, dass durch die SAP-S/4HANA-Transformation zu viele personelle Ressourcen gebunden werden, die dann für Kernaufgaben fehlen. Kommt es vor, dass IT und Fachbereiche als Antipoden agieren, sollte ein Change-Coach als Vermittler eingesetzt werden.

Hybride Betriebsmodelle setzen sich langfristig durch

Bereits vor dem Projektstart muss abschließend geklärt sein, welches Betriebsmodell für SAP S/4HANA am besten zu einem Unternehmen und seinen Zielen passt, auch mit Blick auf regulatorische Anforderungen. Das ist häufig nicht der Fall, sodass das Projektteam unnötig Zeit damit verbringt, das passende Betriebsmodell zu ermitteln. Das bremst Transformationsvorhaben aus.

Nach Ansicht eines Teilnehmenden wird sich langfristig ein hybrides Betriebsmodell durchsetzen, bei dem der SAP-Kunde entscheidet, welche Elemente der SAP-S/4HANA-Landschaft in einer Hyperscaler-Cloud, einer souveränen Cloud und/oder On-Premises laufen. Eine weitere, weitgehend unbekannte Möglichkeit ist der Betrieb im Rahmen der Customer-Data-Center-Option (CDC) von SAP Cloud ERP Private (früher: SAP S/4HANA Cloud Private Edition), die aus Gründen wie Datenschutz, Leistung und Souveränität eine interessante Alternative sein kann.

Mehrere Experten stellen darüber hinaus fest, dass die vollwertige SaaS-Lösung SAP Cloud ERP Public (früher: SAP S/4HANA Cloud Public Edition) inzwischen verstärkt eingesetzt wird. Sie stellt vorkonfigurierte Kern-ERP-Funktionen (Best Practices) bereit und lässt sich relativ schnell einführen, ermöglicht aber kaum individuelle Anpassungen. Diese Abstriche nehmen Unternehmen in Kauf, um von regelmäßigen, automatischen Upgrades und technologischen Innovationen zu profitieren.

Kritisiert wurde allerdings, dass die Cloud-Diskussion häufig unter begrifflichen Unschärfen leidet. So macht der Betrieb von SAP S/4HANA in einer Hyperscaler- oder SAP-Cloud die Lösung noch lange nicht zum Software-as-a-Service-Angebot. Solche Ungenauigkeiten irritierten SAP-Kunden und bremsten die Entscheidungsfindung. Letztlich sind beim Cloud-Betrieb auch die Kosten entscheidend. Zwar wollen viele Unternehmen anfangs maximale Sicherheit mit Private Network und Confidential Computing, wählen dann aber günstigere Commercial-Cloud-Angebote. Ausnahmen bilden regulierte Branchen und der öffentliche Sektor.

Ob hybrides Betriebsmodell oder Kostenfrage, am Ende entscheidet über den Projekterfolg nicht allein die Technologie, sondern auch, wie diszipliniert Scope und Wandel im Unternehmen gesteuert werden.

Teilnehmer der Round-Table “SAP S4HANA 2027”

Harald Becker / Hewlett-Packard GmbH

Sonja Brüggemann / Lufthansa Industry Solutions GmbH & Co. KG

Microsoft Deutschland GmbH

VOGUS – Wolfgang Voglhuber / Natuvion GmbH

smartShift Technologies GmbH

You are one of the six billion people (75% of the world population) online today, and every click you make is routed through the data center. Data centers, whether knowingly or unknowingly, play a very critical role in your daily online activities. With an increasing population, increasing usage of online presence, and now omniscient AI, the demand for data centers has increased manyfold, and the trend seems similar to the year 2000, when telephone towers were built to accommodate increased digital presence.

To win the AI race, Hyperscalers (Google, Meta, Amazon, Microsoft, Alibaba, Oracle, IBM, Tencent) are spending huge amounts of money on data center development. In the USA, the hyperscalers are planning to spend $650 billion in 2026, which is around 70% higher than 2025 spending, according to Yahoo Finance.

As per McKinsey research, by 2030, companies will invest around $7 trillion in Capex on data center infrastructure globally. More than $4 trillion will go towards computing hardware investment. More than 40% of this spending will be invested in the United States.

Demand growth in data centers

McKinsey analysis shows that global demand for data center capacity can more than triple by 2030, with a compound annual growth rate (CAGR) of around 22 per cent. In the USA, data center demand could grow by 20-25 per cent at the same time.  

The data center industry is currently undergoing a violent transition. We are moving away from the era of “bespoke projects” — where every facility was a unique architectural feat — into an era of industrialized infrastructure. With global capital expenditure in the sector projected to hit $3 trillion by 2028, the “bottleneck” has shifted. It is no longer about securing the capital; it is about the physics of the supply chain.

During my tenure at Vantage, managing the intersection of data center construction management (DCCM) and infrastructure management (DCIM), I saw firsthand that the most successful players aren’t those with the deepest pockets, but those with the most integrated data threads. If your construction data in Procore doesn’t talk to your financial reality in Yardi, or your operational capacity in DCIM, you aren’t building a data center — you’re managing a $500 million blind spot.

The death of “sticks and bricks”

Traditionally, data center construction was treated as civil engineering. But for the modern CIO, a data center is a complex product assembly.

The challenges are systemic. We are facing 50-to-80-week lead times for critical “long-pole” items: extra-high-voltage transformers, switchgear, and the liquid cooling manifolds required for the next generation of AI chips. In this environment, the traditional reactive supply chain model is a liability.

To survive the $3 trillion inflow, we must adopt a hybrid-agile SCOR (supply chain operations reference) model. This means applying continuous flow logic to standardized components (like modular power skids) while maintaining agile responsiveness for the volatile IT layer.

The digital bridge: Construction management software  to ERP

The most significant opportunity for CIOs lies in financial-operational integration. In many organizations, there is a data chasm between the construction site and the corporate office. Construction teams live in the construction management software tracking tasks, trades, RFIs and payment submittals. Finance teams operate corporate offices with project management tools (worth remembering that email is a key tool besides spreadsheets and phone calls) tracking capex schedule, commissioning timeline, capital drawdowns and asset lifecycle management.

These systems are siloed; the CIO loses visibility into the total cost to serve. By integrating construction management into the financial system, we create real-time financial visibility of the build. We can see exactly how a three-week delay in a chiller delivery impacts the internal rate of return (IRR) of the entire asset. This isn’t just accounting; it’s strategic telemetry.

From BIM to DCIM: The lifecycle thread

The second bridge is the handoff from construction (BIM) to operations (DCIM). Historically, this handoff was a nightmare of PDFs and Excel sheets. By the time the operations team took the keys, the “as-built” design information was already out of date.

The opportunity today is to maintain a continuous data thread. The sensor data and asset tags established during the “make” phase in our SCOR model should flow directly into the DCIM. This allows us to perform virtual commissioning. Before a single server is racked, we should already have a digital replica of the airflow, power distribution, and cooling capacity.

The scientific inference: AI in the supply chain

As someone who has led data and AI initiatives, I’ve seen the hype. But in the supply chain, the application of AI must be pragmatic, not generative. We don’t need AI to write poems; we need it for predictive procurement. Most organizations manage their procurement in ERP or a mix of a few tools to manage the source-to-settle business flow. Adopting a system workflow improves data collection and the state of the procurement cycle, which in turn provides AI with the context to draw inferences for possible delays and anomalies in original specifications and change orders.

By applying machine learning to global logistics data, we can move from just-in-time to just-in-case modeling. AI can analyze geopolitical risks, shipping lane congestion, and raw material pricing to tell a CIO: “Order your switchgear 14 months early, or your Q3 2027 ‘Power On’ date is at risk.”

Bringing it all together: AI in the supply chain and finance

Why it matters: Approximately 70% of the capex is on this workflow and making timely decisions that directly impact the ready-for-service dates. The current challenge of reactionary adjustment in design to procurement to local fit-out is a significant drain on capex efficiency and cost of capital. Because single-project delivery delays have become so volatile, a massive structural shift is occurring in how digital infrastructure is funded. Single-project debt (special purpose vehicles or SPVs) is facing severe friction. To insulate themselves from RFS shocks, the largest institutional players are moving toward permanent platform capital — aggregating exposure across dozens of global assets simultaneously.

Navigating these complex multi-billion-dollar engineering projects distributed over a large geography is simply unmanageable without rethinking and re-engineering existing tools and processes.

The roadmap for the modern CIO

To lead this transformation, CIOs must move beyond the IT shop mentality and become master orchestrators of the supply chain. Here is the 1500-word reality condensed into three mandates:

1. Standardize the product: Stop designing bespoke facilities. Move toward DFMA (design for manufacturing and assembly). If 70% of your data center can be built in a factory and shipped as modules, you bypass the unpredictability of on-site labor.
2. Integrate the financial stack: If your construction management software and your ERP aren’t sharing a heartbeat, your data is lying to you. Force the integration between Procore and Yardi.
3. Own the long poles: Don’t leave the procurement of transformers and cooling units to general contractors. Use your balance sheet to secure these items years in advance. In 2026, inventory is the new currency.

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

Your CFO has a simple question. “We’re spending more on AI. What are we getting for it?” Most CIOs cannot answer it — not because AI isn’t creating value, but because the accounting systems we inherited were built before AI existed as a category of labor.

This June, the conversation shifted from token maxing to token cutting. The New York Times reported that Meta, Uber, Walmart and Amazon are capping employee AI usage. Uber blew through its 2026 AI budget in four months. Satya Nadella started framing it as human capital versus token capital.

All of that is true. None of it answers the CFO. Capping tokens is an input lever, not an output measure. And the human-versus-token framing names two sources of labor when the reality is four.

The enterprise now has 4 sources of labor

There are humans. There are humans assisted by AI. Humans are working alongside AI. And humans are managing AI. Sources two through four are all supervised machine labor at different intensities — none of them have a line item, a manager or an hourly rate. In our 2026 AI Labor Report, 78% of leaders view AI as both software and a labor force. The org chart has not caught up. Neither has the P&L.

Lexi Reese

Most enterprises are stuck at A-Level 1 with no accounting for any of it, while quietly sliding into A-Level 2. The job descriptions have not caught up. The budget has not caught up. You cannot upskill into a role that has not been named.

AI is the only category of work the modern enterprise has ever bought without a system of record for what it produced.

What you are actually running is supervised machine labor

The model does a first pass. A human makes it usable. One hundred percent of leaders we surveyed said AI work requires human review before it ships; 34% said substantial editing. That is a workforce with no manager, no hourly rate and no line on the income statement.

The accounting breaks in 3 places at once

Under GAAP: COGS if it helps produce the product, OpEx if it does work for you. The same workflow can hit all three buckets at once. A tier-one support resolution involves the human’s salary (OpEx), the AI’s tokens (COGS if support is a delivered service), and the supervisor’s review time (OpEx). Three buckets. One piece of work. No reconciliation. The token invoice arrives from Anthropic or OpenAI and gets coded to OpEx-software because that is what the bill looks like. Audit partners will be asking about this by next year.

When you call AI a tool, you book it like software. When you call it labor, you have to ask which kind and what it is producing.

The per-employee number is the wrong unit

Per-employee AI spend collapses a workforce into a per-head average. It hides the only number that matters: What AI is producing inside each workflow.

Lanai measured two teams inside the same finance organization. Same monthly prep and variance analysis. AI took the same amount of time to produce outputs of similar quality. The only variable was the model each team reached for by default — a choice nobody had made deliberately and nobody had seen until it was measured.

Lexi Reese

The gap existed for months before anyone saw it.

Faith-based budgeting — the organizational equivalent of putting money in the collection plate and hoping God handles the ROI — is what made it invisible.

Lexi Reese

AI labor orphaning

That is not a measurement problem. It is a category error. We call it AI Labor Orphaning. AI does the work. The output gets credited to the human who approved it. The token bill lands in OpEx-software. The supervision time absorbs into salaried hours nobody is auditing. Eighty-seven percent of leaders admitted AI output is sometimes or always credited entirely to the human employee. This is the last-click attribution problem of the AI era, running in reverse.

What fills the vacuum? Belief. Forty-three percent assume that if AI was involved, it contributed. Only twelve percent have a clear methodology. Seventy-nine percent are worried AI budgets will be cut because they cannot connect spend to results. The cuts are not coming because AI does not work. They are coming because nobody can prove that it did.

Capping tokens may look like responsible governance, but it is like turning off a staticky radio rather than tuning the dial. The companies cutting AI budgets in 2026 will discover in 2027 that they cut the workflows that worked alongside the ones that did not.

The real cost of AI is not the model. It is the redesign

Three layers. Most organizations only manage the first.

Lexi Reese

What to actually do

The 12% of organizations that can answer the CFO treat AI like every other category of labor — with a cost per AI Work Hour that is accounted for by a set of AI assistants, co-pilots and agents that are held accountable to performance standards. 

• Audit the four sources separately. Each A-Level has different token economics, SaaS implications and human redesign requirements.
• Find the embedded SaaS repricing before your next renewal. Pull your top 20 contracts. Ask whether AI features previously included are now priced incrementally.
• Redesign the human role at A-Level 2 before you scale it. You cannot upskill into a role that has not been named.
• Build a system of record before you build the next agent. Start with one department. Two weeks. You will find something that surprises you.
• Stop calling it a tool. Start calling it labor. The language determines the chart of accounts.

When your blended AI rate is $22 an hour, the conversation shifts from ‘we spent $340,000 on AI’ to ‘we acquired a skilled workforce at $22 an hour.’ That sentence is defensible. A vendor invoice is not.

The CIOs who will have a defensible AI story in 2027 are the ones who renamed the work in 2026. Not because technology changed. Because they finally built the accounting to see it.

Findings are drawn from the 2026 AI Labor Report, fielded by Wakefield Research with 200 senior technology leaders at US enterprises of 1,000-plus employees, March 20–April 8, 2026 (±6.9pp at 95% confidence).

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

Outsourcing worked – until it didn’t.

After Akirolabs achieved early market validation and onboarded its first enterprise customers, outsourcing began to create strategic limitations around scalability, intellectual property (IP) ownership, security and delivery execution.

The challenges started after the first enterprise customers confirmed product-market fit. At that point, delivery speed became directly tied to business growth. Product quality expectations increased. Infrastructure and security requirements became stricter. Investors started asking difficult but fair questions about IP ownership, operational dependencies and long-term scalability.

Most importantly, engineering execution was no longer just an operational function – it became part of the company’s strategic advantage. That was the moment when the founders decided the company needed dedicated technology leadership to address these challenges. This is how I joined the company at the beginning of 2023. As VP of Engineering and a bit later as CTO, I led the transformation (usually known as insourcing, repatriating or backsourcing) from an outsourced model to an internal engineering organization while maintaining product delivery continuity and preparing the company for the next growth stage. The process took roughly a year and involved not only technical migration, but also organizational design, hiring, process development, infrastructure modernization and cultural transformation – everything from the ground up.

Building an internal engineering organization while still delivering

One of the biggest misconceptions about insourcing is that it is primarily a technical project. It is a leadership and execution challenge.

When I joined the company, there was effectively no internal engineering structure, limited visibility into the existing system and no clear long-term technical strategy. My first months were dedicated to understanding reality and I began with a comprehensive assessment of the codebase, operational risks, documentation quality and knowledge dependencies to determine the most viable transition strategy.

Very early in the process, I faced a critical strategic decision: whether to gradually assume ownership of the existing platform or rebuild it internally. To make that decision, I evaluated four distinct transition models ranging from limited management insourcing to a complete internal rebuild.

After assessing the technical, operational and long-term business implications of each approach, I selected the most demanding option: rebuilding the product internally while maintaining uninterrupted delivery for existing customers. Although riskier in the short term, a full rebuild offered the clearest route to complete IP ownership, architectural flexibility and long-term scalability.

At the time, this decision ran counter to the approach typically taken by startups in similar situations. Most organizations gradually assume ownership of an existing codebase to minimize short-term risk and preserve delivery capacity. My assessment was that the accumulated architectural debt, fragmented knowledge distribution and long-term maintenance risks would ultimately make a phased takeover more expensive and less scalable than a controlled rebuild. The strategy required significantly higher execution discipline, but it allowed us to establish complete ownership of the platform, eliminate inherited constraints and create an architecture capable of supporting enterprise-scale growth.

The next challenge was hiring.

In Germany, hiring can easily take four to six months – mostly due to a typical 3-month notice period, which is incompatible with startup timelines. We solved this by building a hybrid organization structure early: a lean internal core team combined with carefully selected contractors. Instead of hiring only narrow specialists, we prioritized experienced generalists capable of operating across architecture, infrastructure, security and compliance discussions. Later, we evolved toward a product engineering model, where engineers owned broader product outcomes rather than narrowly defined technical functions.

During the first three months, we established a core engineering team of four senior engineers. Over the following nine months, the organization expanded to roughly fifteen engineers while I strategically designed and executed the transformation of the platform’s architecture to meet the rigorous deployment and compliance standards of our first enterprise clients, including Raiffeisen Bank International and Bertelsmann. This structural overhaul allowed the company to meet the deployment, security and compliance requirements of enterprise customers that had previously been inaccessible under the outsourced model. At that point, we had already achieved complete coverage across backend, frontend, DevOps, QA and security.

I also intentionally kept processes lightweight during the transition. Instead of introducing heavyweight frameworks, we focused on clarity of priorities, fast decision-making and execution discipline. We used Kanban over Scrum, eliminated unnecessary meetings, shortened the remaining ones and emphasized engineering culture over process overhead.

Another major challenge was project estimation. Because dual-track development was unavoidable until the in-house platform reached production readiness, estimation accuracy had a direct impact on budget efficiency. Despite all challenges, my initial estimate ultimately proved remarkably close to the final delivery date, differing by only about a week. Accurate forecasting under conditions of parallel development streams, ongoing customer commitments and active team formation became a critical leadership challenge. Maintaining this level of predictability throughout the transition helped align engineering execution with business planning, hiring decisions and investor expectations.

The engineering transformation enabled capabilities that contributed to Akirolabs being recognized as an IDC Innovator in Procurement in 2023, named amongst the Top 27 AI Startups in Germany in 2024, Sifted’s 100 Fastest-Growing Startups in DACH & CEE 2025 and inclusion in 2024-2026 in ProcureTech100 annual recognition of procurement technology providers shaping the future of digital procurement.

Managing risk without slowing down the business

The hardest part of insourcing is not writing code, selecting the technology stack, designing architecture or configuring infrastructure. It is avoiding disruption while the company is changing underneath the product. I successfully orchestrated the concurrent overhaul of product architecture, cross-functional engineering recruitment, infrastructure modernization and live customer operations under exceptionally tight margins.

To reduce delivery risk, we approached the transition in layers.

First, we focused on infrastructure reliability and operational readiness before feature expansion. Cloud architecture, recovery testing, permission segregation and incident management processes were implemented early, not after launch. We also introduced multiple testing stages and dedicated QA functions after learning the hard way that a “developers-only” quality control approach does not scale for complex web platforms and business domains.

Second, we established a structured knowledge-transfer process to rapidly onboard engineers and reduce external dependencies.

Third, we became extremely disciplined about scope management. One of the most common reasons insourcing initiatives fail is uncontrolled change during the rebuild phase. Every new feature request increases uncertainty non-linearly. We learned to separate strategic improvements from distractions and protect the core delivery roadmap aggressively. Throughout the transition, we successfully maintained uninterrupted customer operations by utilizing planned maintenance windows, achieved a near-zero-downtime migration and permanently doubled product velocity immediately following the migration.

Beyond the technical migration itself, the transition established a repeatable operating model for scaling technology organizations beyond the product-market-fit stage. The framework combined organizational redesign, controlled knowledge repatriation, architecture modernization and enterprise-grade operational practices while maintaining uninterrupted customer delivery throughout the transformation. While the implementation was specific to Akirolabs, the underlying principles are broadly applicable to organizations seeking to transition from outsourced development to internal product ownership without disrupting business operations.

By the time the new platform reached production readiness, I had established not only a functioning engineering organization, but also a stable operational model: internal ownership, production-grade infrastructure, security processes, scalable hiring practices and clear technology and product roadmaps.

A positive side effect of the transition was the creation of internal UI/UX and Data Science capabilities, which later became strategically important for AI product initiatives and created a foundation for the third version of the product, which we released in mid-2025.

My technical restructuring and migration to a secure proprietary platform reduced architectural risk, established full in-house ownership and helped strengthen investor confidence during the company’s successful €5M fundraising round in 2024.

The transition created a stronger foundation for scale and supported the company’s continued expansion among enterprise organizations operating at Fortune 500 scale, including Ahold Delhaize, Workday, IFF, Deutsche Bahn and others.

Lessons learned for CTOs considering insourcing

Looking back, several decisions made the transition successful, and several mistakes made it harder than necessary.

The first lesson is simple: decisiveness in strategic transition is paramount to maintaining business momentum. Rapidly evaluating insourcing frameworks and defining clear boundaries with the external partner allowed us to mitigate operational downtime and execute a highly efficient migration ahead of critical market deadlines.

Second, hire more senior people and do it as early as possible. Strong technical leaders multiply execution capacity far beyond their individual contribution. In our case, the quality of the first hires influenced architecture quality, hiring standards, delivery discipline and engineering culture for the entire organization.

Finally, culture matters more than frameworks. Processes can be added later. Ownership mentality cannot.

The biggest long-term advantage of bringing development in-house was not simply faster execution, not better code quality or operational cost optimization by over 30% after the transition which we also achieved. It was an alignment. Product strategy, engineering decisions, customer priorities and business goals became part of the same conversation instead of being separated by organizational boundaries. For technology companies operating in highly competitive markets, that alignment becomes a compounding advantage over time.

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

I use a very cool and relatively new web framework called Astro. The keen insight that the Astro team had was that most websites are made up of static content, so they made it really easy to add content to a website. To add a blog post to my personal website, all I have to do is create a Markdown file with some front matter, deploy it, and the blog post automatically appears. If I need to reach deeper for more dynamic functionality, I can easily do that with TypeScript, React, or almost any other framework. It’s really cool.

And these days, I really don’t write any code. Claude Code does most (all?) of the work. Since Astro is an open-source project and has excellent documentation, Claude knows all about how Astro works. It has no trouble at all managing my site and making the improvements I ask for.  

And that got me thinking, how does Astro get built? Is the Astro team building with agentic coding? Astro itself has many dependencies, including big projects like Vite and Node. And of course, Vite and Node have dependencies, too. Are those dependencies being developed by hand, or are those development teams also using AI agents to code?

My curiosity got the best of me, and I asked Claude to dig deeper. It turns out that the Astro repository has an AGENTS.md file, and some of the commits even have commit message trailers indicating that they were at least co-authored by Claude and GitHub Copilot. Further down, there is a .agents/skills directory with skills covering development, merging, triage, and more. I poked around for a look, and someone has done a great job building agentic support.

Now my interest is really piqued, and further investigation reveals quite a bit of interesting stuff. About a year ago, documentation started appearing about how to build Astro sites with coding agents.  Around that same time, the docs team released an MCP server that gives developers coding agents deeper, easier access to the Astro documentation.  

And there are small steps in the Astro codebase that indicate it is “agentic ready.” For instance, the command-line development server can tell when it is being started by an agent, and the application itself can tell if it is being driven by an agent. Small things, but steps in the direction of embracing Astro developers who use coding agents. 

Okay, that was a fun spelunking trip. But so what?

The “so what” is that code is going to be commoditized. As an Astro developer I am using AI agents pretty much all of the time. The Astro development team is starting to use AI agents more and more. The folks building the Astro dependencies are using AI agents. Shoot, the people building Claude Code and the agents themselves are “eating their own dogfood” and using their own tools to build the next frontier model. Before we know it, it will be turtles all the way down. 

No one says “who generated that electricity?” or “who wove the fabric in that shirt?” any more. And it won’t be long before no one says “Who wrote the code for that app?” because it won’t matter. Just as we don’t look at the assembly code written by our compilers, we’ll stop looking at the “regular” code written by our agents. I’m not even sure anyone is writing assembly code anymore. Soon we’ll be saying that about TypeScript, Python, and C++.

Model Context Protocol (MCP) verbindet KI-Agenten mit Datenquellen und erfreut sich im Unternehmensumfeld wachsender Beliebtheit. Allerdings ist auch MCP nicht frei von Sicherheitslücken, wie entsprechende Entdeckungen, etwa beim SaaS-Anbieter Asana oder dem IT-Riesen Atlassian gezeigt haben. Inzwischen hat sich jedoch einiges in Sachen MCP-Sicherheit getan. Einerseits wurden mit Blick auf das Kernprotokoll etliche Fortschritte erzielt. Beispielsweise in Form von Support für OAuth sowie für Authentifizierungs-Server von Drittanbietern und Identity-Management-Systeme. Darüber hinaus wurde inzwischen auch eine offizielle MCP Registry geschaffen, die einen Überblick über sichere, öffentlich verfügbare MCP-Server bietet.

Dennoch bestehen weiterhin Sicherheitslücken, die sich für diverse Cyberschandtaten ausnutzen lassen – Prompt Injection, Tool Poisoning, Token-Diebstahl, Server-übergreifende Attacken oder manipulierte Messages sind nur einige von vielen Beispielen. Mit anderen Worten: Unternehmen, die sich beim Aufbau von Agentic-AI-Systemen einen Wettbewerbsvorteil verschaffen wollen, müssen erhebliche Anstrengungen unternehmen, um zu gewährleisten, dass sensible Daten nicht nach außen dringen. Glücklicherweise gibt es diverse Tools, die dabei Unterstützung versprechen.

In diesem Artikel lesen Sie:

• was Security-Tools für MCP leisten sollten, und
• welche Angebote in diesem Bereich interessant sind.

Das sollten MCP-Sicherheitslösungen können

Die Gefahr von Datenlecks, Prompt Injections und weiteren Sicherheitsbedrohungen besteht unabhängig davon, ob Unternehmen:

• ihre eigenen KI-Agenten mit MCP-Servern von Drittanbietern,
• ihre eigenen MCP-Server mit Drittanbieter-Agenten, oder
• ihre eigenen Server mit den eigenen Agenten verbinden.

Soll heißen: Unternehmen müssen in jedem Fall Autorisierungen und Berechtigungen überprüfen, detaillierte Zugriffskontrollen implementieren und alles protokollieren. Daraus ergeben sich auch die Anforderungen für MCP-Sicherheitslösungen. Diese sollten bieten:

• MCP-Servererkennung. Für Mitarbeiter eines Unternehmens ist es einfach, MCP-Server herunterzuladen und zu nutzen. Mit Scan-Services für MCP-Server können Unternehmen sämtliche Instanzen von Schatten-MCP-Servern in ihrer Umgebung finden.
• Laufzeitschutz. KI-Agenten kommunizieren mit MCP-Servern in natürlicher Sprache. MCP-Sicherheits-Tools sollten deshalb in der Lage sein, diese Kommunikation auf Sicherheitsprobleme wie Prompt Injections hin zu überwachen.
• Authentifizierungs- und Zugriffskontrollen. Das MCP-Protokoll unterstützt inzwischen OAuth, aber das ist nur ein erster Schritt. Für zusätzliche Sicherheit empfehlen sich Tools mit integrierten Kontroll-Frameworks für Zero Trust und Least Privilege.
• Logging und Observability. Tools und Plattformen sollten zudem die Möglichkeit bieten, MCP-Protokolle zu sammeln, Sicherheitsteams über Richtlinienverstöße zu informieren, Compliance-Daten zu erfassen oder Protokolle in die bestehende Sicherheitsinfrastruktur einzuspeisen.

MCP-Security-Angebote

Im Folgenden haben wir die Anbieter von MCP-Security-Tools in drei Kategorien aufgeteilt. Diese Aufstellung erhebt keinen Anspruch auf Vollständigkeit.

Hyperscaler

Für Unternehmen, die sich vollständig auf eine bestimmte Cloud-Plattform verlassen, bieten die MCP-Tools des jeweiligen Hyperscalers einen einfachen Einstieg.

• Amazon Web Services (AWS) hat Mitte 2025 seine eigene agentenbasierte KI-Plattform eingeführt. Amazon Bedrock AgentCore umfasst ein Gateway, das mehrere Protokolle unterstützt (darunter auch MCP), ein Identity-Management-System sowie Observability.
• Microsoft bietet einen grundlegenden Azure-MCP-Server an, inklusive Support für Azure Key Vault. Darüber hinaus unterstützen auch Azure AI Foundry Agent Service und Azure API Management das Model Context Protocol. Zudem bietet Microsoft mit dem Agent Framework auch ein Open-Source-Entwicklungskit, das sowohl MCP als auch Agent2Agent unterstützt und beispielsweise Schutz vor Prompt Injections verspricht.
• Google Cloud kündigte Anfang 2025 seine MCP Toolbox für Datenbanken an – inklusive integrierter Authentifizierung und Observability. Außerdem hat der Hyperscaler auch eine Referenzarchitektur veröffentlicht, um MCP-Server auf seiner Cloud-Plattform abzusichern.

Große Plattformanbieter

• Der IT-Dienstleister Cloudflare hat mit MCP Server Portals ein Tool veröffentlicht, mit dem Unternehmen MCP-Verbindungen zentralisiert absichern und überwachen können. Die Funktion ist Bestandteil der Cloudflare-One-Plattform.
• Palo Alto Networks hat mit Blick auf MCP-Sicherheit mehrere Eisen im Feuer. Mit Prisma AIRS hat das Unternehmen einen eigenen, intermediären MCP-Server veröffentlicht. Dieser sitzt zwischen den KI-Agenten und dem eigentlichen MCP-Server und erkennt schadhafte Inhalte und Daten. Das Tool MCP Security ist hingegen Bestandteil von Cortex Cloud WAAS und überprüft die MCP-Kommunikation an der Netzwerkgrenze auf bösartige Aktivitäten.
• SentinelOne gewährt mit seiner Singularity Platform ebenfalls Einblick in die MCP-Interaktionskette und bietet zum Beispiel Warnmeldungen und automatisierte Incident Response für MCP-Server auf lokaler oder Remote-Ebene.
• Die Plattform von Acuvity (seit Februar 2026 Teil von Proofpoint) verspricht, MCP-Server umfassend abzusichern. Dafür sorgt laut dem Anbieter eine Kombination aus Least-Privilege-Execution, unveränderlichen Laufzeiten, kontinuierlichen Schwachstellenscans, Authentifizierung und Bedrohungserkennung.
• Daneben hat auch Broadcom MCP-Sicherheitsfunktionen für VMware Cloud Foundation angekündigt, die künftig mehr Sicherheit für agentenbasierte Workflows gewährleisten sollen.

Startups

• Das API-Security-Startup Akto hat eine MCP-Security-Plattform im Angebot. Sie umfasst ein Discovery Tool, um MCP-Server in Unternehmensumgebungen zu identifizieren, Security-Testing-Werkzeuge sowie Monitoring- und Threat-Detection-Funktionen.
• Invariant Labs bietet mit MCP-Scan ein quelloffenes Tool, das die statische Analyse und Echtzeitüberwachung von MCP-Servern ermöglicht. Mit Guardrails hat das Startup auch ein kommerzielles Produkt im Angebot. Dabei handelt es sich um einen Proxy. Der zwischen KI-Agenten und MCP-Servern sitzt und vor Security-Risiken schützen soll. Das Tool befähigt Anwender außerdem dazu, Richtlinien aufzusetzen.
• Highflame (vormals Javelin) addressiert ebenfalls das Thema MCP-Sicherheit. Etwa mit Funktionen wie MCP-Server auf Risiken zu scannen oder Datenanfragen zu überprüfen.  
• Lasso Security stellt ein Open-Source-MCP-Gateway zur Verfügung, das die Konfiguration und das Lebenszyklusmanagement von MCP-Servern ermöglicht und Messages um sensible Informationen bereinigt.

(fm)

Dieser Artikel ist im Original bei unser Schwesterpublikation CSOonline.com erschienen.

A large majority of IT and security leaders are confident in their teams’ ability to detect when an AI agent has gone rogue, but few are able to take quick action to mitigate the fallout when an agent exceeds its intended scope.

Nine in 10 IT and security leaders surveyed by IT observability vendor WanAware believe in their capabilities to find malfunctioning agents, but only 26% acknowledge that they can trace the downstream impact within minutes. Over 45% say it would take hours to understand the full impact of an agent incident.

That delay between detection and mitigation can be a huge problem, says Jeffrey Collins, WanAware’s CEO. The survey suggests IT leaders are overconfident about their ability to control agents, he adds.

And here, timing is critical, Collins says, given that malfunctioning agents can lead to major outages and data breaches — damage that can start within seconds, he notes.

“That’s truly the gap here. It’s not if you understand it; it’s when you understand it,” Collins says. “If your average time to just knowing about an event is measured in days, weeks, or months, you have a serious problem right now.”

While it’s not always easy to tell whether an agent has gone beyond its scope, it’s even harder to tell the downstream impacts, he adds.

“What’s been affected if one machine was compromised, either from our own AI usage as a customer or from someone else’s, what else could happen, and how can we understand that quickly?” Collins asks.

Machine speed

Kevin Paige, field CISO at IT solutions provider C1, agrees that time is of the essence when an AI agent malfunctions.

“The problem is that agents move at machine speed, so the gap between an agent malfunctioning and you catching it isn’t measured in minutes, it’s measured in actions,” he says. “Every minute it’s wrong it’s still working, and because it’s usually running on borrowed standing credentials, the damage spreads across everything those credentials can reach before anyone can pin it on the agent.”

In many cases, organizations with rogue agents don’t find out from their own detection tools, but from customers, auditors, or broken downstream systems, he says.

“That’s the worst way to learn,” Paige adds. “The longer-term cost is trust, because one incident like that and the business pulls back on agents entirely, so failing to contain a malfunction fast is also what stalls adoption.”

The problem with detecting rogue agents is that many organizations have built in visibility but not control, he says.

“When an agent goes out of scope it’s rarely dramatic,” Paige adds. “Usually, it’s using access it legitimately has, for a purpose nobody signed off on, which means your access model doesn’t even flag it. So you find out after the fact, and you fix it by hand.”

IT teams can stop agents that exceed their scope, but only if controls were built in before the agent was deployed, adds Chris Camacho, COO of Abstract Security.

“Every agent should have its own identity, narrowly scoped permissions, and a complete audit trail,” he says. “Just as important, organizations need the ability to immediately revoke that identity or suspend the agent without manually hunting through multiple consoles during an incident.”

Part of the challenge is that an agent’s activity is spread across identities, cloud platforms, SaaS applications, APIs, and security tools that were not designed to tell a complete story, Camacho says. Security teams often have to piece together events from multiple basic questions such as, what did the agent access, and what changed?

“Most organizations know where they’ve deployed AI agents,” he adds. “That’s very different from knowing exactly what an agent did after something unexpected happens.”

The organizations that most successfully manage agents won’t be the ones that deploy the most, he says. “They’ll be the ones that can explain every action an agent took, prove it operated within policy, and stop it immediately when it doesn’t,” he adds.

Confidence isn’t reality

The survey’s results make sense to Joe Brinkley, director of offensive security research and community at pentest firm Cobalt. The high confidence in detecting malfunctions is compliance paperwork, whereas the minority of respondents who can detect problems quickly is the reality on the ground, he says.

“Tracing agent impact fast is brutal,” Brinkley says. “These systems do not run on fixed code paths. They use nondeterministic reasoning across a web of different APIs. Traditional logs only catch isolated events. They completely miss the full execution chain.”

By the time an anomaly alert hits, an agent has already executed multiple downstream actions, he adds.

In some cases, agent malfunctions are related to data flow vulnerabilities, such as when a prompt injection from an untrusted input such as a malicious email overwrites the system instructions, he says.

“We need to be clear about the actual technology; the AI is not waking up angry,” Brinkley says. “The agent suddenly thinks its official job is to dump your database. It spends tokens as fast as possible to do that.”

Agents are also vulnerable to loop failures, when they hit API errors and try to self-correct, he adds.

“It hits that same broken endpoint 10,000 times in two minutes,” he says. “It drains your budget and causes a self-inflicted denial of service. It is an automated wrecking ball moving faster than your monitoring can log it.”

Brinkley recommends that IT leaders put “hard kill” switches at the API layer to stop agents going out of scope.

“You can stop it, but soft guardrails are useless,” he says. “Do not try to patch the prompt or filter the text. You have to treat the agent like a compromised user account. Pull the OAuth tokens and kill the access immediately.”

Something interesting happened during an internal evaluation of AI meeting transcription tools at Tungsten Automation. The products worked. They weren’t bad. But sitting across from the pricing, we kept asking the same question: what exactly are we paying for?

We already had a secure enterprise AI environment. Building a meeting summary workflow took days, not months. We customized the outputs, injected our own internal context, and controlled security our way instead of working around someone else’s roadmap. We built it. It works better. We own it.

That’s not a knock on those vendors. It’s a signal of something more fundamental happening across enterprise software.

The moat was never the product

For two decades, SaaS rode a favorable asymmetry: building internal tools was hard, integrations were messy, and even modest automation required developers and long timelines. Buying was faster and cheaper than building. That asymmetry fueled the explosion of SaaS into every corner of the enterprise stack.

AI is collapsing that asymmetry. Large language models and agentic workflows can orchestrate APIs, move data between systems, generate interfaces, and automate business logic with a fraction of the engineering effort required even two years ago. The integration friction that once protected entire product categories is evaporating.

The vendors most exposed are not the deeply embedded enterprise platforms. They’re the lightweight workflow layers, the products that essentially put a polished interface on top of accessible data and relatively straightforward processes. Reporting dashboards. Meeting tools. Narrow productivity applications. These products created value by simplifying implementation. That rationale is getting harder to sustain when implementation is no longer the real barrier.

Here’s the part most analyses miss: it’s not just that AI makes development faster. It’s that agents change the integration model entirely. For 30 years, enterprise software was built for humans navigating UIs. Agentic systems don’t use UIs. They call APIs, read from multiple sources simultaneously, and move data freely across systems. The switching costs that once made incumbent software sticky are collapsing, because an agent doesn’t care which UI it used last quarter.

The SaaS that survives

The question isn’t whether SaaS survives. It’s which SaaS survives.

The companies with durable positions are not the ones with the cleanest interface. They’re the ones that transfer operational risk customers genuinely cannot absorb themselves. Compliance. Regulatory certification. Accumulated domain expertise. Liability.

Think about compliant invoicing across 140 countries. That’s not a workflow someone builds in a sprint. The certifications alone take years. A single regulatory change in one jurisdiction can break an AP process for a global enterprise overnight. Customers don’t pay for that capability because it’s technically complex. They pay because they cannot afford to own the risk of getting it wrong.

That’s the distinction that matters: AI lowers the cost of building software. It does not lower the cost of absorbing risk. The vendors who understand this are building durable businesses. The ones who don’t are quietly subsidizing their customers’ internal build programs.

Software sells features. Platforms sell accountability.

The prototype trap

The danger for enterprise buyers right now is overcorrection. Every successful prototype looks like a cost-saving opportunity. Very few survive the jump to production.

Building a workflow with generative AI is becoming straightforward. Maintaining it is not. Models evolve. Outputs drift. Governance requirements tighten. What worked cleanly in a controlled environment behaves differently at scale, and the failure mode is worse than traditional software. Rule-based automation, when it fails, fails obviously. Agents fail silently, confidently, at scale, often with a completely reasonable-sounding explanation.

Engineering teams that take on AI-powered systems need to solve for observability, model drift, access controls, audit trails, and long-term maintenance ownership. In regulated industries, they need to demonstrate exactly how the system reached every decision. That’s not a weekend project. That’s an ongoing operational commitment that compounds over time as models change and regulatory requirements evolve.

Before a team decides to replace an external platform with internal AI tooling, the honest question isn’t, “Can we build this?” The real question is, “Are we prepared to own this in production, for years, as the underlying models change beneath us?” Sometimes the answer is yes. Often the answer is no, and the true cost only becomes visible after the vendor contract is canceled.

Build vs. partner: a sharper frame

The build vs. buy framing has always been too binary. The right question is build vs. partner.

Partner for the capabilities where risk transfer, regulatory complexity, and domain expertise create genuine value your team cannot replicate. Build for the capabilities that actually differentiate your business from your competitors. Don’t burn your best engineers rebuilding compliant invoice processing or production-grade document extraction. Those aren’t competitive advantages. They’re table stakes, and someone else has already paid the cost, across decades, to make them reliable.

The organizations getting this right are honest about where they create unique value. They focus development there, and partner for everything else. The ones getting it wrong are vibe-coding solutions to non-differentiating problems while their actual competitive moat goes unattended.

The true value of software

We’re not watching the death of SaaS. We’re watching the end of the friction-based value proposition: the idea that software is worth renewing because integration used to be painful. That rationale is largely gone.

What survives is software that does something customers cannot reasonably replicate internally: absorb risk, maintain regulatory compliance, deliver operational reliability at scale, and bring genuine domain expertise into a production-grade system that someone else already stress-tested for years.

The vendors who recognize this are already repositioning around accountability, governance, and outcomes. The ones who haven’t will find the next renewal conversation noticeably harder.

Software sells features. Platforms sell accountability. That distinction is about to separate a lot of winners from a lot of cautionary tales.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

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

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

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

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

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

AIops and agentic ops aid SREs

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

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

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

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

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

AI’s impact on people and burnout

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

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

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

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

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

AI agent reliability

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

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

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

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

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

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

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

AI raises the SRE’s business impact

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

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

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

Technology executives from across the New York metropolitan area gathered July 16 at Convene, One Liberty Plaza, for CIO 100 Leadership Live New York, a full day of roundtables and panel discussions on enterprise AI investment, governance, and organizational change.

Several key areas of consensus emerged throughout this highly interactive event. Infrastructure fragmentation continues to block the path to securing returns on AI investments prompting leaders to understand rising cloud spend attributed to large language model utilization. This has caused a growing number of organizations to refocus on on-premises and hybrid options in C-suite and board-level capital planning conversations. Speakers, along with comments from the audience, described a shift from project thinking to product thinking, with smaller multidisciplinary teams moving faster than legacy structures.

Several participants repeatedly warned that automating broken processes just amplifies dysfunction. Governance and measurement remain unresolved, with usage metrics still getting mistaken for business value. One of the panels explored how CIOs may benefit from applying venture capital-style scrutiny to enterprise bets, weighing team execution as heavily as the technology itself. The throughline was a redefinition of the CIO role, from technology executor to business strategist fluent in revenue, board engagement, and transformation ownership.

Morning roundtable tackles AI infrastructure

The day opened with an invitation-only executive breakfast roundtable, “Beyond the Pilot, Building the Infrastructure for Real AI Returns,” co-hosted by Unisys and Dell Technologies. Over a dozen executives representing major public and private sector organizations across the New York metropolitan area joined Steve Hollander, senior director of Americas global alliances at Dell Technologies, and Matt Marshall, CIO at Unisys for a workshop-style discussion.

The session explored the strategic, operational, financial, and technological issues that must be mastered to optimize infrastructure decisions and separate organizations that are experimenting with AI from those competing on it. Discussion questions probed how CIOs measure whether AI investment is translating into business results, how they can break the cycle of fragmented and siloed AI deployments, how boards are beginning to scrutinize seven-figure token spend and whether on-premises or hybrid infrastructure can rein in costs.

The take-home point: the organizations pulling ahead are the ones that stopped treating AI as four separate problems, strategic, operational, financial, technological, owned by four separate functions, and started running it as one coordinated decision. Fragmentation is the actual cost center here, not the token spend itself. A CIO who solves the infrastructure question in isolation from the governance question, or the cost question in isolation from the talent question, ends up optimizing one silo while the other three keep bleeding value. Competing on AI, instead of just experimenting with it, means the finance, operations, technology and business sides are reasoning from the same picture of what’s being built and why, so the tradeoffs get made once, together, instead of getting re-litigated at every handoff.

Forum sessions open with a mandate for growth

Following breakfast, the main forum program began with “The New CIO Mandate, Delivering Growth, Not Just Technology.” In a moderated conversation, Laksh Nathan, chief information officer at Paramount Skydance, drew on his experience with mergers, enterprise transformation and AI-enabled development to describe a shift from project and application management toward a product-centric operating model. Nathan addressed how smaller, multidisciplinary teams are changing expectations on both the business and technology sides of the enterprise, and what mindset changes CIOs must lead to turn AI into an engine of growth rather than a cost center.

PwC followed with a session on “Designing the Intelligent Enterprise, From AI Investment to Evolving Operations.” Darren O’Meara, principal and chief technology officer for managed services, and Meghna Shah, principal for engineering and AI, examined why fragmented outcomes persist even after heavy investment in technology and transformation.

The intelligent enterprise, they posited, is less about working toward achieving specific technology outcomes and more about creating operating models that integrate strategy, technology, operations, and governance into one system. This, they explained, requires linking AI, data, and decisions across the business and will leave an indelible mark on how decision rights are redesigned, funding models are developed, and accountability is enforced to accommodate the speed of the agentic economy.

Talent, tradeoffs, and the cost of getting it wrong

The session “Return on Transformation: Time, Talent, and Tradeoffs” — with Prashant Hinge, chief information and transformation officer at MSIG USA; Joseph Gimigliano, chief technology officer at Northwell Health; and Eduard de Vries Sands, AI executive advisor at PatientPoint — examined why transformation initiatives so often lose their way.

The main culprit, even today in 2026, continues to revolve around a persistent instinct for technology implementations to become the objective rather than the means to a measurable business outcome. The panelists made the case for doing the incredibly difficult work of re-engineering (if not entirely re-imagining) existing processes before automating them and then placing smaller bets inside that bigger vision.

Ricky Thakrar, head of sales and account management at Zoho, took the stage to present “Smaller, Smarter, Safer, The Enterprise AI Architecture Most Leaders Get Backwards,” arguing that constrained, context-rich architectures consistently outperform expensive models bolted onto fragmented systems.

A round of Hot Topic Discussion Groups and a networking lunch followed, including the Next CIO Luncheon featuring Robert Half Regional Director Jason Deneu.

Afternoon sessions turn to security, scale, and investment signals

CSO and CIO Contributor Joan Goodchild moderated “Securing Trust in the Agentic Economy,” a discussion with Marlowe Cochran, CISO at the New York State Education Department, and Gee Rittenhouse, vice president of security services at AWS, on how organizations are balancing speed, innovation and security as AI agents move from experimentation into productization at scale.

Rittenhouse framed agentic risk as closer to human risk than traditional software risk, describing how an independent agent acting in a non-deterministic way really does look like a potential insider threat, pushing CISOs toward behavioral monitoring over static workload protection. He tied this to a structural shift in defense, noting it’s hard to do agentic security if you’re not observing it, putting observability at the center of agentic risk management.

Cochran concurred, adding that many of the key tools that are needed to move into the agentic economy already exist, but must be implemented more aggressively, comprehensively and even more creatively. CISOs don’t need to invent an entirely new security discipline for the agentic era so much as extend identity management, access control and monitoring frameworks they already run to cover a new class of non-human actor — agents.

A session on “AI, From Experimentation to Enterprise Impact” brought together Meagan Gentry, national AI practice manager and distinguished technologist at Insight and Yuri Gubin, chief technology officer at DataArt, for a candid look at why pilots stall before reaching scaled production and what operating capabilities, governance, cost visibility, continuous education, must be in place to sustain AI once a proof of concept works.

During the session’s Q&A segment, a discussion emerged around how proof-of-concept success can result in a false signal, raising questions about whether pilots should be considered successful before the intended outcomes have had time to materialize, and drawing a distinction between measuring usage and adoption versus measuring business value.

The panelists explored how CIOs can identify the small number of transformational AI opportunities worth pursuing rather than managing hundreds of incremental use cases, and even challenged whether prioritization is the CIO’s job at all. The discussion closed on a sequencing question with real strategic weight, whether AI-first strategies are putting the technology ahead of the business problem CIOs are trying to solve, and what role CIOs should play with boards in defining the outcomes AI is expected to support.

A shift in perspectives

The “Think Like a VC, Investment Shifts Towards Focused AI Applications” session featured three venture investors, Aaron Darr, partner at Lead Edge; Isabelle Phelps, partner at Lerer Hippeau; and Marshall Porter, general partner at AlleyCorp. The panel explored how investors evaluate risk and talent in a market where products and competitive positions can shift within months, and what separates a focused AI application with durable enterprise value from an AI wrapper built to chase a trend.

The panel challenged the enterprise instinct to seek certainty in a market moving this fast, questioning whether CIOs should stop looking for technologies that will future-proof the enterprise and instead grow more comfortable continuously reassessing their bets. Investors framed this as a deliberate departure from the traditional low-tolerance-for-failure posture that has long governed enterprise technology purchasing, arguing that the search for certainty has itself become a risk in a market where products and business models can shift within months. The discussion pressed CIOs to weigh how they can adopt a more dynamic investment mindset without compromising the enterprise security, governance and accountability their organizations still depend on.

A Lightning Insights followed, featuring five-minute briefings from Insight, Platform9 and Console, followed by Keystone Senior Principal Ellora Sarkar’s talk on why most enterprise AI investment fails to produce measurable value and what separates the small share of firms capturing real return on investment from the majority still stuck in pilots.

Closing the day

The forum closed with “What’s Next for the CIO, Preparing for the Next 12 to 24 Months,” a fireside conversation with Leif Maiorini, CIO for corporate services at Omnicom. Maiorini discussed why business processes need to be redesigned for agentic speed rather than automated around existing human workflows, how organizational structures may shift as autonomous agents reshape visibility and decision support, and where sustainable differentiation will come from once AI capability itself becomes widely accessible.

Maiorini encouraged the industry to clearly distinguish between nondifferentiated services that should be made as efficient as possible and the differentiated capabilities that actually influence why customers choose to do business with an organization, once the major efficiency gains from optimization and AI have been captured.

He was candid about the governance gap agentic systems open up, noting that agents lack the professional reputation, personal accountability and inherent constraints that shape human behavior, which creates new risk when autonomous decisions occur at machine speed. That combination, reinvesting efficiency gains into genuine differentiation while building governance models suited to non-human decision-makers, framed his closing case for why human creativity and judgment remain the enterprise’s most durable asset even as the underlying technology becomes commoditized.

Join the CIO 100 Awards & Conference Aug 17–19, 2026 at Omni PGA Frisco Resort & Spa, Frisco, TX — where top IT leaders celebrate innovation and connect.  Learn more to attend or partner.

A sandbox security hole that could lead to remote code execution (RCE), patched last week by ServiceNow, is being actively exploited in the wild, according to a report from threat intel firm Defused. 

The report, posted on X, said the firm is “observing in-the-wild exploitation of the ServiceNow pre-auth sandbox-escape RCE (CVE-2026-6875).”

Defused CEO Simo Kohonen, in an interview with CSO Online, noted that it appeared that the attacker has changed its tactics from those documented in an earlier proof of concept (PoC) from researchers at Searchlight Cyber, in response to ServiceNow patches and defenses. The company had implemented five different mitigations in its code base, which “neutered” the initial attack methodology, he said, adding that, overall, his team is seeing more attack method tweaks than it used to see. 

“We are seeing a lot of [attack] variations, much more so than a year ago, for the same vulnerability,” Kohonen said. Attackers “now have more tools to build their own stuff.”

However, he admitted that his team has thus far only observed this exploit an in the wild exploitation “once, by one actor.” 

In response to the report, ServiceNow issued a statement saying that it has not yet directly seen any such exploitations. 

“ServiceNow is aware of a cybersecurity company’s recent publication regarding exploitation activity associated with a previously disclosed security vulnerability, identified as CVE-2026-6875. Based on our investigation to date, we have not observed evidence that this activity is related to instances that ServiceNow hosts,” the emailed statement said. “We have provided updates and patches designed to address this issue, and we encourage our self-hosted and ServiceNow-hosted customers to apply the relevant patches if they have not already done so.”

A ‘repeatable failure point’

Analysts and consultants said the bigger concern with this hole is that it focuses on the lack of protections in the sandbox, which many security and IT teams have relied on for years. 

“The vulnerability lets an attacker bypass ServiceNow’s scripting sandbox entirely, and researchers are now seeing exploitation using a different technique than the one originally published, which means signature-based defenses built on the first proof of concept are unlikely to catch every variant,” said Frank Dickson, group VP for security at IDC.

“A compromise that starts in the cloud tenant can end up inside the corporate network, turning a SaaS incident into an on-premises one,” he pointed out. “And because ServiceNow frequently houses HR records, CMDB asset data, and the ticketing system itself, an attacker sitting inside it may have visibility into how the incident response team is tracking the incident.”

Dickson added that this incident is further proof that both IT and security teams need to reevaluate their patching methodologies. 

“Enterprises outsource patching for platforms like ServiceNow to the vendor, but keep the risk that comes from what those platforms touch: HR records, CMDB inventories, and now on-premises systems through MID Server integration. Control sits with the vendor, liability sits with the enterprise, and that mismatch argues for treating core SaaS platforms as part of the internal attack surface, not externalized vendor risk,” he said, noting that as vendors embed more AI-driven scripting into their platforms, the sandbox boundary becomes “a repeatable failure point.”

Because of this, he advised, “CISOs should start asking every AI-enabled SaaS vendor how that boundary is architected and tested, before the next version of this story breaks elsewhere.”

Noah Kenney, principal consultant at Digital 520, said the sandbox escape is the more disturbing element of the issue. 

“The significance is not that ServiceNow had a critical bug, so much as the fact that the bug is a sandbox escape in the AI Platform, which means the containment layer specifically built to run untrusted AI-driven code safely is the thing that failed,” he said. “CISOs have been told repeatedly that the sandbox is what makes enterprise AI safe to deploy, but we’re now seeing the sandbox breaking and that should reframe how CISOs think about every feature sitting behind a similar wall.”

Addition of AI increases blast radius

This is yet another example where AI is fundamentally changing just about every IT and security rule, he pointed out.

“Enterprises are bolting AI onto their most privileged systems of record faster than anyone is updating the threat models for those systems, and the AI layer is becoming the softest part of the hardest targets,” Kenney said. “The real question for a CISO is how many of your critical platforms shipped an AI feature in the past year, and whether a single person in your organization can tell you what that did to the pre-auth attack surface. Most cannot, and that is the actual exposure.”

Aman Mahapatra, chief strategy officer for Tribeca Softtech, a New York City-based technology consulting firm, agreed.

“A vulnerability that gives an attacker a foothold in the ServiceNow instance is now also a vulnerability that gives them access to whatever AI agents are running inside that instance, along with any capability tokens, service accounts, or delegated permissions those agents hold,” Mahapatra said. “The blast radius of a ServiceNow compromise in 2026 is meaningfully larger than the same compromise would have been in 2023, and most enterprise security programs have not caught up to that shift.”

Defused’s Kohonen said that he did not disagree with the sandbox concerns, but he stressed that enterprise CISOs have long ago abandoned the belief that sandboxes are secure. 

“Nothing is foolproof, and having a sandbox is better than not having one,” he said. “But the belief that a sandbox removes all of the risk is incredibly dumb,” especially in the reality of today’s threat landscape, which contains “an endless conveyor belt of exploits.”

A sandbox security hole that could lead to remote code execution (RCE), patched last week by ServiceNow, is being actively exploited in the wild, according to a report from threat intel firm Defused. 

The report, posted on X, said the firm is “observing in-the-wild exploitation of the ServiceNow pre-auth sandbox-escape RCE (CVE-2026-6875).”

Defused CEO Simo Kohonen noted in an interview that it appeared that the attacker has changed its tactics from those documented in an earlier proof of concept (PoC) from researchers at Searchlight Cyber, in response to ServiceNow patches and defenses. The company had implemented five different mitigations in its code base, which “neutered” the initial attack methodology, he said, adding that, overall, his team is seeing more attack method tweaks than it used to see. 

“We are seeing a lot of [attack] variations, much more so than a year ago, for the same vulnerability,” Kohonen said. Attackers “now have more tools to build their own stuff.”

However, he admitted that his team has thus far only observed this exploit an in the wild exploitation “once, by one actor.” 

In response to the report, ServiceNow issued a statement saying that it has not yet directly seen any such exploitations. 

“ServiceNow is aware of a cybersecurity company’s recent publication regarding exploitation activity associated with a previously disclosed security vulnerability, identified as CVE-2026-6875. Based on our investigation to date, we have not observed evidence that this activity is related to instances that ServiceNow hosts,” the emailed statement said. “We have provided updates and patches designed to address this issue, and we encourage our self-hosted and ServiceNow-hosted customers to apply the relevant patches if they have not already done so.”

A ‘repeatable failure point’

Analysts and consultants said the bigger concern with this hole is that it focuses on the lack of protections in the sandbox, which many security and IT teams have relied on for years. 

“The vulnerability lets an attacker bypass ServiceNow’s scripting sandbox entirely, and researchers are now seeing exploitation using a different technique than the one originally published, which means signature-based defenses built on the first proof of concept are unlikely to catch every variant,” said Frank Dickson, group VP for security at IDC.

“A compromise that starts in the cloud tenant can end up inside the corporate network, turning a SaaS incident into an on-premises one,” he pointed out. “And because ServiceNow frequently houses HR records, CMDB asset data, and the ticketing system itself, an attacker sitting inside it may have visibility into how the incident response team is tracking the incident.”

Dickson added that this incident is further proof that both IT and security teams need to reevaluate their patching methodologies. 

“Enterprises outsource patching for platforms like ServiceNow to the vendor, but keep the risk that comes from what those platforms touch: HR records, CMDB inventories, and now on-premises systems through MID Server integration. Control sits with the vendor, liability sits with the enterprise, and that mismatch argues for treating core SaaS platforms as part of the internal attack surface, not externalized vendor risk,” he said, noting that as vendors embed more AI-driven scripting into their platforms, the sandbox boundary becomes “a repeatable failure point.”

Because of this, he advised, “CISOs should start asking every AI-enabled SaaS vendor how that boundary is architected and tested, before the next version of this story breaks elsewhere.”

Noah Kenney, principal consultant at Digital 520, said the sandbox escape is the more disturbing element of the issue. 

“The significance is not that ServiceNow had a critical bug, so much as the fact that the bug is a sandbox escape in the AI Platform, which means the containment layer specifically built to run untrusted AI-driven code safely is the thing that failed,” he said. “CISOs have been told repeatedly that the sandbox is what makes enterprise AI safe to deploy, but we’re now seeing the sandbox breaking and that should reframe how CISOs think about every feature sitting behind a similar wall.”

Addition of AI increases blast radius

This is yet another example where AI is fundamentally changing just about every IT and security rule, he pointed out.

“Enterprises are bolting AI onto their most privileged systems of record faster than anyone is updating the threat models for those systems, and the AI layer is becoming the softest part of the hardest targets,” Kenney said. “The real question for a CISO is how many of your critical platforms shipped an AI feature in the past year, and whether a single person in your organization can tell you what that did to the pre-auth attack surface. Most cannot, and that is the actual exposure.”

Aman Mahapatra, chief strategy officer for Tribeca Softtech, a New York City-based technology consulting firm, agreed.

“A vulnerability that gives an attacker a foothold in the ServiceNow instance is now also a vulnerability that gives them access to whatever AI agents are running inside that instance, along with any capability tokens, service accounts, or delegated permissions those agents hold,” Mahapatra said. “The blast radius of a ServiceNow compromise in 2026 is meaningfully larger than the same compromise would have been in 2023, and most enterprise security programs have not caught up to that shift.”

Defused’s Kohonen said that he did not disagree with the sandbox concerns, but he stressed that enterprise CISOs have long ago abandoned the belief that sandboxes are secure. 

“Nothing is foolproof, and having a sandbox is better than not having one,” he said. “But the belief that a sandbox removes all of the risk is incredibly dumb,” especially in the reality of today’s threat landscape, which contains “an endless conveyor belt of exploits.”

This article originally appeared on CSOonline.

When a goal goes in during a tournament quarter-final and a hundred million people watch it at the same time, what they feel is the goal. The roar, the replay, the disbelief.

They do not feel the contribution feeds traversing private media networks across continents, or the edge nodes absorbing a traffic spike that appeared without warning.

They just feel the moment.

And that’s exactly how it’s supposed to work.

And as live sports viewership pushes into territory that makes previous records look modest (driven by a generation that expects to watch anything, on any device, anywhere, without waiting), the gap between getting that delivery right and getting it wrong has never been more consequential, or more public.

As audiences moved to digital platforms, the margin for error disappeared.

There is a version of this conversation that is easy to have: audiences expect more, technology has to keep up. True, but incomplete.

Audiences have always expected live sport to work. What changed is what “working” means, and how quickly they find out when it doesn’t.

Viewers no longer sit in front of a single screen. During a FIFA World Cup match, a household might have the main feed on the living room television, while someone else streams the highlights on a second TV in the bedroom, all while phones flash with live stats and tablets run separate commentary. From the infrastructure’s perspective, that isn’t just one household watching a game; it’s a chaotic web of concurrent demands triggered by the exact same split-second on the pitch.

Multiply that across tens of millions of viewers, and the scale of the challenge becomes clear. Social media raises the stakes further. When a platform fails during a World Cup knockout match, audiences report it in real-time on the same platforms they use to discuss the game. The complaint travels faster than the fix.

Broadcasters no longer have the luxury of resolving an incident before people notice. The incident becomes the story, and in many cases, travels further than the match itself.

What these viewership numbers actually mean for infrastructure

The shift in how people watch live sport has moved well beyond trend territory.

EMARKETER forecasts that digital live sports audiences in the US will grow to 114.1 million viewers, while traditional pay TV audiences decline to 82.0 million, highlighting the continued shift toward streaming.

The concurrency numbers generated by major sporting events now sit in a territory that would have seemed implausible a decade ago.

During the 2026 FIFA World Cup, for instance, streaming platforms shattered every historical ceiling, highlighted by Brazil’s CazéTV repeatedly breaking global YouTube records for concurrent viewership during the group stage. Meanwhile, in the United States, Peacock and Telemundo’s digital platforms logged an unprecedented 13 million concurrent viewers for a single knockout window. 

When tens of millions of people tune into the same live stream at the same moment, it’s a challenge unlike regular web traffic.

Historically, massive global audiences were insulated by geography. The load was spread across distinct regional networks: antenna signals, satellite downlinks, and physical cable architectures. The physical infrastructure of traditional television inherently absorbed the impact. 

Digital streaming removes that buffer. Traffic spikes all at once, often at the most critical moment. The tighter the match, the deeper the stoppage time, the sharper the spike. Network infrastructure is forced to handle its heaviest, most volatile traffic exactly when it has zero margin for error.

Social media compounds the pressure operationally. The second a crucial goal is scored, a wave of real-time reactions floods the internet, instantly dragging a secondary “curiosity audience” into the app. These are people who weren’t even watching the match, but saw the hype and decided to tune in, meaning the network has to absorb a massive new rush of users precisely while the primary stream is already maxing out its capacity.

To survive these surges while satisfying a modern audience, the underlying broadcast playbook has undergone a massive structural shift. It’s no longer just about handling traffic; it’s also about using modern technology like AI to manage it intelligently.

According to an industry survey, 25% of broadcasters integrated AI into live production workflows in 2025, a massive leap from just 9% the previous year, with 64% identifying AI as the single largest impact driver over the next five years. 

The network is no longer just delivering content. AI is now generating highlights and short clips in real time, producing millions of videos that keep fans engaged long after the live moment has passed.

Ultimately, the technical demand is driven by a shift in what viewers expect. An IBM sports study revealed that 56% of fans now want AI-driven insights layered directly onto their content, while 33% point to real-time, automated translation as the feature that most impacts their experience.

Whether it’s one screen or several, viewers don’t notice the edge infrastructure or AI powering the experience. They just expect the game to play without interruption.

The planning mistake most organisations make

Capacity planning is where most organisations spend their time when preparing to stream a major event. Can the system handle a million concurrent streams? Can it scale on demand if the numbers exceed projections? These are real questions. 

The lesson is not unique to sports streaming. Every digital business now experiences moments where demand, visibility, and customer expectations collide. Peak traffic events such as flash sales, ticket releases, and viral campaigns can drive website traffic 2 to 25 times above normal levels within seconds. The infrastructure may be different, but the pressure is remarkably similar.

Large-scale system failures occur when multiple components, each functioning as expected on its own, are overwhelmed by a surge in demand, rising latency, or regional blind spots at the same time.

The problem isn’t the individual systems. It’s how they work together.

Latency is the factor most consistently underestimated. A few seconds of delay is not a minor inconvenience in live sport. It is a fundamentally broken experience. 

A viewer whose stream is running four seconds behind will see a notification before the decisive moment appears on screen. Someone watching a service from the privacy of their room may hear a celebration from another room before seeing it on their screen.

Geography is another planning gap. Streaming growth is increasingly being driven by emerging markets. In Southeast Asia alone, premium video streaming subscriptions grew 19% in 2025, led by Indonesia, while viewing hours continued to climb across the region. Yet much of the world’s media infrastructure was originally designed around North American and Western European demand. An architecture that looks robust on paper can deliver very different experiences depending on where the viewer is.

The reason is simple: physical distance still matters. Every extra hop between the viewer and the content adds latency, making it harder to deliver a consistent experience at global scale.

Then there is the timing question. The decisions that determine whether a platform holds during the most-watched minutes of the year are not made on event day. They are made months earlier through choices around architecture, redundancy, testing, and operational readiness.

Once an event is underway, it’s too late to redesign the architecture behind it. If your system isn’t designed to handle the pressure before the crowd arrives, it’s already too late.

The hidden chain behind every live event

When a streaming disruption becomes public, people naturally look for a single point of failure: the app, the platform, or the provider.

A live event depends on dozens of systems working together, and any one of them can become a problem.

And the experience is only as good as the weakest handoff between them.

It all starts with the live camera feed moving from the venue to the production studio. This is a real-time stream, not a file download. If you drop even a single packet at the wrong moment, everything down the line breaks, no matter how perfect the rest of your setup is.

Remote and cloud-based production workflows have redefined how live sports are produced, enabling broadcasters to operate with greater agility and scale. As production becomes more distributed, success increasingly depends on ensuring every stage of the delivery chain works together seamlessly.

Each transition is a potential failure point. Managing them requires visibility that extends across providers, platforms, and networks simultaneously.

Behind every live stream, technologies like encoding, transcoding, packaging, rights management, and ad insertion are constantly at work. If any one of them fails, the stream can go down altogether.

Global distribution introduces another layer of complexity. Viewers in Asia, Africa, and South America may all be watching the same match, but each stream travels across different networks and infrastructure. That means performance can vary by region, and issues may affect one audience without impacting another. 

AI is increasingly helping operators detect anomalies in real time, pinpoint affected regions and trigger corrective actions before disruptions become widespread. Combined with point-to-point monitoring, it provides the visibility needed to keep live events running smoothly at global scale.

Edge delivery is where the difference between preparation and improvisation becomes most apparent. Bringing content closer to users reduces latency, absorbs local traffic surges, and improves performance in markets with variable connectivity. 

The value of technology investments such as AI and Edge becomes clearest during the moments when demand is highest.

Monitoring is what turns visibility into action. With AI helping analyze telemetry and detect anomalies in real time, operations teams can identify issues sooner and respond before they affect viewers. By the time customers start reporting a problem, the opportunity to prevent it has already passed.

What reliability is actually worth

For most of early broadcast history, audience tolerance provided some buffer. Disruptions happened. People accepted them. There was nowhere else to go, and the story rarely escaped the room.

Neither of those things is true now.

A streaming failure during a major match becomes public within seconds. Viewers don’t distinguish between a network issue, a processing failure, or a distribution problem; they simply see a service that failed. That single experience can shape the broadcaster’s reputation, credibility and customer loyalty, influencing whether viewers come back for the next event or recommend the service to others.

The commercial implications are significant. Global tournaments such as the FIFA World Cup illustrate just how valuable live sports rights have become. Their return depends on reliably reaching the audience that was promised.

Advertisers invest in live sport for one reason: to reach a large, engaged audience at the exact moment it matters most. If the stream fails during that window, the opportunity is lost. Those viewers, impressions, and advertising value cannot be recovered once the moment has passed.

The same principle increasingly applies outside media. Customers rarely know nor care whether an outage originated in the application, the cloud environment, the network or a third-party dependency. They experience a failure of the brand. In a digital-first economy, reliability has become part of the customer experience itself.

For broadcasters and streamers, reliability is no longer just an operational KPI. It directly influences audience trust, advertising revenue, and the long-term value of premium sports rights.

The demands ahead are bigger

AI-assisted production is already changing how live events are created. Broadcasters are using AI to automate highlight generation, camera selection and real-time clip packaging for social media, with new AI-assisted workflows producing sports highlights up to 80% faster than traditional methods. 

All of this processing happens within the live delivery chain, where every additional task must be completed without adding latency or compromising the viewing experience.

Personalisation at scale is the next significant challenge. Not personalisation in a vague sense, but the specific technical reality of delivering multi-language commentary tracks, different languages, different statistical overlays, and different camera angles to different viewers watching the same event simultaneously. 

Instead of one stream per event, the infrastructure has to manage a matrix of concurrent variants, each with its own encoding, storage, and delivery requirements. 

Interactive experiences add bidirectional data flows: real-time polls, integrated second-screen data, live wagering. These move data from the viewer back through infrastructure that was primarily built to push content outward. Managing that at scale is a different engineering problem from managing delivery.

Higher-resolution formats (4K now becoming a standard expectation in premium markets, 8K moving into early deployment) are bandwidth-intensive at exactly the scale where bandwidth is already under pressure. Consumer devices are ready. Infrastructure in many high-growth markets is not uniformly there yet.

Many of these capabilities are already being deployed for major global sporting events. The organisations investing seriously in technology, innovation, and infrastructure now are building toward a standard that will be the baseline requirement within a few years. Those that are not will be closing the gap under the worst possible conditions.

The technology you never think about

The broadcasters that succeed don’t leave reliability to chance. They plan for it from the outset, designing their infrastructure to handle peak demand long before the audience arrives.

This reality hits hardest during massive global events. When a stream glitches, millions of people feel it simultaneously in a matter of seconds. Keeping those streams alive doesn’t happen by accident; it takes massive scale, intense discipline, and deep experience controlling everything from the stadium camera to the viewer’s screen.

The lesson extends well beyond live sports. Every enterprise is becoming a real-time digital business, whether it’s delivering AI-powered applications, launching digital products, processing financial transactions, or handling a sudden surge in customer demand. Different industries may face different triggers, but the expectation is the same: the experience has to work, even when demand is at its highest.

Delivering that level of reliability is why many of the world’s largest sports brands rely on Tata Communications. Supporting the broadcast, production, and management of 80% of the world’s sporting events, and reaching more than two billion viewers across 190+ countries, Tata Communications operates in the invisible layers that make every live moment possible. We call this the “Virtual Stadium of the World”, the technology and infrastructure that connects fans, broadcasters, rights-holders, and sporting moments at a truly global scale.

By managing the critical handoffs across contribution networks, edge processing, and global media infrastructure, we engineer the resilience required to keep 120,000 live events running flawlessly every year.

Live sport may be the most visible test of digital infrastructure, but it won’t be the last. As AI, personalisation and real-time experiences become the norm across industries, the ability to deliver reliably at scale will define far more than match day.

To learn more, visit us here.

For three decades, enterprise software has been a buy-it decision. Packaged software from SAP, Oracle and Salesforce covered roughly 80% of requirements at a fraction of the cost of building. The economics were obvious, and for traditional applications, they still are.

AI is introducing a wrinkle that is forcing even the most committed enterprise software customers to rethink their options. AI is a layer that sits across your data, your processes, and your decisions. Where that layer runs and who controls it is an architecture question, and most of the enterprise community is still treating it as a procurement one.

The appeal of vendor-embedded AI is clear: automated operational decisions, smarter supplier and merchandising choices, and friction-free workflows built into the systems enterprises already rely on. The catch is that these capabilities almost universally depend on your data living in the vendor’s cloud environment. For most large enterprises, it sits on-premises, in hyperscale cloud infrastructure they manage themselves, or in private data centers. That gap between where your data is and where your vendor’s AI assumes it should be creates a fundamental strategic fork in the road.

Build vs. buy is a category error

The framing I keep hearing is “build vs. buy your AI strategy.” It implies that some organizations are out there training foundation models from scratch. Nobody serious is doing that. The real choice sits across three distinct approaches, and conflating them leads to poor decisions:

• Buy embedded. Use the AI capabilities your vendor ships natively inside their platform: the assistant baked into your ERP, your CRM, your HCM suite. Lowest integration cost, fastest time to value, tightest fit with the application data.
• Buy platform. Adopt the vendor’s AI infrastructure layer and build your own assistants and agents on top of it. More flexible, but you remain inside the vendor’s architectural boundary and subject to their governance model.
• Compose. Connect a third-party model (Claude, GPT, Gemini, an open-weight model running in your own environment) directly to your existing landscape. Maximum control, maximum integration burden, and full responsibility for what comes out the other end.

These are not equivalent options at different price points. They make different assumptions about where your data lives, who governs the AI, and how much architectural change you’ll absorb to get there. Vendor pitches sometimes blur the distinction on purpose. Enterprise leaders can’t afford to.

The vendor AI stack has an assumption baked in

Every embedded AI capability ships with an unstated architectural prerequisite: your data must be where the AI can see it, in the shape it expects, under the governance the vendor enforces.

For organizations with clean, modern cloud estates, that is often a reasonable trade. For the long tail of large enterprises running heavily customized environments on private or hybrid infrastructure, that trade becomes a precondition, one you must meet before the AI conversation can even begin. Whether meeting it makes sense depends on your starting point, your sector’s regulatory posture, and your appetite for migration risk. None of those are uniform across organizations.

That’s the part that gets glossed over in vendor keynotes. The AI demo on stage assumes a destination architecture the audience hasn’t necessarily reached yet. Large enterprise customers are carrying an unusually heavy technology burden right now. Many are simultaneously managing platform modernization programs that have been building for over a decade, alongside pressure to migrate to vendor-managed cloud infrastructure. Sitting above both is a boardroom-level directive to demonstrate meaningful AI progress fast. The vendor path to AI and the boardroom path to AI can diverge sharply, and enterprises need to make selective, strategic decisions about where to adopt AI first to maximize value and minimize risk.

Sovereignty isn’t a slogan, it’s an architecture constraint

The conversation about sovereignty has been hijacked by both sides. One camp treats every SaaS adoption as a sovereignty violation. The other dismisses every sovereignty concern as Luddite resistance. Neither is useful.

What’s happening in real customer conversations – particularly in DACH, public sector, and financial services – is more specific. Organizations are drawing a distinction between running their applications in a vendor’s cloud (which is broadly fine, well understood, decades of precedent) and enriching their data and processes inside a vendor’s AI model (which has less precedent, is harder to reverse, and carries material implications for competitive position).

Enriching your data inside a vendor’s AI model is the genuinely new question, and organizations that conflate it with their existing cloud posture tend to defend the wrong perimeter.

Despite spending around $100 million annually with Amazon, Disney built its own internal AI system to house its corporate intelligence rather than rely on a hyperscaler’s AI offering. The decision came down to control. When your data represents decades of creative and commercial IP, you think carefully about where it lives and who can learn from it. Disney has become more open to SaaS over time. The AI sovereignty question is a separate debate from the SaaS debate and conflating the two leads organizations to the wrong conclusions.

At the other end of the spectrum, enterprises in heavily regulated environments treat data sovereignty as an absolute non-negotiable. Any AI model must run within their controlled environment, especially where sensitive data cannot touch the public internet. GDPR obligations reinforce this instinct across the European market, requiring organizations to maintain clear accountability for how personal data is processed inside AI systems, including vendor-managed ones.

AI-enriched data, meaning models that have learned the shape of your business processes, your supplier negotiations, your customer behavior, carries a different half-life and a different strategic value than the operational data underneath it. That deserves its own architectural decision, separate from your broader cloud strategy.

What this means in practice

Most large enterprise estates will end up with a mix of all three approaches, and where you draw the lines matters more than your overall posture.

Embedded AI capabilities are the right answer for in-application productivity: the assistant inside your ERP workflows, the agent inside your procurement or HR suite. That is where vendor embedding genuinely shines, and attempting to compose your own equivalent is typically a poor use of engineering resources.

Compose belongs elsewhere: in cross-application orchestration, in custom assistants over operational and observability data, and in agents that need to reach across multiple vendor systems and infrastructure layers in ways no single vendor stack will never natively support. Research from McKinsey suggests the most significant near-term productivity gains from enterprise AI will come precisely from these cross-system workflows, rather than from within individual applications. The most interesting enterprise AI work over the next eighteen months lives here, and it doesn’t require waiting for a migration to complete first.

That compose path isn’t free, and it’s important to be honest about the costs. Governance, audit trails, and accountability for hallucinated outputs become your problem, not the vendor’s. Prompt drift and evaluation discipline are real engineering costs that never appear in the proof-of-concept. Those costs scale with the complexity of your landscape and the number of systems your agents touch. Budget for them before deployment, not after your first production incident. None of that is a reason to avoid the path. It’s a reason to staff for it, honestly.

The real question

The build-vs-buy frame survives because it gives executives a binary choice along a familiar axis. AI sits somewhere else entirely.

The question worth putting on the table at your next architecture review is simpler:

Which decisions do we want our vendors’ AI to make, and which do we want to keep on our side of the boundary?

Answer that, and the right build/buy/compose mix flows from it. Skip it, and you will end up with the architecture your vendors prefer – which may or may not be the one your business needs.

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

Most organizations I work with have invested heavily in cloud security. They have endpoint detection tools, SIEM platforms, cloud security posture management, and skilled security teams running on a 24/7 shift. And yet, when I ask them a simple question — who has admin access in your Salesforce tenant right now? — The room goes quiet. Nobody knows. Not because they are negligent. Because they genuinely cannot see it.

That is the SaaS blind spot.

Ashish Mishra

SaaS: Numbers speak volumes

I ask this question in almost every engagement: how many SaaS applications does your organization run? The answers I get range from 30 to maybe 50. The real number, once someone counts, is usually north of three hundred. AppOmni’s 2024 research put it even higher — 49% of Microsoft 365 organizations believed they had fewer than ten apps connected to their tenant when the actual average was over a thousand.

Here is the part that concerns me more than the count. Of all those applications, security teams have clear sight into maybe one in 10. The rest — where your customer records live, where your source code sits, where your financial reports get shared — nobody is watching. Not because the team is careless. Because the tools they have were never built to look there.

The following incidents will discuss these realities.

Salesforce in 2023

In April 2023, KrebsOnSecurity broke the story — Salesforce Community sites were quietly leaking sensitive data belonging to government agencies, banks, and healthcare providers. No sophisticated attack technique. Just the right API endpoint and a misconfigured guest user profile. The exposed records included Social Security numbers, account details, and home addresses. Salesforce was clear in its response: this was not a platform vulnerability. Administrators had misconfigured guest access policies, and nobody had checked.

Guest user profiles in Salesforce Communities can be granted access to data records. When administrators set those permissions too broadly — often without realizing it — unauthenticated external users can query that data straight through the API. Over 150,000 companies were potentially sitting in that window before anyone raised the alarm.

The pattern is always the same. Configuration made under time pressure, default set slightly too permissive, nobody looks at it again. SaaS applications accumulate these quiet exposures over months and years.

GitHub in 2022

In April 2022, GitHub disclosed that an attacker had used stolen OAuth tokens — issued to Heroku and Travis CI — to access and download private repository contents from dozens of organizations, including npm. GitHub’s own systems were never touched. The tokens came from third-party applications that users had authorized to connect to their accounts, and those applications had been quietly compromised.

The entry point was not GitHub. It was not even the organizations that lost their data. It was the CI/CD tools those organizations had connected to GitHub months or years earlier — tools that had been granted broad read and write permissions that were never revisited.

That is the OAuth problem in plain terms. The moment you authorize a third-party application; its security posture becomes your problem too. Most organizations have dozens of these connections sitting open across their SaaS platforms — and no one reviewing them.

Microsoft in 2023

The Microsoft case from 2023 is the one I bring up when people assume this only happens to careless organizations. Wiz Research found that Microsoft’s own AI team had exposed 38TB of internal data — private keys, passwords, and more than 30,000 internal Teams messages — through a single misconfigured Azure access token. The token was supposed to share one training dataset on GitHub. Instead, it opened an entire storage account to anyone who found the link.

What gets me about this one is the timeline. That token had been sitting there since October 2021. Nearly two years, inside Microsoft, before anyone caught it. If a team with that level of resources and expertise can leave a door open for two years, the idea that “we’d notice” is not much of a security strategy. And it’s worth noting — this wasn’t a database leak. It was Teams messages. The same collaboration tools your employees use every day are just as exposed as the platforms holding structured records.

Why traditional security tools miss this

Cloud Security Posture Management tools — CSPM — are designed to monitor infrastructure configuration: virtual machines, storage buckets, network rules, and IAM policies at the infrastructure level. They do an acceptable job at that layer. What they do not do is look inside SaaS applications. CISA’s Secure Cloud Business Applications (SCuBA) guidance specifically calls out the gap between infrastructure security tools and SaaS-layer visibility as one of the most under addressed areas in enterprise cloud security.

This is the gap SSPM was built to close. Instead of watching infrastructure, it watches the configuration of the SaaS applications themselves — permissions, sharing settings, who has access to what. And the distinction is not just academic. Infrastructure misconfigurations tend to expose systems. SaaS misconfigurations tend to expose data — directly, quietly, and often without any detectable attack activity at all.

Ashish Mishra

What security teams should do now

You do not need to deploy a full SSPM platform tomorrow to start closing the gap. There are practical steps that move the needle immediately.

• Audit connected OAuth applications across your primary SaaS platforms. Revoke any integration that cannot be justified by a current business need.
• Common source of public data exposure: Review guest and external sharing permissions in Salesforce Communities and Microsoft SharePoint.
• Check whether legacy authentication protocols are disabled in Microsoft 365. Legacy auth bypasses MFA and becomes a potential entry point in enterprise environments.
• Establish a quarterly access review for high-privilege accounts in SaaS applications. Most organizations run annual reviews at best — that is not frequent enough for platforms that change configuration daily.
• A map of which SaaS applications hold sensitive data, and which have no security team ownership at all. That list will be longer than you expect.

The core issue is not that organizations are careless. It is that they have built security programs around the perimeter and the infrastructure, and SaaS applications grew up inside that perimeter without ever being brought into scope. The data is there. The access is there. The misconfiguration is often there too. What has been missing is the visibility to see it.

SSPM closes that gap. But even before a formal tool is in place, simply asking the question — what can the applications we already run see and share? — is a meaningful first step. In my experience, the answer surprises almost every organization that takes the time to look.

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

Meta is reportedly planning a cloud business that would sell access to AI computing power and models, extending its internal infrastructure into a commercial service for outside developers and enterprises. Reuters, citing Bloomberg’s reporting, noted that the planned offering would allow customers to access AI models hosted on Meta’s infrastructure and pay based on usage, effectively positioning the company in the infrastructure-as-a-service and AI platform markets. On the surface, this seems like a logical next step. If you are already spending enormous amounts of money to build AI infrastructure, there is a natural temptation to ask whether some of that investment can be monetized beyond your own internal use.

I have seen this pattern before. A company builds sophisticated internal systems, recognizes their value, and then begins to imagine that becoming a cloud provider is simply a matter of exposing those capabilities to external customers. It sounds straightforward, especially given the excitement around AI and the demand for high-performance infrastructure. But cloud computing is not just another distribution model. It is not simply a matter of offering on-demand multitenant services and charging a fee. It is a deeply operational, trust-based business in a market that punishes companies that do not fully understand what enterprise customers require.

A crowded neocloud market

The first problem Meta faces is that this is not an open opportunity. The neocloud space, meaning purpose-built AI infrastructure delivered as a service, is already crowded and increasingly difficult to enter. Amazon, Microsoft, and Google dominate the conversation for obvious reasons. They have years of cloud operating experience, broad service portfolios, global reach, mature ecosystems, and deeply established enterprise relationships. Oracle remains a serious player as well, especially in enterprise applications, data platforms, and performance-sensitive workloads. IBM still matters in hybrid cloud, operations, and industries where governance and regulatory rigor remain central.

That list alone should give Meta pause. These companies are not just infrastructure vendors. They are experienced cloud operators. They have spent years building not only the underlying platforms, but also the native capabilities enterprises now expect by default. Those capabilities include security, governance, identity management, observability, support, compliance, billing controls, resilience planning, and integration with the broader enterprise technology estate. These are not secondary features. They are part of the core value proposition.

This is why late entry into the cloud market is so hard. A new provider is not just competing on price or capacity. It is competing against accumulated trust. Enterprises are not casual buyers. They are selecting long-term operating environments for applications, data, AI models, and business-critical processes. They want confidence that the provider understands how these services will be consumed, governed, and supported over time. Meta is entering a market where the incumbents already have a major head start on all of those fronts.

Harder than it looks

Over the years, I have had many technology companies come to me and say they wanted to reposition their technology in the cloud space, either as software as a service or infrastructure as a service. In the beginning, enthusiasm is always high. The technology is impressive. The market size looks attractive. The revenue models appear compelling. Investors love the story. Then we begin to walk through what it really means to operate as a cloud provider, and the optimism usually fades fast.

The questions become very practical and very uncomfortable. How will tenants be isolated? How will identity and access controls work across different kinds of customers? What governance models will be built in natively? How will workloads be monitored, optimized, and secured? What does support look like 24 hours a day, across regions, across industries, across compliance boundaries? How will outages be handled, communicated, and remediated? How will the platform integrate with existing customer tools for operations, policy management, and security response? How much investment will it take just to become credible before you even begin to differentiate?

Once companies fully understand the complexities, market dynamics, and the capital and execution required to compete even with secondary players, many of them back off. They realize that cloud technology is not a packaging exercise. It is a transformation in how a company designs, operates, supports, sells, and evolves technology. That is why I remain skeptical when any company assumes it can translate internal infrastructure excellence into external cloud success without a very long, disciplined commitment.

Meta’s market readiness

Of course, Meta is not lacking in financial resources. If any company can afford to spend aggressively in this space, it is Meta. The company has the capital to build infrastructure, absorb losses, hire experienced talent, and stay in the market long enough to make a serious attempt. I would never argue that Meta is too small or too poor to try. Quite the opposite. If there is any non-traditional entrant with the financial scale to force itself into the conversation, Meta would be high on the list.

But money does not erase complexity. It only gives you the chance to confront it. The real question is not whether Meta can afford to become a cloud provider. The question is whether Meta has what it takes to become an excellent cloud provider. Those are two very different things. Enterprises are not going to move meaningful workloads to a new platform simply because the company behind it is wealthy or technically famous. They are going to ask whether the provider understands enterprise consumption patterns, enterprise risk, enterprise governance, and enterprise operations.

That is where the challenge becomes much more serious. Meta has extensive experience running infrastructure for itself. That is valuable, but internal operating excellence is not the same thing as external service maturity. Running systems for your own workloads allows a high degree of control over architecture, standards, priorities, and operating assumptions. Running systems for paying customers requires flexibility, consistency, transparency, and support across a wide range of use cases that you do not control. Those are very different disciplines, and companies often underestimate the gap between them.

What exactly is Meta?

Another concern here is strategic clarity. Meta already has a complicated market identity. It is a social media company, an advertising platform company, a hardware company, an AI company, and still, in the minds of many, the company that spent billions pursuing the metaverse. If it now wants to be viewed as a serious cloud infrastructure provider, it will need to explain not only what it is offering, but why customers should believe this is a durable long-term commitment and not just another adjacent experiment.

That uncertainty can be damaging. Customers want stable providers with clear strategic intent. They do not want to architect important systems around a platform if they suspect the provider may lose interest, shift direction, or reframe the business after a few years of uneven results. Cloud computing requires patience, consistency, and deep customer orientation. It is not a market where strategic ambiguity helps.

This could become confusing for Meta internally as well. Building a true cloud business demands focus. It demands years of investment in areas that may not be glamorous but are absolutely necessary, such as governance, operations, controls, support frameworks, partner programs, and enterprise sales alignment. If the company is not willing to make those sacrifices fully and for the long term, the initiative will struggle.

OpenClaw’s announcement that it has become a nonprofit foundation is generating IT excitement because of the potential for governance and development consistency that the popular platform has thus far lacked. Still, some worry about the risks created by the move. 

“Our ambition is for OpenClaw to be the Switzerland of AI. Neutral ground where every model and every lab can plug into the technology and collaborate on standards in the era of agents,” OpenClaw said in a post. “That work is already underway in Foundation-convened councils on agent identity, agent profiles, evals, and enterprise deployment.”

The statement, co-authored by OpenClaw creator Peter Steinberger, pointed out, “the great open source projects of our time — Linux, Apache, Mozilla — endure because a neutral steward stands behind them. That is the role we are taking on to keep OpenClaw MIT licensed, open, and independent so that everyone building on it can trust it will be here for the long term.”

But it reassured users that the original OpenClaw leadership is still in charge.

“Peter built this thing and Peter keeps making the calls, especially the technical ones. Since joining OpenAI earlier this year, he has continued to steward OpenClaw as an open and independent project, and OpenAI has made a commitment to keep it that way,” the post said. “The foundation is here to serve: good governance, stable funding, and paying the people who keep the claws alive.”

However, some analysts and consultants were skeptical about how much true independence Steinberger would have, given his salaried role with OpenAI. 

Neutrality claim in question

“The Switzerland of AI neutrality claim collapses under its own announcement,” said Noah Kenney, principal consultant at Digital 520. “OpenAI runs a team [at OpenAI] called Claw Labs that Peter leads and OpenAI is a major donor to OpenClaw. The ‘neutral steward’s’ chief technical decision maker is employed by one of the competing labs it is supposed to be neutral with.” To OpenAI, he said, OpenClaw is closer to a tax-exempt nonprofit subsidiary than it is to a neutral ‘Switzerland of AI.’

He pointed out that, in addition, Microsoft is shipping the enterprise version of OpenClaw, and Nvidia is shipping the hardware bundle. “This is being called the Switzerland of AI, but Switzerland does not have its central bank run by France,” he observed.

Kenney said that what the new OpenClaw has actually built is “a shared dependency that several competitors fund, staff, and steer, wrapped in a nonprofit structure. Enterprise IT should understand that structure, because treating OpenClaw as neutral is a mistake,” adding that CIOs need to look at this development devoid of the emotional component. 

“There is a strategic irony here that CIOs should sit with,” Kenney said. “If OpenClaw succeeds at becoming the universal agent substrate, then every model plugs into the same identity layer, the same profiles, and the same deployment plumbing. The thing every vendor is racing to own becomes a commodity that nobody owns.” He pointed out that, in the short term, that is genuinely good news for buyers because it means less lock-in and more portability.

“But,” he said, “when the connective tissue is free and natural, the only labs that benefit are the ones with the best models and the deepest distribution. Commoditize the layer below you and you compete on the layer where you are already strongest. The foundation is not a charity. It is the biggest players agreeing to stop fighting over the plumbing so they can fight over the water, and the enterprise is the one paying the water bill either way.”

Good news, bad news

Jason Andersen, principal analyst at Moor Insights & Strategy, liked the potential consistency that could emerge from the structural change, given the complexity of agent development today. 

“We are seeing a lot of OpenClaw variants hit the market, such as those from Nvidia as well as competing products from cloud and SaaS vendors. A common base helps solidify the common parts,” Andersen noted. “That said, a common challenge is the sustainability of these open source foundations over time. In addition to releasing code, these foundations need funding to evolve and grow. And that funding needs to come from continued momentum to incentivize existing members to increase investment and recruit new members to join.”

Andersen stressed that IT buyers need to keep an eye on the roadmap for any OpenClaw variant they choose to deploy, “as that will directly impact the foundation, and the momentum of the foundation and common base. If the common base loses momentum, it can lead to forks, or just a loss of innovation. When that happens, members tend to back away, which puts customers in limbo.”

But not everyone sees the promised structure as entirely good for IT.

Ishraq Khan, CEO at coding productivity tool vendor Kodezi, said, “most CIOs do not want to bet their future entirely on a single model vendor. They want Claude for some workloads, GPT for others, open models for sensitive environments, and potentially internally fine-tuned systems for specific use cases. The problem is that every vendor currently brings its own identity system, tool interfaces, permissions model, and operational assumptions. That fragmentation does not scale.”

He said, “the risk if standards fail is straightforward: every vendor builds its own closed ecosystem, enterprises become locked into individual stacks, and security becomes dramatically harder. The opportunity if OpenClaw succeeds is equally significant: enterprises get portable agents, common identity standards, interoperable tooling, and a healthier competitive market around models rather than ecosystems.”

Will it remain a nonprofit?

However, said Justin Greis, CEO of consulting firm Acceligence, one of the key details that IT executives will want to keep in mind is that OpenAI also began as a nonprofit, but it was quickly seen as not adhering to nonprofit objectives. 

“OpenAI’s transition from a nonprofit research organization into a more complex structure highlighted the challenge of maintaining mission alignment while scaling technology, capital, partnerships, and commercial operations,” Greis said. “OpenClaw has the opportunity to address some of those governance questions earlier by establishing clear principles around neutrality, transparency, and decision-making before the ecosystem becomes even larger and more valuable.”

He noted, “we have seen this pattern before with technologies like Linux and Kubernetes. The strongest open ecosystems succeeded because they created trusted foundations that enterprises could build upon. The technology was important, but the governance model that underpinned it was equally critical.”

Risks are ‘squarely in IT’s lap’

Consultant Brian Levine, executive director of FormerGov, echoed Greis’ concerns. 

“CIOs shouldn’t assume that this nonprofit will always be a nonprofit, or confuse being a nonprofit with actually being neutral or unbiased,” he said. “The risks are squarely in IT’s lap: autonomous agents ‘with their own identity’ acting on a user’s behalf blow straight through traditional IAM assumptions. Issues, such as agent identity, auditability, secret handling. Identity boundaries have not yet been reliably solved. Until they are, enterprises should treat OpenClaw agents like privileged service accounts, not like a browser plugin.”

Independent cybersecurity and risk advisor Steven Eric Fisher pointed to another IT exposure that might come from this OpenClaw transition: Cost.

“OpenClaw currently has a very high token burn rate in usage, which presents a significant cost consideration for large-scale enterprise adoption,” he said. “The skills marketplace introduces a new supply chain threat that enterprises will need to manage. Threat management, and specifically handling external marketplace elements, can be highly challenging for open-source operations. Ultimately, at scale, enterprise adoption could become a difficult balancing act between managing high operational costs and securing an expanded security surface.”

This article originally appeared on Computerworld.

These days, application developers can take their pick from a vast menu of architectural solutions. We can choose from the well-understood to the experimental, and from blended solutions in between. Several powerful middle-ground technologies that emerged during the cloud revolution have really come of age. Here we’ll take a look at putting together three of the most impressive: GitHub, Vercel, and Firestore.

Each of these is an important tool in its own right that can be used to attack specific problems. In combination, they not only meet the needs of several important application scenarios, but they have a superpower—the ability to dramatically shorten the distance between development and deployment.

There is nothing quite as gratifying as putting your hands on just the right mix of tools for a given need.

A ‘no-ops’ stack built for speed

If your primary goal is sheer development velocity, you would be hard-pressed to top this architecture. This “no-ops” stack collapses the distance between your local IDE and a globally distributed production environment. You are essentially trading the overhead of managing VMs and load balancers for the sheer speed of committing code and watching it deploy automatically.

While each component is highly flexible, adopting them requires a specific, event-driven mindset. There are a few finicky bits to manage, mostly around routing environment variables securely and designing around stateless back-end functions. But the constraints are obvious and well-documented.

Before we look more closely, let’s quickly identify the kinds of apps that are a perfect fit here, along with those that are workable and those that really merit a different approach.

• The sweet spot (deploy and go): AI-mediated applications, asynchronous game back ends, and real-time collaborative B2B dashboards. This architecture perfectly absorbs the unpredictable latency of LLM APIs and instantly syncs state across multiple clients without requiring you to build custom WebSocket infrastructure.
• The middle ground (workable, with trade-offs): Headless e-commerce, moderate IoT telemetry, and apps requiring scheduled batch processing. You will encounter friction if your catalog relies on deeply relational SQL constraints, or if your background reporting jobs take longer than a few minutes and hit serverless execution limits.
• The danger zone (look elsewhere): High-frequency trading, fast-paced action multiplayer games, heavy data ETL pipelines, and core financial ledgers. Serverless architectures cannot natively hold open the persistent WebSockets required for twitch-reflex data, and heavy compute tasks will abruptly time out.

We should mention that these categories are not mutually exclusive. Many enterprise applications, such as a full-scale e-commerce platform, straddle these lines. You might use Vercel and Firestore to build a lightning-fast, reactive storefront that handles ephemeral user state like shopping carts, while simultaneously “stitching in” a managed SQL database like Supabase or PlanetScale. This hybrid approach allows you to maintain the relational integrity required for back-office inventory and financial ledgers and pair it with the front-end velocity this stack provides.

GitHub: the bedrock

I don’t need to introduce you to GitHub. It is a central element of the development landscape. I still remember CVS and SVN with a certain nostalgia, but the enhancements of Git speak for themselves. When combined with the orchestration powers of GitHub, it is no wonder that virtually the whole industry has adopted this type of platform.

Git plus GitHub gives you an enormous amount of power already, in terms of how you can organize and automate your projects. But there is a next-level experience in combining GitHub and Vercel. For JavaScript-based projects, you can take simple GitHub pushes and turn them into instantly deployed clients and serverless functions. It is one of the cleanest and least fiddly ways to move from raw code on your local machine to a globally deployed, full-stack architecture.

Vercel: the nexus

Vercel is more than just a deployment host. It is a control plane that ties this high-velocity, no-ops architecture together. Alongside GitHub and Firestore, Vercel’s deeper strength is its ability to act as an orchestration layer between your reactive front end and external stateful services.

Vercel has a great amount of facility in fine-tuning what branches go to what environment and helpful features like instant rollback. You can just log into Vercel’s dashboard for your project and see the history of deployments and any errors and logs. It’s a simple menu choice to roll back to a historical version or compare one version against another.

When you “stitch in” third-party services (such as a managed SQL database like Supabase or a payment processor like Stripe), Vercel’s serverless functions become the lightweight interface, and Vercel’s the adapters handle the communication. You offload the integration logic (the service layer) to Vercel’s global Edge Network, keeping your UI and back end clean, responsive, and decoupled. 

In short, Vercel allows you to get the speed of the “no-ops” development life cycle without sacrificing the complex transactional integrity required for some applications like enterprise inventory systems.

Firestore: the datastore

Firestore is an extremely lightweight, NoSQL, cloud datastore. It has a great deal of add-on power, but its core value proposition is that it accepts virtually any data you stuff into it and it provides event-driven subscriptions to data changes.

These two capabilities together make Firestore about as straightforward a solution to a managed back end as you can imagine. You subscribe to collections or even fields and then you simply stick “unstructured” data (read: JSON with variable fields) in and the client waits for the changes it is interested in.

This is so streamlined that one can just point the browser (or native mobile app) directly at Firestore and listen for events. Which immediately raises the question of identity, for auth and for data visibility, but hold on—Firestore’s third superpower is that it has an authentication module that actually works. What I mean is, it is actually pretty simple and yet confidently secures your app.

Sometimes auth solutions seem either too simple (and yet opaque) or too mired in the nitty gritty. Firestore auth will let you do some basic configuration and start using a reasonable auth almost immediately. 

Not to belabor the point, but having a realistic and attainable auth solution elevates your stack to a production grade—one that can handle many real-world applications. Firestore auth plays nicely with other important APIs, like Stripe. Typically, auth is a major feature that feels like off-roading in a Honda Civic, but Firestore’s approach to auth, added to this particular stack, feels like a normal speed bump. It’s just another component you plug in, rather than a tentacled alien you weave into the your code.

The limits of the velocity stack

This architecture combines components that are optimized for flexibility. That same character also introduces distinct limitations. Understanding these is essential before committing production workloads.

The serverless life cycle

Serverless functions are spun up to handle requests. They close out soon afterward and lose any state. For that reason, they cannot natively hold open persistent WebSockets. If your system requires continuous, sub-millisecond, bidirectional streams—like a real-time multiplayer action game or a high-frequency trading dashboard—pure serverless will fight you all the way. You are forced to introduce a third-party managed WebSocket service to route messages back to your stateless endpoints via HTTP webhooks.

The execution time ceiling

Vercel (like all serverless platforms) enforces strict timeouts on operations. While enterprise tiers might grant you up to 15 minutes, standard functions often time out after 10 to 60 seconds. Long-running tasks like video transcoding, database scripts, or orchestrating multi-step AI agent workflows, which might take 20 minutes to resolve, will run up against these limits. Heavy-lifting tasks must be offloaded to a dedicated, long-running service like Google Cloud Run, or broken into smaller, asynchronous chunks via message queues.

The cold start reality

While the industry has made massive strides in minimizing initialization times—particularly with lightweight edge networks—traditional Node.js-based serverless functions still experience cold starts. If a function has not been invoked recently, or if traffic spikes require a new instance to spin up concurrently, the first request will take a noticeable latency hit as the container provisions and the code loads.

API instead of RAM

In a traditional server environment, you can store transient data in global RAM, allowing subsequent requests to access shared context instantly. In the serverless model, every request might hit a fresh container. Therefore, all shared context must be externalized. Although Firestore serves brilliantly as the state manager, relying on a database for high-frequency, sub-millisecond, ephemeral caching introduces network latency and per-operation costs. That said, using a shared RAM state on a server is non-trivial also, unless you are using a single app server and VM (because high-availability or fail-over requirements will lessen the RAM win on a traditional server).

Tuning for velocity and control

Every architectural decision is a trade-off. There are no cost-free choices. By adopting the GitHub, Vercel, and Firestore stack, you are explicitly maximizing feature velocity over fine-grained control.

You lose the ability to tweak the underlying operating system, hold open persistent sockets, or run hour-long back-end scripts. In exchange, you gain an architecture that scales from zero to global distribution instantly, requires virtually no devops maintenance, and perfectly absorbs the asynchronous, event-driven realities of modern application development.

For the right application—whether it is a fast-moving prototype or an enterprise AI copilot—this stack doesn’t just save time; it fundamentally changes how quickly a small team (or a single person) can impact the market. You stop worrying about build chains, load balancers, and server patches, and you focus on the central mission: shipping features.

Gen AI spending is moving beyond the familiar software model of seats, licenses, and pilots. As AI shifts from copilots to embedded workflows and autonomous agents, one user request can trigger multiple model calls, retrieval steps, retries, orchestration layers, and infrastructure events. A tool that looks affordable in pilot may behave very differently once connected to production systems or allowed to act with less human supervision.

According to Michael Corrigan, CIO of World Insurance Associates, AI introduces a fundamentally different cost model — one that’s usage driven, non-linear, and tightly coupled to business activity. “Success requires shifting from traditional IT budgeting to FinOps-style discipline where consumption, value, and governance are actively managed in real time,” he says.

Here are five ways CIOs can build that discipline before AI costs spiral.

Forecast AI by workflow, not by user

At World, a top 25 insurance broker with about 3,000 employees across roughly 300 locations, AI use falls into three broad categories, Corrigan says. One is broad tools, such as copilots. Another is embedded AI inside SaaS platforms. And the third is bespoke AI built around specific workflows and manual processes.

“The bespoke is the area that’s growing the most right now,” he says. “And that’s where the model, from a cost perspective, has really been shifting from a license seat cost to a token consumption or token burn cost, or even a hybrid.”

Seat-based pricing is relatively easy to forecast whereas consumption-based AI isn’t. Costs may depend on prompt complexity, output length, model choice, workflow design, and whether the system calls a model once or many times in the background.

World tries to manage that uncertainty by defining the business problem, success criteria, and expected operational improvement upfront. Pilots help estimate consumption before scaling, but Corrigan says they don’t remove the ambiguity.

“We’ll try our best in the pilot to understand what the consumption rate is, what the token burn rate is,” he says. But once a consumption-based workflow goes into production, he adds, an estimate is put into place. That estimate is informed, but still rough.

Elmer Morales, founder and CEO of koder.com, an agentic AI coding startup, says CIOs should think less about headcount and more about workflow mechanics. Agentic AI costs are driven by the number of decisions an agent makes, how often it retrieves external data, how much context it carries, and how many systems it touches.

“CIOs should start by mapping workflows, not necessarily users,” he says. “The relevant variable isn’t going to be the headcount but how many decisions an agent makes per task.”

Model the failure path, not just the happy path

Pilots can mislead because they often test the cleanest version of an AI workflow. Morales says many enterprises model agentic AI costs around the happy path: the user gives a clear prompt, the system understands the request, the agent completes the task, and the process ends. Production is messier.

“They generally don’t model for situations where the agent is going to need to go back and check its work and redo things,” Morales says. “A lot of times, agents are wrong, either because they hallucinate or they understood the problem incorrectly.”

In an agentic workflow, the system may check its work, call another tool, retrieve more data, or redo a step. While that may improve quality, it also adds cost.

The difference between copilots and agents is central. A copilot interaction is often one prompt and one response. An agentic workflow may involve agents moving through a decision tree, executing tasks in sequence or in parallel, and calling sub-agents or external systems along the way. “By the time it’s achieved the original goal, the agent might have made 50 or 100 model calls, compared with a single call for a traditional copilot prompt,” Morales says.

That’s why CIOs should require teams to model the failure path before production, like how many retries are allowed, how much context is resent, which tools can be called, when a human should intervene, and what happens when the agent can’t complete the task.

Build cost controls into the architecture

Traditional FinOps practices still matter, but AI requires more than retrospective dashboards and chargebacks.

According to Pavan Madduri, senior cloud platform engineer at industrial supply company Graigner, looking backward at usage data, as traditional FinOps often does, can be too late. Costs are shaped by prompt design, model selection, agent behavior, orchestration choices, and runtime loops.

“Dashboards or chargebacks, those are historical accounting,” he says. “The money’s already gone.” For AI, he argues, cost controls need to be embedded into the architecture. That includes hard token caps, retry-depth limits, maximum runtime limits, workload prioritization, background-job throttling, and cluster-level controls that prevent runaway consumption.

“The real FinOps means you need to have the cost constraints embedded into your architecture framework,” Madduri says.

Those controls also extend to infrastructure. Expensive GPUs may sit warm between jobs because systems need capacity available when inference demand arrives. Teams may pass huge schemas, databases, or thousands of lines of code into frontier models when a smaller or more focused prompt would do.

Enterprises should also adopt event-driven autoscaling, Madduri says. “Use tools like KEDA to scale GPU nodes down to zero the moment inference demand drops, so teams only pay for the windows when the silicon is actively crunching tokens.”

Corrigan says World uses rate limits, spend limits, alerts, and approval gateways for consumption-based tools. When users approach token consumption limits, automated alerts allow IT and the business to review whether the continued spend is justified.

“If it’s not meeting the success criteria we expected, you have to have the control in place to say we’re going to move on or kill that process,” Corrigan says.

Route work to the right model

CIOs can also reduce AI bill shock by avoiding a default assumption that every task requires the most powerful model available. While some tasks need advanced reasoning, many others don’t. A simple support ticket, log-parsing task, or structured database transaction may be handled by a smaller or cheaper model. A complex architecture decision, legal analysis, or multi-step reasoning task may justify a more powerful one.

“Choosing the right model for the right prompt and right question — that’s where you leverage the maximum from that model, and you can decrease the costing,” Madduri says. “If you default every single call to a frontier model, that’s architectural laziness.”

Morales makes a similar point. Not every step in an agentic workflow requires a top-of-the-line model. Model routing, he says, is the discipline of determining the best model for the task, and providing the relevant context when the model needs it.

According to Jim Olsen, CTO of enterprise software company ModelOp, CIOs should use the least expensive model that can accomplish the business goal. Using the biggest model for everything is easier, but expensive. “It’s like hiring the most expensive engineer to change a few colors in a website’s CSS, or visual styling,” he says. “You wouldn’t do that. You use the appropriate tools for the task.”

Tie consumption to business value

For Olsen, the deeper enterprise problem is AI value shock, not just bill shock. Spending $200,000 in a quarter on AI is justified if it produces $2 million in business value. The problem is spending heavily on use cases that don’t generate a meaningful return.

“Are you actually getting that return on investment, or are you just blowing tokens for something that’s not delivering the value to your business?” Olsen asks. Tracking token usage by user or department may show who consumed AI, but not whether the consumption mattered.

For most enterprise AI systems, Olsen says costs should be tied back to business use cases. A model may be used for HR document search, customer support, code review, problem resolution, or other functions. Each use case may draw on the same underlying models or agents, but the business value can be very different.

That’s why he argues that companies need an AI inventory, a record of which business workflows use which models, agents, providers, workflows, and systems. Without that inventory, enterprises can’t connect consumption to value.

Corrigan takes a similar approach from a governance perspective. At World, new AI ideas go through an intake process. Business users propose improvements, and IT, finance, operations, sales, and business stakeholders evaluate, prioritize, and monitor them from pilot through production.

That may be where the next stage of AI FinOps is heading, toward a clearer understanding of which AI consumption deserves to scale, not just to lower bills. So the question, as Olsen puts it, isn’t whether someone used a million tokens. It’s what are they using them for.

Europe is sweltering. The summer of 2026 has seen historic heat waves that have taken a significant toll on infrastructure. In recent weeks, across the continent, problems have been reported in the power grid, telecommunications, and rail transportation. IT infrastructure has not been spared from the situation.

“The heat affects equipment long before anyone notices a problem,” explains Ricardo Román, sales director at Fracttal, in an email. “Every piece of equipment has a temperature range within which it is designed to operate, and when it operates above that range, it begins to degrade silently,” he says. A process of wear and tear begins that will eventually take its toll. With technology, this happens much faster. “In a data center, this effect is amplified because there’s no margin for error,” he notes. When something starts to fail, everything grinds to a halt.

In fact, this latest heat wave has already had negative impacts on data centers outside of Spain. In the United Kingdom, high temperatures shut down hospital data centers and caused the University of Cambridge’s Dawn supercomputer to go offline, as its cooling systems were unable to cope with the temperatures. That’s the crux of the problem. “In IT, heat isn’t a computing problem—it’s a problem of maintaining the assets that support the data center,” explains Román. 

Heat thus becomes yet another risk for the IT industry and, in particular, for data centers.

Temperatures are a clear and growing concern when it comes to corporate risk prevention. “I see it in conversations with clients: In the past, the maintenance team was the one monitoring the temperature in a technical room,” Román says. “Today, management also monitors it, because they know that if that goes down, the service goes down—and behind the service is the end customer,” he adds. Maintenance has gone from being a cost “to a lever for business continuity that no one dares to touch.”

As a World Economic Forum analysis warns, we’re experiencing a boom in AI-driven data centers, but the impact of climate risks on them is being overlooked. Their estimates suggest these risks could result in an additional annual cost of $81 billion by 2035 and $168 billion by 2065. These calculations include all kinds of threats, such as floods or droughts, but most of the impact comes from extreme heat.

These projections are confirmed by data from the industry itself: Over the past three years, extreme weather events have accounted for one-third of the losses incurred by the U.S. division of the data center company Zurich. According to projections by the climate risk analysis firm First Street, 79% of global data centers will face increased risks from extreme weather. MapleCroft estimated in 2025 that 56% of major data centers had a high or very high risk rating for extreme heat, and that this figure would rise to 80% by 2080.

These percentages cannot be easily extrapolated to Europe in general—and to Spain in particular—as one might think, although they do make the trend clear. Guillermo Benito, CTO of Nabiax, points out during a video call that these studies are based on global samples and thus place significant weight on the capacity of Asia and the United States. “We represent a small percentage there, but that said, all countries will have to adapt. The two major challenges for data centers are energy and cooling,” Benitonotes.

Spain: A pioneer in heat?

In late June, French Labor Minister Jean-Pierre Farandou proposed taking a training course in Spain to learn how to prevent high temperatures from paralyzing a country. Although Spain’s climate varies by region, high summer temperatures are common in many areas (though climate change has made them more extreme and frequent in recent years), and the infrastructure of knowledge and solutions that Farandou wanted to learn about has been established. The big question is whether this also applies to data centers. Is Spain better prepared than other European regions?

“Heat waves are becoming increasingly intense and frequent. What used to happen once every two years now happens two, three, or four times a year,” Benito says. Speaking from his own experience, he adds: “In Spain, data centers already take these factors into account.” When it comes to redundancy, monitoring, or maintenance, these factors are already factored in. “It’s not like it’s an unforeseen event. It’s already been taken into account, and we build in a lot of redundancy—a wide safety margin,” he says.

The difference compared to central or northern Europe is that some haven’t considered this possibility. Benito points out that the same thing happens with homes. “For many years, they’ve been designing with two assumptions: that they have plenty of water because their climates are humid, and that it never gets hot,” he says. And this is a problem, because their summer temperatures have risen significantly during extreme heat waves. “Temperatures in the UK have gone up by 10 or 15 degrees, and their data centers aren’t prepared for that,” he says. In fact, he shares an anecdote about “a certain hyperscaler that, a few years ago, when its data centers in the United Kingdom went down, held a global conference to figure out how this had happened and draw lessons from it.” The curious thing is that what they learned was something that was already well known in Spain.

İsmail Enes Ayhan | Unsplash

It was already getting hot in southern Europe, and preparations were needed. Now, temperatures are becoming a topic of conversation outside the region, and climate change has made its way into IT strategy. Benito confirms that, yes, the conversation is more visible in global settings. “For several reasons. The first is because, obviously, it affects operations. Another is the market. Customers also demand that you address this.” Before, the focus was on power capacity and square meters. Now, the expert points out, people are asking where the electricity comes from and whether it’s clean, and they’re demanding emissions guarantees. The sector is making significant investments to become sustainable, he argues.

Beyond consumption data and the improvements that can be made, the big question is whether these high temperatures are already impacting decision-making—whether decisions on where to locate data centers (or not) are already being made with heat in mind.

Industry representatives explain that while the climate can have an impact and is already taken into account when deciding where to locate a data center, it is not yet the sole factor or the most decisive one. In other words, many other factors must be considered, and these carry much more weight in the decision-making process. One such factor is energy, which is essential for these infrastructures and must be constant, resilient, and have a low carbon footprint. It is also an area where cooling plays a major role. As Román points out, cooling can account for between 30 and 40% of energy consumption, “and in poorly managed facilities, that figure approaches 50%.” Energy efficiency and cooling efficiency are thus essential—and not just for sustainability reasons. “It’s a matter of the bottom line.”

Another factor is space. As Benito says, you need “stable locations where you can grow.” This isn’t just about whether the infrastructure fits, but also about how it aligns with the needs of its customers. As this expert points out, the concentration of data centers near Madrid or Barcelona isn’t “just a whim,” but because you need to be close to large population centers to provide them with low latency. “Other supercomputing applications can be located farther away, and that’s already happening,” he explains, but generally speaking, you can’t just put data centers anywhere. You have to strike a balance between needs and available space.

How to survive the heat

So, how can we survive the heat, especially when projections suggest that the future will bring even higher temperatures? The key is to understand that this is no longer a curiosity or an occasional incident. As Román points out, air-conditioning systems are running longer and longer. What worked 10 years ago will now barely suffice—it’s “pushed to its limits.” “Heat is shifting from being an August blip to a variable that must be monitored year-round. One you endure; the other you manage.”

“By the time the room’s thermometer rises, it’s already too late. What you need to monitor isn’t the room—it’s the equipment—and you have to do it sooner,” he says. Román recommends a three-step strategy. First, don’t measure the environment; instead, measure the equipment and its variations in temperature, vibrations, and energy consumption. Next, take action on any deviations: Don’t wait for a failure, but instead act on early indicators that things aren’t normal. And finally, keep a comprehensive record of historical data, which will be key to anticipating issues and learning from them. “And here I’m going to be honest, because this is what I see every day: The technology to do all this already exists and isn’t expensive,” he asserts. “Many critical facilities are still managed using an Excel spreadsheet and the memory of a technician who’s been there for twenty years,” he warns. And that’s a problem.

In the specific case of data centers, Spain has done its homework. The high temperatures (which exceeded those recorded in the United Kingdom, where some data centers did shut down) did not bring them to a halt during this heat wave.

Unlike what might happen in other countries, Spain has optimized its cooling systems to be efficient and sustainable, as Benito explains, noting that the country must also contend with water stress. “In other countries, I can use water and let it evaporate as I please because I know it’s going to rain again—or at least that was the case until recently. In Spain, we’ve known for a long time that this isn’t the case,” he says. That’s why we work with closed-loop systems. “Most of us operators don’t use any water,” he says. The same water, mixed with certain cooling agents, circulates continuously. “Once the loop is filled, we don’t lose a single drop,” he asserts.

What this expert is now seeing at international conferences is that in other countries where water wasn’t an apparent problem, people are starting to talk about working this way—”as a technical innovation.” “That’s where we say, ‘Yes, just like the ones we have in Spain or Portugal,’” he remarks with a touch of humor. “Water, like energy, is a challenge,” he says, so everything has already been designed with that in mind. It isn’t wasted, it doesn’t evaporate, and it isn’t consumed, he says.

I attended several major technology conferences in 2025 where the first AI agents embedded in enterprise SaaS platforms were announced. Some of these agents showed promise and a glimpse into the future of work, while others looked like natural language extensions of a platform’s existing functionality.  

At the end of 2025, Anthropic and OpenAI launched new AI models and code-generating capabilities. More developers tried vibe coding, and some platforms launched spec-driven development capabilities. By February 2026, even The New York Times reported that the AI disruption had arrived, noting that code generators were building “apps that may be flawed, but credible.”

Wall Street investors took notice of the code-generation improvements and other disruptive factors, driving a selloff in SaaS stocks, now referred to as the “SaaSpocalypse.” Part of their concern stemmed from the belief that CIOs would use AI to write software that would replace SaaS solutions.

AI innovations from SaaS and solution providers

But I thought differently and wrote a response in my article asking whether AI is the end of SaaS as we know it. CIOs might use AI to accelerate application modernization, but I doubt they would replace their ERP, CRM, and even smaller SaaS point solutions by building them.

Instead, I believed it would be SaaS companies that would take the most advantage of AI code-generation capabilities.

This hypothesis drove me to attend nine conferences this spring to see how SaaS companies were launching AI agents and defining a new future of work. I wrote eight articles on what CIOs need to know about data management, agile organizations, marketing, ERPs, critical process management, and other evolutions to plan for in the AI era.

Now, looking across all nine conferences, I can draw some conclusions about how AI agents are shaping the future of work. Here are my learnings and what CIOs need to consider when evaluating and deploying AI agents in the workplace.

Agentic, human-in-the-middle, or augmenting human?

SaaS companies have very distinct perspectives on the future of work, including the extent to which humans will play which roles and whether and how quickly we’ll see agentic, fully automated work.

For example, Atlassian proclaimed, “step into the future of human-AI collaboration,” while SAP unveiled “the autonomous enterprise.” Snowflake aimed to “make AI real for business,” while Appian targeted “serious AI built on process.”

These vendors’ marketers had to decide whether to lead with AI, people, or business in their messaging, but so must CIOs as they contemplate their AI strategies and how to get employees to fully adopt AI agents.

Some CIOs see a fully automated agentic AI as the future, with human-in-the-middle as a transitional phase as departments build trust in AI agents’ decision-making and automation capabilities.

Other CIOs see AI more as a tool that delivers productivity improvements by augmenting human decision-making capabilities. Many of these CIOs see human augmentation as essential to supporting critical thinking, innovation, and creativity.

Deloitte’s State of AI Report, published in January, provides a benchmark. It states that 36% of IT leaders expect at least 10% of their jobs to be fully automated in the next year, and 82% expect to reach that benchmark in three years.

Many organizations will have a mix of AI agents, choosing automation where reliability at scale is possible, but opting for human augmentation in operationally critical or customer-facing domains. But how CIOs position AI agents is not only an operational strategy; it’s also a cultural statement that shapes employees’ embrace of AI and whether detractors vocalize job-loss fears.

In the short term, it will also weigh in on which AI agents to use from different partners and which areas to build in-house.

Many options to test and deploy AI agents

Many solution providers are demonstrating significantly more AI agents this year. For example, SAP went from 40 Joule Agents in 2025 to over 200 in 2026. Three technology capabilities are fueling this significant growth:

• Adobe, Appian, Boomi, Cisco, Domo, Salesforce, SAP, Snowflake, and others offer data fabrics and data-pipeline capabilities to connect data sources outside the primary workflows supported by their platforms. Appian, Pega, Quickbase, and SAP also centralize business process automation, an important starting point for developing AI agents.  
• MCP servers enable integration and communication between AI agents and are used to facilitate multistep agentic workflows. Virtually all the companies announcing major investments in AI agents are also announcing MCP integration capabilities and related partnerships.
• Solution providers are not just using AI code-generating capabilities; many are launching their own AI agent development tools. The first beneficiaries of these development tools are the solution providers themselves and their integration partners, who use them to accelerate the development of AI agents and make them available to customers.

The result is that CIOs will have many options about which agents to test, but will have to dedicate analysts to understand the capability, cost, and compliance trade-offs. Additionally, expect AI agent capabilities to evolve significantly over the next few years, so CIOs should continuously revisit their decisions regarding deployed AI agents, focusing on performance, benefits, and ROI.

CIOs should also watch for signs of shadow AI and employee confusion about which AI agents to experiment with on different platforms. The AI strategy should include a transparent, defined process for selecting, reviewing, evaluating, procuring, deploying, driving adoption, monitoring, and collecting end-user feedback around AI agents.

AI development capabilities for engineers and citizen builders

The apparent ease-of-use of AI code generators may lead some engineering teams to build AI agents rather than buy them from SaaS providers. But CIOs should quickly realize that coding is just one step in developing AI agents, and that aggressively pursuing a build strategy can lead to AI debt and increased AI costs.

DevOps teams can code AI agents using tools such as Claude, Codex, Lovable, and Replit — a do-it-yourself approach. Some SaaS companies are providing an alternative, with AI agent development tools that leverage the data, infrastructure, and governance baked into their platforms. Many of these development tools offer flexibility, allowing developer teams to select AI models and development environments.

Examples of new and enhanced AI development tools I saw at conferences this quarter include:

• Appian Composer and Agent Studio
• Atlassian Rovo Dev
• Boomi Companion
• Cisco Cloud Control Studio
• Domo App Catalyst
• Pega Infinity Studio
• Quickbase Pave
• Snowflake CoCo
• SAP Joule Studio.

I also reviewed Nutanix Agentic AI, a platform-as-a-service for accelerating the deployment of agentic AI workloads, and Adobe Firefly AI Assistant for creatives.

These development tools can target different audiences. Some look like low-code development tools targeted at software developers, whereas others are no-code and enable citizen developers, i.e., businesspeople, to develop applications and agents. Additionally, some of these tools support spec-driven development and generate artifacts such as product requirement documents (PRDs), data models, and testing capabilities.

Before commissioning AI development for apps and agents, CIOs should sponsor proofs of technical, data, modeling, security, and governance capabilities.

The context layer powering AI agents

Between AI agents and the enterprise’s intelligence, including structured data sources, defined business processes, and agent interactions (both human-to-agent and agent-to-agent), lies an evolving “context layer.”

This layer refers to the enterprise knowledge that AI agents draw on when evaluating signals and recommending or taking actions. Context may include a knowledge graph, a semantic layer, cleansed document repositories, and other knowledge bases.

The context layer, skills, tools, out-of-the-box agents, and governance capabilities are some areas to review where solution providers differentiate. Some examples: 

• Many support the Open Semantic Interchange, and some brand their context layers, such as the Atlassian Teamwork Graph, Boomi Knowledge Hub, and the SAP Knowledge Graph.
• Some are branding their guardrails, such as Adobe’s AI Brand Intelligence, Appian’s Private AI, and Quickbase AI Control Center.
• To manage AI agents at scale, some are extending the notion of data catalogs and other governance tools to the AI domain with products such as Boomi Connect, SAP AI Agent Hub, and Snowflake Horizon Catalog.

CIOs should recognize that while solution providers will compete on capabilities, the real “secret sauce” of the context layer lies in the company’s trusted data, well-defined business processes, and employee adoption of AI agents.

Conversational user experiences and coworkers

AI agents use the context layer, but also tap into skills, which encode the procedures they can follow, and tools, which prescribe the actions they can take. Before AI agents are ready to pilot, their governance, including permissions, approval gates, and other guardrails, must be defined. Other capabilities to look for when defining AI agents include orchestration, testing evals, and observability.

In 2025, many solution providers bolted on AI agents to their existing user experiences. This year, many solution providers showcased new conversational user experiences that employees can use instead of traditional ones built with forms, flows, reports, and static dashboards. Conversational user experiences are where AI agents and people come together, whether it’s human-in-the-middle or human augmentation.

Solution providers also grouped their AI agents into assistants or coworkers. For example, Adobe CX Coworker illustrates human augmentation, helping marketers manage campaigns with prompts and monitor their performance. SAP launched Joule Assistants across several business functions, including finance, human capital, supply chain, and customer experience. Other assistants, such as Appian AI Copilot, Atlassian Rovo, Cisco AI Assistant, Nutanix NIVA, and Snowflake CoWork, offer AI-first user experiences to assist different end-user types.

CIOs should demo these AI-first user experiences to glimpse the future of work.

Developers are already getting used to these experiences through code generators and vibe coding tools. Now, similar capabilities are being tailored across all business functions. CIOs should ramp up their change management programs to accelerate the adoption of these AI capabilities.

Solution providers are showcasing AI capabilities that can help CIOs reshape their businesses. But in Q2, there were only a few examples of how AI can help CIOs drive growth, evolve business models, or embed AI into customer-facing products. I expect to see a wave of further AI innovations that will go beyond productivity improvements and efficiencies and help CIOs pursue growth-driving digital transformation strategies.  

Sacolick travelled to conferences mentioned in this article as a guest of Adobe, Appian, Atlassian, Domo, Nutanix, SAP, and Snowflake. In addition, he was hired by Quickbase to speak at its conference.

Since the advent of generative AI, the use of AI in business has shifted from something we should do to something we must do to survive. Many companies are now working to utilize AI with the aim of improving productivity and creating value.

Here, I would like to pose a question to you all once again: “What is the fundamental factor that determines AI performance?”

Is it the AI model? Is it the AI tool? Or is it the AI agent?

Of course, I believe all of these are important. However, if we look at the long-term perspective, the competition among multiple companies to improve AI model performance will eventually level off, and we will eventually reach a point where every AI model is amazing!

In that context, what I believe is the most important factor influencing AI performance is the data accumulated by companies that connects to their unique strengths.

For example, if asked, “What do plants need to grow?” I would say “good water and light.”

Similarly, if asked, “What do people need to thrive?” I would say, “Kind words.”

Finally, “What does AI need to thrive?” The answer is “good data.”

I believe that the extent to which companies can genuinely understand the importance of this extremely simple principle and implement it with unwavering dedication will determine their ability to establish a competitive advantage and achieve sustainable growth.

AI is a mirror of data

As I’m sure you’re all aware, AI is by no means a magic wand. It is an entity that learns based on the data it is given and makes inferences within that scope. In other words, AI’s output depends heavily on the quality of its input data; one could say that AI is a mirror of data.

• If you feed it inaccurate data, it will return inaccurate results (i.e., garbage in, garbage out)
• If you feed it biased data, it will make biased judgments
• Insufficient data yields only shallow insights and suggestions

In this way, AI is not smart but rather faithful to the data. Based on this premise, it becomes clear that the essence of AI utilization lies not in which tools to use, but in what kind of high-quality data to prepare and how to utilize it.

What is good data?

So, what exactly is good data?

It goes without saying that data is useless if it is merely abundant in quantity, but on the other hand, what specific qualities must good data possess?

Generally speaking, good data possesses at least the following elements.

• Accuracy: Data containing many errors or noise will skew conclusions, no matter how advanced the analysis. It is important to minimize sensor errors, input mistakes and duplicates.
• Completeness: Are any required fields missing, and are there too many missing values? For example, if customer data is missing information such as age, region or gender, it becomes difficult to perform meaningful analysis.
• Consistency: Is data with the same meaning mixed in different formats (e.g., date formats, units, variations in notation)? This is particularly important for system integration and long-term data.
• Timeliness: No matter how accurate it is, data that is too old may not be useful for decision-making. Whether real-time data is required or historical data is sufficient depends on the use case, but it is important that the data has the appropriate freshness for the purpose.
• Relevance: If there is a large amount of data unrelated to the analysis objective, it becomes noise and leads to incorrect judgments. It is necessary to clearly define what the data is used for and ensure the data is appropriate for that purpose.
• Reliability: The data’s source and collection method must be clear, ensuring reliability and reproducibility. Data with an unknown source or that is a black box cannot be verified later.

In summary, good data is data that is accurate, has few gaps, is consistent in meaning and notation, is collected at the appropriate time, is suitable for the purpose and comes from a reliable source.

Only when the quality of this good data is guaranteed can AI produce valuable outputs. Conversely, introducing AI with unorganized data will not yield the expected results. Many complaints, such as “We implemented AI but it’s unusable” or “The AI’s accuracy isn’t improving stem from data issues.”

Data does not organize itself naturally

The key point here is that good data does not arise naturally. On the contrary, if left unattended, data will inevitably deteriorate.

• Rules become inconsistent depending on who entered the data and when
• Multiple instances of data with the same meaning exist
• Outdated data is scattered and left unattended
• Data becomes siloed by department

These conditions are likely common in many companies.

Below is an overview of our company’s data management framework.

Akio Ueda

Broadly speaking, it consists of data governance — covering roles and structures, risk management and evaluation — and data management, which encompasses data utilization cycle management and data utilization support services. Within this framework, data utilization cycle management involves:

• Needs management: We clarify the purpose and needs by asking, “What is the data being used for?” and “For whom, and in what way, does this data create value?”
• Collection: We gather the necessary data based on the defined objectives. We design the process to determine what data is required (internal/external), the level of detail and frequency of collection, and how to ensure data quality.
• Processing: We enhance the quality and prepare the data for use. This includes cleansing (correcting errors and missing values), standardizing formats, deduplicating and integrating data, processing structured and unstructured data separately, and assigning business and operational meaning to the data.
• Storage: We ensure the data is available to the right people at the right time. This involves storing data in databases or data lakes, implementing security and access controls, and managing metadata (ensuring the data is clearly identifiable).
• Utilization: This is the most critical step. The purpose of data is not merely analysis but driving action. We generate value from the data through visualization (dashboards), analysis (statistical processing, BI, AutoML, AI) and integration into business operations (automation and decision support).
• Disposal: We properly dispose of data that is no longer needed. Simply holding data can itself pose risks, such as managing retention periods, complying with laws and governance requirements, and mitigating security risks. That is why the principle of not holding data that is not used is so important.

Data management is not a one-time effort; it is an ongoing initiative that requires continuous maintenance and improvement.

The CIO must embed data management as a system within the organization and continue to implement it until it becomes firmly established.

Data management is not just the IT department’s job

Another important point is that data management is not just the IT department’s job.

Data is fundamentally generated within day-to-day operations on the front lines. Therefore:

• Who determines the meaning and definition of data
• How should input rules be standardized?
• How do we ensure data quality?

are, in essence, operational issues, business issues and management issues.

The latest Digital Skills Standard ver. 2.0, published by the Ministry of Economy, Trade and Industry in April 2026, defines the following three roles within the data management category:

• Data steward: Based on business domain knowledge, this role is responsible for operations aimed at ensuring data quality, reliability and security, as well as for promoting the adoption and establishment of data management within business divisions and frontline organizations, and for fostering data utilization. In short, they are the data quality manager and data utilization promoter.
• Data engineer: This role involves understanding the current state of data and supporting the organization’s continuous data utilization through data preparation and preprocessing in processes such as collection, integration, processing and provision, as well as the design and implementation of data pipelines. In essence, they are the implementers and operators who drive data.
• Data architect: This role involves taking a bird’s-eye view of the data structure, flow and utilization methods across the entire organization and business. By designing and continuously reviewing data architecture that encompasses the entire data lifecycle in alignment with business strategy, they ensure the successful integration of company-wide data utilization and governance—essentially serving as the overall designer of data.

The CIO is not merely responsible for establishing data storage and analysis infrastructure; they are also tasked with appropriately assigning personnel to these three roles within the company and establishing cross-departmental, company-wide tools and rules to connect data with management, business operations and daily tasks.

Ultimately, the success of data utilization depends on organizational culture

On the other hand, no matter how much progress is made in staffing, infrastructure, tools and rulemaking, data will not be utilized unless there is an organizational culture that actively drives management, business and operations based on data.

• The purpose of data entry is not understood
• Data is optimized solely for the department’s own operations
• Decision-making based on data is not valued

In such a situation, no matter how well the systems are set up, they will become mere formalities.

In contrast, in organizations where data utilization is advanced:

• Discussions are based on data
• Formulate hypotheses and verify them with data
• And continuously improve based on data

These actions occur naturally.

In other words, the essence of data management ultimately lies in creating an organizational culture that assumes the effective use of data.

Data management cannot be achieved overnight. That is precisely why it is important to start small and build on your successes.

• Organize data for specific tasks and achieve results through the use of AI
• Rolling out successful practices
• Gradually Expand the Scope

By repeating this cycle, the importance of data will permeate the entire organization.

The role expected of a CIO in the AI era

In the AI era, the role expected of a CIO has changed significantly.

Traditionally:

• Ensuring the stable operation of systems
• And optimizing costs

However, moving forward:

• We will view data as an asset and maximize its value
• Developing the data infrastructure, tools and rules that underpin AI adoption, and advancing personnel allocation and development
• And fostering an organizational culture that embraces data utilization —roles that are more directly linked to business management

In other words, the CIO must evolve into the person responsible for creating value from data.

Data is the source of competitive advantage

In the coming era, the use of AI will be a given. What will set companies apart is not whether they use AI, but what data they possess.

Data is the accumulation of a company’s past strengths and the source of future value creation. And its quality is determined by daily operations and the nature of the organization.

• AI grows by being fed good data
• And companies grow through that AI

Taking this simple principle as our starting point, we must place data management at the core of our business strategy. Isn’t that the shortest route to sustainable growth in the AI era?

CIOs are called upon to lead the way in making this a reality.

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

OpenClaw’s announcement that it has become a nonprofit foundation is generating IT excitement because of the potential for governance and development consistency that the popular platform has thus far lacked. Still, some worry about the risks created by the move. 

“Our ambition is for OpenClaw to be the Switzerland of AI. Neutral ground where every model and every lab can plug into the technology and collaborate on standards in the era of agents,” OpenClaw said in a post. “That work is already underway in Foundation-convened councils on agent identity, agent profiles, evals, and enterprise deployment.”

The statement, co-authored by OpenClaw creator Peter Steinberger, pointed out, “the great open source projects of our time — Linux, Apache, Mozilla — endure because a neutral steward stands behind them. That is the role we are taking on to keep OpenClaw MIT licensed, open, and independent so that everyone building on it can trust it will be here for the long term.”

But it reassured users that the original OpenClaw leadership is still in charge.

“Peter built this thing and Peter keeps making the calls, especially the technical ones. Since joining OpenAI earlier this year, he has continued to steward OpenClaw as an open and independent project, and OpenAI has made a commitment to keep it that way,” the post said. “The foundation is here to serve: good governance, stable funding, and paying the people who keep the claws alive.”

However, some analysts and consultants were skeptical about how much true independence Steinberger would have, given his salaried role with OpenAI. 

Neutrality claim in question

“The Switzerland of AI neutrality claim collapses under its own announcement,” said Noah Kenney, principal consultant at Digital 520. “OpenAI runs a team [at OpenAI] called Claw Labs that Peter leads and OpenAI is a major donor to OpenClaw. The ‘neutral steward’s’ chief technical decision maker is employed by one of the competing labs it is supposed to be neutral with.” To OpenAI, he said, OpenClaw is closer to a tax-exempt nonprofit subsidiary than it is to a neutral ‘Switzerland of AI.’

He pointed out that, in addition, Microsoft is shipping the enterprise version of OpenClaw, and Nvidia is shipping the hardware bundle. “This is being called the Switzerland of AI, but Switzerland does not have its central bank run by France,” he observed.

Kenney said that what the new OpenClaw has actually built is “a shared dependency that several competitors fund, staff, and steer, wrapped in a nonprofit structure. Enterprise IT should understand that structure, because treating OpenClaw as neutral is a mistake,” adding that CIOs need to look at this development devoid of the emotional component. 

“There is a strategic irony here that CIOs should sit with,” Kenney said. “If OpenClaw succeeds at becoming the universal agent substrate, then every model plugs into the same identity layer, the same profiles, and the same deployment plumbing. The thing every vendor is racing to own becomes a commodity that nobody owns.” He pointed out that, in the short term, that is genuinely good news for buyers because it means less lock-in and more portability.

“But,” he said, “when the connective tissue is free and natural, the only labs that benefit are the ones with the best models and the deepest distribution. Commoditize the layer below you and you compete on the layer where you are already strongest. The foundation is not a charity. It is the biggest players agreeing to stop fighting over the plumbing so they can fight over the water, and the enterprise is the one paying the water bill either way.”

Good news, bad news

Jason Andersen, principal analyst at Moor Insights & Strategy, liked the potential consistency that could emerge from the structural change, given the complexity of agent development today. 

“We are seeing a lot of OpenClaw variants hit the market, such as those from Nvidia as well as competing products from cloud and SaaS vendors. A common base helps solidify the common parts,” Andersen noted. “That said, a common challenge is the sustainability of these open source foundations over time. In addition to releasing code, these foundations need funding to evolve and grow. And that funding needs to come from continued momentum to incentivize existing members to increase investment and recruit new members to join.”

Andersen stressed that IT buyers need to keep an eye on the roadmap for any OpenClaw variant they choose to deploy, “as that will directly impact the foundation, and the momentum of the foundation and common base. If the common base loses momentum, it can lead to forks, or just a loss of innovation. When that happens, members tend to back away, which puts customers in limbo.”

But not everyone sees the promised structure as entirely good for IT.

Ishraq Khan, CEO at coding productivity tool vendor Kodezi, said, “most CIOs do not want to bet their future entirely on a single model vendor. They want Claude for some workloads, GPT for others, open models for sensitive environments, and potentially internally fine-tuned systems for specific use cases. The problem is that every vendor currently brings its own identity system, tool interfaces, permissions model, and operational assumptions. That fragmentation does not scale.”

He said, “the risk if standards fail is straightforward: every vendor builds its own closed ecosystem, enterprises become locked into individual stacks, and security becomes dramatically harder. The opportunity if OpenClaw succeeds is equally significant: enterprises get portable agents, common identity standards, interoperable tooling, and a healthier competitive market around models rather than ecosystems.”

Will it remain a nonprofit?

However, said Justin Greis, CEO of consulting firm Acceligence, one of the key details that IT executives will want to keep in mind is that OpenAI also began as a nonprofit, but it was quickly seen as not adhering to nonprofit objectives. 

“OpenAI’s transition from a nonprofit research organization into a more complex structure highlighted the challenge of maintaining mission alignment while scaling technology, capital, partnerships, and commercial operations,” Greis said. “OpenClaw has the opportunity to address some of those governance questions earlier by establishing clear principles around neutrality, transparency, and decision-making before the ecosystem becomes even larger and more valuable.”

He noted, “we have seen this pattern before with technologies like Linux and Kubernetes. The strongest open ecosystems succeeded because they created trusted foundations that enterprises could build upon. The technology was important, but the governance model that underpinned it was equally critical.”

Risks are ‘squarely in IT’s lap’

Consultant Brian Levine, executive director of FormerGov, echoed Greis’ concerns. 

“CIOs shouldn’t assume that this nonprofit will always be a nonprofit, or confuse being a nonprofit with actually being neutral or unbiased,” he said. “The risks are squarely in IT’s lap: autonomous agents ‘with their own identity’ acting on a user’s behalf blow straight through traditional IAM assumptions. Issues, such as agent identity, auditability, secret handling. Identity boundaries have not yet been reliably solved. Until they are, enterprises should treat OpenClaw agents like privileged service accounts, not like a browser plugin.”

Independent cybersecurity and risk advisor Steven Eric Fisher pointed to another IT exposure that might come from this OpenClaw transition: Cost.

“OpenClaw currently has a very high token burn rate in usage, which presents a significant cost consideration for large-scale enterprise adoption,” he said. “The skills marketplace introduces a new supply chain threat that enterprises will need to manage. Threat management, and specifically handling external marketplace elements, can be highly challenging for open-source operations. Ultimately, at scale, enterprise adoption could become a difficult balancing act between managing high operational costs and securing an expanded security surface.”

What is cloud native? Cloud native defined

The term “cloud-native computing” encompasses the modern approach to building and running software applications that exploit the flexibility, scalability, and resilience of cloud computing. The phrase is a catch-all that encompasses not just the specific architecture choices and environments used to build applications for the public cloud, but also the software engineering techniques and philosophies used by cloud developers.

The Cloud Native Computing Foundation (CNCF) is an open source organization that hosts many important cloud-related projects and helps set the tone for the world of cloud development. The CNCF offers its own definition of cloud native:

Cloud native practices empower organizations to develop, build, and deploy workloads in computing environments (public, private, hybrid cloud) to meet their organizational needs at scale in a programmatic and repeatable manner. It is characterized by loosely coupled systems that interoperate in a manner that is secure, resilient, manageable, sustainable, and observable.

Cloud native technologies and architectures typically consist of some combination of containers, service meshes, multi-tenancy, microservices, immutable infrastructure, serverless, and declarative APIs — this list is not exhaustive.

This definition is a good start, but as cloud infrastructure becomes ubiquitous, the cloud native world is beginning to spread behind the core of this definition. We’ll explore that evolution as well, and look into the near future of cloud-native computing.

Cloud native architectural principles

Let’s start by exploring the pillars of cloud-native architecture. Many of these technologies and techniques were considered innovative and even revolutionary when they hit the market over the past few decades, but now have become widely accepted across the software development landscape.

Microservices. One of the huge cultural shifts that made cloud-native computing possible was the move from huge, monolithic applications to microservices: small, loosely coupled, and independently deployable components that work together to form a cloud-native application. These microservices can be scaled across cloud environments, though (as we’ll see in a moment) this makes systems more complex.

Containers and orchestration. In could-native architectures, individual microservices are executed inside containers — lightweight, portable virtual execution environments that can run on a variety of servers and cloud platforms. Containers insulate the developers from having to worry about the underlying machines on which their code will execute. That is, all they have to do is write to the container environment. 

Getting the containers to run properly and communicate with one another is where the complexity of cloud native computing starts to emerge. Initially, containers were created and managed by relatively simple platforms, the most common of which was Docker. But as cloud-native applications got more complex, container orchestration platforms that augmented Docker’s functionality emerged, such as Kubernetes, which allows you to deploy and manage multi-container applications at scale. Kubernetes is critical to cloud native computing as we know it — it’s worth noting that the CNCF was set up as a spinoff of the Linux Foundation on the same day that Kubernetes 1.0 was announced — and adhering to Kubernetes best practices is an important key to cloud native success. 

Open standards and APIs. The fact that containers and cloud platforms are largely defined by open standards and open source technologies is the secret sauce that makes all this modularity and orchestration possible, and standardized and documented APIs offer the means of communication between distributed components of a larger application. In theory, anyway, this standardization means that every component should be able to communicate with other components of an application without knowing about their inner workings, or about the inner workings of the various platform layers on which everything operates.

DevOps, agile methodologies, and infrastructure as code. Because cloud-native applications exist as a series of small, discrete units of functionality, cloud-native teams can build and update them using agile philosophies like DevOps, which promotes rapid, iterative CI/CD development. This enables teams to deliver business value more quickly and more reliably.

The virtualized nature of cloud environments also make them great candidates for infrastructure as code (IaC), a practice in which teams use tools like Terraform, Pulumi, and AWS CloudFormation, to manage infrastructure declaratively and version those declarations just like application code. IaC boosts automation, repeatability, and resilience across environments—all big advantages in the cloud world. IaC also goes hand-in-hand with the concept of immutable infrastructure—the idea that, once deployed, infastructure-level entities like virtual machines, containers, or network appliances don’t change, which makes them easier to manage and secure. IaC stores declarative configuration code in version control, which creates an audit log of any changes.

Foundry

How the cloud-native stack is expanding

As cloud-native development becomes the norm, the cloud-native ecosystem is expanding; the CNCF maintains a graphical representation of what it calls the  cloud native landscape that hammers home to expansive and bewildering variety of products, services, and open source projects that contribute to (and seek to profit from) to cloud-native computing. And there are a number of areas where new and developing tools are complicating the picture sketched out by the pillars we discussed above.   

An expanding Kubernetes ecosystem. Kubernetes is complex, and teams now rely on an entire ecosystem of projects to get the most out of it: Helm for packaging, ArgoCD for GitOps-style deployments, and Kustomize for configuration management. And just as Kubernetes augmented Docker for enterprise-scale deployments. Kubernetes itself has been augmented and expanded by service mesh offerings like Istio and Linkerd, which offer fine-grained traffic control and improved security

Observability needs. The complex and distributed world of cloud-native computing requires in-depth observability to ensure that developers and admins have a handle on what’s happening with their applications. Cloud-native observability uses distributed tracing and aggregated logs to provide deep insight into performance and reliability. Tools like Prometheus, Grafana, Jaeger, and OpenTelemetry support comprehensive, real-time observability across the stack.

Serverless computing.  Serverless computing, particularly in its function-as-a-service guise, offers to strip needed compute resources down to their bare minimum, with functions running on service provider clouds using exactly as much as they need and no more. Because these services can be exposed as endpoints via APIs, they are increasingly integrated into distributed applications, operating side-by-side with functionality provided by containerized microservices. Watch out, though: the big FaaS providers (Amazon, Microsoft, and Google) would love to lock you in to their ecosystems.  

FinOps. Cloud computing was initially billed as a way to cut costs — no need to pay for an in-house data center that you barely use — but in practice it replaces capex with opex, and sometimes you can run up truly shocking cloud service bills if you aren’t careful. Serverless computing is one way to cut down on those costs, but financial operations, or FinOps, is a more systematic discipline that aims to aligns engineering, finance, and product to optimize cloud spending. FinOps best practices make use of those observability tools to best determine what departments and applications are eating up resources.

How cloud-native architecture is adapting to AI workloads

Enterprises deploy larger AI models and make use of more and more real-time inference services. That’s putting demands on cloud-native systems and forcing them to adapt to remain scalable and reliable.

For instance, organizations are re-engineering cloud environments around GPU-accelerated clusters, low-latency networking, and predictable orchestration. These needs align with established cloud-native patterns: containers package AI services consistently, while Kubernetes provides resilient scheduling and horizontal scale for inference workloads that can spike without warning.

Kubernetes itself is changing to better support AI inference, adding hardware-aware scheduling for GPUs, model-specific autoscaling behavior, and deeper observability into inference pipelines. These enhancements make Kubernetes a more natural platform for serving generative AI workloads.

AI’s resource demands are amplifying traditional cloud-native challenges. Observability becomes more complex as inference paths span GPUs, CPUs, vector databases, and distributed storage. FinOps teams contend with cost volatility from training and inference bursts. And security teams must track new risks around model provenance, data access, and supply-chain integrity.

Application frameworks for building distributed cloud-native apps

Microsoft’s Aspire is one of the most visible examples of a shift towards application frameworks to simplify how teams build distributed systems. Opinionated frameworks like Aspire provide structure, observability, and integration out of the box so developer don’t need to stitch together containers, microservices, and orchestration tooling by hand.

Aspire in particular is a prescriptive framework for cloud-native applications, bundling containerized services, environment configuration, health checks, and observability into a unified development model. Aspire provides defaults for service-to-service communication, configuration, and deployment, along with a built-in dashboard for visibility across distributed components.

While Aspire was originally aligned with Microsoft’s .NET platform,Redmond now sees it as having a  polyglot future. This positions Aspire as part of a broader trend: frameworks that help teams build cloud-native, service-oriented systems without being locked into a single language ecosystem. Several other frameworks are gaining traction: Dapr provides a portable runtime that abstracts many of the plumbing tasks in cloud-native distributed applications, and Orleans offers an actor-model-based framework for large-scale systems in the .NET world, and Akka gives JVM teams a mature, reactive toolkit for elastic, resilient services.

Frameworks and tools in the expanding cloud-native ecosystem

While frameworks like Aspire simplify how developers compose and structure distributed applications, most cloud-native systems still depend on a broader ecosystem of platforms and operational tooling. This deeper layer is where much of the complexity—and innovation—of cloud-native computing lives, particularly as Kubernetes continues to serve as the industry’s control plane for modern infrastructure.

Kubernetes provides the core abstractions for deploying and orchestrating containerized workloads at scale. Managed distributions such as Google Kubernetes Engine (GKE), Amazon EKS, Azure AKS, and Red Hat OpenShift build on these primitives with security, lifecycle automation, and enterprise support. Platform vendors are increasingly automating cluster operations—upgrades, scaling, remediation—to reduce the operational burden on engineering teams.

Surrounding Kubernetes is a rapidly expanding ecosystem of complementary frameworks and tools. Service meshes like Istio and Linkerd provide fine-grained traffic management, policy enforcement, and mTLS-based security across microservices. GitOps platforms such as Argo CD and Flux bring declarative, version-controlled deployments to cloud-native environments. Meanwhile, projects like Crossplane turn Kubernetes into a universal control plane for cloud infrastructure, letting teams provision databases, queues, and storage through familiar Kubernetes APIs. These tools illustrate how cloud-native development now spans multiple layers: developer-focused application frameworks like Aspire at the top, and a powerful, evolving Kubernetes ecosystem underneath that keeps modern distributed applications running.

Advantages and challenges for cloud-native development

Cloud native has become so ubiquitous that its advantages are almost taken for granted at this point, but it’s worth reflecting on the beneficial shift the cloud native paradigm represents. Huge, monolithic codebases that saw updates rolled out once every couple of years have been replaced by microservice-based applications that can be improved continuously. Cloud-based deployments, when managed correctly, make better use of compute resources and allow companies to offer their products as SaaS or PaaS services. 

But cloud-native deployments come with a number of challenges, too:

• Complexity and operational overhead: You’ll have noticed by now that many of the cloud-native tools we’ve discussed, like service meshes and observability tools, are needed to deal with the complexity of cloud-native applications and environments. Individual microservices are deceptively simple, but coordinating them all in a distributed environment is a big lift.
• Security: More services executing on more machines, communicating by open APIs, all adds up to a bigger attack surface for hackers. Containers and APIs each have their own special security needs, and a policy engine can be an important tool for imposing a security baseline on a sprawling cloud-native app. DevSecOps, which adds security to DevOps, has become an important cloud-native development practice to try to close these gaps.
• Vendor lock-in: This may come as a surprise, since cloud-native is based on open standards and open source. But there are differences in how the big cloud and serverless providers works, and once you’ve written code with one provider in mind, it can be hard to migrate elsewhere.
• A persistent skills gap: Cloud-native computing and development may have years under its belt at this point, but the number of developers who are truly skilled in this arena is a smaller portion of the workforce than you’d think. Companies face difficult choices in bridging this skills gap, whether that’s bidding up salaries, working to upskill current workers, or allowing remote work so they can cast a wide net. 

Cloud native in the real world

Cloud native computing is often associated with giants like Netflix, Spotify, Uber, and AirBNB, where many of its technologies were pioneered in the early ’10s. But the CNCF’s Case Studies page provides an in-depth look at how cloud native technologies are helping companies. Examples include the following:

• A UK-based payment technology company that can switch between data centers and clouds with zero downtime
• A software company whose product collects and analyzes data from IoT devices — and can scale up as the number of gadgets grows
• A Czech web service company that managed to improve performance while reducing costs by migrating to the cloud

Cloud-native infrastructure’s capability to quickly scale up to large workloads also make it an attractive platform for developing AI/ML applications: another one of those CNCF case studies looks at how IBM uses Kubernetes to train its Watsonx assistant. The big three providers are putting a lot of effort into pitching their platforms as the place for you to develop your own generative AI tools, with offerings like Azure AI Foundry,Google Firebase Studio, and Amazon Bedrock. It seems clear that cloud native technology is ready for what comes next.

Learn more about related cloud-native technologies:

• Platform-as-a-service (PaaS) explained
• What is cloud computing
• Multicloud explained
• Agile methodology explained
• Agile development best practices
• Devops explained
• Devops best practices
• Microservices explained
• Microservices tutorial
• Docker and Linux containers explained
• Kubernetes tutorial
• CI/CD (continuous integration and continuous delivery) explained
• CI/CD best practices

Cloud computing continues to be the platform of choice for large applications and a driver of innovation in enterprise technology. Gartner forecasts public cloud spending alone to the public cloud services market alone will reach $1.42 trillion in current U.S. dollars, driven by AI workloads and enterprise modernization.

Driving this growth are the rise of AI and machine learning on the cloud, adoption of edge computing, the maturation of serverless computing, the emergence of multicloud strategies, improved security and privacy, and more sustainable cloud practices.

What is cloud computing?

While often used broadly, the term cloud computing is defined as an abstraction of compute, storage, and network infrastructure assembled as a platform on which applications and systems are deployed quickly and scaled on the fly.

Most cloud customers consume public cloud computing services over the internet, which are hosted in large, remote data centers maintained by cloud providers. The most common type of cloud computing, SaaS (software as service), delivers prebuilt applications to the browsers of customers who pay per seat or by usage, exemplified by such popular apps as Salesforce, Google Docs, or Microsoft Teams.

5 top trends in cloud computing

1. Agentic cloud ecosystems: The shift from AI as a tool to AI as an autonomous operator within cloud environments.
2. Sovereign and localized clouds: Meeting strict national data residency and digital sovereignty laws.
3. Specialized AI hardware access: Navigating the GPU capacity crunch through reserved instances and boutique AI clouds.
4. Integrated greenOps: Merging cost optimization with mandatory carbon-footprint reporting.
5. Industry-specific walled gardens: The maturation of vertical clouds into highly regulated, precompliant environments for finance and healthcare.

Next in line is IaaS (infrastructure as a service), which offers vast, virtualized compute, storage, and network infrastructure upon which customers build their own applications, often with the aid of providers’ API-accessible services.

When people refer to the “the cloud” today, they most often mean the big IaaS providers: AWS (Amazon Web Services), Google Cloud Platform, or Microsoft Azure. All three have become ecosystems of services that go way beyond infrastructure and include developer tools, serverless computing, machine learning services and APIs, data warehouses, and thousands of other services. With both SaaS and IaaS, a key benefit is agility. Customers gain new capabilities almost instantly without the capital investment in hardware or software on-premises — and they can instantly scale the cloud resources they consume up or down as needed.

According to Foundry’s Cloud Computing Study, 2025, enterprises are moving to the cloud to improve security and/or governance, increase scalability​, accelerate adoption of artificial intelligence and machine learning and other new technologies, replace on-premises legacy technology, ​improve employee productivity, and ensure disaster recovery and business continuity.

Hyperscalers now dominate cloud services

The largest cloud service providers are often described as hyperscalers, due to their capability to provide large-scale data centers across the globe. Hyperscalers typically offer a wide range of cloud services, including IaaS, PaaS, SaaS, and more.

As mentioned above, notable hyperscalers include Amazon Web Services (AWS), Google Cloud Platform, and Microsoft Azure. They offer the following capabilities.

• Scalability: Hyperscalers can handle massive workloads and scale resources up or down quickly.
• Cost-effectiveness: Hyperscalers often offer competitive pricing and economies of scale.
• Global reach: Hyperscalers operate data centers around the world, providing low-latency access to customers in different regions.
• Innovation: Hyperscalers are at the forefront of cloud innovation, offering new services and features.

Challenges of working with hyperscalers

• Vendor lock-in: Relying heavily on a single hyperscaler can create vendor lock-in, making it difficult to switch to another provider and charging large egress fees if you do move.
• Complexity: Hyperscalers offer a vast array of services, which can be overwhelming for some customers.
• Security concerns: Because hyperscalers handle sensitive data, security is a major concern.

AI, Agents, and the Sovereign Cloud

The AI-enabled enterprise has moved beyond simple chatbots. The focus has shifted to agentic workflows — autonomous systems that reside in the cloud and possess the authority to execute business processes, manage cloud spend, and self-patch security vulnerabilities without human intervention.

The shift to agentic infrastructure

Cloud providers are no longer just selling compute. They are selling inference-as-a-service. Modern cloud budgets are now dominated by the high cost of specialized GPU clusters (such as Nvidia’s Blackwell architecture). This has led to the rise of boutique AI clouds that compete with hyperscalers by offering bare-metal access to the latest silicon specifically for model training and fine-tuning.

Data sovereignty and private AI

A major shift in late 2025 is the move away from public AI models for sensitive data. Organizations are increasingly using retrieval-augmented generation (RAG) within walled garden environments. This ensures that a company’s proprietary data never leaves their specific cloud instance to train a provider’s base model.

Furthermore, sovereign AI has become a requirement for global operations. Governments now demand that the AI models processing their citizens’ data be hosted on infrastructure that is owned, operated, and governed within their own borders.

The challenges of ghost AI

Just as shadow IT plagued the 2010s, ghost AI—unauthorized AI agents running on corporate cloud accounts — has become a primary security risk. Managing these autonomous entities requires a new layer of AI governance, where the cloud provider automatically audits the intent and permissions of every running agent to prevent runaway costs or data leaks.

Cloud computing definitions

In 2011, NIST posted a PDF that divided cloud computing into three “service models” — SaaS, IaaS, and PaaS (platform as a service) — the latter being a controlled environment within which customers develop and run applications. These three categories have largely stood the test of time, although most PaaS solutions now are made available as services within IaaS ecosystems rather than as dedicated PaaS clouds.

Two evolutionary trends stand out since NIST’s threefold definition. One is the long and growing list of subcategories within SaaS, IaaS, and PaaS, some of which blur the lines between categories. The other is the explosion of API-accessible services available in the cloud, particularly within IaaS ecosystems. The cloud has become a crucible of innovation where many emerging technologies appear first as services, a big attraction for business customers who understand the potential competitive advantages of early adoption.

SaaS (software as a service) definition

This type of cloud computing delivers applications over the internet, typically with a browser-based user interface. Today, most software companies offer their wares via SaaS — if not exclusively, then at least as an option.

The most popular SaaS applications for business are Google’s G Suite and Microsoft’s Office 365. Most enterprise applications, including giant ERP suites from Oracle and SAP, come in both SaaS and on-premises versions. SaaS applications typically offer extensive configuration options as well as development environments that enable customers to code their own modifications and additions. They also enable data integration with on-prem applications.

IaaS (infrastructure as a service) definition

At a basic level, IaaS cloud providers offer virtualized compute, storage, and networking over the internet on a pay-per-use basis. Think of it as a data center maintained by someone else, remotely, but with a software layer that virtualizes all those resources and automates customers’ ability to allocate them with little trouble.

But that’s just the basics. The full array of services offered by the major public IaaS providers is staggering: highly scalable databases, virtual private networks, big data analytics, AI and machine learning services, application platforms, developer tools, devops tools, and so on. Amazon Web Services was the first IaaS provider and remains the leader, followed by Microsoft Azure, Google Cloud Platform, IBM Cloud, and Oracle Cloud.

PaaS (platform as a service) definition

PaaS provides sets of services and workflows that specifically target developers, who can use shared tools, processes, and APIs to accelerate the development, testing, and deployment of applications. Salesforce’s Heroku and Salesforce Platform (formerly Force.com) are popular public cloud PaaS offerings; Cloud Foundry and Red Hat’s OpenShift can be deployed on premises or accessed through the major public clouds. For enterprises, PaaS can ensure that developers have ready access to resources, follow certain processes, and use only a specific array of services, while operators maintain the underlying infrastructure.

FaaS (function as a service) definition

FaaS, the original and most basic version of serverless computing, adds another layer of abstraction to PaaS, so that developers are insulated from everything in the stack below their code. Instead of futzing with virtual servers, containers, and application runtimes, developers upload narrowly functional blocks of code, and set them to be triggered by a certain event (such as a form submission or uploaded file). All of the major clouds offer FaaS on top of IaaS: AWS Lambda, Azure Functions, Google Cloud Functions, and IBM Cloud Functions. A special benefit of FaaS applications is that they consume no IaaS resources until an event occurs, reducing pay-per-use fees.

Private cloud definition

A private cloud downsizes the technologies used to run IaaS public clouds into software that can be deployed and operated in a customer’s data center. As with a public cloud, internal customers can provision their own virtual resources to build, test, and run applications, with metering to charge back departments for resource consumption. For administrators, the private cloud amounts to the ultimate in data center automation, minimizing manual provisioning and management.

VMware remains a force in the private cloud software market, but the acquisition by Broadcom has created confusion and raised concerns among some customers about potential changes in pricing, licensing, and support. This could lead some organizations to explore alternative solutions.

OpenStack continues to be a popular open-source choice for building private clouds. It offers a flexible and customizable platform that can be tailored to specific needs. However, OpenStack can be complex to deploy and manage, and it may require significant expertise to maintain.

Kubernetes, a container orchestration platform that has gained significant traction in recent years, is often used in conjunction with other technologies like OpenStack to build cloud-native applications. Red Hat OpenShift is a comprehensive cloud platform based on Kubernetes that provides a managed experience for deploying and managing container-based, applications.

Many cloud providers offer their own cloud-native platforms and tools, such as AWS Outposts, Azure Stack, and Google Cloud Anthos.

Common factors to consider when evaluating private cloud platforms include the following:

1. Pricing: The initial cost of deployment and ongoing maintenance costs.
2. Complexity: The level of technical expertise needed to manage the platform.
3. Flexibility: The ability to customize the platform to meet specific needs.
4. Vendor lock-in: The degree to which the organization is tied to a particular vendor.
5. Security: The security features and capabilities of the platform.
6. Scalability: The capability to expand the platform to meet future needs.

Hybrid cloud definition

A hybrid cloud is the integration of a private cloud with a public cloud. At its most developed, the hybrid cloud involves creating parallel environments in which applications can move easily between private and public clouds. In other instances, databases may stay in the customer data center and integrate with public cloud applications — or virtualized data center workloads may be replicated to the cloud during times of peak demand. The types of integrations between private and public clouds vary widely, but they must be extensive to earn a hybrid cloud designation.

Public APIs (application programming interfaces) definition

Just as SaaS delivers applications to users over the internet, public APIs offer developers application functionality that can be accessed programmatically. For example, in building web applications, developers often tap into the Google Maps API to provide driving directions; to integrate with social media, developers may call upon APIs maintained by Twitter, Facebook, or LinkedIn. Twilio has built a successful business delivering telephony and messaging services via public APIs. Ultimately, any business can provision its own public APIs to enable customers to consume data or access application functionality.

iPaaS (integration platform as a service) definition

Data integration is a key issue for any sizeable company, but particularly for those that adopt SaaS at scale. iPaaS providers typically offer prebuilt connectors for sharing data among popular SaaS applications and on-premises enterprise applications, though providers may focus more or less on business-to-business and e-commerce integrations, cloud integrations, or traditional SOA-style integrations. iPaaS offerings in the cloud from such providers as Dell Boomi, Informatica, MuleSoft, and SnapLogic also let users implement data mapping, transformations, and workflows as part of the integration-building process.

IDaaS (identity as a service) definition

The most difficult security issue related to cloud computing is managing user identity and its associated rights and permissions across data centers and pubic cloud sites. IDaaS providers maintain cloud-based user profiles that authenticate users and enable access to resources or applications based on security policies, user groups, and individual privileges. The ability to integrate with various directory services (Active Directory, LDAP, etc.) and provide single sign-on across business-oriented SaaS applications is essential.

Leaders in IDaaS include Microsoft, IBM, Google, Oracle, Okta, Capgemini, Okta, Junio Corporation, OneLogin, and JumpCloud.  

Collaboration platforms

Collaboration solutions such as Slack and Microsoft Teams have become vital messaging platforms that enable groups to communicate and work together effectively. Basically, these solutions are relatively simple SaaS applications that support chat-style messaging along with file sharing and audio or video communication. Most offer APIs to facilitate integrations with other systems and enable third-party developers to create and share add-ins that augment functionality.

Vertical clouds

Key providers in such industries as financial services, healthcare, retail, life sciences, and manufacturing provide PaaS clouds to enable customers to build vertical applications that tap into industry-specific, API-accessible services. Vertical clouds can dramatically reduce the time to market for vertical applications and accelerate domain-specific B2B integrations. Most vertical clouds are built with the intent of nurturing partner ecosystems.

Other cloud computing considerations

The most widely accepted definition of cloud computing means that you run your workloads on someone else’s servers, but this is not the same as outsourcing. Virtual cloud resources and even SaaS applications must be configured and maintained by the customer. Consider these factors when planning a cloud initiative.

Cloud computing security considerations

Objections to the public cloud generally begin with cloud security, although the major public clouds have proven themselves much less susceptible to attack than the average enterprise data center.

Of greater concern is the integration of security policy and identity management between customers and public cloud providers. In addition, government regulation may forbid customers from allowing sensitive data off-premises. Other concerns include the risk of outages and the long-term operational costs of public cloud services.

Multicloud management considerations

To enhance their operational efficiency, reduce costs, and improve security, many companies are increasingly turning to multicloud strategies. By distributing workloads across multiple cloud providers, organizations can avoid vendor lock-in, optimize costs, and leverage the best-of-breed services offered by different providers.

This multicloud approach also improves performance and reliability by minimizing downtime and optimizing latency. Additionally, multicloud strategies strengthen security by diversifying the attack surface and facilitating compliance with industry regulations. Finally, by replicating critical workloads across multiple regions and providers, companies can establish robust disaster recovery and business continuity plans, ensuring minimal disruption in the event of catastrophic failures.

The bar to qualify as a multicloud adopter is low: A customer just needs to use more than one public cloud service. However, depending on the number and variety of cloud services involved, managing multiple clouds can become complex from both a cost optimization and a technology perspective.

In some cases, customers subscribe to multiple cloud services simply to avoid dependence on a single provider. A more sophisticated approach is to select public clouds based on the unique services they offer and, in some cases, integrate them. For example, developers might want to use Google’s Vertex AI Studio on Google Cloud Platform to build AI-driven applications, but prefer Jenkins hosted on the CloudBees platform for continuous integration.

To control costs and reduce management overhead, some customers opt for cloud management platforms (CMPs) and/or cloud service brokers (CSBs), which let you manage multiple clouds as if they were one cloud. The problem is that these solutions tend to limit customers to such common-denominator services as storage and compute, ignoring the panoply of services that make each cloud unique.

Edge computing considerations

You often see edge computing incorrectly described as an alternative to cloud computing. Edge computing is about moving compute to local devices in a highly distributed system, typically as a layer around a cloud computing core. There is typically a cloud involved to orchestrate all of the devices and take in their data, then analyze it or otherwise act on it. 

To the cloud and back – why repatriation is real

While public cloud offers scalability and flexibility, some enterprises are opting to return to on-premises infrastructure due to rising costs, data security concerns, performance issues, vendor lock-in, and regulatory compliance challenges. While the public cloud offers scalability and flexibility, on-premises infrastructure provides greater control, customization, and potential cost savings in certain scenarios leading some technology decision-makers to consider repatriation. However, a hybrid cloud approach, combining public and private cloud, often offers the best balance of benefits.

More specific reasons to repatriate including the following:

• Unanticipated costs, such as data transfer fees, storage charges, and egress fees, can quickly escalate, especially for large-scale cloud deployments.  
• Inaccurate resource provisioning or underutilization can lead to higher-than-expected costs.
• Stricter data privacy regulations require organizations to store and process data within specific geographic boundaries.  
• For highly sensitive data, companies may prefer to maintain greater control over security measures and access permissions. 
• On-premises infrastructure can offer lower latency, particularly for applications requiring real-time processing or high-performance computing.  
• Overreliance on a single cloud provider can limit flexibility and increase costs. Repatriation allows organizations to diversify their infrastructure and reduce vendor dependency.  
• Industries with stringent compliance requirements may find it easier to meet standards with on-premises infrastructure.  
• On-premises environments offer greater control over hardware, software, and network configurations, allowing for customized solutions.  

Benefits of cloud computing

The cloud’s main appeal is to reduce the time to market of applications that need to scale dynamically. Increasingly, however, developers are drawn to the cloud by the abundance of advanced new services that can be incorporated into applications, from machine learning to internet of things (IoT) connectivity.

Although businesses sometimes migrate legacy applications to the cloud to reduce data center resource requirements, the real benefits accrue to new applications that take advantage of cloud services and “cloud native” attributes. The latter include microservices architecture, Linux containers to enhance application portability, and container management solutions such as Kubernetes that orchestrate container-based services. Cloud-native approaches and solutions can be part of either public or private clouds and help enable highly efficient devops workflows.

Cloud computing, be it public or private or hybrid or multicloud, has become the platform of choice for large applications, particularly customer-facing ones that need to change frequently or scale dynamically. More significantly, the major public clouds now lead the way in enterprise technology development, debuting new advances before they appear anywhere else. Workload by workload, enterprises are opting for the cloud, where an endless parade of exciting new technologies invite innovative use.

SaaS has its roots in the ASP (application service provider) trend of the early 2000s, when providers would run applications for business customers in the provider’s data center, with dedicated instances for each customer. The ASP model was a spectacular failure because it quickly became impossible for providers to maintain so many separate instances, particularly as customers demanded customizations and updates.

Salesforce is widely considered the first company to launch a highly successful SaaS application using multitenancy — a defining characteristic of the SaaS model. Rather than each Salesforce customer getting its own application instance, customers who subscribe to the company’s salesforce automation software share a single, large, dynamically scaled instance of an application (like tenants sharing an apartment building), while storing their data in separate, secure repositories on the SaaS provider’s servers. Fixes can be rolled out behind the scenes with zero downtime and customers can receive UX or functionality improvements as they become available.

For several decades now, the most innovative software has always emerged from the world of open source software. It’s no different with machine learning and large language models. If anything, the open source ecosystem has grown richer and more complex, because now there are open source models to complement the open source code.

For this article, we’ve pulled together some of the most intriguing and useful projects for AI and machine learning. Many of these are foundation projects, nurturing their own niche ecology of open source plugins and extensions. Once you’ve started with the basic project, you can keep adding more parts.

Most of these projects offer demonstration code, so you can start up a running version that already tackles a basic task. Additionally, the companies that build and maintain these projects often sell a service alongside them. In some cases, they’ll deploy the code for you and save you the hassle of keeping it running. In others, they’ll sell custom add-ons and modifications. The code itself is still open, so there’s no vendor lock in. The services simply make it easier to adopt the code by paying someone to help.

Here are 16 open source projects that developers can use to unlock the potential in machine learning and large language models of any size—from small to large, and even extra large.

Agent Skills

AI coding agents are often used to tackle standard tasks like writing React components or reviewing parts of the user interface. If you are writing a coding agent, it makes sense to use vetted solutions that are focused on the task at hand. Agent Skills are pre-coded tools that your AI can deploy as needed. The result is a focused set of vetted operations capable of producing refined, useful code that stays within standard guidelines. License: MIT.

Awesome LLM Apps

If you are looking for good examples of agentic coding, see the Awesome LLM Apps collection. Currently, the project hosts several dozen applications that leverage some combination of RAG databases and LLMs. Some are simple, like a meme generator, while others handle deeper research like the Journalist agent. The most complex examples deploy multi-agent teams to converge upon an answer. Every application comes with working examples for experimentation, so you can learn from what’s been successful in the past. Altogether, the apps in this collection are great inspiration for your own projects. License: Apache 2.0.

Bifrost

If your application requires access to an LLM service, and you don’t have a particular one in mind, check out Bifrost. A fast, unified gateway to more than 15 LLM providers, this OpenAI-compatible API quickly abstracts away the differences between models, including all the major ones. It includes essential features like governance, caching, budget management, load balancing, and it has guardrails to catch problems before they are sent out to service providers, who will just bill you for the time. With dozens of great LLM providers constantly announcing new and better models, why limit yourself? License: Apache 2.0.

Claude Code

If the popularity of AI coding assistants tells us anything, it’s that all developers—and not just the ones building AI apps—appreciate a little help writing and reviewing their code. Claude Code is that pair programmer. Trained on all the major programming languages, Claude Code can help you write code that is better, faster, and cleaner. It digests a codebase and then starts doing your bidding, while also making useful suggestions. Natural language commands plus some vague hand waving are all the Anthropic LLM needs to refactor, document, or even add new features to your existing code. License: Anthropic’s Commercial TOS.

Clawdbot

Many of the tools in this list help developers create code for other people. Clawdbot is the AI assistant for you, the person writing the code. It integrates with your desktop to control built-in tools like the camera and large applications like the browser. A multi-channel inbox accepts your commands through more than a dozen different communication channels including WhatsApp, Telegram, Slack, and Discord. A cron job adds timing. It’s the ultimate assistant for you, the ruler of your data. If AI exists to make our lives easier, why not start by organizing the applications on your desktop? License: MIT.

Dify

For projects that require more than just one call to an LLM, Dify could be the solution you’ve been looking for. Essentially a development environment for building complex agentic workflows, Dify stitches together LLMs, RAG databases, and other sources. It then monitors how they perform under different prompts and parameters and puts it all together in a handy dashboard, so you can iterate on the results. Developing agentic AI requires rapid experimentation, and Dify provides the environment for those experiments. License: Modified version of Apache 2.0 to exclude some commercial uses.

Eigent

The best way to explore the power and limitations of an agentic workflow is to deploy it yourself on your own machine, where it can solve your own problems. Eigent delivers a workforce of specialized agents for handling tasks like writing code, searching the web, and creating documents. You just wave your hands and issue instructions, and Eigent’s LLMs do their best to follow through. Many startups brag about eating their own dogfood. Eigent puts that concept on a platter, making it easy for AI developers to experience directly the abilities and failings of the LLMs they’re building. License: Apache 2.0.

Headroom

Programmers often think like packrats. If the data is good, why not pack in some more? This is a challenge for code that uses an LLM because these services charge by the token, and they also have a limited context window. Headroom tackles this issue with agile compression algorithms that trim away the excess, especially the extra labels and punctuation found in common formats like JSON. A big part of designing working AI applications is cost engineering, and saving tokens means saving money. License: Apache 2.0.

Hugging Face Transformers

When it comes to starting up a brand-new machine learning project, Hugging Face Transformers is one of the best foundations available. Transformers offers a standard format for defining how the model interacts with the world, which makes it easy to drop a new model into your working infrastructure for training or deployment. This means your model will interact nicely with all the already available tools and infrastructure, whether for text, vision, audio, video, or all of the above. Fitting into a standard paradigm makes it much easier to leverage your existing tools while focusing on the cutting edge of your research. License: Apache 2.0.

LangChain

For agentic AI solutions that require endless iteration, LangChain is a way to organize the effort. It harnesses the work of a large collection of models and makes it easier for humans to inspect and curate the answers. When the task requires deeper thinking and planning, LangChain makes it easy to work with agents that can leverage multiple models to converge upon a solution. LangChain’s architecture includes a framework (LangGraph) for organizing easily customizable workflows with long-term memory, and a tool (LangSmith) for evaluating and improving performance. Its Deep Agents library provides teams of sub-agents, which organize problems into subsets then plan and work toward solutions. It is a proven, flexible test bed for agentic experimentation and production deployment. License: MIT.

LlamaIndex

Many of the early applications for LLMs are sorting through large collections of semi-structured data and providing users with useful answers to their questions. One of the fastest ways to customize a standard LLM with private data is to use LlamaIndex to ingest and index the data. This off-the-shelf tool provides data connectors that you can use to unpack and organize a large collection of documents, tables, and other data, often with just a few lines of code. The layers underneath can be tweaked or extended as the job requires, and LlamaIndex works with many of the data formats common in enterprises. License: MIT.

Ollama

For anyone experimenting with LLMs on their laptop, Ollama is one of the simplest ways to download one or more of them and get started. Once it’s installed, your command line becomes a small version of the classic ChatGPT interface, but with the ability to pull a huge collection of models from a growing library of open source options. Just enter: ollama run and the model is ready to go. Some developers are using it as a back-end server for LLM results. The tool provides a stable, trustworthy interface to LLMs, something that once required quite a bit of engineering and fussing. The server simplifies all this work so you can tackle higher level chores with many of the most popular open source LLMs at your fingertips. License: MIT.

OpenWebUI

One of the fastest ways to put up a website with a chat interface and a dedicated RAG database is to spin up an instance of OpenWebUI. This project knits together a feature-rich front end with an open back end, so that starting up a customizable chat interface only requires pulling a few Docker containers. The project, though, is just a beginning, because it offers the opportunity to add plugins and extensions to enhance the data at each stage. Practically every part of the chain from prompt to answer can be tweaked, replaced, or improved. While some teams might be happy to set it up and be done, the advantages come from adding your own code. The project isn’t just open source itself, but a constellation of hundreds of little bits of contributed code and ancillary projects that can be very helpful. Being able to customize the pipeline and leverage the MCP protocol supports the delivery of precision solutions. License: Modified BSD designed to restrict removing OpenWebUI branding without an enterprise license.

Sim

The drag-and-drop canvas for Sim is meant to make it easier to experiment with agentic workflows. The tool handles the details of interacting with the various LLMs and vector databases; you just decide how to fit them together. Interfaces like Sim make the agentic experience accessible to everyone on your team, even those who don’t know how to write code. License: Apache 2.0.

Sloth

One of the most straightforward ways to leverage the power of foundational LLMs is to start with an open source model and fine-tune it with your own data. Unsloth does this, often faster than other solutions do. Most major open source models can be transformed with reinforcement learning. Unsloth is designed to work with most of the standard precisions and some of the largest context windows. The best answers won’t always come directly from RAG databases. Sometimes, adjusting the models is the best solution. License: Apache 2.0.

vLLM

One of the best ways to turn an LLM into a useful service for the rest of your code is to start it up with vLLM. The tool loads many of the available open source models from repositories like Hugging Face and then orchestrates the data flows so they keep running. That means batching the incoming prompts and managing the pipelines so the model will be a continual source of fast answers. It supports not just the CUDA architecture but also AMD CPUs and GPUs, Intel CPUs and GPUs, PowerPC CPUs, Arm CPUs, and TPUs. It’s one thing to experiment with lots of models on a laptop. It’s something else entirely to deploy the model in a production environment. vLLM handles many of the endless chores that deliver better performance. License: Apache-2.0.

Jurassic Park wasn’t really about dinosaurs.

It was about arrogant people building systems they believed were controllable.

“Life finds a way” is probably the most famous line from the entire franchise. Ian Malcolm’s warning that no matter how sophisticated the technology becomes, no matter how expensive the fences are, and no matter how confident the operators feel, nature eventually escapes containment.

And in every movie, it does.

The dinosaurs always get out. The systems fail. Eventually, the humans lose control.

What makes Jurassic Park fascinating is that despite advanced monitoring, complex containment systems and sophisticated operational controls, the outcome never really changes. At its core, the story is about people mistaking visibility for control.

Cybersecurity has the same problem.

For years, security teams have operated under the assumption that with enough tooling, governance, process, maturity and spend, we can build environments that are effectively secure. Maybe not perfect, but secure enough that compromise becomes rare and manageable.

But attackers find a way.

Given enough time, skill or motivation, they eventually identify the weakness nobody considered. The overlooked privilege. The dependency nobody mapped. The misconfiguration hiding behind layers of dashboards, process, and compliance reporting.

We are already seeing this play out. Nation-state attacks are becoming increasingly sophisticated, while AI-driven exploit discovery is beginning to compress vulnerability research from weeks into minutes.

The raptors are learning faster now.

Mistaking visibility for control

That does not mean prevention no longer matters. The fences in Jurassic Park still slowed the dinosaurs down. They created friction. They reduced exposure. Modern security controls do the same thing.

But the failure in Jurassic Park was never simply that the fences broke.

It was that the entire system assumed the fences represented certainty.

Cybersecurity often makes the same mistake.

The industry has become incredibly good at demonstrating preparedness in controlled environments. Dashboards. Compliance reports. Tabletop exercises. RTO metrics. Recovery attestations.

Jurassic Park had dashboards too.

The problem is that visibility is often mistaken for survivability. Organizations can prove they monitored the environment, documented the process, and ran the exercise, while still having very little confidence that the business could continue operating during a genuine systemic failure.

Most organizations still operate with an implicit belief that compromise is exceptional rather than inevitable. Disaster recovery plans, business continuity workshops, and annual tabletop exercises are treated as evidence of resilience. In reality, many of them are carefully controlled simulations of a world that no longer exists.

Traditional disaster recovery was designed for an era where infrastructure changed slowly, applications were relatively static, and dependencies were limited enough that recovery assumptions could remain valid for months or even years.

That world is gone. AI killed it.

Environments now evolve constantly. Cloud infrastructure changes daily. AI-assisted development accelerates release cycles. Applications rely on sprawling third-party ecosystems. APIs connect systems in ways many organizations do not fully understand. Entire workloads appear and disappear dynamically.

The environment you tested last quarter may no longer exist today.

And yet many resilience programs still operate as if annual or quarterly testing provides meaningful confidence.

Most companies do not really test resilience.

They test optimism.

The backup fallacy

And nowhere is this overconfidence more obvious than backups.

Somewhere along the way, organizations confused “having backups” with “being resilient.” Those are not remotely the same thing.

A backup simply proves you stored a copy of something at a specific point in time. It does not prove you can survive.

Most recovery models were designed in the late 90s and early 2000s for relatively static systems and predictable infrastructure. The core philosophy has barely evolved since then, even as environments have become increasingly distributed, ephemeral, and interconnected.

Restoring data is not the same as restoring operations.

Restoring infrastructure is not the same as restoring business functionality. Modern application are complex and rely on ephemeral elements, third party components and applications as well as complex data flows not just data sets.

Very few organizations continuously validate whether they can recover full feature-function applications, maintain operational workflows, preserve data integrity, reconnect dependencies, restore permissions correctly, or continue operating under active attack conditions.

We built incredibly sophisticated telemetry for understanding how we die.

We built almost none for proving we can survive.

That gap is becoming impossible to ignore.

The recent rise of continuous resilience testing and recovery validation is not accidental. It reflects a growing realization that recovery assumptions themselves may no longer be trustworthy.

Static resilience models are struggling to survive dynamic infrastructure.

This is where resilience starts becoming an engineering problem rather than a compliance exercise.

When restoration assumptions fail

Because the real question is no longer, “How quickly can we restore the application?”

The real question is, “What happens if we cannot restore it?”

Jurassic Park repeatedly explored exactly this scenario. The real panic never started when the fences failed. It started when the operators realized they could not regain control quickly enough.

Businesses now face the same risk.

What happens if AWS experiences a prolonged outage? What happens if Azure Identity Services fail globally? What happens if Stripe, Salesforce, Slack, or Microsoft 365 disappear for days rather than hours?

Many organizations do not actually have business continuity strategies for those situations.

They have restoration assumptions.

Twenty years ago, most organizations directly owned large portions of their operational stack. Today, companies increasingly rent critical business capability from a relatively small number of providers.

Identity. Infrastructure. Communications. Payments. Collaboration. Customer operations.

The efficiency gains are enormous.

So is the concentration risk.

Resilience as an engineering discipline

Historically, business continuity planning assumed localized disruption. A building burned down. A regional data center failed. A storm impacted an office. The internet itself was not the dependency.

Today, entire businesses are built on tightly interconnected SaaS and cloud ecosystems where operational survivability depends on third parties remaining continuously available.

We optimized organizations for efficiency, automation, integration, and scale.

Not necessarily survivability.

That is why resilience needs to evolve beyond annual tabletop exercises and static recovery plans.

True resilience is not a binder sitting on a shelf. It is not a workshop performed once a year. It is not a recovery document written against an environment that changed six months ago.

It is a continuous understanding of the environment itself.

It requires live telemetry, operational visibility, dependency awareness, continuous validation, and the ability to adapt under changing conditions.

Adapting to chaos

The survivors in Jurassic Park only succeeded once they stopped pretending the environment was fully controllable and instead adapted to the reality in front of them.

Cybersecurity needs to make the same shift.

Attackers will keep adapting.

AI will accelerate faster than most governance models can handle.

Complexity will continue to outpace our assumptions about control.

The organizations that survive will not necessarily be the ones with the tallest fences. They will be the ones who understand their environments deeply enough to continue operating when control is lost.

The goal was never to eliminate chaos.

It was to survive long enough to adapt to it.

Because resilience is not about preventing chaos.

It is about operating through it.

Because eventually, one way or another, life finds a way.

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

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

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

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

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

Opportunity knocks

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

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

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

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

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

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

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

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

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

Prep for success

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

Boost AI skills

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

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

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

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

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

Gain domain knowledge

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

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

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

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

Acquire soft skills

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

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

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

Master debugging and incident response

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

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

Network and keep learning

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

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

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

덴마크의 다국적 제약사 노보 노디스크(Novo Nordisk)는 특허 만료 전에 신약을 최대한 빨리 시장에 출시하는 데 큰 관심을 두고 있다. 노보 노디스크의 디지털 혁신 책임자(CDTO) 스테파니 보바(Stephanie Bova)는 “대형 블록버스터 신약의 경우 출시가 일주일만 늦어져도 손실 규모가 1,000만~1억 달러(약 149억~1,494억 원)에 이를 수 있다”라며 “특허 보호 기간 동안 제품을 판매할 수 있는 시간이 그만큼 줄어들기 때문”이라고 설명했다.

생성형 AI는 신약 개발 과정의 여러 단계를 획기적으로 단축할 가능성을 제시했다. 특히 노보 노디스크는 핵심 업무 프로세스마다 소요 시간을 꾸준히 추적·관리해 왔기 때문에 다른 많은 기업보다 유리한 출발점에 있었다. 생성형 AI를 일부 업무에 적용하면 생산성이 향상되고, 곧바로 재무 성과로 이어질 것으로 기대할 수도 있었다. 하지만 현실은 그렇게 단순하지 않았다. 신약 개발은 여러 부서에서 다양한 업무가 서로 다른 시점에 진행되는 복잡한 과정이기 때문이다.

보바는 “각 담당자는 자신이 맡은 분야의 전문가이지만, 다음 단계의 업무나 전체 프로세스가 어떻게 연결되는지까지는 잘 알지 못하는 경우가 많다”라며 “시스템 자체가 워낙 크고 복잡해 전체 성과를 한눈에 파악하기 어렵다”라고 설명했다.

프로세스 문서에 기록된 내용과 실제 업무 방식이 일치하지 않는 경우도 적지 않다. 같은 업무를 담당자마다 서로 다른 방식으로 수행하기도 하며, 일부 핵심 업무는 외부에서 거의 드러나지 않는다. 예를 들어 생산팀은 완전히 다른 조직에 속해 있어 신약이 미국 식품의약국(FDA) 제출을 앞두고 있다는 사실조차 인지하지 못할 수 있다. 이 경우 필요한 문서도 아직 준비되지 않은 상태일 수 있다.

보바는 “앞 단계에서는 아무리 빠르게 업무를 진행해도 결국 다른 팀의 준비가 끝날 때까지 기다려야 하는 상황이 발생한다”라고 말했다.

이는 기업이 AI 프로젝트의 성과를 측정하는 과정에서 마주하는 여러 어려움 가운데 하나이며, AI 관련 설문조사 결과가 서로 엇갈리는 이유이기도 하다.

개별 업무 단위에서 보면 노보 노디스크는 AI 도입을 통해 생산성이 향상됐고, 분명한 효과도 확인하고 있다. 하지만 시야를 넓혀 기업 전체의 실적을 기준으로 평가하면 상황은 훨씬 복잡해진다. 중요한 단계 하나라도 누락되면 신약 출시 기간은 단축되지 않는다. 또한 신약이 실제 환자에게 공급되기까지는 수년이 걸리기 때문에 AI 도입에 따른 재무적 효과 역시 상당한 시간이 지나야 나타난다. 그리고 이는 AI 투자 수익률(ROI)을 측정하기 어렵게 만드는 문제의 시작에 불과하다.

프로세스 측정의 중요성

이 같은 프로세스의 사각지대를 해소하기 위해 노보 노디스크는 차세대 프로세스 마이닝 기술인 AI 기반 실시간 운영 디지털 트윈을 도입했다.

보바는 “프로세스 인텔리전스 기업 셀로니스(Celonis)와 협력해 프로세스 데이터를 기반으로 한 디지털 트윈을 구축했다”라며 “임상 분야에 이 기술을 적용한 것은 업계 최초였다”라고 설명했다. 이 도구는 기업 시스템에서 데이터를 수집해 직원들이 실제로 어떤 업무를 수행하는지 추적한다. 일부 직원의 기억에 의존하는 설문조사 방식과 달리 실제 업무 흐름을 객관적으로 파악할 수 있다는 것이 특징이다.

첫 번째 적용 대상은 7단계로 구성된 비교적 단순한 프로세스였다. 하지만 디지털 트윈을 구축한 결과, 실제로는 담당자에 따라 5단계로 진행되기도 하고 9단계까지 늘어나기도 한다는 사실이 드러났다.

보바는 “동일한 업무 전문가 10명을 한자리에 모아도 프로세스에 대한 해석은 제각각이며, 시간이 지나면서 업무 방식도 조금씩 달라진다”라고 말했다.

프로젝트는 기존 프로세스의 여러 문제점도 찾아냈다. 일부 업무는 직원 재교육이 필요했고, 어떤 경우에는 사용자 인터페이스(UI)를 개선해야 했다. 하지만 일단 프로세스를 표준화하면 AI 도입 이전의 기준 데이터를 확보할 수 있다. 이를 기반으로 AI를 활용한 업무 지원이나 자동화가 실제 성과를 냈는지 객관적으로 비교·평가할 수 있다.

또 하나 미리 결정해야 했던 과제는 AI로 확보한 시간을 어떻게 활용할 것인지였다.

보바는 “사람을 감원하는 것은 바람직하지 않다”라며 “이들은 고도의 전문성을 갖춘 구하기 어려운 인재인 만큼, 팀 간 인력을 재배치하는 방안을 고려하는 편이 더 적절하다”라고 밝혔다.

현재 노보 노디스크는 수백 개의 AI 에이전트를 실제 업무에 운영하고 있다. 이들 에이전트는 모두 디지털 트윈 인프라 안에서 식별할 수 있도록 관리된다.

보바는 “문제가 발생하면 어디에서 오류가 생겼는지 정확히 파악해 바로 수정할 수 있다”라며 “다음 단계는 여러 AI 에이전트가 서로 협업하는 멀티 에이전트 오케스트레이션이다. 지금은 각각의 AI 에이전트가 연결돼 있지만, AI 에이전트를 관리하는 또 다른 AI 에이전트는 아직 없는 상태”라고 설명했다.

다만 신약 개발은 수년에 걸쳐 진행되는 만큼 아직 AI 투자 수익률(ROI)을 평가하기에는 이르다는 것이 보바의 설명이다.

보바는 “전체 프로세스를 종단간(end-to-end)으로 분석하면 불필요한 과정을 제거해 개발 기간을 2년 정도 단축할 수 있을 것으로 기대한다”라며 “현재보다 2년 더 빨리 시장에 제품을 출시하는 것이 목표”라고 말했다.

이미 임상 개발 막바지에 접어든 신약은 AI 도입에 따른 시간 단축 효과가 제한적이다. 반면 개발 초기 단계의 신약은 가장 큰 혜택을 받을 것으로 예상된다. 다만 이러한 성과가 기업의 재무 실적으로 이어지기까지는 앞으로 수년이 더 걸릴 전망이다.

이처럼 여러 프로세스를 동시에 최적화해야 진정한 가치를 얻을 수 있는 산업은 제약업계만이 아니다. PwC에 따르면 단발성 AI 프로젝트는 측정 가능한 성과를 내지 못하는 경우가 많다. 반면 기업의 경영 전략과 연계된 전사적 규모의 AI 도입은 실질적인 투자 수익을 창출하는 것으로 나타났다.

실제로 AI 도입이 거의 보편화됐음에도 불구하고 지난 12개월 동안 AI를 통해 매출이 증가하거나 비용이 감소했다고 답한 기업은 많지 않았다. 그럼에도 KPMG는 올해 말 기업의 AI 투자 규모가 지난해보다 거의 두 배로 증가할 것으로 전망했다.

생산성 측정

대부분의 기업은 비교적 작은 규모에서 AI 도입을 시작한다. 대표적인 사례가 직원 생산성 향상을 위한 AI 챗봇 도입이다. AI 챗봇은 놀라울 정도로 빠른 속도로 확산됐지만, 정작 기대했던 생산성 향상을 어떻게 측정해야 하는지는 여전히 쉽지 않은 과제로 남아 있다.

카네기멜런대학교 AI 교수 아난드 라오(Anand Rao)는 무엇보다 기준선(baseline)을 확보하는 것이 중요하다고 말한다. 하지만 어떤 업무는 기준선을 측정하기가 어렵고, 어떤 경우에는 사실상 불가능하다.

예를 들어 보험 심사는 결과가 나타나기까지 수년이 걸린다. 생명보험이라면 그 기간이 수십 년에 이를 수도 있다. 일부 의사결정은 애초에 성과를 측정할 기준 자체가 존재하지 않는다.

라오는 “사람의 의사결정 과정과 그 질을 평가하겠다고 하면 사회적 거부감이 생긴다”라며 “사람은 자신의 의사결정이 평가받는 것을 좋아하지 않는다”라고 설명했다.

이어 “결과가 좋으면 누구나 자신의 공이라고 말하지만, 결과가 나쁘면 외부 요인 때문이라고 생각하는 경향이 있다”라고 말했다.

측정이 가능한 업무라도 상황은 크게 다르지 않다. 많은 기업이 AI를 도입하기 전에 기존 성과를 측정하는 작업부터 하지 않는 경우가 많기 때문이다.

패션 소매업체 룰루레몬(Lululemon)의 전 글로벌 최고정보책임자(CIO)이자 수석부사장(EVP)을 지낸 줄리 애버릴(Julie Averill)은 “처음부터 기준선을 마련하지 않았다”라고 말했다. 현재 애버릴은 디지털 혁신 컨설팅 기업 골드 스레드(Gold Thread)의 CEO를 맡고 있다.

애버릴은 “AI가 더 나은 의사결정을 도와줄 것이라는 전제를 먼저 세우고 시작했다”라며 “그렇게 되면 이후 성과를 제대로 측정하기가 어려워진다”라고 설명했다.

물론 다른 지표를 활용할 수도 있다. 예를 들어 AI 사용률이나 사용자 만족도 같은 수치다.

애버릴은 “AI는 실제로 활용되고 있고 다양한 이점을 만들어내고 있다”라며 “눈에 보이는 효과도 있지만 그렇지 않은 효과도 있다. 결국 프로세스를 믿어야 한다”라고 말했다.

이어 “이는 클라우드 도입과 비슷하다. 모두가 미래의 방향이라는 사실은 알고 있고 장점도 이해하지만, 실제로 전환하기는 쉽지 않으며 조직 전반에 많은 변화가 필요하다”라며 “하지만 전환을 빨리 시작할수록 새로운 운영 방식에 더 빨리 적응하고 AI의 가치를 제대로 활용할 수 있다”라고 설명했다.

반면 고객 서비스처럼 성과를 수치로 측정하기 쉬운 영역도 있다.

애버릴은 “고객 서비스는 반복적인 업무가 많아 기업이 AI 자동화를 가장 먼저 적용하는 분야”라며 “측정 가능한 결과가 분명하고 기준선도 비교적 쉽게 설정할 수 있다”라고 말했다.

룰루레몬은 개인화 추천 시스템에도 수년간 AI를 활용해 왔다. 이 역시 성과를 정량적으로 측정할 수 있는 분야다. 또한 AI는 수작업 데이터 입력을 자동화해 오류율을 낮출 수 있으며, 규정 준수 모니터링과 사기 탐지, 설비 예지보전(Predictive Maintenance) 등에서도 활용되고 있다. 이러한 분야는 모두 AI 효과를 수치로 평가할 수 있다.

하지만 직원 생산성 전반을 측정하는 일은 룰루레몬뿐 아니라 대부분의 기업에 여전히 어려운 과제다.

가장 직관적인 방법은 AI의 영향을 많이 받는 직종에서 실제 해고가 늘어났는지를 살펴보는 것이다. AI 때문에 일자리가 줄어든다는 보도는 이미 넘쳐난다.

그러나 올해 3월 공개된 앤트로픽 보고서는 다른 결과를 제시했다. AI의 영향을 가장 크게 받는 직종, 즉 AI로 인해 해고 가능성이 가장 높은 직군에서도 실업 증가를 보여주는 증거는 발견되지 않았다.

2025년 초에는 연구기관 METR이 숙련된 소프트웨어 개발자를 대상으로 AI 사용 여부에 따른 업무 수행 속도를 비교하는 실험을 진행했다.

결과는 예상과 달랐다. 개발자들은 AI를 사용하면 생산성이 24% 정도 향상될 것으로 기대했고, 실제 체감 효과도 약 20%라고 평가했다. 하지만 실측 데이터는 정반대였다. AI를 사용한 경우 오히려 작업 속도가 평균 19% 느려진 것으로 나타났다.

물론 AI 도구는 빠르게 발전하고 있다. METR은 AI 사용 여부를 다시 비교하는 후속 연구를 추진했지만 충분한 참가자를 모집하지 못했다. 연구 참여 비용을 지급했음에도 AI 없이 작업하는 방식으로 돌아가려는 개발자가 거의 없었기 때문이다.

물론 AI 덕분에 한 명의 엔지니어가 수백 명의 업무를 수행했다는 사례도 심심치 않게 들린다. 클로드 코드의 50만 줄 규모 코드베이스가 실수로 유출됐을 당시 한국인 개발자 시그리드 진(Sigrid Jin)이 클린룸 방식(원본 코드를 직접 복사하거나 참고하지 않고, 동일한 기능을 새롭게 구현하는 개발 방식)으로 이를 2시간 만에 재구현한 뒤 깃허브에 공개했고, 해당 프로젝트가 역대 가장 빠르게 별 10만 개를 달성했다는 사례도 있다.

하지만 AI와 관련된 대부분의 이야기처럼 실제 상황은 훨씬 복잡하다. 특히 소프트웨어 개발에서는 코드를 작성하는 일 자체가 전체 개발 과정에서 차지하는 비중은 일부에 불과하다.

리서치 기관 DX가 400개 기업의 핵심 엔지니어링 지표를 분석한 보고서에 따르면 AI 활용률은 2024년 11월 이후 65% 증가했다. 그러나 AI로 인한 생산성 향상은 10%에도 미치지 못한 것으로 나타났다.

AI의 숨은 비용

AI의 생산성 향상을 측정하기 어려운 것처럼 AI 도입 비용을 정확하게 산정하는 일도 쉽지 않다. 기업이 AI를 처음 도입할 때는 비용을 비교적 간단하게 계산할 수 있다. 직원들이 사용하는 AI 챗봇의 월 구독료는 얼마인지, 맞춤형 모델을 학습하거나 파인튜닝하는 데 얼마나 드는지만 계산하면 되기 때문이다. 하지만 활용 사례가 복잡해질수록 비용 산정도 훨씬 어려워진다고 애버릴은 설명했다.

애버릴은 “이제는 AI 자체뿐 아니라 AI를 둘러싼 다양한 시스템까지 고려해야 한다”라며 “이런 비용은 측정하기는 더 어렵지만 기업에 미치는 영향은 훨씬 크다”라고 말했다.

예를 들어 RAG을 활용해 AI를 업무 프로세스에 통합하면 LLM API 호출 비용이 지속적으로 발생한다. 여기에 기존 시스템을 연동하거나 수정하는 비용까지 추가된다. 이러한 비용 구조는 시간이 갈수록 더욱 복잡해지고 있다.

KPMG의 글로벌 AI·데이터 랩 총괄인 스와미나탄 찬드라세카란(Swaminathan Chandrasekaran)은 “기업들은 지금까지 AI 사용 현황을 체계적으로 수집·분석할 수 있는 텔레메트리와 계측 체계를 구축하는 데 충분한 노력을 기울이지 않았다”라고 말했다. 기업 전체의 AI 비용을 정확히 파악하는 일은 마치 날씨를 예측하는 것과 비슷하다는 설명이다.

그는 “오늘날 정확한 기상 예보가 가능한 이유는 수만 개의 기상관측소가 데이터를 수집하고 이를 종합하기 때문”이라며 “그런 데이터가 없다면 날씨를 예측할 수 없을 것”이라고 설명했다.

기업도 AI 활용 전반을 측정할 수 있는 계측 체계를 구축해야 한다는 것이 그의 주장이다. 얼마나 많은 토큰을 사용했는지, 누가 사용했는지, 그리고 그 사용량이 실제 업무 성과와 어떤 관계가 있는지까지 추적해야 한다는 것이다.

찬드라세카란은 “현재는 이러한 측정 체계가 근본적으로 부족한 상황”이라고 지적했다.

직원이 AI 챗봇을 사용하는 경우에는 그나마 비용을 예측하기 쉽다. 사람이 하루에 입력할 수 있는 질문 수에는 물리적인 한계가 있고 구독료도 비교적 일정하기 때문이다. 또한 RAG를 적용한 업무 시스템에서는 기존의 규칙 기반 시스템이 예측 가능한 방식으로 LLM API를 호출한다.

하지만 에이전틱 AI가 등장하면서 상황은 훨씬 복잡해졌다. AI 에이전트는 예측하기 어려운 방식으로 자율적으로 행동하기 때문에 API 호출 횟수가 급격히 늘어날 수 있다. 보스턴컨설팅그룹(BCG) 보고서에 따르면 기업의 약 3분의 2는 AI 확장에 따른 비용이 통제하기 어려운 수준으로 증가하고 있다고 답했다.

기업이 간과하기 쉬운 또 다른 비용은 데이터 관련 비용이다. 다른 예산 항목에 포함돼 있다는 이유로 제대로 추적하지 않는 경우도 많다. AI 학습이나 파인튜닝을 위한 데이터 준비, RAG 임베딩 구축, AI 에이전트를 통한 MCP 직접 연동 등은 모두 상당한 비용을 수반하며, AI 도입이 확대될수록 이러한 비용은 빠르게 증가할 수 있다.

컨설팅 업체 코글린 어소시에이츠(Coughlin Associates)의 대표이자 IEEE 펠로인 톰 코글린(Tom Coughlin)은 “대표적인 비용 가운데 하나가 데이터 반출(egress) 비용”이라며 “클라우드에서 데이터를 꺼내와야 하는 경우 데이터 반출 수수료가 상당한 수준까지 늘어날 수 있다”라고 설명했다.

AI 도입에는 사람에 대한 투자 비용도 적지 않다.

코글린은 “장기적으로 AI는 큰 가치를 제공하겠지만, 이를 제대로 활용하려면 직원들이 올바르게 사용하는 방법을 익혀야 한다”라며 “그러한 역량이 부족하면 결국 경쟁에서 뒤처질 수밖에 없다”라고 말했다.

해결책과 상반된 현실

AI 프로젝트에서는 문제를 해결하는 데도 적지 않은 비용이 든다. 지난 18개월 동안 대다수 기업이 최소 한 차례 이상의 AI 관련 사고를 경험했으며, 그중 상당수는 금전적 손실로 이어졌다. 일부 기업은 피해 규모가 50만 달러(약 7억 4,700만 원)를 넘기도 했다. 여기에 AI 기능이 거의 모든 소프트웨어와 서비스에 기본 탑재되면서 ROI를 계산하는 일은 더욱 복잡해지고 있다.

미국 로펌 브라운스타인 하얏트 패버 슈렉(Brownstein Hyatt Farber Schreck)의 최고정보책임자(CIO) 앤드루 존슨(Andrew Johnson)은 “직접적인 비용은 정확히 파악할 수 있다”라면서도 “기존에 사용하던 플랫폼이나 원래 AI 기능이 없던 SaaS 애플리케이션에 AI가 추가되는 경우에는 비용을 측정하기가 훨씬 어렵다”라고 말했다.

이어 “공급업체들은 AI 기능이 추가됐다며 라이선스 비용을 큰 폭으로 인상하고 있다”라며 “그 인상분 가운데 실제로 얼마나 AI 때문인지를 따져보면 명확하지 않은 경우가 많다”라고 설명했다.

AI가 비용 절감 효과를 가져오더라도 그에 따른 추가 비용이 발생하는 경우도 적지 않다. 예를 들어 브라운스타인은 계약 관리 플랫폼에 연간 약 7만 달러(약 1억 462만 원)를 지출하고 있었다. 이를 AI를 활용해 자체 구축하면서 약 4만 달러(약 5,980만 원)의 개발 인건비와 연간 3,000달러(약 448만 원)의 호스팅 비용이 들었다. 이후 유지보수 비용도 연간 수천 달러 수준으로 발생할 예정이다.

여기에 자체 애플리케이션을 운영하면 보안 감사와 취약점 평가, 침투 테스트, 코드 리뷰 등 간접 비용도 함께 고려해야 한다.

존슨은 “플랫폼이 복잡하고 위험도가 높을수록 자체 솔루션을 개발하려는 의지는 그만큼 줄어든다”라고 말했다.

그럼에도 AI 덕분에 소프트웨어 개발 조직의 생산성은 크게 향상됐다. 현재 개발자 4~5명이 과거 20~30명이 수행하던 업무를 처리할 수 있게 됐다.

하지만 생산성 향상이 곧바로 인건비 절감으로 이어지는 것은 아니다. 해결해야 할 새로운 프로젝트가 계속 생겨나기 때문이다.

존슨은 “개발해야 할 솔루션 아이디어가 엄청나게 많이 쌓여 있다”라고 말했다.

카네기멜런대학교의 라오 교수는 업무는 가용한 시간을 모두 채우는 방향으로 늘어나는 경향이 있다고 설명했다.

예를 들어 AI 덕분에 생산성이 20% 향상됐다고 가정해 보자. 라오는 “100명이 하던 일을 이제는 80명이 할 수 있게 됐다고 생각할 수 있다”라며 “하지만 연말이 돼도 실제 인원은 그대로인 경우가 많다”라고 말했다.

이어 “기존 업무는 분명 더 효율적으로 처리된다”라며 “하지만 사람은 확보한 20%의 여유 시간을 활용해 새로운 업무를 추가하거나 기존 업무를 보완한다. 한 시간 일찍 퇴근하는 것이 아니라 새로운 가치를 만드는 일에 시간을 쓰게 된다”라고 설명했다.

오히려 일부 업종에서는 생산성 향상이 단기적으로 수익성을 악화시킬 수도 있다. 대표적인 사례가 시간당 수임료를 청구하는 법률 서비스다.

존슨은 “효율성 향상은 지금까지 법률업계가 수익을 창출해 온 방식과 상충하는 측면이 있다”라며 “하지만 장기적인 관점에서 생각해야 한다. 단기적으로는 어려움이 있지만 장기적으로는 결코 불리한 일이 아니다. 오히려 AI를 도입하지 않으면 중장기적으로 경쟁력을 잃을 가능성이 크다”라고 말했다.

예를 들어 AI가 변호사의 실사(due diligence) 업무를 지원한다고 해서 해당 AI 도구에 투자한 비용이 곧바로 매출 증가로 이어진다고 단정하기는 어렵다.

존슨은 “AI 도입이 장기적으로 올바른 방향이라는 점은 분명하다”라며 “다만 그것이 구체적으로 어느 정도의 투자 수익으로 이어질지는 아직 단정하기 어렵다”라고 말했다.
dl-ciokorea@foundryco.com

Customer expectations don’t end when business hours do, which is why delivering a fast, always-on customer experience (CX) has traditionally required large call centres and significant resources. This often placed small businesses at a disadvantage, as many lacked the manpower and budget to provide 24/7 support at scale. Today, AI has completely levelled the playing field. Even small businesses now have access to powerful tools that can answer queries, resolve routine issues, and deliver highly personalised interactions around the clock.

But adopting AI in customer engagement is not just a question of efficiency. For smaller businesses especially, where loyalty is often built on familiarity, trust, and personal service, the real challenge is using AI in ways that strengthen rather than dilute the human connection that customers value most.

Human empathy combined with AI efficiency is a delicate blend. Done right, it ensures that every customer interaction feels personal, thoughtful, and seamless, whether the customer is engaging with a bot at 2 a.m. or a live agent during office hours.

So, how can small businesses embrace always-on virtual agents without losing the human connection that defines their identity? Here’s a practical playbook to guide the transition.

1. Understand what customers want: Speed, simplicity, and empathy

Before diving into AI adoption, it’s critical to understand what customers expect. Twilio’s Digital Patience study suggests that while speed matters, it is not the only thing that customers value. Twilio found that 46% of respondents in the Asia-Pacific and Japan region say quick service and resolution are most important, but 51% say delays are acceptable if they lead to better customer support. The study also notes that customers are open to AI, but still value human touchpoints more highly.

The takeaway: AI should enhance CX, not replace it. Businesses can let natural-sounding AI voice agents handle inbound calls, regardless of peak hours or time zones. These virtual agents act as an intelligent frontline – answering common questions and qualifying leads – before seamlessly routing the conversation to a live human representative. The result? Callers get immediate answers, and the business captures every opportunity without losing the human touch.

2. Map the handover points between AI and humans

One of the most common pitfalls in implementing AI is failing to clearly define when and how customers transition from bots to human agents. To avoid customer frustration, organisations must thoughtfully map out these “handover points” by designing for two key principles: choice and continuity.

Designing for Choice

Give customers the option to reach a human when needed. While AI is perfectly suited for routine inquiries like FAQs or order tracking, customers should never feel trapped in a bot loop. Always provide a clear, accessible option for them to choose to escalate the issue. Additionally, configure your system to proactively step in and offer a human handoff the moment it detects emotion, ambiguity, or complex steps.

Designing for Continuity

Effective handovers rely on technology that recognises when an issue exceeds AI’s scope. By leveraging natural language processing and intelligent routing, organisations can ensure the transition from machine to human is frictionless. Crucially, this means automatically carrying the full history and context of the interaction forward so the customer never needs to repeat themselves.

Achieving this level of continuity requires a new approach to managing interaction data during handovers. Instead of passing along a raw transcript, organisations need a managed memory service that provides agents with persistent context across every conversation, channel, and session. By transforming customer preferences, unresolved issues, and intent into a structured semantic profile—one that continuously evolves and reconciles new interactions as they occur—agents can quickly understand the relationship and continue the interaction without disruption.

To support truly omnichannel experiences, the system must also resolve identity automatically across touchpoints, linking interactions from phone, email, messaging apps, and other channels to a single customer profile. Equally important is the ability to surface only the information that is relevant to the task at hand. By presenting agents with a concise summary of the active issue and customer preferences, grounded in verified business knowledge such as product policies and FAQs, organisations can reduce resolution times while ensuring customers experience a seamless continuation of the conversation.

3. Don’t automate for automation’s sake

AI adoption should never feel like a “set it and forget it” strategy. Instead, it should be approached as a way to solve real business problems. It starts with asking questions like: What are the most time-consuming tasks for the team? What frustrates customers the most?

For instance, a restaurant might automate table reservations and menu queries, while a small online retailer could deploy AI to handle order status updates or product recommendations. These targeted use cases ensure that AI adds tangible value without overwhelming operations.

Take the example of Driva, a fast-growing online finance broker that deployed AI-powered customer service tools to answer routine enquiries and provide immediate assistance while customers wait in the call queue. By automating common interactions, Driva reduced the volume of requests requiring human intervention and achieved a 5% uplift in conversion rates at key points in the customer journey.

4. Invest in AI that connects

While consumers embrace automation, research shows they still draw comfort from the warmth of a human voice. To make your virtual agents feel less robotic and more like an extension of your team, look for tools that:

• Deliver human-like voice AI experiences at scale through natural turn-taking and barge-in capabilities.
• Connect interactions across voice, messaging, and digital channels into a single thread so every exchange builds on the last.
• Leverage Natural Language Processing (NLP) that enables conversational systems to interpret context, mimic human tone, and even recognise sentiment.
• Place orchestration at the heart of the experience. An effective orchestration engine acts as the “conductor,” actively coordinating workflows and routing interactions so the right resource—whether an AI bot or a human—handles the right moment.

When AI bots, automated workflows, and human teams are seamlessly coordinated behind the scenes, the customer simply experiences one unbroken, dynamic dialogue. For small enterprises, this means delivering sophisticated experiences that effortlessly bridge the gap between automation and live support, even at scale.

5. Empower teams with real-time context

AI is not about replacing human workers; it’s here to make jobs easier. However, for teams to fully embrace this new dynamic, organisations must shift their focus from retrospective performance reviews to real-time agent assistance. By feeding agents context as the conversation happens, businesses ensure that every interaction never starts from scratch.

• Leveraging Conversational Intelligence: Use a real-time intelligence layer that turns live conversations into signals and actions. By analysing voice and messaging with generative AI Language Operators, businesses can understand intent, sentiment, and churn risk instantly, allowing human and AI agents to act in the moment with the right response or escalation.
• In-the-Moment Guidance: Give agents instant context and in-the-moment guidance during every interaction. Surfacing relevant customer history, next-best action suggestions, and summaries in real time allows agents to resolve issues faster without switching tools.
• Resolving Complex Customer Needs: AI can handle routine enquiries with low latency, but human agents still excel at nuanced problem-solving. With AI feeding them persistent customer memory and sentiment analysis in real time, human agents can skip the repetitive questions and immediately focus on resolving complex issues, rescuing deals, or preventing churn.

When employees are equipped with real-time customer data and voice-driven insights, SMEs empower their teams to stop reacting to problems and start responding to customers proactively.

Consider global AI platform Genspark, which leverages a Programmable Voice API for its “Call for Me” agent to handle complex outbound tasks like checking supplier pricing or booking international hotels. The AI can conduct real-time, natural conversations across different languages on the user’s behalf, seamlessly navigating the live interactions before delivering a structured summary. Because these natural voice experiences depend entirely on speed and consistency, the underlying infrastructure provides the critical sub-second latency necessary to keep every automated call clear and uninterrupted.

6. Maintain transparency with customers

Finally, a successful AI implementation requires transparency. Customers should always know when they’re communicating with a bot and when they’ve been handed over to a human. AI-powered interactions must offer clarity by providing transparency about when and how AI is used and explaining next steps in plain language.

Transparency builds trust. Small businesses can go a step further by soliciting customer feedback on their AI interactions and using this input to fine-tune their systems.

For small enterprises, the AI-to-human handover isn’t about choosing between humans and machines; it’s about combining the strengths of both to create exceptional customer experiences. AI can provide the speed and efficiency customers expect, while humans deliver the empathy and creativity they value.

By strategically defining handover points, investing in human-like AI, and empowering agents to work alongside technology, organisations can build a CX strategy that’s as scalable as it is personal.

This blended approach ensures that every interaction – whether managed by a bot or a human – is thoughtful, natural, and distinctly on-brand.  

To learn more about Twilio, visit here.

It’s the end of the road for yet another facet of Exchange Server, Microsoft’s on-premises email and calendar system. The stripped-down version of its web client, Outlook Web App (OWA) Light, is being retired, forcing those Exchange Server users still using it to adopt the standard Outlook Web App instead.

“OWA Light was created for a much earlier era of the web, when browser support, bandwidth, and accessibility technologies were very different from today. Going forward, we want to invest in a modern Outlook on the web experience that provides the cross-browser, accessible, and security-focused experience,” said Microsoft.

Those enterprises still operating in a resource-constrained environment are out of luck, then.

The change will be effected in an upcoming Exchange Server update expected in August. The move should come as no surprise: Microsoft had already deprecated the light version of Outlook in August 2024. Microsoft said that sysadmins should spend the next couple of months preparing for the change by identifying any staff still using OWA Light.

This is just the latest alteration that Microsoft has made to its Exchange ecosystem, which some holdouts still use instead of the SaaS-based Microsoft 365 service. However, even on-premises customers must now pay a subscription fee to use Exchange Server.

One of the advantages of SaaS offerings is that customers don’t have to deal with patching, an advantage brought home to on-premises customers in May when a zero-day exploit struck Exchange Server.

Michael Taylor has spent 25 seasons with the Mercedes-AMG Petronas F1 team, working every IT role from trackside support to engineering systems to business transformation. Today, as IT director, he leads an 18-person team responsible for one of the most data-intensive operations in the world.

When a car rolls out of the garage, it carries 300 sensors. When it’s running, it generates more than a million data points per second. Every component, system, and lap produces telemetry that engineers use to find fractions of a second — the difference between winning and losing.

“Formula One has been data-centric for many years,” Taylor says. “The key metric in our sport is the stopwatch, and that’s been true since the World Championship began in the 1950s. But now we instrument everything. If you measure it, you can improve it.”

The challenge isn’t collecting data — Formula One has been streaming live telemetry since the 1980s. It’s making decisions at speed while maintaining the governance that keeps a complex, high-stakes operation running.

For CIOs navigating the pressure to move fast on AI while managing risk, security, and data quality, Taylor’s hard-won lessons from the pit lane offer a useful framework: how to balance speed and control, when to keep humans in the loop, and why “good enough” governance beats perfect governance that never ships.

Innovation vs. stability: ‘A constant battle’

In most enterprises, the tension between innovation and control plays out over quarters or years. In F1, it happens weekly.

“It’s really tough,” Taylor admits. “And something we don’t always get right. This is where we rely on people. Industry experience is really important when making decisions around change.”

The team operates in two distinct modes. Between races, they’re at the factory in Brackley, UK. The site, which is headquarters for the design, manufacturing, and operation of their championship-winning Formula One cars, includes a 60,000-square-meter technology campus. It’s all project and program management, with room for experimentation. But as race weekend approaches, everything shifts to execution.

“We have that kind of normal mode when we’re not racing. We’re back at the factory designing and building and improving,” Taylor explains. “But as we get closer to race weekend, we switch to executing that in the most effective way. We have to not make changes that will impact engineers.”

This duality shapes every technology decision. The same agility that drives innovation during the week must yield to stability when results are on the line. Taylor calls it a “constant battle.”

Modernizing at racing speed

Mercedes-AMG Petronas had run SAP since 1999. The platform underpins the team’s entire design-to-track process — from design release through planning, procurement, manufacturing, testing, and development, all the way to reassembling the car trackside.

“All of those steps are core processes,” Taylor says.

So, when it came time to modernize, the team approached it like a pit stop: planned to the second, executed with precision. They chose RISE with SAP — the vendor’s bundled cloud ERP and migration package — agreeing to the journey in December 2024 and targeting a go-live in August 2025, aligned with the sport’s mandatory two-week shutdown.

“It’s the perfect window to make changes,” Taylor says. “We have to plan everything to perfection so it goes smoothly when we start racing again.”

They finished eight weeks ahead of schedule.

“We are control freaks because of the sport and its time-bound nature,” Taylor says. His team prefers to own and manage systems in-house rather than rely on large systems integrators who “dip their toes in and disappear,” Taylor says. With just 18 people on the IT team, they tap SAP’s expertise for specific problems, then take back the reins. “Once done, we continue to own and manage,” Taylor explains, “and SAP does what they do best.”

The secure path must be the easiest path

Intellectual property in F1 racing has a short shelf life. Once a new component is on the car and photographed in the pit lane, competitors can see it. But that doesn’t diminish the value of what’s behind it.

“The real advantage is not just the part,” Taylor says. “It’s the thinking, the modeling, the simulation, the failure modes, the trade-offs, and the development direction behind it.”

Protecting that requires an offensive security posture. Taylor’s head of information security reports directly to him, and the team actively probes its own defenses.

“Act like, think like, work like a hacker,” Taylor says. “We’re thinking about how we can counter threats without impact on end-users.”

In an engineering-permissive culture where people are empowered to move fast, heavy-handed security backfires. Taylor learned early that perfection is the enemy of progress.

“If security gets in the way of the business, the business will find ways to work around it,” he says. “The job is not to slow the organization down; it’s to make the secure path the easiest path.”

Humans in the loop

With AI evolving weekly, Taylor’s team is running pilots across the organization: machine learning for simulation, agentic workflows in production planning, copilots helping developers write code. But he’s resisting the urge to rush.

“We’re still finding our way,” he says. “There’s no one-size-fits-all. We’re playing with everything available, but in six to ten months we’ll make decisions about what to scale.”

Despite the hype around autonomous AI, Taylor remains committed to human oversight.

“I’m still very much ‘humans should be in the loop,’” he says. “When our workforce is harmonized with AI, that’s where we’ll see real benefit — where it complements our people.”

AI has also raised the bar for data governance. “Good enough now includes stronger visibility, cleaner permissions, and clearer ownership,” Taylor says. “You have to be more deliberate about what data AI is allowed to access.”

Start with consequence

Taylor’s advice to CIOs in other industries wrestling with similar questions is deceptively simple: “Start with consequence, not technology.”

In financial services, it might be customer harm or a regulatory breach. In healthcare, patient safety or loss of public trust. In F1, the consequence of a security failure is loss of competitive advantage.

“Once you understand the consequence, you can decide what needs the strongest control, what needs monitoring, what needs retention, and what simply needs better hygiene,” Taylor says.

It’s a lesson learned over 25 seasons at the edge of what’s technically possible — where decisions happen in milliseconds, and the margin between success and failure is measured in fractions of a second.

The threat that I now spend most of my time designing against doesn’t look like a breach at all. At least not at first.

Imagine a team deploys an agent that does exactly what it’s permitted to do: it reads a customer record, summarizes it, then sends the summary to an outside address. Every step in the sequence is authorized. But it turns out that the breach is the sequence itself.

The problem is that each security check only looks at one step at a time. Is this read okay? Yes. Is this summary okay? Yes. Is this email okay? Yes. Each step passes. But nobody is watching the combination of all three steps together. The security tools designed for human-driven workflows assumed a person would be doing this manually, one thing at a time. However, the AI agent bundles it all into a single automated sequence, and that bundling slips through gaps between the checks.

I build authorization for agentic systems, and the gap between “every action was allowed” and “the outcome was a breach” is what I keep coming back to.

An agent is not a user or a file. It is an insider authorized with an API token instead of a badge to act on your behalf. We learned decades ago that perimeters don’t secure against insiders. But in the design reviews I’ve sat in this year, the security conversation still centers on prompt injection and output filtering. That’s one layer below where the exposure has moved.

Two decades of asking the wrong two questions

We spent 20 years getting very good at two questions:

• Who is allowed in?
• What data is allowed out?

Identity and access management answered the first question. Data loss prevention the second. Both assume a world of users and files—a human you authenticate at the door and a document you inspect on the way out. But production AI agents make both questions obsolete.

An agent is an actor. It reads context, chains tool calls, invokes connectors and changes systems of record, then hands work to other agents as it goes. The danger isn’t that it does one clearly forbidden thing; it’s that it does a series of small, permitted things that add up to something harmful. And because each individual action looks fine, the standard security tools don’t flag anything. It’s the same reason an employee with legitimate access is harder to catch than an outside hacker.

This is a known failure mode in IT security, sometimes called the confused deputy problem: a program with legitimate authority gets manipulated into misusing it on someone else’s behalf. Now, AI agents have given it initiative. An agent is a confused deputy that doesn’t just hold authority but plans with it. The OWASP community ranks excessive agency—an agent operating with broader capability than its task requires—among the top risks for large language model applications.

The four ways agent authority goes wrong

When I threat-model an agent before it ships, four failure modes do most of the damage, and the governance conversation most teams are having addresses none of them.

1. Tool-chain abuse. Each tool call is safe on its own, but the chain composes into something no one authorized. The pattern is mundane: an agent permitted to read records, call a summarizer and send mail turns those three benign capabilities into a clean exfiltration path. Content filtering inspects each step and waves all of them through, because no single step is prohibited.

2. Delegation-chain exploitation. An agent hands a subtask to another agent, and the child ends up with authority it was never meant to have. The mechanism is simple: the parent passes the child a copy of its own credentials, so the child can now do everything the parent can. Most orchestration frameworks pass parent context down by default because they assume the child is trusted. That’s a framework default, not a security decision.

3. Approval evasion. A human-in-the-loop gate is supposed to catch the consequential action, but the agent reaches the same outcome by a path the rule didn’t anticipate. This isn’t agents being clever; it’s policies written for human workflows. A gate that checks “summarizing customer records” is blind to an agent reaching the same data by another tool path. In other words, it guards the actions humans take, not the outcome it was meant to protect.

4. The first three are how the breach happens. The fourth is why it becomes a crisis: audit opacity. Even after you discover something went wrong, you can’t piece together the full picture: what exactly the agent did, who authorized it to do those things or whether it went beyond what it was supposed to do. The logs simply show that reads and sends happened. Only in the post-incident review do teams discover their logs were written for debugging, not for proof.

Move the decision to runtime

When these failure modes surface, the instinct is to add another detection layer, such as a better filter or a smarter classifier watching the output. That instinct is wrong. You can’t inspect your way out of a problem of authority. The answer is a runtime policy engine that governs what an agent is allowed to do at the moment it acts.

The concept isn’t new; it’s zero trust, applied inward. We spent years pushing zero trust outward to the perimeter for people and devices. Every request is authenticated and authorized in context, decided centrally rather than assumed at the edge. Agents move the object of that decision inward, from who are you at the door to what will you do in the next call.

A runtime policy engine makes that concrete. It evaluates which tool is being called, which data is being touched and what the downstream effect will be.

Three properties make it real:

1. Decide before the action fires. Evaluate the agent’s intended action against policy and live context at call time, not afterward in a log review. A policy that isn’t evaluated at the moment of action isn’t a control.

2. Make delegated authority shrink. Authority should only narrow as it passes from agent to agent, never widen. That way, a compromised agent can’t exceed the narrowest link in its chain, and stopping a parent leaves no orphaned authority downstream. Capability can still be re-requested; a child can ask its parent to escalate, but that escalation is evaluated and logged at call time, not baked into a token handed over once.

3. Build audit as evidence, not logs. Evidence means a record that ties each action to the policy that authorized it—principal, tool called, inputs, the rule evaluated, the decision and a timestamp—in append-only or signed storage so it can’t be quietly rewritten. It lets a regulator or a board reconstruct who acted, on whose authority and whether that authority was exceeded, instead of relying on a forensic reconstruction weeks later. Most deployments skip this because it’s infrastructure work, not policy work.

One implementation caveat: Evaluating every action at runtime adds latency and demands live policy context. Some friction is unavoidable, so the question is where you add it. Focus on the actions where a mistake is hardest to reverse: Anything touching customer data, financial systems or infrastructure.

The three questions I ask before every deployment

When a team brings me an agent bound for a real system of record, I’ve stopped asking which model it uses. I ask three things instead:

1. Can every action resolve to a human source of authority, captured at runtime?

2. Does the agent’s authority shrink as it delegates, or can a subagent do more than its parent?

3. If this agent did something wrong tomorrow, could we prove what it did? (Not describe it. Prove it.)

The autonomy that makes AI agents so valuable also makes legacy controls insufficient. You can’t add autonomous agents to your existing processes and expect last year’s controls to cover them. When an agentic breach happens, the question the board asks won’t be, “What leaked?” It will be, “What was your agent allowed to do, and can you prove it?”

Get ahead of it before the board has to ask.

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

It is lap 47 of 57.

Before the race began, the team had already processed gigabytes of race data, simulations, tire models, weather forecasts, competitor tendencies and scenario plans. But on the pit wall, there is tension.

The race leader’s tires are degrading faster than predicted. A rival has just pitted for fresh tires and is closing the gap by three-tenths of a second per lap. The lead may not hold. In short, the race is not going to plan.

A strategist now has only seconds to synthesize live telemetry, competitor data, weather projections, tire inventory, track position and race simulations into one call that could determine the outcome.

They do not have those seconds because they are simply fast. They have them because the entire system behind the decision was designed that way: the data architecture, simulation models, communication protocols, decision rights, scenario playbooks and feedback loops all work together to compress complexity into a clear decision window.

What if this is not just a racing story? What if it is also a blueprint for how the best enterprises will operate in the AI era?

This builds on a broader shift I’ve described as the intent-driven future of work, where enterprise work begins less with navigating systems and more with expressing outcomes, context and intent.

The AI advantage will not belong to companies with the most tools. It will belong to companies that redesign how work senses, decides, acts and learns.

AI isn’t just a faster engine

The popular story about Formula 1 is usually about speed or the quality of the driver. The fastest car with the most powerful engine with the driver with the quickest reflexes will win. But anyone who follows the sport closely knows that raw speed is only the starting point.

Every car on the track is fast. Speed gets you into the race. It does not guarantee you a win.

The teams that win consistently do so because of the quality of the system surrounding the car. They connect telemetry, simulations, strategy, engineering, pit operations, driver judgment and real-time learning into one high-performance operating model.

Every part of that operating model matters. But the best individual part alone does not win the race.

Enterprise AI strategy is at risk of making the same mistake that would keep an F1 team stuck in the middle of the pack: investing heavily in the engine while underinvesting in the entire race system.

I see enterprising investing in more copilots, more agents, more dashboards, more tools and ultimately more automation. 

The AI systems perform their tasks at unprecedented speed. But the business outcomes do not change. In many ways, AI is becoming a new operating system of work not because it replaces every application, but because it changes how intent, context, workflow and execution come together.

That is the gap many organizations are now facing. They have access to powerful AI capabilities, but they have not yet redesigned the operating model around those capabilities. The result is faster individual task execution inside disconnected systems, fragmented workflows and unclear accountability. In fact, a recent McKinsey report found that 88% use AI but two-thirds haven’t scaled it.

The next phase of AI value will not come from simply adding more AI tools. It will come from redesigning how the enterprise senses, decides, acts and learns.

The enterprise has too many disconnected signals

Most enterprises do not suffer from a lack of signals. In fact, they are everywhere across the business.

Customer intent signals, campaign performance data, product usage patterns, sales activity, support interactions, contract information, financial indicators, employee sentiment, security events and operational metrics already exist throughout an organization.

The problem is signal fragmentation.

The average knowledge worker has become the integration layer of the enterprise. They move between CRM, marketing automation, analytics dashboards, spreadsheets, collaboration tools, support systems, workflow platforms and financial reports. Then they manually assemble context that no single system provides.

They do this to answer questions that should take seconds, not hours.

• Which customer needs attention?
• Which opportunity is at risk?
• Which process is slowing down execution?
• Which signal should trigger action?
• Which decision needs human judgment?

In Formula 1 terms, this would be like a pit crew strategist having to call five different team members to gather tire degradation data, track conditions, competitor lap times, fuel load, weather forecasts and pit stop windows before making a race-defining call.

The data exists. But the latency in accessing, interpreting and acting on it makes it less valuable at the moment of decision.

That is the signal-to-action gap. And closing that gap is one of the most important opportunities in enterprise AI.

The new operating model: Sense, decide, act, learn

The AI-native enterprise needs to operate more like a Formula 1 team: continuously sensing, deciding, acting and learning.

• Sense is the foundation. It means connecting the right signals across systems, workflows, customers, employees and operations into a layer that AI can reason across. This is not just reporting on the past. It is creating the ability to understand what is happening now and anticipate what is likely to happen next.
• Decide is where AI intelligence and human judgment come together. AI can surface context, detect patterns, model options and recommend actions. Humans bring business judgment, ethical reasoning, organizational context and accountability. The quality of this partnership depends on the quality of the signals and context available to both.
• Act is where intelligence turns into execution. The goal is not another recommendation sitting in a dashboard. The goal is a workflow that triggers the right action, with the right controls, at the right time.
• Learn is where the operating model becomes a competitive advantage. Every action should generate feedback. Every outcome should improve the next recommendation. Every workflow should become smarter over time.

In Formula 1, every lap creates learning. Tire wear, track temperature, driver feedback, competitor movement and weather changes continuously reshape strategy.

The enterprise needs the same kind of learning loop.

Semantic intelligence is the missing layer

To close the signal-to-action gap, enterprises need more than data integration. They need semantic intelligence.

Semantic intelligence is what helps AI understand enterprise meaning. It connects business language, customer context, workflow relationships, policies, roles, systems and outcomes so AI can reason across the business, not just retrieve information from systems.

A customer health score is not just a number. Its meaning depends on product usage, renewal timing, support history, stakeholder engagement, commercial value, sentiment, implementation milestones and prior interventions.

A delayed workflow is not just a status update. It may signal unclear ownership, missing approvals, poor handoffs, missing context, poor data quality or a decision that needs escalation.

A sales opportunity at risk is not just a CRM field. It may reflect adoption gaps, customer sentiment, usage decline, executive sponsor changes, pricing friction, support issues or service delivery risk.

Without semantic intelligence, AI can summarize what happened. With semantic intelligence, AI can understand what matters, why it matters, who needs to act and what action is most likely to improve the outcome.

This is where enterprise AI value compounds. Foundation models will become broadly available. The model itself will not be the moat. The moat will be enterprise context, semantic intelligence, workflow intelligence, governance and learning loops.

Redesign work before automating it

There is a warning in the Formula 1 analogy that deserves attention: adding more power to a poorly designed system does not make it high performing.

The same is true for enterprise AI. Adding AI to a broken workflow does not fix the workflow. It just compounds the dysfunction.

If the data is fragmented, AI will produce incomplete recommendations confidently. If governance is disconnected from execution, AI can scale risk as quickly as it scales productivity.

The question teams ask shouldn’t be, “Where can we insert AI into this existing process?”

The better question is, “If we were designing this work from scratch, knowing what AI now makes possible, how should it operate?”

This pushes leaders to clarify where work starts, what signals matter, which decisions should be automated, where human judgment is required, what controls must be embedded, how outcomes should be measured and how the system should learn.

This is where CIOs, CTOs and technology leaders have an expanded role. AI transformation is no longer only about deploying technology. It is about redesigning how the enterprise works.

Context becomes the differentiator

In a world where every enterprise can access powerful models, context becomes the differentiator.

The winning organizations will not be the ones with the most AI tools. They will be the ones with the strongest enterprise context and the clearest path from signal to action.

That context includes customer history, product usage, workflow patterns, decision history, business rules, governance standards, risk boundaries, organizational knowledge and outcome feedback.

It also includes knowing what happened after a decision was made. Did the action improve retention? Did it accelerate a deal? Did it reduce cycle time? Did it improve customer experience? Did it create risk? Did it scale?

Without that feedback, AI remains a recommendation layer. With it, AI becomes part of a learning operating model.

This is why the most important AI investments are not always the most visible ones. Data quality, identity, access, governance, workflow integration, observability, semantic models, feedback loops and change management may not sound as exciting as the latest AI agent. But they are what allow AI to create durable enterprise value.

The CIO as architect of the race system

The CIO’s role is evolving from technology operator to architect of the enterprise race system.

That means connecting strategy, workflows, data, platforms, governance, security, talent and execution into an operating model that can move faster without losing control. The CIO’s job is no longer just to provide platforms. It is to design the conditions where intelligence can move safely and effectively through the enterprise with the right context, controls, accountability and feedback loops.

Business teams need the ability to experiment and innovate. But they need to do so within clear standards for data access, identity, security, privacy, model usage, auditability, human oversight and business accountability.

This is the balance every enterprise needs to strike: speed with control.

The future is federated innovation with centralized guardrails. It is an enterprise operating model where more people can create value with AI, but within a trusted architecture that protects the company, the customer and the quality of decisions.

The companies that pull ahead in the next decade will not be the ones that deployed AI first or assembled the largest portfolio of tools.

They will be the ones who built the enterprise equivalent of a winning Formula 1 race system: a connected operating model.

In Formula 1, the gap between the team that wins the championship and the team that finishes fourth is often measured in tenths of a second per lap. Compounded over a race distance, those tenths become decisive.

The same dynamic is emerging in enterprise AI.

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

데이터독 코리아는 9일 서울에서 기자간담회를 열고 이 같은 사업 현황과 연례 컨퍼런스 ‘대시(Dash) 2026’에서 공개한 신제품 전략을 소개했다.

엄수창 데이터독 코리아 지사장은 이를 시장 변화의 신호로 해석했다.

엄 지사장은 “연초만 해도 ‘SaaS 아포칼립스’라는 말이 나올 정도로 SaaS 기업들의 미래를 부정적으로 보는 시각이 많았다”며 “하지만 데이터독은 AI와 함께 성장하면서 오히려 큰 미래 비전을 갖게 됐다”고 말했다. 이어 “글로벌 상위 AI 기업 10곳 모두 데이터독을 사용하고 있다는 사실 자체가 시장이 우리의 성장 가능성을 높게 평가하고 있다는 방증”이라고 강조했다.

이 같은 자신감의 배경에는 AI 시대 급증하는 운영 관리 수요가 있다. 과거에는 데브옵스(DevOps)와 SRE(Site Reliability Engineering) 조직이 장애 분석과 인프라 모니터링을 위해 주로 활용했다면, 이제는 AI를 활용해 운영을 자동화하는 기능과 AI 애플리케이션 자체를 관리하는 기능까지 제공하며 AI 시대에 맞춰 사업 영역을 확대하고 있다.

정영석 데이터독 기술총괄은 올해 대시에서 공개한 100여 개의 신기능을 ‘자율 IT 운영(Autonomous Operations)’과 ‘AI 거버넌스’라는 두 가지 축으로 설명했다.

자율 IT 운영 분야에서는 ‘비츠 AI(Bits AI)’가 장애 탐지부터 원인 분석, 해결까지 자동으로 수행한다. 정 총괄은 “장애가 발생하면 비츠 AI가 8가지 안팎의 가설을 세운 뒤 하나씩 검증해 근본 원인을 찾아내고, 코드 수정안까지 PR(Pull Request) 형태로 제안한다”며 “기존에는 엔지니어가 1~2시간 걸리던 분석 및 보고서 작성 작업을 빠르면 5분 이내로 단축할 수 있다”고 설명했다.

또 인프라 자원이 부족하면 슬랙 등을 통해 운영자 승인만 받아 메모리와 CPU를 자동으로 증설하고, 사전에 정의한 가드레일 안에서는 무인 복구도 수행한다. 코드 변경부터 스테이징 배포, 프로덕션 환경에 이르기까지 애플리케이션이 의도대로 동작하는지도 AI가 지속적으로 검증한다.

AI 거버넌스 분야에서는 ▲에이전트 옵저버빌리티(Agent Observability) ▲AI 게이트웨이(AI Gateway) ▲AI 가드(AI Guard) ▲LLM 비용 관리 콘솔 등의 기능 공개했다.

에이전트 옵저버빌리티는 AI 에이전트 내부에서 어떤 LLM과 도구를 사용했고, 토큰과 비용이 얼마나 발생했는지 시각화한다. AI 게이트웨이는 여러 LLM을 통합 관리하고 감사(Audit)를 수행하며, AI 가드는 프롬프트 인젝션과 민감정보 유출을 차단한다.

정 총괄은 “코파일럿, 커서(Cursor), 클로드 등 여러 AI 모델을 함께 사용하는 기업이 늘면서 비용과 보안, 신뢰성을 통제하는 것이 C레벨 경영진의 공통 과제가 됐다”며 “개발자별, 모델별 사용량과 비용을 세분화해 보여주기 때문에 임원들도 최적화 지점을 쉽게 찾을 수 있다”고 말했다.

최근 많은 기업이 멀티 LLM 전략을 채택하는 만큼 이러한 통합 관리 플랫폼의 필요성도 커질 것이라는 설명이다.

CIO 코리아가 AI 기능 추가로 관련 비용이 늘어나는 것 아니냐고 묻자 정 총괄 “데이터독이 제공하는 수백 개의 외부 서비스 연동 기능은 모두 기본 호스트 사용료에 포함돼 있어 AI 기능이 추가됐다고 모니터링 비용이 늘어나는 것은 아니다”며 “다만 로그는 저장량이 늘어나면 비용이 증가하는 구조인데 이는 어느 벤더나 비슷하다”고 답했다.

이어 “AI가 추가됐다고 인프라 모니터링 비용이 올라가는 것은 아니지만 AI SRE처럼 자동 분석 기능을 사용할 경우 토큰(크레딧)이 소모돼 비용이 추가될 수 있다”며 “반면 엔지니어의 업무 시간을 크게 줄일 수 있기 때문에 ROI 측면에서는 충분히 상쇄할 수 있고, UI 대신 MCP(Model Context Protocol)를 활용하면 비용을 낮출 수 있어 국내 여러 대형 고객도 MCP 기반 AI옵스를 구축하고 있다”고 덧붙였다.

AI가 문제 해결책까지 제시하는 것에 대한 고객사의 거부감은 없는지 묻는 질문에는 “잘못 분석할 가능성이 있는 것은 사실이지만 지금까지 고객 반응은 매우 긍정적”이라며 “AI가 잘못 탐지하더라도 사용자가 대화를 통해 추가 분석을 요청하면 계속 수정하면서 근본 원인에 더 가까운 결과를 제시한다”고 설명했다.

이어 “이 경험은 ‘비츠 메모리(Bits Memory)’ 기능에 축적돼 이후 유사한 장애가 발생하면 더욱 정확하게 분석하도록 학습된다”고 말했다.

내부 AI는 자체 모델과 업계 최신 모델을 함께 사용하는 하이브리드 구조다.

정 총괄은 “프론티어 모델과 자체 모델인 ‘토토(Toto)’를 함께 운영하고 있으며 작업 특성에 따라 가장 적합한 모델을 선택해 사용한다”고 밝혔다. 클로드, GPT, 제미나이 등 다양한 외부 최신 모델을 활용하며, AI SRE는 내부적으로 최적 모델이 자동 선택되지만 에이전트 빌더에서는 고객이 MCP와 사용할 모델을 직접 선택할 수 있다. 또한 LLM 옵저버빌리티에서는 환각을 탐지하기 위해 교차 검증용 모델을 별도로 지정하는 기능도 제공한다.

데이터독은 앞으로 옵저버빌리티(Observability), 보안, 핀옵스(FinOps), 비즈니스 인텔리전스(BI)를 하나의 플랫폼에서 통합 제공하는 차별성을 앞세워 국내 시장 공략을 확대하겠다고 밝혔다.
jihyun.lee@foundryco.com

The hardest thing to manage is change. I wrote that line more than a decade ago in an article about the “XPocalypse,” Microsoft’s end-of-life deadline for Windows XP. My argument then was that the real crisis was not obsolete software. It was the shortage of technically literate professionals capable of guiding organizations through inevitable transitions.

More than a decade later, the names have changed. The lesson has not.

Y2K defined the pattern. The risk was real, but disaster was avoided because skilled people did the work. When nothing happened at midnight (1999-2000), many assumed the threat had been exaggerated instead of recognizing that it had been managed. Windows XP became the next version of the same problem. The operating system stayed embedded in retail, banking, healthcare, energy, law enforcement and defense systems long after it should have been retired. The vulnerability was real, but the larger lesson was mostly missed: organizations let technical debt pile up until a deadline turns it into a crisis.

Is agentic AI actually breaking the enterprise SaaS business model?

Now we have the “SaaSpocalypse.” Headlines warn that agentic AI is breaking the SaaS business model, lowering software valuations and making entire categories of enterprise tools obsolete. Investors are reacting; analysts are talking about “FOBO,” Fear of Becoming Obsolete, and organizations are again asking whether they are ready for what comes next.

The disruption is real. AI agents can now automate workflows that once required dedicated software tools and teams of human operators. The per-seat pricing model that powered two decades of SaaS economics is under pressure. But the apocalyptic framing misdiagnoses the problem. SaaS is not dying. It is bifurcating.

Platforms requiring precision, auditability, complex state management and regulatory accountability, such as financial systems, healthcare records and compliance infrastructure, will remain essential. What is collapsing is the undifferentiated middle: horizontal tools that AI agents can replicate cheaply and at scale.

The organizations most exposed are not simply those using the wrong software. They are those who outsourced technical judgment along with technical execution. They bought SaaS as a substitute for internal capability, accumulated organizational debt and now lack the human capital to navigate a transition that is fundamentally about people and process.

The old taxonomy still applies: people, process and technology. Technology serves business functions. Processes create efficiency. Qualified people sustain both. But the pace of technological change continues to outrun the education system’s ability to produce experienced professionals with current skills.

AI has widened that gap. Data engineers now design orchestration infrastructure that determines whether AI produces value or liability. Security practitioners must govern autonomous agents acting on behalf of enterprises. Business leaders need enough technical fluency to make build-versus-buy decisions in a market changing in real time.

These are not narrow technical tasks. They are the applied outputs of serious STEM education grounded in a business context, professional standards and sustained practice. We are still not producing enough people who have those skills.

How is the growing STEM education gap threatening AI leadership?

The numbers are sobering. The United States now produces fewer than 820,000 STEM graduates annually, representing about 20% of all degrees awarded. China produces approximately 3.57 million STEM graduates each year, about 40% of its university degrees. At the doctoral level, the gap is sharper. In 2000, the United States awarded 17,830 STEM PhDs, compared with China’s 7,520. By 2022, China awarded more than 50,970 STEM doctorates, over 50% more than the 33,820 awarded in the United States.

This matters directly to AI leadership. Countries building the strongest STEM pipelines today are positioning themselves to define the architecture, governance and standards of AI systems tomorrow.

How can we solve the AI talent shortage and rebuild the IT profession?

More than a decade ago, I argued that IT must be treated as a profession, not merely a resource. Finance, medicine, law, engineering and accounting all have formal professional pathways, standards and institutional support. Information technology underpins nearly every critical function of modern society, yet still lacks equivalent professional frameworks.

The AI transition makes this more urgent. As AI absorbs routine execution, the humans left in the loop must be more capable, not fewer. Their role is shifting from implementation to governance, from configuration to architecture, from maintenance to judgment. That requires better preparation, stronger incentives and professional recognition.

The United States still leads in private AI investment, but it has not matched that commitment with investment in the human capital needed to sustain it. China has embedded AI degree programs across more than 500 universities and integrated corporations directly into research and workforce pipelines. India’s AI upskilling surge is driven heavily by corporate sponsorship, with employers treating workforce education as strategic investment. The European Union has committed significant public funding to AI talent development and cross-border STEM mobility.

The United States has examples worth scaling. North Carolina’s AI Academy at NC State, built with more than 100 corporate partners, combines university credentialing with applied workplace training. North Carolina A&T, the nation’s leading producer of Black engineers, is partnering with NVIDIA and the Office of Naval Research to expand AI and cybersecurity talent. Texas has committed heavily to doctoral research infrastructure through the Texas Institute for Electronics, linking universities, government and industry around semiconductor and defense technology priorities.

These models show what a national strategy should look like: public investment, corporate sponsorship, university research capacity and continuous pathways from undergraduate study through doctoral work. But they remain exceptions. Corporate PhD fellowships from leading technology companies are valuable, but they are filters, not pipelines.

The technology sector has long harvested talent from a pipeline it does not adequately fund, then wondered why the pipeline runs short. That model is no longer sustainable. Federal and state governments must create the policy environment, including tax incentives, credentialing reform, research funding and visa frameworks, that makes corporate STEM investment structurally attractive rather than reputationally optional.

The SaaSpocalypse will pass, as Y2K and the XPocalypse passed, because capable people will do the work. The headlines will move on. The underlying shortage will remain.

What I called for in 2014 still stands: STEM education, paired with business, information management and finance, must become a sustained national infrastructure. Not as a reaction to this disruption, but as preparation for the next one.

The hardest thing to manage is change. The next is learning from it.

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

Infoblox announced today that it has entered into a definitive agreement to acquire Kentik, combining Infoblox’s authoritative DNS, DHCP, and IP address management (IPAM) data with Kentik’s network observability platform. Financial terms were not disclosed.

Kentik was founded in 2014, originally as CloudHelix before rebranding the following year, and has raised more than $100 million in venture funding to date. The platform provides real-time visibility into network traffic and ingests flow data, routing intelligence, and device telemetry across data centers, cloud environments, WANs, and the public internet. In recent years, the company has enhanced its platform with an AI advisor that helps to accelerate investigations.

Infoblox has spent more than two decades managing the DNS, DHCP, and IPAM services enterprises rely on to stay connected. In 2024, it first launched its Universal DDI SaaS platform for managing DNS, DHCP, and IP addresses from a single place, expanding in 2025 to more providers. DDI refers to the trio of core network services in IP networks: DNS, which turns domain names into IP addresses; DHCP, which assigns IP addresses to resources; and IPAM, which manages the network’s IP address infrastructure.

Infoblox and Kentik each had something the other one was missing.

“We know every device, every application across the hybrid multi cloud state, we know because we handed out the IPs, or we have acquired those assets,” Mukesh Gupta, chief product officer at Infoblox, told Network World. “We know what is on the network. We don’t know who is talking to who.”

The path to acquisition

“We’ve been talking for a few years,” Avi Freedman, co-founder and CEO of Kentik, told Network World.

Both Gupta and Freedman said the companies have discussed working together for several years, driven largely by customers who use both platforms and asked the two vendors to integrate them directly.

“We’ve gone from very internet-centric companies to some of the largest enterprises in the world, and guess who they use for all of their core sources of truth,” Freedman said. “So, our customers have been saying, hey, you have this great platform that can take all this enrichment, and we need you to be doing this kind of integration.”

For Infoblox, the situation was similar. Gupta noted that some of the problems his company was trying to solve require network flow information, which Kentik provides.

“We have a lot of common customers, and they were like, ‘Can you bring these platforms together?’” Gupta said.

What the integration will enable

The combination of the two companies’ technologies will bring more capabilities to users.

One specific example cited by Gupta has to do with the company’s Infoblox IQ, an agentic operations layer that was announced in June 2026, One of its existing capabilities, called IQ Actions, is designed to detect problems and begin investigating them automatically, before a customer notices an issue.

The system monitors DNS and DHCP metrics for anomalies, then automatically collects related data and analyzes it using large language models before an operator opens the ticket.

“We throw that data into LLMs and see if they can figure out what the root cause is, and come up with a recommendation, so all of that happens completely automatically,” Gupta said.

What Kentik would add to that workflow is flow data. Combining Infoblox’s DNS-based threat intelligence with Kentik’s flow data could extend the same kind of automatic investigation into security incidents. DNS data can identify devices communicating with a command and control server. Flow data can then show where those devices connected next inside the network.

“With flow data, we can draw that blast radius and tell customers proactively what the issue is and what the exposure is,” Gupta said.

Kentik’s own AI Advisor is moving in a similar direction, from answering direct questions to carrying out tasks on its own. The combination with DDI information will help to support that vision.

“What we’ve been working on is making it proactive, so basically operating Kentik for you, doing your networking tasks, all your planning, capacity optimization, troubleshooting,” Freedman said. 

Freedman traced that same logic back to why the deal made sense in the first place.

“We can actually build an amazing platform together, which customers are actually asking for, which is always the best way to build a business,” he said.

Apple, Samsung, and Google are all expected to introduce their takes on folding smartphones in the coming weeks. 

All three competitors work together on some things; Samsung allegedly makes displays for iPhone; Google makes an OS for Samsung; and Apple works with Google Gemini for AI. That proximity suggests that we might experience some synchronicity between these devices when they finally arrive.

Samsung and Google move first — but September belongs to Apple

Bloomberg agrees: the publication claims Samsung’s forthcoming Galaxy Unpacked event in London on July 22 will feature the Galaxy Z Fold 8, which will have a short, wide design “that resembles Apple Inc.’s planned folding iPhone.”

It is expected to cost around $1,999 for the 256GB model. The late July introduction is widely seen as an attempt to steal a little thunder from the upcoming launch of the iPhone Fold/Ultra, Apple’s first foldable device.

Google is also chasing the looming Apple thundercloud with its own “Made by Google” event in New York on Aug. 12. This is expected to be a Pixel family update, likely including a successor to the Pixel 11 Pro Fold. Leaks suggest these devices will have more RAM (for AI), more storage — with a 256GB minimum — and be priced at an estimated $1,999 – or maybe even more.

Both of these devices will be great. Both will likely be compelling; but what we don’t know yet is how the decade or so Apple has spent designing and developing its own folding smartphones will crystallize into the final result. 

A decade in development, but will it blend?

Apple has its reputation on the line – will its phone stand out for its combination of high-tech and high design, or will the company fail in its bid to stand apart? We’ll find out in September when Apple’s folding smartphone finally appears, and the oxygen once again starts circulating around this part of the room.

We do know that the iPhone Ultra has entered mass production, with MacRumors seemingly rebutting recent claims by Ming-Chi Kuo that the device might ship later than expected and be in short supply once it appears. Citing Chinese supply chain sources, the report says manufacturing has begun. Other reports indicate Apple has increased initial manufacturing orders to 10 million units. Somewhere in between the truth lies.

The iPhone Ultra is expected to be a book-style foldable with a 7.8-in. inner display and a 5.5-in. cover display, Touch ID, an Apple C2 modem and an A20 processor. It will run iOS 27, which has already been found to be capable of changing display layout and resolution to seamlessly switch between different views; moving from the outer to the inner display should seem almost instantaneous, with smooth transitions between both states. 

The hinges need to do the talking

Apple has paid particular attention to the hinge design, which is thought to be near invisible to the eye and extremely robust. (It needs to be robust; the hinge will inevitably be put to some very tough tests by hungry vlogging tech influencers everywhere.)

Those same influencers will also be putting Siri AI to the test, with most potential customers very curious about the extent to which Apple Intelligence can turn the folding iPhone into a viable replacement for Macs or iPads. What happens when you use an iPhone Ultra with an external mouse and keyboard, for example? Will competing devices match the user experience for productive tasks?

At $2,000 a pop, a lot of potential customers for any of these foldable devices will be looking for a solution that ticks more boxes than simply being a giant smartphone. They will certainly want the luxury finish we can expect in all three devices, but they will also be hoping for a tool fit for a range of use cases smartphones don’t generally meet. 

Samsung’s existing Fold range, for example, is celebrated for its advanced multitasking features and media content and consumption features, even as its ability to connect to a monitor, keyboard, and mouse (Samsung DeX) makes it a convenient PC replacement.

Resetting the high-end smartphone price point

You can expect much the same from all three devices: a focus on display resolution, color gamut, brightness and screen refresh rates. But for all three, the really critical point will be the resilience of the hinge. Because once the novelty of the fold fades, the winner will be the one that succeeds in becoming something more useful than the smartphone we already know. 

In the end, these things must deliver more, not less, if they are to persuade consumers to reset their price-driven comfort zones. All of the manufacturers have a vested interest in driving shoppers to spend even more money on their devices. 

Join me on social media at BlueSky,  LinkedIn, or Mastodon,and do please subscribe to The Core for your daily collection of human-curated Apple News lovingly assembled by yours truly.

The strangest thing about cloud strategy is how confident it looks in PowerPoint and how nervous it feels in real life.

I’ve sat in rooms where the cloud slide looked clean enough to frame. Public cloud here. Private cloud there. Hybrid for the awkward middle child. Multi-cloud for resilience, bargaining power and the faint hope that no single vendor would ever own our sleep.

Then AI arrived.

At first, it looked like another conversation about workload. Bigger compute. More storage. Faster experiments. Some awkward cost questions. Nothing we couldn’t absorb with a thicker roadmap.

Then the bills landed. The data moved in odd ways. Teams built things before governance could find its shoes. Vendors became more central than anyone had admitted.

The old cloud strategy didn’t collapse. It blushed. AI exposed the assumptions beneath it.

Now, quantum changes something deeper. It asks whether the decisions behind the workload can survive time, secrecy, suppliers, weak evidence and uncertainty.

That’s a much less comfortable meeting.

Cloud strategy was built for workloads we thought we understood

For years, cloud strategy was a sensible debate about location, cost, control and speed. Public cloud for scale. Private cloud for sensitive workloads. Hybrid cloud for compromise. Multi-cloud for resilience, negotiation or, if we’re being honest, organizational politics with a nice diagram.

The logic was sound. Move faster. Cut heavy infrastructure spend. Improve recovery. Give developers what they need before they grow old waiting for a server. It worked because the work behaved in familiar ways. Systems had owners. Costs had patterns. Data had borders, or at least we pretended it did.

The question was simple: Where should this workload live? That question still matters. But it no longer carries enough weight.

AI changed that. AI changed the pattern, not just the platform AI didn’t politely join the cloud strategy. It wandered through the house, opened every cupboard and asked why the plumbing sounded tired.

The first shock was demand.

Traditional systems consume resources in ways you can usually model. AI workloads behave differently. Training, testing, inference and data processing can spike, pause, restart and spread before anyone has agreed on who owns the meter.

Cloud cost control used to ask a billing question, “How much will we use?” AI asks an operating question: “Who is allowed to create demand, at what scale, for what purpose and with whose approval?”

The second shock was data.

AI does more than store data. It chews it, reshapes it, remembers parts of it, produces new versions of it and leaves traces in places people forget to check. Prompts, logs, embeddings, model outputs, copied files and forgotten notebooks can become quiet risk pockets.

A cloud strategy that only asks where data sits misses how data behaves.

The third shock was supplier dependency.

Many firms thought they had a cloud strategy. AI revealed they had a supplier dependency strategy wearing a cloud badge. GPUs, model platforms, managed services, specialist APIs and third-party tools became central to delivery.

AI compressed the distance between idea and exposure. A team could test, connect and release faster than governance could form a working group. I say that with affection. I’ve seen working groups age in dog years.

Cloud strategy had become a test of decision speed, risk appetite, financial discipline and data control. It now goes beyond architecture.

Then quantum changed the clock.

Quantum changes the time horizon

Quantum risk often gets dumped into the cryptography drawer. That is understandable. It is also dangerous.

The leadership issue adds time to the future of quantum computers.

Some data stolen today may still matter years from now. Some secrets age badly. Trade secrets, legal records, health data, source code, identity data and sensitive contracts don’t all expire at the same speed. Some decay like fruit. Some sit like plutonium.

That is why “harvest now, decrypt later” matters. An attacker may collect encrypted data today and wait for better tools tomorrow. You don’t need to panic. You do need to ask which data has a long secrecy life.

If your most sensitive long-lived data spans cloud platforms, SaaS services, backups, archives, collaboration tools and supplier systems, where exactly is your quantum exposure? Which encryption protects it? Who manages the keys? Which supplier has a plan? Which one has a brochure?

A brochure is a scented candle for anxious executives.

Migration also takes time. Cryptography hides everywhere. In applications. In identity systems. In network devices. In APIs. In firmware. In backup tools. In old systems, nobody wants to touch.

Quantum readiness goes beyond a weekend patch. It is discovery, classification, design, testing, contracts, funding, sequencing and proof.

The risky sentence is, “We’ll revisit this when things become clearer.”

By then, the cheap decisions may have left the building.

The real issue is decision infrastructure

AI exposed assumptions about speed, cost, data and suppliers. Quantum exposes timing, ownership, evidence and memory. Together, they point to a quieter weakness: decision infrastructure.

By decision infrastructure, I mean the system by which leaders frame risk, assign ownership, make trade-offs, record choices, track evidence and revisit assumptions when facts change. That sounds dull. Good. Dull is where serious governance lives. The glamorous stuff gets applause. The dull stuff prevents regret.

Many organizations saw the risk and still failed because too many people saw different pieces of it, and nobody owned the decision. The cloud team sees architecture. Security sees exposure. Legal sees liability. Procurement sees contract gaps. Finance sees cost drift.

The board sees amber. Amber is often where hard decisions go to nap.

This is why AI and quantum belong in the same leadership conversation. AI asks whether your cloud strategy can keep pace. Quantum asks whether it can cope with time. Both punish vague ownership.

Who owns long-term cryptographic exposure? Who can force a supplier conversation? Who accepts residual risk if migration cannot happen fast enough? Who records why a decision was made and when it must be reviewed?

Suppose those questions feel awkward, good. Awkward questions earn their rent.

The questions leaders should ask now

The board needs better questions.

Start with exposure. What protects your most sensitive systems and data? Where do you rely on supplier-managed encryption? Which systems are old, critical, poorly documented and painful to change?

Exposure is a map of assets, data, dependencies and time.

Then ask about ownership. Who owns quantum readiness across cloud, cyber, legal, procurement, privacy, resilience and the business? Who can make trade-off decisions when risk reduction competes with cost and delivery? Which risks are stuck because everyone is involved and nobody is accountable?

Awareness without ownership is just anxiety with better stationery.

Then ask about evidence. Can you show progress by system, supplier, business service and data class? Would your evidence survive a board review, a regulator’s questioning or a post-incident investigation?

Evidence built under pressure is expensive. It is also sweaty. Build the proof trail before the room gets hot.

Finally, ask about timing. Which choices must be made now because migration will take years? What event would trigger faster action? When will the board revisit the risk?

Which delay would you regret if the timeline moves faster than expected?

That last question matters. Regret is often the most honest risk metric in the room.

What a quantum-aware cloud strategy looks like

A quantum-aware cloud strategy is not a glossy side document owned by three cryptographers and a nervous intern.

It is a cloud strategy with better questions built into it:

1. Build cryptographic visibility. Start with the services that matter most. Find the encryption, certificates, protocols, keys, libraries and suppliers that protect them. Perfection can wait. Blindness cannot.
2. Classify data by secrecy life. Not just sensitivity. Time. How long must this information stay protected? A short-lived report and a long-life trade secret do not belong in the same queue.
3. Press suppliers for evidence. Ask what they are doing, what you must do and how they will prove progress. Confidence is lovely. Evidence pays the rent.
4. Rank migration by risk. Start where business value, long-life data, weak visibility and migration pain meet. Treating everything as equal is how serious work becomes theatre.
5. Change board reporting. Don’t report quantum as a foggy science project. Report decisions required, risks accepted, blockers, supplier gaps and review dates. Boards govern choices. Give them choices.
6. Build a review rhythm. Standards, tools, suppliers, threats and regulations will continue to evolve. A stale roadmap is just a risk register wearing a lab coat.

No panic. Panic burns energy and produces bad slides. The aim is readiness with owners, evidence and judgment.

The cloud question grew up

Cloud strategy began as an architecture question.

AI turned it into an operating question. Quantum turns it into a leadership question.

That is the shift.

To handle this well, organizations will need to build decision muscle early. They will know what matters, who owns it, what evidence exists, which suppliers are ready and when the next decision must be made.

But beneath cloud, AI and quantum sits the discipline leaders often avoid until pressure arrives, wearing a suit: decision quality.

AI changed the cloud bill. Quantum changes the clock.

And the clock is where risk hides.

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

La multinacional farmacéutica danesa Novo Nordisk está muy interesada en acelerar el tiempo que se tarda en lanzar medicamentos al mercado a medida que expiran las patentes. “Si tienes un medicamento superventas, un retraso de una semana puede suponer entre 10 y 100 millones de dólares”, afirma Stephanie Bova, responsable de transformación digital de la empresa. “Es una cantidad enorme, porque dispones de menos tiempo de protección mediante patente”.

La IA generativa ofrecía la posibilidad de acelerar drásticamente múltiples etapas del proceso de desarrollo de medicamentos. Y, dado que Novo Nordisk ya llevaba un seguimiento minucioso de la duración de sus procesos clave, contaba con una ventaja de la que carecían muchas otras empresas. Por lo tanto, debería haber sido relativamente sencillo incorporar un poco de IA generativa, ver cómo mejoraba la productividad y observar cómo llegaban los beneficios. Pero no fue tan fácil. El proceso de desarrollo de un fármaco consta de muchas partes, que tienen lugar en distintos momentos y en distintos departamentos. “Las personas son expertas en sus propios ámbitos, pero no necesariamente conocen el siguiente ámbito ni cómo encaja todo. El sistema es tan grande y complejo que no se puede ver todo el rendimiento de una sola vez”, afirma Bova.

Es posible que la documentación de los procesos no se corresponda con lo que la gente hace realmente en la práctica, y que diferentes personas realicen la misma tarea de formas distintas. Además, algunas tareas cruciales pueden pasar prácticamente desapercibidas desde fuera. El equipo de fabricación, por ejemplo, puede formar parte de un grupo completamente diferente y no ser consciente de que el medicamento se está preparando para su presentación ante la FDA (la agencia gubernamental estadounidense del medicamento), y que aún no tiene toda la documentación lista. “Así que has avanzado muy rápido solo para tener que esperar a que ellos te alcancen”, añade Bova.

Este es solo uno de los muchos retos a los que se enfrentan las empresas al intentar medir los resultados de los proyectos de IA, y la razón por la que las encuestas son tan contradictorias.

Si nos fijamos en las tareas individuales, Novo Nordisk puede demostrar mejoras en la productividad y claros beneficios positivos derivados del uso de la IA. Pero si damos un paso atrás y analizamos los resultados financieros de la empresa, el panorama se vuelve más confuso. En primer lugar, si se omiten pasos críticos, el tiempo de comercialización no mejorará. Además, un nuevo medicamento tarda años en llegar a los clientes, por lo que los efectos positivos en los resultados no se notarán hasta pasado un tiempo. Y eso es solo el principio del problema que plantea la medición del retorno de la inversión.

Medición de procesos

Para abordar los puntos ciegos de sus procesos, Novo Nordisk recurrió a la nueva generación de minería de procesos: gemelos digitales de las operaciones en tiempo real impulsados por IA. “Nos asociamos con la empresa de inteligencia de procesos Celonis para obtener un gemelo digital de nuestros datos de procesos. Fuimos los primeros del sector en aplicarlo al ámbito clínico”, explica Bova. La herramienta recopila información de los sistemas de la empresa para hacer un seguimiento de lo que los empleados hacen realmente, en lugar de utilizar encuestas para recabar información sobre lo que una parte de los empleados recordaba haber hecho en algún momento.

El primer proyecto consistió en un proceso sencillo de siete pasos y, al crear un gemelo digital del mismo, Novo Nordisk descubrió que, dependiendo de quién lo llevara a cabo, podía tratarse de un proceso de cinco o de nueve pasos. “Si reúnes a diez expertos en la materia en una sala, obtienes todo tipo de interpretaciones y, con el tiempo, se producen desviaciones”, cuenta.

El proyecto puso de manifiesto múltiples fallos en los procesos existentes. En algunos casos, fue necesario volver a formar a los empleados. En uno de ellos, hubo que actualizar la interfaz de usuario. Sin embargo, una vez que se estandariza un proceso, surge la oportunidad de tomar una “fotografía” de la situación anterior, de modo que haya algo con lo que comparar posteriormente y comprobar si la mejora mediante IA o la automatización arrojan algún resultado.

Otra cuestión que tuvieron que resolver de antemano fue decidir qué hacer con el tiempo ahorrado que se generara. “No quieres despedir a nadie”, afirma Bova. “Se trata de personal altamente cualificado y difícil de encontrar. Quizá deberíamos plantearnos redistribuir un poco los equipos”.

En la actualidad, la empresa cuenta con varios cientos de agentes de IA en funcionamiento, etiquetados dentro de la infraestructura del gemelo digital para poder identificarlos. “Si algo falla, sabemos exactamente dónde solucionarlo”, dice, y añade que la siguiente fase es la coordinación entre múltiples agentes. “Hoy en día, los tenemos conectados, pero no contamos con ‘agentes de agentes”.

Aún es demasiado pronto para saber si hay retorno de la inversión, ya que, en el desarrollo de fármacos, el proceso lleva años. “Pero, al analizar el proceso de principio a fin, espero que podamos recortar dos años del ciclo de desarrollo. Dos años menos hasta la comercialización, en comparación con la situación actual”»”, indica.

Los medicamentos que ya se encuentran en la fase final de desarrollo no experimentarán una aceleración tan notable, pero los que acaban de iniciarse serán los que más se beneficien. Sin embargo, los resultados finales no se verán hasta dentro de varios años.

La industria farmacéutica no es la única en la que el verdadero valor proviene de la optimización simultánea de múltiples procesos interconectados. Según PwC, los proyectos tácticos de IA a menudo no aportan un valor cuantificable, y los beneficios tangibles provienen de implementaciones a escala empresarial coherentes con la estrategia de negocio.

De hecho, muchas empresas no han experimentado ni un aumento de los ingresos ni una reducción de los costes gracias a la IA en los últimos 12 meses, a pesar de su adopción casi universal. Aun así, el gasto empresarial en IA se prevé que casi se duplique a finales de año en comparación con el año pasado, según KPMG.

Medición de la productividad

La mayoría de las empresas empiezan a pequeña escala, implantando chatbots de IA para los empleados con el fin de ayudar a mejorar la productividad. Y el ritmo de adopción en este ámbito ha sido asombrosamente alto, solo equiparado por la incapacidad de medir las ganancias de productividad que se supone que se deben alcanzar.

Disponer de una referencia es clave, afirma Anand Rao, profesor de IA en la Universidad Carnegie Mellon, de Estados Unidos, pero en algunos casos resulta difícil de medir y, en otros, es prácticamente imposible. Tomemos, por ejemplo, las decisiones relacionadas con los seguros, en las que los resultados pueden tardar años en hacerse evidentes. En el caso de los seguros de vida, podrían ser décadas, afirma. Y para algunos tipos de decisiones, las empresas no disponen de ningún tipo de indicador.

“Existe un estigma social a la hora de decir que estoy tratando de analizar tu proceso de toma de decisiones y lo bien que las estás tomando. Como seres humanos, no nos gusta que se evalúen nuestras decisiones”, señala. Luego, cuando una decisión sale bien al final, la gente se atribuye encantada el mérito. “Si la decisión sale mal, se achaca a factores externos”.

Pero incluso en el caso de tareas específicas en las que es posible realizar mediciones, las empresas a menudo no se esfuerzan por llevarlas a cabo antes de implementar herramientas de IA. “No partimos de una referencia”, apunta Julie Averill, antigua vicepresidenta ejecutiva y directora de sistemas de información global de la cadena de moda Lululemon. Averill es ahora directora general de Gold Thread, una consultora de transformación digital. “Partimos de la suposición de que la IA iba a ayudar a la gente a tomar mejores decisiones. Y eso te lleva a no poder medir bien los resultados”, explica.

Existen métricas alternativas que una empresa puede tener en cuenta en su lugar, añade, como las tasas de uso o la satisfacción de los usuarios. “Esto está ocurriendo y está aportando beneficios, algunos de los cuales se pueden ver y otros no. Hay que confiar en el proceso. Es igual que con la nube. Sabes que es el camino del futuro y puedes ver las ventajas, pero es difícil llegar hasta allí, y se requieren muchos cambios. Pero cuanto antes lo hagas, antes te habrás adaptado a la nueva forma de operar y podrás sacarle realmente partido”.

Hay otras áreas en las que es más fácil disponer de métricas concretas, como el servicio de atención al cliente. “Se trata de tareas repetitivas y suele ser el primer ámbito que las empresas automatizan con IA. Hay resultados muy tangibles que se pueden medir y se puede establecer una referencia muy sólida”, explica Averill.

Lululemon también lleva años utilizando la IA para mejorar la personalización y las recomendaciones, y esa es otra área que se puede cuantificar. Además, la automatización puede reducir la introducción manual de datos, lo que disminuye las tasas de error. La IA también se puede utilizar para ayudar en la supervisión del cumplimiento normativo, la detección de fraudes y el mantenimiento predictivo de los equipos, todos ellos casos de uso que se pueden cuantificar.

¿Pero la productividad de los empleados en general? Eso es difícil de medir, y no solo para Lululemon. Una forma obvia podría ser analizar los despidos en profesiones expuestas a la IA. Al fin y al cabo, los titulares están por todas partes. Pero en un informe publicado en marzo, Anthropic no encontró indicios de un aumento del desempleo en las profesiones altamente expuestas, aquellas en las que las personas tienen más probabilidades de ser despedidas debido a la IA.

A principios de 2025, la empresa de investigación METR intentó cuantificar la productividad de los desarrolladores comparando la rapidez con la que los desarrolladores experimentados eran capaces de realizar tareas con IA y sin ella. ¿El resultado? Los desarrolladores afirmaron que esperaban que la IA les permitiera trabajar un 24% más rápido y estimaron que, en realidad, la IA les había permitido hacerlo un 20 % más rápido. Pero los datos revelaron una realidad totalmente diferente. El uso de la IA, en realidad, les ralentizó un 19%.

Por supuesto, las herramientas de IA están mejorando. METR intentó realizar un estudio de seguimiento, comparando de nuevo las tareas realizadas con y sin IA, pero no pudo encontrar suficientes desarrolladores dispuestos a volver al enfoque sin IA, a pesar de que los investigadores les pagaban por participar en el estudio.

Existen casos anecdóticos de empresas en las que un solo ingeniero realiza el trabajo de cien gracias al uso de la IA. O aquella vez en que se filtró accidentalmente todo el código fuente de Claude Code, de medio millón de líneas, y el desarrollador coreano Sigrid Jin creó una reconstrucción desde cero en dos horas, que luego subió a GitHub, donde se convirtió en el proyecto más rápido de la historia en alcanzar las 100.000 estrellas.

Pero, como ocurre con cualquier otro tema relacionado con la IA, la realidad es más compleja. En el caso concreto del desarrollo de software, escribir el código es, en realidad, solo una pequeña parte de lo que implica desarrollar software.

La consultora DX analizó recientemente métricas clave de ingeniería de 400 empresas y, en un informe reciente, constató que el uso de la IA había aumentado un 65% desde noviembre de 2024, pero que la productividad relacionada con la IA se situaba justo por debajo del 10%.

Costes ocultos

Al igual que resulta difícil medir los beneficios de la IA en términos de productividad, también puede resultar complicado cuantificar los costes. Cuando una empresa empieza a utilizar la IA, los costes pueden ser relativamente fáciles de estimar. ¿A cuánto ascienden las cuotas mensuales totales de suscripción a los chatbots de IA que utilizan los empleados? ¿Cuál es el coste de entrenar o ajustar un modelo personalizado? Pero cuando se pasa a casos de uso más complejos, los cálculos se vuelven más difíciles, afirma Averill. “Ahora existen todos los sistemas relacionados con la IA. Esos son más difíciles de cuantificar, pero su impacto es mayor”, dice.

Por ejemplo, si la IA se integra en los procesos empresariales mediante RAG, existe el gasto continuo de las llamadas a la API, pero también los cambios que hay que realizar en otros sistemas, explica. Y la cosa se complica cada día más. “No hemos realizado un esfuerzo muy concertado para implantar la telemetría y la instrumentación”, afirma Swaminathan Chandrasekaran, director global de IA y laboratorios de datos en KPMG. Según él, obtener una visión global de los costes totales de la IA en una empresa es como predecir el tiempo.

“La razón por la que contamos con un sistema de predicción meteorológica tan impresionante en este país es que disponemos de decenas de miles de estaciones meteorológicas que recopilan datos”, explica. “Sin eso, no sabríamos qué tiempo va a hacer”.

Las empresas deben implantar sistemas de medición para evaluar todos los aspectos del consumo relacionado con la IA, señala, empezando por el número de tokens utilizados, quién los utiliza y cómo se correlaciona esto con el rendimiento laboral. “Esa medición brilla por su ausencia”, afirma.

Al menos cuando los humanos utilizan chatbots de IA, hay un límite en el número de preguntas que son físicamente capaces de formular, además de unos costes de suscripción predecibles. Y cuando los procesos empresariales se habilitan con IA a través de RAG, las llamadas a la API de los modelos de lenguaje grandes (LLM) las realizan sistemas empresariales predecibles y programados de forma tradicional.

Pero ahora, la IA agentiva está empeorando aún más las cosas, ya que los agentes pueden actuar de forma impredecible y el número de llamadas a la API puede dispararse rápidamente fuera de control. En un informe del Boston Consulting Group, dos tercios de las empresas señalan gastos de escalado de la IA incontrolables.

Otro coste que algunas empresas quizá no prevean bien, o que no controlen porque forma parte de un presupuesto diferente, es el relacionado con los datos. Ya sea preparando datos para el entrenamiento o el ajuste fino, utilizando incrustaciones de RAG o configurando el acceso directo a MCP a través de agentes, estos costes pueden acumularse rápidamente cuando entra en escena la IA.

“Las tarifas de salida son uno de los gastos más importantes”, afirma Tom Coughlin, miembro del IEEE y presidente de la consultora Coughlin Associates. “Si tienes que sacar datos de la nube, esas tarifas de salida podrían ser considerables”. Además, están todos los costes de personal que conlleva la implementación de la IA, añade.

“A largo plazo, la IA aportará un gran valor a las personas, pero estas deben saber cómo utilizarla correctamente. Si no cuentan con esas habilidades, se encontrarán en desventaja”, expone.

Soluciones y mensajes contradictorios

Luego está la cuestión de resolver los problemas. La mayoría de las empresas han sufrido al menos un incidente relacionado con la IA en los últimos 18 meses, y la mayoría de ellos han supuesto pérdidas económicas, algunas de más de 500.000 dólares. Además, está la IA que se está integrando en todo.

“Conocemos nuestros costes directos”, afirma Andrew Johnson, director de sistemas de información (CIO) de Brownstein Hyatt Farber Schreck, un bufete de abogados estadounidense. “Pero donde resulta más difícil de cuantificar es con las plataformas que ya tenemos implantadas y las aplicaciones SaaS que no contaban con capacidades de IA. Nos piden aumentos extraordinarios y los atribuyen a las nuevas capacidades que aporta la IA. ¿Cuánto se le debe atribuir a la IA? Eso es un poco difuso”, relata.

Incluso cuando la IA permite ahorrar dinero, a menudo hay costes adicionales asociados a ello. Por ejemplo, el bufete gastaba unos 70.000 dólares al año en una plataforma de gestión de contratos. Desarrollar su propia versión con IA supuso unos 40.000 dólares en costes de mano de obra y otros 3.000 dólares al año en alojamiento. El mantenimiento continuo será mínimo para esa aplicación en concreto, añade, lo que supondrá un total de otros dos mil dólares al año.

Pero también hay otros costes indirectos asociados al funcionamiento de las aplicaciones propias, como las auditorías de seguridad, las evaluaciones de vulnerabilidad, las pruebas de penetración y la revisión del código. “Cuanto más compleja y arriesgada es la plataforma, menor es el interés por intentar crear una solución interna”, indica.

Aun así, el equipo de desarrollo de software es ahora mucho más productivo gracias a la IA, ya que cuatro o cinco desarrolladores son capaces de hacer el trabajo de 20 o 30. Pero las mejoras en la productividad no se traducen en un ahorro de mano de obra, ya que los desarrolladores tienen mucho trabajo nuevo que hacer. “Tenemos una enorme lista de oportunidades pendientes para desarrollar soluciones”, afirma.

La tendencia del trabajo a expandirse para ocupar todo el tiempo disponible no se da solo en el desarrollo de software, señala Rao, de Carnegie Mellon. Supongamos, por ejemplo, que se espera que la IA suponga una mejora del 20% en la productividad, explica. “Antes había cien personas haciendo ese trabajo, y ahora solo necesitamos 80. Pero, al final del año, la plantilla no ha cambiado. «En las tareas que realizaban, hay una mejora, añade, “pero las personas añadirán tareas para suplir o complementar ese 20%. No es que se vayan a casa una hora antes, sino que están encontrando otras actividades que generan valor”.

De hecho, en algunos casos, el aumento de la productividad en una empresa puede llegar a perjudicar los resultados. Los abogados, por ejemplo, cobran por horas. “La eficiencia va en contra de nuestras formas tradicionales de ganar dinero”, afirma Johnson, de Brownstein. “Tenemos que pensar más allá de eso. No es perjudicial para nuestros intereses a largo plazo, pero supone un reto a corto plazo. Sin embargo, si no lo hacemos, es probable que no seamos competitivos a medio y largo plazo”.

Así pues, si una nueva herramienta de IA ayuda a un abogado en la diligencia debida, no existe una relación directa entre la inversión en esa herramienta y el aumento de los ingresos. “Es un hecho que la dirección es la correcta”, afirma Johnson. “Pero no podemos afirmar que vaya a generar un rendimiento concreto”.

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

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

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

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

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

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

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

Process measurement

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

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

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

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

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

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

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

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

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

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

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

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

Productivity measurement

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hidden costs

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

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

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

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

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

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

“That measurement is fundamentally lacking,” he says.

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

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

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

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

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

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

Solutions and mixed messages

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

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

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

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

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

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

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

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

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

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

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

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

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

As a medical equipment rental company that rents, sells, and manages movable medical devices, including infusion pumps, monitors, ventilators, and incubators, USME’s mission is simple in definition, but highly sophisticated in practice.

“Our job is to deliver the right equipment to the right place at the right time,” says CIO Antonio Marin. “When you look at the community we serve, the last part of the supply chain is a patient in need. So we need to make sure all our technology, processes, and everything we do has a patient in mind. After all, they call us because they need lifesaving equipment, not because it’s a beautiful day.”

A particularly vital application of technology for Marin and his team has been directed to revamping the company’s inventory and equipment management, and field services.

“We did a lot of automation behind the scenes,” he says. “Knowing your inventory, knowing what parts you need to fix, and tracking the lifecycles of inventory is all now very automated, well managed, and fully visible across the organization. It’s about humans making critical decisions, not doing paperwork.”

But with that added efficiency comes some risk. And when lives are on the line in a highly regulated sector, vulnerabilities can surface with more tech that’s introduced. So some innovations can be more detrimental to the operations of a company or a hospital.

“We use encryption and different systems to overlay protection when it comes to personal identification data,” Marin says. “When you look at the cybersecurity chain, humans are still the weakest link.”

When talking about security, particular care needs to be taken in terms of knowing exactly where the team and equipment are at all times, and tracking performance across company and hospital staff, and hospital partners.

“As a person in IT and as an employee of the company, it’s very rewarding when we’re able to deliver lifesaving equipment so hospitals can succeed in helping patients,” he says.

Marin also discusses the importance tech and human synergy, prioritizing education in regard to cybersecurity, and the power of automating processes. Watch the full video below for more insights, and be sure to subscribe to the monthly Center Stage newsletter by clicking here.

On setting the right foundations: We’re in the middle of a major transformation. The company started with a homegrown system with phenomenal software, but as we’ve grown, it becomes more complicated to keep up with the rate of progress. So we decided to move to a SaaS platform and we have the first part of the project already complete. It’s been very successful and now we’re finishing the second part.

We can look not only at our business processes and refine them, but we think about embedding AI for faster and more accurate results. You have to have sound data and processes with AI. In one of my previous companies we used AI at the beginning when it was a buzzword and not really there. I learned a very important lesson then. You can fit the model, train it, and ask a specific question, but an unexpected answer might come back. So we went back to the old ways to analyze data and realized that the answer was right but the question was wrong.

I learned you have to be open to evaluate answers and understand where the real data is coming from, and the real sentiment on the data — the context of the information you’re working with.

On human involvement: There always has to be a human in the loop. That doesn’t mean we can’t speed the process for that human. There’s incredible things we’re doing today where an AI doesn’t have to be just gen AI. There are so many variances of AI and versions of what you can do with it. For instance, we’ve been able to automate the ordering process from a single click at a hospital nurse station to our branch operations where we get all the information we need to deliver lifesaving equipment.

In one hospital in particular, we delivered a full bed and mattress in less than 15 minutes. To put that in context, industry standards are normally between 12 and 24 hours. So in certain cases when we’re in proximity, we can be extremely fast because there’s no human interaction.

On AI and model training: We created a system called GoUSME Connect. It’s a combination of RPA, AI, and machine learning that can read a request generated by an electronic medical record system. So we’re agnostic of any EMR, and it reads information. And through machine learning, it reads the pattern of the request that transfers into an order, which ends up in one of our delivery locations.

That’s one part of how we can deliver equipment. We’re working hard to continue on predictive analytics and teaching the models because as a rental company, we have so much information about the true performance of medical equipment. Our goal in the next few months is to be able to predict equipment failures based on historical data.That’s the thing about medical equipment. It’s just a new computer. They have to go through preventive maintenance once a year, and every time they come back from a hospital, they go through review process.

So we always make sure equipment is patient ready. As we all know, though, equipment can fail. But if we can gather all the equipment we’ve rented in the last 23 years and start feeding those models with all that data, then we can be more predictive.

On logistics: One of the first things is to know your inventory, what equipment you have. And in the medical equipment rental business, it could be very seasonal. You have times where you have respiratory issues, then you get neonatal seasons. So what it allows us to do is look at our past rentals, and our inventory, and then start helping the equipment management team plan their production for the next month, week, or the next day. That’s a huge change in how we used to do things to what we can do now.

From the time of getting equipment prepared to being patient ready in the old days could be like getting a call, having a technician look for the piece of equipment, and then do all the necessary paperwork and testing. Every interaction was very manual. Now we know where it’s coming from and we prepare it. If parts for a piece of equipment are needed, the parts requisition is already requested. We know where those parts are in the country, and we know we need to ship them somewhere else. So the days of doing all those things that waste time are gone.

Revised transaction structure enables immediate closing, accelerating the Company’s strategic pivot toward AI data centers, enterprise GPU compute, and digital power infrastructure.

Envirotech Vehicles, Inc. (NASDAQ: EVTV) (“EVTV” or the “Company”) today announced the successful completion of its merger with Azio AI Corporation (“Azio AI”) on July 2, 2026, paving the way for the Company to transform to an AI Datacenter Provider and meeting the growing market demand for artificial intelligence (“AI”) infrastructure, enterprise GPU compute, digital power solutions, data center development, and digital asset infrastructure; a market that the International Data Corporation (IDC) projects will reach $487 billion in global spending in 2026 and exceed $1 trillion by 2029.[1] The transaction marks a defining milestone in the Company’s strategic transformation and establishes the foundation for its next phase of commercial execution and long-term growth.

The parties amended the proposed transaction structure to expedite the closing timeline, allowing the combined company to begin operating as a fully integrated public company significantly sooner than originally anticipated. The accelerated closing enables management to immediately focus on commercialization across its expanding AI Datacenter strategy.

With the merger complete and the combined company operating as one organization, management is now fully focused on commercial execution, infrastructure deployment, strategic growth initiatives, and creating long-term shareholder value.

Over the past several months, the Company advanced development activities at its South Texas site and deployed six megawatts of off-grid power for its modular data centers. The Company further secured rights to a 548-acre site with the capacity to scale up to 500 MW, supporting the future development of AI hyperscale data centers.

Management believes these achievements demonstrate that the combined company is entering its next phase with meaningful operational momentum already in place rather than beginning from a standing start. Infrastructure deployment is underway, customer commitments have already been established, commercial execution is actively progressing, and the Company’s corporate structure is now aligned with an operating platform built to support long-term expansion.

The completion of the merger comes at a time when investment in AI infrastructure continues to accelerate globally as enterprises increasingly require access to high-performance computing resources, GPU infrastructure, and scalable digital power solutions. Management believes the combined company is well positioned to capitalize on these long-term industry trends through a diversified infrastructure strategy designed to monetize power assets across multiple complementary revenue streams, including AI data centers, enterprise compute infrastructure, power hosting, and digital asset mining operations.

Following the closing of the transaction, the Company intends to continue expanding its AI Infrastructure strategy through AI data center development, enterprise GPU compute solutions, power hosting services, digital asset mining operations, strategic infrastructure investments, and additional commercial partnerships designed to maximize utilization of its power resources while creating multiple long-term revenue opportunities.

In connection with the closing of the merger, Phillip Oldridge has stepped down as Chief Executive Officer. Jason Maddox vacates the President position and is now the Chief Financial Officer. The Company’s Board of Directors appointed Simon Yu as President and Chris Young as Chief Executive Officer, effective immediately.

Mr. Yu is a serial entrepreneur and public markets operator with almost a decade of experience taking companies public, executing capital raises, and scaling businesses. He has previously served in founder, C-suite, and board roles at three publicly traded companies, two of which reached market capitalizations in excess of $1 billion. Mr. Yu has led legal, accounting, and advisory teams through Regulation A+ Tier 2 offerings, PCAOB audits, and public company reporting, alongside leading M&A transactions. As an active early-stage venture investor, he has evaluated investment opportunities across artificial intelligence, SaaS, and B2B technology.

Mr. Young brings extensive experience in launching and leading public companies and investing in and advising emerging technology companies, with a particular focus on artificial intelligence, software innovation, and strategic growth initiatives. Prior to joining EVTV, he served as Chief Executive Officer of Clubhouse Media Group, a publicly traded social media company and an Entrepreneur in Residence at Amplify, where he worked alongside founders and venture-backed technology companies to accelerate commercialization and support the development of high-growth technology businesses.

“Today’s announcement represents far more than the completion of a merger—it marks the beginning of our next chapter,” said Chris Young, Chief Executive Officer of EVTV. “Over the past several months, our teams have been building the operational foundation of this business while simultaneously working toward completing this transaction. With the merger now finalized, we move forward as one company with one leadership team and one strategy, focused on executing against the opportunities in front of us. We believe demand for AI infrastructure, enterprise compute, and digital infrastructure will continue expanding for years to come. Our objective is to build a scalable platform capable of serving that demand while creating long-term value for our shareholders.”

Jason Maddox, Chief Financial Officer of EVTV, added, “Completing this transaction under the amended merger structure allows us to immediately focus on execution. We have already established meaningful operational momentum, and we believe operating as a unified public company enhances our ability to deploy infrastructure, serve customers, pursue strategic growth opportunities, and continue building long-term shareholder value.”

The transaction establishes a unified operating platform designed to support the Company’s long-term growth strategy through continued investment in AI infrastructure, enterprise computing, digital power assets, and digital infrastructure development. Management believes the completion of the merger provides the operational and organizational foundation necessary to pursue the next phase of commercialization while expanding its presence across some of the fastest-growing sectors of the global technology market.

Transaction and Operational Highlights

• Successfully completed the merger with Azio AI pursuant to an amended and restated merger agreement.
• Approximately six megawatts of off-grid digital infrastructure deployed at the Company’s South Texas development site.
• Development footprint exceeding 548 acres with the potential to support up to 500 MW of AI infrastructure capacity.
• Combined company positioned to accelerate commercialization across AI infrastructure, enterprise GPU compute, digital power solutions, and digital asset mining operations.
• Merger consideration consisted of 2,655,157 shares of common stock and 973,450 shares of non-voting convertible preferred stock in exchange for 100% of outstanding capital stock of Azio AI, of which 194,807 shares of common stock were reserved for convertible notes of Azio AI assumed by the Company upon closing.
• Each share of preferred stock convertible into 100 shares of Company common stock subject to stockholder approval.
• Chris Young appointed Chief Executive Officer and Chairman of the Board.
• Simon Yu appointed President.
• Jason Maddox appointed Chief Financial Officer.
• Phillip Oldridge stepped down as Chief Executive Officer.

About Envirotech Vehicles, Inc.

Envirotech Vehicles, Inc. (NASDAQ: EVTV) is a technology infrastructure company focused on developing, owning, and operating artificial intelligence data centers, enterprise GPU compute infrastructure, digital power solutions, and digital asset mining operations. Following its acquisition of Azio AI, the Company operates an integrated AI infrastructure business encompassing AI data center development, the sale and distribution of enterprise GPU systems and server infrastructure, high-performance computing solutions, power hosting, and strategic technology investments, serving enterprise and institutional customers across domestic and international markets. Through this diversified AI infrastructure strategy, the Company is positioned to capitalize on the rapidly expanding global demand for AI infrastructure, compute capacity, digital power, and next-generation AI technologies.

For more information please visit: www.azioai.ai and for potential partnerships contact: AI@PhoenixMGMTconsulting.com

Forward-Looking Statements

This press release contains forward-looking statements within the meaning of the Private Securities Litigation Reform Act of 1995. In some cases, you can identify forward-looking statements by words such as “may,” “will,” “could,” “expect,” “anticipate,” “believe,” “estimate,” “project,” “intend,” “continue,” “potential,” “ongoing,” or the negative of these terms or other comparable terminology, although not all forward-looking statements contain these words. Forward-looking statements include statements regarding the Company’s ability to capitalize on accelerating demand for AI infrastructure, enterprise GPU compute, digital power solutions, data center development, and digital asset infrastructure; the Company’s plans to continue expanding its digital infrastructure platform through AI data center development, enterprise GPU compute solutions, power hosting services, digital asset mining operations, strategic infrastructure investments, and additional commercial partnerships; the Company’s ability to maximize utilization of its power resources while creating multiple long-term revenue opportunities; the ability to continue deploying modular digital infrastructure at the Company’s South Texas site; the anticipated deployment and scaling of NVIDIA B200 and B300 GPU systems; the ability to advance and execute against the Company’s commercial infrastructure pipeline; the anticipated development of the Company’s footprint; the ability to monetize power assets across multiple complementary revenue streams, including AI data centers, enterprise compute infrastructure, power hosting, and digital asset mining operations; customer demand for AI infrastructure, enterprise compute, and digital infrastructure; the Company’s ability to build a scalable platform designed to serve that demand and create long-term shareholder value; and the Company’s broader business strategy and long-term growth objectives.

These statements are based on current expectations and assumptions that involve risks and uncertainties that could cause actual results to differ materially. Most of these factors are outside the Company’s control and are difficult to predict. Factors that may affect actual results include, but are not limited to, the Company’s limited operating history within AI infrastructure and compute operations, project scope, engineering challenges, supply chain constraints, installation timelines, energy availability, finalization of site usage rights, regulatory considerations, equipment performance, ability to raise capital required for expansion activities, changes in digital asset markets, evolving compute demand, market conditions, the Company’s ability to successfully integrate the combined business following the completion of the merger, the risk that the anticipated benefits and synergies of the merger are not realized, the risk of unexpected costs, charges, or expenses resulting from or relating to the merger, potential adverse reactions or changes to business relationships resulting from the completion of the merger, risks related to the diversion of management’s attention from ongoing business operations during the post-closing integration period, the risk that required stockholder approval for the conversion of preferred stock issued in the merger as required by rules of The Nasdaq Stock Market LLC (the “Conversion Proposal”) is not obtained, and additional risks and uncertainties described in the Company’s most recent Annual Report on Form 10-K and subsequent Quarterly Reports on Form 10-Q filed with the SEC, which are available at www.sec.gov. The Company undertakes no obligation to update forward-looking statements except as required by law.

Important Information About the Merger and Where to Find it

The Company expects to file a proxy statement with the SEC relating to the Conversion Proposal. The definitive proxy statement will be sent to all Company stockholders. Before making any voting decision, investors and security-holders of the Company are urged to read the proxy statement and all other relevant documents filed or that will be filed with the SEC in connection with the Conversion Proposal as they become available because they will contain important information about the amended and restated merger agreement between the parties and the related transactions and the Conversion Proposal to be voted upon by the Company’s stockholders. Investors and security-holders will be able to obtain free copies of the proxy statement and all other relevant documents filed or that will be filed with the SEC by the Company through the website maintained by the SEC at www.sec.gov.

Participants in the Solicitation

The Company and its directors and executive officers may be considered participants in the solicitation of proxies from EVTV’s stockholders with respect to the Conversion Proposal under the rules of the SEC. Information about the directors and executive officers of EVTV is set forth in its Annual Report on Form 10-K for the year ended December 31, 2025, which was filed with the SEC on April 13, 2026, and in subsequent Quarterly Reports on Form 10-Q and other documents filed by the Company from time to time with the SEC. Additional information regarding the persons who may be deemed participants in the proxy solicitation and a description of their direct and indirect interests, by security holdings or otherwise, will also be included in the proxy statement, and other relevant materials to be filed with the SEC when they become available. You may obtain free copies of these documents as described above.

¹ Source: International Data Corporation (IDC), “AI Infrastructure Spending Caps Historic Year at ~$90 Billion in Q4 2025; 2029 Spending to Eclipse $1 Trillion,” April 16, 2026. The Company has not independently verified the data or projections contained in this report, and there can be no assurance that the projections will be realized.

Contact

Phoenix MGMT & Consulting

Press@PhoenixMGMTConsulting.com

Revised transaction structure enables immediate closing, accelerating the Company’s strategic pivot toward AI data centers, enterprise GPU compute, and digital power infrastructure.

Envirotech Vehicles, Inc. (NASDAQ: EVTV) (“EVTV” or the “Company”) today announced the successful completion of its merger with Azio AI Corporation (“Azio AI”) on July 2, 2026, paving the way for the Company to transform to an AI Datacenter Provider and meeting the growing market demand for artificial intelligence (“AI”) infrastructure, enterprise GPU compute, digital power solutions, data center development, and digital asset infrastructure; a market that the International Data Corporation (IDC) projects will reach $487 billion in global spending in 2026 and exceed $1 trillion by 2029.[1] The transaction marks a defining milestone in the Company’s strategic transformation and establishes the foundation for its next phase of commercial execution and long-term growth.

The parties amended the proposed transaction structure to expedite the closing timeline, allowing the combined company to begin operating as a fully integrated public company significantly sooner than originally anticipated. The accelerated closing enables management to immediately focus on commercialization across its expanding AI Datacenter strategy.

With the merger complete and the combined company operating as one organization, management is now fully focused on commercial execution, infrastructure deployment, strategic growth initiatives, and creating long-term shareholder value.

Over the past several months, the Company advanced development activities at its South Texas site and deployed six megawatts of off-grid power for its modular data centers. The Company further secured rights to a 548-acre site with the capacity to scale up to 500 MW, supporting the future development of AI hyperscale data centers.

Management believes these achievements demonstrate that the combined company is entering its next phase with meaningful operational momentum already in place rather than beginning from a standing start. Infrastructure deployment is underway, customer commitments have already been established, commercial execution is actively progressing, and the Company’s corporate structure is now aligned with an operating platform built to support long-term expansion.

The completion of the merger comes at a time when investment in AI infrastructure continues to accelerate globally as enterprises increasingly require access to high-performance computing resources, GPU infrastructure, and scalable digital power solutions. Management believes the combined company is well positioned to capitalize on these long-term industry trends through a diversified infrastructure strategy designed to monetize power assets across multiple complementary revenue streams, including AI data centers, enterprise compute infrastructure, power hosting, and digital asset mining operations.

Following the closing of the transaction, the Company intends to continue expanding its AI Infrastructure strategy through AI data center development, enterprise GPU compute solutions, power hosting services, digital asset mining operations, strategic infrastructure investments, and additional commercial partnerships designed to maximize utilization of its power resources while creating multiple long-term revenue opportunities.

In connection with the closing of the merger, Phillip Oldridge has stepped down as Chief Executive Officer. Jason Maddox vacates the President position and is now the Chief Financial Officer. The Company’s Board of Directors appointed Simon Yu as President and Chris Young as Chief Executive Officer, effective immediately.

Mr. Yu is a serial entrepreneur and public markets operator with almost a decade of experience taking companies public, executing capital raises, and scaling businesses. He has previously served in founder, C-suite, and board roles at three publicly traded companies, two of which reached market capitalizations in excess of $1 billion. Mr. Yu has led legal, accounting, and advisory teams through Regulation A+ Tier 2 offerings, PCAOB audits, and public company reporting, alongside leading M&A transactions. As an active early-stage venture investor, he has evaluated investment opportunities across artificial intelligence, SaaS, and B2B technology.

Mr. Young brings extensive experience in launching and leading public companies and investing in and advising emerging technology companies, with a particular focus on artificial intelligence, software innovation, and strategic growth initiatives. Prior to joining EVTV, he served as Chief Executive Officer of Clubhouse Media Group, a publicly traded social media company and an Entrepreneur in Residence at Amplify, where he worked alongside founders and venture-backed technology companies to accelerate commercialization and support the development of high-growth technology businesses.

“Today’s announcement represents far more than the completion of a merger—it marks the beginning of our next chapter,” said Chris Young, Chief Executive Officer of EVTV. “Over the past several months, our teams have been building the operational foundation of this business while simultaneously working toward completing this transaction. With the merger now finalized, we move forward as one company with one leadership team and one strategy, focused on executing against the opportunities in front of us. We believe demand for AI infrastructure, enterprise compute, and digital infrastructure will continue expanding for years to come. Our objective is to build a scalable platform capable of serving that demand while creating long-term value for our shareholders.”

Jason Maddox, Chief Financial Officer of EVTV, added, “Completing this transaction under the amended merger structure allows us to immediately focus on execution. We have already established meaningful operational momentum, and we believe operating as a unified public company enhances our ability to deploy infrastructure, serve customers, pursue strategic growth opportunities, and continue building long-term shareholder value.”

The transaction establishes a unified operating platform designed to support the Company’s long-term growth strategy through continued investment in AI infrastructure, enterprise computing, digital power assets, and digital infrastructure development. Management believes the completion of the merger provides the operational and organizational foundation necessary to pursue the next phase of commercialization while expanding its presence across some of the fastest-growing sectors of the global technology market.

Transaction and Operational Highlights

• Successfully completed the merger with Azio AI pursuant to an amended and restated merger agreement.
• Approximately six megawatts of off-grid digital infrastructure deployed at the Company’s South Texas development site.
• Development footprint exceeding 548 acres with the potential to support up to 500 MW of AI infrastructure capacity.
• Combined company positioned to accelerate commercialization across AI infrastructure, enterprise GPU compute, digital power solutions, and digital asset mining operations.
• Merger consideration consisted of 2,655,157 shares of common stock and 973,450 shares of non-voting convertible preferred stock in exchange for 100% of outstanding capital stock of Azio AI, of which 194,807 shares of common stock were reserved for convertible notes of Azio AI assumed by the Company upon closing.
• Each share of preferred stock convertible into 100 shares of Company common stock subject to stockholder approval.
• Chris Young appointed Chief Executive Officer and Chairman of the Board.
• Simon Yu appointed President.
• Jason Maddox appointed Chief Financial Officer.
• Phillip Oldridge stepped down as Chief Executive Officer.

About Envirotech Vehicles, Inc.

Envirotech Vehicles, Inc. (NASDAQ: EVTV) is a technology infrastructure company focused on developing, owning, and operating artificial intelligence data centers, enterprise GPU compute infrastructure, digital power solutions, and digital asset mining operations. Following its acquisition of Azio AI, the Company operates an integrated AI infrastructure business encompassing AI data center development, the sale and distribution of enterprise GPU systems and server infrastructure, high-performance computing solutions, power hosting, and strategic technology investments, serving enterprise and institutional customers across domestic and international markets. Through this diversified AI infrastructure strategy, the Company is positioned to capitalize on the rapidly expanding global demand for AI infrastructure, compute capacity, digital power, and next-generation AI technologies.

For more information please visit: www.azioai.ai and for potential partnerships contact: AI@PhoenixMGMTconsulting.com

Forward-Looking Statements

This press release contains forward-looking statements within the meaning of the Private Securities Litigation Reform Act of 1995. In some cases, you can identify forward-looking statements by words such as “may,” “will,” “could,” “expect,” “anticipate,” “believe,” “estimate,” “project,” “intend,” “continue,” “potential,” “ongoing,” or the negative of these terms or other comparable terminology, although not all forward-looking statements contain these words. Forward-looking statements include statements regarding the Company’s ability to capitalize on accelerating demand for AI infrastructure, enterprise GPU compute, digital power solutions, data center development, and digital asset infrastructure; the Company’s plans to continue expanding its digital infrastructure platform through AI data center development, enterprise GPU compute solutions, power hosting services, digital asset mining operations, strategic infrastructure investments, and additional commercial partnerships; the Company’s ability to maximize utilization of its power resources while creating multiple long-term revenue opportunities; the ability to continue deploying modular digital infrastructure at the Company’s South Texas site; the anticipated deployment and scaling of NVIDIA B200 and B300 GPU systems; the ability to advance and execute against the Company’s commercial infrastructure pipeline; the anticipated development of the Company’s footprint; the ability to monetize power assets across multiple complementary revenue streams, including AI data centers, enterprise compute infrastructure, power hosting, and digital asset mining operations; customer demand for AI infrastructure, enterprise compute, and digital infrastructure; the Company’s ability to build a scalable platform designed to serve that demand and create long-term shareholder value; and the Company’s broader business strategy and long-term growth objectives.

These statements are based on current expectations and assumptions that involve risks and uncertainties that could cause actual results to differ materially. Most of these factors are outside the Company’s control and are difficult to predict. Factors that may affect actual results include, but are not limited to, the Company’s limited operating history within AI infrastructure and compute operations, project scope, engineering challenges, supply chain constraints, installation timelines, energy availability, finalization of site usage rights, regulatory considerations, equipment performance, ability to raise capital required for expansion activities, changes in digital asset markets, evolving compute demand, market conditions, the Company’s ability to successfully integrate the combined business following the completion of the merger, the risk that the anticipated benefits and synergies of the merger are not realized, the risk of unexpected costs, charges, or expenses resulting from or relating to the merger, potential adverse reactions or changes to business relationships resulting from the completion of the merger, risks related to the diversion of management’s attention from ongoing business operations during the post-closing integration period, the risk that required stockholder approval for the conversion of preferred stock issued in the merger as required by rules of The Nasdaq Stock Market LLC (the “Conversion Proposal”) is not obtained, and additional risks and uncertainties described in the Company’s most recent Annual Report on Form 10-K and subsequent Quarterly Reports on Form 10-Q filed with the SEC, which are available at www.sec.gov. The Company undertakes no obligation to update forward-looking statements except as required by law.

Important Information About the Merger and Where to Find it

The Company expects to file a proxy statement with the SEC relating to the Conversion Proposal. The definitive proxy statement will be sent to all Company stockholders. Before making any voting decision, investors and security-holders of the Company are urged to read the proxy statement and all other relevant documents filed or that will be filed with the SEC in connection with the Conversion Proposal as they become available because they will contain important information about the amended and restated merger agreement between the parties and the related transactions and the Conversion Proposal to be voted upon by the Company’s stockholders. Investors and security-holders will be able to obtain free copies of the proxy statement and all other relevant documents filed or that will be filed with the SEC by the Company through the website maintained by the SEC at www.sec.gov.

Participants in the Solicitation

The Company and its directors and executive officers may be considered participants in the solicitation of proxies from EVTV’s stockholders with respect to the Conversion Proposal under the rules of the SEC. Information about the directors and executive officers of EVTV is set forth in its Annual Report on Form 10-K for the year ended December 31, 2025, which was filed with the SEC on April 13, 2026, and in subsequent Quarterly Reports on Form 10-Q and other documents filed by the Company from time to time with the SEC. Additional information regarding the persons who may be deemed participants in the proxy solicitation and a description of their direct and indirect interests, by security holdings or otherwise, will also be included in the proxy statement, and other relevant materials to be filed with the SEC when they become available. You may obtain free copies of these documents as described above.

¹ Source: International Data Corporation (IDC), “AI Infrastructure Spending Caps Historic Year at ~$90 Billion in Q4 2025; 2029 Spending to Eclipse $1 Trillion,” April 16, 2026. The Company has not independently verified the data or projections contained in this report, and there can be no assurance that the projections will be realized.

Contact

Phoenix MGMT & Consulting

Press@PhoenixMGMTConsulting.com

Revised transaction structure enables immediate closing, accelerating the Company’s strategic pivot toward AI data centers, enterprise GPU compute, and digital power infrastructure.

Envirotech Vehicles, Inc. (NASDAQ: EVTV) (“EVTV” or the “Company”) today announced the successful completion of its merger with Azio AI Corporation (“Azio AI”) on July 2, 2026, paving the way for the Company to transform to an AI Datacenter Provider and meeting the growing market demand for artificial intelligence (“AI”) infrastructure, enterprise GPU compute, digital power solutions, data center development, and digital asset infrastructure; a market that the International Data Corporation (IDC) projects will reach $487 billion in global spending in 2026 and exceed $1 trillion by 2029.[1] The transaction marks a defining milestone in the Company’s strategic transformation and establishes the foundation for its next phase of commercial execution and long-term growth.

The parties amended the proposed transaction structure to expedite the closing timeline, allowing the combined company to begin operating as a fully integrated public company significantly sooner than originally anticipated. The accelerated closing enables management to immediately focus on commercialization across its expanding AI Datacenter strategy.

With the merger complete and the combined company operating as one organization, management is now fully focused on commercial execution, infrastructure deployment, strategic growth initiatives, and creating long-term shareholder value.

Over the past several months, the Company advanced development activities at its South Texas site and deployed six megawatts of off-grid power for its modular data centers. The Company further secured rights to a 548-acre site with the capacity to scale up to 500 MW, supporting the future development of AI hyperscale data centers.

Management believes these achievements demonstrate that the combined company is entering its next phase with meaningful operational momentum already in place rather than beginning from a standing start. Infrastructure deployment is underway, customer commitments have already been established, commercial execution is actively progressing, and the Company’s corporate structure is now aligned with an operating platform built to support long-term expansion.

The completion of the merger comes at a time when investment in AI infrastructure continues to accelerate globally as enterprises increasingly require access to high-performance computing resources, GPU infrastructure, and scalable digital power solutions. Management believes the combined company is well positioned to capitalize on these long-term industry trends through a diversified infrastructure strategy designed to monetize power assets across multiple complementary revenue streams, including AI data centers, enterprise compute infrastructure, power hosting, and digital asset mining operations.

Following the closing of the transaction, the Company intends to continue expanding its AI Infrastructure strategy through AI data center development, enterprise GPU compute solutions, power hosting services, digital asset mining operations, strategic infrastructure investments, and additional commercial partnerships designed to maximize utilization of its power resources while creating multiple long-term revenue opportunities.

In connection with the closing of the merger, Phillip Oldridge has stepped down as Chief Executive Officer. Jason Maddox vacates the President position and is now the Chief Financial Officer. The Company’s Board of Directors appointed Simon Yu as President and Chris Young as Chief Executive Officer, effective immediately.

Mr. Yu is a serial entrepreneur and public markets operator with almost a decade of experience taking companies public, executing capital raises, and scaling businesses. He has previously served in founder, C-suite, and board roles at three publicly traded companies, two of which reached market capitalizations in excess of $1 billion. Mr. Yu has led legal, accounting, and advisory teams through Regulation A+ Tier 2 offerings, PCAOB audits, and public company reporting, alongside leading M&A transactions. As an active early-stage venture investor, he has evaluated investment opportunities across artificial intelligence, SaaS, and B2B technology.

Mr. Young brings extensive experience in launching and leading public companies and investing in and advising emerging technology companies, with a particular focus on artificial intelligence, software innovation, and strategic growth initiatives. Prior to joining EVTV, he served as Chief Executive Officer of Clubhouse Media Group, a publicly traded social media company and an Entrepreneur in Residence at Amplify, where he worked alongside founders and venture-backed technology companies to accelerate commercialization and support the development of high-growth technology businesses.

“Today’s announcement represents far more than the completion of a merger—it marks the beginning of our next chapter,” said Chris Young, Chief Executive Officer of EVTV. “Over the past several months, our teams have been building the operational foundation of this business while simultaneously working toward completing this transaction. With the merger now finalized, we move forward as one company with one leadership team and one strategy, focused on executing against the opportunities in front of us. We believe demand for AI infrastructure, enterprise compute, and digital infrastructure will continue expanding for years to come. Our objective is to build a scalable platform capable of serving that demand while creating long-term value for our shareholders.”

Jason Maddox, Chief Financial Officer of EVTV, added, “Completing this transaction under the amended merger structure allows us to immediately focus on execution. We have already established meaningful operational momentum, and we believe operating as a unified public company enhances our ability to deploy infrastructure, serve customers, pursue strategic growth opportunities, and continue building long-term shareholder value.”

The transaction establishes a unified operating platform designed to support the Company’s long-term growth strategy through continued investment in AI infrastructure, enterprise computing, digital power assets, and digital infrastructure development. Management believes the completion of the merger provides the operational and organizational foundation necessary to pursue the next phase of commercialization while expanding its presence across some of the fastest-growing sectors of the global technology market.

Transaction and Operational Highlights

• Successfully completed the merger with Azio AI pursuant to an amended and restated merger agreement.
• Approximately six megawatts of off-grid digital infrastructure deployed at the Company’s South Texas development site.
• Development footprint exceeding 548 acres with the potential to support up to 500 MW of AI infrastructure capacity.
• Combined company positioned to accelerate commercialization across AI infrastructure, enterprise GPU compute, digital power solutions, and digital asset mining operations.
• Merger consideration consisted of 2,655,157 shares of common stock and 973,450 shares of non-voting convertible preferred stock in exchange for 100% of outstanding capital stock of Azio AI, of which 194,807 shares of common stock were reserved for convertible notes of Azio AI assumed by the Company upon closing.
• Each share of preferred stock convertible into 100 shares of Company common stock subject to stockholder approval.
• Chris Young appointed Chief Executive Officer and Chairman of the Board.
• Simon Yu appointed President.
• Jason Maddox appointed Chief Financial Officer.
• Phillip Oldridge stepped down as Chief Executive Officer.

About Envirotech Vehicles, Inc.

Envirotech Vehicles, Inc. (NASDAQ: EVTV) is a technology infrastructure company focused on developing, owning, and operating artificial intelligence data centers, enterprise GPU compute infrastructure, digital power solutions, and digital asset mining operations. Following its acquisition of Azio AI, the Company operates an integrated AI infrastructure business encompassing AI data center development, the sale and distribution of enterprise GPU systems and server infrastructure, high-performance computing solutions, power hosting, and strategic technology investments, serving enterprise and institutional customers across domestic and international markets. Through this diversified AI infrastructure strategy, the Company is positioned to capitalize on the rapidly expanding global demand for AI infrastructure, compute capacity, digital power, and next-generation AI technologies.

For more information please visit: www.azioai.ai and for potential partnerships contact: AI@PhoenixMGMTconsulting.com

Forward-Looking Statements

This press release contains forward-looking statements within the meaning of the Private Securities Litigation Reform Act of 1995. In some cases, you can identify forward-looking statements by words such as “may,” “will,” “could,” “expect,” “anticipate,” “believe,” “estimate,” “project,” “intend,” “continue,” “potential,” “ongoing,” or the negative of these terms or other comparable terminology, although not all forward-looking statements contain these words. Forward-looking statements include statements regarding the Company’s ability to capitalize on accelerating demand for AI infrastructure, enterprise GPU compute, digital power solutions, data center development, and digital asset infrastructure; the Company’s plans to continue expanding its digital infrastructure platform through AI data center development, enterprise GPU compute solutions, power hosting services, digital asset mining operations, strategic infrastructure investments, and additional commercial partnerships; the Company’s ability to maximize utilization of its power resources while creating multiple long-term revenue opportunities; the ability to continue deploying modular digital infrastructure at the Company’s South Texas site; the anticipated deployment and scaling of NVIDIA B200 and B300 GPU systems; the ability to advance and execute against the Company’s commercial infrastructure pipeline; the anticipated development of the Company’s footprint; the ability to monetize power assets across multiple complementary revenue streams, including AI data centers, enterprise compute infrastructure, power hosting, and digital asset mining operations; customer demand for AI infrastructure, enterprise compute, and digital infrastructure; the Company’s ability to build a scalable platform designed to serve that demand and create long-term shareholder value; and the Company’s broader business strategy and long-term growth objectives.

These statements are based on current expectations and assumptions that involve risks and uncertainties that could cause actual results to differ materially. Most of these factors are outside the Company’s control and are difficult to predict. Factors that may affect actual results include, but are not limited to, the Company’s limited operating history within AI infrastructure and compute operations, project scope, engineering challenges, supply chain constraints, installation timelines, energy availability, finalization of site usage rights, regulatory considerations, equipment performance, ability to raise capital required for expansion activities, changes in digital asset markets, evolving compute demand, market conditions, the Company’s ability to successfully integrate the combined business following the completion of the merger, the risk that the anticipated benefits and synergies of the merger are not realized, the risk of unexpected costs, charges, or expenses resulting from or relating to the merger, potential adverse reactions or changes to business relationships resulting from the completion of the merger, risks related to the diversion of management’s attention from ongoing business operations during the post-closing integration period, the risk that required stockholder approval for the conversion of preferred stock issued in the merger as required by rules of The Nasdaq Stock Market LLC (the “Conversion Proposal”) is not obtained, and additional risks and uncertainties described in the Company’s most recent Annual Report on Form 10-K and subsequent Quarterly Reports on Form 10-Q filed with the SEC, which are available at www.sec.gov. The Company undertakes no obligation to update forward-looking statements except as required by law.

Important Information About the Merger and Where to Find it

The Company expects to file a proxy statement with the SEC relating to the Conversion Proposal. The definitive proxy statement will be sent to all Company stockholders. Before making any voting decision, investors and security-holders of the Company are urged to read the proxy statement and all other relevant documents filed or that will be filed with the SEC in connection with the Conversion Proposal as they become available because they will contain important information about the amended and restated merger agreement between the parties and the related transactions and the Conversion Proposal to be voted upon by the Company’s stockholders. Investors and security-holders will be able to obtain free copies of the proxy statement and all other relevant documents filed or that will be filed with the SEC by the Company through the website maintained by the SEC at www.sec.gov.

Participants in the Solicitation

The Company and its directors and executive officers may be considered participants in the solicitation of proxies from EVTV’s stockholders with respect to the Conversion Proposal under the rules of the SEC. Information about the directors and executive officers of EVTV is set forth in its Annual Report on Form 10-K for the year ended December 31, 2025, which was filed with the SEC on April 13, 2026, and in subsequent Quarterly Reports on Form 10-Q and other documents filed by the Company from time to time with the SEC. Additional information regarding the persons who may be deemed participants in the proxy solicitation and a description of their direct and indirect interests, by security holdings or otherwise, will also be included in the proxy statement, and other relevant materials to be filed with the SEC when they become available. You may obtain free copies of these documents as described above.

¹ Source: International Data Corporation (IDC), “AI Infrastructure Spending Caps Historic Year at ~$90 Billion in Q4 2025; 2029 Spending to Eclipse $1 Trillion,” April 16, 2026. The Company has not independently verified the data or projections contained in this report, and there can be no assurance that the projections will be realized.

Contact

Phoenix MGMT & Consulting

Press@PhoenixMGMTConsulting.com

Revised transaction structure enables immediate closing, accelerating the Company’s strategic pivot toward AI data centers, enterprise GPU compute, and digital power infrastructure.

Envirotech Vehicles, Inc. (NASDAQ: EVTV) (“EVTV” or the “Company”) today announced the successful completion of its merger with Azio AI Corporation (“Azio AI”) on July 2, 2026, paving the way for the Company to transform to an AI Datacenter Provider and meeting the growing market demand for artificial intelligence (“AI”) infrastructure, enterprise GPU compute, digital power solutions, data center development, and digital asset infrastructure; a market that the International Data Corporation (IDC) projects will reach $487 billion in global spending in 2026 and exceed $1 trillion by 2029.[1] The transaction marks a defining milestone in the Company’s strategic transformation and establishes the foundation for its next phase of commercial execution and long-term growth.

The parties amended the proposed transaction structure to expedite the closing timeline, allowing the combined company to begin operating as a fully integrated public company significantly sooner than originally anticipated. The accelerated closing enables management to immediately focus on commercialization across its expanding AI Datacenter strategy.

With the merger complete and the combined company operating as one organization, management is now fully focused on commercial execution, infrastructure deployment, strategic growth initiatives, and creating long-term shareholder value.

Over the past several months, the Company advanced development activities at its South Texas site and deployed six megawatts of off-grid power for its modular data centers. The Company further secured rights to a 548-acre site with the capacity to scale up to 500 MW, supporting the future development of AI hyperscale data centers.

Management believes these achievements demonstrate that the combined company is entering its next phase with meaningful operational momentum already in place rather than beginning from a standing start. Infrastructure deployment is underway, customer commitments have already been established, commercial execution is actively progressing, and the Company’s corporate structure is now aligned with an operating platform built to support long-term expansion.

The completion of the merger comes at a time when investment in AI infrastructure continues to accelerate globally as enterprises increasingly require access to high-performance computing resources, GPU infrastructure, and scalable digital power solutions. Management believes the combined company is well positioned to capitalize on these long-term industry trends through a diversified infrastructure strategy designed to monetize power assets across multiple complementary revenue streams, including AI data centers, enterprise compute infrastructure, power hosting, and digital asset mining operations.

Following the closing of the transaction, the Company intends to continue expanding its AI Infrastructure strategy through AI data center development, enterprise GPU compute solutions, power hosting services, digital asset mining operations, strategic infrastructure investments, and additional commercial partnerships designed to maximize utilization of its power resources while creating multiple long-term revenue opportunities.

In connection with the closing of the merger, Phillip Oldridge has stepped down as Chief Executive Officer. Jason Maddox vacates the President position and is now the Chief Financial Officer. The Company’s Board of Directors appointed Simon Yu as President and Chris Young as Chief Executive Officer, effective immediately.

Mr. Yu is a serial entrepreneur and public markets operator with almost a decade of experience taking companies public, executing capital raises, and scaling businesses. He has previously served in founder, C-suite, and board roles at three publicly traded companies, two of which reached market capitalizations in excess of $1 billion. Mr. Yu has led legal, accounting, and advisory teams through Regulation A+ Tier 2 offerings, PCAOB audits, and public company reporting, alongside leading M&A transactions. As an active early-stage venture investor, he has evaluated investment opportunities across artificial intelligence, SaaS, and B2B technology.

Mr. Young brings extensive experience in launching and leading public companies and investing in and advising emerging technology companies, with a particular focus on artificial intelligence, software innovation, and strategic growth initiatives. Prior to joining EVTV, he served as Chief Executive Officer of Clubhouse Media Group, a publicly traded social media company and an Entrepreneur in Residence at Amplify, where he worked alongside founders and venture-backed technology companies to accelerate commercialization and support the development of high-growth technology businesses.

“Today’s announcement represents far more than the completion of a merger—it marks the beginning of our next chapter,” said Chris Young, Chief Executive Officer of EVTV. “Over the past several months, our teams have been building the operational foundation of this business while simultaneously working toward completing this transaction. With the merger now finalized, we move forward as one company with one leadership team and one strategy, focused on executing against the opportunities in front of us. We believe demand for AI infrastructure, enterprise compute, and digital infrastructure will continue expanding for years to come. Our objective is to build a scalable platform capable of serving that demand while creating long-term value for our shareholders.”

Jason Maddox, Chief Financial Officer of EVTV, added, “Completing this transaction under the amended merger structure allows us to immediately focus on execution. We have already established meaningful operational momentum, and we believe operating as a unified public company enhances our ability to deploy infrastructure, serve customers, pursue strategic growth opportunities, and continue building long-term shareholder value.”

The transaction establishes a unified operating platform designed to support the Company’s long-term growth strategy through continued investment in AI infrastructure, enterprise computing, digital power assets, and digital infrastructure development. Management believes the completion of the merger provides the operational and organizational foundation necessary to pursue the next phase of commercialization while expanding its presence across some of the fastest-growing sectors of the global technology market.

Transaction and Operational Highlights

• Successfully completed the merger with Azio AI pursuant to an amended and restated merger agreement.
• Approximately six megawatts of off-grid digital infrastructure deployed at the Company’s South Texas development site.
• Development footprint exceeding 548 acres with the potential to support up to 500 MW of AI infrastructure capacity.
• Combined company positioned to accelerate commercialization across AI infrastructure, enterprise GPU compute, digital power solutions, and digital asset mining operations.
• Merger consideration consisted of 2,655,157 shares of common stock and 973,450 shares of non-voting convertible preferred stock in exchange for 100% of outstanding capital stock of Azio AI, of which 194,807 shares of common stock were reserved for convertible notes of Azio AI assumed by the Company upon closing.
• Each share of preferred stock convertible into 100 shares of Company common stock subject to stockholder approval.
• Chris Young appointed Chief Executive Officer and Chairman of the Board.
• Simon Yu appointed President.
• Jason Maddox appointed Chief Financial Officer.
• Phillip Oldridge stepped down as Chief Executive Officer.

About Envirotech Vehicles, Inc.

Envirotech Vehicles, Inc. (NASDAQ: EVTV) is a technology infrastructure company focused on developing, owning, and operating artificial intelligence data centers, enterprise GPU compute infrastructure, digital power solutions, and digital asset mining operations. Following its acquisition of Azio AI, the Company operates an integrated AI infrastructure business encompassing AI data center development, the sale and distribution of enterprise GPU systems and server infrastructure, high-performance computing solutions, power hosting, and strategic technology investments, serving enterprise and institutional customers across domestic and international markets. Through this diversified AI infrastructure strategy, the Company is positioned to capitalize on the rapidly expanding global demand for AI infrastructure, compute capacity, digital power, and next-generation AI technologies.

For more information please visit: www.azioai.ai and for potential partnerships contact: AI@PhoenixMGMTconsulting.com

Forward-Looking Statements

This press release contains forward-looking statements within the meaning of the Private Securities Litigation Reform Act of 1995. In some cases, you can identify forward-looking statements by words such as “may,” “will,” “could,” “expect,” “anticipate,” “believe,” “estimate,” “project,” “intend,” “continue,” “potential,” “ongoing,” or the negative of these terms or other comparable terminology, although not all forward-looking statements contain these words. Forward-looking statements include statements regarding the Company’s ability to capitalize on accelerating demand for AI infrastructure, enterprise GPU compute, digital power solutions, data center development, and digital asset infrastructure; the Company’s plans to continue expanding its digital infrastructure platform through AI data center development, enterprise GPU compute solutions, power hosting services, digital asset mining operations, strategic infrastructure investments, and additional commercial partnerships; the Company’s ability to maximize utilization of its power resources while creating multiple long-term revenue opportunities; the ability to continue deploying modular digital infrastructure at the Company’s South Texas site; the anticipated deployment and scaling of NVIDIA B200 and B300 GPU systems; the ability to advance and execute against the Company’s commercial infrastructure pipeline; the anticipated development of the Company’s footprint; the ability to monetize power assets across multiple complementary revenue streams, including AI data centers, enterprise compute infrastructure, power hosting, and digital asset mining operations; customer demand for AI infrastructure, enterprise compute, and digital infrastructure; the Company’s ability to build a scalable platform designed to serve that demand and create long-term shareholder value; and the Company’s broader business strategy and long-term growth objectives.

These statements are based on current expectations and assumptions that involve risks and uncertainties that could cause actual results to differ materially. Most of these factors are outside the Company’s control and are difficult to predict. Factors that may affect actual results include, but are not limited to, the Company’s limited operating history within AI infrastructure and compute operations, project scope, engineering challenges, supply chain constraints, installation timelines, energy availability, finalization of site usage rights, regulatory considerations, equipment performance, ability to raise capital required for expansion activities, changes in digital asset markets, evolving compute demand, market conditions, the Company’s ability to successfully integrate the combined business following the completion of the merger, the risk that the anticipated benefits and synergies of the merger are not realized, the risk of unexpected costs, charges, or expenses resulting from or relating to the merger, potential adverse reactions or changes to business relationships resulting from the completion of the merger, risks related to the diversion of management’s attention from ongoing business operations during the post-closing integration period, the risk that required stockholder approval for the conversion of preferred stock issued in the merger as required by rules of The Nasdaq Stock Market LLC (the “Conversion Proposal”) is not obtained, and additional risks and uncertainties described in the Company’s most recent Annual Report on Form 10-K and subsequent Quarterly Reports on Form 10-Q filed with the SEC, which are available at www.sec.gov. The Company undertakes no obligation to update forward-looking statements except as required by law.

Important Information About the Merger and Where to Find it

The Company expects to file a proxy statement with the SEC relating to the Conversion Proposal. The definitive proxy statement will be sent to all Company stockholders. Before making any voting decision, investors and security-holders of the Company are urged to read the proxy statement and all other relevant documents filed or that will be filed with the SEC in connection with the Conversion Proposal as they become available because they will contain important information about the amended and restated merger agreement between the parties and the related transactions and the Conversion Proposal to be voted upon by the Company’s stockholders. Investors and security-holders will be able to obtain free copies of the proxy statement and all other relevant documents filed or that will be filed with the SEC by the Company through the website maintained by the SEC at www.sec.gov.

Participants in the Solicitation

The Company and its directors and executive officers may be considered participants in the solicitation of proxies from EVTV’s stockholders with respect to the Conversion Proposal under the rules of the SEC. Information about the directors and executive officers of EVTV is set forth in its Annual Report on Form 10-K for the year ended December 31, 2025, which was filed with the SEC on April 13, 2026, and in subsequent Quarterly Reports on Form 10-Q and other documents filed by the Company from time to time with the SEC. Additional information regarding the persons who may be deemed participants in the proxy solicitation and a description of their direct and indirect interests, by security holdings or otherwise, will also be included in the proxy statement, and other relevant materials to be filed with the SEC when they become available. You may obtain free copies of these documents as described above.

¹ Source: International Data Corporation (IDC), “AI Infrastructure Spending Caps Historic Year at ~$90 Billion in Q4 2025; 2029 Spending to Eclipse $1 Trillion,” April 16, 2026. The Company has not independently verified the data or projections contained in this report, and there can be no assurance that the projections will be realized.

Contact

Phoenix MGMT & Consulting

Press@PhoenixMGMTConsulting.com

When I started evaluating browser agents, most of the conversation around me focused on multimodal models, computer-use systems and screenshot-based automation. Almost every framework I evaluated assumed agents needed to perceive the web the way humans do, visually, pixel by pixel.

The more time I spent shipping agents against real web applications, the more I became convinced we were solving the wrong problem. AI agents would stall on checkout forms because a button had no ARIA role. They would waste seconds and thousands of tokens taking screenshots to figure out what was on the screen.

The problem was never the Agent. It was that we kept treating the web as a visual surface, even though it already has a machine-readable interface. We have had one for decades. It is called the accessibility tree.

The web already has a machine interface

Most developers think of accessibility as a feature for people. Technically, accessibility required the web platform to solve a deeper problem: Exposing interfaces in a machine-readable form. Long before AI agents existed, screen readers were already consuming the web through a structured semantic representation of roles, labels, states and relationships. There was no pixel interpretation and no screenshot.

That’s not adjacent to what AI agents need. That is what AI agents need. Long before LLMs existed, assistive technologies proved the core thesis: Machines can navigate interfaces, semantics can outlive presentation and structure can substitute for vision. Screenshot-based agents spend tokens rediscovering facts the browser already knows. The accessibility tree already contains role, name and state in structured form. In my own agent work, switching from screenshot-based to DOM-native execution cut per-action latency from 2–5 seconds to under 500ms and token cost by an order of magnitude.

Accessibility proved the thesis. Now we need the next layer

The most clarifying realization I had was this: Accessibility had already solved a large portion of the problem agents face. Accessibility gives machines a way to discover interfaces. It exposes available controls, their names, their states and their relationships. But discovery is not execution. The accessibility tree can identify a button named “Checkout” and indicate whether it is disabled. What it cannot provide is a contract for the action itself. For example, what inputs it accepts, what preconditions are required and what state changes it produces.

One emerging response to this gap is WebMCP, which introduces a browser-native way to expose typed capabilities that agents can invoke directly. When a form field has no explicit agent annotation, Chrome’s declarative API derives the parameter description from the associated element first. It falls back to aria-description if no label exists. The same HTML that accessibility has required developers to write correctly for thirty years is now the primary input to your agent tool contract. A colleague put it well: “If we had done a good job with accessibility, we should get this for free.”

The frontend patterns that break both

Modern component architectures actively degrade the semantic quality that accessibility and agents both depend on. When a design system wraps a native button in a custom component, what reaches the DOM is often a div with generated class names and no semantic role. The accessibility tree gets “generic” instead of “button.” Under WebMCP’s declarative API, a form field with no label has no parameter description for the browser to inherit. Either way, the agent has nothing to work with.

Beyond div soup, virtualized lists only render visible rows, making out-of-viewport content completely unreachable. Client state that updates visually but never updates ARIA attributes leaves agents acting on stale snapshots. The common thread is that accessibility was treated as a concern for human users only, and the semantic layer got quietly destroyed in the abstraction. That’s now a double failure.

Designing for determinism

Humans can tolerate ambiguous UI. Agents cannot. Every point of ambiguity is a probability distribution over possible actions, and probability distributions can produce wrong actions at scale.

For frontend teams thinking about this now, there are three places to start.

1. Make state visible. Every piece of client state that affects whether an action is available should be reflected in the accessibility tree, not just rendered visually. If your cart count updates in a state store but the button’s aria-label doesn’t update with it, an agent is operating on stale information. ARIA synchronization isn’t an enhancement; it’s part of the interface contract.
2. Make identifiers stable. CSS modules and build-time hashing produce class names that change on every deploy and are meaningless as selectors. A data attribute convention with stable, human-readable identifiers—such as checkout.submit_order gives agent runtimes something to target that survives refactors, redesigns and framework migrations. I have added a lint rule that fails the build when interactive elements are missing one.
3. Make actions explicit. Today, what an element does lives entirely in JavaScript, opaque to any outside observer. The direction WebMCP points toward, and what I would encourage teams to start thinking about now, is exposing action intent alongside UI semantics: What an action is called, what inputs it accepts, what preconditions it requires and what effects it produces. Even without a formal protocol, a consistent schema gives agent runtimes something to reason about rather than infer.

I have started thinking of agent operability as a strict superset of accessibility. Tools like axe-core already catch a meaningful share of agent failures because they validate the semantic layer agents depend on. The WebMCP team’s proposed Lighthouse audit for the agentic web is the natural next layer.

The completion of work already started

HTML gave us a machine-readable structure. ARIA and the Accessibility Object Model gave us machine-readable meaning. What agents need next is machine-readable capability: Not just what a control is, but what it does, under what conditions and with what effect.

Teams that invested in accessibility did not just build more inclusive products. They also built the closest thing to agent-compatible UIs on the web. WebMCP makes that inheritance explicit: Labels become parameter descriptions, ARIA metadata becomes agent metadata and semantic structure becomes the foundation for machine execution.

Assistive technologies proved the thesis decades ago: Machines can navigate interfaces, semantics can outlive presentation and structure can substitute for vision. This isn’t a new protocol. It is the completion of work that ARIA and the Accessibility Object Model started – turning machine-readable descriptions into contracts that agents can execute against reliably.

.

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

Existing security controls weren’t designed for AI agents.

Static credentials and standing privileges aren’t sufficient for an emerging model where organizations need to rapidly authorize, limit, and revoke permissions from autonomous agents, sometimes more than once within a single workflow.

Agentic AI requires organizations to carefully consider how to govern agentic identity, agent-to-agent communication, secrets management, privileged access, and workforce identity.

Agentic identity

The first challenge is to establish a reliable identity for agents themselves.

The “how” here is still being hotly debated. Some organizations treat AI agents as another form of non-human identity, similar to service accounts or machine identities. Others argue that agents should be their own category, distinct from both human users and machine accounts.

In any case, agents need something like a “certificate” to give them an identity that can be recognized and governed across environments. This is especially important because, in most enterprises, agents will operate across multiple environments, including cloud platforms, on-premises systems, and SaaS applications. 

Agent-to-agent communication

Securing agentic AI requires organizations to limit not only which resources AI agents can access, but also which other access-enabled agents they can communicate with. This is often currently handled with Model Context Protocol (MCP) gateways, although this approach is largely giving way to the use of agentic mesh.

An agentic mesh is a distributed architecture where multiple specialized AI agents can discover one another, coordinate, and collaborate on tasks without a central controller. This approach lets organizations overlay intent-based communication rules via certificates, but also allows permissions to be revoked on demand.

Agentic secrets

Traditionally, secrets like passwords and API keys are managed via requests through IT service management platforms. But this mechanism doesn’t work for AI agents, which operate too quickly and across too many systems to rely on static credentials.

Instead, secrets should be generated dynamically, used for a specific purpose, and then retired when the task is complete. This approach can be compared to modern hotel key cards. Unlike the physical room keys of the past, a key card is issued for a specific stay, but after that, it becomes worthless to both legitimate users and malicious actors.

Privileged access

AI agents may start with the same permissions as a given human user, drawing on relevant business systems and data for context. However, as workflows get handed off from agent to agent, this privilege should not be passed along throughout the process. Rather, privileges should be whittled down at each stage until only a thin layer remains to authorize a specific execution step.

Workforce identity

Organizations already manage the identities of human workers, of course, but often these identities are handled differently across separate management platforms and sign-on tools. To support agentic AI, organizations must find ways to break through this fragmentation, ensure that worker identities are current, and translate workforce permissions correctly into agentic workflows.

A lifecycle approach to identity

These five areas should not be addressed in isolation. Rather, organizations should apply governance and observability across the identity lifecycle, ensuring that every agentic action can ultimately be traced back to approved access and permission levels.

The outcomes of this effort—including dynamic access, the principle of least privilege, strong identity, and clear auditability—are goals that many organizations have long been pursuing. The rise of agentic AI makes them more urgent than ever.

To learn more, visit us here.

Higher education has consolidated its entire academic operation into a handful of massive SaaS platforms. The LMS manages instruction, grading and communication. The SIS owns enrollment, records and financial aid. Identity and productivity live in a small number of cloud providers. These are not peripheral tools — they are the operational infrastructure of the institution. As IT stewards, we manage platforms we do not own, cannot restore ourselves and cannot directly control — which makes contingency planning not optional, but fundamental to the role.

The contracts are in place. The SLAs are signed. The compliance certifications are current. None of that matters to a student who cannot reach her instructor three days before finals. None of it matters to a faculty member who has no roster, no grade book and no way to document the work his students submitted before the platform went dark. SLAs govern vendor response timelines. Keeping academic operations running during that response window is IT’s responsibility.

The disruption hit during finals week 2026, and I was doing what every CIO in higher education was doing — monitoring. A major learning management system had been breached. The disruption spread fast. Finals were canceled. Exams were postponed. Students and staff were stranded without access to coursework, rosters or grade books. The costs — in academic disruption, extended contracts, emergency response — were substantial and widely reported. My institution was not directly impacted. But watching peer institutions in my own state go dark during the highest-stakes moment of the academic calendar was not reassuring. It was a confirmation of something I had been thinking about for a long time.

The disruption proved something IT professionals have relearned in every decade of their careers. Mark Twain observed that history does not repeat itself, but it does rhyme. This is a verse we have heard before: Dependence on a single point of failure, without a tested contingency plan, is not a strategy — it is a risk that has simply not yet been called. Whether the failure comes from a cyberattack, a vendor outage, an infrastructure collapse or a cloud provider’s bad deployment, the result is the same. The institution stops. And no SLA, contract or compliance certification prevents that moment from arriving.

Vigilance is not optional. Technologies are evolving faster than any IT team can fully anticipate. New platforms, new integrations, new dependencies emerge constantly — and with each one comes a new potential failure point. That is not an argument against adopting new technology. It is an argument for the one principle that never becomes obsolete: Reliance on any single critical system, whether it is a connectivity provider, an identity platform or a SaaS solution, is a proven strategy for failure. The question is never whether that system will fail. The question is whether the institution is prepared when it does.

Single points of failure fail — inevitably, and at the worst possible time. IT professionals have known this for thirty years. The SaaS layer is not exempt.

This is not a new lesson. Azure has gone down. AWS has failed. Google Workspace has had outages that took organizations dark globally. No campus runs a single ISP connection — we provision redundant circuits, preferably from independent providers, because we learned long ago that the connection will sometimes fail and the institution cannot afford to stop when it does. Financial services, government and multinational enterprises applied that same logic to every dependency in their stack. Their response to platform risk was not to demand better SLAs. It was to architect around the dependency. Redundancy. Failover. Independent continuity capability. The massive disruptions from Canvas demonstrate that effective contingency solutions for these critical platforms have not kept pace with our dependence on them. We cannot get fooled again.

That omission is what made the 2026 attack so damaging. Not the sophistication of the breach — the entry point was a peripheral free-tier environment that wasn’t even within the vendor’s primary certification scope. The damage was catastrophic because institutions had no fallback. Faculty had no rosters. Administrators had no enrollment data. There was no continuity layer. A single point of failure, at institutional scale, with no plan for when it fails.

And now the economics have shifted in the worst possible direction. PowerSchool paid a ransom in December 2024 after attackers stole data on 60 million students — and was re-extorted anyway, with individual school districts receiving separate demands months later using the same stolen data. Instructure’s CEO publicly confirmed the extortion payment. Anyone who has paid a ransom only to be hit a second time at double the cost can tell you — paying the attackers resolves nothing and instead invites more attacks. The sector has now proven twice, publicly, and at scale, that it will pay. That changes the threat calculus entirely. Higher education stops being a target of opportunity and becomes a target of strategy. Criminal groups share that intelligence. Banner serves over 1,400 institutions. Blackboard reaches tens of millions of users across thousands of campuses. Every major higher education SaaS platform is now on active threat actor priority lists — not because they are newly vulnerable, but because the sector has proven it will pay, that academic calendar pressure creates maximum leverage, and that IT has not yet built the operational alternative that our dependence on these platforms demands — and therefore the failure is ours to own, especially if we allow it to happen a second time.

The sector has proven it will pay. Every ransomware group operating today just received the same market signal. What follows is not unpredictable — it is documented, underway and aimed directly at the platforms carrying your institution’s academic operations.

As a CIO, my approach to this is not a spreadsheet or a stack of printed reports. IT is responsible for identifying critical failure points and countering them — that is not optional; it is the job. Accepting failure as inevitable without a mitigation strategy is not viable. Redundancy and continuity solutions are standard practice everywhere else in our infrastructure. There was no reason the SaaS layer should be different.

A leader’s first job isn’t to be right — it’s to be responsible.

The solution I implemented is a secure, read-only, centralized repository — a continuity strategy that ensures students, staff and faculty can continue to function whether the issue is a power outage, a cyberattack or a SaaS platform going dark. It is not a replacement for Canvas or Banner. It is the independent fallback that allows the institution to keep operating while the primary system is restored. I have learned the hard way that accepting failure without a plan is not a posture any CIO can defend.

Watching the frustration across the industry during and after the 2026 attack — institutions paralyzed, peer CIOs improvising, faculty working from personal spreadsheets, boards asking questions no one could answer — the logic of extending this capability to other institutions became unavoidable. The solution is not complex. The architecture is straightforward. The discipline behind it is thirty years old. The discipline is established. The responsibility to apply it is our field of expertise in IT.

To be precise about scope: An ACR does not prevent vendor breaches, replace cyber insurance or remove notification obligations. When an incident hits, legal counsel, security teams and institutional leadership still manage the response. What the ACR changes is what they have to work with — a governed, auditable record of what data was accessed, what manual actions were taken and how operations continued while the vendor worked to restore service.

Redundancy, disaster recovery, continuity of operations — the discipline is not new. The SaaS platforms carrying academic operations deserve the same standard we hold everywhere else.

The solution to this problem exists. A SaaS third-party continuity of operations strategy requires an independent data layer — one the institution controls, synchronized on a regular scheduled cycle from source systems, and accessible when those systems are not. Platform-agnostic across Canvas, Banner, Blackboard and PowerSchool. Read-only by design. Auditable by requirement. Independent by architecture. That last word is the one that matters — independent of the platforms whose availability you cannot guarantee.

Every CIO in higher education knows what a single point of failure looks like. Every one of us has built around them at every other layer. Servers, networks, data centers — we do not accept the single-point risk, and we do not wait for the failure to motivate the fix. The SaaS layer is not an exception.

The question is not whether your institution will face it. The question is whether you will have a continuity strategy in place when it arrives — or be explaining to your board why you did not.

Leaders don’t rent accountability — they own it outright.

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

SAP가 AI 전환에 필요한 재원을 마련하기 위해 채용과 출장 비용을 줄인다.

블룸버그에 따르면 SAP는 최근 사내 이메일을 통해 “장기적인 성공에 핵심적인 AI 직무를 중심으로 일부 직군에 한해서만 신규 채용을 진행할 것”이라고 직원들에게 공지했다.

또 AI 개발과 직접 관련된 경우를 제외한 내부 출장을 중단하고, 협력업체 관련 비용을 포함한 다른 지출을 줄이는 방안도 검토하고 있다고 밝혔다.

SAP 대변인은 CIO.com에 이 같은 내용을 확인하며 “SAP는 고객에게 장기적인 가치와 혁신을 제공할 수 있는 분야에 자원을 집중하기 위해 투자 현황을 지속적으로 점검하고 있다”라며 “이러한 방침에 따라 AI 관련 역량과 인재, 기술에 대한 투자를 우선하는 한편, 채용과 외부 지출, 내부 출장은 더욱 엄격하게 관리하고 있다. 고객 대상 활동과 핵심 AI 프로젝트는 기존과 동일하게 전폭적으로 지원할 것”이라고 설명했다.

이번 조치는 AI 전략을 한층 강화하려는 SAP의 행보를 보여주는 사례로 볼 수 있다. 여기에는 SAP의 AI 디지털 비서 ‘쥴(Joule)’에 대한 투자 확대도 포함된다. 앞서 지난 주 SAP CEO 크리스티안 클라인은 대부분의 AI 개발 조직을 직접 총괄하는 역할을 맡았다. 지난 3월에는 영업, 구축, 서비스, 지원 조직의 관리 권한을 현재 최고고객책임자(CCO)를 맡고 있는 토마스 자우어에시히 이사회 멤버가 이끄는 고객가치그룹(Customer Value Group)으로 이관한 바 있다.

고객이 체감할 수 있는 가치가 중요

컨설팅 기업 인포테크리서치 그룹(Info-Tech Research Group)의 수석 리서치 디렉터 테라 히긴슨은 SAP가 AI 도입을 확대해 회사의 전략을 뒷받침하고 투자 효과를 입증해야 하는 상황이지만, “고객은 추가 예산을 투입하거나 운영 우선순위를 높이기 전에 AI가 어떤 가치를 제공하는지 보다 명확한 근거를 확인하기를 원한다”라고 말했다.

히긴슨은 SAP 역시 다른 소프트웨어 기업들과 마찬가지로 여러 압박에 직면해 있다고 분석했다. SaaS 기업의 시장 가치는 이전 호황기보다 여전히 크게 낮은 수준이며, AI는 구축과 운영, 확장에 많은 비용이 들어간다. 반면 AI가 얼마나 실질적인 수익을 가져다줄지는 아직 불확실하다.

히긴슨은 “지금은 비용을 공격적으로 늘릴 시기가 아니다”라며 “SAP는 경쟁 우위를 분명히 확보할 수 있는 분야에 집중적으로 투자해야 한다. AI 디지털 비서 쥴은 지금까지 기대에 미치지 못했지만, SAP는 사용자들에게 이를 적극 활성화하도록 독려하고 있는 것으로 알고 있다. 이런 점이 현실적인 긴장을 만들어내고 있다”라고 평가했다.

AI가 바꾸는 인력 구조

AI는 SAP가 2024년 구조조정 당시와 같은 대규모 감원을 피하려는 전략에도 영향을 미치고 있다. 뉴욕타임스에 따르면 SAP는 새로운 AI 기술을 활용해 직원들이 보다 높은 가치를 창출하는 새로운 역할을 만들어내도록 장려하고 있다.

또한 클라인 CEO는 머지않은 미래에 인력이 줄어드는 것이 아니라 지금과는 전혀 다른 형태의 인력 구성이 될 것으로 내다봤다. 그는 2~3년 뒤에도 사람이 직접 소프트웨어 코드를 작성하는 일이 남아 있을지 확신할 수 없다고 밝혔다.

또 다른 컨설팅 기업 무어인사이트앤드스트래티지(Moor Insights & Strategy)의 부사장이자 수석 애널리스트인 제이슨 앤더슨은 직원들이 AI를 적극 활용하면 일상적인 업무 방식 자체가 달라진다고 설명했다. 예를 들어 소프트웨어 엔지니어는 코딩에 쓰던 시간이 줄어들면서 보안 점검이나 테스트 업무에 더 많은 시간을 투입하고 있다는 것이다.

앤더슨은 “하지만 이러한 업무 재배분은 아직 해결되지 않은 가장 큰 과제”라며 “미래의 업무 환경에 대한 논의와 그것이 현재 근로자에게 어떤 의미를 갖는지를 연결하는 핵심 고리가 아직 부족하다. 여기에 적어도 세 가지 요인이 당분간 이러한 변화의 정착을 어렵게 만들 것”이라고 말했다.

구체적으로 앤더슨은 AI가 업무 방식을 바꾸는 과정에서 해결해야 할 과제로 세 가지를 제시했다.

첫째, 현재 AI는 개인의 생산성을 높이는 데는 효과적이지만 팀 단위 협업을 지원하는 수준에는 아직 이르지 못했다.

둘째, AI 덕분에 과거에는 할 수 없었던 업무까지 수행할 수 있게 되면서 생산성이 크게 향상될 것이라는 기대가 있지만, 그런 업무 자체가 충분한 사업적 필요성을 갖추지 못한 경우도 적지 않다고 지적했다. 결국 AI로 확보한 생산성을 새로운 업무에 활용할 것인지, 아니면 단순히 비용과 예산을 줄이는 데 사용할 것인지가 기업의 과제로 남아 있다고 설명했다.

셋째, AI가 가져올 변화는 몇 달이나 몇 분기가 아니라 수년, 나아가 수십 년에 걸쳐 나타날 것이라고 전망했다. 자동화가 장기적으로는 오히려 일자리를 늘린다는 연구 결과를 고려하면, AI가 일자리를 변화시키더라도 결국 노동시장은 새로운 균형을 찾아갈 것이라고 내다봤다.

앤더슨은 SAP를 비롯한 기업들이 장기적인 경쟁력을 유지하기 위해 이러한 변화에 대응하는 것은 불가피하다고 평가했다. 다만 “단기적으로는 앞으로 나아가기 위해 많은 기업이 조직과 비용을 줄여야 할 것이며, 이는 영향을 받는 직원들에게는 결코 위로가 되지 않을 것”이라고 말했다.
dl-ciokorea@foundryco.com

Wanan Wanan – shutterstock.com

Microsoft-CEO Satya Nadella sorgte kürzlich für Aufsehen, als er prognostizierte, dass traditionelle Enterprise-Anwendungen im Zeitalter der agentischen KI „kollabieren” würden. Die Befürchtungen vieler Anleger, dass AI-Agenten den Markt für Unternehmenssoftware erschüttern werden, spitzten sich Anfang Februar zu, als die Veröffentlichung von Anthropic Cowork einen massiven Ausverkauf von Software-Aktien auslöste.

Ist die „SaaS-pocalypse“ lediglich ein Phänomen der Wall Street, oder hat sie auch Auswirkungen auf CIOs? Ist die Rhetorik „SaaS ist tot“ realistisch, oder ist sie maßlos übertrieben? Wir haben Branchenbeobachter befragt, womit sie rechnen.

Etablierte Lieferanten sind im Vorteil

Branchenausblick: Die aktuellen Marktführer werden ihre Dominanz auf absehbare Zeit ausüben, indem sie KI-Agenten in ihre Plattformen integrieren.

Forrester-Analystin Kate Leggett hat eine klare Meinung zur Zukunft des Softwaremarktes: „Es gibt einmal die Bewertungen von Investoren und dann gibt es die Realität, was in großen Unternehmen tatsächlich geschieht und in welchem Zeitrahmen Veränderungen stattfinden werden.“ Kernanwendungen würden so schnell nicht verschwinden, erklärt sie gegenüber unserer US-Schwesterpublikation CIO.com, auch wenn es an den Rändern zur Erosion komme. In welchem Zeitrahmen? „Es könnte Jahrzehnte dauern, bis alle Ausgaben vollständig von KI-Agenten übernommen werden.“

Abonnieren Sie unserer CIO-Newsletter für mehr Analysen, Hintergründe und Deep Dives für die CIO-Community.

IT-Experte William Flaiz fügt hinzu: „Auf Führungsebene werden keine Entscheidungen getroffen, CRM-Systeme komplett abzuschaffen.“ Allerdings hätten CIOs in Unternehmen einen starken Anreiz, agentische KI in bestehende Plattformen zu integrieren, um mehr Wert aus ihren Investitionen herauszuholen. „Sie suchen nach Möglichkeiten, mit den ihnen zur Verfügung stehenden Tools bessere Ergebnisse zu erzielen“, sagt Flaiz.

„Hinsichtlich des Ausmaßes der Umwälzungen gibt es viel Schwarz-Weiß-Denken“, berichtet Alex Demeule, Senior Analyst bei Technology Business Review Inc. (TBRI). „Natürlich wird KI einen großen Einfluss auf Softwareanbieter haben. Aber in den kommenden fünf bis zehn Jahren sind sie viel besser positioniert für den Sprung ins KI-Zeitalter, als es der Aktienkurs vermuten lässt.“ Seine Prognose lautet, dass Agentic AI nur langsam eingeführt wird und Menschen noch viele Jahre lang eine Rolle spielen werden.

Agentic AI wird Preismodelle revolutionieren

Branchenausblick: Agentische KI wird einen grundlegenden Wandel von Abo-basierenden hin zu verbrauchs- oder ergebnisorientierten Preismodellen auslösen.

Dana Gardner, Präsident und Chefanalyst bei Interarbor Solutions, ist der Ansicht, dass es kurz- bis mittelfristig weniger darum geht, bestehende Software-Systeme komplett zu ersetzen. Vielmehr stehe das Ende der Preismacht ihrer Lieferanten bevor. „Versierte CIOs werden KI nutzen, um die Gesamtkosten der IT zu senken.” Schließlich seien KI-Agenten in der Lage, Verbrauchs- und Nutzungsmuster von Business-Applikationen zu verstehen. CIOs können diese Erkenntnisse in günstigere Verträge umsetzen.

In einem Bericht über die Auswirkungen von KI auf den SaaS-Markt schreibt die Unternehmensberatung Bain & Co.: „Wenn ein AI Agent eine menschliche Aufgabe ersetzt, erwarten Kunden, dass sie auf Basis der Ergebnisse bezahlen und nicht nach der Anzahl der Anmeldungen. Marktführer wie Intercom und Salesforce bewegen sich bereits in diese Richtung. Der grundlegende Wandel besteht darin, nicht mehr für den Zugriff, sondern für die geleistete Arbeit zu berechnen.“

Auch die Marktbeobachter von IDC stellen im Report „FutureScape: Worldwide Agentic AI 2026 Predictions“ fest, dass eine rein auf Nutzerlizenzen basierende Preisgestaltung bis 2028 überholt sein wird. So würden 70 Prozent der Softwareanbieter demnach ihre Preisstrategien auf neue Wertkennzahlen wie Verbrauch, Ergebnisse oder organisatorische Fähigkeiten umstellen.

Laut Forrester-Analystin Leggett werde sich die Abkehr von Abo-Preisen auf verschiedene Weise vollziehen. So könnte ein CIO, der ein Abonnement für 100 Lizenzen hat, beispielsweise 10 oder 20 dieser Lizenzen gegen eine nutzungs- oder ergebnisbasierte Abrechnung umtauschen. Lieferanten würden voraussichtlich Lizenzstufen oder flexible Optionen mit einer Art agentenbasierter Preisgestaltung anbieten.

Softwareplattformen werden fusionieren und neue Rivalitäten schaffen

Branchenausblick: Da KI-Agenten nicht unterscheiden, woher die Daten stammen, werden die Grenzen zwischen traditionellen Kategorien der Unternehmenssoftware wie CRM und ERP verschwimmen.

Um effektiv zu arbeiten, benötigen KI-Agenten Zugriff auf Daten, unabhängig davon, wo diese gespeichert sind. SaaS-Anbieter haben das erkannt und heben die Grenzen zwischen CRM, ERP, IT-Service-Management und anderen Kategorien auf. Leggett weist beispielsweise darauf hin, dass Lieferanten wie Oracle und Microsoft einheitliche Datenplattformen aufbauen. Diese lassen sich via Model Context Protocol (MCP) integrieren, um komplexe KI-basierte Workflows zu unterstützen.

• Oracle bietet eine integrierte Suite aus cloudbasierten ERP- und CRM-Anwendungen sowie eine vollständig verwaltete agentenbasierte Plattform an.
• Microsoft offeriert unter dem Dach von Dynamics 365 sowohl ERP- als auch CRM-Funktionalitäten, ebenso wie branchenspezifische Lösungen auf Basis kleiner Sprachmodelle (SLMs), die schlanker und kostengünstiger sind als LLMs.
• SAP integriert seine Signavio-Suite für Geschäftsprozess-Management, sein LeanIX-SaaS-Tool für Unternehmensarchitektur-Management sowie seinen Joule-AI-Agenten zu einem einheitlichen System.
• Salesforce führt sein Mulesoft-Angebot für Integration und Automatisierung als Platform-as-a-Service mit seiner Data360-Kundendatenplattform und seiner Agentforce-AI-Plattform zusammen.
• Das IT-Service-Management-Schwergewicht ServiceNow hat die Übernahme des Anbieters der agentischen KI-Plattform Moveworks abgeschlossen und Salesforce im CRM-Bereich herausgefordert.

Gewinner und Verlierer im Software-Sektor

Branchenausblick: Agentic AI wird erhebliche Auswirkungen auf Anbieter von Einzelprodukten haben. Anbieter mit generischen Apps müssen kämpfen, während Lieferanten beispielsweise branchenspezifischer Tools besser aufgestellt sind.

Laut Analystin Leggett von Forrester werden Einzelprodukte wie Workflow-, Tabellenkalkulations- oder einfache Projektmanagement-Apps „in relativ kurzer Zeit verschwinden“, da sie leicht nachzubilden sind. Stark vertikalisierte Apps seien besser vor Disruption geschützt, da sie tiefgreifendes Fachwissen und Integrationen mit angrenzenden Systemen, beispielsweise aus den Bereichen CAD oder medizinische Bildgebung, bieten. Beispiele hierfür sind Epic und Cerner für das Management elektronischer Patientenakten (EHR), IQVIA für Pharmazie und Biowissenschaften oder Procore im Bauwesen.

Laut Leggett verfügen die großen Anbieter von CRM-Plattformen über eingebaute Vorteile: einen Schutzwall um ihre Daten, branchenspezifisches Wissen und Workflows, tiefe Partnernetzwerke, bewährte Branchen-Practices sowie Fachwissen in regulatorischen Feldern. Demeule von TBRI weist zudem darauf hin, dass etablierte Anbieter gerade deshalb langfristig Bestand haben, weil sie sich bei jeder Disruptionswelle erfolgreich neu ausrichten konnten – sei es beim Übergang von On-Premises-Lösungen zur Cloud oder bei der Umstellung von unbefristeten Lizenzen auf Abonnements.

Vibe-Coding als Disruptor spezifischer Segmente

Branchenausblick: Vibe-Coding könnte die Vormachtstellung der SaaS-Anbieter ins Wanken bringen und Endnutzern die Möglichkeit geben, ihre eigenen Agenten zu erstellen.

Vibe-Coding, also KI-Agenten zu verwenden, um Software auf Basis einfacher Eingaben in natürlicher Sprache zu erstellen, hebt die Low-Code- und No-Code-Bewegung auf eine neue Stufe. Mithilfe von Vibe-Coding können Software-Anwender KI-Dienste nutzen, um eine Produktivitäts-App zu erstellen, die über die Grenzen einer traditionellen CRM- oder ERP-Plattform hinausgeht.

Laut Leggett stellt Vibe-Coding eine echte Bedrohung dar, da es Arbeitnehmern potenziell ermöglicht, produktiver zu sein. So ließen sich traditionelle Plattformen für Enterprise-Software umgehen, auch weil sie von vielen Nutzern als aufgebläht und kompliziert angesehen werden.

Unternehmen, die technologisch rückständig sind, verfügen möglicherweise nicht über die Fähigkeiten oder das Selbstvertrauen, eigene Agenten zu entwickeln und einzusetzen, die geschäftskritische Arbeitsabläufe beeinflussen. „Vibe-Coding als punktuelle Lösung betrachten wir als disruptiv”, sagt Demeule. „Geschäftsmodelle für kleine, isolierte Lösungen geraten durch AI-Agenten in große Gefahr. Wer aber komplexe, unternehmenskritische Infrastrukturen managt, der ist aktuell sicher, weil KI diese Komplexität noch nicht beherrscht.“

Eine agentische Orchestrierungsschicht entsteht

Branchenausblick: Es wird weiterhin herkömmliche SaaS-Anwendungen geben, doch diese werden voraussichtlich hinter einer agentischen Orchestrierungsschicht verborgen sein.

Analysten sind sich einig, dass die Benutzeroberfläche der Zukunft nicht die herkömmliche SaaS-Lösung, sondern agentisch sein wird, während das CRM- oder ERP-System in den Hintergrund tritt. IDC-Analyst Bo Lykkegaard erläutert den Trend: „Komplexität ist die Achillesferse des SaaS-Modells. Jede SaaS-Anwendung erfordert eine eigene Lernkurve und Benutzeroberfläche, was bei sporadischer Nutzung schnell zu Ineffizienzen führt.“

KI biete hier eine überzeugende Lösung: Anstatt durch mehrere Dashboards zu navigieren, könnten Nutzer mit agentengesteuerten, dialogorientierten Schnittstellen interagieren, die systemübergreifend Aufgaben ausführen. Das Ergebnis? „KI als eine neue Schnittstellenschicht, die Komplexität abstrahiert, repetitive Prozesse automatisiert und neu definiert, wie Menschen Software nutzen.“ Die entscheidende Frage für die kommenden Jahre: Werden CIOs diese Funktionalität von ihren aktuellen Software-Lieferanten oder von Disruptoren wie OpenAI, Anthropic und Palantir beziehen? (ajf/jd)