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?

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

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

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

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

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

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

#2. Distinguish between human and autonomous agent behavior 

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

#3. Establish guardrails for automated package updates on endpoints

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

#4. Enforce principle of least privilege for AI agents

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

#5. Maintain continuous endpoint posture management

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

Summary

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

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

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.”

Atos has launched a new sovereign cloud platform aimed squarely at European public sector bodies, healthcare providers and defense organizations. It’s the latest effort by European companies in their fight back against US dominance.

Atos Sovereign Cloud offers a range of controls for data management, providing customers with resilience and full control over their data, complying with existing European legislation on data residency.

“Digital sovereignty has become a global operational priority for organizations that need to manage dependencies, jurisdictional exposure and disruption risks across complex digital environments. Atos Sovereign Cloud gives customers a practical way to apply sovereign controls to their most critical workloads, while preserving flexibility, resilience and the ability to innovate securely,” said Michael Kollar, Atos Group digital sovereignty leader.

There has been a concerted effort by European organizations to meet US competition head-on. Earlier this month, four companies signed up to the certification program introduced by the European cloud body, CISPE,

This is the latest effort by Atos to get the company back on track. In April, it sold its supercomputer company, Bull to the French government, after a previous attempt in 2024 to sell off its computer services division and after a refinancing deal in the same year.

The company implemented a further round of refinancing this year and in its half-yearly report claimed that this was an “important milestone” in securing the company’s future. However, in its first-quarter results revenue showed an organic decline of 11 percent, so any projected growth may be some time in the future. Whether its Sovereign Cloud offering is the harbinger of the revival remains to be seen.

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.

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

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

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

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

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

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

#2. Distinguish between human and autonomous agent behavior 

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

#3. Establish guardrails for automated package updates on endpoints

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

#4. Enforce principle of least privilege for AI agents

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

#5. Maintain continuous endpoint posture management

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

Summary

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

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

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?

Atos has launched a new sovereign cloud platform aimed squarely at European public sector bodies, healthcare providers and defense organizations. It’s the latest effort by European companies in their fight back against US dominance.

Atos Sovereign Cloud offers a range of controls for data management, providing customers with resilience and full control over their data, complying with existing European legislation on data residency.

“Digital sovereignty has become a global operational priority for organizations that need to manage dependencies, jurisdictional exposure and disruption risks across complex digital environments. Atos Sovereign Cloud gives customers a practical way to apply sovereign controls to their most critical workloads, while preserving flexibility, resilience and the ability to innovate securely,” said Michael Kollar, Atos Group digital sovereignty leader.

There has been a concerted effort by European organizations to meet US competition head-on. Earlier this month, four companies signed up to the certification program introduced by the European cloud body, CISPE,

This is the latest effort by Atos to get the company back on track. In April, it sold its supercomputer company, Bull to the French government, after a previous attempt in 2024 to sell off its computer services division and after a refinancing deal in the same year.

The company implemented a further round of refinancing this year and in its half-yearly report claimed that this was an “important milestone” in securing the company’s future. However, in its first-quarter results revenue showed an organic decline of 11 percent, so any projected growth may be some time in the future. Whether its Sovereign Cloud offering is the harbinger of the revival remains to be seen.

This article first appeared on CIO.

Atos has launched a new sovereign cloud platform aimed squarely at European public sector bodies, healthcare providers and defense organizations. It’s the latest effort by European companies in their fight back against US dominance.

Atos Sovereign Cloud offers a range of controls for data management, providing customers with resilience and full control over their data, complying with existing European legislation on data residency.

“Digital sovereignty has become a global operational priority for organizations that need to manage dependencies, jurisdictional exposure and disruption risks across complex digital environments. Atos Sovereign Cloud gives customers a practical way to apply sovereign controls to their most critical workloads, while preserving flexibility, resilience and the ability to innovate securely,” said Michael Kollar, Atos Group digital sovereignty leader.

There has been a concerted effort by European organizations to meet US competition head-on. Earlier this month, four companies signed up to the certification program introduced by the European cloud body, CISPE,

This is the latest effort by Atos to get the company back on track. In April, it sold its supercomputer company, Bull to the French government, after a previous attempt in 2024 to sell off its computer services division and after a refinancing deal in the same year.

The company implemented a further round of refinancing this year and in its half-yearly report claimed that this was an “important milestone” in securing the company’s future. However, in its first-quarter results revenue showed an organic decline of 11 percent, so any projected growth may be some time in the future. Whether its Sovereign Cloud offering is the harbinger of the revival remains to be seen.

ISC2 has begun developing a vendor-neutral AI security certification aimed at cybersecurity professionals working to secure AI systems and manage emerging AI risks.

The nonprofit organization, best known for the CISSP certification, says it is seeking volunteers worldwide to help define the knowledge and skills that will shape the new credential. While ISC2 has not finalized the certification domains, the certification is expected to address both technical AI security and governance topics, with a pilot exam planned before the end of 2026.

According to Casey Marks, ISC2 chief operating officer, feedback from cybersecurity practitioners led ISC2 to conclude that AI security had grown beyond expanding AI content within existing certifications.

“AI has reached a tipping point,” Marks says. “AI no longer is just another tool; instead, it has fundamentally changed the cybersecurity practice itself.”

ISC2 already includes AI-related content in certifications including CISSP and CCSP, but Marks says practitioners have identified new responsibilities and risks that extend beyond those programs. “Enterprise security teams are currently grappling with significant knowledge gaps, particularly around securing model architectures against new vulnerabilities like prompt injection, data poisoning, and model inversion,” Marks adds.

Organizations are working to understand emerging governance frameworks, including the NIST AI Risk Management Framework and ISO/IEC 42001, while adapting traditional application security and security operations workflows to AI systems, he says.

ISC2 has not finalized the certification domains, but Marks says the organization expects the credential to address both technical controls and governance practices for securing AI systems and managing AI risk. The certification will use ISC2’s established certification development process, which relies on cybersecurity practitioners to define job roles, develop exam content, and validate competencies.

Marks says ISC2 will continue to update the certification through ongoing input from cybersecurity professionals, in addition to its regular certification review process.

The organization is also determining which professionals the certification will target. Marks says AI security responsibilities are emerging across security architecture, risk management, security operations, software development security, governance and compliance, communication and network security, and security assessment and testing. ISC2 says the certification will reflect how those roles are evolving.

For organizations that are building AI security programs now, Marks recommends using existing AI training resources, adopting established governance frameworks, creating cross-functional AI security working groups, and participating in the certification development process.

Marks says ISC2 expects AI knowledge to become part of most cybersecurity roles while a more specialized AI security discipline continues to develop. He says organizations will increasingly need professionals with foundational AI security knowledge, as well as specialists in areas such as adversarial machine learning, model architectures, and AI data pipelines.

Looking ahead, Marks says he expects AI security expertise to evolve into both a foundational skill for cybersecurity professionals and a specialized discipline of its own.

“At this time, we are seeing a hybrid evolution occurring in real time: AI security is simultaneously becoming a baseline expectation for all security roles, while also carving out a dedicated, highly specialized discipline,” Marks says.

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.”

The cybersecurity landscape has evolved beyond human scale. Today’s adversaries have replaced predictable, manual playbooks with machine-generated attack chains that can breach traditional controls in seconds. To bridge the gap, organizations must move past legacy, reactive controls and embrace a fundamentally different, AI-driven architecture: Agentic Endpoint Security (AES). 

AES represents a paradigm shift, moving security from a passive monitor to an active participant in the defense lifecycle. It provides the visibility and automated guardrails necessary to govern autonomous AI agents and agentic tools, ensuring that as your workforce scales with AI, your security posture remains unbreakable. 

With autonomous AI agents now capable of planning and executing multi-stage attacks at machine speed, the pressure on traditional security operations (SOC) has reached a breaking point. To survive this shift, the strategy is clear: we must fight AI with AI. 

Here is how AI-driven defense, pioneered by Cortex XDR and the era of Agentic Endpoint Security, is fundamentally rewriting the cybersecurity playbook.

1. From reactive patching to proactive prevention 

For decades, the industry lived in a “wait-and-see” mode waiting for a vulnerability to surface, waiting for a signature, and then rushing to patch the hole. But reactive methods just don’t hold up against modern “frontier” AI attacks that are constantly morphing. 

AI-driven defense changes the game by shifting to a prevention-first architecture. Rather than relying on historical signatures, modern platforms deploy localized, ML-driven analysis to evaluate the intent and behavior of an active process, stopping threats pre-execution. Cortex XDR leads with a strict prevention-first approach by using AI-driven local analysis and behavioral threat protection; the XDR agent stops sophisticated threats pre-impact and pre-execution. This proactive stance reduces the overall risk profile by blocking malicious chains of events in real time across network, process, file, and registry activity. 

2. Eliminating the “agentic blind spot” 

As we all rush to adopt generative AI and automated workflows, a new gap has appeared: the “agentic blind spot.” Adversaries are now targeting AI assistants and automated scripts to bypass defenses. Since these digital agents often have deep access to enterprise data, a compromise here lets attackers move completely under the radar. 

The new playbook requires securing this entire ecosystem. By combining the distinct capabilities of Cortex XDR and Koi Security, organizations can effectively close this gap. Koi Agentic Endpoint Security tracks everything from shell commands to prompts in real time, while Cortex XDR adds a layer of defense that identifies and neutralizes behavioral anomalies unique to these automated threats. 

3. Machine-speed detection and “attack storylines” 

When an attacker can move through your network in seconds, human-led teams can’t keep up. To make matters worse, most systems just flood analysts with low-quality, isolated alerts, leading to major burnout. 

AI-driven defense fixes the investigation process by automatically stitching separate data points into a single, high-fidelity “attack storyline.” Cortex XDR uses thousands of machine learning detectors across endpoint, network, and cloud sources to group related signals into one cohesive case. This reveals the full story of an attack, letting your analysts focus on fast remediation instead of digging through piles of data, reducing alert noise by up to 98%. 

4. Surgical and autonomous response 

The final piece of the puzzle is moving from manual remediation to autonomous action. AI-driven response lets your SOC handle threats in minutes, not hours. The platform can automatically revoke compromised tokens or isolate endpoints at machine speed. 

Cortex XDR delivers built-in enterprise-grade automation at no additional cost, providing over 120 out-of-the-box playbooks and 18 quick actions to handle up to 99% of incidents without manual intervention. Crucially, this level of automation requires an unbreakable foundation of agent resilience. To ensure the defense cannot be disabled by an adversary, Cortex XDR is certified in both the AVC EDR Detection and Anti-Tampering tests, successfully blocking all attempts to disable or modify the agent. 

Summary

The threat landscape is changing faster than ever, driven by AI-powered attackers who exploit even the smallest gaps. But you don’t have to stay on the defensive. By shifting to a proactive, AI-driven architecture like the one built into Cortex XDR, you can stop threats before they happen, secure your agentic workflows, and automate away the noise that leads to analyst burnout. 

The journey to a more resilient, AI-powered SOC doesn’t have to be daunting. With the right foundation in place, you’re not just keeping pace with the new threat landscape; you’re staying one step ahead. It’s time to move beyond the old manual playbook and embrace the future of security operations. 

To learn more about Palto Alto Networks, visit https://www.paloaltonetworks.com.

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

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

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

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

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

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

DARPA’s Quantum Benchmarking Initiative

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

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

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

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

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

Genesis Mission

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

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

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

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

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

Enterprise priorities

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

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

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

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

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

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?

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.

Studie “SAP S4HANA”: Sie können sich noch beteiligen!

Zum Thema SAP S4HANA führt die COMPUTERWOCHE derzeit eine Multi-Client-Studie unter IT-Verantwortlichen durch. Haben Sie Fragen zu dieser Studie oder wollen Partner bei dieser Studie werden, helfen wir Ihnen unter research-sales@foundryco.com gerne weiter.

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”

GitLab has released GitLab 19.2, an update to the company’s devsecops platform that allows teams to fix vulnerable dependencies automatically, use Security Review Flow to catch logic flaws that scanners miss, and run AI agents straight from the terminal, the company said.

Highlights in GitLab 19.2 include the following:

• Dependency Scanning Auto-Remediation, in public beta, uses AI to fix build-breaking changes and iterates until your pipeline passes, with every change governed by your existing gates and audit trail.
• Security Review Flow, also in public beta, analyzes code changes as a security engineer would and catches authorization gaps, business-logic errors, and race conditions that static scanners structurally cannot see.
• GitLab Duo CLI, now generally available, gives developers access to agents and multi-step agentic flows for all software life cycle tasks without leaving the terminal. 
• Custom Flows, now generally available, let teams replace manual multi-step workflows with agentic automations for software development, triggered by GitLab events.

“Coding agents made it possible to generate far more code and moved the bottleneck downstream to reviews and security,” said Manav Khurana, chief product and marketing officer at GitLab, in a statement. “GitLab 19.2 puts agents to work on that bottleneck: fixing vulnerable dependencies, catching the flaws scanners miss, and automating the steps in between with a person still approving what ships.”

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.

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.

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.

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.

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?

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.

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

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

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

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

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

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

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

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

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

MCP under threat

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

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

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

The ever-widening blast radius of AI testing

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

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

Vulnerability management on notice

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

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

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

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

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

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

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

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.

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

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

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

From AI-ready networks to autonomous networks

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

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

The core characteristics of the network of the future

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

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

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

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

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

Human expertise remains essential

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

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

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

5 actions enterprises should take now

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

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

The road ahead

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

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

CISOs at government organizations and universities have an unexpected ally coming to their aid: OnlyFans models.

For some time, hackers have exploited weaknesses in the websites of universities or government departments to host scams or malware, using content stolen from the OnlyFans website as bait to attract victims.

Now, according to security researchers at Upguard, the fightback has begun: creators of adult content on OnlyFans are leveraging Google search results and the protection offered by copyright law to break up the traffic distribution systems created by bad actors.

These distribution systems work in three stages: entry points using adult or other content to attract and capture web traffic, a routing system sends it to destination sites, and those sites monetize the traffic through scams and malware. It has proved to be a lucrative business for the scammers.

Google recognizes the approach and calls such actors SEO parasites as they benefit from the reputations of other organizations — in particular government or academic sites, which Google views as having high authority.

Since the creators of OnlyFans content are also the copyright holders, they are able to issue Digital Millennium Copyright Act (DMCA) take-down notices for the stolen content posted by the bad actors to other sites. Upguard was able to track this through Google’s DMCA Transparency Report, and through the Lumen Database, another tracker of takedown notices, to which it was granted research access.

“This allows us to identify likely compromised sites: government and university domains advertising unlicensed adult content,” Upguard said.

The OnlyFans creators’ action has two benefits for the operators of the affected websites: The adult content associated with their domain disappears from Google search results, no longer affecting their reputation — and if they receive takedown notices for such content they can check their webservers for the vulnerabilities that enabled the bad actors to post it there in the first place.

This article first appeared on CSO.

CISOs at government organizations and universities have an unexpected ally coming to their aid: OnlyFans models.

For some time, hackers have exploited weaknesses in the websites of universities or government departments to host scams or malware, using content stolen from the OnlyFans website as bait to attract victims.

Now, according to security researchers at Upguard, the fightback has begun: creators of adult content on OnlyFans are leveraging Google search results and the protection offered by copyright law to break up the traffic distribution systems created by bad actors.

These distribution systems work in three stages: entry points using adult or other content to attract and capture web traffic, a routing system sends it to destination sites, and those sites monetize the traffic through scams and malware. It has proved to be a lucrative business for the scammers.

Google recognizes the approach and calls such actors SEO parasites as they benefit from the reputations of other organizations — in particular government or academic sites, which Google views as having high authority.

Since the creators of OnlyFans content are also the copyright holders, they are able to issue Digital Millennium Copyright Act (DMCA) take-down notices for the stolen content posted by the bad actors to other sites. Upguard was able to track this through Google’s DMCA Transparency Report, and through the Lumen Database, another tracker of takedown notices, to which it was granted research access.

“This allows us to identify likely compromised sites: government and university domains advertising unlicensed adult content,” Upguard said.

The OnlyFans creators’ action has two benefits for the operators of the affected websites: The adult content associated with their domain disappears from Google search results, no longer affecting their reputation — and if they receive takedown notices for such content they can check their webservers for the vulnerabilities that enabled the bad actors to post it there in the first place.

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.

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.

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.

Recent data from the CompTIA Tech Jobs Report shows that tech jobs have seen a drop in unemployment, down to 3.1% in May from 3.5% in April, accounting for an increase of around 6,700 in May. Roles that saw the highest demand include software developers and engineers, systems engineers and architects, tech support specialists, cybersecurity engineers and analysts, and AI engineers.

And according to projections form the U.S. Bureau of Labor Statistics, the tech workforce is anticipated to grow twice as fast as the overall US workforce, with an expected replacement rate of 6% annually, or approximately 323,000 workers, for tech occupations between 2024 and 2034.

“More than ever, business success relies on technology,” said Seth Robinson, VP of  industry research at CompTIA. “Our research has shown a desire to build capability in core operational functions, which then allows companies to build advanced practices in AI, data, and cybersecurity.”Further data, this time from the CompTIA Sate of the Tech Workforce 2026 report, shows that 83% of IT leaders and HR professionals say their organizations are placing a high or moderately high priority on addressing skill concerns, and 62% say they expect the budget for AI training to increase in the next year. Organizations also seem to recognize the impact that skills development can have on employees, with 83% saying they expect these investments to have a high or moderate degree of impact on employee morale and engagement.

Cause and effect

There are two main factors driving the skills gap and pushing IT leaders to invest in training programs: AI accelerating technological change, and a shortage of AI skilled professionals in the hiring market. However, while AI is a main driver in the skills gap, 48% of IT leaders also say AI is crowding out other important needs, including a much-needed shift to skills-based hiring methodologies.

IT leaders are looking to build training programs that specifically address AI basics, data analysis, AI threat awareness, automation, data preparation, securing AI systems, building inputs and prompts, and creating AI agents. Currently IT leaders cite cost of training, training fatigue, turnover, lack of executive support, difficulty measuring ROI, and stale training curriculum as some of the biggest challenges when developing training programs, according to CompTIA.

So organizations that embark on upskilling and training will need a robust strategy in place to ensure employees take advantage of the training and remain engaged. Leaders will also need to set the expectations for how to integrate training into daily work, so they aren’t left feeling overwhelmed by the process on top of their current roles.

“What we’ve found that works is to embed AI into people’s workflows after the initial training, and pair people with colleagues who are further along in their AI utilization,” says Maruf Ahmed, CEO of IT solutions provider Dexian. “The gap between ‘I attended the training’ and ‘I’m actually using this differently in my job’ is where companies lose people, and closing it takes more than a single training cycle.”

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.

Red Hat OpenShift 4.22, an update to the company’s hybrid cloud application platform, is now generally available. The release focuses on cutting cloud infrastructure costs, simplifying operations of virtualized workloads, and securing sensitive data.

Announced July 14, Red Hat OpenShift 4.22 continues to harden the platform foundation to meet growing security standards, helping reduce the manual effort of compliance and risk mitigation, Red Hat said. The introduction of a minimal Red Hat Universal Base Image (UBI) strips away non-essential packages to reduce the overall attack surface. With Red Hat OpenShift sandboxed containers 1.12, OpenShift 4.22 makes support for confidential containers on bare metal generally available.

The OpenShift 4.22 release also introduces confidential AI as a technology preview. With confidential AI, organizations can isolate and run highly sensitive workloads and proprietary AI algorithms inside a cryptographically isolated slice of memory and CPU, providing data privacy even during runtime execution, according to Red Hat.

OpenShift 4.22 also brings new Red Hat OpenShift Virtualization capabilities. A new Ethernet virtual private network integration with user-defined networks allows teams to connect containerized and virtualized workloads to external infrastructure. Volume groups now can be used to execute multi-volume snapshots for VMs, providing a crash-consistent backup mechanism that simplifies disaster recovery. And the introduction of two-node OpenShift with fencing provides a highly resilient and resource-efficient option for constrained edge environments, Red Hat said.

In addition, OpenShift 4.22 offers new platform capabilities designed to optimize resource usage and lower operational overhead. The Red Hat build of Karpenter, an open source auto-scaler that right-sizes compute instances for Kubernetes clusters, is now generally available for Red Hat OpenShift Service on AWS with hosted control planes. And customers running Red Hat OpenShift Service on AWS with hosted control planes now can integrate AWS EC2 Spot Instances for fault-tolerant workloads to save on costs.

Finally, Red Hat OpenShift 4.22 introduces the JobSet operator to streamline large-scale distributed training runs and LLM fine-tuning. This framework coordinates multiple related jobs as a single unit, maximizing the use of expensive GPU compute.

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.

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

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

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

Acumen with AI-powered tools

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

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

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

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

Keen understanding of emerging and established AI threats

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

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

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

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

Appreciation of performance and business goals

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

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

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

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

Systems mindset

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

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

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

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

Cross-disciplinary fluency and broad stack know-how

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

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

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

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

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

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

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

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

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

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

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

Willingness to keep learning

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

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

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

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

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

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

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.

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.”

Generative AI is a kind of artificial intelligence that creates new content, including text, images, audio, and video, based on patterns it has learned from existing data.

Today’s generative models are typically built on foundation-model architectures such as large-language models (LLMs) and multimodal systems, enabling them to carry on conversations, answer questions, write stories, generate code, and produce images or videos from brief prompts.

Generative AI is different from discriminative AI, which draws distinctions between different kinds of input. Where discriminative AI answers questions like “Is this image of a rabbit or a lion?”, generative AI instead responds to prompts such as “Describe to me how a rabbit and lion look different from one another” or “Draw me a picture of a lion and a rabbit sitting next to each other” — and in both cases produces text or imagery that, while grounded in the AI’s training data, isn’t just a copy of something that already existed.

Just a few years ago, generative AI was once a novelty focused on chatbots and artistic image generation. Today, it has become a core enterprise technology, and powers everything from content creation and software development to customer support and analytics workflows. But with that power comes a new set of challenges — from model alignment and hallucination to governance and data-integration hurdles.

In this article, we’ll look at how generative AI works, explore how it has evolved into the foundation-model era, examine how to implement it effectively, and offer best practices for getting value out of it, today and in the future.

How does generative AI work?

For decades, early artificial-intelligence efforts often focused on rule-based systems or narrowly trained models that were built for one task at a time. While these efforts produced useful systems that could reason and solve human tasks, they were generally a far cry from sci-fi visions of thinking machines. Programs that could talk to people never seemed to get very far past the level of ELIZA, a “computer therapist” created at MIT in the mid 1960s; even Siri and Alexa after much fanfare were revealed to be fairly limited.

The big structural shift that gave birth to modern generative AI came with the concept of a transformer, first introduced in “Attention Is All You Need,” a 2017 paper from Google researchers.

Using a transformer architecture as a basis, you can build a system that derives meaning from analyzing long sequences of input tokens (words, sub-words, bytes) to understand how different tokens might be related to one another, then determines how likely any given token is to come next in a sequence, given the others. In AI lingo, we call these systems models. Because a model analyzes very large datasets and parameter counts, it can pick up on statistical patterns and knowledge implicitly embedded in the data.

This is all easier said than done. The process of adjusting a model’s internal parameters so it gets better at predicting the next token in sequences is called training. During training, the model repeatedly guesses the next token in a given sequence, compares its prediction to the actual one, measures the error, and updates its parameters to reduce that error across billions of examples. Over time, that process teaches the model the statistical relationships that will allow it to generate coherent language (or code, or images) later.

What is a foundation model?

You’ll often hear the word large used for transformer-based models of these types, like the LLMs we mentioned earlier. Large in this context refers to the large number of internal numerical values that the model adjusts during training to represent what it has learned, along with breadth and diversity of data used to train the model and the underlying compute resources powering this whole process.

This is in contrast with the narrow models of the earlier era of AI/ML, which werebuilt for one purpose and trained on a limited dataset. For instance, a spam filter may be very good at what it does, but it’s only trained on email data and all it can do is classify emails. Large models, by contrast, serve as what’s known as foundation models. They’re trained broadly on diverse data (text, code, images, or multimodal data) and then adapted or specialized for many downstream tasks.

These foundation models are the basis for most of the popular generative AI tools and services on the market today. They can be specialized in several ways:

• Fine-tuning: Giving a foundation model further training on a smaller, task-specific dataset
• Retrieval-augmented generation (RAG): Giving the model the ability to pull in external knowledge when asked a question
•  Prompt engineering: Tailoring a query so the model gives the sort of answers you’re looking for.

How do AI systems write computer code?

One of the surprising discoveries of the gen AI era was that in recent years was that foundation models trained on natural-language text can also, when fine-tuned with code examples, also write computer code — often better than many purpose-built systems. Still, it makes sense, when you think about it — after all, high-level computer languages are designed by humans and ultimately based on human language.

This 2023 InfoWorld article highlights how models like PaLM, LLaMA and other transformer-based systems fine-tuned on code repositories propelled this shift, but since AI giants like OpenAI have moved into this space. This all matters because code generation (or code-assisted productivity) has become a key enterprise use case of generative AI — perhaps the key use, given the industry’s enthusiastic adoption of it.

What are AI agents?

So far, we’ve been talking about chatbots, writing assistants, image-generation tools. They respond to prompts, output text or images, and then stop. A new category of tool called agentic AI goes further: it plans, executes, and in many cases learns as it works.

Because large models already understand language, code, and even structured data to some extent, they can be repurposed to generate not only descriptive text but operational instructions. For example: an agent might parse the intent “generate a sales-report”, then format internal calls like getData(salesDB, region=NA, period=lastQuarter), and then call an API, all by generating text that’s interpreted as instructions. The MCP framework standardizes the “language” of those instructions and the plug-points into tools and data so that the model doesn’t need bespoke integrations for each new workflow.

These kinds of autonomous agents have several enterprise use cases:

• Software automation: Agents that generate code, call unit tests, deploy builds, monitor logs and even roll back changes autonomously.
• Customer support: Instead of simply drafting responses, agents interact with CRM APIs, update ticket statuses, escalate issues, and trigger follow-up workflows.
• IT operations/AIOps: Agents monitor infrastructure, identify anomalies, open/close tickets, or auto-remediate based on defined rules and context from logs.
• Security: Agents may detect threats, initiate alerts, isolate compromised systems, or even attempt to manage threat containment — though this raises new risks.

How can you implement generative AI in the enterprise?

We’ve now touched on what generative AI can do. But how can you make it work reliably in your business. The difference between a pilot and full-scale deployment often comes down to systems, structure and governance as much as to models themselves. InfoWorld’s Matt Asay offers a deep dive into enterprise gen AI essentials, but here are some important points to keep in mind:

Choosing between API, open-source or custom fine-tuned models. One of the first major decisions for any enterprise project is: do you use a model via an API (e.g., from a vendor like OpenAI or Anthropic), deploy an open-source model internally, or build/fine-tune a custom model yourself? Each has trade-offs.

APIs offer speed and minimal setup, but may expose data, limit customization or accrue high cost — and will leave you at the mercy of your vendor. Open source allows internal control and may ease fine-tuning, but requires infrastructure, expertise, and support. Custom fine-tuning gives you the tightest alignment to your use-case, but lengthens time to value and increases risk.

Governance, data privacy and compliance. Deploying generative AI in an enterprise setting raises new governance, privacy and regulatory issues. For example: Who owns the data that’s ingested? How is proprietary data protected if you call a third-party API? What traceability exists for model outputs—a huge question for regulated industries? One useful framework is covered in “A GRC framework for securing generative AI” Data governance must adapt for the new era,  and new frameworks are evolving to help.

Human-in-the-loop review. Even the best models make mistakes and cannot simply be put on autopilot. You need a human-in-the-loop (HITL) process: real people need to review outputs, validate for bias, approve high-stakes content, and tune prompts or models based on feedback. Incorporating HITL checkpoints helps mitigate risk and improve overall quality.

Integration with existing systems and RAG pipelines. Retrieval-augmented generation, which we touched on earlier, connects foundation models into business workflows, systems, and enterprise data stores. RAG can bind LLMs to your organization’s internal knowledge bases, thereby reducing hallucinations (which we’ll discuss in a moment) and increasing the relevance of gen AI output.

What causes AI hallucinations?

Probably the biggest limitation of generative AI is what those in the industry call hallucinations, which is a perhaps misleading term for output that is, by the standards of humans who use it, false or incorrect.  

Every generative AI system, no matter how advanced, is built around prediction. Remember, a model doesn’t truly know facts—it looks at a series of tokens, then calculates, based on analysis of its underlying training data, what token is most likely to come next. This is what makes the output fluent and human-like, but if its prediction is wrong, that will be perceived as a hallucination.

Because the model doesn’t distinguish between something that’s known to be true and something likely to follow on from the input text it’s been given, hallucinations are a direct side effect of the statistical process that powers generative AI. And don’t forget that we’re often pushing AI models to come up with answers to questions that we, who also have access to that data, can’t answer ourselves.

In text models, hallucinations might mean inventing quotes, fabricating references, or misrepresenting a technical process. In code or data analysis, it can produce syntactically correct but logically wrong results. Even RAG pipelines, which provide real data context to models, only reduce hallucination—they don’t eliminate it. Enterprises using generative AI need review layers, validation pipelines, and human oversight to prevent these failures from spreading into production systems.

What are some other problems with generative AI?

Generative AI has proven to be such a disruptive technology that’s stoking near-apocalyptic fears that it will result in a superintelligence that will enslave or destroy humanity. Meanwhile, in the present day, increasingly troubling reports of so-called AI psychosis are emerging, where people have mental health episodes triggered by the uncanny and sometimes sycophantic ways chatbots affirm whatever you talk to them about and try to keep the conversation going.

Compared to such existential questions, the following business-related problems may seem petty. But they’re real issues for enterprises considering investing in AI tools.

• Data leakage and regulatory risk. When a model is fine-tuned or prompted with sensitive information, that data may be memorized and unintentionally reproduced. Using third-party APIs without strict controls can expose proprietary or personally identifiable information (PII). Regulatory frameworks like GDPR and HIPAA require explicit governance around where training data resides and how inference results are stored.
• Prompt injection occurs when an attacker manipulates a model’s instructions—embedding hidden directives or malicious payloads in user input or external content the model reads. This can override safety rules, expose internal data, or execute unintended actions in agentic systems. Guardrails that sanitize inputs, restrict tool-calling permissions, and validate outputs are becoming essential.
• Copyright and content ownership. Many foundation models are trained on data scraped from the public internet, creating disputes over copyright and data provenance. Enterprises using generated output commercially need to confirm usage rights and review indemnity terms from vendors.
• Unrealistic productivity expectations. Finally, organizations sometimes expect generative AI to deliver instant productivity gains. The reality, it turns out, is more mixed. Enterprise adoption requires infrastructure, governance, retraining, and cultural change. The models accelerate work once properly integrated, but they don’t automatically replace human judgment or oversight.

The current generation of enterprise AI systems includes several layers of defense against these risks:

• Guardrails that constrain model behavior and filter unsafe outputs.
• Model validation frameworks that measure factual accuracy and consistency before deployment.
• Policy layers that enforce compliance rules, redact sensitive data, and log model actions.

These safeguards reduce—but don’t remove—the inherent uncertainty that defines generative AI.

GenAI: essential for the enterprise

Generative AI has evolved from a novelty into a core layer of enterprise technology. Foundation models and agentic systems now power automation, analytics, and creative workflows — but they remain fundamentally probabilistic tools. Their strength lies in scale and adaptability, not perfect understanding.

For organizations, success depends less on chasing model breakthroughs than on integrating these systems responsibly: building guardrails, maintaining oversight, and aligning them with real business needs. Used wisely, generative AI can amplify human capability rather than replace it.

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.

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.

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?

덴마크의 다국적 제약사 노보 노디스크(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