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.

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

Why advanced prompting still matters in enterprise settings

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

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

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

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

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

After (CoT prompt):

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

Results: Accuracy and depth improved dramatically.

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

Template you can use:

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

[Task or question]

For each step:

1. State your observation or calculation.

2. Explain the implication.

3. Proceed only when confident.

Final answer in this format: [structured output]

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

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

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

Prompt Snippet:

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

Path 1: Focus on cost and scalability.

Path 2: Focus on security, compliance and integration.

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

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

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

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

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

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

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

ReAct example: (used in data analytics workflow)

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

1. Reason about what information you need.

2. Choose the appropriate tool or action.

3. Observe the result.

4. Repeat until you can answer confidently.

Query: [user request]

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

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

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

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

Original prompt: [paste]

Provide the improved version and explain your changes.

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

5. Multimodal and structured output techniques

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

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

Best practices I learned the hard way

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

Final takeaways for technical leaders

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

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

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

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

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

AI as a leadership multiplier

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

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

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

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

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

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

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

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

AI as a new operational framework

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

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

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

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

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

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

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

Risks in the AI adoption model

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

MCP’s new features

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

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

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

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

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

Rebuilding the trust boundary

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

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

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

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

Updated MCP SDKs

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

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

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

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

This article first appeared on InfoWorld.

For years, I have been saying that cybersecurity is no longer a technology problem. It has become a business leadership challenge.

Yet, despite record levels of spending, ever-growing security teams, increasingly sophisticated technologies and a constant stream of new regulations, organizations continue to suffer major cyber incidents with alarming regularity. Every week seems to bring news of another ransomware attack, supply chain compromise or data breach affecting organizations that many would have assumed were well protected.

The obvious conclusion is that we are asking the wrong questions.

Too many executive teams remain preoccupied with the latest threat actor, the newest security product the CISO wants to buy or the latest vulnerability making headlines. Those issues matter, but they are not what should be keeping CEOs awake at night.

In my view, there are three far more fundamental issues that deserve the attention of every chief executive.

1. Corporate complexity, and the widening gap between business leadership and cybersecurity reality

Perhaps the biggest cybersecurity risk facing large organizations today is not technical at all.

It is the growing disconnect between executive perception and operational reality.

Many boards genuinely believe their organizations are reasonably well protected. They receive regular dashboards showing improving maturity scores, increasing compliance levels, falling vulnerability counts and reassuring traffic-light reports.

Unfortunately, cyber attackers do not read dashboards.

Behind those executive reports often lies an increasingly complex technology landscape, thousands of unmanaged digital assets, ageing infrastructure, rampant shadow IT, fragmented ownership, inconsistent governance and security teams struggling to keep pace with relentless business change.

The problem is rarely a lack of effort.

It is that corporate complexity has reached a level where traditional governance mechanisms are no longer capable of providing an accurate picture of organizational resilience.

Executives believe they understand the level of cyber risk they face because they receive regular reports. Those reports often measure activity rather than resilience.

Governance committees end up debating around another percentage point of phishing awareness or vulnerability remediation, while fundamental issues remain unaddressed in the background.

2. Organizational inertia, and the need for executive structure to evolve faster

Cyber criminals continue to evolve rapidly. Large organizations generally do not.

This is the second issue that should concern every CEO.

Throughout my career, I have observed organizations repeatedly responding to new cyber threats by adding another technology platform, another monitoring capability, another compliance framework or another governance committee.

Very rarely do they stop to redesign how cybersecurity operates.

The result is what I described several years ago as the “Cybersecurity Spiral of Failure”.

• As complexity and regulation increase, organizations invest in more security products.
• More products create more complexity.
• More products and greater complexity generate more alerts.
• More alerts require more analysts.
• More analysts produce more reports.
• More reports continue to build up executive confidence.
• Meanwhile, the underlying structural weaknesses remain largely unchanged, technical debt piles up and costs escalate.

And when the inevitable breach eventually happens, reality reveals itself, but distrust also sets in between senior executives and security teams.

This is not a funding problem. Nor is it a skills problem. It is fundamentally an operating model problem.

Many organizations continue trying to solve twenty-first century challenges using governance, accountability, organizational and reporting structures designed twenty-five years ago.

The cybersecurity function itself has evolved dramatically. Many executive structures have not.

This organizational inertia extends beyond technology: It affects budgeting cycles, investment priorities, procurement processes, accountability models and decision-making speed.

Cyber attackers innovate every day. Organizational change often takes years.

That imbalance should worry every CEO.

3. Accelerating technological disruption, and how it challenges organizations in areas where they are intrinsically weak

The third issue is potentially the most significant over the coming decade.

• Artificial intelligence, autonomous agents and machine identities
• Software supply chain complexity.
• Quantum computing, and post-quantum cryptography

Each of these developments represents far more than another technical trend.

Together, they fundamentally change the dynamics of cybersecurity.

Artificial intelligence is transforming countless business processes. At the same time, it is also increasing both the speed and sophistication of cyber-attacks while simultaneously transforming defensive capabilities.

Organizations have become increasingly dependent on software ecosystems that extend far beyond their own direct control. Engaging with the supply chain in ways that lead to a genuine appreciation of the risks involved has become a key challenge for most cybersecurity practices.

Quantum computing may eventually invalidate much of today’s cryptographic algorithms, forcing organizations into one of the largest technology efforts since Y2K — but without the benefit of a fixed deadline and faced by a problem that is considerably more complex and hyperconnected IT estates that have little to do with those of the late 90s.

None of these challenges can be solved overnight: They require clear governance, sustained investment over a few years and cross-functional organizational coordination.

Most large organizations are weak on those three fronts: This is precisely why CEOs should be focusing on them now.

Waiting until some of those risks become obvious will almost certainly be too late.

Businesses naturally prioritise immediate commercial pressures. Cybersecurity often involves preparing for risks whose timing remains uncertain.

But one of the greatest leadership failures I keep seeing remains the inability of organizations to act decisively on known unknowns.

That tension explains why many organizations delay action until external events force them to respond. Unfortunately, cybersecurity rarely rewards late action.

Leadership will determine who succeeds

Cybersecurity discussions still frequently focus on technology. I believe they should focus far more on leadership.

Technology will continue evolving. Threat actors will continue adapting. Regulations will continue expanding. Those developments are inevitable.

What remains within the control of every CEO is how their organization responds.

Does cybersecurity remain an IT issue? Or is it recognised as an integral part of business resilience?

How is cybersecurity accountability assigned at executive level? Or does it still rest largely with a CISO hidden in the organization?

Does the board spend sufficient time discussing resilience? Or does cybersecurity appear only when approving budgets or reviewing incidents?

These questions will increasingly determine organizational success.

The companies that navigate the next decade successfully will not necessarily be those spending the most on cybersecurity. Nor will they be those deploying the latest security technologies first.

They will be the organizations whose leadership recognises that cybersecurity has become a permanent business capability — embedded into governance, strategy, operational decision-making and organizational culture.

That transformation cannot be delegated. It begins with the CEO.

And perhaps that is the single biggest issue that should keep every chief executive awake at night: Not when the next cyber-attack will happen, but whether their organization is evolving quickly enough on those matters to meet a threat landscape that is changing much faster than the business itself.

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

What is a business analyst?

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

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

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

Impact of AI on business analyst role

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

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

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

Business analyst job description

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

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

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

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

Business analyst skills

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

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

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

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

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

Business analyst salary

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

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

Skills	Salary Boost
ScrumMaster	44%
Microsoft Azure	30%
Supply Chain	27%
Oracle eBusiness Suite	25%
Master Data Management (SAP MDM)	24%
SAP Sales and Distribution (SAP SD)	24%
Product Support	18%
Microsoft Dynamics GP	18%
SAP Quality Management (SAP QM)	18%
Workday Software	15%

For tips on boosting your salary, click here.

Business analyst certifications

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

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

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

Business analytics tools and software

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

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

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

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

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

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

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

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

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

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

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

MCP’s new features

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

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

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

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

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

Rebuilding the trust boundary

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

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

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

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

Updated MCP SDKs

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

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

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

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

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

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

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

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

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

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

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

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

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

MCP’s new features

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

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

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

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

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

Rebuilding the trust boundary

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

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

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

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

Updated MCP SDKs

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

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

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

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

This article first appeared on InfoWorld.

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

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

AI as a leadership multiplier

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

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

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

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

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

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

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

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

AI as a new operational framework

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

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

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

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

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

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

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

Risks in the AI adoption model

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

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

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

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

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

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

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

What is a business analyst?

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

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

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

Impact of AI on business analyst role

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

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

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

Business analyst job description

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

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

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

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

Business analyst skills

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

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

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

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

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

Business analyst salary

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

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

Skills	Salary Boost
ScrumMaster	44%
Microsoft Azure	30%
Supply Chain	27%
Oracle eBusiness Suite	25%
Master Data Management (SAP MDM)	24%
SAP Sales and Distribution (SAP SD)	24%
Product Support	18%
Microsoft Dynamics GP	18%
SAP Quality Management (SAP QM)	18%
Workday Software	15%

For tips on boosting your salary, click here.

Business analyst certifications

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

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

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

Business analytics tools and software

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

For years, I have been saying that cybersecurity is no longer a technology problem. It has become a business leadership challenge.

Yet, despite record levels of spending, ever-growing security teams, increasingly sophisticated technologies and a constant stream of new regulations, organizations continue to suffer major cyber incidents with alarming regularity. Every week seems to bring news of another ransomware attack, supply chain compromise or data breach affecting organizations that many would have assumed were well protected.

The obvious conclusion is that we are asking the wrong questions.

Too many executive teams remain preoccupied with the latest threat actor, the newest security product the CISO wants to buy or the latest vulnerability making headlines. Those issues matter, but they are not what should be keeping CEOs awake at night.

In my view, there are three far more fundamental issues that deserve the attention of every chief executive.

1. Corporate complexity, and the widening gap between business leadership and cybersecurity reality

Perhaps the biggest cybersecurity risk facing large organizations today is not technical at all.

It is the growing disconnect between executive perception and operational reality.

Many boards genuinely believe their organizations are reasonably well protected. They receive regular dashboards showing improving maturity scores, increasing compliance levels, falling vulnerability counts and reassuring traffic-light reports.

Unfortunately, cyber attackers do not read dashboards.

Behind those executive reports often lies an increasingly complex technology landscape, thousands of unmanaged digital assets, ageing infrastructure, rampant shadow IT, fragmented ownership, inconsistent governance and security teams struggling to keep pace with relentless business change.

The problem is rarely a lack of effort.

It is that corporate complexity has reached a level where traditional governance mechanisms are no longer capable of providing an accurate picture of organizational resilience.

Executives believe they understand the level of cyber risk they face because they receive regular reports. Those reports often measure activity rather than resilience.

Governance committees end up debating around another percentage point of phishing awareness or vulnerability remediation, while fundamental issues remain unaddressed in the background.

2. Organizational inertia, and the need for executive structure to evolve faster

Cyber criminals continue to evolve rapidly. Large organizations generally do not.

This is the second issue that should concern every CEO.

Throughout my career, I have observed organizations repeatedly responding to new cyber threats by adding another technology platform, another monitoring capability, another compliance framework or another governance committee.

Very rarely do they stop to redesign how cybersecurity operates.

The result is what I described several years ago as the “Cybersecurity Spiral of Failure”.

• As complexity and regulation increase, organizations invest in more security products.
• More products create more complexity.
• More products and greater complexity generate more alerts.
• More alerts require more analysts.
• More analysts produce more reports.
• More reports continue to build up executive confidence.
• Meanwhile, the underlying structural weaknesses remain largely unchanged, technical debt piles up and costs escalate.

And when the inevitable breach eventually happens, reality reveals itself, but distrust also sets in between senior executives and security teams.

This is not a funding problem. Nor is it a skills problem. It is fundamentally an operating model problem.

Many organizations continue trying to solve twenty-first century challenges using governance, accountability, organizational and reporting structures designed twenty-five years ago.

The cybersecurity function itself has evolved dramatically. Many executive structures have not.

This organizational inertia extends beyond technology: It affects budgeting cycles, investment priorities, procurement processes, accountability models and decision-making speed.

Cyber attackers innovate every day. Organizational change often takes years.

That imbalance should worry every CEO.

3. Accelerating technological disruption, and how it challenges organizations in areas where they are intrinsically weak

The third issue is potentially the most significant over the coming decade.

• Artificial intelligence, autonomous agents and machine identities
• Software supply chain complexity.
• Quantum computing, and post-quantum cryptography

Each of these developments represents far more than another technical trend.

Together, they fundamentally change the dynamics of cybersecurity.

Artificial intelligence is transforming countless business processes. At the same time, it is also increasing both the speed and sophistication of cyber-attacks while simultaneously transforming defensive capabilities.

Organizations have become increasingly dependent on software ecosystems that extend far beyond their own direct control. Engaging with the supply chain in ways that lead to a genuine appreciation of the risks involved has become a key challenge for most cybersecurity practices.

Quantum computing may eventually invalidate much of today’s cryptographic algorithms, forcing organizations into one of the largest technology efforts since Y2K — but without the benefit of a fixed deadline and faced by a problem that is considerably more complex and hyperconnected IT estates that have little to do with those of the late 90s.

None of these challenges can be solved overnight: They require clear governance, sustained investment over a few years and cross-functional organizational coordination.

Most large organizations are weak on those three fronts: This is precisely why CEOs should be focusing on them now.

Waiting until some of those risks become obvious will almost certainly be too late.

Businesses naturally prioritise immediate commercial pressures. Cybersecurity often involves preparing for risks whose timing remains uncertain.

But one of the greatest leadership failures I keep seeing remains the inability of organizations to act decisively on known unknowns.

That tension explains why many organizations delay action until external events force them to respond. Unfortunately, cybersecurity rarely rewards late action.

Leadership will determine who succeeds

Cybersecurity discussions still frequently focus on technology. I believe they should focus far more on leadership.

Technology will continue evolving. Threat actors will continue adapting. Regulations will continue expanding. Those developments are inevitable.

What remains within the control of every CEO is how their organization responds.

Does cybersecurity remain an IT issue? Or is it recognised as an integral part of business resilience?

How is cybersecurity accountability assigned at executive level? Or does it still rest largely with a CISO hidden in the organization?

Does the board spend sufficient time discussing resilience? Or does cybersecurity appear only when approving budgets or reviewing incidents?

These questions will increasingly determine organizational success.

The companies that navigate the next decade successfully will not necessarily be those spending the most on cybersecurity. Nor will they be those deploying the latest security technologies first.

They will be the organizations whose leadership recognises that cybersecurity has become a permanent business capability — embedded into governance, strategy, operational decision-making and organizational culture.

That transformation cannot be delegated. It begins with the CEO.

And perhaps that is the single biggest issue that should keep every chief executive awake at night: Not when the next cyber-attack will happen, but whether their organization is evolving quickly enough on those matters to meet a threat landscape that is changing much faster than the business itself.

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

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

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

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

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

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

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

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

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

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

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

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

Expect nearly every enterprise to be impacted

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

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

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

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

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

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

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

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

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

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

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

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

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

Potentially widespread fallout

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

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

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

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

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

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

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

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

Impossible to predict what will happen

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

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

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

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

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

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

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

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

Why advanced prompting still matters in enterprise settings

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

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

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

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

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

After (CoT prompt):

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

Results: Accuracy and depth improved dramatically.

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

Template you can use:

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

[Task or question]

For each step:

1. State your observation or calculation.

2. Explain the implication.

3. Proceed only when confident.

Final answer in this format: [structured output]

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

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

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

Prompt Snippet:

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

Path 1: Focus on cost and scalability.

Path 2: Focus on security, compliance and integration.

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

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

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

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

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

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

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

ReAct example: (used in data analytics workflow)

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

1. Reason about what information you need.

2. Choose the appropriate tool or action.

3. Observe the result.

4. Repeat until you can answer confidently.

Query: [user request]

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

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

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

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

Original prompt: [paste]

Provide the improved version and explain your changes.

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

5. Multimodal and structured output techniques

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

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

Best practices I learned the hard way

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

Final takeaways for technical leaders

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

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

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

Microsoft 365 Director Jeremy Chapman this month took to video to tell Windows admins that the days of delaying security patches are over.

Complex enterprise systems and historic incidents involving patch problems have caused many admins to hold fire on immediately applying security patches, in many cases deferring patch rollouts for two to four weeks or more to ensure stability. Microsoft argues that this cautious approach, though understandable, is no longer viable because AI is accelerating the discovery and exploitation of software vulnerabilities.

As a result, Microsoft has advised admins to act on patches within three days.

Independent experts agree with Microsoft’s diagnosis of the problems posed by AI-powered vulnerability discovery, but many say Microsoft’s three-day remediation window is unrealistic for large enterprises with heavy testing, change-control, and compatibility constraints.

Instead of taking a blanket approach, enterprises need to focus more on quickly resolving those vulnerabilities that are under active exploitation and relevant to their environments, according to critics of Microsoft’s revised approach.

Tighter patching deadlines

Microsoft’s revised vulnerability remediation advice comes in the wake of its work with Anthropic’s Project Glasswing and findings from Microsoft’s own MDASH multi-model agentic scanning harness. Tighter patching deadlines are configurable via Windows Autopatch and Microsoft Intune or update tooling options such as Microsoft Configuration Manager and Windows Server Update Services.

As IT environments become increasingly more complex, inadvertent issues can occur with what appears to be a simple patch.

Unique or complex deployments may not be compatible with a patch, resulting in potential data corruption, system shutdown, or the dreaded “Blue Screen of Death.” Multiple vendors in the operating system and the enterprise software and security market have released patches that have broken products and caused outages, so the issue goes well beyond Windows shops.

Increasing both the volume and the speed of patching is unsustainable for most security teams because organizations are already struggling with successful remediation as it is.

“Many organizations have patch windows, review cycles, and test environments to identify these issues prior to patching production environments,” says Scott Caveza, senior research manager at exposure management and vulnerability assessment firm Tenable. “Organizations lacking the resources for extended validation risk deploying faulty patches that cause downtime or force last-minute configuration changes.”

Caveza adds: “The mitigation steps will vary for each organization, but blindly relying on auto-updates without contextual validation is not a defensible security posture.”

CISA’s Known Exploited Vulnerabilities list and other industry data suggest that only a small fraction of disclosed vulnerabilities are confirmed as exploited in the wild.

“[Enterprises should focus on] identifying vulnerabilities with credible and functional PoCs, verified exploitation, or sustained attention from ransomware groups, threat actors, and botnets,” says Caitlin Condon, vice president of security research at VulnCheck. “Timely exploit intelligence helps organizations identify the bugs that require immediate attention, while allowing lower-risk issues to proceed through appropriate testing and change control.”

Other independent experts are more sympathetic to Microsoft’s argument that AI has made vulnerability discovery and exploit development faster than ever and, as a result, the risks of delaying patches are far greater.

“Organizations sometimes delay patches to protect the uptime of critical systems, and many updates still require a restart,” says Danny Jenkins, CEO and co-founder at endpoint protection technology vendor ThreatLocker. “Some teams also stay one update cycle behind because they are concerned that a new patch could introduce bugs or break an overlooked dependency. Unfortunately, delaying patches to preserve uptime is becoming much harder to justify.”

Jenkins adds: “Organizations should not leave critical systems exposed while waiting for the next maintenance window. Patches should still be tested, but that process needs to move quickly, with the highest priority given to vulnerabilities that are actively exploited or exposed to the internet. A controlled interruption is usually far less costly than a successful attack exploiting a known vulnerability.”

Wider cross-industry impact

Microsoft’s three-day recommendation reflects a fundamental change in the threat landscape. Other vendors might be expected to follow suit and that means CISOs need to revise their approach to vulnerability remediation.

“Organizations should expect faster disclosure-to-exploitation timelines to become the norm, which means security programs must emphasize automation, trusted software supply chains, and continuous visibility rather than relying on periodic maintenance windows,” says Mike Nelson, VP and field CTO at DigiCert.

AI is compressing the time between vulnerability discovery and exploitation, and the industry is moving rapidly from 30-, 60-, and 90-day patching windows toward a matter of days.

However a “blanket three-day requirement for every vulnerability is neither realistic nor safe for most large organizations,” says Jeff Williams, founder and CTO at Contrast Security.

Failing to patch opens up security threats, but rushing an inadequately tested patch into production creates operational risk.

“The goal cannot be to treat every CVE [vulnerability] as an emergency,” according to Williams. “It has to be identifying, within hours, which vulnerabilities are actually exploitable and require immediate action.”

Holistic remediation

Security teams are already facing significant pressure to patch faster and to remediate a rising tide of new vulnerabilities, yet many practitioners are losing ground. Verizon’s Data Breach Investigation Report, published earlier this year, found that the median time to patch had actually increased to 43 days.

Patch deployment in enterprise environments involves configuration changes, reviews, testing, and validation.

Enterprises need to become more proficient at exposure management so that they have a holistic view of their environment that’s necessary to identify which assets are at greatest risk.

“By pinpointing the misconfigurations, identity flaws, and specific vulnerabilities that pose the greatest risk to their environment, security teams can prioritize exactly what to patch first,” Tenable’s Caveza says. “The idea of ‘patch everything’ is really outdated, and ‘patch faster’ isn’t feasible with the rapidly increasing number of vulnerabilities disclosed each day.”

CISOs will have to re-engineer their vulnerability and exposure management processes. “The traditional model of scanning everything, assigning generic severity scores, and tilting at a massive and expanding backlog is no longer fast enough,” says Contrast Security’s Williams.

Organizations need to identify the small number of vulnerabilities that matter, protect against them immediately, and remediate them on a timeline the business can safely support.

Enterprises should prioritize on resolving “internet facing, remotely exploitable vulnerabilities and any of the CISA Known Exploited Vulnerability list,” says Jose Lejin, an IEEE senior member.

Businesses that cannot safely validate and deploy patches within three days still have options, including “compensating controls, reducing an asset’s exposure, or in some cases removing the component entirely, all of which shrink the exploitable risk and buy time to patch properly,” says Brad Hibbert, CSO of vulnerability management provider Brinqa.

AWS has updated AWS Data Exports, its service for generating and managing cost and usage Reports (CURs), to include standardized Amazon Bedrock product metadata, making it easier for enterprise engineering teams to analyze AI usage and spending as they scale AI deployments spanning multiple foundation models.

The update extends billing exports with normalized fields for model provider, model name, inference type, inference mode, billing unit and Bedrock product family, and will enable enterprises to identify which models generated costs and compare spending across providers without relying on custom parsing or normalization of billing records, AWS wrote in a blog post.

That reduced reliance on custom parsing will reduce the engineering effort required to analyze billing data, analysts said.

“Before the update, a data engineer would typically need to maintain a model ID registry, write regex against usage type strings, or join AWS CloudTrail with CUR to figure out which provider generated which cost,” said Bhupendra Chopra, chief revenue officer at IT consulting firm Kanerika.

The new standardized fields “can be the difference between a billing pipeline that needs constant babysitting and one that doesn’t,” Chopra added.

That’s because custom parsing logic is more prone to break down or require maintenance when AWS adds new models or updates pricing in Bedrock, said Pareekh Jain, principal analyst at Pareekh Consulting.

Richer billing data to boost enterprise AI cost governance

Beyond reducing engineering overhead, the update could also help enterprises improve AI cost governance.

Before this update FinOps teams struggled to identify which model Bedrock related to because usage type fields were inconsistent, and there was no unified product family name that captured all Bedrock costs in one place, Chopra said.

“Now those attributes — model provider, model name, inference type, inference mode, pricing unit — are standardized and available by default. That’s the plumbing work no one talks about, but it’s what makes downstream reporting actually reliable,” Chopra added.

This, said Jain, makes it easier to build dashboards showing cost by model, provider, token type or inference mode while also identifying expensive workloads, unusual token growth and opportunities to move to cheaper models or batch processing.

It’s a timely update, especially in light of last week’s AWS billing issue that caused some customers to see incorrect cost estimates of services consumed in the AWS Management Console, said Muskan Bandta, cloud associate at FinOps services providing firm ZopDev.

“Anything that gives customers clearer, more granular and more trustworthy billing data is welcome when confidence in the numbers has just been shaken. It does not fix what went wrong, but better visibility into where spend is going is exactly what teams want more of after an episode like that,” Bandta added.

This article first appeared on InfoWorld.

AWS has updated AWS Data Exports, its service for generating and managing cost and usage Reports (CURs), to include standardized Amazon Bedrock product metadata, making it easier for enterprise engineering teams to analyze AI usage and spending as they scale AI deployments spanning multiple foundation models.

The update extends billing exports with normalized fields for model provider, model name, inference type, inference mode, billing unit and Bedrock product family, and will enable enterprises to identify which models generated costs and compare spending across providers without relying on custom parsing or normalization of billing records, AWS wrote in a blog post.

That reduced reliance on custom parsing will reduce the engineering effort required to analyze billing data, analysts said.

“Before the update, a data engineer would typically need to maintain a model ID registry, write regex against usage type strings, or join AWS CloudTrail with CUR to figure out which provider generated which cost,” said Bhupendra Chopra, chief revenue officer at IT consulting firm Kanerika.

The new standardized fields “can be the difference between a billing pipeline that needs constant babysitting and one that doesn’t,” Chopra added.

That’s because custom parsing logic is more prone to break down or require maintenance when AWS adds new models or updates pricing in Bedrock, said Pareekh Jain, principal analyst at Pareekh Consulting.

Richer billing data to boost enterprise AI cost governance

Beyond reducing engineering overhead, the update could also help enterprises improve AI cost governance.

Before this update FinOps teams struggled to identify which model Bedrock related to because usage type fields were inconsistent, and there was no unified product family name that captured all Bedrock costs in one place, Chopra said.

“Now those attributes — model provider, model name, inference type, inference mode, pricing unit — are standardized and available by default. That’s the plumbing work no one talks about, but it’s what makes downstream reporting actually reliable,” Chopra added.

This, said Jain, makes it easier to build dashboards showing cost by model, provider, token type or inference mode while also identifying expensive workloads, unusual token growth and opportunities to move to cheaper models or batch processing.

It’s a timely update, especially in light of last week’s AWS billing issue that caused some customers to see incorrect cost estimates of services consumed in the AWS Management Console, said Muskan Bandta, cloud associate at FinOps services providing firm ZopDev.

“Anything that gives customers clearer, more granular and more trustworthy billing data is welcome when confidence in the numbers has just been shaken. It does not fix what went wrong, but better visibility into where spend is going is exactly what teams want more of after an episode like that,” Bandta added.

What if the next breakthrough in Enterprise AI doesn’t come from computer science alone?

What if it comes from applying principles that physicists have understood for more than a century?

According to Gartner, rising token-driven AI spend is straining budgets and challenging cost justification. As organizations race to deploy generative AI and agentic systems, token consumption dominates nearly every executive discussion: How many tokens did we use? How much did inference cost? Can we reduce our AI bill?

These are important operational questions. But they are not the strategic questions.

I believe the economics of enterprise AI can be viewed through the lens of three well-established principles from thermodynamics: the conservation of energy, entropy, and exergy.

While these principles describe physical systems — not AI —they offer a useful way to think about how organizations should measure AI success.

Principle 1: Value is created through transformation

The 1^st Law of Thermodynamics tells us that energy cannot be created or destroyed. It can only be transformed.

Enterprise AI presents a similar management lesson: Tokens are not valuable because they are consumed; they become valuable only when they are transformed into business outcomes: A faster loan application decision. A better customer experience. Faster and more accurate software. Reduced fraud. Higher employee productivity. A new product. A strategic insight.

The executive question therefore is not, “How many tokens did we consume?” It is: “How much business value did those tokens create?”

This leads to a new executive metric: return on tokens (ROT).

Just as organizations measure return on investment, they should begin measuring the business value generated for every million AI tokens consumed.

The organizations that win will not necessarily consume fewer tokens. They will generate more value from every token they use.

Principle 2: Every transformation creates waste

The 2nd Law of Thermodynamics teaches us that every energy transformation introduces inefficiencies.

Some energy inevitably becomes less useful for doing work.

The same pattern appears in enterprise AI: Not every token contributes equally to business outcomes.

Some are spent on:

• Repeated prompts
• Oversized context windows
• Redundant reasoning
• Hallucinations requiring correction
• Multiple agents performing the same work
• Expensive models solving simple problems

Those tokens are not “lost.” They simply produce very little business value.

I think of this as token entropy. Every enterprise deploying AI will experience it. The goal is not to eliminate token entropy completely — that would be unrealistic. The goal is to continuously identify it, measure it and reduce it. Because every unnecessary token represents an opportunity to improve both cost and business performance.

Principle 3: Useful work matters more than energy consumed

Thermodynamics introduces another important idea: Exergy.

Unlike energy, exergy measures how much energy can actually be converted into useful work. Two systems may consume the same amount of energy while producing dramatically different results.

The same is true for enterprise AI.

Imagine two companies each consuming one billion tokens. One produces meeting summaries. The other transforms claims operations, accelerates software delivery, detects fraud, improves customer retention, and creates new revenue opportunities. Both consumed the same number of tokens. Only one extracted significantly more business value.

Borrowing this concept as a management analogy, I call this token exergy.

Token exergy represents an organization’s ability to convert AI intelligence into meaningful business outcomes:

• High token exergy means AI is solving important business problems.
• Low token exergy means AI is generating activity without creating proportional enterprise value.

The distinction matters, because activity is not the same as impact.

A new responsibility for CIOs

For years, CIOs have monitored infrastructure: Cloud costs, storage, network utilization, GPU consumption.

These metrics remain important, but they tell only part of the story.

Token usage needs to be measured, planned, optimized and governed with the same discipline as any other cloud resource. This means that the next generation of CIO dashboards should answer different questions:

• What is our return on tokens?
• Where is token entropy reducing our effectiveness?
• How much token exergy are we generating?
• Which AI initiatives produce the greatest business value?
• Which use cases create the strongest competitive advantage?

These are no longer technology metrics. They are business metrics.

The next generation of CIOs will not simply deploy AI. They will manage an economy of intelligence.

Their role will resemble that of a portfolio manager — allocating AI capacity where it creates the greatest enterprise value, reducing waste and continuously improving the productivity of every autonomous workflow.

That responsibility cannot be fulfilled by dashboards alone.

It requires an intelligent layer capable of observing, learning and optimizing the entire AI  ecosystem. Three-layer enterprise agentic architecture Will enable this.

The next competitive advantage

Every major technology revolution eventually shifts from measuring inputs to measuring outcomes:

• Factories stopped measuring coal consumption and began measuring productivity.
• Cloud computing evolved beyond server utilization to business agility.
• Digital businesses measured customer acquisition costs and lifetime value.

Enterprise AI is approaching the same inflection point. Organizations that focus only on token costs will optimize for efficiency. Organizations that measure return on tokens, minimize token entropy and maximize token exergy will optimize for business transformation.

That is a fundamentally different objective. And I believe it will separate AI leaders from AI followers.

Because in the end, the future of enterprise AI will not be determined by how many tokens an organization consumes. It will be determined by how effectively those tokens are transformed into lasting business value. The AI adoption spending spree is over. Time to focus on value.

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

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.

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

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

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

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

The next AI bottleneck is the infrastructure behind the model.

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

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

Pilots hide the hard part

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

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

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

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

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

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

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

AI is becoming an integration problem

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

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

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

That is why the CIO question is changing.

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

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

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

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

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

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

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

Latency will become a trust issue

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

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

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

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

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

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

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

Observability has to expand

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

AI needs that, but it also needs more.

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

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

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

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

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

Data readiness is still underestimated

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

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

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

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

That is a real risk.

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

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

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

Security cannot be added later

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

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

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

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

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

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

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

The CIO has to define the operating model

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

The CIO sits in the middle of all of it.

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

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

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

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

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

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

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

That is the shift CIOs need to lead.

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

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

Regelmäßige Netzwerk-Scans reichen für eine gehärtete Angriffsfläche nicht mehr aus. Um die Sicherheit von Unternehmensressourcen und Kundendaten zu gewährleisten, ist eine kontinuierliche Überwachung auf neue Ressourcen und Konfigurationsabweichungen erforderlich. Werkzeuge aus den Bereichen Cyber Asset Attack Surface Management (CAASM) sowie External Attack Surface Management (EASM) sind darauf ausgelegt, die Angriffsfläche von Unternehmen:

• zu quantifizieren,

• zu minimieren, und

• zu härten.

Das Ziel besteht dabei darin, den Angreifern möglichst wenig Informationen über das Security-Niveau des Unternehmens zu geben und gleichzeitig kritische Business Services aufrechtzuerhalten. Dabei spielt inzwischen auch Agentic AI eine immer größere Rolle.

12 Attack-Surface-Management-Tools

Die folgenden zwölf Lösungen unterstützen Sie dabei, Risiken zu identifizieren und zu managen.

Axonius Cyber Asset Attack Surface Management

Diese CAASM-Suite von Axonius deckt alle wichtigen Aspekte ab, wenn es um Attack Surface Monitoring geht. Das Tool erstellt zunächst ein Asset-Inventar, das automatisch aktualisiert und mit Kontext aus internen Datenquellen und Ressourcen angereichert wird.

Dabei ist es auch möglich, Monitoring-Prozesse aufzusetzen, die auf Grundlage von Richtlinien wie PCI oder HIPAA ablaufen. So lassen sich Konfigurationen oder Schwachstellen identifizieren, die diesen zuwiderlaufen und entsprechende Maßnahmen ergreifen.

Bugcrowd EASM

Bugcrowd hat im Mai 2024 Informer.io übernommen und dessen EASM-Angebot in seine Security-Plattform integriert. Diese automatisiert die Asset Discovery über Webapplikationen, APIs und andere “public facing”-Komponenten des IT-Stacks hinweg.

Assets überwacht die Lösung kontinuierlich, wobei identifizierte Risiken in Echtzeit priorisiert werden. Darüber hinaus stehen auch Zusatz-Services wie manuelle Risikoprüfungen oder Penetrationstests zur Verfügung. Das Workflow-basierte Response-System der Lösung verspricht eine einfachere Einbindung mehrerer Teams, indem existierende Ticketing- und Kommunikations-Tools integriert werden. Praktisch ist auch die Möglichkeit, Konfigurationsänderungen oder System Updates zu validieren, um sicherzustellen, dass identifizierte Bedrohungen tatsächlich bereinigt wurden.  

CrowdStrike Falcon Exposure Management

Crowdstrike hat sein Falcon-Surface-Angebot von einem Standalone EASM-Tool zu einem Kernbestandteil von Falcon Exposure Management ausgebaut. Die Lösung wird nun auch durch KI-nativen Code dabei unterstützt, Risiken zu identifizieren und auszuschalten. Darüber hinaus kommt die Technologie auch für Adversarial-AI-Szenarien zum Einsatz.

Die Crowdstrike-Lösung kann außerdem:

• Risiken mit dem Business-Kontext korrelieren,
• die Ausnutzbarkeit validieren und
• direkte Abhilfemaßnahmen über die Falcon-Plattform einleiten.

Unternehmen sollen sich mit dem Tool einen nachhaltigen Überblick über ihre Angriffsfläche verschaffen und Risiken oder Bedrohungen mit einer Vielzahl von Techniken aufspüren können. Dazu gehören etwa aktive, passive und API-basierte Scans, um mit dem Internet verbundene Ressourcen zu identifizieren.

Falcon Exposure Management ist nicht Teil des Enterprise-Softwarepakets von Crowdstrike. Es kann als Abonnementlizenz auf Basis der gemanagten Endpunkte erworben werden.

CyCognito Attack Surface Management

Das CAASM-Produkt von CyCognito bietet eine kontinuierliche Überwachung und Inventarisierung von Assets. Dabei spielt es keine Rolle, ob diese On-Premises, in der Cloud, bei einem Drittanbieter oder einer Tochtergesellschaft vorliegen.

Um den Triage-Prozess und die Risiko-Priorisierung zu erleichtern, kann auch Business-Kontext hinzugefügt werden (beispielsweise Beziehungen zwischen einzelnen Assets). Das hilft dabei, sich auf die wichtigsten Netzwerkrisiken zu konzentrieren. CyCognitos Tool verfolgt darüber hinaus auch Konfigurationsänderungen und ermöglicht so, neue Risiken für die Unternehmensinfrastruktur schnell zu identifizieren.

JupiterOne Cyber Asset Attack Surface Management

JupiterOne preist seine CAASM-Lösung als eine Möglichkeit an, “Cyber-Asset-Daten nahtlos in einer einheitlichen Ansicht zu aggregieren”. Der Kontext wird bei Bedarf automatisch hinzugefügt, und die Beziehungen zwischen den Assets können definiert und optimiert werden, um Schwachstellenanalyse und Incident-Response-Fähigkeiten zu verbessern.

Benutzerdefinierte Abfragen ermöglichen es Cybersecurity-Teams, komplexe Fragen zu beantworten, während der Asset-Bestand über eine interaktive Map durchsucht werden kann. Die Security-Tools, in die Sie bereits investiert haben, können Sie integrieren – was eine ganzheitliche, zentralisierte Perspektive auf das Security-Niveau zulässt.

Microsoft Defender External Attack Surface Management

Microsoft Defender EASM erkennt nicht verwaltete Assets und Ressourcen, die per Schatten-IT bereitgestellt werden oder sich auf anderen Cloud-Plattformen befinden. Sobald die Assets und Ressourcen identifiziert sind, sucht das Tool nach Schwachstellen auf jeder Ebene des Technologie-Stacks, einschließlich der zugrunde liegenden Plattform, App-Frameworks, Webanwendungen, Komponenten und des Kerncodes.

Defender EASM ermöglicht es IT-Profis, Schwachstellen in neu entdeckten Ressourcen schnell zu beheben, indem diese nach Entdeckung in Echtzeit kategorisiert und priorisiert werden. Naturgemäß lässt sich Defender EASM eng mit anderen Microsoft-Lösungen wie Security Copilot integrieren.

Outpost24 EASM

Der schwedische Anbieter Outpost24 hat 2023 den belgischen EASM-Anbieter Sweepatic übernommen und dessen Tool in seine Modul-Kollektion für Threat Intelligence, Data Leakage und Pentesting integriert. Diese EASM-Lösung ist sowohl Standalone, als auch als Managed Service erhältlich und kann Daten entweder passiv über DNS und andere TCP/IP-Details oder über direkte Verbindungen zu Cloud-Anbietern wie AWS und Azure sowie den Lösungen großer Softwareanbieter (etwa ServiceNow, Slack oder Atlassian) erfassen.

Palo Alto Networks Cortex Xpanse

Xpanse ist Teil der XSIAM-Produktsuite von Palo Alto, kann jedoch auch separat erworben werden. Das Standalone-Produkt hat allerdings einen etwas geringeren Funktionsumfang.

Das Palo-Alto-Tool unterstützt auch die Integration mit Tools von Drittanbietern wie Qualys, Jira und ServiceNow. Zudem verfügt das Produkt über eine beeindruckende Auswahl an vorgefertigten Detection-Regeln, Widgets, um Queries und Discovery-Routinen zu erstellen und anpassbare Daten-Dashboards aufzusetzen.

Rapid7 Surface Command

Surface Command ist nur eines von zahlreichen Modulen, das Rapid7 im Angebot hat (unter anderem Vulnerability und Incident Management sowie Cloud-Native Security). Das Tool bringt Threat Exposure, Detection und Response unter einen Nenner und verspricht eine kontinuierliche „Vogelperspektive“ über sämtliche Schwachstellen – vom Endpunkt bis hin zur Cloud.

Das Rapid-7-Tool ist darauf konzipiert, blinde Flecken in der Security aufzuspüren sowie Reaktion und Behebung zu beschleunigen. Für letzteres sind zudem auch agentenbasierte KI-Funktionen enthalten.

RiskProfiler EASM

Über die RiskProfiler-Plattform lassen sich sämtliche externen Bedrohungen managen. Das Tool ermöglicht beispielsweise Dark-Web-Monitoring, digitales Monitoring sowie Hacking-Kampagnen, Schwachstellen und Supply-Chain-Angriffe zu tracken. Die hieraus gewonnenen Bedrohungsinformationen werden von KI-Agenten zu einem einheitlichen Korpus verdichtet.

Bestandteil des Tools sind zudem mehr als 13.000 vorinstallierte Regeln, die sowohl Open-Source- als auch eigene proprietäre Algorithmen miteinander verbinden. Auch die Risikobewertungen von Drittanbietern werden analysiert. Ein anpassbares Management-Dashboard visualisiert die Daten in diversen Ansichten. 

SOCRadar AttackMapper

Mit AttackMapper (ein Teil der Tool-Suite für SOC-Teams), will SOCRadar, den Anwendern die Sicht der Angreifer auf die Assets ermöglichen. Das Tool überwacht Assets mithilfe von Agentic AI dynamisch in Echtzeit, identifiziert neue oder veränderte und analysiert sie auf potenzielle Schwachstellen.

Die Ergebnisse werden mit bekannten Angriffsmethoden korreliert, um den Entscheidungsfindungs- und Triageprozess zu unterstützen. Dabei überwacht AttackMapper nicht nur Endpunkte und Software Vulnerabilities, sondern auch SSL-Schwachstellen, abgelaufene Zertifikate, DNS-Einträge und Konfigurationen. Das Tool erkennt selbst Website-Defacement-Angriffe, was entscheidend sein kann, um die Markenreputation zu schützen.

Tenable Attack Surface Management

Tenable hat schon seit einigen Jahren Tools im Angebot, um Schwachstellen aufzuspüren – und auch die aktuelle Tool-Suite wird modernen IT-Sicherheitsanforderungen gerecht. Bei Tenable Attack Surface Management handelt es sich um das EASM-Modul des Unternehmens, das in dessen Exposure-Management-Plattform „One“ integriert ist.

Tenable Attack Surface Management liefert Kontext und Details zu Assets und Schwachstellen, allerdings nicht nur aus technischer Sicht, sondern auch auf Business-Ebene, was für eine umfassende Priorisierung der Maßnahmen erforderlich ist.

7 Fragen vor dem ASM-Invest

Die folgenden Fragen sollten Sie sich und potenziellen Anbietern von Attack-Surface-Management-Lösungen stellen, bevor Sie einen Vertrag unterzeichnen.

• Benötigt unser Unternehmen eine EASM- oder eine CAASM-Lösung? Die Antwort darauf hängt davon ab, ob Sie nach internen oder externen Angreifern suchen – und wie groß der Anteil Ihrer lokalen Infrastruktur ist.
• Wie umfangreich – und effektiv – ist das Tool automatisiert? Erkennt es zuverlässig alle anfälligen Ressoucren, einschließlich digitaler Zertifikate, offengelegter Anmeldedaten und mit dem Netz verbundene Server und Services? Welche Metadaten und weiteren Details liefert die Lösung?  
• Wie behebt die Lösung Schwachstellen, wenn sie welche findet? Läuft das automatisiert ab oder sind manuelle Eingriffe erforderlich?
• Unterstützt das Tool Continuous Monitoring? Und falls ja: Wie werden Veränderungen nachgehalten?
• Welche Schwachstellen werden wie mit anderen SOC-Tools geteilt oder integriert?
• Gibt es unterschiedliche Dashboards für Management- und andere Zwecke? Beziehungsweise: Wie lässt sich das Tool auf unterschiedliche Benutzergruppen anpassen?
• Wie sieht ihre Preisgestaltung im Detail aus? Stellen Sie sicher, dass Sie das Preisgefüge des Anbieters Ihrer Wahl wirklich verstehen. In den meisten Fällen sind Sie dabei mit komplexen, nutzungsabhängigen Abrechnungsmodellen konfrontiert.

(fm)

Dieser Beitrag ist im Original bei unserer Schwesterpublikation CSOonline.com erschienen.

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.

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

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

They just feel the moment.

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

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

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

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

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

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

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

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

What these viewership numbers actually mean for infrastructure

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

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

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

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

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

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

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

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

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

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

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

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

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

The planning mistake most organisations make

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

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

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

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

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

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

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

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

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

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

The hidden chain behind every live event

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

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

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

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

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

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

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

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

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

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

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

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

What reliability is actually worth

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

Neither of those things is true now.

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

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

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

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

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

The demands ahead are bigger

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

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

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

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

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

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

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

The technology you never think about

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

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

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

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

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

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

To learn more, visit us here.

Major AI labs are unleashing forward-deployed engineers (FDEs) to try and grab enterprise customers. Large consultancies are dishing out tokens and assembling armies of consultants — both human and agent — to do the same.

But smaller firms are in the mix now, as well. AI is helping 28Stone Consulting, a New York-based, 230-person technology consultancy for capital markets, punch above its weight against larger rivals in the rush to deliver FDEs.

In this Q&A, Thomas Dolan and Frank Erickson, founders of 28Stone, argue that agentic AI isn’t a one-size-fits-all solution in vertical markets; success takes discipline, deep domain expertise, and human involvement to mitigate risk.

Many enterprises continue to struggle with the use of AI agents, which is consultancies are stepping in to get projects off the ground. 28Stone is among those that have published blueprints and methodologies on the development and delivery of agentic AI workflows with humans in the loop.

Computerworld spoke with both founding partners about why companies are still stumbling with agentic AI rollouts, and what a disciplined delivery process actually looks like.

After 15 years of delivering software for capital markets firms, is ‘AI-first’ a real distinction or just positioning?

Dolan: “We’re not shying away from being AI-forward. What needs to shine through is AI done intelligently — not stuff you get by buying some tokens for somebody on the trading desk. We’re an AI-first firm.”

Erickson: “And it’s temporary. At some point, AI is going to be synonymous with software development.

“The whole idea of an AI SDLC (software development lifecycle) versus an SDLC is going to be one and the same, a lot like cloud computing today. To not include AI in your strategy, you’d look like a COBOL vendor.”

What does agentic AI delivery look like?

Dolan: “We’ve got several AI initiatives delivering a pure agentic approach. We’ve doubled down on the human expertise wrapper in the SDLC. That doesn’t mean sacrificing any of the benefits of the AI models — quite the opposite.

“You don’t achieve anywhere near the same level of value from applying AI without keeping that expertise — industry, functional and technical — throughout the process.”

Where do humans stay in the loop once agents are doing the work?

Dolan: “We’re believers in starting with requirements discovery. Someone who knows the analytical nuances of a good business analyst is critically important; shaping a product owner’s business information through a markup file that can be fed into a BA agent, then treating the output as if it came from a very fast junior BA. Only then is the story complete.

“The developer takes that story, transforms it into the most efficient input, then owns the output, because they’re accountable for that code. A developer should own the code on both the input and output side.

“Your product owner, who knows the business, that’s great. But expecting them to interact with an agent and output enterprise code is ridiculous. It’s not a great plan.“

Why not just put one do-everything person in charge of AI and agents?

Erickson: “Every analyst, programmer or software engineer isn’t a great requirements analyst. And a great domain analyst with some technical background won’t know if the agent’s code is garbage, maintainable, performant.

“It’s unrealistic to expect one individual to have that breadth across domain, software engineering, testing, deployment. Clients ask all the time, and we push back: ‘Great, if you can find that guy, they’re few and far between.’ To deliver at the enterprise level, you need the human expertise, at depth.“

Dolan: “There’s system speed and latency, important in parts of finance. Then there’s speed of delivery, because other areas evolve quickly and time-to-market is critical.

“Our human wrapper may at first pass come across as a little slowed down. Maybe it is. But [Erickson] has a good analogy about one of the dangers of AI: you can end up going really fast in the wrong direction. By the time you look up, you’re way off base and have to backtrack.“

What about AI in your sector do you think is overhyped?

Dolan: “The hype around the ease of use of AI and the democratization of enterprise software delivery — that ‘anybody could do it now, it’s all being done by machines’ — is another idea that could prove costly in the long run.

“This do-it-yourself reaction is dangerous for clients, and for trust in the overall AI benefit, which is real. We compare it to the beginning of offshoring 20, 30 years ago: a golden idea that was going to cure everything. A lot of firms did it thoughtlessly, thinking it’s just labor arbitrage, and it almost inevitably failed. That all-or-nothing mentality missed that offshoring is an amazing way of getting better value for your dollar, but it has to be done thoughtfully, so the delivery process — the thing that ties it all together — stays unsevered.

“We’re seeing that now. I’ve heard, ‘We’ll just push a button, the machine’s building the system.’ The machine is not building the system. It might be writing the code, the story, running the tests.

The system is built by a team of engineers you bring in and trust. My fear is that people will say, ‘We don’t need this vendor or this technology team. I’ve got a product team. They might not be able to code at all, but they know the business,’ and it fails dramatically. 

“Then people say, ‘We played with AI, it’s not ready yet,’ and throw it all away. One of the best things we can do is ensure clients know the benefit is real.“

Erickson: “The hype can be summed up in a single phrase: vibe coding. That has done AI a massive disservice, because there’s a huge difference between vibe coding and enterprise software development, and some of the loudest proponents of AI are too latched on to it. In our industry, the only way to succeed would be a stable of unicorns. It just doesn’t scale. I get perturbed when our people internally refer to AI tooling as vibe coding; if they think that’s what they’re doing, they’re misunderstood.“

When you engage clients at different levels of AI maturity, how do you get them to a understand what works?

Dolan: “95% of our take on an agentic approach is in line with everyone else’s, but that 5% matters, especially in requirements discovery, in who’s giving the requirements and how they’re thought of. It can set you up for dramatic errors, given the speed at which you’re moving.

“There’s a dangerous human tendency we’re seeing among clients to try and cut corners at the start of a project and — in lieu of having deep, expert driven discovery sessions — just summarize what they may want using AI.

“We would hope our clients are collaborative, everyone understanding it’s early days. If a client insists on doing something we feel strongly against, like a product owner completely owning everything right up to code generation, that’s an issue we have to either push back strongly on or step out of the accountability for.“

AI body shops — LLM providers and giant consultancies — are emerging to help enterprises deploy AI. Does that model work?

Dolan: “Whether you’re partnering with an LLM or with an AI-first, generic software provider — ‘Hey, we’re not industry guys, but we know AI delivery’ — you end up, if you’re a bank or a broker-dealer, saying: ‘All right, we know our business, these guys know the AI side of it. What could go wrong? Put us together and we’ll have quality engineering.’

“The problem is what you miss: the know-how of putting industry and technical expertise together and actually delivering financial services systems. The people working at the generic delivery firms, whether an AI-only firm or a body shop somewhere, don’t have that capability.“

Does AI change the economics for smaller consultancies like yours competing against the big firms, and does it cut both ways?

Dolan: “Over our 15 years pre-AI, there were two recurring reasons we’d lose a project. One: ‘We’d love to work with you guys, given your subject matter expertise, but the costs just aren’t there compared to my budgets. I’m being forced to go to a body shop or an [offshore] delivery center.’ The other side of that coin: ‘We love your capabilities, but you’re a firm of 230 people and I need 300, 400 people.’

“AI changes the options for clients. You don’t have to sacrifice the niche vendor who knows your space just because you need a larger team or a cost target. AI levels the playing field and should allow smaller firms to compete with the larger, big-box generic firms, the Accentures of the world.“

Erickson: “It redefines what scale means. You can look at velocity as a measure of your cost to deliver, not a rate card. Scale can’t be defined in terms of headcount anymore. It’s got to be defined in terms of output.

“There’s a threat in it, too. If you’re an Accenture with hundreds of thousands of low-cost software engineers, how do you train all those people? I feel for them. But for us, a couple hundred people with a specific domain focus, it’s a huge opportunity.“

How has the profile of the people you and others hire changed with this agentic process?

Erickson: “You’re still looking for people with strong engineering and design backgrounds, and communication skills, because they interact across the software development lifecycle more than in the past.

“Many take too much joy in typing out perfect code. Sorry, I don’t need you writing for-loops and classes anymore. I need you reviewing them, understanding them, operating at a higher level. That’s a different kind of person: an engineer, not a programmer or a coder. On the [business analyst] side it’s similar: people took great pride in detailed user stories covering every path. Now it’s conversations, prompts, reviewing output — less doing, more interacting.

“More than ever, they have to be interested in the domain. They can’t just be, ‘I want to learn everything there is to know about Java.’ That’s too narrow. They don’t have to be an expert; they have to be interested. In our case, capital markets is a specific niche. The biggest challenge is getting familiar with the tools — finding time, while delivering for customers, to ramp up and make the mistakes you need to without jeopardizing projects.“

What about governance? Who’s keeping AI delivery and its costs under control?

Erickson: “This is evolving rapidly. People aren’t sure how to put governance around this. The most obvious is financial governance. People are starting to get hefty bills. One of our clients spent a million dollars on tokens over the last eight weeks alone. Sticker shock. The token-maxing policies are starting to show their flaws. It’s wild west still: learn on the fly, then figure out what needs to be governed.“

Are CIOs actually opening their wallets? And when they do, what’s the smarter way to invest?

Erickson: “There’s still a lot of caution. Forecasts keep going down on how long something should take. So: ‘I could wait three months and maybe still get it delivered by the same date someone’s promising me now, but for half the price. I’m going to wait and see when equilibrium is met.’ We haven’t seen the wallets open up like crazy — it’s slow adoption.“

Dolan: “One of our clients is looking at it from a productivity-boost perspective: instead of doing the same for less, I can do much more for the same. AI lets clients pull the trigger on things they wouldn’t have in the past — projects that might not have been approved pre-AI, where the costs have come down to a point that’s palatable with the business.“

Erickson: “And that’s the story we’re hoping to hear more of. There isn’t a huge cost anymore to exploring a business opportunity. The time and money that would have gone to a return-on-investment study could be spent on a proof-of-concept with AI, and the project done a few weeks later. Maybe [there’s] a hint of things to come, where decisions start being made quicker. 

“There’s a little fear on our side, though: a lot of tiny little projects is tough for a consulting business.“

Security operations centers (SOCs) have spent years struggling under the weight of growing alert volumes, expanding attack surfaces, and chronic staffing shortages. Now artificial intelligence is adding a new complication: not just more information, but more machine-generated information that must itself be evaluated.

“There is an asymmetry here because you now have to parse through a lot of AI slop to get to, ‘Okay, is this real or not?’” Fernando Montenegro, vice president and practice lead at The Futurum Group, tells CSO.

His observation captures a growing concern among security leaders. AI is helping attackers and defenders move faster, but it is also creating new forms of cognitive burden for the humans tasked with separating signal from noise.

As AI accelerates vulnerability discovery and enables more automated reconnaissance and exploitation, defenders are increasingly responsible for overseeing systems whose outputs can be difficult to interpret or verify. The challenge is not simply more work. It is that the volume, speed, and complexity of that work are increasing simultaneously.

Yet experts who study and advise SOCs reject the idea that collapse is inevitable. Instead, they describe an industry entering a difficult transition that could reshape how security teams operate and how humans and machines share responsibility for defense.

The vulnerability surge is exposing years of security debt

One of the most immediate concerns is the possibility that AI dramatically increases the number of vulnerabilities organizations must identify and remediate.

Chris Crowley, a longtime cybersecurity instructor and SOC expert, argues that organizations are facing the consequences of years of accumulated technology debt.

“A lot of what we’re going to have to account for in the next couple of years is a technology debt of vulnerable software that has been deployed because it’s good enough to solve the problem, but then there are all these latent cyber issues, flaws, vulnerabilities that weren’t discovered prior to deployment,” he tells CSO.

AI-assisted vulnerability discovery has the potential to expose those weaknesses at a pace defenders have never experienced before.

“The compression of work that is being dropped on us is unprecedented,” Crowley says. “We’ve just been ignoring it for decades.”

He does not believe AI will necessarily create entirely new classes of vulnerabilities. Instead, he expects defenders to confront much larger volumes of familiar problems.

“We’re going to have 100 of these simultaneously,” he says, referring to the kinds of high-priority vulnerabilities security teams traditionally handle one at a time.

The AI challenge for many SOCs may be less a novelty problem than a volume problem. Security teams already know how to patch systems, prioritize remediation, and respond to critical exposures. What changes is the scale and speed at which those demands arrive.

Organizations with mature patching, prioritization, escalation, and response processes may struggle but adapt. Organizations that have treated security operations as a bare-minimum compliance function may find themselves overwhelmed.

For CISOs, Crowley says, that means treating “patch now” less as an occasional emergency state and more as a permanent operating posture. As AI accelerates vulnerability discovery, the distinction between routine maintenance and crisis response may continue to blur.

He compares the situation to disaster recovery planning. Organizations that wait until a crisis arrives to establish staffing plans, escalation paths, and remediation processes may discover there is not enough help available.

Cognitive overload may become the defining challenge

While vulnerability discovery receives much of the attention, Montenegro believes security leaders need a broader framework for understanding AI’s impact.

Organizations should think about AI through three lenses, he says: security for AI, AI for security, and security from AI. The first involves protecting AI systems. The second involves using AI to improve defensive operations. The third asks what happens when adversaries use AI against the organization.

For SOCs, all three categories are beginning to overlap.

As AI makes it easier to create reports, assessments, vulnerability submissions, and other operational artifacts, humans remain responsible for determining whether that information is accurate and useful.

“It becomes much easier to generate content,” Montenegro says, “but if you’re going to review that content as a human, the onus on you now is that much larger.”

The result is a new form of cognitive overload. Security professionals may spend increasing amounts of time evaluating machine-generated information instead of conducting higher-value security work.

Organizations can increasingly use AI to summarize reports, evaluate alerts, and assist with investigations, but humans remain responsible for validating the results.

“We’re not at the stage yet where people are comfortable” handing off critical decisions entirely to AI, he says.

That leaves defenders caught between two competing realities: AI is creating more information to process, but AI is also becoming one of the few viable tools for managing that growing workload.

For Montenegro, the principle should be to automate tasks, not roles. AI can absorb repetitive investigative steps, but organizations should be cautious about removing humans from the process entirely.

The risk, he says, is that if organizations hide too much complexity behind automated outputs, analysts may lose opportunities to develop the domain knowledge needed to advance.

“How is that professional who is reacting to those alerts growing as a professional?” he says.

The gap between mature and struggling SOCs may widen

Not every organization will experience the impact of AI in the same way.

John Hubbard, senior cybersecurity consultant and SANS instructor, believes the industry’s response will largely depend on how well organizations have prepared for operational stress before AI arrives at scale.

“I would roughly break security operations teams into two camps,” Hubbard tells CSO. “There are the ones that are definitely struggling, are already overwhelmed. And then some are doing really well.”

The struggling organizations tend to be understaffed, underfunded, undertrained, or dependent on ad hoc processes. Every incident feels different, forcing teams to improvise under pressure.

“Getting hit with something like this can certainly be an accelerant for burnout if they weren’t already experiencing it,” Hubbard says.

By contrast, mature security teams have already invested in processes, training, exercises, and automation. “The teams that are doing a really solid job now are probably not super overwhelmed because they’ve developed the processes and procedures to be ready for this kind of thing,” Hubbard says.

He compares successful SOCs to fire departments. Firefighters cannot predict exactly where the next emergency will occur, but they know how to respond because they have rehearsed those responses repeatedly.

“The teams that kind of can react like a fire department are the ones that are getting it right,” he says.

Those organizations conduct tabletop exercises, adversary emulation exercises, red-team assessments, and incident response drills. As a result, they can absorb additional workload without descending into panic.

Burnout remains the industry’s most difficult problem

Despite widespread concern about AI-enabled attacks, none of the experts view AI solely as a threat. Several argue that AI will become essential for helping defenders cope with the challenges it creates.

Jose-Marie Griffiths, president emerita and former CIO of Dakota State University, believes AI can help security teams sift through overwhelming volumes of information and identify the signals that matter most.

“People who work in SOCs are now seeing overwhelming volumes of data, and they’re getting fatigued,” Griffiths tells CSO.

AI can help automate portions of analysis, validate alerts, and improve visibility into complex environments. But Griffiths cautions that some AI-assisted vulnerability discovery tools are also producing large numbers of false positives.

That matters because false positives do not eliminate work. They create it. As organizations confront escalating volumes of findings, distinguishing genuine risk from erroneous results may become as important as discovering vulnerabilities in the first place.

The experts agree that technology alone will not determine outcomes. People will.

Crowley argues that cybersecurity professionals must recognize that uncertainty is intrinsic to the profession. “We are the group that deals with uncertainty,” he says. “That’s really and truly what cybersecurity is.”

That reality places responsibility on both individuals and organizations. Analysts need mechanisms for managing stress. Teams need to recognize when colleagues are approaching their limits. Managers need to establish healthy escalation practices and realistic expectations.

Hubbard rejects the notion that burnout is inevitable.

“It is not a foregone conclusion that security operations jobs have to be a painful grind that everyone hates,” he says.

He has seen organizations where employees remain engaged for years because leaders actively manage workload, create supportive cultures, and encourage open communication.

That includes making it safe for analysts to admit when they have reached their limits. “If people are unwilling to say, ‘I’m maxed out right now, and I’m going crazy,’ that’s going to be the thing that breaks a lot of teams,” Hubbard says.

Pay alone may not solve the problem. Crowley pointed to SANS/SOC survey findings showing that compensation ranked fourth among retention factors, behind meaningful work, training, and professional development.

The future SOC may look very different

Griffiths believes organizations will need to respond not only with better technology but with structural changes. Traditional tiered SOC models may need to evolve into more collaborative teams with diverse expertise working together in real-time.

“I think we’re going to have to eliminate the hierarchies a little bit and have teams of people with different expertise working together,” she says.

She also argues that organizations should invest in human expertise rather than simply increasing AI consumption. “Buy engineers, not tokens,” she says.

Professional networks and peer support will matter as much as any tool, Griffiths says, because defenders need trusted communities where they can compare notes, share practices, and avoid facing sustained pressure in isolation.

If there is a consensus emerging among experts, it is that AI is exposing weaknesses that already existed.

The staffing shortages, alert fatigue, burnout, and process failures affecting SOCs did not begin with generative AI. AI is simply amplifying them.

At the same time, AI is providing new tools that may help organizations manage those very challenges.

The future SOC may spend less time manually triaging alerts and more time validating automated findings, conducting threat hunting, and making strategic decisions. Human expertise may increasingly be paired with AI systems that act as operational partners.

The transition will not be painless. Some teams will struggle. Some practitioners may leave the field. Others will adapt and thrive.

“In a way,” Griffiths says, “we’re turning the whole SOC inside out.”

Montenegro sees the transition as a cybersecurity version of the Red Queen effect: defenders and attackers must keep running simply to stay in place.

Borrowing from science-fiction author William Gibson, Montenegro offered perhaps the simplest description of the industry’s current moment: “The future is already here. It’s just unevenly distributed.”

For security leaders, that future is arriving in the form of AI-generated vulnerabilities, AI-assisted investigations, and AI-enabled adversaries. The question is no longer whether security operations centers will change. It is whether organizations can adapt quickly enough to keep pace.

In one ransomware response I observed, the master operational dashboard remained green while the underlying environment told a very different story. It was a classic example of what we in the IT audit profession call the “watermelon effect”—green on the outside, red on the inside.

Beneath that dashboard sat an unmapped web of legacy technical debt, undocumented service accounts and shadow cloud instances. For years, presenting a green dashboard to the audit committee could give technology leaders a false sense of comfort. If a catastrophic breach occurred, it was generally treated as an unpredictable operational tragedy, managed via cyber insurance, a carefully calibrated public relations pivot and perhaps a quiet executive transition.

Today, that corporate shield is thinner than many technology leaders assume. For technology leaders in regulated or public-company environments, executive exposure is no longer only a theoretical debate. The regulatory environment has made plausible deniability much harder to sustain.

The erosion of the corporate shield

With the application of the European Union’s Digital Operational Resilience Act (DORA) for financial entities, alongside the broader NIS2 Directive for essential and important entities, cybersecurity governance has become harder to separate from board-level oversight. DORA places ultimate responsibility for ICT risk management on the management body of financial entities, while NIS2 requires management bodies to approve and oversee cybersecurity risk-management measures. In the United States, the U.S. Securities and Exchange Commission’s cybersecurity disclosure rules require public companies to disclose material cyber incidents and describe their cyber risk management, strategy and governance in annual filings. The new burden is not simply to operate controls; it is to show, after the fact, that leadership decisions matched the risk evidence available at the time.

The serious risk to a modern CIO is not simply the occurrence of a sophisticated security incident. The true danger is the inability to reconcile what leadership presented externally to investors, regulators and the board with what the internal evidence showed inside the environment.

When a serious crisis breaks, you may find yourself surrounded by corporate defense counsel, regulatory investigators and outside forensic lawyers all asking variations of the same uncomfortable questions: What did you know, when did you discover it and what specific actions did you take next?

When those questions are asked, a slide deck asserting that your security posture is “aligned with industry best practices” will not be enough. A post-incident review may recognize that sophisticated attacks occur. What creates greater exposure is evidence that known risks were ignored, understated or left outside structured governance. To survive that level of post-incident review, one of your strongest assets is a disciplined, independent evidence trail showing that risks were identified, challenged, escalated and acted on before the first indicator of compromise appeared.

Why point-in-time comfort letters fail regulatory scrutiny

The reality we face is that legacy compliance evidence often falls short under regulatory scrutiny. For years, the annual SOC 2 Type II report or a standardized ISO 27001 certification was brandished by technology teams as the definitive proof of a functional control environment. I have sat in dozens of scoping meetings where an engineering director pointed to a freshly minted compliance report as if it were a complete defense against scrutiny.

But a compliance report is a historical artifact—a retrospective evaluation of how specific controls operated during a defined window of time months in the past. It tells an investigator that on a random afternoon in Q2, your production change-management approvals conformed to a baseline policy. It says absolutely nothing about the configuration drift, unauthorized API keys or emergency patch bypasses that developers introduced the following weekend to hit a product release deadline.

Modern regulators, boards and investors are no longer satisfied by historical comfort letters alone. Under contemporary frameworks, especially regimes focused on operational resilience, static compliance evidence is no longer enough. The expectation of due care has shifted from a passive state of compliance to an active state of continuous challenge. Increasingly, post-incident reviews look for evidence that leadership identified system vulnerabilities, formally escalated material deficiencies, evaluated systemic risk to the business and tracked remediation progress with measurable rigor.

When an architecture fails, post-incident reviews often focus quickly on ownership, escalation and whether known risks were acted upon. If your defensive documentation consists entirely of static policy documents and green dashboards, you leave an evidentiary vacuum that can invite difficult questions about executive oversight. Post-incident reviews rarely turn on perfection. They turn on whether the organization can show a traceable chain of governance.

5 non-negotiable artifacts for your executive evidence engine

This reality requires a complete reframing of your relationship with your IT audit department. Historically, this dynamic has been defined by friction. Technology leaders frequently view my peers and me as compliance traffic cops—bureaucrats who interrupt core engineering sprints to demand evidence samples, user access reviews and system configurations.

It is time to view IT audit through a pragmatic lens: we are your independent evidence engine. We are one of the few corporate functions tasked with independently challenging your control environment, documenting where exceptions were escalated and showing how management responded. When an auditor identifies a control gap and partners with you to draft a management action plan, they are not creating a bureaucratic roadblock. They are helping you construct an evidence trail that can show risk was identified, escalated and acted upon.

To transform your IT audit function into an effective executive shield, you must shift focus away from superficial check-the-box exercises and collaborate on specific artifacts. The most effective exercise you can run with your audit leadership is to flip the timeline completely and ask: if this program were reviewed six months from now, which evidence would show we governed the risk before it failed?

1. Board-facing risk registers with escalation history: A risk register that sits unreviewed on an intranet page for 12 months is not a management tool; to an investigator, it can look like evidence that known risks were not actively governed. Your material technology, cybersecurity and dependency risks must be centrally logged. More importantly, this artifact must contain a clear, chronological escalation history showing exactly when the risk was presented to leadership committees and the board, along with related minutes, decisions or follow-up actions.
2. Granular risk acceptance records: You cannot remediate every vulnerability instantly. Business continuity, legacy software limitations and budgetary boundaries require you to accept certain operational exposures. When this occurs, ensure your risk acceptance records are airtight. A defensible record must document the specific technical variance, the precise financial or operational rationale for the delay, a definitive expiration date, explicit executive sign-off and the active compensating controls deployed to reduce the blast radius in the interim.
3. Tabletop and operational simulation records: Independent frameworks such as ISACA’s Digital Trust Ecosystem Framework can help structure this evidence, but boards and regulators will still look for proof that the testing actually happened. Your audit trail should contain comprehensive records of cyber incident, disaster recovery and third-party dependency simulations. These records must detail the scenario tested, the executive participants, the control failures identified during the drill and a formalized tracking schedule showing when those gaps were closed.
4. AI governance inventories and data-flow mappings: The rapid deployment of generative AI tools across enterprise operations has created a massive blind spot for technology executives. In one audit, we found developers using an unapproved public large language model to accelerate debugging with sensitive internal code. To protect yourself, work with your audit team to build an active enterprise AI inventory that maps data lineage, identifies model business owners, documents risk classification approvals and demonstrates active technical monitoring for unauthorized data exfiltration.
5. Synchronized disclosure-control handoffs: When a material security incident or system outage occurs, the clock begins ticking for regulatory reporting. Your incident response playbook must be technically linked to your corporate disclosure controls. The audit trail should show that a documented, synchronized handoff occurred between your technical response leaders, general counsel, chief financial officer and corporate communications team. This evidence helps show that your external statements match internal technical realities.

In the modern corporate ecosystem, technology leadership is no longer just an engineering challenge; it is an exercise in rigorous, evidence-based governance. The regulatory landscape has changed, and the expectation of continuous traceability cannot be avoided.

Open and direct collaboration with your IT audit team will not prevent a zero-day exploit, an unexpected cloud outage or a critical third-party vendor failure. That is not the purpose of enterprise risk management.

The true value is far more practical: when a serious incident puts your program under review, you will not be forced to defend your reputation with a feeling, an unverified assumption or a misleadingly green dashboard. Instead, you will have an independent record showing that risk was actively seen, appropriately challenged, properly escalated and responsibly managed. In today’s regulatory environment, that disciplined trail of evidence may be the difference between a failure that can be explained and one that begins to look negligent.

.

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

I keep seeing a version of the same scene. A CEO has a question about AI. It is a real question, the kind that will shape where the company spends the next two years. The CEO does not bring it to the CIO. They bring it to a data leader two levels down, or to a vendor who presented at a conference, or to an AI specialist a board member recommended. The CIO finds out the strategy is forming when a slide shows up that they did not build. By then, the direction is already half-set, and the CIO is being asked to react to it rather than shape it.

I want to be precise about what is happening, because it is easy to misread. The CIO has not been removed from anything. Title intact, budget intact, seat at the table intact. What has changed is quieter. On one of the most consequential technology conversations the company will have this decade, the CIO is being routed around. The work still flows through them eventually. The thinking no longer starts with them.

I have watched this happen to capable people who would have given the CEO a better answer than the person who was asked. That is what makes it worth naming. This is not a competence gap. It is a positioning gap, and positioning gaps close in the wrong direction if you ignore them long enough.

How the routing actually starts

The routing does not begin with a decision to exclude anyone. It begins with a CEO who is anxious about AI and looking for someone who sounds certain. AI is moving fast enough that executives feel the pressure to have a point of view before they have earned one. That pressure usually arrives secondhand, from a board member or a peer on the golf course describing what is working at their company. So the CEO goes looking for someone who will confirm the answer they already want to hear, and they keep going back to whoever gives it to them.

Here is where many technology leaders lose the thread. For years, the safe posture in the CIO seat was measured caution. You raised the risks, you flagged the integration cost, you asked who owns the data and what the compliance exposure looks like. That posture built credibility in an era when the failure mode was moving too fast on technology nobody understood. With AI, the same posture reads as drag. A CEO who is being told by three vendors that “the future is already here” does not want to hear why they should slow down and be cautious. They hear caution as losing the race, and they go find a point of view somewhere else.

The data leaders, vendors and specialists who get the call are not necessarily more capable. They are more available with a confident answer. A vendor’s whole job is to arrive with conviction. A data scientist who has shipped one impressive model carries more apparent authority on AI, in that moment, than a CIO who runs the entire estate but talks about AI the way they talk about every other risk. The CEO is not weighing depth against depth. They are weighing the person who said yes against the person who said it depends.

Once that pattern sets, it compounds. The CEO who got a satisfying answer from the data leader goes back to the data leader. The vendor who shaped the first conversation gets invited into the second. Each loop the CIO is not in makes the next one easier to run without them. The org chart still says the CIO owns technology strategy. The actual conversation has relocated.

What it costs before anyone notices

The cost shows up late, which is exactly why it is dangerous. For a while nothing looks broken. The CIO is still delivering. The AI initiatives are still landing on their plate to execute. The damage is happening upstream, in the room where the bets get made, and the CIO is not in that room.

I have seen what arrives downstream when the strategy was set without the person who has to run it. A model gets championed that the data cannot actually support. A vendor commitment gets made that locks the company into an architecture the CIO would have flagged in the first meeting. An agent gets deployed inside a business unit, with executive blessing, and the CIO inherits accountability for it months later without ever having shaped how it was governed. The recent IBM finding that CIOs are increasingly held accountable for AI they do not fully control is the visible end of this. The invisible front end is the conversation the CIO was routed around, the one where the accountability got created in the first place.

What I find most corrosive is what it does to the CIO’s standing over time. Every initiative the CIO executes but did not shape reinforces a story about what the CIO is for. They become the person who runs the technology other people decided on. That is a fine description of an order taker and a poor description of a strategic leader, and CEOs do not promote, fund, or defend order takers when budgets tighten. The routing-around does not just cost the company a worse AI strategy. It quietly recasts the CIO as the implementer of everyone else’s thinking, and that recasting is hard to reverse once the executive team has internalized it.

What the leaders who stayed in the conversation did

The technology leaders I have watched hold their position on AI did one thing first. They stopped leading with caution and started leading with a point of view. Not a reckless one. A real, defensible position on where AI creates value in their specific business and where it does not, delivered with the same conviction the vendors bring, before the CEO went looking elsewhere for it. They made themselves the person with the clearest answer, which is the role the routing-around was filling with someone else.

That requires giving up a posture that felt safe for a long time. The CIOs who made the shift accepted that on AI, being right and cautious is worth less than being early and directional. They formed a view ahead of being asked. They walked into the CEO’s office with where we should place our AI bets and why, rather than waiting to be handed someone else’s bets to pressure-test. The difference is whether you are the author of the strategy or its editor, and CEOs route around editors.

They also changed how they talk about risk. Instead of presenting risk as the reason to slow down, they folded it into the recommendation. The data is not ready for that use case, so here is the use case where it is ready, and here is what we do in parallel to unlock the first one. That framing keeps the CIO inside the conversation as the person making AI happen responsibly, rather than the person standing outside it explaining why it is hard. Same expertise, opposite effect on whether the CEO keeps coming back.

None of this is about pushing the data leaders and specialists out. The strongest CIOs I know pulled those people closer and brought them into the room under their own framing, so that when the CEO wanted the specialist’s input, it arrived through the CIO rather than around them. They made themselves the orchestrator of the AI conversation instead of one of its casualties.

If you are a technology leader right now, the question worth sitting with is not whether you are good at AI. You probably are. The question is whether the most important AI conversations in your company are still starting with you, or whether you have quietly become the person they get handed to after the thinking is done. That answer is set in rooms you may not be in, and the only way to find out is to ask who your CEO called the last three times AI came up. If the answer is not you, the role is still yours. The conversation has already started leaving.

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

Organizations usually face the same questions concerning XLAs: What should we measure, who owns the data, how should incentives work, and how will this change provider behavior after signature.

There are no easy answers either, but after advising clients in MSP relationships with major providers, I’ve seen what works and what doesn’t. Successful XLA programs rarely start with massive transformation, nor rely on perfection before adding experience accountability to the contract.

Start with the right metrics

The first concern I hear is what to measure. MSPs often steer that discussion toward metrics already in their reporting stack. That’s a trap.

Unlike SLAs, which measure operational outputs, XLAs should focus on employee experience and business outcomes. The strongest programs start with three to five high-signal metrics tied to the employee journeys creating the most friction. More than that and the program loses focus before it gains traction.

I typically recommend starting with employee satisfaction scores, perceived lost productivity time, repeat incident rates, task completion success, and ease of getting support. Then focus early measurement on common employee experiences like service desk interactions, employee onboarding, application reliability, and device performance.

Trying to measure everything is understandable, but it’s also one of the fastest ways to stall an XLA program.

Precisely define roles and responsibilities

This is the part of XLA contract design where I spend the most time with clients, and it’s the part that major MSPs are most likely to leave vague if you let them. Accenture and TCS both have mature commercial teams skilled at agreeing to things in principle while avoiding specific accountability in writing. Don’t let that happen here.

Employee experience isn’t solely the vendor’s responsibility. It’s genuinely shared, which is a more productive framing than pure vendor accountability, but only if the split is clearly spelled out. This is what I’ve found works in practice.

Customer responsibilities

• Selecting tools and platforms
• Managing data infrastructure
• Sharing experience data openly with the provider
• Supporting internal improvement initiatives that the provider flags

Vendor responsibilities

• Running the measurement cadence
• Delivering monthly experience reporting
• Identifying and surfacing improvement opportunities from the data
• Executing operational improvements within agreed timelines

Without this level of specificity, XLA programs almost always become reporting exercises. The data gets collected, the scorecard gets presented, and nothing actually changes.

Build flexible targets

One of the biggest mistakes in XLA design is treating experience targets like traditional SLAs,  setting once at contract signing and left unchanged for years. Employee expectations, workforce patterns, and technology environments, after all, evolve constantly. A target that feels ambitious in year one may become meaningless by year three.

The strongest XLA contracts include formal reviews every three to six months to recalibrate targets, align with business priorities, and raise expectations as experience improves. This prevents providers from locking in easy wins and coasting. When providers resist review cycles, it’s often a sign they believe the targets can be met on autopilot, a red flag in any XLA program.

Use the right scoring method

One overlooked XLA best practice is how experience scores are calculated. Point-in-time scores can be distorted by outages, isolated incidents, or low survey participation, and providers sometimes exploit that volatility.

I advise clients to calculate official XLA scores using rolling two-month averages instead of snapshots. It creates a more stable and accurate view of experience trends, and makes operational timing games much harder. Most importantly, define the scoring methodology explicitly in the contract. Don’t leave it to be worked out operationally after signing.

Structure incentives carefully

Relying on penalty-only incentives is one of the most expensive XLA mistakes. On paper, the model is simple: miss the target, pay the penalty. In practice, it drives the wrong behavior. Providers focus on protecting themselves instead of improving employee experience, optimizing survey timing, and managing averages rather than solving problems collaboratively.

I’ve seen this repeatedly in Infosys, HCL, and TCS relationships. The strongest XLA structures combine risk and reward where providers earn meaningful upside for exceeding targets, innovating, and improving outcomes. Penalties still matter, especially in mature programs, but they can’t be the only lever otherwise the contract becomes another SLA model with better branding.

Define escalation processes

When experience scores fall below threshold, the contract needs to specify what happens next. This sounds obvious, but I’ve reviewed many service delivery measurement frameworks in clients’ incumbent MPS contracts that specify financial consequences without defining any collaborative process to address the underlying problem.

The escalation language I push clients to include specifies:

• a joint review process triggered when scores fall below threshold.
• root cause analysis expectations and timelines.
• remediation planning requirements with named owners on both sides.
• timelines for corrective action and progress reporting.

The framing matters as much as the mechanics. Escalation should be positioned as collaborative problem-solving, not blame assignment. Contracts that turn every missed score into a commercial dispute damage the relationship when provider engagement matters most. The best MSPs treat escalation as a shared diagnostic exercise, not a contractual confrontation.

Establish an operating rhythm

Signing the contract is the beginning, not the end. In my experience, the organizations that get the most out of XLA programs are those that build a disciplined operating cadence and stick to it. The ones that treat XLAs as a reporting exercise almost never see meaningful improvement.

This is the cadence I recommend:

Daily: Both parties maintain live dashboards showing experience trends, application performance, regional issues, and persona-specific insights to catch emerging issues.

Weekly: Customer and vendor teams hold focused working sessions to determine what improved experience this week, what hurt it, which remediation actions were completed, and what’s the priority for next week.

Monthly: Formal governance meetings to review experience scores, improvement actions, root cause discussions, and cross-functional issues that need escalation.

Biannually: Leadership steering meetings to assess overall experience performance, recalibrate targets, and align the XLA program with evolving business priorities to honestly evaluate whether or not the program is driving the outcomes the organization actually cares about.

Common mistakes organizations make

After working through XLA design and implementation with clients across their MSP relationships, the failure modes are predictable. Here’s what to watch for.

Setting targets before establishing a baseline
Rushing into targets before understanding your current state is one of the fastest ways to create disputes. Spend the first three to six months gathering baseline data, then negotiate targets based on evidence rather than guesswork.

Measuring too much
More metrics don’t create more insight. Frameworks with 20 data points rarely survive operational reality. Start focused and expand gradually.

Hiding the data
Transparency is foundational to XLAs. Providers who obscure poor scores, especially when controlling the measurement platform, undermine the entire model. Clients who weaponize the data create the same problem. Build mutual transparency obligations into the contract.

Over-relying on penalties
Penalty-only structures recreate legacy SLA behaviors. Balanced incentives drive better long-term outcomes.

Treating XLAs as static
Employee expectations, technology, and business priorities evolve constantly. Without formal review cycles, XLA programs quickly become irrelevant.

Start smaller than you think you need to

The organizations that get XLAs right are rarely the ones with the most sophisticated tooling. They’re the ones that stopped waiting for a perfect program and introduced real accountability into the contract with what they had.

The most effective starting points are often simple: agree on a focused set of experience metrics, establish a six-month review cycle, commit to shared visibility and data transparency, and create joint accountability for continuous improvement.

From there, maturity develops over time. Governance builds trust, data becomes more actionable, and targets evolve alongside business priorities. The relationship shifts from compliance management to outcome-driven partnership.

In my experience, the organizations that succeed are the ones that stopped accepting green scorecards at face value and demanded something more meaningful.

The Cybersecurity and Infrastructure Security Agency (CISA) and four international cybersecurity agencies have published guidance urging software manufacturers and online service providers to establish coordinated vulnerability disclosure (CVD) programs, saying structured engagement with security researchers can help improve vulnerability management and product security.

Published jointly with the US National Security Agency (NSA), Japan Computer Emergency Response Team Coordination Center (JPCERT/CC), the Netherlands’ National Cyber Security Centre (NCSC-NL), and the UK’s National Cyber Security Centre (NCSC-UK), the guidance, “Establishing a Coordinated Vulnerability Disclosure Program to Work With Security Researchers,” outlines how organizations can build public programs for receiving, assessing, and responding to vulnerability reports involving software, hardware, and network products.

According to the guidance, a well-defined CVD program enables software manufacturers and online service providers to better assess potential risk, improve vulnerability management processes, and make informed decisions that strengthen product security.

CISA said the guidance supports its Secure by Design initiative, which encourages technology providers to build more secure products and take greater responsibility for identifying and remediating vulnerabilities.

“Coordinated vulnerability disclosure is foundational to building a secure software ecosystem,” Chris Butera, CISA’s acting executive assistant director for cybersecurity, said in a statement.

“The practices in this guide help protect customers, strengthen products, and support CISA’s Secure by Design initiative, which encourages companies to be transparent and responsible in how they build and maintain their technology,” Butera said.

Building an effective disclosure program

The guidance recommends that organizations publish a clear vulnerability disclosure policy describing how researchers can report vulnerabilities, what testing activities are permitted, how reports will be handled, and what researchers should expect throughout the assessment process. CISA said maintaining communication with researchers helps keep the process transparent and builds trust between vendors and the security research community.

Piyush Sharma, co-founder and CEO of cybersecurity firm Tuskira, said the guidance addresses a key operational requirement for both researchers and security teams.

“CISA is right to emphasize that vulnerability disclosure requires a clear process,” Sharma said. “Researchers need to know where to report a flaw, while security teams need defined ownership to validate, prioritize, and remediate findings.”

Andrew Costis, engineering manager of the Adversary Research Team at AttackIQ, said establishing a reporting channel is only the beginning of the process.

“Creating a clear path for researchers to report vulnerabilities is a great first step, but the real work starts once that report lands,” Costis said. “Security teams have to understand what the weakness could give an attacker access to and how urgently it needs to be addressed.”

According to CISA, security researchers can help software manufacturers and online service providers identify weaknesses before they are exploited, but only if organizations provide a clear and safe mechanism for reporting vulnerabilities.

Prioritizing vulnerabilities at scale

The guidance comes as AI-assisted vulnerability discovery is increasing the volume of security findings that enterprise security teams must assess and remediate, according to Sharma.

“The challenge is that AI-assisted vulnerability discovery is increasing the volume of disclosures faster than most organizations can manually assess them,” he said.

Sharma said organizations should avoid treating every disclosed vulnerability as equally urgent and instead determine whether a flaw creates a reachable attack path, identify exposed assets, and evaluate whether existing controls can interrupt an attack while remediation is underway.

Costis echoed that view, saying vulnerability management should focus on exploitability rather than severity scores alone.

“Vulnerabilities can’t be treated as isolated findings or prioritized on severity alone,” he said. “Teams need to understand how a weakness connects to the rest of their environment and whether it creates a viable path to critical systems.”

Where patches are unavailable, Sharma said validating compensating controls can significantly reduce enterprise risk until remediation is completed.

Costis said organizations should also verify that remediation has eliminated exploitable attack paths rather than simply confirming that a vulnerability has been patched.

“Closing a ticket is one thing,” he said. “Proving the attack path is broken, and the fix holds against real-world adversary behavior is another.”

With AI increasingly tucked into every cranny of the enterprise, someone has had to step up and provide the tools necessary to discover, track, and monitor all the agents and LLMs and keep them humming along in their various workflows. Thankfully, the DevOps world answered the call, building the tools to support our new overlords in an emerging subdiscipline interchangeably called “AIOps,” “AgentOps,” and sometimes “agent observability.”

Many of the challenges involved in AgentOps are similar to those tackled by traditional DevOps tools and processes. After all, at their foundation, LLMs are just software running on hardware somewhere. Typical issues involving RAM and disk space are just as important in the agent world, maybe more so because AI operations are even more greedy about consuming storage than regular software is.

Many of the companies supporting agent observability are big names in DevOps circles, having adapted their stacks to address the idiosyncrasies of modern LLMs. IT teams maintaining enterprise agents can treat the LLMs as just one node in a big graph filled with services that are constantly swapping packets and triggering software jobs. Latency and resource constraints must be managed because end-users don’t care whether it’s an LLM, a database, or a plain-old Python script that’s failing, bringing their work to a grinding halt.

But new AI-specific challenges are opening the door to newcomers that are building tools with the peculiarities of LLMs in mind — for example, keeping deeper logs filled with records of prompts. LLMs are also often very non-deterministic by design, making it trickier to pinpoint failure modes. And then there’s the fact that an agent will give a perfectly intelligent answer one minute and hallucinate the next.

Relying on many of the same approaches that DevOps tools do, AgentOps tools watch for misbehavior and flag anything out of the ordinary for deeper analysis. This may be as simple as fixing slow responses, but it can also include AI hallucinations and other issues born of LLMs’ non-determanism.

Teams trying to choose which agent observability tools is best for their use case should look at the size and nature of their agentic systems and projects. Are they adding AI agent features to an existing product or application, or are they building agentic systems from scratch? Are they more focused on maintaining a stable LLM operation or iterating on new approaches? Is AI the center of attention or just an add-on that’s meant to improve an existing stack?

The AgentOps and agent observability options listed below share many of the same features but differ in their focus and their attention to the challenges organizations will encounter when incorporating agents into their stacks. Each tool offers a worthwhile place to start understanding how to care for the growing presence of AI in the production world.

AgentOps.ai

When teams of agents work together, tracking the conversations are essential for understanding and debugging what’s happening. The SDK from AgentOps.ai records events so that the creators can replay past behavior to track details such as token counts, spending, latency, and more. Available as a service and on-premises.

Pricing: Starts at $40 per month plus usage costs at $0.20 per 1M tokens

Standout feature: Replay analytics with “time-travel debugging”

Best suited for: Complex agent debugging

Arize Phoenix

Debugging prompts and LLM responses requires a nuanced understanding of just what’s happening, in part because of the non-determinism that often enters the process. Phoenix from Arize supports this process with robust tracing and the ability to score the results for more precise iteration. Their system can track the results and tool calls from a variety of major platforms (Anthropic, AWS, OpenAI, etc.) that are initiated by the major frameworks (LangChain, LlamaIndex, DSPy, etc.). The result is insight into what data is triggering what chain of responses.

Pricing: Small free tier; Pro plan starts at $50 per month plus costs tied to events

Standout feature: LLM-as-a-Judge metrics for tracking quality

Best suited for: Teams focusing on iterating for accuracy and quality

BigPanda

BigPanda has always offered solutions for tracking performance of complex systems. Now the company is drilling deeper into the challenge of detecting and ending the problems that come from models that go awry. BigPanda’s main system relies on historical data and machine learning algorithms to flag issues. Its own agent layer connects the problematic nodes and errant models while dispatching alerts to the right team members.

Pricing: “Value-based” table on request

Standout feature: Automated triage for faster response

Best suited for: Large teams seeking to reduce alert fatigue from large customer base

Braintrust

Setting up an effective improvement cycle for an AI agent requires a strong feedback loop from production data to the agent’s next generation. Braintrust watches the production workload and creates test vectors that expose how an agent may be drifting, regressing, or departing from its path. The tool automates much of the testing and scoring feedback loop so problematic patterns can be discovered and addressed. A core part of the offering is a specialized data store that can track large and sometimes deeply nested collections of tests and their results. Their approach may be summarized by one of their tag lines: “trace everything.”

Pricing: Free starter tier; Pro plan starts at $249 with some usage-based costs covered

Standout feature: Highly scalable trace ingestion

Best for: Teams developing strong guardrails through continuous testing

Chronicle Labs

When it’s time to release a new version of an agent into the wild, the platform from Chronicle Labs specializes in staging it and testing it with a collection of use tests and regression cases. The tools are also helpful during development cycles. “Backtest your agent against reality,” their sales material promises, with a set of tools that mines the production telemetry for solid test vectors that stress every part of the agent with prompts and challenges that the agent will encounter after leaving the safety of the lab.

Pricing: On request

Standout feature: Back-testing options for complex testing regimes

Best for: Teams chasing strong models with good fidelity to reality

Comet Opik

Building a dashboard for tracking every in-flow and out-flow to agents is one way to be ready to watch for and solve problems. Opik from Comet is just such a tool. The DevOps teams can track each call and add its own automated routines to examine the results, score them based on 30-plus metrics, and if desired, send it off to another LLM to evaluate the results. Agents that are constantly failing stand out. DevOps teams can also ask questions like, “Who is using this model and racking up all of the bills?” The same goes for MCP skills and other cogs in the machine.

Pricing: Free tiers for open source and small projects; Pro plan starts at $19 per month with usage limits

Standout feature: Auto-scoring with 30-plus metrics for evaluating traces

Best for: Teams focusing on RAG and agentic workflows

Datadog

DevOps teams that rely on Datadog to track logs across collections of services can also use it to track LLM operations, which are, of course, just another source and sink for data. It will track performance such as time to first token and offer insight into what might be causing an issue, such as lack of memory. Results then get plugged into the same cost-tracking mechanism so the bean counters can predict when the budget will run out. After all, the CFO likely doesn’t care whether the bill comes from an LLM or an old-school S3 storage bucket. Datadog integrates AI into their tools by treating these models as just another source of data.

Pricing: Small free tier with multiple paid tiers for various levels of enterprise monitoring

Standout feature: Large installed base with broad focus on more than LLMs

Best for: Large enterprise teams working with established infrastructure

Dynatrace

For more than 20 years, Dynatrace has been delivering tools that track dataflows across the full stack. Now that AIs are finding roles in many of the nodes in this complex graph, they’re expanding to track how various AI agents can interact. They want to build one platform that helps track the root cause and, often now, deploy solutions autonomously. They want to focus on being ready to support complex networks of agents that detect problems in either performance or security and then work within defined guardrails to fix them. Determining the right role for their own AI-powered agents is a key part of the product.

Pricing: Plans start at $7 per month with larger plans designed for full enterprise monitoring

Standout feature: High level of autonomous monitoring designed for large installations

Best for: Complex, hybrid environments mixing LLMs with traditional services

Galileo

Placing some AI systems into production is often a harrowing experience because the actual performance is impossible to predict, even with the most rigorous tests. Galileo offers guardrails that track performance and watch for any behavior that deviates from the ground truth. Their “LLM-as-judge” systems are distilled into compact models that can be run locally for lower costs and faster performance.

Pricing: Small free tier; Pro plans start at $50 per month with usage-based limits and costs

Standout feature: Real-time guardrails for deployed agents

Best for: Security-conscious installations that need to defend against hallucination and data leakage

Grafana Labs

Long the go-to source for open source telemetry, Grafana Labs now tracks performance of AI models in constellations of services. Grafana tracks the evolution of answers across the agentic network to recognize how small changes or hallucinations can spin out of control. It bills its system as “actually useful AI” and has even trademarked it. Its cloud assistant can configure and reconfigure the Grafana dash to offer the right level of observability. Its system includes AI-level analysis that can flag models that are responding quickly but offering bad answers because of problems such as model drift or context degradation.

Pricing: Basic free tier; Pro plan begins at $19 per month, includes better retention and some usage-based fees 

Standout feature: Full-stack tool with fully integrated LLM tools

Best for: Large, enterprise-scale system adding AI

Helicone

Sometimes shoehorning in another tool into the chain can be tricky. Helicone is designed as a smart network proxy that will route all model requests while keeping solid debugging records from the data as it goes by. The data it captures can be turned into nice charts that make it easy to spot latency issues or model failures. Naturally, tracking AI spend is also a feature in much demand as bills continue to climb.

Pricing: Small free tier; Pro plan starts at $79 per month, includes features such as team collaboration and improved querying

Standout feature: Proxy-based integration

Best for: Development teams who want to add better monitoring features quickly

Laminar

Tracking agents in development and production means building strong storehouses of data enumerating what happened. Laminar works closely with OpenTelemetry to follow agents operating in production so that flaws and failure modes can be understood from log files stored efficiently with their own compression scheme. Developers can search through traces with an SQL-ish language and Laminar’s transcript view illuminates what happened. When necessary, the traces can enable developers to scroll back in time and replay the same inputs for debugging. The goal is to offer deep insights with high-level visibility of how well the agents are meeting business objectives.

Pricing: Small free tier; “Hobby” tier that adds more features at $30; Pro level starts at $150 per month

Standout feature: Open-source license makes self-hosting a viable option

Best for: Teams fully able to leverage open-source responsibilities

LangChain LangSmith

Real-time data from agents is essential for managing any mutli-agent system in production. LangSmith from LangChain traces costs, tools, and progress toward solutions for a wide collection of agents using SDKs for Python, TypeScript, Go, and Java. The OpenTelemetry-based solution watches for anomalies, issuing warnings and alerts through dashboards and communication channels such as PagerDuty. Deeper analysis can reveal issues such as topic clustering or odd patterns of failure. Coordination with agent deployment platforms such as LangGraph and deepagents ensures greater focus on successful resolution of assignments.

Pricing: Free for solo developers; Pro teams start at $39 per person per month 

Standout feature: Systematic approach to regression testing of prompts

Best for: Teams relying on LangChain and LangGraph frameworks for supporting complex agentic behavior

Lunary

Watching the user experience is essential for building AI applications such as chatbots and assistants. Lunary offers a proxy that traces all interactions and then builds analytical dashboards for measuring metrics such as user satisfaction or model costs. One common usage is finding frequent topics and looking at the responses to ensure they deliver. When prompts aren’t perfect, Lunary lets teams iterate on the prompt text until the right answers are coming out. Its proxy structure and common API format enables Lunary to promise to work with “any LLM, any framework.”

Pricing: Free tier; Pro plan starts at $20 per month

Standout feature: Deep integration with humans for reviewing and optimizing results

Best for: Startups focused on rapid prompt innovation

NewRelic

The platform that began tracking performance of some web applications is now powerful enough to track the flows of data through complex agentic ecologies. NewRelic’s AI-driven monitoring watches for golden signals that can indicate misbehavior or worse throughout the entire lifecycle. It tracks every detail of the interactions through protocols such as MCP and then makes this available to the AI engineers responsible for performance. The dashboard provides the insights necessary to watch for toxic behavior, overt bias, drift, and overblown hallucinations. Predicting and maybe even controlling the cost is also a growing role as tokenomics becomes as important as response time.

Pricing: Free tier; Pro plan fees available through website

Standout feature: Full-stack support with hundreds of integrations with other tools

Best for: Established enterprise teams mixing in AI

Nova AI Ops

The goal of Nova AI Ops is to deliver a team of agents that watch over a cloud and make it, at least partially, self-healing. Each agent uses a mixture of predictive AI and machine learning to watch cloud telemetry reports for anomalies. Then they calculate the “blast radius” and decide whether this is a problem that can be fixed automatically “while you sleep” or saved for the human supervisors. These tools are aimed not just on LLM operations but on the stack as a whole.

Pricing: Small free tier; Standard pricing  begins at $40 per user per month with usage billing

Standout feature: Focus on software reliability engineering helps teams deliver stable stacks

Best for: Teams that want to integrate LLMs into incident response and stability management

Splunk

The platform that began delivering smart logging is now fully AI capable, offering solutions that can watch over agents with much the same way that it continues to track microservices. Splunk now includes a fairly large amount of predictive AI for learning from the information in the logs and then turning this learning into fast solutions. This AI assistant can track deployed AI models connected by protocols such as MCP and watch over behavior while delivering the ability for users to drill down and explore what’s working and what’s failing. Their AI Canvas is meant to offer a central hub where the AI scientists can track both the local behavior of the models as well as their role in a larger data ecosystem.

Pricing: Activity-based pricing tracks usage of LLM backends and storage

Standout feature: Ready to scale to large enterprise stacks

Best for: Teams with legacy systems that are folding in agentic options

SuperPenguin

One of the most important parts of an AI service is the bill. SuperPenguin is a product designed to track consumption and make predictions so that the CFO won’t be surprised. The goal is to provide solid estimates about the total cost of each product by allocating costs to customers, features, and teams. If there’s a sudden shift, a “spike detector” will raise an alarm so that dev teams can ensure that the AI spend is worth it.

Pricing: Small free tier for experimentation; Growth tier for teams, starting at $30 per month; Pro tier offers deeper options starting at $200 per month

Standout feature: Strong accounting with invoice reconciliation and PR-level usage tracking

Best for: Teams that need precise cost accounting

Vellum

Prompt engineers spend time fussing over the details of tweaking, improving, and enhancing the words that guide the LLM. Vellum started as a company that would provide the pipeline so that you could manage and improve the prompts that ran again and again. Now the system is growing more powerful, offering a higher level of automation that lets you meta-manage the prompt chain. They’ve also begun marketing it as a form of personal assistant with pre-built connections to many of the major services such as Gmail. Its llm-cost-optimizer can juggle multiple options while finding a cheaper way to execute a prompt, a process the company suggests can save 60% or more.

Pricing: Open-source free tier; Pro plan starts at $35 per month

Standout feature: Focus on multi-model pipelines for true agentic solutions

Best for: Product teams with complex prompt engineering workflows

In many teams, dependency security still happens after the most important trust decision has already been made. A package is added, the lockfile changes, the feature moves forward, and only later does the pipeline ask whether the application should have trusted that code in the first place.

That workflow made sense when dependency security was mostly viewed as a compliance check. Run a scanner. Produce a report. Fail the build if the risk crosses a threshold. Let someone decide what to do next.

But the modern Node.js ecosystem has changed. The risk no longer begins in CI. It begins earlier, at the moment a developer decides to trust a package.

That is why the next phase of Node.js security cannot be limited to better pipeline enforcement. It has to move closer to the developer workflow, before dependencies become part of the application, before a pull request becomes someone else’s problem, and before a build log becomes the first moment anyone realizes that something important has changed.

Every install is a trust decision

The npm ecosystem is built on trust at an enormous scale. Every install is a trust decision. Every transitive dependency extends that decision to maintainers, packages, scripts, release pipelines, and infrastructure the application team may never inspect directly. This model gave JavaScript its incredible velocity. It also created one of its deepest security weaknesses.

Recent npm supply chain incidents show why this matters. In March 2026, malicious Axios versions were published to npm through a compromised maintainer account. Microsoft later described how those packages attempted to retrieve a second-stage payload during installation. In May 2026, TanStack published a postmortem explaining that 84 malicious versions across 42 npm packages were published through a legitimate release pipeline after an attacker abused GitHub Actions behavior and runner trust boundaries. Security researchers also reported broader Mini Shai-Hulud activity across the npm ecosystem in May, including hundreds of malicious package versions published in a short period.

Not every one of these incidents is a traditional CVE. Some are malicious package compromises. Some involve CI/CD credential theft. Some involve maintainer or pipeline compromise. But they all point to the same larger issue: dependency risk is now part of everyday software engineering, not something that can be pushed entirely to a downstream security process.

The problem is not the scanner. It is the handoff.

Ubiquitous dependency risk changes what developers need from security tooling.

The problem is not that teams lack scanners. Many organizations already run security checks in CI. The problem is that the output of those checks often arrives too late and speaks the wrong language for the person expected to act on it.

A pull request fails. A long vulnerability report appears. The report may be technically accurate. It may contain the right advisory IDs, affected versions, dependency paths, severity labels, and references. But the developer still has to comb through the output and reconstruct the actual engineering decision from the evidence provided.

That reconstruction is rarely simple. The developer has to understand which package introduced the issue, whether the vulnerable dependency is direct or transitive, whether the fix is actually within the application team’s control, and whether the recommended version is safe to adopt. They also have to determine whether the dependency is used in production or only during development, whether the update might break the application, and whether the fix belongs in the current pull request or requires separate engineering work.

That uncertainty is where security work often slows. The scanner has detected risk, but the developer has not been given a clear path from detection to decision.

Security needs to move closer to engineering judgment

This is not a criticism of scanning. Scanning is necessary. CI enforcement is necessary. Centralized security platforms are necessary. But they are not sufficient, because they often operate after the trust decision has already been made.

The real architectural question is this: where should dependency security live in the software development life cycle?

If it lives only in CI, it becomes an interruption. If it lives only in dashboards, it becomes someone else’s queue. If it lives only in periodic audits, it becomes a backlog. But if it lives at the moment a dependency is introduced, upgraded, or reviewed, it becomes part of engineering judgment.

That shift matters because modern JavaScript development is becoming faster than human review can comfortably handle. Developers no longer add dependencies only by reading documentation and choosing libraries manually. AI coding assistants can suggest packages, generate install commands, modify package files, and rewrite code around third-party APIs. Agentic development workflows can make dependency changes as part of broader automated refactors.

AI makes the trust boundary harder to see

That acceleration is useful. It also changes the risk model.

When a human developer adds one package, the team can review the decision. When a coding agent modifies several dependencies as part of a larger task, the trust boundary becomes harder to see. The package file changes, the lockfile changes, the application still runs, and the pull request may look like a normal feature update. But the real security question may be hidden inside the dependency graph.

This is where Node.js teams need a different mental model.

Dependency adoption should not be treated as a small implementation detail. It should be treated as an architectural decision with security consequences. A new package is not just code reuse. It is a new trust relationship.

That does not mean developers should stop using packages. The npm ecosystem exists because reuse works. Most teams cannot and should not build everything themselves. But convenience should not erase visibility. If a dependency becomes part of the application, the team should understand what was added, what changed in the lockfile, what risk comes with it, and what action is available if something is wrong.

Developers need confidence, not just reports

The same applies to remediation. Developers do not want a wall of vulnerability text. They want confidence. They want to know what action reduces risk, what version should be targeted, whether the change is safe, and whether the fix is actually under their control. A vulnerability report that leaves the developer uncertain may satisfy a process requirement, but it does not necessarily improve the speed or quality of remediation.

That is the gap many teams feel today. Security tools are often very good at saying, “There is a problem.” They are less consistent at helping the developer answer, “What should I do next?”

This is the broader problem I have been exploring through CVE Lite CLI, now an OWASP project. The point is not that one command-line tool solves Node.js security. It does not. The larger idea is that dependency security has to move closer to the developer’s moment of decision. A useful developer-side security workflow should not merely report that risk exists. It should help the engineer understand whether the issue is in their control, what change is available, and whether the fix actually reduces risk.

The future is decision support, not just detection

That distinction is important. The future of Node.js security is not just more detection. It is better decision support.

Security teams still need policy. Enterprises still need dashboards. CI still needs gates. But developers need something more immediate: a way to reason about dependency risk while the code is still fresh in their mind. That is where the ecosystem has to evolve.

We already accept that testing belongs close to development. We accept that linting belongs close to development. We accept that formatting, type checking, and build validation belong close to development. Dependency security should follow the same path. It should not be treated as a mysterious report that appears at the end of the process. It should become part of the normal rhythm of engineering work.

Before adding a package, developers should understand what trust relationship is being introduced. Before accepting an AI-generated dependency change, they should inspect what entered the graph. Before merging a pull request, teams should understand whether a vulnerability is direct, transitive, fixable, or blocked by another package. And before treating a CI failure as noise, organizations should ask whether the workflow is giving developers enough information to act confidently.

Node.js security will be won, or lost, before CI runs

The Node.js ecosystem will not become safer by slowing down all development. That is unrealistic. It will become safer when security work is placed where developers can actually use it.

The next generation of Node.js security will be won or lost before CI runs.

It will be won when dependency decisions are still small enough to understand, fresh enough to review, and close enough to the developer for action to feel natural.

That is the shift teams need to make now. Not from insecure to secure in one step, but from late detection to earlier judgment. From vulnerability reports to engineering decisions. From trusting packages by habit to understanding trust as part of software design.