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?

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.

Early in my consulting career, I assumed maintenance windows reduced risk. After all, the purpose of planned maintenance is to improve reliability, apply fixes and prevent future outages. That assumption changed after I participated in what should have been a routine infrastructure change.

Every pre-check passed. Device health looked normal. High-availability synchronization was complete. Monitoring showed no obvious concerns. Yet shortly after the change, users began reporting application failures.

The root cause was not a failed upgrade, hardware fault or software defect. The maintenance activity exposed a dependency elsewhere in the traffic path that nobody had considered.

Since then, I have seen similar patterns repeatedly across enterprise environments. The change itself was rarely the problem. The problem was the assumption that the change was isolated.

Planned maintenance is intended to reduce risk, but in practice, it often introduces risk into an otherwise stable network.

Many production incidents result from routine tasks such as firewall updates, DNS changes, certificate renewals, routing adjustments, load balancer failovers, WAF updates, switch upgrades or software patches, rather than dramatic failures.

The reality is that “routine” does not equate to “low risk.” It simply means the activity has been performed before, not that the current environment will respond the same way.

Modern networks have become too interconnected for maintenance to be treated as a simple device-level task. A change to one control point can expose a dependency elsewhere in the traffic path. A firewall update can affect asymmetric return traffic. A DNS change can shift users to a data center where persistence is not aligned. A load balancer failover can expose stale ARP or MAC learning issues. A certificate renewal can cause an inspection or TLS negotiation to fail in the backend. A WAF update can block application behavior that was never visible in testing.

Failures rarely stem from the maintenance activity itself, but rather from the assumption that the change is isolated.

Why routine changes still cause outages

In traditional network operations, the unit of change was often a device: upgrade a switch, modify a router, add a firewall rule, renew a certificate or reboot an appliance. That model worked better when application traffic paths were simpler, and dependencies were easier to understand.

Today, a single user transaction may cross DNS, global traffic management, WAN routing, data center switching, firewalls, load balancers, TLS inspection points, WAF policies, API gateways and backend application tiers. Each layer may make an independent decision about availability, security, routing or session handling.

This creates a risky maintenance pattern. Teams often validate only the component they changed, not the complete traffic flow before and after the change. Devices may appear healthy, configurations may load correctly and all checks may pass, yet users can still experience failures due to a changed dependency somewhere in the end-to-end path.

Google’s Site Reliability Engineering (SRE) guidance highlights that changes remain one of the most common sources of service disruption, which is why mature organizations invest heavily in change validation, rollback planning and observability. The SRE book provides extensive discussion of change management, reliability engineering and operational risk in large-scale environments.

For this reason, maintenance windows should be evaluated as both operational events and potential failure vectors.

Common failure points during maintenance

One common issue is state mismatch. Firewalls, load balancers, NAT devices and application delivery controllers often maintain connection or session state. During failover, reboot or path change, existing flows may not survive even if the standby device becomes active as designed. New connections may succeed while long-lived sessions fail. In other cases, traffic may enter through one device and return through another, causing stateful inspection to drop packets that appear invalid.

Asymmetric routing is another frequent cause. A routing change may look harmless from a Layer 3 perspective, but if the forward and return paths traverse different firewalls or inspection zones, applications can fail intermittently. The network may still be “up,” but the security policy no longer sees the full conversation.

Layer 2 behavior is also underestimated. In highly available data center designs, MAC learning, ARP cache behavior, VLAN tagging, port channels and first-hop gateway behavior can determine whether traffic moves cleanly after a failover. A device may successfully assume an active role, but upstream switches or firewalls may still forward traffic toward the old path until tables age out or are refreshed.

DNS and GSLB changes introduce a different class of risk. Teams often test name resolution, but resolution is only the first step. The more important question is where users are being sent and whether that destination is ready to handle production traffic.

DNS resilience guidance published by the Internet Society emphasizes that successful name resolution alone does not guarantee application availability, particularly when multiple infrastructure dependencies exist behind the DNS response.

If global traffic management shifts users from one data center to another, the receiving site must have aligned firewall rules, load balancer configuration, health monitors, certificates, persistence behavior, routing advertisements and backend capacity. Otherwise, DNS sends users to a site that is not actually ready.

Certificate maintenance can also break more than the browser-facing endpoint. In many environments, TLS is terminated, re-encrypted, inspected or validated across multiple hops. Renewing a certificate on the external virtual server may not address backend certificates, intermediate chains, SNI behavior, cipher compatibility or trust stores used by inspection devices. The maintenance task may be described as a certificate renewal, but the real dependency is end-to-end TLS negotiation.

Security policy maintenance creates another risk. WAFs, IPSs, DDoS protection systems, bot defense platforms and firewall policies are designed to block abnormal behavior. But during updates, tuning changes or signature refreshes, they can also block legitimate application traffic if policy enforcement is not validated against real transaction patterns.

This is especially true for APIs, where small differences in headers, methods, payload structure or authentication flows can trigger unexpected enforcement.

The test environment problem

Many teams rely on pre-checks and test environments, but these controls are often less effective than they seem.

Pre-checks confirm device reachability, interface status, route existence, pool member availability and HA health. While necessary, these checks do not ensure production traffic will survive a path change because they focus on infrastructure rather than transaction validation.

Test environments rarely mirror production. Production environments involve real user volume, client diversity, DNS caching behavior, firewall states, certificates, backend latency and complex dependencies. A failover that succeeds in a lab may behave very differently in the real world.

This does not render testing useless, but test results should not be considered proof of production safety. They provide evidence, not a guarantee.

This challenge aligns with broader operational resilience guidance from the NIST Cybersecurity Framework, which emphasizes continuous monitoring, validation and recovery planning as critical operational capabilities.

A stronger maintenance process starts with mapping the traffic path before the window. For critical applications, teams should understand the normal ingress path, egress path, firewall zones, NAT points, load balancer virtual servers, DNS or GSLB decision points, TLS termination points, persistence requirements and backend dependencies.

The next step is defining failure expectations. What happens to existing sessions if a firewall is rebooted? Should source MAC, floating IP, ARP or upstream forwarding behavior change during a load balancer failover? How long will cached clients continue to access the old site after a DNS shift? Which clients and inspection devices validate the certificate chain when a certificate is replaced?

These questions should be addressed before the maintenance window, not during an outage.

Pre-checks should include both control-plane and data-plane evidence. Control-plane checks confirm configuration, synchronization, device health, routing tables, interface status and object availability. Data-plane checks validate real traffic movement: TCP handshakes, TLS negotiation, HTTP status codes, API responses, session persistence, source NAT behavior and return-path consistency.

During the change, monitoring should focus on symptoms that expose traffic failure early. Device CPU and interface status are useful, but they are not enough. Teams should also watch connection resets, denied firewall logs, WAF violation spikes, pool member selection failures, DNS answer changes, TCP retransmissions, backend 5xx errors and synthetic transaction results.

Rollback planning must also be precise. Simply rolling back a configuration is often insufficient. If a DNS record changes, cached clients may continue using the previous answer. If a firewall state table is cleared, restoring the rule does not recover active sessions. If failover alters forwarding behavior, upstream devices may require ARP refresh, route reconvergence or manual validation.

An effective rollback plan should identify lost state, persistent caches and the evidence required to confirm recovery.

Treating maintenance as a resilience exercise

The objective is not to make maintenance overly complex or bureaucratic. The objective is to avoid underestimating its risks.

Every maintenance window is a controlled opportunity to test whether the network behaves as specified by the architecture.

If failover is part of the design, maintenance should verify failover behavior. If a secondary data center is expected to handle traffic, maintenance should demonstrate that it can process real transactions. If security policies are updated, maintenance should prove that legitimate traffic is still allowed. If certificates are renewed, maintenance should validate the complete TLS path, not just the public endpoint.

Industry outage studies published by the Uptime Institute consistently show that human error and process failures remain significant contributors to downtime. Their annual outage research continues to highlight the role of operational processes and maintenance activities in service disruptions.

Maintenance windows provide an opportunity to identify those weaknesses before they become customer-facing incidents.

This requires closer collaboration between network, security, application and operations teams. Network engineers may own routing or load-balancing changes, but application teams understand transaction flows. Security teams understand inspection and enforcement behavior. Operations teams often see user-impacting symptoms first.

Treating maintenance as a shared traffic event rather than a device event reduces blind spots.

Routine maintenance will always involve some risk. However, the greatest risk is the false confidence that the term ‘routine’ conveys.

Modern networks fail in the spaces between systems: between DNS and load balancing, between firewalls and routing, between TLS inspection and application behavior, between HA design and actual forwarding state. Maintenance exposes those spaces.

For that reason, network teams should view every maintenance window as more than a checklist. It is a live test of architecture, operational discipline and production resilience.

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

In the past year, cloud outages have exposed a hard truth about the modern digital economy: A disruption at one hyperscaler can quickly spread far beyond a single vendor’s platform. Failures in cloud control planes, identity systems, storage layers, and core regions have disrupted business operations, developer workflows, and consumer services worldwide. From Google Cloud’s internetwide disruption to repeated outages at AWS and Microsoft Azure, the pattern is now impossible to ignore. As organizations deepen their dependence on a small number of providers, resilience, redundancy, and contingency planning are becoming strategic necessities rather than purely technical concerns. Just consider this list of recent sizeable outages in the past year alone:

• Google Cloud, June 12, 2025: Google Cloud suffered a major outage that disrupted its own services and rippled across the internet, affecting platforms including Spotify and other downstream applications.
• AWS, October 20, 2025: AWS experienced a significant outage linked to a network health monitor issue, disrupting businesses worldwide and, once again, underscoring the concentration risk surrounding its US-East-1 region.
• Microsoft Azure, October 29, 2025: Azure’s global outage generated more than 18,000 user reports at its peak. It was tied to a configuration change in Azure Front Door’s global control plane.
• Microsoft Azure, February 2–3, 2026: Azure endured another major outage lasting more than 10 hours after a misconfiguration in Microsoft-managed storage accounts triggered cascading failures across virtual machine operations and managed identities.
• AWS, May 2026: AWS was hit by a serious US-East-1 outage caused by a thermal event and power loss at a Virginia data center, impairing core services including EC2 and EBS.

What once seemed exceptional is now a regular occurrence that organizations must accept as part of doing business in the cloud. This normalization of infrastructure-layer failures should concern every technology leader who has been told that the cloud is the reliable, enterprise-grade foundation for their digital transformation initiatives.

A staggering financial impact

The financial impact of these outages on enterprises is substantial and often underestimated. When a cloud platform goes down, companies lose revenue in direct proportion to the outage’s duration and their reliance on the affected services. For large enterprises processing millions of transactions per hour, even a two-hour outage can cost tens of millions of dollars in lost revenue. Beyond direct losses, there are reputational damages, customer churn, and the operational costs of incident response and recovery.

When your e-commerce platform goes down during a peak shopping period, you don’t just lose the sales from that two-hour window. You lose customer trust that extends well beyond the outage itself. When your enterprise collaboration tools become unavailable, productivity grinds to a halt across your entire organization. When your data processing pipeline stalls, downstream analytical capabilities that drive critical business decisions are delayed or entirely compromised. The true cost of a cloud outage extends far beyond the immediate period of unavailability.

SLAs don’t help much

Many enterprise tech leaders are frustrated by their limited recourse during outages. Cloud service-level agreements (SLAs) often offer service credits that are far below actual damages. These agreements also usually absolve providers of responsibility for indirect or consequential damages, subject to a cap that rarely reflects the true cost of an outage.

In essence, enterprises are being asked to trust platforms they don’t control with business-critical operations, while accepting terms that provide minimal protection when things go wrong. This fundamentally imbalanced relationship favors the provider at the customer’s expense.

Resilient architecture

This situation demands a fundamental shift in how enterprises approach cloud architecture and infrastructure planning. The days of simply migrating everything to a single hyperscaler and assuming reliability will follow are over. Organizations need to deliberately build resilience into their platforms by embracing architectural approaches that reduce dependence on any single provider or service.

A hybrid architecture that combines cloud-based and on-premises infrastructure enables organizations to shift workloads during outages while maintaining control of critical systems. Similarly, a multicloud strategy that distributes applications and data across multiple providers reduces the blast radius of any single provider’s failure. These approaches, without question, introduce complexity and require more sophisticated management tools and operational expertise. However, the alternative—accepting that your business continuity depends entirely on the reliability of platforms you cannot control—is increasingly untenable.

The challenge is that achieving resilience through heterogeneity introduces management complexity that many organizations are not prepared to handle. Using multiple cloud providers and on-premises infrastructure requires learning different operational models, maintaining diverse skill sets, and managing different tools across your environment. Licensing costs, integration efforts, and ongoing operational overhead are significant.

However, the organizations that invest in this complexity will be better positioned to maintain business continuity when the next major cloud failure inevitably occurs. The question is not whether you can afford to invest in resilience, but whether you can afford not to.

Three things to do now

The practical reality is that organizations cannot simply wait for cloud providers to solve this problem. The economics of the industry make it unlikely that service-level agreements will become significantly more favorable to customers. The complexity of modern cloud infrastructure means that outages will continue to occur regardless of the investments providers make in reliability. Therefore, enterprises must take responsibility for their own resilience.

Here are the three things enterprises should be doing right now:

First, enterprises should conduct a comprehensive audit of their cloud dependencies to identify single points of failure across their architecture. This means mapping every application, data store, and integration point to determine exactly what would happen if a specific cloud service went offline. Most organizations discover they have far more dependencies on a single provider than they realized, and many of those dependencies are undocumented. An audit will serve as the foundation for a deliberate resilience strategy that prioritizes redundancy for the most critical systems. 

Second, enterprises should implement a hybrid architecture that incorporates on-premises infrastructure for their most critical workloads. Mission-critical systems must have an alternative path to operation when cloud services fail. The key is to identify which systems truly require this level of protection and which can tolerate cloud-only deployment. A phased approach that starts with the most sensitive workloads and expands over time allows organizations to build expertise with hybrid systems and refine their processes as they go.

Third, enterprises must establish formal disaster-recovery testing procedures that specifically target cloud provider outages rather than traditional site failures. Most organizations test their disaster recovery capabilities against scenarios such as a data center failure or a natural disaster, but they rarely test what happens when a cloud API becomes unresponsive or a cloud region goes dark. Regular testing of these scenarios will expose gaps in the architecture that might otherwise remain hidden until an actual outage occurs.

Here’s the bottom line: Don’t put all your eggs in a single basket. Accept that cloud platforms will continue to fail, and plan your architecture accordingly. The investment in resilience will pay for itself the next time your primary cloud provider experiences an outage. Your competitors will be scrambling while your business continues to operate.

Earlier this year, I was running my own local AI agent, a system I built called LaptopAI-Agent, which uses a LangGraph reasoning loop, a local Ollama model and a set of tools that can read files, query my git repositories and monitor system processes, all running entirely on my laptop with no cloud calls. I had given it a broad task and walked away. When I came back, it had completed the work. Every file it touched was within its allowed paths. Every action was technically correct.

What unsettled me was not what the agent had done. It was that I could not reconstruct the sequence of decisions that led to it. Without the SHA-256 chained audit log I had deliberately built in, I would have had no record of why the agent made each choice, only what it produced. That gap between visible outcomes and invisible reasoning is what I had to engineer around for a single-user personal tool. Enterprises face the same problem at the scale of thousands of agents, with far less instrumentation.

This is what I mean by shadow agents: autonomous AI processes that operate at the API layer, chain tools together and complete multi-step workflows without logging in, generating session records, or waiting for a human to approve. They already run inside enterprise systems today. The governance infrastructure to manage them is, in most cases, far behind.

The question is no longer whether your organization will run these autonomous processes. It already does. The question is whether you can see what they are doing.

The economics that opened the door

The immediate catalyst for this shift is financial. Enterprise teams that embedded frontier AI models from providers like OpenAI and Anthropic into everyday workflows quickly discovered that per-token cloud inference costs compound fast once agents run autonomously, making hundreds of API calls per task rather than one.

The industry response has been a push toward local AI processing. Google’s Gemma 4 12B, released in June 2026, is the clearest signal yet. Designed to run on consumer-grade hardware with just 16GB of VRAM, it brings multimodal AI, covering text, audio and visual processing, fully local to enterprise laptops without any cloud API dependency. Apache 2.0 licensing means any organization can deploy it without per-token fees.

For finance teams, this is cost relief. For IT governance teams, it is a new category of exposure. When inference moves onto thousands of distributed laptops, centralized telemetry disappears. The natural network choke points that monitoring tools rely on vanish with it. Without visibility infrastructure built before rollout, IT has no reliable way to know what those agents are accessing or deciding in the organization’s name.

The visibility gap is structural

Every monitoring tool, security scanner and compliance platform most enterprises rely on was designed to track human behavior: logins, session durations and file accesses triggered by a person at a keyboard. The implicit assumption in all of it is that a human is somewhere in the loop, generating observable signals.

Agentic AI generates none of those signals. It operates at the API layer, bypasses the user interface entirely, retrieves context from data stores, reasons over it and takes action. It does not log in. It produces no session record.

Box’s April 2026 launch of the Box Agent shows exactly how fast enterprise software is moving in this direction. The Box Agent works natively on the enterprise content layer, respecting existing permissions and compliance controls while it autonomously searches, summarizes and routes documents. That is solid engineering for business teams. It also means that contract reviews, approval chains and regulatory filings can now be executed by an agent that leaves no login trace in the monitoring systems IT manages.

The compliance consequence is real. An agent can chain tools in ways that move sensitive data from a secured internal store to an external processing endpoint because the agent found the connection useful, all within valid permissions, with no single step appearing suspicious and no record in any system IT is watching. The violation happens in the reasoning layer.

A new role: The forward-deployed AI engineer

Closing the governance gap requires a type of technical talent that most enterprise IT teams have not hired for. I have been calling this the forward-deployed AI engineer, a distinct role from DevOps.

A DevOps engineer asks whether the system is up. A forward-deployed AI engineer asks whether the agent is doing what was intended and only that. Their work covers three areas.

The first is prompt governance. The instructions that drive agent behavior function as code. They need version control, hardening against prompt injection attacks and rigorous re-testing after every model update. A prompt producing correct output in January can behave differently after a model version change in March, with no external indication that anything shifted.

The second is guardrail design: defining in technical terms what each agent is permitted to access, which external systems it may contact and which categories of action, financial transactions, credential access, outbound data transfers require human authorization before the agent can proceed.

The third is RAG pipeline governance. Enterprise agents typically access corporate knowledge through Retrieval-Augmented Generation pipelines. Scoping those pipelines correctly and auditing them on a consistent schedule is one of the most underestimated security responsibilities in agentic deployment. Overly permissive retrieval creates data exposure paths that are hard to detect until something has already gone wrong.

Runtime isolation: The right security model for agents

The architectural shift required here is from perimeter defense to runtime isolation. Perimeter defense assumes you control what enters the environment. When agents run locally, call external APIs dynamically and chain tools based on autonomous reasoning, the perimeter boundary is no longer a meaningful control surface.

Microsoft’s Agent Executor, part of the Microsoft Agent Framework, provides a practical model here. The Agent Executor wraps an agent in a sandboxed runtime that manages session state, conversation context and tool permission boundaries within a controlled envelope. An agent inside a properly configured executor cannot reach unauthorized systems or take unapproved actions regardless of what the model decides to do. The security guarantee shifts from trusting the model’s output to controlling what it is allowed to execute. For any organization under compliance mandates, that distinction between trust and control is not a nuance; it is the design requirement.

Governing at scale: The multi-agent challenge

One sandboxed agent with clear guardrails is manageable. A fleet of coordinating agents with distinct permissions, running simultaneously across cloud, desktop and on-premises environments, is a qualitatively different problem that requires dedicated infrastructure.

Automation Anywhere’s EnterpriseClaw, launched in May 2026 with Cisco, NVIDIA, Okta and OpenAI as partners, is the most comprehensive platform I have seen address this. NVIDIA contributes OpenShell, an open-source runtime for deploying autonomous agents safely, plus NIM microservices with Nemotron models for on-premises customers. Okta handles cross-agent identity management and policy enforcement across the entire agent fleet. Cisco AI Defense provides an agent-specific threat detection layer that conventional network monitoring cannot replicate. OpenAI enables production workflows on its latest models, including GPT-5.5.

The platform gives IT a single governance surface: centralized policy, behavioral monitoring and auditable observability across every agent regardless of where it runs. The core principle is that no agent, cloud-hosted or running locally on a laptop, operates outside a defined policy boundary. EnterpriseClaw is currently in preview, with general availability expected later in 2026.

Accountability cannot be an afterthought

Building governance into LaptopAI-Agent took deliberate effort: a permission guard with path allowlists, blocked commands, manual approval triggers and a chained audit log. That overhead for a personal tool on a single laptop previews what enterprises face at an orders-of-magnitude larger scale, across systems they did not build and agents they did not deploy themselves.

The tools are available. The architectural patterns are documented. What is missing in most organizations is the deliberate decision to build governance in parallel with deployment, not as remediation after the first incident.

Every shadow agent in your environment was approved somewhere, by someone, for a specific purpose. The question is whether you still have a current, verifiable line from that approval to what the agent is doing right now. If the answer is no, or we are not sure, that is exactly where the work needs to start.

Shadow agents are not a future problem. They are in production today, summarizing documents, routing decisions and interacting with systems your monitoring tools cannot observe. IT leaders who build real accountability infrastructure around them will be positioned to harness autonomous AI with confidence. The ones who wait will spend their time explaining, after the fact, how something happened that nobody could see.

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

Across the global corporations, I advise, in financial services, healthcare, retail and the public sector, the same crisis surfaces in leadership meetings. Executives approved a bold AI roadmap. Cloud spending climbed 40, 50, even 70 percent. And yet the AI workloads that made perfect sense in the boardroom presentation now stall, overshoot their budgets or collapse under production load before they reach real users.

I am writing this just after the spring 2026 conference season, and the signal from Google Cloud Next, Microsoft Build, and a run of AWS summits only sharpens the point. Over the past several weeks the industry shipped, in production form, the infrastructure to run and govern AI at scale. What most enterprises still lack is the operating model to decide how to use it.

The problem is not the AI models. The models work. The problem is that organizations built their AI ambitions on cloud strategies designed for a world that no longer exists: strategies built for SaaS applications, predictable traffic and linear cost curves. AI workloads break all three assumptions at once.

Why AI breaks traditional cloud assumptions

For a decade, cloud-first served enterprises well. It delivered elasticity, reduced capital expenditure and democratized access to compute, because enterprise workloads were predictable: web applications, ERP systems, databases and analytics pipelines that scaled smoothly and billed in ways finance could model on a spreadsheet. GenAI and agentic AI change every one of those assumptions at once.

When organizations move AI into production, real inference, retrieval pipelines, vector search and real-time decisioning, the cloud equation breaks in at least five ways:

1. Training clusters demand power densities far above standard compute.
2. Inference needs millisecond latency that network geography can defeat.
3. Vector databases generate cost spikes invisible in standard billing.
4. Agentic workloads chain hundreds of tool calls with cascading dependencies.
5. And data-sovereignty rules constrain where any of them can run.

In short, what works at the platform level fails at the workload level.

The costs are the first thing to surprise leaders, because they hide. CloudZero’s analysis and the FinOps teams I work with put it plainly: AI spend surfaces as generic compute, storage and instance line items, rarely labeled “AI.” Three layers drive most of the waste:

1. The most visible is LLM API cost, where stateless calls re-send the full conversation history on every request, so a deployment with a couple hundred users can burn many times the token budget in the business case.
2. The biggest is idle GPU: teams’ provision for peak and then run at 10 to 20 percent utilization, and most miss their AI cost forecasts by more than a quarter.
3. The most underestimated is the vector database and retrieval layer, where storage I/O, query volume and embedding refresh appear nowhere labeled AI until the bill arrives.

The dimensions leaders underweight resilience and control

Cost and latency dominate the conversation. Two dimensions rarely get the same rigor until something breaks:

1. Resilience, whether an AI-dependent system can survive failure, degrade gracefully and recover predictably.
2. Control, who can observe, halt and audit it.

AI introduces failure modes that traditional architecture never faced: GPU single points of failure under revenue-critical inference, agentic pipelines that fail mid-execution with no rollback, and models that degrade silently from drift or throttling.

I see the pattern repeated across industries. Organizations design resilience for their traditional applications, then deploy AI on top without asking whether the same guarantees hold. In one global financial services firm I advise, a real-time credit-decisioning model running on a single cloud region took a 47-minute outage during a regional availability event. The halted loan approvals cost more than the system’s entire annual infrastructure budget, and the resilience rework that followed cost several times what designing it in from the start would have. The leaders who avoid this should ask four questions before go-live:

1. What happens when the network fails?
2. What happens when the model degrades?
3. What happens when an agent executes only halfway?
4. Who holds the authority to halt and audit?

What the cloud providers signaled this spring

The major providers are on track to spend close to $700 billion on AI infrastructure in 2026, roughly three and a half times the 2024 level. Their announcements are strategic signals, not just features. Last year they converged on one message: enterprises cannot run everything in public cloud, so all three built ways to bring their infrastructure into your data center and your sovereign environment. This year the signal advanced a step. They stopped talking about where workloads run and started shipping the layer that governs what agents are allowed to do: identity, containment, auditability and rollback.

Microsoft introduced an “Agent Computer” model with execution containers and machine identity for agents. AWS built Amazon Bedrock AgentCore around runtime, memory, identity and auditability. Google shipped an agent gateway and sovereign controls for cross-cloud traffic. As Bain observed, agentic AI is now an economics and operations problem, not just a capability problem. The through-line, captured by Microsoft’s own framing, is that AI alone will not change your business; the system running it will. McKinsey’s read is consistent: workloads are becoming more distributed, specialized and operationally demanding, which forces more deliberate infrastructure decisions.

From platform choice to placement decision

The failure I document most often is not a technology failure; it is a governance failure. Most enterprises lack a clear, repeatable way to decide what runs where, under what conditions and with what tradeoffs. Platform teams make that call informally, under deadline pressure and repeat it hundreds of times as new use cases launch. Workloads then accumulate in public cloud by default, not by design and 30 to 50 percent cost overruns follow, not because public cloud was the wrong choice but because no deliberate choice was ever made.

In one global manufacturer I advise, a predictive-maintenance model went live on public cloud and performed exactly as validated in staging. But real-time inference on the factory floor ran at 80 to 120 milliseconds across the WAN, when the machine-control system needed under ten. Moving the model to edge nodes fixed the latency, but the company lost most of a quarter of the cost, rework and delayed benefits, and the line had run for weeks on stale recommendations: a control failure that could have caused a safety event. The fix was never more AI talent. It was a structured placement decision at the start, weighing six dimensions:

• Latency: real-time (under 10 ms, edge or on-prem), interactive (50 to 500 ms, cloud) or batch.
• Cost and TCO: token spend, GPU utilization, vector-database queries, egress and unit economics per workload.
• Resilience: failover architecture, degraded-mode behavior, recovery SLA and rollback policy.
• Control: observability, audit trails, governance authority and the ability to halt or reverse.
• Data sensitivity: sovereignty requirements, privacy and compliance rules, and IP protection.
• Integration: legacy system dependencies, pipeline complexity and data-residency constraints.

Run consistently, those dimensions produce a placement pattern like this:

Workload	Latency	Cost predictability	Data sovereignty	Recommended path
Customer-facing chatbot	200-500 ms	Medium	Low risk	Public cloud, reserved instances
Real-time fraud detection	Under 10 ms	Medium	High	On-prem or sovereign private cloud
Clinical decision support	100-300 ms	Predictable	Critical	Sovereign cloud or dedicated VPC
Demand forecasting (batch)	Hours	High	Low risk	Spot instances or scheduled cloud
Factory-floor vision AI	Under 5 ms	Predictable	Medium	Edge node (Azure Local, AWS on-prem)
Internal knowledge assistant	1-3 sec	Variable tokens	High (IP risk)	Private cloud with on-prem retrieval

This is no longer optional. Cloudian’s 2026 enterprise AI infrastructure survey found that 79 percent of enterprises have already moved AI workloads out of public cloud, and 93 percent are repatriating or actively evaluating it, driven by data sovereignty, cost overruns and real-time performance. Repatriation is now the norm, not the exception.

The agentic layer makes discipline urgent. An agent chains 20 to 100 tool calls, each with its own latency, cost and failure mode, so the governance model that works for a chatbot does not work for an autonomous agent approving procurement or onboarding a customer. This spring the providers shipped production infrastructure for exactly this, yet Deloitte’s 2026 survey of more than 3,000 leaders finds only about one in five companies has a mature governance model for autonomous agents. The platforms solved the mechanism. Most enterprises have not yet written the policy.

What the leaders do differently

The organizations extracting compounding value from AI, not just running experiments, share one discipline: they treat workload placement as a repeatable process, and they build resilience and control in from the start rather than after the first production incident. In practice, they do five things:

1. Classify every use case at intake across the six dimensions, before any infrastructure is provisioned.
2. Separate AI budget lines for experiments, production inference and training, so cost is governable.
3. Treat unit economics, cost per inference, per query and per agent run, as engineering KPIs, not month-end surprises.
4. Define repatriation triggers in advance, typically 12 to 18 months of stable volume.
5. Write an explicit resilience contract, and agentic observability and rollback rules, before scaling.

The gap between strategy-ready and infrastructure-ready is the remediation backlog, and most enterprises stall moving from proof of concept to production for exactly this reason. Deloitte’s tech-trends analysis frames the same shift as the move to inference economics: the bottleneck is infrastructure governance, not model capability.

For CIOs, a 90-day agenda. Five actions separate the leaders from those managing infrastructure crises:

1. Audit every AI workload in production across latency, cost, sovereignty, volume, resilience, control and integration.
2. Separate AI infrastructure budget lines so each workload type is attributable and governable.
3. Define unit economics by workload and review them as engineering KPIs.
4. Set a quantitative repatriation evaluation trigger.
5. Define observability, cost attribution and rollback policy before scaling agents.

The strategic reframe

The organizations making real progress on AI are not distinguished by the sophistication of their models or the size of their cloud contracts. One discipline sets them apart: a clear, repeatable way to decide what runs where, under what conditions, with what tradeoffs and what happens when something fails. That discipline is not an IT problem. It is a strategic capability that requires CIO ownership, CFO alignment and executive accountability.

This spring the cloud providers handed enterprises the infrastructure to run and govern AI, and agents, at every tier of the architecture. The gap is no longer supply. It is the operating model to use deliberately. The companies building that model now build the operating foundation for AI at scale. Everyone else builds a remediation backlog. The infrastructure decisions you make in the next 12 months will decide which of those two you become.

This article was made possible by our partnership with the IASA Chief Architect Forum. The CAF’s purpose is to test, challenge and support the art and science of Business Technology Architecture and its evolution over time as well as grow the influence and leadership of chief architects both inside and outside the profession. The CAF is a leadership community of the IASA, the leading non-profit professional association for business technology architects.

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

IBM, its RedHat subsidiary, and Palo Alto Networks are teaming up to help enterprises identify vulnerabilities in open-source software and deploy safeguards against threats, particularly those generated by AI.

The joint effort will rely on Palo Alto’s network-based virtual patching technology, which is found in its Prisma security software, and IBM/Red Hat’s Project Lightwell, a software remediation initiative designed to help enterprises secure open-source software. Vulnerability intelligence from both vendors will also contribute to threat detection and remediation, the companies stated.  

Announced in May, Project Lighthouse is IBM and Red Hat’s $5 billion project to develop what IBM calls a “trusted enterprise clearinghouse combined with a global force of engineers to identify and fix vulnerabilities at scale.”

“The clearinghouse will serve as a security coordination layer, using advanced AI capabilities to validate and test fixes across an unprecedented volume of open source code,” IBM stated in May. “These capabilities will be offered through commercial subscriptions, allowing enterprises to integrate secure patches directly into their existing software supply chains with enterprise-grade validation and lifecycle management.”

Open-source software (OSS) underpins modern enterprise infrastructure, with more than 90% of Fortune 500 companies relying on OSS, IBM stated, citing a Worldmetric study.

IBM and Red Hat said they are working with a variety of early adopters on Project Lightwell, including Bank of America, BNY, Citi, Goldman Sachs, JPMorgan Chase, Mastercard, Morgan Stanley, RBC, State Street, Visa and Wells Fargo.

Key elements of the Palo Alto/IBM/Red Hat initiative include:

• Vulnerability coverage: Protection across open-source software, commercial applications, operational technology environments, and connected devices.
• Preemptive coverage: Organizations can receive virtual patch protections before official software patches become available, helping reduce exposure while remediation is underway.
• Rapid protection: When a new vulnerability is discovered, network-level protections can be deployed the same day, with a long-term goal of reducing the time from validated discovery to protection.   

The companies said they also plan to establish secure processes for sharing vulnerability information across participating software vendors, technology providers, and security teams. The idea is to accelerate protection development and provide anonymized telemetry on real-world exploitation attempts, the companies stated.

“AI has compressed the window between vulnerability discovery and exploit from weeks to minutes. Traditional patching cannot keep pace,” said Nikesh Arora, CEO and chairman of Palo Alto Networks, in a statement. “By collaborating with IBM and Red Hat, we are shifting the advantage back to defenders. This powerful combination allows us to neutralize threats in the network while providing uninterrupted business continuity for our global clients.”

IBM and Palo Alto have a long-running relationship of integrating security and enterprise-class networks. Recently, IBM and Palo Alto said they would combine to offer a service, Quantum-Safe Readiness, that would let enterprise customers identify cryptographic exposure, understand quantum-computing related risks, and accelerate their use of quantum-safe security technology.

In addition, the companies earlier this year said they would combine to offer a service designed to help enterprises discover, assess, and prioritize security and compliance risks for their artificial intelligence implementations in the cloud.

Unless you’ve been living under an old woodpile in your backyard, you have certainly seen how agentic coding is rocking the software development world. Things are happening fast and furious, and keeping up is practically a full-time job. 

The latest area that is catching the attention of developers is how agentic coding is affecting the open source community. The open source movement has been defending the rights of folks to use, change, and contribute to software for many years. And of course, agentic coding is starting to become part of that process.

On the one hand, maintainers of open source projects rightfully are frustrated as they become overwhelmed with pull requests of dubious quality and usefulness being submitted by coding agents. On the other hand, as David Heinemeier Hansson notes, maintainers are starting to get a little snooty about accepting AI-written code, viewing it as somehow not worthy of being included. Some organizations have explicitly banned AI-generated submissions.

I get that they don’t want AI slop overwhelming their input queues. But I think it is a huge mistake to ban AI-written code outright.

Whose code?

Before I dig deeper into that notion, it’s important to look at another issue that arises from all of this: Who actually owns the code that AI writes? 

Copyright requires that a human produce the thing being copyrighted. If you prompt Claude Code with “Write me a CMS system” and then Claude writes you a CMS system that you check into a public GitHub repository unchanged, it’s not quite clear if that code is protected by copyright. However, if you prompt Claude Code with a specification and guidelines and then you work with Claude to refine the initial result, reviewing the code and making changes as part of an iterative process, then it could be argued that a human did produce that code. But it is not at all clear-cut legally. (Please note that I am not a lawyer.)

The current thinking is that the result of accepting verbatim the output of a simple prompt is not copyrightable, and that no one actually owns the code — an interesting notion in and of itself. 

But then the ethical question comes into play. If I find a bug in an open source project, I ask GitHub Copilot to fix it, and Copilot writes a clever and effective fix, then who cares who owns the code? Should a maintainer of the project reject such a pull request just because it was AI-generated? That seems silly to me, yet it is happening today. 

Our code

There is, too, the issue of license compliance for AI-generated code. As a general rule, LLMs generate code rather than copying it. They don’t copy and paste code directly from repositories. However, there have been cases where AI-produced code has resembled open source code so closely that the claim could be made that it is a copy. If this happens with GPL code, it could be a violation of the license to use it without the receiving code base being “infected.” Open source maintainers naturally should be concerned about this happening.

In the end, an open source maintainer should care about the quality and license compliance of submissions, not how those submissions were derived. Gatekeeping based on the source of code doesn’t seem like a good path towards project success. Good code is good code, no matter where it comes from.

Agentic coding is here, and the open source community needs to realize — and embrace — that inevitability.

For the past few years, the most visible corner of the AI market has been easy to caricature: OpenAI gets the consumer attention, Anthropic gets the developer love, Google gets the benefit of the doubt with increasingly capable models and a complementary product suite, and everyone else gets to explain why they’re not dead yet.

That’s unfair, of course, but not completely wrong. In AI, attention compounds and it’s leading to outsized revenue, with both OpenAI and Anthropic reportedly rushing toward trillion-dollar-sized IPOs on the backs of billions in revenue.

So it’s easy to underrate Mistral AI.

Honestly, I hadn’t thought of the Paris-based company for a year. Maybe longer. But then Brian Hall announced he’s joining Mistral as CMO, and I had an Arrested Development “Her?” moment. Hall, a longtime Microsoft exec, hired me at AWS and went on to run product marketing at Google Cloud. His move prompted curiosity because Mistral doesn’t dominate developer chatter in the United States or boast the same seemingly endless compute budgets as Anthropic or OpenAI. If the AI market is simply a race to build the biggest, most magical, most general-purpose model, Mistral isn’t the company to bet on.

But that’s the wrong question, and likely the wrong bet.

The more interesting question is when the enterprise AI market will revert to type and demand that AI deliver the same security, predictability, and control we’re used to from other IT investments. Here Mistral has a real story. As Hall notes, Mistral’s approach is to “prioritize AI for mission-critical environments that need the confidence and self-control to bet for the long term (with open weights and real sovereign capabilities).”

While this might have sounded like an overly hopeful talking point, it became real in June when the US government ordered Anthropic to suspend access for foreign nationals to its most advanced Fable 5 and Mythos 5 models. Anthropic said it would disable the models for all users because of the export-control directive. “Can this vendor be forced to turn us off?” is no longer a theoretical question.

That’s why Mistral’s quiet focus on enterprise control just might work.

The wrong race

The enterprise control story is much more compelling than the narrative I used to hear. You know, the “Europe needs its own OpenAI” schtick. There is a market for “patriotic AI,” but it’s relatively small. The far bigger market is comprised of enterprises that just want AI that works, costs less (or delivers more) than expected, and can be customized while fitting their compliance requirements.

Though the company’s initial launch page went out of its way to mention that the company was operating out of Europe and headquartered in Paris, since at least October 2023 Mistral’s product posture has centered on enterprise control. Scattered throughout its current (and past) website are words like “customize,” “fine-tune,” “open source,” and “complete control.” Mistral pitches Studio for building and running AI apps, Forge for custom model training and alignment, Vibe for agentic work, Vibe for Code for coding workflows, and Compute for training and inference infrastructure. The company talks about observability, evals, guardrails, deployment portability, and running production AI “from edge to cloud.”

In other words, it sounds less like a chatbot company and more like an infrastructure company.

That positioning becomes clearer when you look underneath the product names. Mistral AI Studio includes an AI Registry that acts as a system of record for agents, models, data sets, judges, tools, and workflows. It tracks lineage, ownership, and versioning. It enforces access controls and promotion gates before deployment. That’s boring governance plumbing (and “boring” is good in enterprise IT, as I’ve written).

Forge may be even more important. Mistral describes it as a way for enterprises to train frontier-grade models on proprietary enterprise data. Rather than training on others’ copyrighted information strewn across the web or on a mountain of Reddit posts, Forge goes well beyond retrieval-augmented generation (RAG) to not simply “read in” proprietary docs/info/etc., but rather to give an enterprise its own private OpenAI, as it were. 

That’s super interesting.

But is it different? I mean, OpenAI and Anthropic can do plenty of this, with greater scale and the benefit of leading frontier models. Both have enterprise products, cloud partnerships, evals, agents, governance tools, and varying forms of model customization. Mistral’s bet with Forge isn’t that the big labs can’t customize models. It’s that some enterprises aren’t interested in customization as a side feature bolted onto a frontier API. It is the product. OpenAI and Anthropic can build everything around Forge but not Forge itself, because the one thing they almost certainly aren’t interested in selling is independence from them.

This is where Mistral may have found a useful seam, one that allows it to ask a different set of questions. What if the best enterprise model isn’t the smartest general-purpose model? What if the best model is the one that’s small enough to run where the customer needs it, open enough to inspect and adapt, cheap enough to use broadly, and specialized enough to do the job? What if “good enough, governable, and your own” beats “slightly smarter, mostly opaque, and rented”?

This won’t matter for every use case, of course. If I’m asking AI to reason through a spreadsheet or write code, I probably want the best model I can get. But for banks, defense agencies, manufacturers, utilities, telcos, and governments, “best” is multidimensional and includes questions like latency, auditability, etc. It’s why banks, for example, still run so many workloads on premises: They want control.

What about compute?

None of this makes compute irrelevant. But it may change how compute matters.

If Mistral is trying to be a French version of OpenAI, its lack of hyperscale compute is a fatal weakness. It won’t outspend OpenAI, Oracle, Microsoft, Google, Amazon, SpaceX, or Anthropic. It probably won’t out-recruit them across every frontier research area, either. The AI market is already littered with companies that underestimated how quickly “good model” became “not good enough.”

But if Mistral is trying to become the enterprise-controlled AI layer for organizations that don’t want all intelligence to live behind someone else’s API, compute becomes a more nuanced issue. It still needs infrastructure, and Mistral seems to know it. After all, Mistral raised $830 million in debt to buy 13,800 Nvidia chips for a data center near Paris. That’s a rounding error compared to OpenAI and Anthropic, of course, but the real question is whether Mistral can turn relative compute scarcity into a virtue, like Amazon’s Leadership Principle “Frugality” on steroids. If lower compute capacity leads Mistral to deliver smaller, more efficient, and more specialized models, which in turn helps enterprises maintain more control of their data at lower cost, then less really does become more.

Mistral’s compute challenge, then, is not to try and have as much compute as OpenAI. It’s to make customers care less about raw compute scale and more about deployment flexibility, specialization, and control.

That’s a hard sell. But it’s not a dumb one.

What Mistral must prove

The bear case remains obvious. OpenAI has consumer distribution, developer mindshare, capital, and a brand that has basically become synonymous with AI. Anthropic has become the developer darling and has an unusually strong enterprise story of its own. Google has the models, the infrastructure, the data, and a bevy of complementary services. AWS, Microsoft, and Oracle have customer relationships and infrastructure.

Mistral has to prove that there’s room for another center of gravity. More specifically, it must prove three things.

First, it has to show that open-weight and controllable AI matter enough to influence buying decisions, not just conference panels. Everyone says they want control, just as most like the idea of open source. But proprietary software and cloud services still dominate the market. Mistral must make control feel like the easy button.

Second, it must prove that specialization beats generality in enough high-value markets. “Our model is almost as good” is not a strategy. “Our model is better for your bank, your government agency, or your retailer” just might be.

Third, it needs to establish a beachhead within enterprise IT before OpenAI and Anthropic become “boring” enough to satisfy the same buyers. This is the real race. The biggest AI companies are hiring enterprise sales teams, building admin controls, and cutting deals with every major cloud. Mistral’s window exists because the market is still young, but that window won’t stay open much longer.

If AI remains a model benchmark race, Mistral likely loses. But if AI keeps evolving to become grown-up enterprise infrastructure, Mistral has a real chance.

A new form of vendor lock-in is here. And it’s not proprietary languages or rigid enterprise software suites — it’s something more fundamental. It’s the very thing that writes the code.

JetBrains Research found that 74% of developers worldwide use AI tools. Claude Code, available only since May 2025, is now the most popular AI coding tool, followed by Gemini Code Assist and GitHub Copilot, according to Jellyfish’s 2026 State of Engineering Management Report.

The latter study also found that 91% of developers say their productivity has increased in the past 12 months. As coding output expectations are rewritten daily, the engineering world is becoming heavily reliant on paid external AI services.

Gartner predicts that by 2028 spending on AI coding tokens could exceed developer salaries. Yet, tokenmaxxing while vibe coding through a vendor’s cloud-based API feels like a far cry from the open foundations of free programming languages and open models, which many of today’s AI platforms now abstract.

“Open infrastructure will be the backbone of the AI era,” says Peter Farkas, CEO of Percona, a provider of open-source database solutions. “Right now, too many companies are building their entire AI strategy on top of proprietary platforms because the convenience is seductive.”

“It’s ‘three clicks’ to stand up a database or an AI service in a hyperscaler, and that convenience blinds people to the lock-in they’re signing up for,” he adds. “As AI workloads mature, organizations will realize that depending on one vendor for their data, models, runtime, and pricing is not a strategy.”

AI-assisted coding is democratizing software engineering for non-engineers and accelerating top performers. But if teams are always working within the confines of how one platform thinks the world should work, it could create locked-in toolsets at scale. And as AI platform costs rise, a fundamental question arises: will software developers consume AI on their own terms, or on someone else’s?

There’s a strong case that the long-term winners in tech will be built on open-source standards and foundations, similar to the history of cloud-native computing and the internet itself.

“Open always wins,” says Brian Alvey, CTO at WordPress VIP, a managed WordPress hosting platform. “Not because it’s a fancy ideology, but because it gives you total freedom to adapt, evolve, and stay in control.”

Open infrastructure avoids a future where developers perpetually rent. “For AI to be useful to people at large, it can’t be something you’re paying rent for the rest of your life,” says Manik Surtani, CTO and co-founder of the Agentic AI Foundation (AAIF), a vendor-neutral home for open-source agentic AI technologies. “And it can’t be concentrated in one particular corporation or a small handful of corporations, because we know how that goes.”

Pricey, closed, proprietary AI

AI development today is traveling two parallel paths. On one path, open-source AI is thriving and fueling tremendous growth in the number and variety of AI models and tools. Just take the thousands of open-weight models on HuggingFace, the community around the OpenClaw AI agent, or the many academic institutions publishing new breakthroughs.

“Open-source models and tooling are hot on the heels of state-of-the-art, with interesting and boundary-pushing work being shared by labs and researchers across the world,” says Austin Parker, director of AI strategy at Honeycomb, an observability platform provider, citing frontier open-source models like Mistral, DeepSeek, and Ai2’s OLMo as examples.

Others agree. “There’s unprecedented openness at the model and tooling layer, with open-source models, frameworks, and orchestration advancing at remarkable speed,” says Mark Collier, general manager of AI and infrastructure at the Linux Foundation.

On the other path, we’re seeing heavy reliance on proprietary AI systems controlled by Anthropic, Cursor, Google, Microsoft, OpenAI, and others. As Collier says, “Many platforms are wrapping those open components in closed, opinionated interfaces that trade short-term speed for long-term constraints.”

Open source and the AI tooling market don’t always mix well. LangChain’s Open Agent Platform, for instance, was open-sourced to much fanfare in 2025, but by 2026 had been deprecated, with the repository now recommending fully managed alternatives.

For Roman Shaposhnik, co-founder and CTO of Ainekko, provider of an open-source, composable AI stack, the current AI platform landscape is reminiscent of low-code and no-code platforms, which promised democratization of software development but often failed to deliver, becoming synonymous with platform lock-in and inflexibility.

“Honestly, it feels familiar,” Shaposhnik says. “We have incredibly powerful AI tools right now, but most of them come bundled as tightly controlled platforms.” This is a risk for AI, he says, because the infrastructure, models, and hardware are tightly coupled. “If those layers are closed, you lose flexibility fast.”

Some abstractions that sit on top of models, like routing and agent frameworks, tend to be tightly coupled and optimized for certain models. Other platforms take the walled garden concept quite literally. Anthropic, for instance, has repeatedly made headlines for blocking access to its Claude models over vague policy violations. The company recently shut off competitor xAI’s use and stonewalled OpenCode, drawing community backlash.

Moves toward increasingly closed systems don’t bode well for an AI economy already built on shaky economics. As Vikram Srivats, head of product experience at WaveMaker, provider of an agentic application development platform, adds, “Given the unit economics of AI tooling and pace of accelerated change to keep up, it seems obvious that some will evolve to more of a closed system to be able to monetize and gain ROI.”

Why openness matters in the AI era

Reliance on proprietary AI platforms can create long-term operational dependencies. As systems become less interoperable, organizations may be forced to standardize on a single stack across data pipelines, models, and decision logic, says the Linux Foundation’s Collier.

“As infrastructure consolidates, enterprises become more exposed when platforms change direction, raise prices, or fall behind technically,” he says. “If you can’t change platforms without re-architecting your AI systems, you’ve already given up too much control.”

“When you build on someone else’s platform, you have to live by their rules and those rules always change,” adds WordPress VIP’s Alvey. “We’ve all seen this before, businesses wasting time and money building to serve Google, Facebook, YouTube, and the App Store, instead of building to serve their customers.”

Platform lock-in can also create direct business risk. As Ainekko’s Shaposhnik says, “It usually shows up as higher costs, fragile systems, and growing risk when it’s time to change direction.”

At Ainekko, an internal group called the AI Plumbers focuses on back-end AI infrastructure like inference, scheduling, memory, and hardware integration. “Their view is simple,” says Shaposhnik. “If those layers are closed, everything above them becomes fragile.”

Open standards, interfaces, and infrastructure provide a necessary hedge against closed systems to prevent this sort of fragility. “In the AI era, open infrastructure gives enterprises control, portability, and choice at exactly the time they need it most,” says Percona’s Farkas.

It can cost upwards of $100,000 to migrate enterprise software, according to Cloudaware, making portability a major enterprise concern. From this perspective, procuring closed systems can become a costly architectural dependency.

Others argue that openness is a critical hedge against vendor concentration risks at large, especially if AI replaces human labor en masse. “If all of that economic value is now being concentrated in the hands of one or two companies,” says the AAIF’s Surtani, “that’s an order of magnitude bigger problem than we’ve seen in any other wave of computing.”

Instead, open foundations allow adaptability to evolving conditions so enterprises can swap out models, agents, data, hardware, and orchestration, as needed. “Open standards let those components change independently without breaking the system,” says Collier. 

Openness can also help future-proof businesses against economic upheaval. “Open everything will help build a cushion for businesses and users to survive and thrive after the almost-certain correction in the current hype cycle,” says WaveMaker’s Srivats.

Momentum toward open AI infrastructure

At the industry level, momentum toward open AI infrastructure is growing. The establishment of the Agentic AI Foundation, Anthropic’s donation of Model Context Protocol (MCP), and Block’s donation of its Goose agent are significant ecosystem-wide moves toward openness. Other advances include the donation of llm-d, a Kubernetes framework for LLM inference, to the Cloud Native Computing Foundation (CNCF).

For Parker, donations like this help ensure long-term support and care. “Open standards aren’t just the foundation of the internet, they’re the foundation of the AI space,” he says. “I predict that we’ll see these practices continue, especially as enterprise adoption increases in earnest,” he adds.

Still, some question whether this level of stewardship is enough for a rapidly evolving ecosystem. “The internet benefited early on from groups that helped keep vendors aligned,” says Shaposhnik. “In AI infrastructure, we don’t really have that yet.”

“All of us open source veterans are hopeful,” he says, “but we also need to adapt to this new reality in what we do regarding AI infrastructure.”

Beyond industry governing bodies, companies themselves are also spearheading open AI initiatives. Warp, an agentic development environment, recently went open source amid closed-source rivals. Arcade.dev, meanwhile, is pushing an open-source Agent Library for agentic memory.

Where openness matters most in the AI stack

While AI infrastructure can be open in many ways, a few layers stand out as especially important. First is the openness of the model itself. “Open-source models must be the foundation of future trust and value,” says WaveMaker’s Srivats.

“The forms of open infrastructure that reduce integration friction and accelerate adoption stand out,” adds Neeraj Abhyankar, VP of data and AI at R Systems, a global digital solutions provider. For him, open model representation formats, open orchestration and execution layers, open agentic protocols, and open governance and metadata standards are all essential for enterprise flexibility.

Others place more value on the connective tissue between AI components. “The most important forms of open infrastructure are the ones that connect systems together,” says Collier. “That includes open APIs, metadata standards, identity and policy frameworks, and protocols for how models and agents communicate.” 

Arguably, MCP has become the connective tissue between AI agents and the broader API ecosystem. “If we get MCP right we unlock the same level of interoperability between entities on the web and models driving them as we came to enjoy during the Web 2.0 era and the API-first boom,” says Shaposhnik. “If we don’t we risk massive proprietary lock-ins.”

Parker agrees that open protocols will underlie future AI progress. “We’ll see continued development and progress on AI agents which will rely on protocols like MCP and ACP [Agent Client Protocol] to interoperate with various clients and each other,” he says. Yet a gap remains around API conventions for models. “It would be nice if we could get a commitment from model providers to use a standard here.”

For the AAIF’s Surtani, opening up the protocol layer is the most important aspect. “I think it’s really important for interoperability, for choice,” he says. “It means you can bring your own agent, you can bring your own framework, you can bring your own harness, and pick what model you want.”

Open standards may also play a significant role within inference architecture. “As AI expands to the edge, developers need visibility into how models run, how memory is used, and how performance scales,” says Shaposhnik. Open systems could make it easier to optimize, debug, and adapt while helping enterprises avoid observability fragmentation.

Lastly, cloud-native architectural standards are a key ingredient for open AI infrastructure. “We’re seeing Kubernetes become the missing link for people who want the hyperscaler-style convenience without hyperscaler lock-in,” says Percona’s Farkas. For him, Kubernetes has become the de facto hybrid enterprise deployment option for data, workloads, and AI components.

History repeats itself

The 2026 State of Open Source Report found avoiding vendor lock-in to be the primary driver of open source adoption. But beyond being a strategic decision for a single company, open infrastructure provides a layer for entire industries to be built upon.

Arguably, the internet itself is evidence of this, where groups like the IETF and the IEEE were instrumental in defining the fundamental protocols. “Without open protocols we would’ve been in telco hell and without phenomenons like Google or Facebook,” says Shaposhnik.

Or, take the history of Linux as a parallel. “Linux became the default operating system because it offered a common, vendor-neutral foundation that everyone could build on,” says Collier. “In the AI era, open infrastructure will define the layers that organizations rely on for long-term continuity.”

At the infrastructure level, open standards have repeatedly underpinned major platform shifts, from Docker to Kubernetes. The question now is whether AI will develop a similarly durable standards layer.

For Parker, it’s too early to say, but the current growth of AI mirrors the early cloud. “Remember that it took many years before we saw the development and popularization of the open source cloud-native ecosystem,” he says. “I think it would be a mistake to extrapolate from the current trajectory towards a closed, proprietary future.”

Others agree the future must be rooted in openness. “I see open infrastructure becoming the foundation of enterprise AI,” says R Systems’s Abhyankar. “As systems become more distributed and agent‑driven, closed ecosystems simply won’t scale.”

The groundwork is being laid through open agentic protocols, open frameworks, and industry support intended to reduce fragmentation around proprietary standards.

“Ironically, the AI movement has mostly seemed to learn from the mistakes of the past and is starting off on a more open foot,” says Parker. “Over time, I believe we’ll see innovation and openness thrive.”

Many IT leaders looking to capitalize on the promise of agentic AI still struggle with a basic step — building out their agentic architecture — even as they roll out dozens or hundreds of agents.

AI agent deployment is expected to skyrocket over the next year, with IDC predicting a tenfold increase in agent use by large enterprises by the end of this year. But in some cases, CIOs haven’t focused on the building blocks needed to run a huge team of agents, experts say.

Many CIOs have underestimated the infrastructure work required to get agents to scale responsibly, says Hilary Packer, EVP and head of enterprise data and AI at American Express.

“There’s a tendency to focus on what an agent can do and then move quickly to deployment before the underlying infrastructure is in place,” she says. “It is essential to first build the enterprise capabilities that allow agents to operate consistently across systems, data sources, and workflows.”

IT leaders must also set up well-governed data foundations, but many companies still operate with fragmented systems, inconsistent data definitions, and siloed ownership structures, Packer adds.

“Before deploying increasingly sophisticated models and agents, organizations need confidence that the underlying data is accurate, accessible, and fit for purpose,” she says. “That requires investments in governance, lineage, and modern data infrastructure that allows information to move efficiently across the enterprise.”

More than an IT challenge

Packer sees agentic AI as much a governance and operating model challenge as a technology challenge. In some cases, IT teams are reinventing the wheel with each agent pilot, she suggests.

“As organizations experiment, teams often end up rebuilding the same capabilities repeatedly — for example, identity management, access controls, monitoring, and observability,” she says. “That may be sufficient for isolated pilots, but it becomes difficult to manage and scale across the enterprise.”

What agentic architecture really requires

CIOs need to take a wholistic approach to agentic architecture. While some IT leaders think of architecture as the AI model powering agents, it goes much deeper.

Agentic architecture includes several elements, and in some cases, CIOs have underinvested in some functionality, says Saurabh Pitkar, director of product management for agentic commerce at Dell Technologies.

Agentic architecture, Pitkar says, includes an orchestrator, the brain that controls subagents; subagents themselves, which have specialized functions; APIs and other tools; memory to maintain context of an agent session and overall behavior over a longer period; and guardrails to set boundaries for agents

Many organizations are now building agentic architecture, but those still struggling have failed to make the right investments in areas such as building memory and creating MCP tool standardizations, Pitkar says.

A lack of data access and integration can be a huge barrier to agent deployments despite heavy investments in data modernization, he adds.

In addition, IT leaders struggling to deploy agents have often failed to manage organizational changes to account for a faster, agent-driven delivery cycle, he says. Adoption can slow down considerably if teams aren’t ready to engage with agent-speed outputs.

“AI does not care about org structure when it comes to accessing data,” he says.

Use cases determine the details

While the elements of agentic architecture are fairly standard, CIOs may need to focus more on different functionality depending on the use case, according to Pitkar. The devil is in the details.

“Customer support may need higher investments in dynamic intent mappings, memory, effective UX as these are emotionally charged conversations with human users who need a problem solved to continue their job,” Pitkar adds. “Agentic commerce may focus on deterministic APIs with machine readable data, guardrails, and compliance to securely process transactions with real money.”

Another way to look at agentic architecture is to think about four layers:

• System of context, including unified, semantically enriched data
• System of work, or composable application services agents can act on
• System of agency, where planning, coordination, and governance live
• System of engagement, the interfaces that enable agents to interact with employees and customers

Most organizations have these four functions happening in other enterprise software packages, but they are built for human-paced orchestration instead of machine-speed agents, says Shibani Ahuja, SVP for enterprise IT strategy at Salesforce.

“Agentic architecture is the enterprise foundation that allows AI agents to autonomously reason and act — not just respond — in a way that’s governed and secure,” she says. “It’s the difference between an AI that drafts an email and an AI that closes tickets, triggers payments, and updates records, without waiting for a human to pass the baton.”

Ahuja sees organizations struggling to even define agentic architecture, much less deploy it. Throughout 2025, she heard CIOs describing how they implemented AI on a scale.

“If you listened carefully, one was describing predictive AI, one generative AI, and one an agentic workflow that was really just a sophisticated chatbot,” she says. “We were using the same word for fundamentally different things. When the ROI didn’t materialize, organizations didn’t know what had actually failed.”

Agent deployment struggles, meanwhile, have been less about capability and more about where organizations focus their energy, Ahuja says. Many IT leaders focus on the agent, including the use case, the prompt, and the model, but it’s just as important to ask whether the organization’s architecture actually supports its agentic goals, she adds.

“Can agents access real-time, governed data across your entire business?” she says. “Can they act across systems with minimal human input to reconcile inconsistencies? In most enterprises, the honest answer is not yet, and no amount of prompt tuning fixes that.”

Setup is only the first step

It’s now trivial to set up an agent, with most organizations able to do it in days, if not hours. But the work doesn’t stop there, says Adam Field, chief AI officer at workflow automation provider Tungsten Automation.

Good agentic architecture allows agents to operate reliably inside real business processes, not just in isolation, he says. For the past 30 years, enterprise systems were built for humans to navigate UIs, but agents work silently on the inside by calling APIs and requiring action-level permissions rather than login access.

The underestimated piece of agentic architecture is the governance controls that define what agents can do autonomously and when they must stop and hand off control to a human, Field says.

“Deploying an agent on a discrete task is straightforward,” he adds. “The hard part is that businesses don’t run on discrete tasks.”

Instead, enterprises operate on end-to-end, regulated processes with exceptions, dependencies, compliance requirements, and humans in the loop at specific moments, he notes.

“Designing agentic architecture that works across an entire process, not just a single step, is a fundamentally different challenge,” Field adds. “Traditional software fails obviously. Agents fail silently, confidently, at scale.”

Open-Source-Code ist in Unternehmen allgegenwärtig; Schätzungen zufolge nutzen mehr als 90 Prozent der Fortune-500-Unternehmen ihn in ihren Software-Lieferketten. Open-Source-Code ist jedoch bekanntermaßen voller Schwachstellen und das Aufspüren und Beheben dieser Fehler kann für Sicherheitsteams zu einem endlosen Kampf werden.

IBM und Red Hat setzen darauf, dass eine neue Initiative, Project Lightwell, dazu beitragen kann, diesen Prozess zu beschleunigen. Im Rahmen des Projekts wollen die beiden Unternehmen fünf Milliarden Dollar sowie 20.000 Ingenieure von IBM und Red Hat bereitstellen, um eine Art „Clearingstelle“ für Unternehmen aufzubauen.

Den Unternehmen zufolge soll diese als KI-gestützte „Sicherheits-Koordinierungsebene“ dienen und Unternehmen die Möglichkeit geben, Patches direkt in ihre bestehenden Software-Lieferketten zu integrieren.

„Project Lightwell“ befindet sich derzeit in der Konzeptphase mit einer Gruppe von elf Finanzpartnern und soll später als kommerzielles Abonnement angeboten werden.

„Die Fortschritte bei KI-Tools haben die Patching-Landschaft revolutioniert – also die Fähigkeit, Schwachstellen in Software zu entdecken, ohne dabei an Behebungsgeschwindigkeit einzubüßen“, erklärt Ashesh Badani, Senior Vice President und Chief Product Officer bei Red Hat, gegenüber CSOonline. „Jeder nutzt Open-Source-Software und die Herausforderung besteht darin, Schwachstellen nicht schnell genug beheben zu können.“

Die Lücke bei der Behebung von Schwachstellen schließen

Die Sicherheitsprobleme bei Open-Source-Software sind gut dokumentiert: Fast 50.000 Common Vulnerabilities and Exposures (CVEs) wurden im Jahr 2025 veröffentlicht, und das Project Glasswing von Anthropic, das auf dem Mythos Preview-Modell basiert, fand kurz nach dem Start rund 3.900 bisher unentdeckte Schwachstellen mit hohem oder kritischem Schweregrad in Open-Source-Software.

IBM betreibt eines der größten kommerziellen Open-Source-Ökosysteme und nutzt mehr als 62.000Softwarepakete in Umgebungen wie Linux, Kubernetes, Kafka, Terraform und Java. Das Unternehmen bietet dort bereits Lebenszyklusmanagement, Validierung und Patching an.

Mit Project Lightwell sollen diese Prinzipien nun auf KI-Frameworks, unabhängige Bibliotheken, Sprach-Toolchains und Daten-Streaming-Plattformen ausgeweitet werden. Ziel ist es, validierte Sicherheitskorrekturen für Open-Source-Code bereitzustellen, der bereits in Unternehmensumgebungen eingesetzt wird – ohne Stabilität, Zertifizierungen oder Compliance-Anforderungen zu beeinträchtigen.

IBM zufolge sind dafür keine Upgrades oder der Zugriff auf den Quellcode erforderlich. Project Lightwell werde Sicherheitskorrekturen auf genau die Abhängigkeitsversionen zurückportieren, die bereits getestet und bereitgestellt wurden. Die Lösung arbeitet auf Basis von Konfigurationsdateien wie pom.xml, sodass der Code innerhalb der kontrollierten Unternehmensumgebung verbleibt. Der anfängliche Fokus liegt auf Java/Maven, später sollen auch PyPI, npm, Go und weitere Plattformen unterstützt werden.

Diskrete Fehlerbehebung möglich

Unternehmen sollen zudem die Möglichkeit erhalten, sensible Schwachstellen unter Embargo über ein „sicheres Vermittlermodell“ zu teilen und validierte Patches zu erhalten, die Red Hat-Plattformen und unabhängigen Community-Code abdecken. Darüber hinaus können sie Korrekturen über Abhängigkeitsketten hinweg bereitstellen, Probleme in aktiven Produktionsumgebungen melden und beheben sowie Korrekturen an die Upstream-Community weitergeben, damit diese sie integrieren kann.

„Wir wollen sicherstellen, dass alle Korrekturen, die wir den Unternehmen über die Clearingstelle zur Verfügung stellen, auch wieder ihren Weg zurück in die Open-Source-Projekte finden, die [den Code] entwickelt haben“, erklärt Badani. „Wenn beispielsweise ein Stück Python-Code gepatcht wurde, soll die Korrektur schnell an die Python-Community zurückgeliefert werden.“

Mithilfe fortschrittlicher KI und in Zusammenarbeit mit führenden Open-Source-Mitwirkenden werden sich die Ingenieure von IBM und Red Hat darauf konzentrieren, Upstream- und Downstream-Umgebungen besser zu verbinden, damit die Korrekturen sofort für Unternehmen nutzbar sind. Zudem sollen sie Patches entwickeln, große Mengen an Schwachstellen analysieren und priorisieren sowie Abhängigkeiten absichern.

Badami zufolge stammen die 20.000 Ingenieure aus den bestehenden Teams von IBM und Red Hat. Bei Bedarf sollen weitere Fachkräfte hinzugezogen werden. Die Unternehmen wollen sowohl moderne Foundation-Modelle führender KI-Labore als auch eigene KI-Werkzeuge und Frameworks einsetzen. Die fünf Milliarden Dollar werden in KI-Werkzeuge und den Aufbau der erforderlichen Infrastruktur investiert.

Zu den frühen Unterstützern von Project Lightwell zählen unter anderem Bank of America, BNY, Citi, Goldman Sachs, JPMorganChase, Mastercard, Morgan Stanley, Royal Bank of Canada, State Street, Visa und Wells Fargo. Nach der Designphase soll das Angebot schrittweise weiteren Kunden über ein Abonnementmodell zugänglich gemacht werden.

Ein Aufruf zum Handeln?

David Shipley von Beauceron Security bezeichnet die Initiative als „dringend notwendig“, wenn Unternehmen Open Source langfristig erhalten wollen. Die Zeit, in der Billionenwerte auf der Arbeit freiwilliger Entwickler beruhten, sei mit Claude Mythos abrupt zu Ende gegangen. Nun müssten Unternehmen ihren Beitrag leisten, um Open Source zu unterstützen.

„Wenn wir keinen Weg finden, in Open Source zu investieren, besteht die Alternative darin, dass jeder seinen eigenen maßgeschneiderten Code mithilfe von KI entwickelt“, erklärt Shipley. Das wäre aus Rechen- und Umweltperspektive „enorm verschwenderisch“.

Menschen bleiben unverzichtbar

Red-Hat-Manager Badani betont, dass KI zwar hervorragend darin sei, Sicherheitsprobleme in Open-Source-Code aufzudecken, der Prozess der Fehlerbehebung jedoch nach wie vor mühsam sein kann. Korrekturen müssten zunächst an die Entwickler weitergeleitet, an die Open-Source-Community verteilt und dann an Kunden und Nutzer zurückgespielt werden.

„Den Fehler zu finden ist eine Sache“, so Badani. „Die eigentliche Herausforderung sind die vielen Schritte, die erforderlich sind, um ihn tatsächlich zu beheben. Genau diesen zusätzlichen Zeitaufwand wollen wir verkürzen.“

Während die öffentliche Diskussion häufig davon geprägt sei, menschliche Entwickler durch KI zu ersetzen, verfolge Project Lightwell den gegenteiligen Ansatz, fügte der Red-Hat-CPO an „Wir können das Problem mit einer Kombination aus KI-Tools und menschlichem Wissen und Fachkompetenz angehen. Die Verbindung beider Aspekte führt zu einem besseren Ergebnis als ausschließlich das eine oder das andere zu nutzen.“ (mb)

The rapid uptake of agentic AI has exposed a range of issues with our non-deterministic helpers. That’s mainly because AI agents are not people and don’t behave like people, even though they generally use the same APIs as humans. For one thing, they make many more queries than a human would, as they build the necessary context to deliver a response.

Anecdotal data from companies that have worked with agents or who have users who access services through agents indicate that this can mean massive increases in API usage, which have affected availability. This increase is the result of automated requests flooding in and blocking calls and responses from APIs that worked perfectly well a year or so ago but now are struggling to cope with the load.

A fundamental redesign of our APIs is necessary, but budgets, resourcing, and capacity make this hard to deliver overnight. What’s needed, then, is a way to manage agent interactions with APIs, treating agents as a new class of user, providing and enforcing the policies that are needed to manage agent life cycles. The use of Model Context Protocol (MCP) as a standard wrapper for agent access to APIs helps here, as it gives us a common environment where we can implement the governance layer needed to keep agents under control.

Microsoft recently launched a public preview of its open-source Agent Governance Toolkit (AGT), which is intended to wrap policy-based enforcement around agents, ensuring that calls are evaluated before they’re made. You can think of the toolkit as a way to manage agent actions, rather than controlling the inputs and outputs of the large language models (LLMs) your agents use. Figures from Microsoft suggest that this method of securing agents is far safer than relying on rules in prompts. However, in practice it’s a good idea to run a capability tool like Agent Governance Toolkit alongside traditional filters to trap user errors and prompt-based attacks.

AGT is a set of tools designed to cover OWASP’s list of agentic risks, building on Microsoft’s experience securing its own agents and AI platforms, with more than 13,000 tests built into the toolkit. It works by evaluating actions before they’re run, checking them against your policies, before allowing or denying the action and logging the results. Microsoft expects policy evaluation to take less than 0.1ms per operation, keeping overheads to a minimum.

Policies for agents

OWASP’s top 10 agent risks lists the most significant issues that can disrupt agent operations resulting from user prompts and bad application design. These risks include agent goal hijacking, uncontrolled code execution, insecure output handling, and agents going rogue. Features in the toolkit are designed to protect agentic applications from these and other issues, using isolation and sandboxing, as well as validating outputs using content policies.

You can use declarative programming techniques to build the policies that define the limits of your agents’ operations. As the policies are human-readable, you can share them with colleagues and refine them across projects to produce a common set of AGT rules for all agents running inside your organization.

The resulting authorization model is intent-based, with agents declaring their intent, which AGT approves or denies. The policy then determines what operations are allowed, whether they’re permitted with an alert, or blocked. This approach allows your code to check orchestrated operations for drift from the top-level intent. When your code is running a harness for multiple parallel agents, this helps keep the application on track and reduces the risk of unwanted operations and using too many tokens.

Agent behavior often results in using more tokens than expected, so keeping spend under control is another role for AGT. As platforms move to new pricing and budgeting models, the ability to control the number of tokens that can be spent on an agent interaction will become very important indeed, and the ability to set a token budget in an AGT policy will allow developers to prevent users from significant unintended spend. AGT’s budget management tools can be used to throttle activities as agents approach preset limits, and to reject actions if they look likely to use excessive tokens.

Monitoring and manag agents in action

You can even use AGT to manage API calls, something that’s becoming increasingly important as agent context-seeking activities can quickly overwhelm APIs designed for human interactions. By building rules that limit the number of calls in a set amount of time, you can now have your agent framework manage throttling for you rather than implementing complex API management tools.

One key feature of AGT is the ability to use its mix of declarative policies to find agents that are drifting from your set baselines, helping spot issues before they cost money or affect operations. AGT also can be used to apply kill switches where necessary. Logging and observability capabilities include a way to provide a root cause analysis of issues, along with what Microsoft calls a “decision bill of materials” that keeps track of governance decisions with an audit chain and the details of the trust levels associated with agents.

A toolkit like AGT needs to be vendor neutral, as your agents could be working with models running in any environment. AGT is designed to work with Azure Foundry, Amazon Bedrock, and Google ADK, as well as with most common agent orchestration frameworks. AGT supports five different programming languages: Python, TypeScript, .NET, Rust, and Go. While capabilities vary between the different implementations, the Python version has the full set.

Microsoft has made some interesting architectural decisions in AGT. Perhaps the most important is that it treats agents as code running on a secure operating system, using concepts from hypervisors to isolate agents from the underlying platform. You can see this in the way the underlying components and packages are named; the core governance package is called Agent OS.

Building AGT into your code

Getting started with AGT can be as simple as installing the complete toolkit using standard package manager of your language of choice. You don’t need to install the whole thing. You have the option of installing specific packages when you don’t need all the features, or when you only want to use a single function. You could download only AGT’s software reliability engineering tools, for example, when you want to put your agents through chaos testing.

You can define policies inside your code or as external policy documents. Policies are focused on key security and governance goals, such as blocking dangerous tools from running, looking for PII in messages, and showing users what action has been taken and why. External policy documents are recommended for use with production AGT implementations, as they let you author policies in YAML. The toolkit provides a single call to load all the policy files in a directory, so it’s a good idea to store only production policies in that location to avoid issues.

Adding support for AGT in existing code is a matter of adding evaluations before your agent framework makes a call. This can be handled using refactoring tools in your editor, finding the call and wrapping the evaluator and decision results around it. This way you can develop agents without using AGT, adding its tools when you’re confident you have a working agent. Microsoft provides custom adapters for 19 different frameworks, tuned to work with them. These can be loaded alongside the rest of the toolkit.

AGT is a sign of growing maturity in our agent landscape, applying enterprise rigor to what has been something of a Wild West free-for-all. It addresses many of the concerns associated with using agents at scale, helping control both agent behavior and costs. Autonomous software needs to be kept on a leash, and AGT’s declarative approach to building and applying policies — along with the rest of its suite of tools — gives you the ability to quickly build and apply the necessary controls.

With companies looking to control costs and regulators wanting to ensure that agentic software doesn’t violate compliance requirements, tools like the Agent Governance Toolkit will likely become an essential part of our modern agent development environment.

기업 환경에서 오픈소스 코드는 사실상 필수 요소가 됐다. 포춘 500대 기업의 90% 이상이 소프트웨어 공급망에 오픈소스 코드를 포함하고 있는 것으로 추정된다. 그러나 오픈소스는 수많은 보안 취약점을 안고 있는 경우가 많아, 이를 찾아내고 패치하는 작업은 보안팀의 끝없는 과제로 꼽힌다.

IBM과 레드햇은 이러한 문제를 해결하기 위해 새로운 프로젝트인 ‘프로젝트 라이트웰(Project Lightwell)’을 추진한다.

29일 공개된 프로젝트 라이트웰은 50억 달러(약 6조 8,000억 원)와 IBM 및 레드햇 엔지니어 2만 명을 투입해 오픈소스 소프트웨어의 취약점 발견과 대응을 가속화하는 새로운 ‘엔터프라이즈 클리어링하우스(Enterprise Clearinghouse)’를 구축하는 것이 목표다. 양사는 이 클리어링하우스가 AI 기반 ‘보안 조정 계층(Security Coordination Layer)’ 역할을 수행해 기업이 기존 소프트웨어 공급망에 패치를 직접 통합할 수 있도록 지원할 것이라고 밝혔다.

프로젝트 라이트웰은 현재 11개 금융기관과 함께 설계 단계에 있으며, 향후 구독형 상용 서비스로 제공될 예정이다.

레드햇의 수석부사장 겸 최고제품책임자(CPO) 아셰시 바다니는 “AI 도구의 발전으로 취약점을 발견하면서도 대응 속도를 유지할 수 있는 환경이 마련됐다”라며 “대부분의 기업이 오픈소스 소프트웨어를 사용하고 있지만, 취약점을 충분히 빠르게 해결하지 못하는 것이 가장 큰 과제”라고 CSO온라인에 설명했다.

취약점 대응 격차 해소 나선 IBM·레드햇

오픈소스 보안 문제는 이미 널리 알려져 있다. 2025년 한 해 동안 공개된 공통 취약점 및 노출(CVE)은 약 5만 건에 달했다. 또한 앤트로픽의 미토스 프리뷰(Mythos Preview) 모델 기반 ‘프로젝트 글래스윙(Project Glasswing)’은 출시 직후 오픈소스 소프트웨어에서 약 3,900건의 미발견 고위험 및 치명적 취약점을 찾아냈다.

IBM은 업계에서 가장 폭넓은 상용 오픈소스 생태계를 보유한 기업 가운데 하나로 평가받는다. 현재 6만 2,000개 이상의 패키지를 활용하고 있으며, 리눅스(Linux), 쿠버네티스(Kubernetes), 카프카(Kafka), 테라폼(Terraform), 자바(Java) 등 다양한 플랫폼에서 운영·검증·패치 및 라이프사이클 관리 서비스를 제공하고 있다.

IBM은 프로젝트 라이트웰을 통해 이러한 엔지니어링 원칙을 AI 프레임워크, 독립 라이브러리, 언어 툴체인, 데이터 스트리밍 플랫폼 등으로 확대 적용할 계획이다. 이를 통해 기업 환경에서 이미 사용 중인 오픈소스 코드에 검증된 수정 사항을 제공하고, 시스템 안정성이나 인증, 규제 준수에 영향을 주지 않으면서 취약점을 해결할 수 있도록 지원한다는 설명이다.

프로젝트 라이트웰은 소스코드 접근 권한이나 버전 업그레이드를 요구하지 않는다. 이미 테스트와 배포가 완료된 정확한 의존성 버전에 맞춰 수정 사항을 역이식(backport)하는 방식으로 운영된다. 또한 pom.xml과 같은 구성 매니페스트를 기반으로 작동해 패치된 아티팩트가 배포되더라도 코드는 기업의 통제된 운영 환경 내에 그대로 유지된다. 초기에는 자바·메이븐(Java/Maven) 생태계에 집중하지만, 향후 PyPI, npm, Go 등으로 지원 범위를 확대할 예정이다.

기업은 ‘보안 중개 모델(Secure Intermediary Model)’을 통해 공개 전 단계의 민감한 취약점 정보를 안전하게 공유할 수 있으며, 레드햇 플랫폼은 물론 독립 오픈소스 커뮤니티 코드에 대한 검증된 패치도 받을 수 있다. 또한 의존성 체인 전반에 걸쳐 수정 사항을 배포하고, 운영 환경에서 발견된 문제를 보고·해결하며, 수정 사항을 다시 업스트림에 공유해 오픈소스 커뮤니티 전체가 활용할 수 있도록 지원한다.

레드햇의 수석부사장 겸 최고제품책임자(CPO) 아셰시 바다니는 “클리어링하우스를 통해 기업에 제공하는 수정 사항이 해당 코드를 개발한 오픈소스 커뮤니티에도 다시 전달되도록 하는 것이 중요하다”라며 “예를 들어 파이썬 코드의 취약점을 수정했다면 그 결과가 신속하게 파이썬 커뮤니티에도 공유돼야 한다”고 설명했다. 이어 “프로젝트 라이트웰은 이러한 과정을 안전하게 연결하는 ‘보안 지도(Secure Map)’ 역할을 수행할 것”이라고 덧붙였다.

IBM과 레드햇 엔지니어들은 첨단 AI 기술과 주요 오픈소스 기여자들과의 협력을 바탕으로 업스트림과 다운스트림 환경을 연결해 기업 환경에 바로 적용할 수 있는 패치를 개발할 계획이다. 이와 함께 대규모 취약점 검토 및 분류 작업, 의존성 강화 작업도 수행한다.

바다니는 “프로젝트에 투입되는 2만 명의 엔지니어는 IBM과 레드햇이 보유한 기존 인력으로 구성되며, 필요에 따라 추가 인력을 배치할 예정”이라고 설명했다. 양사는 최첨단 AI 연구소들이 개발한 파운데이션 모델과 자체 개발한 AI 도구 및 프레임워크를 함께 활용할 계획이다. 50억 달러(약 6조 8,000억 원)의 투자금은 AI 도구 도입과 내부 운영 인프라 구축에 사용된다.

프로젝트 라이트웰의 초기 참여 기업으로는 뱅크오브아메리카(Bank of America), BNY, 씨티(Citi), 골드만삭스(Goldman Sachs), JP모건체이스(JPMorganChase), 마스터카드(Mastercard), 모건스탠리(Morgan Stanley), 캐나다왕립은행(Royal Bank of Canada), 스테이트스트리트(State Street), 비자(Visa), 웰스파고(Wells Fargo) 등이 포함됐다. IBM과 레드햇은 초기 설계 단계가 마무리되면 구독형 모델을 통해 더 많은 고객으로 프로젝트를 확대할 계획이다.

오픈소스 생태계를 위한 투자 촉구

보서론 시큐리티(Beauceron Security)의 데이비드 십리는 기업이 오픈소스 생태계를 지속 가능하게 유지하려면 이와 같은 프로젝트가 “절실히 필요하다”고 평가했다.

십리는 미토스(Mythos)의 등장으로 막대한 규모의 디지털 자산이 자원봉사자들의 노력에 의존하던 시대는 사실상 막을 내렸다고 지적했다. 이제 오픈소스 생태계 유지 비용을 기업이 부담해야 할 시점이 왔으며, 그렇지 않으면 결국 그 혜택을 잃게 될 것이라는 설명이다.

십리는 “오픈소스에 투자할 방법을 찾지 못한다면, 오랫동안 이어져 온 형평성 문제도 해결할 수 없게 된다”라며 “그 대안은 모든 기업이 AI를 활용해 각자 맞춤형 코드를 개발하는 것뿐”이라고 말했다. 이어 “이는 컴퓨팅 자원과 환경 측면에서 매우 비효율적이고 낭비가 큰 방식”이라고 지적했다.

또한 “이번 프로젝트가 다른 기업들의 행동을 촉발하는 계기가 되기를 기대한다”고 밝혔다.

인간의 역할은 여전히 중요

바다니는 AI가 오픈소스 코드의 보안 취약점을 발견하는 데는 뛰어난 성능을 발휘하지만, 실제 패치 과정은 여전히 복잡하고 시간이 많이 소요된다고 강조했다.

취약점이 발견되면 수정 사항을 업스트림 프로젝트에 전달해야 하고, 이후 오픈소스 커뮤니티 전체에 배포된 뒤 다시 고객과 사용자 환경으로 전달되는 과정을 거쳐야 한다.

바다니는 “버그를 발견하는 것과 실제로 이를 해결하는 것은 전혀 다른 문제”라며 “실제 수정 작업에는 수많은 절차가 필요하며, 그 과정에서 발생하는 시간 지연이 우리가 줄이고자 하는 격차”라고 설명했다.

문제의 심각성을 보여주듯 프로젝트 라이트웰 발표 이후 IBM과 레드햇에는 관련 문의와 참여 요청이 쇄도하고 있는 것으로 알려졌다.

바다니는 “이 문제는 가까운 시일 내에 사라지지 않을 것”이라며 “초기 과제를 성공적으로 해결하더라도 기업은 이러한 지원을 지속적이고 반복적으로 필요로 하게 될 것”이라고 전망했다.

최근 AI가 인간 엔지니어를 대체할 것이라는 논의가 확산되고 있지만, 프로젝트 라이트웰은 오히려 AI와 인간의 협업에 초점을 맞추고 있다.

바다니는 “AI 도구와 인간의 지식, 전문성을 결합하면 이 문제를 훨씬 효과적으로 해결할 수 있다”라며 “둘 중 하나만 사용하는 것보다 두 요소를 함께 활용할 때 더 나은 결과를 얻을 수 있다”고 강조했다.
dl-ciokorea@foundryco.com

Open source code is everywhere in the enterprise; it’s estimated that upwards of 90% of Fortune 500 companies have it in their software supply chains. But open source code is notoriously rife with vulnerabilities, and identifying and patching those bugs can be an endless battle for security teams.

IBM and Red Hat are betting that a new initiative, Project Lightwell, can help accelerate this process.

Announced today, the project will commit $5 billion and 20,000 IBM and Red Hat engineers to build a new ‘enterprise clearinghouse’ to accelerate discovery and remediation of vulnerabilities in open source software. The companies say the clearinghouse will serve as an AI-powered  “security coordination layer,” giving enterprises the ability to integrate patches directly into their existing software supply chains.

Now in the design phase with a group of 11 financial partners, Project Lightwell will eventually be offered as a commercial subscription.

“The advancement in AI tools has broken the patching map, which is the ability to discover vulnerabilities in software without losing the speed of remediation,” Ashesh Badani, Red Hat SVP and CPO, told CSOonline. “Everyone’s running open source software, and the challenge is not being able to fix vulnerabilities quickly enough.”

Closing the remediation gap

Open source security issues have been well documented: Almost 50,000 common vulnerabilities and exposures (CVEs) were published in 2025, and Anthropic’s Project Glasswing, powered by its Mythos Preview model, found roughly 3,900 previously undiscovered high or critical severity vulnerabilities in open source software shortly after launch.

IBM is considered one of the broadest commercial open source ecosystems, using more than 62,000 packages and operating across Linux, Kubernetes, Kafka, Terraform, Java and other platforms, and providing lifecycle management, validation, and patching for elements within those environments.

The company says Project Lightwell will now apply those same engineering principles to broader AI frameworks, independent libraries, language toolchains, and data streaming platforms, to deliver validated fixes to open-source code already in use in enterprise environments. This can support remediation without disruption of stability, certification, or compliance.

No upgrades or access to source code are required; Project Lightwell will backport fixes to exact dependency versions that have already been tested and deployed. It operates on fundamental configuration manifests like pom.xml so code remains in controlled enterprise environments when patched artifacts are rolled out. Initial focus will be on Java/Maven, but the project will eventually expand to PyPI, npm, Go, and others.

Enterprises will have the ability to share sensitive vulnerabilities under embargo through a “secure intermediary model” and receive validated patches spanning Red Hat platforms and independent community code. They will also be able to deliver fixes across dependency chains; report and address issues across active production environments; and share fixes upstream so the wider open-source community can incorporate them.

“We want to make sure that whatever fixes we provide to the enterprises through the clearinghouse also find their way back into the open source community that developed [the code],” Badani explained. For instance, if a piece of Python code was patched, the fix should be quickly delivered back to the Python community. With Project Lightwell, that process can be achieved through a “secure map.”

Using advanced AI, and working with leading open source contributors, IBM and Red Hat engineers will focus on connecting upstream and downstream environments so fixes are enterprise-ready. They will also develop patches and perform “high volume” vulnerability review and triage, and dependency hardening.

The network of 20,000 engineers will come from IBM’s and Red Hat’s existing pools of talent, and the companies will augment those teams as needed, Badani explained. The companies will take advantage of foundation models coming out of frontier labs, as well as their own internally-built AI tools and frameworks. The $5 billion will be used to equip teams with AI tools and build out internal operational infrastructure.

Early Project Lightwell adopters include Bank of America, BNY, Citi, Goldman Sachs, JPMorganChase, Mastercard, Morgan Stanley, Royal Bank of Canada, State Street, Visa, and Wells Fargo. Following the initial design period, IBM and Red Hat will phase more customers onto Project Lightwell via a subscription model.

A call to action?

This type of initiative is “desperately needed” if enterprise is to save open source, noted David Shipley of Beauceron Security.

The days of trillions in wealth depending on volunteers “ended violently” with Mythos, he noted, and the bill has ultimately come due for open source. Enterprises will need to pay up, or lose it.

“If we don’t find a way to invest in open source, which will close a long-standing equity issue, the alternative is everyone building their own bespoke code using AI,” Shipley said. That would be “massively wasteful” from a compute and environmental perspective.

“I hope this drives others to act,” he said.

Keeping humans in the loop for an ongoing battle

Badani emphasized that, while AI is great at discovering security issues in open-source code, the patching process can still be cumbersome. Fixes have to be sent upstream, distributed to the open source community, then flow back to customers and users.

“Finding the bug is one thing,” said Badani. “The other is all the steps that it takes to actually go and remediate it. That extra amount of time is the gap that we’re trying to help close.”

Underscoring the severity of the problem, IBM and Red Hat have already had an “onslaught of incoming requests” since Project Lightwell was announced.

“This isn’t going to stop any time soon,” Badani said. “Even if we were to very successfully solve the initial set of challenges that come to us, this will be something that companies are going to need on an ongoing or recurring basis.”

And, while the narrative has focused on cutting human engineers in favor of AI, Project Lightwell is focused on the opposite: “We can address [the problem] with a mixture of AI tools and human knowledge and expertise,” Badani said. “Coupling the two gives you a better outcome than just using one or the other.”

Open source code is everywhere in the enterprise; it’s estimated that upwards of 90% of Fortune 500 companies have it in their software supply chains. But open source code is notoriously rife with vulnerabilities, and identifying and patching those bugs can be an endless battle for security teams.

IBM and Red Hat are betting that a new initiative, Project Lightwell, can help accelerate this process.

Announced today, the project will commit $5 billion and 20,000 IBM and Red Hat engineers to build a new ‘enterprise clearinghouse’ to accelerate discovery and remediation of vulnerabilities in open source software. The companies say the clearinghouse will serve as an AI-powered  “security coordination layer,” giving enterprises the ability to integrate patches directly into their existing software supply chains.

Now in the design phase with a group of 11 financial partners, Project Lightwell will eventually be offered as a commercial subscription.

“The advancement in AI tools has broken the patching map, which is the ability to discover vulnerabilities in software without losing the speed of remediation,” Ashesh Badani, Red Hat SVP and CPO, told CSOonline. “Everyone’s running open source software, and the challenge is not being able to fix vulnerabilities quickly enough.”

Closing the remediation gap

Open source security issues have been well documented: Almost 50,000 common vulnerabilities and exposures (CVEs) were published in 2025, and Anthropic’s Project Glasswing, powered by its Mythos Preview model, found roughly 3,900 previously undiscovered high or critical severity vulnerabilities in open source software shortly after launch.

IBM is considered one of the broadest commercial open source ecosystems, using more than 62,000 packages and operating across Linux, Kubernetes, Kafka, Terraform, Java and other platforms, and providing lifecycle management, validation, and patching for elements within those environments.

The company says Project Lightwell will now apply those same engineering principles to broader AI frameworks, independent libraries, language toolchains, and data streaming platforms, to deliver validated fixes to open-source code already in use in enterprise environments. This can support remediation without disruption of stability, certification, or compliance.

No upgrades or access to source code are required; Project Lightwell will backport fixes to exact dependency versions that have already been tested and deployed. It operates on fundamental configuration manifests like pom.xml so code remains in controlled enterprise environments when patched artifacts are rolled out. Initial focus will be on Java/Maven, but the project will eventually expand to PyPI, npm, Go, and others.

Enterprises will have the ability to share sensitive vulnerabilities under embargo through a “secure intermediary model” and receive validated patches spanning Red Hat platforms and independent community code. They will also be able to deliver fixes across dependency chains; report and address issues across active production environments; and share fixes upstream so the wider open-source community can incorporate them.

“We want to make sure that whatever fixes we provide to the enterprises through the clearinghouse also find their way back into the open source community that developed [the code],” Badani explained. For instance, if a piece of Python code was patched, the fix should be quickly delivered back to the Python community. With Project Lightwell, that process can be achieved through a “secure map.”

Using advanced AI, and working with leading open source contributors, IBM and Red Hat engineers will focus on connecting upstream and downstream environments so fixes are enterprise-ready. They will also develop patches and perform “high volume” vulnerability review and triage, and dependency hardening.

The network of 20,000 engineers will come from IBM’s and Red Hat’s existing pools of talent, and the companies will augment those teams as needed, Badani explained. The companies will take advantage of foundation models coming out of frontier labs, as well as their own internally-built AI tools and frameworks. The $5 billion will be used to equip teams with AI tools and build out internal operational infrastructure.

Early Project Lightwell adopters include Bank of America, BNY, Citi, Goldman Sachs, JPMorganChase, Mastercard, Morgan Stanley, Royal Bank of Canada, State Street, Visa, and Wells Fargo. Following the initial design period, IBM and Red Hat will phase more customers onto Project Lightwell via a subscription model.

A call to action?

This type of initiative is “desperately needed” if enterprise is to save open source, noted David Shipley of Beauceron Security.

The days of trillions in wealth depending on volunteers “ended violently” with Mythos, he noted, and the bill has ultimately come due for open source. Enterprises will need to pay up, or lose it.

“If we don’t find a way to invest in open source, which will close a long-standing equity issue, the alternative is everyone building their own bespoke code using AI,” Shipley said. That would be “massively wasteful” from a compute and environmental perspective.

“I hope this drives others to act,” he said.

Keeping humans in the loop for an ongoing battle

Badani emphasized that, while AI is great at discovering security issues in open-source code, the patching process can still be cumbersome. Fixes have to be sent upstream, distributed to the open source community, then flow back to customers and users.

“Finding the bug is one thing,” said Badani. “The other is all the steps that it takes to actually go and remediate it. That extra amount of time is the gap that we’re trying to help close.”

Underscoring the severity of the problem, IBM and Red Hat have already had an “onslaught of incoming requests” since Project Lightwell was announced.

“This isn’t going to stop any time soon,” Badani said. “Even if we were to very successfully solve the initial set of challenges that come to us, this will be something that companies are going to need on an ongoing or recurring basis.”

And, while the narrative has focused on cutting human engineers in favor of AI, Project Lightwell is focused on the opposite: “We can address [the problem] with a mixture of AI tools and human knowledge and expertise,” Badani said. “Coupling the two gives you a better outcome than just using one or the other.”

This article originally appeared on InfoWorld.

The rapid uptake of agentic AI has exposed a range of issues with our non-deterministic helpers. That’s mainly because AI agents are not people and don’t behave like people, even though they generally use the same APIs as humans. For one thing, they make many more queries than a human would, as they build the necessary context to deliver a response.

Anecdotal data from companies that have worked with agents or who have users who access services through agents indicate that this can mean massive increases in API usage, which have affected availability. This increase is the result of automated requests flooding in and blocking calls and responses from APIs that worked perfectly well a year or so ago but now are struggling to cope with the load.

A fundamental redesign of our APIs is necessary, but budgets, resourcing, and capacity make this hard to deliver overnight. What’s needed, then, is a way to manage agent interactions with APIs, treating agents as a new class of user, providing and enforcing the policies that are needed to manage agent life cycles. The use of Model Context Protocol (MCP) as a standard wrapper for agent access to APIs helps here, as it gives us a common environment where we can implement the governance layer needed to keep agents under control.

Microsoft recently launched a public preview of its open-source Agent Governance Toolkit (AGT), which is intended to wrap policy-based enforcement around agents, ensuring that calls are evaluated before they’re made. You can think of the toolkit as a way to manage agent actions, rather than controlling the inputs and outputs of the large language models (LLMs) your agents use. Figures from Microsoft suggest that this method of securing agents is far safer than relying on rules in prompts. However, in practice it’s a good idea to run a capability tool like Agent Governance Toolkit alongside traditional filters to trap user errors and prompt-based attacks.

AGT is a set of tools designed to cover OWASP’s list of agentic risks, building on Microsoft’s experience securing its own agents and AI platforms, with more than 13,000 tests built into the toolkit. It works by evaluating actions before they’re run, checking them against your policies, before allowing or denying the action and logging the results. Microsoft expects policy evaluation to take less than 0.1ms per operation, keeping overheads to a minimum.

Policies for agents

OWASP’s top 10 agent risks lists the most significant issues that can disrupt agent operations resulting from user prompts and bad application design. These risks include agent goal hijacking, uncontrolled code execution, insecure output handling, and agents going rogue. Features in the toolkit are designed to protect agentic applications from these and other issues, using isolation and sandboxing, as well as validating outputs using content policies.

You can use declarative programming techniques to build the policies that define the limits of your agents’ operations. As the policies are human-readable, you can share them with colleagues and refine them across projects to produce a common set of AGT rules for all agents running inside your organization.

The resulting authorization model is intent-based, with agents declaring their intent, which AGT approves or denies. The policy then determines what operations are allowed, whether they’re permitted with an alert, or blocked. This approach allows your code to check orchestrated operations for drift from the top-level intent. When your code is running a harness for multiple parallel agents, this helps keep the application on track and reduces the risk of unwanted operations and using too many tokens.

Agent behavior often results in using more tokens than expected, so keeping spend under control is another role for AGT. As platforms move to new pricing and budgeting models, the ability to control the number of tokens that can be spent on an agent interaction will become very important indeed, and the ability to set a token budget in an AGT policy will allow developers to prevent users from significant unintended spend. AGT’s budget management tools can be used to throttle activities as agents approach preset limits, and to reject actions if they look likely to use excessive tokens.

Monitoring and manag agents in action

You can even use AGT to manage API calls, something that’s becoming increasingly important as agent context-seeking activities can quickly overwhelm APIs designed for human interactions. By building rules that limit the number of calls in a set amount of time, you can now have your agent framework manage throttling for you rather than implementing complex API management tools.

One key feature of AGT is the ability to use its mix of declarative policies to find agents that are drifting from your set baselines, helping spot issues before they cost money or affect operations. AGT also can be used to apply kill switches where necessary. Logging and observability capabilities include a way to provide a root cause analysis of issues, along with what Microsoft calls a “decision bill of materials” that keeps track of governance decisions with an audit chain and the details of the trust levels associated with agents.

A toolkit like AGT needs to be vendor neutral, as your agents could be working with models running in any environment. AGT is designed to work with Azure Foundry, Amazon Bedrock, and Google ADK, as well as with most common agent orchestration frameworks. AGT supports five different programming languages: Python, TypeScript, .NET, Rust, and Go. While capabilities vary between the different implementations, the Python version has the full set.

Microsoft has made some interesting architectural decisions in AGT. Perhaps the most important is that it treats agents as code running on a secure operating system, using concepts from hypervisors to isolate agents from the underlying platform. You can see this in the way the underlying components and packages are named; the core governance package is called Agent OS.

Building AGT into your code

Getting started with AGT can be as simple as installing the complete toolkit using standard package manager of your language of choice. You don’t need to install the whole thing. You have the option of installing specific packages when you don’t need all the features, or when you only want to use a single function. You could download only AGT’s software reliability engineering tools, for example, when you want to put your agents through chaos testing.

You can define policies inside your code or as external policy documents. Policies are focused on key security and governance goals, such as blocking dangerous tools from running, looking for PII in messages, and showing users what action has been taken and why. External policy documents are recommended for use with production AGT implementations, as they let you author policies in YAML. The toolkit provides a single call to load all the policy files in a directory, so it’s a good idea to store only production policies in that location to avoid issues.

Adding support for AGT in existing code is a matter of adding evaluations before your agent framework makes a call. This can be handled using refactoring tools in your editor, finding the call and wrapping the evaluator and decision results around it. This way you can develop agents without using AGT, adding its tools when you’re confident you have a working agent. Microsoft provides custom adapters for 19 different frameworks, tuned to work with them. These can be loaded alongside the rest of the toolkit.

AGT is a sign of growing maturity in our agent landscape, applying enterprise rigor to what has been something of a Wild West free-for-all. It addresses many of the concerns associated with using agents at scale, helping control both agent behavior and costs. Autonomous software needs to be kept on a leash, and AGT’s declarative approach to building and applying policies — along with the rest of its suite of tools — gives you the ability to quickly build and apply the necessary controls.

With companies looking to control costs and regulators wanting to ensure that agentic software doesn’t violate compliance requirements, tools like the Agent Governance Toolkit will likely become an essential part of our modern agent development environment.

Vibe coding is expanding beyond the realm of software development teams into a variety of business units at a range of enterprises, and technology leaders are not only supporting these efforts but in some cases leading the charge.

This democratization of software development, buoyed by vibe coding tools, including chatbots and agents that generate code via prompts, has made vibe coding a thing in departments such as human resources and marketing.

With guidance from IT, such efforts can cut down development backlogs, move solution-building closer to business problems, and open opportunities not previously pursued. But vibe coding can be edgy business. IT leaders interested in unleashing the power of vibe coding in the hands of business users must establish the governance and guardrails necessary to ensure secure results.

Here is a look at how several IT leaders are deploying vibe coding beyond IT and the challenges they’ve faced.

Feeling the vibe

At financial services technology provider EnFi, everyone in the organization, including the C-suite, is actively encouraged to use Claude Code to build their own sub-agents and then get the rest of their teams to use their creations.

“The results have surprised us,” says Scott Weller, CTO. “What started as an engineering productivity initiative has become a company-wide capability, where anyone from the CEO to a customer success manager can turn an idea into a working prototype in hours, not weeks.”

Vibe coding using the tool quickly expanded when non-engineering employees realized they could participate directly in building applications, Weller says. “Product leadership, customer success, and executive stakeholders now routinely initiate development work through the same system,” he says. “Every branch, regardless of who initiates [coding projects], passes through the same automated quality gates, architectural checks, and human code review before anything reaches production.”

When an AI agent writes code, “it follows the same rules as a senior engineer,” Weller says. “AI-powered code review catches architectural violations, security issues, and pattern inconsistencies before a human reviewer sees it. This means the output from a product manager’s Slack request meets the same quality bar as an engineer’s pull request.”

Enabling everyone in the company to come up with an idea and see it running by simply asking a bot to build it “has fundamentally changed who participates in building the product,” Weller says.

Making AI-assisted coding broadly available has shortened the time to completing some projects from weeks to hours, Weller notes. “It has dramatically increased the number of experiments we can run, on [user experience] improvements, feature explorations, and workflow alternatives,” he says.

The most significant benefit is that new development ideas are no longer bottlenecked by lack of engineering capacity. “When anyone in the company can describe what they want and see it built, the rate of experimentation goes up dramatically,” Weller says.

The momentum of building solutions to business problems

Skillsoft, a provider of technology training services and products, is also pushing vibe coding outside its software development teams.

“While it initially emerged within IT teams, we’ve been intentional about encouraging this mindset beyond traditional software development,” says Orla Daly, CIO. “We see real value in enabling teams across the organization to explore, experiment, and problem‑solve using AI in ways that are directly connected to their day‑to‑day work.”

Within Skillsoft’s infrastructure and operations organization non-development individuals are building new products and capabilities or leveraging the principles of vibe coding to troubleshoot production issues, Daly says.

“We’ve seen this show up through cross‑functional experimentation such as prototyping customer intelligence solutions for our go-to-market teams and rapid development of a customer portal,” Daly says. “When people are learning and applying AI to solve a real business problem, it creates purpose and momentum.”

With vibe coding, teams are not just learning new concepts, “they’re developing judgment, curiosity, and a better understanding of how AI can elevate their role and the business more broadly,” Daly says. “The benefits show up in very tangible ways. Teams learn faster because they’re applying AI directly to their work. Engagement increases when people feel trusted to explore and contribute ideas. And as an organization, we gain better visibility into where skills already exist and how they’re evolving.”

More broadly, vibe coding supports adaptability, Daly says. “It helps people move from seeing AI as something abstract or intimidating to something they can work with thoughtfully, using judgment and collaboration rather than relying on rigid processes,” she says. “The solutions created as a result of vibe coding have filled capability gaps and delivered solutions to production in shorter timeframes, producing real value.”

Emphasizing experimentation

At Corevist, an ecommerce platform provider, broad use of vibe coding didn’t start as a formal initiative. “It showed up in different parts of the business, mostly in sales and customer-facing teams, because people were trying to move faster and make ideas easier to communicate,” says Terry Stahler, CIO and chief customer officer.

It also didn’t spread purely on its own. “Without leadership pushing for experimentation, it likely would have moved at a much slower, consensus-driven pace,” Stahler says. “Instead, there was clear encouragement to try things, along with budget behind it.”

Today, Corevist uses vibe coding mainly as a prototyping tool. “It helps people get to something concrete faster, which makes conversations a lot clearer,” Stahler says. “That has been the biggest benefit. We are not using it as a shortcut to production software. Anything that is going to live beyond a prototype goes through our normal engineering and security process.”

Sales was the first place where Stahler saw use cases emerge. One was live prototyping during the sales process. “In a normal B2B conversation, a prospect explains what they need, the account team takes notes, and then everyone goes back and tries to interpret it later,” he says. “What changed here was the ability to turn an idea into something visible much faster, sometimes even while the conversation was still happening.”

That gave the prospect something concrete to react to and made it easier to tell whether a sales rep was actually understanding the request correctly. “It cut down on ambiguity early, which is valuable in any complex sales cycle,” Stahler says.

Marketing has also used vibe coding, for an update of its website. “The value there has been speed in the early creative and planning stages,” Stahler says. “They can generate rough versions of pages and flows much faster than they could through written direction or static mockups alone. That has made it easier to align on direction and has reduced some of the usual back-and-forth that comes with a website rebuild.”

Supplementing the engineering queue

Business growth platform provider ZenBusiness encourages vibe coding “across the board,” says Alex Victoria, CTO. “The way we think about it is pretty simple: If AI tools can help you go from idea to something working without waiting in an engineering queue, we want you to do that,” he says.

Vibe coding began within the product and engineering teams but has spread to other departments.

“We’ve seen people on the data side building their own query tools, product managers creating interactive prototypes with no design background, and teams across the company using AI to handle tasks they used to outsource to specialists,” Victoria says. “The culture we’ve tried to build is one where experimentation isn’t reserved for engineers. If you’re willing to learn and use the tools we have, anyone can code to improve their workflows on their own.”

Although Victoria has been using agentic coding tools for years, he says the “real unlock” of benefits came in 2025, with the release of Claude Code.

“I’ve seen a huge impact since then, and also with Cursor and Codex,” he says. “When someone can build their own tool or prototype in an afternoon instead of waiting weeks in an engineering queue, it changes what’s worth doing.”

The bigger benefit is how it’s changed the relationship between roles, Victoria says. “People who know how to build software can now produce far more value than ever before,” he says. “There’s still a gap between a vibe-coded idea and a running product. If you know how to ship a running product, you’re very valuable in this world.”

Facing down challenges

Embracing more widespread use of vibe coding in the enterprise comes with its own set of challenges.

One of these is maintaining quality when everyone can build. “When you open development to non-engineers, the risk is code that works but doesn’t follow project conventions, creating technical debt faster than manual development,” Weller says.

EnFi has addressed this by investing heavily in the rules and skills layer of coding. More than 40 custom skills impact AI output to match pre-determined architectural patterns.

“The agent doesn’t just write code; it writes code that passes the same review criteria we apply to human engineers,” Weller says. “Every branch, whether initiated by the CEO or a junior engineer, goes through the same automated quality gates and human code review.”

For business software provider Agiloft, “the biggest challenge isn’t technical, it’s organizational,” says Noe Ramos, vice president of AI operations. Agiloft is building an AI-native development capacity across every business function, embedding it into processes such as finance, human resources, and professional services.

“Most companies, including ours, are still learning where work actually happens versus where they think it happens,” Ramos says. “Before you can extend AI into a business function, you have to understand the real workflow, not the documented one. That discovery work is underestimated almost everywhere.”

The company also had to work through “the natural friction of trust and adoption,” Ramos says. “The human variable, though critically important to AI, is always the rate-limiting factor in this case, not the technology.”

On the governance side, Agiloft has had to address issues such as access controls, identity management, and data handling. “We built a formal approval process and a structured use-case lifecycle to manage this, so AI doesn’t get introduced into business teams in ways that create technical debt or compliance exposure,” Ramos says.

The primary challenge for healthcare technology provider iCore was creating confidence among non-technical users rather than technical barriers, says Thiago Soares, COO. The company has actively supported AI-assisted development outside its engineering team, including operations and client success functions that are building automated reporting tools, internal workflow templates, and client onboarding checklists that previously required developer time to produce.

“Staff unfamiliar with AI-assisted development needed structured onboarding before adoption felt natural,” Soares says. “We addressed that through peer-led sessions, where early adopters demonstrated practical use cases relevant to each team’s specific workflows.

Uneven confidence levels can slow progress, especially when people worry about getting it wrong, Daly says. “Creating a safe space to learn is important,” she says. “Creating small teams to work together with peer-to-peer support and encouraging shared learning has also been helpful to support progress through practical application, which is where we see people learn best.”

Governance is another key consideration, particularly in regulated industries with strict data handling protocols, such as healthcare. “Successful organizations set out explicit boundaries within which machine-generated code can be developed outside of formal development pathways,” Soares says.

IT leadership at iCore has built the guardrails needed to make expansion of vibe coding safe, “defining data access boundaries and compliance checkpoints that align with our commitment to trust and security,” Soares says. “That governance foundation is what allows cloud-driven innovation to move forward without creating the regulatory exposure healthcare environments cannot afford.”

The future of coding

Organizations that are moving vibe coding beyond software development teams are aiming to expand these efforts further.

At iCore, expansion of vibe coding into marketing and human resources functions is already under way, Soares says, focused on content workflows and documentation automation. These are “areas where vibe coding delivers efficiency without touching sensitive clinical or compliance infrastructure,” he says.

Agiloft plans to expand vibe coding further and make it into a standard practice “carefully and iteratively,” Ramos says, moving from isolated use cases toward a cohesive AI operating model with a shared infrastructure and AI-literate teams across functions, rather than just AI-enabled tools scattered across departments.

“That said, expansion for us means scaling what works, not scaling the toolset,” Ramos says. “We track every AI initiative through a structured lifecycle, from intake through decommission, precisely to avoid accumulating a stack of underutilized capabilities. Every function will eventually have embedded AI, but the goal is for those capabilities to be connected, governed, and [properly] used, not just deployed.”

EnFi is expanding from engineering-adjacent roles, such as product development and customer success, to other functions. “The same pattern — describe what you want, see it built, review and decide — applies to internal tooling, reporting, operational workflows, and documentation,” Weller says.

Organizations that master AI-assisted development internally “will be the ones capable of deploying AI-assisted workflows to their customers with the quality, governance, and reliability that regulated industries demand,” Weller says. “The internal practice is the proof point.”

Launching a new product is hard enough, but the work doesn’t stop once a product is officially on the market. Often, a new and more complex challenge begins: Turning early excitement into sustained growth.

Launches are deceptive. They create visibility, energy and, if you’re lucky, a surge of initial demand. But they don’t guarantee long-term success. Many products generate strong early interest only to stall when that interest doesn’t convert into repeatable revenue or sustained engagement.

The period immediately after launch is where outcomes diverge. This is where organizations move from building to selling, from internal validation to external validation, and from potential to proof.

The real goal: Learning that converts into revenue

A successful launch is not about perfection. It’s about progress. By the time a product is launched, it should be what I call a “minimum lovable product” — something that delivers clear value, even if incomplete. Waiting for perfection delays learning, and in fast-moving markets, delayed learning is often fatal.

Once a product is live, the focus must shift quickly. The goal is no longer to just validate that the product works. Instead, it’s to validate that customers will pay for it — or, in the case of free products, use it consistently enough to support a viable business model. This requires deliberate effort. 

Organizations must build a pipeline of early customers or users. If an organization has a sales team, this means enabling them with a clear message centered on a compelling differentiator. Those without a formal sales organization should work closely with early adopters who are willing to engage and provide honest feedback. These early customers are critical — they aren’t just buyers; they’re partners in shaping the product’s future. Their usage, patterns, feedback and willingness to pay provide signals that are far more valuable than internal metrics alone. One of the simplest and most effective tests is to ask directly: Would you pay for this?

Another area that must be pursued in these early phases is a deep understanding of tomorrow and the day after tomorrow’s ideal customer profile (ICP). This is hard work, requires a lot of customer conversations at varying levels of detail, both buyers and users. It might just make sense to have a team dedicated to doing this; it’s not sales, it’s not pure prioritization, it’s not engineering, it’s a sales and product management skill that goes hand in hand and must be rewarded because this lays the groundwork for what will build a strong revenue stream.  Far too often, this step is overlooked or conducted spuriously, leading to pain later when the product does not sell to later adopters.

Research consistently demonstrates that stated interest and actual willingness to pay are very different. Studies from Harvard Business Review highlight that customer behavior, not intent, is the most reliable indicator of product value.

Balancing ambition with realism in early commitments

One of the most challenging aspects of the post-launch phase is deciding what to promise. On one hand, it’s important to lean forward. Early customers often require additional support, customization or roadmap commitments to get started. Going above and beyond for a small number of initial customers can be the difference between traction and stagnation. On the other hand, overpromising creates risk. Committing to features that don’t exist or unreasonable timelines risks damaging trust — not just with customers, but internally. Engineering teams become overextended, priorities become unclear and execution suffers.

The balance lies in informed ambition. Having a clear view of where a product is headed and what is realistic to deliver. This requires close alignment between product, engineering and go-to-market teams. It also requires discipline in prioritization. Not everything matters equally. Product differentiation, the core reason customers care, is what should drive the roadmap and messaging. Other features, while important, are secondary. Overinvesting in completeness too early can dilute focus and slow progress.

This is a contrarian point for many organizations. The instinct is to make a product as comprehensive as possible before scaling. The most successful products often win by being significantly better at one thing, rather than marginally better at many.

Creating a repeatable go-to-market motion

Launching a product is a moment. Building a go-to-market engine is a process. One of the biggest mistakes organizations make is treating marketing as a one-time event rather than an ongoing system. Messages alone don’t drive growth; distribution does. Build a funnel that consistently brings the message to the right audience.

This includes:

• Clear positioning based on the differentiator
• Targeted outreach to the right customer segments
• Feedback loops to refine messaging and approach
• Metrics to understand what’s working and what isn’t

Frameworks like HubSpot’s inbound methodology emphasize the importance of aligning content, distribution and engagement to create sustained demand. Regardless of the framework used, the principle is the same: consistency matters more than perfection. The initial approach won’t be perfect — it shouldn’t be. The goal is to start with a strong hypothesis and iterate based on real-world results.

At the same time, internal alignment is critical. The organization’s sales team — or equivalent customer-facing function — needs to feel confident and energized. They need to understand not just what the product does, but why it matters and how to position it effectively. Energy is contagious: if the organization believes in the product, that belief translates into better execution.

Why ease of use matters more than you think

Beyond differentiation, one of the most underestimated factors in post-launch success is ease of adoption. Even if the product delivers significant value, friction in getting started can slow growth dramatically. Users are busy. They have alternatives. If a product requires too much effort to understand or implement, adoption will suffer. This is especially important in enterprise environments, where implementation complexity can be a major barrier. 

In one of my experiences, we built a product that was loved by many early adopters. Our product gave varying levels of users and stakeholders insights into their IT systems operations well beyond what they had before. But the setup required to get them to that level of visibility required a lot of hand-holding. While we had the differentiator, our product was too difficult to get started with and that stood out as one of the reasons our sales slowed at that time.

Research from Gartner consistently highlights that customer experience, including ease of use, is a key driver of technology adoption. Ideally, the product should be both differentiated and easy to use. In practice, achieving both on day one is difficult. Given the choice to prioritize, differentiation comes first — but ease of use should follow quickly. Products that combine the two create a powerful foundation for growth.

What happens immediately post-launch

One of the most overlooked aspects of launching a product is what comes next internally. Leading up to launch, teams often operate in a state of focus. There’s a clear goal, a defined timeline and a shared sense of urgency. Once the product is released, that structure often disappears.

Without proper preparation, this can create a void. The solution is to have a near-term roadmap ready before launch. The post-launch period is when organizations receive their most valuable insights. Customers will share what’s working, what isn’t and what they need next. The ability to respond quickly can significantly influence a product’s trajectory.

Launching a product is a major milestone. Taking the time to recognize that achievement reinforces team morale and sets the tone for the next phase. It’s not just about acknowledging past effort. Instead, prepare the organization for what comes next.

Conclusion

Ultimately, the goal of the post-launch phase is to move toward product-market fit.

This is where many products stall. They generate initial interest but fail to translate that into sustained usage or revenue. The reasons vary, but they often come back to the same fundamentals:

• Lack of a clear differentiator that really solves a problem
• Insufficient understanding of customer needs, both early adopters and later ones
• Weak go-to-market execution
• Overly complex setup experience
• Failure to iterate based on feedback

The good news is that this phase offers the fastest learning cycle. If customers are using the product, they will tell you what they value. If they aren’t, that signal is just as important. Either way, you gain clarity. The key is to act on that clarity.

A launch is a beginning, not an endpoint. The organizations that succeed are those that treat it as the start of a continuous process of learning, refining and scaling. They focus on what matters most, align their teams around a clear vision and build systems that support sustained growth.

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

Enterprises are moving quickly to explore artificial intelligence. New pilots are being launched across functions, from customer service chatbots to predictive analytics and automated workflows. Early results are often encouraging. Models perform well, demonstrations impress stakeholders, and momentum builds around the promise of AI-led transformation.

Yet a more difficult reality is emerging. Most AI initiatives do not make it into production.
While adoption is widespread, with 88% of organizations using AI, nearly two-thirds are still in pilot or early-stage deployments, highlighting the gap between experimentation and enterprise-scale impact.

A majority of pilots fail to scale beyond experimentation. The challenge is rarely the model itself. In controlled settings, it usually works. The problem begins when organizations try to translate those results into systems that can operate reliably at scale.

This gap between experimentation and production is not just slowing adoption. It is delaying value, increasing costs, and creating a growing divide between organizations that can operationalize AI and those that remain stuck in cycles of pilots and rework.

Why pilots succeed and production struggles

Pilot projects are designed for controlled outcomes. Teams work with curated datasets. Infrastructure is temporary, usage is limited, and performance issues are resolved manually. Success is measured by model accuracy or proof of concept, not business impact.

Production systems face a very different reality. They must handle real-world data that is inconsistent and constantly changing. They need to integrate with existing enterprise systems, comply with regulations, and deliver consistent performance under variable demand. Once deployed, they are expected to run continuously without constant expert intervention.

This shift exposes fundamental gaps. Infrastructure that performs well under limited load can struggle at scale. Models trained on curated data may degrade when exposed to real-world variability. Bridging this gap requires more than improving algorithms. It requires rethinking how AI is built, deployed, and managed end to end.

Infrastructure readiness is often underestimated

One of the most common barriers to scaling AI is infrastructure that was never designed for it. Traditional enterprise environments are built for predictable workloads. AI introduces variability, intensity, and data complexity that these systems were not designed to handle.

Compute demand can fluctuate significantly, making static provisioning inefficient and expensive. Data presents an even larger challenge. It remains a fundamental constraint – over 50% of organizations cite data quality and availability as the biggest barrier to scaling AI. AI models rely on large volumes of distributed data, and moving this data to centralized locations introduces latency, cost, and compliance risks. Production AI requires architectures that allow data to be accessed where it resides.

Storage and networking also become critical constraints. AI workloads generate high-volume read and write patterns that conventional systems struggle to support. At the same time, production environments must enforce security and regulatory requirements consistently and at scale. Governance that was relaxed during pilots must now be embedded into the system.

Rethinking the talent challenge through platforms

The challenge of scaling AI is often described as a shortage of skilled talent. While expertise is limited, the issue is also about how effectively teams can work.

In many organizations, data scientists spend a large portion of their time on tasks such as data preparation, environment setup, and infrastructure troubleshooting. This approach may work for a few pilots, but it does not scale as use cases grow. In practice, highly skilled teams remain underutilized; studies suggest data scientists spend over 40% of their time on data preparation rather than building models.

Organizations that move successfully into production take a different approach. They invest in shared platforms that reduce complexity. Standardized environments, automated pipelines, and repeatable workflows allow teams to focus on solving business problems rather than managing infrastructure.

This shift also broadens participation. Domain experts can engage more directly in building AI solutions when tools are easier to use, enabling adoption beyond specialist teams and embedding AI into business processes.

Governance becomes foundational

Governance is often treated as a secondary consideration during experimentation. In production, it becomes essential.

AI systems depend on data that evolves over time. Without continuous monitoring and validation, model performance can decline. In customer-facing or regulated environments, this creates real risk.

Enterprises also need transparency and traceability. They must understand how models make decisions, what data was used, and whether outputs meet regulatory and ethical standards. These capabilities must be built into systems from the start. Retrofitting governance later is costly and disruptive.

From isolated projects to platform thinking

A clear pattern is emerging among enterprises that successfully scale AI. They are moving away from isolated projects and adopting platform-led approaches that unify development, deployment, and governance.

In siloed environments, teams use different tools and workflows. This works initially, but becomes difficult to manage as adoption grows. Data fragmentation increases, governance becomes inconsistent, and operational complexity rises.

Platform-led approaches address this by integrating key capabilities into a single system. Data pipelines become repeatable, model development is standardized, and deployment follows consistent processes. This reduces friction and enables scale.

This is where our platform, Tata Communications’ Vayu AI Studio, is becoming relevant. Instead of requiring enterprises to assemble multiple tools, these environments bring together infrastructure, data pipelines, model development, and governance into a unified system designed for production. This simplifies development and creates a more stable foundation for scaling AI.

The platform also improves how data is handled. Integrated pipelines reduce the effort required to move from raw data to production-ready models, while capabilities such as real-time processing and model customization support faster development without sacrificing control.

At the deployment stage, integrated model hosting, low-latency inference, and lifecycle automation enable reliable scaling. Governance is embedded within workflows, with controls for data lineage, access, and monitoring. At the same time, simplified interfaces allow a broader set of users to participate, accelerating adoption across the enterprise.

Closing the gap

The AI deployment gap is not just a technical issue. It is a reflection of how organizations approach AI as part of their operating model.

Enterprises that address this deliberately, by investing in production-ready platforms, strengthening governance, and aligning teams, are able to move beyond isolated pilots. They build systems that scale, adapt, and deliver consistent value.

The question is no longer whether AI will move into production. It is whether organizations can bridge the gap between experimentation and execution in a way that is sustainable and aligned with long-term business outcomes.

Click here to know more about Tata Communications Vayu AI Studio.

Yet a more difficult reality is emerging. Most AI initiatives do not make it into production.
While adoption is widespread,  with 88% of organizations using AI: nearly two-thirds are still in pilot or early-stage deployments, highlighting the gap between experimentation and enterprise-scale impact.

A majority of pilots fail to scale beyond experimentation. The challenge is rarely the model itself. In controlled settings, it usually works. The problem begins when organizations try to translate those results into systems that can operate reliably at scale.

This gap between experimentation and production is not just slowing adoption. It is delaying value, increasing costs, and creating a growing divide between organizations that can operationalize AI and those that remain stuck in cycles of pilots and rework.

Why pilots succeed and production struggles

Pilot projects are designed for controlled outcomes. Teams work with curated datasets. Infrastructure is temporary, usage is limited, and performance issues are resolved manually. Success is measured by model accuracy or proof of concept, not business impact.

Production systems face a very different reality. They must handle real-world data that is inconsistent and constantly changing. They need to integrate with existing enterprise systems, comply with regulations, and deliver consistent performance under variable demand. Once deployed, they are expected to run continuously without constant expert intervention.

This shift exposes fundamental gaps. Infrastructure that performs well under limited load can struggle at scale. Models trained on curated data may degrade when exposed to real-world variability. Bridging this gap requires more than improving algorithms. It requires rethinking how AI is built, deployed, and managed end to end.

Infrastructure readiness is often underestimated

One of the most common barriers to scaling AI is infrastructure that was never designed for it. Traditional enterprise environments are built for predictable workloads. AI introduces variability, intensity, and data complexity that these systems were not designed to handle.

Compute demand can fluctuate significantly, making static provisioning inefficient and expensive. Data presents an even larger challenge. It remains a fundamental constraint – over 50% of organizations cite data quality and availability as the biggest barrier to scaling AI. AI models rely on large volumes of distributed data, and moving this data to centralized locations introduces latency, cost, and compliance risks. Production AI requires architectures that allow data to be accessed where it resides.

Storage and networking also become critical constraints. AI workloads generate high-volume read and write patterns that conventional systems struggle to support. At the same time, production environments must enforce security and regulatory requirements consistently and at scale. Governance that was relaxed during pilots must now be embedded into the system.

Rethinking the talent challenge through platforms

The challenge of scaling AI is often described as a shortage of skilled talent. While expertise is limited, the issue is also about how effectively teams can work.

In many organizations, data scientists spend a large portion of their time on tasks such as data preparation, environment setup, and infrastructure troubleshooting. This approach may work for a few pilots but does not scale as use cases grow. In practice, highly skilled teams remain underutilized, studies suggest data scientists spend over 40% of their time on data preparation rather than building models.

Organizations that move successfully into production take a different approach. They invest in shared platforms that reduce complexity. Standardized environments, automated pipelines, and repeatable workflows allow teams to focus on solving business problems rather than managing infrastructure.

This shift also broadens participation. Domain experts can engage more directly in building AI solutions when tools are easier to use, enabling adoption beyond specialist teams and embedding AI into business processes.

Governance becomes foundational

Governance is often treated as a secondary consideration during experimentation. In production, it becomes essential.

AI systems depend on data that evolves over time. Without continuous monitoring and validation, model performance can decline. In customer-facing or regulated environments, this creates real risk.

Enterprises also need transparency and traceability. They must understand how models make decisions, what data was used, and whether outputs meet regulatory and ethical standards. These capabilities must be built into systems from the start. Retrofitting governance later is costly and disruptive.

From isolated projects to platform thinking

A clear pattern is emerging among enterprises that successfully scale AI. They are moving away from isolated projects and adopting platform-led approaches that unify development, deployment, and governance.

In siloed environments, teams use different tools and workflows. This works initially but becomes difficult to manage as adoption grows. Data fragmentation increases, governance becomes inconsistent, and operational complexity rises.

Platform-led approaches address this by integrating key capabilities into a single system. Data pipelines become repeatable, model development is standardized, and deployment follows consistent processes. This reduces friction and enables scale.

This is where our platforms Tata Communications’ Vayu AI Studio is becoming relevant. Instead of requiring enterprises to assemble multiple tools, these environments bring together infrastructure, data pipelines, model development, and governance into a unified system designed for production. This simplifies development and creates a more stable foundation for scaling AI.

The platform also improves how data is handled. Integrated pipelines reduce the effort required to move from raw data to production-ready models, while capabilities such as real-time processing and model customization support faster development without sacrificing control.

At the deployment stage, integrated model hosting, low-latency inference, and lifecycle automation enable reliable scaling. Governance is embedded within workflows, with controls for data lineage, access, and monitoring. At the same time, simplified interfaces allow a broader set of users to participate, accelerating adoption across the enterprise.

Closing the gap

The AI deployment gap is not just a technical issue. It is a reflection of how organizations approach AI as part of their operating model.

Enterprises that address this deliberately, by investing in production-ready platforms, strengthening governance, and aligning teams, are able to move beyond isolated pilots. They build systems that scale, adapt, and deliver consistent value.

The question is no longer whether AI will move into production. It is whether organizations can bridge the gap between experimentation and execution in a way that is sustainable and aligned with long-term business outcomes.

Click here to know more about Tata Communications Vayu AI Studio.

The apparent revenge deletion of US federal databases after the dismissal of twin brothers from an online hosting company is another reminder to IT and HR leaders that tough off-boarding procedures have to be implemented to prevent insider attacks.

Destructive attacks either from disgruntled current or former employees aren’t new. But the conviction by a Virginia jury last week of one of the brothers raises a number of issues that IT pros and CEOs have to keep in mind.

A federal jury convicted Sohaib Akhter, 34, of Alexandria, Virgina, on charges of conspiracy to commit computer fraud, password trafficking, and possession of a firearm by a prohibited person. He will be sentenced in September. And last month his brother, Muneeb, signed an agreed statement of facts about the siblings’ activities in response to several charges against him. But according to documents from the case provided on the Free Law Project’s archive of court data, The Court Listener, Muneeb is now trying to have the charges dismissed.

Still, the incident has led one expert, Robert Enderle of the Enderle Group, to say, “it should serve as a wake-up call: Organizations must not only tighten their internal controls, but also begin accounting for how AI tools can be weaponized against them, and these AI tools need far stronger guardrails than they currently have.”

The statement of facts

According to the statement of facts Muneeb agreed to, but now disputes, he and his brother, Sohaib, worked for an unnamed company in Washington, DC that provided software and services to more than 45 US government agencies, including hosting data for some federal clients. They included the US Equal Employment Opportunity Commission (EEOC), Homeland Security, and the Internal Revenue Service (IRS).

On Feb 18, 2025, both brothers were terminated by the company after it discovered Sohaib had been convicted nine years earlier of a felony. After the firing, they both allegedly tried to harm their former employer by accessing computers without authorization, deleting databases and destroying evidence of their work. In his statement of facts this year, Muneeb admitted to deleting 96 databases.

How? While five minutes after they were fired in 2025, Sohaib’s VPN was disconnected and he lost access to the hosting provider, his brother still had access. The brothers also still had their company-issued laptops. They went to work.

As part of their alleged destructive work, when Muneeb didn’t know the database commands necessary to accomplish his goals, he used an AI tool to help him, asking “how do I clear system logs from SQL servers after deleting databases” and later, “how do you clear all event and application logs from Microsoft Windows Server 2012.” The agreed statement of facts doesn’t make it clear, but presumably the AI tool was a public chatbot.

In the statement of facts, Muneeb agreed he stole copies of IRS information on a virtual machine that included federal tax information of 450 people.

Muneeb also admitted that between May and December 2025, he committed fraud and stole credentials for the EEOC public portal in an attempt to access email and other online accounts of 4,500 people. In hundreds of instances, he successfully logged into victims’ email accounts without their authorization.

State of insider attacks

According to the State of Human Risk Report from Mimecast, 42% of organizations have experienced an increase in malicious insider incidents over the past year, with 42% also reporting a rise in negligent incidents for the first time.

A report this year by the Ponemon Institute on the costs of insider risks, commissioned by insider threat detection provider DTEX, estimated incidents cost organizations an average of $19.5 million last year, up from $17.4 million in 2024.

The biggest cause of losses last year (53%) was negligence and mistakes, it said. The second biggest cause, however, was malicious activity (27%).

Musa Ishaq, senior principal insider threat analyst at DTEX, said last week’s conviction “is a clear and sobering reminder that termination is not the end of risk. In many cases, it is the beginning of it.”

The off-boarding moment “is one of the most dangerous windows in any organization’s security posture,” he said, “and it remains one of the most underestimated. Every departing employee, whether they leave willingly or are terminated, represents a live risk event that must be treated in real time. That means immediate access revocation, active session termination, and active monitoring, not a checklist completed the following day. When those steps fail, or when even a single access pathway is left open, the consequences can be catastrophic, as this case demonstrates.”

‘AI didn’t give attackers a new capability’

Equally important, he added, is what this case reveals about AI’s role in accelerating insider threats. “AI did not give them a new capability; they already had the access and the intent. What it did was compress their decision cycle, turning what might have taken several minutes of research into seconds of execution. The new threat reality is that AI does not create malicious insiders, but it dramatically amplifies what they can accomplish before defenders are able to respond.”

As a result, organizations have to shift to proactive and risk-adaptive security approaches, Ishaq said. A privileged user querying an AI tool through a company owned or controlled computer for log evasion techniques while simultaneously executing destructive commands on production servers is an escalation signal, he said. “Behavioral visibility, not just technical controls, is what enables security teams to detect that pattern and act before deletion becomes destruction,” he said.

“This case is a preview of what insider threats look like in an AI-enabled world in terms of being faster, harder to trace, and far more consequential when governance gaps exist,” he said. “As such, the fundamentals, including strict access control, real-time off-boarding protocols, and layered monitoring of privileged users, have never been more critical.”

‘Textbook example’ of need to re-think processes

Enderle agreed. He said this incident “is a textbook example of why we need to rethink the speed and process of our off-boarding processes. The fact that a former employee was able to access and delete government databases post-termination highlights a massive failure in basic access control. In a modern enterprise, access revocation needs to be instantaneous, automatic, and comprehensive; any gap between a firing and a lockout is a window for significant liability.”

The most disturbing aspect, he added, is the role AI played. “Using an AI tool to solicit instructions on clearing system logs is a clear signal that the barrier to entry for sophisticated digital sabotage is dropping,” Enderle said. “We are entering an era where AI can act as a force multiplier for malicious intent, making it easier for individuals to cover their tracks. Even AI protections can be bypassed. I saw a demonstration on YouTube the other day where a user just re-asked a question to a public AI site on preparing a bomb until the AI gave up saying ‘No,’ and provided the answer.”

Queries like ‘How to clear SQL logs’ have legitimate administrative purposes, he acknowledged. But, he added, AI providers must move beyond simple keyword filtering and implement intent-aware guardrails that can identify attack chains.

“When a sequence of prompts moves from technical curiosity to a roadmap for destroying evidence and obfuscating logs, the AI should recognize the malicious context and refuse the request, Enderle argued.

“Ultimately,” he warned, “if AI providers don’t take responsibility for preventing their platforms from becoming a ‘How-to’  manual for criminal activity, they risk a regulatory backlash and potential civil and criminal liability that could stifle the very innovation they are trying to promote.”

The first time I approached an OT environment, I assumed that the strategies effective in IT cybersecurity would be equally applicable. I was wrong. The experience revealed a fundamental difference, highlighting the need for a distinct approach to OT cyber risk management.

The mistake was not technical. It was conceptual. I was treating OT as another security domain that needed stronger controls, better tooling and greater discipline. But OT lives under different conditions. Systems stay in service for years, sometimes decades. Patching is limited. Change windows are negotiated. Vendor dependencies are part of daily operations. Asset visibility is often incomplete and the highly distributed environments depend heavily on third-party access.

In summary, OT cyber risk fundamentally constitutes a challenge of leadership and governance. The primary concern at scale is not isolated technical controls at individual sites, but rather the enterprise’s ability to ensure consistent decision-making across all sites through clearly defined roles and shared accountability.

OT changes the nature of cyber risk

Boards have improved their cyber oversight of IT, but OT requires a different perspective. Here, cyber risk goes beyond data and compliance into operational processes, industrial assets and critical services.

OT architecture begins in the physical world, moves through control systems and operations networks, and increasingly connects to enterprise systems and cloud services. This creates a consequence profile distinct from IT, in which cyber risk directly affects physical operations.

OT operating constraints include long asset lifecycles, incomplete asset visibility, embedded third-party access, fragmented ownership across engineering, operations, site leadership, vendors and security. IT cyber assumptions often fail in OT because risk and responsibility structures diverge fundamentally.

The governance baseline for OT remains thin, as reflected in recent World Economic Forum research that highlights broader issues of leadership and oversight. Only 16 percent of organizations with industrial environments report OT security issues to their boards and just 20 percent maintain dedicated OT security teams. Furthermore, in only 36 percent of cases is the CISO directly responsible for OT security. These low levels of reporting and responsibility indicate not only a maturity gap in organizational processes but, more critically, a substantial accountability gap that directly reinforces the thesis: OT cyber risk management at scale is fundamentally a challenge of leadership and governance, rather than solely a technical concern.

At scale, a local weakness becomes an enterprise coordination issue. Differences in maturity, ownership, vendor dependencies and business priorities create uneven exposure. The board question is not whether OT controls exist, but whether the enterprise can make consistent, defensible decisions about OT cyber risk before and during disruption.

At scale, incident outcomes become leadership outcomes

Effective OT oversight shifts from control-by-control discussions to scenario and consequence analysis.

Common OT exposure paths include remote access abuse, shared accounts, weak segmentation, infected maintenance media, compromised workstations and poorly governed vendor connectivity. In OT, these exposures have direct operational consequences. A SCADA compromise can reduce visibility across power operations. Poor remote access governance can degrade rail operations. Infected media can trigger plant downtime. Unauthorized parameter changes can force emergency shutdowns and manual safety validation.

OT risk appetite cannot be reduced to the enterprise itself. OT impact may extend to the economy, environmental, critical services and, sometimes, human safety. As the consequences broaden, oversight standards must rise. A technical control gap is one risk. A governance structure that cannot support safe, coherent decisions under pressure is a different order of magnitude in terms of exposure.

In OT, incident outcomes are determined by leadership choices made before disruption begins.

• Should the organization isolate quickly to stop propagation, or continue operating in a constrained way to protect essential output?
• Should authority be centralized to improve consistency, or federated to improve speed and local judgment?
• Should the organization restore quickly, or verify process integrity first and accept a longer recovery path?
• Should vendor and remote support remain broadly enabled for operational convenience, or be reduced because it has become part of the real perimeter?

No single option is always correct. The key is whether leaders understand trade-offs before action is required. Executive decisions such as isolate versus operate, centralize versus federate and restore versus verify change outcomes. These are governance choices, not technical defaults.

I have seen both sides of this in practice. In one environment, centralization accelerated capability building. It improved consistency, but it also introduced the risk of slower decisions in a crisis because authority sat too far from the operational edge. In another, responsibility was distributed across business units, which improved local ownership but increased coordination risk under stress. The lesson was never ideological. It was operational. The operating model had to match the risk reality.

This is also why the strongest board-level conversations in OT are rarely about tools first. They are about decision rights, escalation logic, crisis thresholds and assurance. The NIST Cybersecurity Framework 2.0 is useful here not because it provides boards with a script, but because it explicitly frames cybersecurity as part of how organizations understand and manage cyber risk.

What boards should ask now

Boards do not need to become technical experts in OT. They do need to demand decision-grade oversight.

First, clarify the operating model. Who owns OT cyber risk across the enterprise? Where does business unit accountability sit? Which decisions are centralized and which are delegated? Who has authority in a crisis when continuity and containment are in tension? If these answers are unclear, residual risk is likely underestimated.

To help make this concrete, consider two common operating models. In a centralized model, OT cyber risk governance, tooling decisions and incident response authority reside primarily at the enterprise or group level, typically under the leadership of a central security or risk function. Local sites implement enterprise direction but have limited autonomy to define controls or crisis actions. In contrast, a federated model grants more decision rights to individual business units or operating sites. Here, local leaders often own OT cyber controls, incident triage and vendor management, while the central organization coordinates standards and provides guidance. Each model brings different trade-offs in consistency, speed and local adaptation. Directors should ask management to clarify which approach is in place today and why it fits the organization’s risk profile.

Second, identify the two or three OT cyber scenarios that would most impact continuity, key operations and external defensibility. Scenarios should be concrete enough to guide priorities, budget and crisis preparation. Generic statements about protecting critical infrastructure are not enough.

Third, require assurance. Boards should ask whether a baseline exists and whether it has been independently tested for effectiveness. Governance and assurance should sit above the technical baseline and operating model. In OT, site assessments, adversarial simulations, tabletop exercises and validation of remote access controls provide more insight than maturity scoring.

Fourth, address innovation. AI and cloud are changing operational environments, even when adoption begins at the physical layer. The leadership agenda is moving toward governance, resilience and control of increasingly complex digital dependencies. For OT, boards should treat these shifts as operating model and assurance questions, not just technology questions.

This is where the board agenda becomes practical. Directors should ask management to clarify decision rights, define the top OT cyber scenarios, establish an enterprise minimum baseline for priority environments and run independent assurance on the sites or operations that matter most. These are not technical housekeeping tasks. They are the foundations of defensible oversight.

This article builds on a recent RSAC session on managing OT risk at scale, but the lesson is broader. OT cyber risk at scale is not simply a controls problem. It is a leadership problem because real outcomes depend on governance, accountability and pre-agreed trade-offs. The organizations that navigate OT disruption better are usually not the ones with the most ambitious slide decks. They are the ones who decided in advance how they will govern, escalate, verify and recover.

That is what the shift boards should insist on. In OT, resilience is built by decisions made before the incident alarm sounds.

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

The data sprawl problem is worse than anyone admits

Before a DSPM tool can protect data, it must find it. That sounds straightforward. In practice, it is the first place most programs quietly begin to unravel.

Enterprises have been operating in hybrid and multi-cloud environments for a long time. Data has followed every workflow — into Salesforce, into SharePoint, into dozens of S3 buckets that were created by developers who have since moved on, and into collaboration tools adopted during the pandemic without any formal data classification policy attached. Nobody tracked it systematically. Research from Cyera’s 2024 DSPM Adoption Report found that 90% of the world’s data was created in just the last two years, and total data volume by 2025 reached 181 zettabytes. Security teams are being asked to govern a landscape that is growing faster than any tool or team was designed to handle.

When DSPM scanners go to work on a large enterprise environment, the volume of findings almost always exceeds initial expectations — sometimes by an order of magnitude. One organization I worked with discovered sensitive customer PII in seventeen cloud storage locations that they had no formal record of. Another found regulated financial data sitting in a collaboration workspace that had been shared with an external contractor two years prior and never revoked.

The visibility is genuinely valuable. But, as Wiz notes in their DSPM framework, visibility without remediation capacity is just a longer list of things that can go wrong. And that is exactly where the first real friction begins.

Ownership is a political problem, not a technical one

DSPM tools are exceptionally good at identifying data risk. They are not designed to resolve the organizational question of who is responsible for fixing it. That question, in most enterprises, does not have a clean answer.

Security teams surface the finding. The data sits in a business unit’s environment. The IT team may own the cloud account, but the data owner is in Finance, HR, or a product team operating on a separate roadmap and budget cycle. When the DSPM platform generates a remediation ticket, the question of who closes it — and who gets measured on closing it — is rarely answered in advance.

This creates what I call the remediation gap. Findings accumulate. Risk scores rise. But nothing gets fixed, because no single team has both the authority and the incentive to fix it. Security points at the business. The business points at IT. IT points at the data owner. The data owner has a product launch in six weeks and no security budget. Forcepoint’s DSPM implementation research confirms this pattern: Even capable platforms underdeliver when rollout turns into a scanning project with unclear ownership and remediation that lives in a permanently deferred backlog.

I have watched this dynamic play out in organizations across industries. It is not a technology failure. It is a governance failure — and no DSPM platform in the market today ships with a solution to it. That solution must be built by leadership, before deployment, with teeth. That means defined data ownership models, escalation paths and accountability metrics that connect to performance conversations, not just security dashboards.

Classification debt is real, and it goes well with compounding

Every DSPM implementation depends on one foundational input: A coherent data classification framework. Most enterprises do not have one that is current, enforced, or agreed upon across business units.

Organizations are equipped with policy documents written five years ago, and what was defined there, nobody uses consistently. What adds more is a growing volume of unstructured content that was never classified at all. According to a 2024 industry survey cited by Securiti, 83% of IT and cybersecurity leaders assert that lack of visibility into data contributes significantly to their weak security posture — a figure that points directly at the classification gap sitting underneath most programs.

DSPM tools apply machine learning to infer sensitivity from data patterns — and they are increasingly good at it. But inference is not a substitute for intentional classification. False positives create noise. False negatives create blind spots. Both erode trust in the platform over time. And once analysts stop trusting the findings, the program stalls regardless of how sophisticated the tooling is.

The harder truth is that many organizations use the DSPM project as a forcing function to finally build the classification framework they should have built years ago. That is not inherently wrong. But it dramatically expands the scope and timeline, and it requires business stakeholder engagement that security teams are rarely resourced to drive on their own. Executives who budget for a DSPM tool without budgeting for the classification work alongside it are setting their programs up for a slow, expensive drift toward shelfware.

Integration complexity is systematically underestimated

DSPM vendors will show you a connector library that spans AWS, Azure, GCP, Microsoft 365, Salesforce, Snowflake and a long list of other platforms. What the demo does not show you is what happens when your specific version of a legacy ERP system does not match the connector’s assumptions or when your on-premises database sits behind a network segment the cloud-native scanner cannot reach without significant architectural change.

Enterprise environments are heterogeneous by nature. Palo Alto Networks’ market analysis puts the DSPM market on a trajectory toward $2 billion by 2025, growing at rates between 25% and 37% annually — a reflection of just how aggressively organizations are investing in this space. But investment velocity and implementation maturity are not the same thing. The average large organization runs hundreds of distinct data stores across multiple cloud providers, legacy systems and third-party SaaS applications. Getting DSPM coverage across all of them is not a deployment — it is an ongoing engineering program.

Connectors break when APIs change. New data sources appear with every acquisition and product build. Maintaining coverage requires dedicated resources that are rarely factored into the initial business case. Executives should push their vendors on exactly which environments will have full coverage at go-live versus which ones are on a roadmap with no committed timeline. The distinction matters enormously because a DSPM deployment with significant coverage gaps gives a false sense of security that can be more dangerous than no deployment at all.

This is a point worth reinforcing with your procurement team: Gartner’s Market Guide for DSPM explicitly flags that organizations can no longer separate data visibility from data control — and that coverage depth, not just breadth, is the critical variable when evaluating platforms.

Alert fatigue arrives faster than expected

A fully operational DSPM deployment in a large enterprise will generate findings at a volume that most security operations teams are not built to absorb. The irony is that the better the tool works, the faster alert fatigue sets in.

Risk prioritization is the answer in theory. In practice, prioritization logic requires ongoing tuning that takes months of calibration with your specific data environment. Varonis, in their DSPM guidance for CISOs, makes the point directly: The goal should not be to generate a list of findings but to surface meaningful, actionable alerts that can be remediated — ideally with automation doing the heavy lifting. Most implementations fall well short of that standard in the early months.

In the meantime, analysts are triaging hundreds of findings per week, many of which turn out to be acceptable risks or known exceptions. Teams burn out. Findings get acknowledged and deprioritized. The board dashboard shows a healthy posture score that no longer reflects ground reality. Zscaler’s analysis of cloud data security challenges identifies this precisely: Security teams need AI and ML-powered prioritization not just to reduce noise but to help analysts focus effort on the data exposures that could realistically lead to a breach.

This is not an argument for turning off the tool. It is an argument for honest capacity planning. If your security operations team is already stretched, a DSPM deployment without additional analyst headcount or a meaningful automation investment is not going to improve your security posture. It is going to add a new category of noise to an already overloaded function.

What good looks like

None of the friction described here is insurmountable. Organizations that get DSPM right tend to share a few common attributes that have nothing to do with which vendor they chose.

They treat DSPM as an organizational change program, not a technology deployment. They invest in governance structures before they deploy scanners. They define data ownership at the business unit level with clear accountability, and they build that accountability into how people are measured and managed. They budget for the classification work alongside the tooling. They phase their integration roadmap honestly, scope the first phase to environments where coverage will be complete, and build confidence before expanding.

They also pay attention to what Microsoft’s research on enterprise data security posture flags as the underlying imperative: Organizations must stop seeing data security as a collection of individual tools and start treating it as a holistic program anchored in measurable business outcomes. That shift in framing changes everything — from how the board conversation is structured to how remediation accountability is assigned across the business.

Most importantly, they have executive sponsorship that goes beyond signing the purchase order. The CISOs who successfully land DSPM programs are the ones who have a CFO, COO, or CEO who understands that data security risk is a business risk — and who is willing to hold business unit leaders accountable for their piece of it.

DSPM, at its best, gives your enterprise the situational awareness it needs to make informed decisions about data risk. The organizations that leverage awareness as a genuine security improvement are the ones that walk in with eyes open — prepared for the friction, staffed for the remediation work and governed for the accountability.

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

A few years back, Bhaskar Ramachandran read the tea leaves and what he saw was clear: With all the enhancements hyperscalers continuous make, there was no value in having on-premises data centers any longer.

“There is just no way for a private company to match that,” says Ramachandran, global vice president and CIO of paints and coatings manufacturer PPG. “This is their business, and they’re really good at it, and it was clear that the size of the hyperscalers is just going to win over the infrastructure game. So it didn’t make sense for us to keep up with the infrastructure.”

PPG began dismantling its eight global data centers about four years ago, with the final one completed in November 2025. For a 143-year-old company that has gone through 60-some acquisitions, that was no small feat.

Applications and infrastructure became a lot to manage, combined with trying to maintain a strong cybersecurity posture and compliance. “You can’t consistently manage this sort of a footprint, and it becomes really unwieldy very quickly,” Ramachandran says.

Decommissioning a data center is like defusing a complex bomb. Every wire, sequence, and step must be handled with care, because one wrong move can be a blow to your organization in downtime risks, data breaches, or a hit to its bottom line. 

“The decommissioning of data centers is underestimated in terms of complexity, financial risks, reputation loss, and data exposure,” according to Gartner. The firm estimates that by 2030, twice as many enterprise data centers will have been decommissioned compared to those built. Reasons include consolidations, obsolescence, and shifting workloads to cloud and colocation services.

The inadvertent data center

In some instances, data centers have cropped up without much forethought. “Most organizations I work with didn’t build a data center intentionally — they grew into one,” says Aaron Walker, CEO of IT consultancy Overbyte, and a former associate partner at IBM Consulting. “A rack in a closet became a row in a repurposed room, and suddenly, you have a facility that was never designed for the job holding years of infrastructure decisions.”

Deconstructing that environment is work that often gets overlooked, says Walker.

He recently consulted with a large, fully remote online school in the throes of this process. The deconstruction work began with a full audit of what systems existed. From there every workload was categorized to determine what gets migrated, what gets moved to cloud-native infrastructure, and what gets retired entirely, he says.

Then came the physical side: decommissioning hardware and deciding what equipment had residual value and what to recycle. 

“The timeline pressures are real,” Walker says. “You can’t just power things down. Dependencies surface that nobody documented.”

The IT organizational side had its own challenges. “People have years of institutional knowledge tied to physical systems, and there’s genuine anxiety about dismantling something they built and maintained,” he says. 

Walker’s team also ran into issues trying to upgrade systems during the migration, which is generally a mistake, he says. “A data center deconstruction is already a significant change event, and layering additional upgrades on top of it introduces unnecessary risk. In most cases, it is better to separate modernization from migration.”

From start to finish, the deconstruction ran about a year, but timing will vary from project to project, he says.

Less hassle, more flexibility

When the time came for digital marketing agency Helium SEO to consider what to do with its data center, CTO Paul DeMott says the math was simple. “We were paying $12,000 a month toward the colocation fees, hardware support, and the maintenance cost for the physical servers sitting in racks. Cloud infrastructure promised better reliability, automatic scaling, and way less hassle once we were done moving everything.”

The most compelling reason to rid itself of a physical footprint, though, was flexibility. Physical servers equated to capacity planning six months ahead, DeMott says, and if they needed more resources, IT had to wait weeks for hardware to come and get installed.

“Cloud allows resources to be spun up in minutes and shut down at the same speed,” he says. “We went from buying expensive hardware that depreciated to purchasing what we are actually using.”

IT began by creating a list of all the apps running on physical servers and classifying them according to how difficult it would be to move them. “Simple web apps moved first as they barely needed changes,” DeMott says. “Databases and anything which stores data — that’s a little bit later because we’d have had to plan the migration well.”

Some older apps had to be changed to work on the cloud, he adds. The actual move took place over six months, and IT decommissioned the data center while deploying apps to the cloud in tandem, moving the services step by step with backup plans for each one.

Still, the process wasn’t seamless. “Translating 15TB of data to the cloud takes 72 hours on our internet connection, and that was the biggest problem,” DeMott notes. IT ended up using AWS Snowball, a physical hard drive, because it took staff weeks to upload everything, “and [it] ruined the performance in our network.”

Another issue was figuring out the cloud costs, which DeMott characterizes as “brutal. Different types of servers, storage, data transfer costs made it almost impossible to budget,” he says. “Our first month bill accrued at 40% more than we estimated because we forgot about charges for moving data out of the cloud.”

It took IT three months of “fumbling” to get costs below what the company paid for the data center before things stabilized.

The power of ‘cloud only’

Once PPG made the decision to dismantle its data centers and move everything to the cloud, it was time to spread the word internally. “When you say, ‘cloud only,’ it makes it much easier for you to have conversations,” Ramachandran says. “It just sets the entire organization up on a single mission … just those two words make it very, very clear to everybody in the company what that means. There is no room for interpretation.”

The news was revealed at a global town hall, and initially, Ramachandran says, the sentiment was, “this too, shall pass. Then people decided to get on board.”

There were the typical organizational change management issues to deal with. Building momentum takes time, he says, but once the first data center was shut down, people came to the realization that “Okay, we are actually doing this,” Ramachandran says. “Then there was no resistance … everybody got on board, and things started to accelerate.”

Officials ensured that all the training IT needed was made available to them and the company paid for everything, certifications included. “We recognized it in town halls; anybody that went through this training and got the certification. We celebrated people. We promoted people that did the things we wanted them to do,” he says. All of this helped reinforce the mission.

“For the most part, business users didn’t care; their apps were available and they didn’t care where they were,” although there were a couple of exceptions among more technically savvy employees who were concerned about workflow and the security implications of cloud. There was a perception among some that a data center was more secure, Ramachandran says.

That led to looking at publicly available information on all the cybersecurity incidents in the recent past. The research indicated a clear pattern, he says.

“And the pattern is: The more significant cybersecurity events were actually happening to companies” that were largely on-prem environments, Ramachandran observes. “So you came to this point where the cloud actually became lot more secure than on-prem infrastructure.”

There are several reasons why, he maintains, including that, relatively speaking, it is a lot easier to implement security policies consistently in the cloud because “you have a single pane of glass enforcement of policies that you don’t have in an on-prem environment.”

This makes managing your attack surface area more straightforward, Ramachandran says. “So you put all of this together, you package it up on the presentation, and talk to those people one on one, and then say, ‘This is why.’”

The dismantling process

PPG works with a single hyperscaler for its business in China and three others. Deciding what apps went where was largely a function of the technology and which hyperscaler “lends itself to that brand of technology versus the other.” In some instances, where a decision of which to use wasn’t clear, IT made the call.

Step one was deciding on an approach, and PPG opted to modernize its apps at the same time as the deconstruction work. “When you pull together the business case to modernize applications, we came to a conclusion that if we do modernization on the application layer and the infrastructure layer at the same time, I would probably be retired by the time we migrated the data center,” Ramachandran says.

That made it easy to decide when to do a lift and shift and when to not bother migrating certain applications, he says. Then IT could focus on other business priorities to modernize the workforce.

“We just adjusted our roadmap to say the new [app] would go straight into the cloud” while not bothering to move older workloads, Ramachandran says.

The human element

The next step was “finding the people that are hungry to do something new and probably have a bit of experience and … they are waiting for someone to say, ‘Hey, let’s do this,’” Ramachandran says of the data center deconstruction. “They are forward thinkers. Every organization in our scale has [them]. It’s identifying those people and then … empowering them. They became the leaders in the new infrastructure.”

Once the migration started, it was important to celebrate the wins. That gets more people interested in being a part of the new organization PPG was forming called the Cloud COE (center of excellence).

The biggest mistake companies make is treating deconstruction as a single project instead of a phased operational shift, says Roland Parker, founder and CEO of Impress Computers, a managed IT services and cybersecurity firm in Houston.

“We walked one 200-person manufacturer through moving workloads in priority tiers — production-critical systems last, not first — which kept their floor running while we systematically eliminated physical infrastructure over 14 months,” he says.

However, it’s “the human side [that] kills more timelines than the tech does,” Parker observes. “Field supervisors and plant managers have work-arounds built around how legacy systems behave.” So, before touching a single rack, Parker’s team audits those informal processes, “because if you don’t, you migrate the infrastructure and orphan the people who actually use it.”

Overbyte’s Walker agrees, saying that almost all the snafus his team ran into during the online school deconstruction project were not technical, but came down to visibility. “At some point, you have to confront unknown systems; things with incomplete or outdated documentation,” he says. “We had moments where, after beginning to deprovision systems, stakeholders surfaced saying, ‘Wait, that’s still in use.’”

Dismantling systems is not the end

PPG experienced no disruptions during the dismantling process, Ramachandran says, other than some tactical delays and contracts that needed updating.

“There were some learnings on the network side because networking can get complex,” he says. “Sometimes, we extended the outage windows” to up to five hours, for example. Those were the hiccups.”

From start to finish, the decommissioning process of all eight data centers took about three years. “The end is not migrating all the workloads. The end is actually shutting down the data center,” Ramachandran stresses. This requires deconstructing the power, the cooling, fire systems, and multiple generators used for backup, which had to be removed by helicopter.

“You have to take the diesel fuel out and dispose it off and sell it. We have to get recertification of the building for safety, because this is a building where you had kilowatts of power coming in, which basically [also] went through a deconstruction process,” he says. “So you have to get a safety certification … all of this takes time because we have to give the building back to the building management the way they gave it to us.”

What data center deconstruction buys you

The painstaking data center deconstruction process has given Ramachandran valuable insight. “Make sure your best people spend time creating value for the business, as opposed to babysitting infrastructure,” he says, because infrastructure no longer adds value.

“You also do a lot of inherent risk management by getting rid of data centers and moving to a cloud environment you don’t have to worry about,” he adds. Noting the current state of the economy, Ramachandran says coping with sudden price increases for memory and chips is no longer stressful since they aren’t buying infrastructure.

“You’re basically giving back working capital to the company, because you’re moving the organization from a fixed capital environment to your variable cost model completely,” he says, “and you don’t have to refresh your hardware every four or five years.”

Cost was never the objective for the data center deconstruction, Ramachandran notes. “Nonetheless, when we did the business case, we said it’s not going to cost us any more or any less, but will buy us better security, better flexibility, better agility for the organization,” as well as better focus and technology. “And we achieved all of those.”

The value is in all those other areas. “We are not data center operators. The team is now focused on delivering applications that are meaningful to the business,” Ramachandran says. “The team is much closer than ever to the business because we are not talking infrastructure but how to make the business better.”

Walker says companies should measure twice, cut once. “Most teams want to jump straight into migration,” he says, “but the real work is building a complete inventory and mapping dependencies upfront.”

While it made sense for PPG to modernize some apps at the same time as the data center deconstruction work, Walker advises IT leaders to resist the urge to do everything at once. “Focus on moving what you understand first, and isolate the unknowns early,” he says.
“The success of these projects is usually determined by how well you handle the edge cases, not the easy wins.”

Any new technological development IT can make without interrupting operations dramatically reduces time to market, Ramachandran says.

Working on the latest technologies makes IT happy, and that helps with talent retention, he adds, “because we can say we’re cloud only, so this 143-year-old company looks modern. That is meaningful in so many ways.”

The way organizations support collaboration today still varies widely from space to space. Small huddle rooms, project spaces, and large boardrooms often come with different setups, different workflows, and different expectations. 

For employees, that inconsistency creates friction. For IT teams, it creates complexity. And for organizations, it quietly undermines the promise of hybrid work. 

What’s becoming clear is that the meeting room is no longer just a physical space. It is where hybrid work either flows or fails. 

Meetings remain the backbone of collaboration 

Despite new ways of working, meetings remain central to how teams align, make decisions, and move projects forward. People come to the office not to sit behind individual screens, but to connect, co‑create, and build momentum together.  

In a hybrid reality, those moments increasingly involve a mix of in‑room and remote participants. 

That places a new kind of pressure on meeting spaces. They must support different group sizes, different collaboration styles, and different platforms, without forcing users to think about the technology behind it.  

When meetings start late because cables are missing, audio behaves differently per room, or content sharing feels unpredictable; attention shifts away from the conversation before it even begins. Hybrid collaboration only works when technology disappears into the background. 

Consistency drives adoption 

One of the most underestimated factors in hybrid collaboration is consistency in user experience. Employees move between meeting spaces throughout the day. Every change in setup introduces uncertainty and hesitation. Over time, that leads to avoidance, workarounds, or reliance on personal devices instead of shared spaces. 

Organizations that succeed approach meeting rooms as a connected ecosystem rather than a collection of individual rooms. A consistent experience across huddle spaces and boardrooms lowers the learning curve, increases confidence, and drives adoption naturally. People know what to expect, how to start, and how to share, regardless of where they are. 

For IT teams, that same consistency reduces support overhead and simplifies management. Standardized setups, predictable workflows, and centralized visibility replace the constant firefighting that fragmented environments create. 

Technology should support people, not distract them 

As collaboration technology evolves, expectations rise. Users no longer accept tools that require explanation or preparation. They expect meetings to start smoothly, participants to be seen and heard clearly, and content to be shared without effort. 

This is where the balance between usability, security, and intelligence becomes critical. Ease of use drives adoption, but it cannot come at the expense of governance or trust. At the same time, intelligence must enhance the experience without adding complexity. Features like automatic audio calibration, speaker framing, or real‑time transcription only deliver value when they feel intuitive and reliable. The goal is not to showcase technology, but to create conditions where collaboration feels natural, inclusive, and uninterrupted. 

From technology choice to workplace experience 

Ultimately, the quality of hybrid collaboration is determined less by individual features than by the experience. Employees judge meeting technology by how it makes them feel: confident or hesitant, included or sidelined, focused or distracted. 

From huddle room to boardroom, the most effective collaboration environments share the same principles. They are simple to use, consistent across spaces, secure by design, and flexible enough to evolve. They respect people’s time and attention, allowing teams to focus on ideas rather than interfaces. 

As organizations continue to refine their hybrid strategies, meeting room solutions remain a revealing indicator. When collaboration flows effortlessly, hybrid work has a real chance to succeed. When it doesn’t, even the best policies and tools elsewhere struggle to compensate. 

In the end, the future of hybrid work is not decided in strategy documents. It is decided, meeting by meeting, in the rooms where people come together to work. 

The way organizations support collaboration today still varies widely from space to space. Small huddle rooms, project spaces, and large boardrooms often come with different setups, different workflows, and different expectations. 

For employees, that inconsistency creates friction. For IT teams, it creates complexity. And for organizations, it quietly undermines the promise of hybrid work. 

What’s becoming clear is that the meeting room is no longer just a physical space. It is where hybrid work either flows or fails. 

Meetings remain the backbone of collaboration 

Despite new ways of working, meetings remain central to how teams align, make decisions, and move projects forward. People come to the office not to sit behind individual screens, but to connect, co‑create, and build momentum together.  

In a hybrid reality, those moments increasingly involve a mix of in‑room and remote participants. 

That places a new kind of pressure on meeting spaces. They must support different group sizes, different collaboration styles, and different platforms, without forcing users to think about the technology behind it.  

When meetings start late because cables are missing, audio behaves differently per room, or content sharing feels unpredictable; attention shifts away from the conversation before it even begins. Hybrid collaboration only works when technology disappears into the background. 

Consistency drives adoption 

One of the most underestimated factors in hybrid collaboration is consistency in user experience. Employees move between meeting spaces throughout the day. Every change in setup introduces uncertainty and hesitation. Over time, that leads to avoidance, workarounds, or reliance on personal devices instead of shared spaces. 

Organizations that succeed approach meeting rooms as a connected ecosystem rather than a collection of individual rooms. A consistent experience across huddle spaces and boardrooms lowers the learning curve, increases confidence, and drives adoption naturally. People know what to expect, how to start, and how to share, regardless of where they are. 

For IT teams, that same consistency reduces support overhead and simplifies management. Standardized setups, predictable workflows, and centralized visibility replace the constant firefighting that fragmented environments create. 

Technology should support people, not distract them 

As collaboration technology evolves, expectations rise. Users no longer accept tools that require explanation or preparation. They expect meetings to start smoothly, participants to be seen and heard clearly, and content to be shared without effort. 

This is where the balance between usability, security, and intelligence becomes critical. Ease of use drives adoption, but it cannot come at the expense of governance or trust. At the same time, intelligence must enhance the experience without adding complexity. Features like automatic audio calibration, speaker framing, or real‑time transcription only deliver value when they feel intuitive and reliable. The goal is not to showcase technology, but to create conditions where collaboration feels natural, inclusive, and uninterrupted. 

From technology choice to workplace experience 

Ultimately, the quality of hybrid collaboration is determined less by individual features than by the experience. Employees judge meeting technology by how it makes them feel: confident or hesitant, included or sidelined, focused or distracted. 

From huddle room to boardroom, the most effective collaboration environments share the same principles. They are simple to use, consistent across spaces, secure by design, and flexible enough to evolve. They respect people’s time and attention, allowing teams to focus on ideas rather than interfaces. 

As organizations continue to refine their hybrid strategies, meeting room solutions remain a revealing indicator. When collaboration flows effortlessly, hybrid work has a real chance to succeed. When it doesn’t, even the best policies and tools elsewhere struggle to compensate. 

In the end, the future of hybrid work is not decided in strategy documents. It is decided, meeting by meeting, in the rooms where people come together to work. 

A few years back, Bhaskar Ramachandran read the tea leaves and what he saw was clear: With all the enhancements hyperscalers continuous make, there was no value in having on-premises data centers any longer.

“There is just no way for a private company to match that,” says Ramachandran, global vice president and CIO of paints and coatings manufacturer PPG. “This is their business, and they’re really good at it, and it was clear that the size of the hyperscalers is just going to win over the infrastructure game. So it didn’t make sense for us to keep up with the infrastructure.”

PPG began dismantling its eight global data centers about four years ago, with the final one completed in November 2025. For a 143-year-old company that has gone through 60-some acquisitions, that was no small feat.

Applications and infrastructure became a lot to manage, combined with trying to maintain a strong cybersecurity posture and compliance. “You can’t consistently manage this sort of a footprint, and it becomes really unwieldy very quickly,” Ramachandran says.

Decommissioning a data center is like defusing a complex bomb. Every wire, sequence, and step must be handled with care, because one wrong move can be a blow to your organization in downtime risks, data breaches, or a hit to its bottom line. 

“The decommissioning of data centers is underestimated in terms of complexity, financial risks, reputation loss, and data exposure,” according to Gartner. The firm estimates that by 2030, twice as many enterprise data centers will have been decommissioned compared to those built. Reasons include consolidations, obsolescence, and shifting workloads to cloud and colocation services.

The inadvertent data center

In some instances, data centers have cropped up without much forethought. “Most organizations I work with didn’t build a data center intentionally — they grew into one,” says Aaron Walker, CEO of IT consultancy Overbyte, and a former associate partner at IBM Consulting. “A rack in a closet became a row in a repurposed room, and suddenly, you have a facility that was never designed for the job holding years of infrastructure decisions.”

Deconstructing that environment is work that often gets overlooked, says Walker.

He recently consulted with a large, fully remote online school in the throes of this process. The deconstruction work began with a full audit of what systems existed. From there every workload was categorized to determine what gets migrated, what gets moved to cloud-native infrastructure, and what gets retired entirely, he says.

Then came the physical side: decommissioning hardware and deciding what equipment had residual value and what to recycle. 

“The timeline pressures are real,” Walker says. “You can’t just power things down. Dependencies surface that nobody documented.”

The IT organizational side had its own challenges. “People have years of institutional knowledge tied to physical systems, and there’s genuine anxiety about dismantling something they built and maintained,” he says. 

Walker’s team also ran into issues trying to upgrade systems during the migration, which is generally a mistake, he says. “A data center deconstruction is already a significant change event, and layering additional upgrades on top of it introduces unnecessary risk. In most cases, it is better to separate modernization from migration.”

From start to finish, the deconstruction ran about a year, but timing will vary from project to project, he says.

Less hassle, more flexibility

When the time came for digital marketing agency Helium SEO to consider what to do with its data center, CTO Paul DeMott says the math was simple. “We were paying $12,000 a month toward the colocation fees, hardware support, and the maintenance cost for the physical servers sitting in racks. Cloud infrastructure promised better reliability, automatic scaling, and way less hassle once we were done moving everything.”

The most compelling reason to rid itself of a physical footprint, though, was flexibility. Physical servers equated to capacity planning six months ahead, DeMott says, and if they needed more resources, IT had to wait weeks for hardware to come and get installed.

“Cloud allows resources to be spun up in minutes and shut down at the same speed,” he says. “We went from buying expensive hardware that depreciated to purchasing what we are actually using.”

IT began by creating a list of all the apps running on physical servers and classifying them according to how difficult it would be to move them. “Simple web apps moved first as they barely needed changes,” DeMott says. “Databases and anything which stores data — that’s a little bit later because we’d have had to plan the migration well.”

Some older apps had to be changed to work on the cloud, he adds. The actual move took place over six months, and IT decommissioned the data center while deploying apps to the cloud in tandem, moving the services step by step with backup plans for each one.

Still, the process wasn’t seamless. “Translating 15TB of data to the cloud takes 72 hours on our internet connection, and that was the biggest problem,” DeMott notes. IT ended up using AWS Snowball, a physical hard drive, because it took staff weeks to upload everything, “and [it] ruined the performance in our network.”

Another issue was figuring out the cloud costs, which DeMott characterizes as “brutal. Different types of servers, storage, data transfer costs made it almost impossible to budget,” he says. “Our first month bill accrued at 40% more than we estimated because we forgot about charges for moving data out of the cloud.”

It took IT three months of “fumbling” to get costs below what the company paid for the data center before things stabilized.

The power of ‘cloud only’

Once PPG made the decision to dismantle its data centers and move everything to the cloud, it was time to spread the word internally. “When you say, ‘cloud only,’ it makes it much easier for you to have conversations,” Ramachandran says. “It just sets the entire organization up on a single mission … just those two words make it very, very clear to everybody in the company what that means. There is no room for interpretation.”

The news was revealed at a global town hall, and initially, Ramachandran says, the sentiment was, “this too, shall pass. Then people decided to get on board.”

There were the typical organizational change management issues to deal with. Building momentum takes time, he says, but once the first data center was shut down, people came to the realization that “Okay, we are actually doing this,” Ramachandran says. “Then there was no resistance … everybody got on board, and things started to accelerate.”

Officials ensured that all the training IT needed was made available to them and the company paid for everything, certifications included. “We recognized it in town halls; anybody that went through this training and got the certification. We celebrated people. We promoted people that did the things we wanted them to do,” he says. All of this helped reinforce the mission.

“For the most part, business users didn’t care; their apps were available and they didn’t care where they were,” although there were a couple of exceptions among more technically savvy employees who were concerned about workflow and the security implications of cloud. There was a perception among some that a data center was more secure, Ramachandran says.

That led to looking at publicly available information on all the cybersecurity incidents in the recent past. The research indicated a clear pattern, he says.

“And the pattern is: The more significant cybersecurity events were actually happening to companies” that were largely on-prem environments, Ramachandran observes. “So you came to this point where the cloud actually became lot more secure than on-prem infrastructure.”

There are several reasons why, he maintains, including that, relatively speaking, it is a lot easier to implement security policies consistently in the cloud because “you have a single pane of glass enforcement of policies that you don’t have in an on-prem environment.”

This makes managing your attack surface area more straightforward, Ramachandran says. “So you put all of this together, you package it up on the presentation, and talk to those people one on one, and then say, ‘This is why.’”

The dismantling process

PPG works with a single hyperscaler for its business in China and three others. Deciding what apps went where was largely a function of the technology and which hyperscaler “lends itself to that brand of technology versus the other.” In some instances, where a decision of which to use wasn’t clear, IT made the call.

Step one was deciding on an approach, and PPG opted to modernize its apps at the same time as the deconstruction work. “When you pull together the business case to modernize applications, we came to a conclusion that if we do modernization on the application layer and the infrastructure layer at the same time, I would probably be retired by the time we migrated the data center,” Ramachandran says.

That made it easy to decide when to do a lift and shift and when to not bother migrating certain applications, he says. Then IT could focus on other business priorities to modernize the workforce.

“We just adjusted our roadmap to say the new [app] would go straight into the cloud” while not bothering to move older workloads, Ramachandran says.

The human element

The next step was “finding the people that are hungry to do something new and probably have a bit of experience and … they are waiting for someone to say, ‘Hey, let’s do this,’” Ramachandran says of the data center deconstruction. “They are forward thinkers. Every organization in our scale has [them]. It’s identifying those people and then … empowering them. They became the leaders in the new infrastructure.”

Once the migration started, it was important to celebrate the wins. That gets more people interested in being a part of the new organization PPG was forming called the Cloud COE (center of excellence).

The biggest mistake companies make is treating deconstruction as a single project instead of a phased operational shift, says Roland Parker, founder and CEO of Impress Computers, a managed IT services and cybersecurity firm in Houston.

“We walked one 200-person manufacturer through moving workloads in priority tiers — production-critical systems last, not first — which kept their floor running while we systematically eliminated physical infrastructure over 14 months,” he says.

However, it’s “the human side [that] kills more timelines than the tech does,” Parker observes. “Field supervisors and plant managers have work-arounds built around how legacy systems behave.” So, before touching a single rack, Parker’s team audits those informal processes, “because if you don’t, you migrate the infrastructure and orphan the people who actually use it.”

Overbyte’s Walker agrees, saying that almost all the snafus his team ran into during the online school deconstruction project were not technical, but came down to visibility. “At some point, you have to confront unknown systems; things with incomplete or outdated documentation,” he says. “We had moments where, after beginning to deprovision systems, stakeholders surfaced saying, ‘Wait, that’s still in use.’”

Dismantling systems is not the end

PPG experienced no disruptions during the dismantling process, Ramachandran says, other than some tactical delays and contracts that needed updating.

“There were some learnings on the network side because networking can get complex,” he says. “Sometimes, we extended the outage windows” to up to five hours, for example. Those were the hiccups.”

From start to finish, the decommissioning process of all eight data centers took about three years. “The end is not migrating all the workloads. The end is actually shutting down the data center,” Ramachandran stresses. This requires deconstructing the power, the cooling, fire systems, and multiple generators used for backup, which had to be removed by helicopter.

“You have to take the diesel fuel out and dispose it off and sell it. We have to get recertification of the building for safety, because this is a building where you had kilowatts of power coming in, which basically [also] went through a deconstruction process,” he says. “So you have to get a safety certification … all of this takes time because we have to give the building back to the building management the way they gave it to us.”

What data center deconstruction buys you

The painstaking data center deconstruction process has given Ramachandran valuable insight. “Make sure your best people spend time creating value for the business, as opposed to babysitting infrastructure,” he says, because infrastructure no longer adds value.

“You also do a lot of inherent risk management by getting rid of data centers and moving to a cloud environment you don’t have to worry about,” he adds. Noting the current state of the economy, Ramachandran says coping with sudden price increases for memory and chips is no longer stressful since they aren’t buying infrastructure.

“You’re basically giving back working capital to the company, because you’re moving the organization from a fixed capital environment to your variable cost model completely,” he says, “and you don’t have to refresh your hardware every four or five years.”

Cost was never the objective for the data center deconstruction, Ramachandran notes. “Nonetheless, when we did the business case, we said it’s not going to cost us any more or any less, but will buy us better security, better flexibility, better agility for the organization,” as well as better focus and technology. “And we achieved all of those.”

The value is in all those other areas. “We are not data center operators. The team is now focused on delivering applications that are meaningful to the business,” Ramachandran says. “The team is much closer than ever to the business because we are not talking infrastructure but how to make the business better.”

Walker says companies should measure twice, cut once. “Most teams want to jump straight into migration,” he says, “but the real work is building a complete inventory and mapping dependencies upfront.”

While it made sense for PPG to modernize some apps at the same time as the data center deconstruction work, Walker advises IT leaders to resist the urge to do everything at once. “Focus on moving what you understand first, and isolate the unknowns early,” he says.
“The success of these projects is usually determined by how well you handle the edge cases, not the easy wins.”

Any new technological development IT can make without interrupting operations dramatically reduces time to market, Ramachandran says.

Working on the latest technologies makes IT happy, and that helps with talent retention, he adds, “because we can say we’re cloud only, so this 143-year-old company looks modern. That is meaningful in so many ways.”

For decades, IT organizations were measured by stability, uptime, cost efficiency and service delivery. Success meant systems ran reliably, incidents were minimized and budgets were controlled.

That model is no longer enough.

In today’s environment, defined by cost pressure, supply chain volatility and accelerating digital expectations, the role of IT is fundamentally transforming. The modern CIO is no longer just an operator of systems, but an orchestrator of business value.

The new mandate: Business value over technology

Digital transformation was once synonymous with technology modernization. But leading organizations have learned a hard truth: Technology does not create value, outcomes do.

Today, CIOs are accountable for:

• Margin improvement and cost reduction
• Faster product development cycles
• Supply chain resilience
• Operational efficiency and quality

This requires a fundamental shift in mindset: “Don’t sell technology. Enable business value and let technology follow.”

Every digital investment must tie directly to measurable impact EBIT uplift, working capital improvement, productivity gains, not just system upgrades.

Run and transform: The dual engine of modern IT

The transition from operator to orchestrator is anchored in a dual mandate:

Run the business + Transform the business

Run the business ensures:

• Secure, resilient IT and OT environments
• Stable ERP and plant operations
• Compliance and cybersecurity
• Predictable service delivery

Transform the business drives:

• Data, AI and automation at scale
• Digital capabilities across engineering, manufacturing and supply chain
• Agile, product-centric ways of working

The differentiator is not managing these separately but orchestrating them seamlessly together.

This orchestration is what elevates IT from a support function to a strategic partner.

From projects to products: Rewiring the operating model

Traditional IT is structured around projects and technology silos. High-performing organizations are shifting to product and platform operating models aligned to business value streams.

This means:

• Product teams own outcomes, not just delivery
• Platform teams enable reuse, scalability and speed
• Business and IT operate as one integrated team

The impact is significant:

• Faster decision-making
• Clear accountability for outcomes
• Reduced duplication and total cost

The guiding principle becomes simple: Standardize first. Digitize second. Scale through platforms.

Digital thread: Unlocking end-to-end value

One of the biggest unlocks in industrial enterprises is the digital thread connecting engineering, manufacturing, supply chain and commercial systems into a unified ecosystem.

When connected, organizations gain:

• Real-time visibility across the value chain
• Faster product development cycles
• Cost transparency from design to delivery
• Predictive, data-driven decision-making

Without this integration, enterprises operate in silos — resulting in inefficiencies, delays and margin erosion.

The digital thread is not just a technology concept it is a business capability multiplier.

AI as a force multiplier, not a side initiative

Artificial intelligence is rapidly becoming embedded across every business function — but its true value lies not in isolated use cases, but in scaling intelligence across the enterprise.

Leading organizations are moving beyond experimentation to:

• Embed AI into core workflows (engineering, quality, supply chain)
• Automate decision-making at scale
• Enable predictive and prescriptive insights

Examples include:

• Predictive quality models reducing defects before they occur
• AI-driven quoting improving margins and win rates
• Intelligent supply chain analytics optimizing inventory and logistics

The shift is clear:

From dashboards → to decisions → to autonomous execution

However, AI’s success depends on two critical enablers: Trusted data and organizational adoption.

Citizen development: Scaling innovation beyond IT

One of the most powerful — and often underestimated — levers of transformation is citizen development.

In a world where demand for digital solutions far exceeds IT capacity, empowering business users to build solutions is no longer optional, it is essential.

Citizen development enables:

• Faster identification and execution of use cases at the plant and function level
• Reduced dependency on centralized IT teams
• Increased ownership and adoption of digital solutions

But this is not about uncontrolled proliferation. Successful organizations balance empowerment with governance through:

• Standardized platforms (low-code/no-code, data, automation)
• Clear guardrails for security, data and architecture
• Digital champions embedded within business functions

The role of IT shifts from builder to platform provider, coach and orchestrator of innovation.

When done right, citizen development creates a multiplier effect, turning every function into a contributor to digital transformation.

Observability & AIOps: Managing complexity at scale

As digital ecosystems grow, so does complexity. Traditional monitoring approaches, reactive and fragmented, are no longer sufficient.

The next frontier is AI-driven observability and AIOps, where:

• Logs, metrics and events are continuously analyzed
• Anomalies are detected proactively
• Automated remediation reduces downtime

This shift enables organizations to:

• Improve reliability and resilience
• Reduce operational cost
• Build internal intelligence rather than relying on external vendors

Observability becomes a core orchestration capability, enabling IT to manage increasingly complex digital environments with confidence.

Talent, culture and leadership: The real differentiators

Technology alone does not transform organizations, people, culture and leadership do.

Key shifts include:

• Skills
• Building capabilities in data, AI and automation across the organization
• Culture
• Driving speed, experimentation and continuous learning
• Leadership
• Ensuring strong sponsorship and business-led digital adoption

The most successful organizations empower business teams to identify opportunities, while IT provides the platforms and governance to scale them.

Governance: From control to value realization

Modern governance is no longer about approvals — it is about outcomes.

Effective models focus on:

• Alignment to business priorities
• Transparent portfolio management
• Continuous tracking of value (EBIT, cost, productivity)

The key question shifts from “Is this project on track?” to “Is this delivering measurable business value?”

Conclusion: The CIO as orchestrator-in-chief

The CIO role has fundamentally evolved — from operator to orchestrator.

Today’s CIO must:

• Align technology to business outcomes
• Integrate data, platforms and processes
• Enable innovation at scale across the enterprise

The organizations that will lead are not those that adopt the most technology, but those that orchestrate technology, data, AI and people into measurable outcomes.

In a world of constrained budgets and rising expectations, the mandate is clear: Run with discipline. Orchestrate with intent. Transform with measurable impact.

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

For years, Kubernetes held an almost mythic place in enterprise IT. It was positioned as the control plane for the future, the standard abstraction for cloud-native systems, and the platform that would finally free enterprises from infrastructure lock-in. To be fair, some of that was true. Kubernetes brought discipline to container orchestration, enabled portable deployment models, and provided architects with a powerful framework for managing distributed applications at scale.

However, the market is changing, and so are enterprise expectations. The question is no longer whether Kubernetes is technically impressive. It clearly is. The question is whether it still represents the best fit for a growing number of mainstream enterprise use cases. In many cases, the answer is increasingly no. What we are seeing is not the death of Kubernetes but the end of its unquestioned dominance as the default strategic choice. Here’s why.

Too operationally expensive

As Kubernetes adoption grew, many organizations hesitated to admit that it introduced operational complexity and needed specialized skills, constant tuning, and strong governance. Running Kubernetes well requires mature engineering, observability, security, networking, and life-cycle management—much more than a side project. Many underestimated this burden.

What looked elegant in architectural diagrams became a real-world tax on operations teams. Clusters multiplied. Toolchains sprawled. Upgrades became risky. Policy enforcement became an engineering discipline in its own right. Enterprises realized they were not just adopting an orchestration platform. They were building and maintaining an internal product that required sustained investment and scarce expertise.

That might be acceptable for digital-native businesses whose scale and complexity justify the effort. It is a much harder sell for enterprises that want reliable deployments, resilient applications, and reasonable cloud costs. In those cases, Kubernetes can feel like overengineering disguised as strategic modernization. When a company spends more time managing the platform than delivering business value on top of it, the novelty wears off quickly.

Portability becomes less important

Kubernetes was marketed as a hedge against lock-in, enabling applications to run across on-premises, cloud, and edge. However, most enterprises faced ecosystem dependencies—storage, networking, security, identity, observability, CI/CD, managed services, and cloud-native databases—creating practical lock-in that Kubernetes didn’t eliminate.

What enterprises gained in workload portability, they often lost in ecosystem complexity. They standardized on Kubernetes while still depending heavily on a particular cloud provider’s managed services and operational conventions. The result was a strange middle ground: all the complexity of a highly abstracted platform without the full simplicity of using opinionated native services end-to-end.

This matters more now because boards and executive teams are less interested in theoretical architectural optionality and more focused on measurable business outcomes. They want speed, resilience, cost control, and lower risk. If a managed application platform, serverless environment, or provider-specific platform-as-a-service offering gets them there faster, many are willing to accept some level of dependency. Enterprises are becoming more candid about the trade-offs. They are realizing that strategic flexibility is valuable, but not at any cost.

This is where Kubernetes starts losing favor. Portability has value, but for many enterprises, it hasn’t justified the operational and organizational burden it entails. The promise exceeded the actual return.

Better abstractions are catching up

Perhaps the most important shift is that enterprises are moving away from buying raw technical primitives and toward consuming higher-level platforms that better align with developer productivity and business outcomes. Platform engineering teams increasingly hide Kubernetes behind internal developer platforms. Public cloud providers continue to improve managed container services, serverless offerings, and integrated application environments that reduce hands-on infrastructure management. Developers, meanwhile, do not want to become part-time cluster operators. They want fast paths to build, deploy, secure, and monitor applications without stitching together a dozen components.

In other words, Kubernetes may still be present under the hood, but it is becoming less visible and less central to strategic buying decisions. That is usually a sign of maturity. Technologies shift from being the headline to being plumbing. Enterprises are not asking, “How do we adopt Kubernetes?” as often as they are asking, “What is the fastest, safest, most cost-effective way to deliver modern applications?” That is a much healthier question.

The answer increasingly points to curated platforms, opinionated developer environments, and managed services that abstract away Kubernetes rather than exposing it. This is not a rejection of cloud-native principles. It is a rejection of unnecessary cognitive load. Enterprises are deciding they do not need to own every layer of complexity to realize the benefits of modern architecture.

Surrendering the spotlight

None of this means Kubernetes is disappearing. It remains important for large-scale, heterogeneous, and highly customized environments. It is still an excellent fit for organizations with strong platform maturity, regulatory constraints, or sophisticated multicloud operational needs. But that is a narrower slice of the market than the hype cycle once suggested.

What is losing popularity is not Kubernetes as a technology, but Kubernetes as the unquestioned standard for enterprises. This difference is important. Companies are becoming more selective about where to accept complexity and where to avoid it. They are less inclined to idealize infrastructure and more eager to choose simplicity when it exists.

That is probably a good thing. The job of enterprise architecture is not to admire elegant technology for its own sake. It is to align technology choices with operational realities, economic constraints, and business outcomes. By that standard, Kubernetes still has a place, but it no longer gets a free pass.

If you’re using Kubernetes, especially a managed version like Azure Kubernetes Service (AKS), you don’t need to think about the underlying hardware. All you need to do is build your application and it should run, its containers managed by the service’s orchestrator.

At least that’s the theory. However, implementing a platform that abstracts your code from the servers and network that support it brings its own problems, and a whole new discipline. Platform engineers fill the gap between software and hardware, supporting security and networking, as well as managing storage and other key services.

Kubernetes is part of an ecosystem of cloud-native services that provide the supporting framework for running and managing scalable distributed systems, including the tools needed to package and deploy applications, as well as components that extend the functionality of Kubernetes’ own nodes and pods.

Key components of this growing ecosystem are the various service meshes. These offer a way to manage connectivity between nodes and between your applications and the outside network, with tools for handling basic network security. Often implemented as “sidecar” containers, running alongside Kubernetes pods, these network proxies can consume added resources as your applications scale. That means more configuration and management, ensuring that configurations are kept up-to-date and that secrets are secure.

Istio goes ambient

One of the key service mesh implementations, Istio, has developed an alternate way of operating, what the project calls “ambient mode”. Here, instead of having individual sidecars for each pod, your service mesh is implemented as per-node proxies or as a single proxy that supports an entire Kubernetes namespace. It’s an approach that allows you to start implementing a service mesh without increasing the complexity of your platform, making it easy to go from a basic development Kubernetes implementation to a production environment without having to change your application pods.

It’s called ambient mode because there’s no need to add new service mesh elements as your application scales. Instead, the service mesh is always there, and your pods simply join it and take advantage of the existing configuration. The resulting implementation is both easier to use and easier to understand.

Microsoft has used Istio as part of Azure Kubernetes Service for many years. Istio is one of a suite of open-source tools that provide the backbone of Azure’s cloud-native computing platform.

Introducing Azure Kubernetes Application Network

So, it’s not surprising to learn that Microsoft is using Istio’s ambient mesh as the basis of Azure Kubernetes Application Network. The new service (available in preview) allows application developers to add managed network services to their applications without needing the support of a platform engineering team to implement a service mesh. It will even help you migrate away from the now-deprecated ingress-nginx by providing access to the recommended Kubernetes Gateway API without needing more sidecars and letting you use your existing ingress-nginx configurations while you complete your migration.

Microsoft describes the preview of Azure Kubernetes Application Network as “a fully managed, ambient-based service network solution for Azure Kubernetes Service (AKS).” The underlying data and control planes are managed by AKS, so all you need to do is connect your AKS clusters to an Application Network and AKS will then manage the service mesh for you, without any changes to your applications.

Like other implementations of Istio’s ambient mesh, there are two levels to Application Network: a core set of node-level application proxies that handle connectivity and security for application services, and an optional set of lower-level proxies that support routing and apply network policies, acting as a software-defined network inside your Kubernetes environment.

This approach lets you build and test a Kubernetes application on your local development hardware without using Application Network features, then deploy it to AKS along with the required network configuration — simplifying both development and deployment. It also reduces development overheads, both in compute and developer resources.

Using Azure Kubernetes Application Network

Once deployed Application Network connects the services in your application securely, managing encrypted connections automatically and managing the required certificates. It can support unencrypted connections, for when you aren’t sending confidential data and don’t need the associated overhead. As the service is managed by AKS, new pods are automatically provisioned as they are deployed, with the ambient mesh supporting both scale-up and scale-down operations.

The architecture of Application Network is much like that of an Istio ambient mesh. The main difference is that the service’s management and control planes are managed by Azure, with application owners limited to working with the service’s data plane, configuring operations and setting policies for their application workloads. Azure’s control of the management plane automates certificate management, ensuring that connections stay secure and there is little risk of certificate expiration, using the tools built into Azure Key Vault.

The Application Network data plane holds proxies and gateways used by the service mesh, and these are deployed when the service is launched, along with the required Kubernetes configurations. The key to operation is ztunnel, a proxy that intercepts inter-service requests, secures the connection, and routes requests to another ztunnel running with the destination service. A gateway oversees connections between ztunnels running in remote clusters, allowing your service mesh to scale out with demand.

Building your first ambient service mesh in AKS

Getting started with Azure Kubernetes Application Network requires the Azure CLI. If you’re working with an existing AKS cluster, then you will need to enable integration with Microsoft Entra and enable OpenID Connect.

As the Application Network service is in preview, start by registering it in your account. This can take some time, but once it’s registered you can install the AppNet CLI extension that’s used to manage and control Application Network for your AKS clusters. You can now start to set up the ambient service mesh, either creating new clusters to use it, or adding the service mesh to existing AKS deployments.

Starting from scratch is the easiest way, as it ensures that you’re running in the same tenant. AKS clusters and Application Network can be in the same resource group if you want, but it’s not necessary. You’re free to use separate resource groups for management.

The appnet command makes it easy to create an Application Network from the command line; all you need is a name for the network, a resource group, a location, and an identity type. Once you’ve run the command to create your ambient mesh, wait for the mesh to be provisioned before joining a cluster to your network. This again simply needs a resource group, a name for the member cluster, and its resource group and cluster name. At the same time, you define how the network will be managed, i.e. whether you manage upgrades yourself or leave Azure to manage them for you. Additional clusters can be added to the network the same way.

With an Application Network and member clusters in place, the next step is to use Kubernetes’ own tooling to add support for the ambient mesh to your applications. Microsoft provides a useful example that shows how to use Application Network with the Kubernetes Gateway API to manage ingress. You need to use kubectl and istioctl commands to enable gateways and verify their operation, adding services and ensuring that they are visible to each other through their respective ztunnels.

Securing applications with policies

Policies can be used to control access from the application ingress to specific services as well as between services, reducing the risk of breaches and ensuring that you control how traffic is routed in your application. These policies can be locked down to ensure only specific methods can be used, so only allowing HTTP GET operations on a read-only service, and POST where data needs to be delivered. Other options can be used to enforce OpenID Connect authorization at a mesh level.

Not all Azure Kubernetes clusters are supported in the preview, which is only available in Azure’s largest regions. For now, Application Network won’t work with private clusters or with Windows node pools. Once running you can’t switch upgrade modes, and as it’s based on Istio, you can’t enable Istio service meshes in your cluster. These requirements aren’t showstoppers, and you should be able to get started experimenting with the service as it’s still in preview.

AKS Application Network is a powerful tool that helps simplify and secure the process of building and running inter-cluster networks in an AKS application. As it is an ambient service, it’s possible to scale as necessary, and can help provide secure bridges between clusters. By working at a Kubernetes level, it’s possible to use Application Network to provide policy driven production network rules, allowing developers to build and test code in unrestricted environments before moving to test and production clusters.

As Application Network uses familiar Kubernetes and Istio constructions, it’s possible to build configurations into Helm charts and other deployment tools, ensuring configurations are part of your build artifacts and that network configurations and policies are delivered with your code every time you push a new build – without needing platform engineering support.

Microsoft has quietly introduced the Agent Governance Toolkit, an open-source project designed to monitor and control AI agents during execution as enterprises try to move them into production workflows.

The toolkit, which is a response to the Open Worldwide Application Security Project’s (OWASP) emerging focus on AI and LLM security risks, adds a runtime security layer that enforces policies to mitigate issues such as prompt injection, and improves visibility into agent behavior across complex, multi-step workflows, Imran Siddique, principal group engineering manager at Microsoft wrote in a blog post.

More specifically, the toolkit maps to OWASP’s top 10 risks for agentic systems, including goal hijacking, tool misuse, identity abuse, supply chain risks, code execution, memory poisoning, insecure communications, cascading failures, human-agent trust exploitation, and rogue agents.

The rationale behind the toolkit, Siddique wrote, stems from how AI systems increasingly resemble loosely governed distributed environments, where multiple untrusted components share resources, make decisions, and interact externally with minimal oversight.

That prompted Microsoft to apply proven design patterns from operating systems, service meshes, and site reliability engineering to bring structure, isolation, and control to these environments, Siddique added.

The result was the Redmond-headquartered giant packaging these principles into the toolkit comprising seven components available in Python, TypeScript, Rust, Go, and .NET.

The cross-language approach, Siddique explained, is aimed at meeting developers where they are and enabling integration across heterogeneous enterprise stacks.

As for the components, the toolkit includes modules such as a policy enforcement layer named Agent OS, a secure communication and identity framework named Agent Mesh, an execution control environment named Agent Runtime, and additional components, such as Agent SRE, Agent Compliance, and Agent Lightning, covering reliability, compliance, marketplace governance, and reinforcement learning oversight.

Beyond its modular design, Siddique further wrote that the toolkit is built to work with existing development ecosystems: “We designed the toolkit to be framework-agnostic from day one. Each integration hooks into a framework’s native extension points, LangChain’s callback handlers, CrewAI’s task decorators, Google ADK’s plugin system, Microsoft Agent Framework’s middleware pipeline, so adding governance doesn’t require rewriting agent code.”

This approach, the senior executive explained, would reduce integration overhead and risk, allowing developers to introduce governance controls into production systems without disrupting existing workflows or incurring the cost and complexity of rearchitecting applications.

Siddique even went on to give examples of several framework integrations that are already deployed in production workloads, including LlamaIndex’s TrustedAgentWorker integration.

For those wishing to explore the toolkit, which is currently in public preview, it is available under an MIT license and structured as a monorepo with independently installable components.

Microsoft, in the future, plans to transition the project to a foundation-led model and is already engaging with the OWASP agentic AI community to support broader governance and stewardship, Siddique wrote.

The article originally appeared in InfoWorld.

Microsoft has quietly introduced the Agent Governance Toolkit, an open source project designed to monitor and control AI agents during execution as enterprises try, and move them into production workflows.

The toolkit, which is a response to the Open Worldwide Application Security Project’s (OWASP) emerging focus on AI and LLM security risks, adds a runtime security layer that enforces policies to mitigate issues such as prompt injection, and improves visibility into agent behavior across complex, multi-step workflows, Imran Siddique, principal group engineering manager at Microsoft wrote in a blog post.

More specifically, the toolkit maps to OWASP’s top 10 risks for agentic systems, including goal hijacking, tool misuse, identity abuse, supply chain risks, code execution, memory poisoning, insecure communications, cascading failures, human-agent trust exploitation, and rogue agents.

The rationale behind the toolkit, Siddique wrote, stems from how AI systems increasingly resemble loosely governed distributed environments, where multiple untrusted components share resources, make decisions, and interact externally with minimal oversight.

That prompted Microsoft to apply proven design patterns from operating systems, service meshes, and site reliability engineering to bring structure, isolation, and control to these environments, Siddique added.

The result was the Redmond-headquartered giant packaging these principles into the toolkit comprising seven components available in Python, TypeScript, Rust, Go, and .NET.

The cross language approach, Siddique explained, is aimed at meeting developers where they are and enabling integration across heterogeneous enterprise stacks.

As for the components, the toolkit includes modules such as a policy enforcement layer named Agent OS, a secure communication and identity framework named Agent Mesh, an execution control environment named Agent Runtime, and additional components, such as Agent SRE, Agent Compliance, and Agent Lightning, covering reliability, compliance, marketplace governance, and reinforcement learning oversight.

Beyond its modular design, Siddique further wrote that the toolkit is built to work with existing development ecosystems: “We designed the toolkit to be framework-agnostic from day one. Each integration hooks into a framework’s native extension points, LangChain’s callback handlers, CrewAI’s task decorators, Google ADK’s plugin system, Microsoft Agent Framework’s middleware pipeline, so adding governance doesn’t require rewriting agent code.”

This approach, the senior executive explained, would reduce integration overhead and risk, allowing developers to introduce governance controls into production systems without disrupting existing workflows or incurring the cost and complexity of rearchitecting applications.

Siddique even went on to give examples of several framework integrations that are already deployed in production workloads, including LlamaIndex’s TrustedAgentWorker integration.

For those wishing to explore the toolkit, which is currently in public preview, it is available under an MIT license and structured as a monorepo with independently installable components.

Microsoft, in the future, plans to transition the project to a foundation-led model and is already engaging with the OWASP agentic AI community to support broader governance and stewardship, Siddique wrote.

Writing a conference preview is an act of professional speculation. You read the agenda, map the schedule session density, and make your personal best call about where the intellectual energy will concentrate.

From my perspective going in, RSA Conference 2026 outlined a defining tension for CISOs today: how to enable AI adoption fast enough to stay competitive while securing the enterprise against a threat landscape AI itself is reshaping.

Now that RSAC 2026 has run its course, it’s worth holding pre-event predictions, such as my five key priorities for CISOs and their teams, against what actually emerged from the sessions, VC panels, and hallway conversations that tend to be more candid than anything on stage.

The verdict: the frame held. In fact, there was very little conversation without AI being front and center. At the Moscone Center in San Francisco I kept hearing, ‘We live in unprecedented times’ — a cliché that I do believe is true.

My own surprises were mostly matters of AI emphasis and velocity with stronger and perhaps sharper commercial edges than I expected.

The AI saturation hypothesis was confirmed

My RSAC 2026 preview argued that AI was no longer a track but had become the event itself, with approximately 40% of the agenda AI-weighted across every cyber domain.

That certainly bore out on stage. Every panel, whether focused on investment, products, identity, or offensive capability, returned to AI. Yoav Leitersdorf of YL Ventures put this bluntly: “Everyone only wants to talk about AI, and if you aren’t doing AI, investors don’t want to talk to you.”

Kevin Mandia from Ballistic Ventures at the RSA Annual Executive Dinner noted that we have to take humans out of the loop, so that AI versus AI is the new paradigm. He explained that AI agents have been introduced into red teaming exercises and are capable of operating at scale and with speed. So, while AI compresses the attack cycle, AI can also “automate” existing teams to improve their response from 5 days to 5 minutes.

What my preview couldn’t fully anticipate was the degree to which the AI narrative forked into two distinct commercial pressures running simultaneously.

Dave DeWalt of NightDragon captured both sides: AI as a tool for defense and offense, but also AI as a structural force flattening the competitive landscape between established vendors and startups. His observation that Series A funding is now looking to be $100 million — and that he’d never seen capital deploy this fast — landed with impact.

RSAC 2026 felt less like a learning event and more like a deal-making environment with educational sessions attached.

Securing the AI stack: Yes, but the threat surface has grown

The first technical priority I offered for CISOs in my conference preview was securing the AI stack — RAG workflows, LLM data pipelines, vector databases, and model APIs — on the basis that prompt injection, training data poisoning, and model inversion attacks were no longer theoretical.

The floor validated this but added dimensions my preview had underweighted. Mike Leland of Island framed the enterprise AI risk surface comprehensively: data leakage, shadow AI, prompt injection, copyright and IP infringement, hallucinations, and data residency. These aren’t sequential concerns — they arrive simultaneously the moment an organization allows AI tools into the environment.

The AI red teaming conversation surfaced with more commercial urgency than anticipated. Frontier Labs’ Brian Singer described environments where AI attackers operate at 1,000 times the speed of human adversaries, pushing the securing-the-stack conversation from defensive posture into something more active. While my preview was right about the topic, it underestimated the operational tempo.

On the conference floor I caught up with Singulr CEO Shiv Agarwaland Richard Bird, Singulr’s CSO and chief strategyofficer,whose platform is attempting to solve this visibility problem at scale. Their starting point was blunt: “AI usage is going out of control at the enterprise. The CIO, the CSO, they need some level of control, but without stopping or slowing down innovation.”

What Singulr’s discovery work is revealing is more of an issue than most boards appreciate. Bird told me that across enterprise assessments, they consistently surface between 350 and 430 AI services and features in active use, the overwhelming majority of which were never formally sanctioned. The shadow AI problem isn’t theoretical. It’s already deployed.

He offered a more nuanced risk framing than most vendors I encountered: context matters as much as the tool itself. “ChatGPT is a very well-contracted and approved AI service,” he said. “But if someone is using it with a personal account and model training has not been turned off, it brings the same risk as a service put up by two people in a garage.” Unfortunately sanction alone doesn’t confer safety.

Non-human identity: The standout theme of the conference

My preview identified non-human identity (NHI) governance as rapidly becoming one of the most consequential operational gaps in enterprise security. This proved to be my most prescient call. It wasn’t just a track; it became a through-line across multiple panels. Ross Haleliuk noted bluntly that machine identities already outnumber human ones.

Mark McClain, founder of SailPoint, reframed the entire identity management problem around agent intent and context: Humans we assumed were at an office or working remotely, but do we understand the intention of an AI agent, and do we have guardrail policies capable of reasoning about that?

McClain’s framing felt the most intellectually honest moment of the conference on this topic. He acknowledged that new technology was coming that would put his own platform under pressure, while simultaneously arguing that anyone who believes you can master the agentic world in isolation without human oversight is being misled.

The infrastructure question was taken further in my conversation with Noam Issachar and Jake Turetsky of Jazz, whose platform is building what they describe as a control plane for the agentic layer. Their framing was architecturally provocative: “AI is the new infrastructure. An AI agent can conduct and take action for something that looks like data transformation and never go into the lower tiers of the technology stack.” In their view, the agent layer is becoming the new HTTP — a data transport and transformation tier that sits above traditional infrastructure but below application logic.

What they found most troubling was the governance vacuum that currently exists in that space: “If AI is truly transformational, then why is there no transformation of processes, policies, and governance to reflect the fact that traffic management is already happening there?” It’s a fair challenge. The architecture has moved faster than the frameworks built to govern it.

AI governance: Present, but absorbed into broader conversations

The compliance priority in my preview centered on the EU AI Act and the need for CISOs to develop defensible licence-to-operate frameworks for AI deployment.

This theme was present at RSAC but was somewhat absorbed into broader discussions about regulatory alignment rather than treated as a standalone priority. VP of Google Threat Intelligence Sandra Joyce’s exchange with Richard Horne of the NCSC touched on the tension between defenders and attackers both benefiting from AI — the NCSC providing framework standards that regulators then align to, a model of governance by reference rather than prescription.

Jay Bavasi, CEO of EC Council, offered the most direct governance framing I encountered across the entire week: “Our attitude as a community has been shoot first, ask questions later. But what we should be doing is ask questions first, shoot later.”

The data behind that charge is harder to dismiss than the rhetoric. Bavasi cited that 84% of Fortune 500 companies reference AI implementation in their 10-K filings. He noted that the proportion that claims to have actual AI governance in place is just 18%. With 72 countries having already launched AI regulations or frameworks, the gap between disclosure and accountability is widening, not closing.

Singulr’s Bird reinforced this concern from an operational standpoint, noting that the governance conversation is still largely performative inside most enterprises — boards are discussing AI risk without the institutional mechanisms to actually manage it.

In-Q-Tel’s Katie Gray offered the sharpest counterweight to the governance narrative: There has never been a better time to sell to the US government, and the DoD spends $5 billion on cyber annually. In that environment, governance conversations are less about compliance architecture and more about positioning to capture procurement.

Shadow AI: Validated and commercially urgent

My preview’s risk priority around shadow AI and vibe coding — unsanctioned AI tool usage largely invisible to security teams — was confirmed across multiple sessions. Leland’s readiness framework put it plainly: Do you have visibility of shadow AI tool usage across the enterprise? Can you identify and prevent inappropriate data usage with gen AI tools?

Singulr’s Agarwal added a dimension that most vendors are reluctant to name. The most commonly discovered unsanctioned AI application in enterprise assessments is Grammarly — not a rogue model or an exotic data exfiltration tool, a writing assistant that most employees assume is benign and most IT teams have never thought to classify as AI risk.

His broader point about risk posture deserves to sit with board directors: “Your monthly board report is kind of useless in a way because your risk position today versus this morning is different.” A static governance snapshot of a dynamic and real-time threat surface is a category error, not a reporting format.

Team8’s Amir Zilberstein flagged investment in a reimagined DLP category on exactly this basis, the old category was hated, but AI-driven classification changes what’s possible.

What my preview missed

Two things the pre-event article didn’t fully anticipate:

First, the capital concentration dynamic. Amir Zilberstein’s observation that more funding is going to fewer companies, combined with David DeWalt’s seed and Series A figures, describes a market consolidating at the top even as it fragments at the bottom. The 9,900 cyber companies DeWalt cited aren’t all going to survive contact with AI titans crossing over from the SaaS world.

Second, the workforce conversation. This was the thread I found most unresolved across every conversation I had on stage and off.

Many speakers quoted Jensen Huang’s 1:2,000 agent-to-human ratio framing. Then I’d note Yoav Leitersdorf counsel to keep R&D flat and grow through AI, and Mark McClain’s observation that AI agents operate at a speed humans physically cannot match — these signals point to a structural workforce shift that cybersecurity leadership hasn’t fully internalized yet.

EC Council’s Bavasi was the most direct voice on this. He pushed back on the premise that CISOs should own AI wholesale: “CISOs are already suffering. A thousand things are already going on. It is one of the most short-lived jobs in the world. And you’re about to throw a behemoth to them.”

He cited 4 million cybersecurity jobs unfilled today, with that figure likely to double as the agentic layer matures — not because demand shrinks, but because the skill profile required is fundamentally different.

Bavasi also landed what I’d call the most confronting statistic of the week — not about threat actors, but about the industry’s own readiness: “We are living in an era where AI agents already have a social media community of their own. We live in an era where humans are being threatened and blackmailed and we still haven’t figured out how we’re going to implement responsible AI governance and ethics,” he said.

Closing observation

While my preview was focused on what CISOs needed to learn at RSAC, what the floor revealed was that some of that may require them to rethink how their teams are built, how their governance is structured, and how they report to boards, which are asking AI governance questions but receiving answers designed for a different era.

The intelligence is accumulating. The institutional response is lagging. That gap was the real story of RSAC 2026.

Attackers have exploited a critical Langflow RCE within hours of disclosure, prompting the US Cybersecurity and Infrastructure Security Agency (CISA) to formally flag it for urgent remediation.

The flaw, which allows running arbitrary code on vulnerable Langflow instances without >credentials, was weaponized within 20 hours of the open-source AI-pipeline tool disclosing it.

According to a Sysdig report, crooks started hitting a fleet of honeypot nodes with vulnerable instances across multiple cloud providers and regions right after they went live. Sysdig observed four such attempts within hours of deployment, with one attacker progressing to environment variable exfiltration.

“This is notable because no public POC repository existed on GitHub at the time of the first attack,” Sysdig researchers said. “The advisory itself contained enough detail (the vulnerable endpoint path and the mechanism for code injection via flow node definitions) for attackers to construct a working exploit without additional research.”

CISA has added the flaw to its Known Exploited Vulnerabilities (KEV) catalog, urging federal agencies to patch their systems by April 8, 2026.

A default setting allows code injection

The vulnerability, tracked as CVE-2026-33017, stems from an exposed API endpoint in Langflow, the open-source visual framework for building AI agents and Retrieval-Augmented Generation (RAG) pipelines.

The exposure allows attackers to submit malicious workflow data containing embedded Python code. Instead of using trusted data, the application executes this attacker-supplied code without any sandboxing, leading to unauthenticated remote code execution on affected systems, according to an NVD description.

“The build_public_tmp endpoint is designed to be unauthenticated (for public flows) but incorrectly accepts attacker-supplied flow data containing arbitrary executable code,” the description added. “This is distinct from CVE-2025-3248, which fixed /api/v1/validate/code by adding authentication.”

The Code Injection flaw affects Langflow versions up to (excluding) 1.8.2, and has been fixed in v1.9.0. It received a critical CVSS rating of 9.3 out of 10, owing to its “unauthenticated” and simple exploitability, massive AI attack surface, and high impact.

Pace of exploit raises concerns

Exploitation activity was observed less than a day after the vulnerability became public, which, Sysdig noted, demonstrates threat actors quickly operationalizing new vulnerabilities (probably through automation).

Attackers could build a working exploit just from the advisory description and quickly start scanning for flawed instances. “Exfiltrated information included keys and credentials, which provided access to connected databases and potential software supply chain compromise,” Sysdig researchers said.

With patch windows collapsing significantly, runtime detection remains a primary and the only option, Sysdig noted. “Every attacker in this campaign followed the same post-exploitation playbook: execute a shell command via Python’s os.popen(), then exfiltrate the output over HTTP,” it said, adding that runtime rules can detect these attempts.

The way runtime detection can help is by working on “day zero,” the researchers explained. “These rules do not require a signature for CVE-2026-33017 specifically because they detect the exploitation behavior, not the vulnerability. The same rules would fire regardless of whether the initial access came through CVE-2026-33017, CVE-2025-3248, or any other RCE in an application.”

Sysdig also shared a list of indicators of compromise (IOCs), including attacker source IPs, C2 and staging infrastructure detected, Dropper URLs, and interactsh callback domains. It recommends immediately upgrading to patched versions, restricting exposure, and monitoring for anomalous activity, emphasizing that exposed instances should be treated as potentially compromised.

For most enterprises, the question of whether to invest in AI is no longer up for debate. AI is already part of the roadmap, the budget, and the board conversation. The harder question now is how to make AI deliver value at scale, not once, but repeatedly, across teams, functions, and geographies.

That is where many organizations are struggling.

AI pilots often succeed. Teams demonstrate working models, agents, or assistants that show clear promise. The difficulty begins when those pilots are expected to move into production and then expand across the enterprise. Progress slows. Complexity increases. Confidence fades. What looked straightforward in a controlled environment becomes fragile in the real world.

In most cases, this has little to do with the quality of the model. It has everything to do with the system required to run AI reliably inside an enterprise.

The gap between building AI and running it

AI is still commonly discussed as if it were a discrete capability. A model is trained. A use case is defined. An application is deployed. In practice, the model is only one part of a much larger picture.

The moment AI moves toward production, a broader set of requirements comes into play. Infrastructure must be provisioned and operated. Data pipelines need to be maintained. Models must be deployed, monitored, updated, and governed over time. Security controls must be enforced. Audit and compliance expectations must be met. Costs must be tracked, explained, and justified as usage grows.

None of this work is optional. It determines whether AI can be trusted, scaled, and sustained. Yet it is often underestimated at the outset. Many AI initiatives begin with a narrow focus on the use case itself, assuming the surrounding work can be addressed incrementally.

That assumption is where most programs begin to stall.

The hidden platform work no one plans for

Every AI initiative introduces platform work, whether organizations intend it or not. Teams select tools, build environments, and define processes to solve immediate needs. Over time, these decisions accumulate. Different teams take different paths. Knowledge fragments. Operational complexity grows.

What emerges is not a deliberate platform strategy, but an accidental one. AI adoption slows not because ambition has faded, but because each additional use case becomes harder to support. Deployments take longer. Costs become less predictable. Risk becomes harder to explain to regulators and leadership.

This is not a failure of technology. It is a mismatch between ambition and operating model.

Why AI does not scale like traditional software

Enterprises have decades of experience scaling applications. They know how to manage infrastructure, security, and operations for conventional systems. AI behaves differently.

Models are influenced by data as much as code. Their behavior can change over time. They introduce requirements around explainability, bias, and accountability that traditional applications never had to address. Treating AI as just another workload often leads to friction across development, deployment, and governance.

To compensate, organizations rely on manual effort and individual expertise. Custom solutions are built. Reviews are handled case by case. Progress depends on people rather than systems. This approach can work for a handful of initiatives. It does not work when AI is expected to scale across the enterprise.

Build versus buy is not the starting question

Build versus buy is often the first question leaders ask once AI initiatives begin to scale. Should these capabilities be built internally, or sourced from a platform or partner? It is a reasonable question, but it is frequently asked too early.

In practice, build versus buy is not a starting point. It is the outcome of a more fundamental decision about how the organization intends to operate AI at scale. As AI adoption expands, operational complexity rises quickly. Internally built tools become harder to maintain as models, techniques, and regulatory expectations evolve. Switching costs increase as workflows become more agent-driven. Procurement grows more complex, with concerns around pricing models, flexibility, and long-term dependency moving into the CIO’s line of sight.

In this context, the more important leadership question is whether the organization can move reliably from experimentation to production, and then repeat that process across teams, use cases, and regulatory environments. That is an operating model question, not a tooling one.

Building makes sense when an organization has a clear and sustained advantage that depends on owning the platform layer itself. This is often true in highly specialized environments, unique deployment constraints, or when AI capabilities are intended to be productized. Buying or partnering is usually the more practical path when speed, repeatability, and predictability matter most. In these cases, the goal is not to become an AI platform company, but an AI-powered business. The most effective approach is to buy the foundation that enables scale, and build the capabilities that differentiate.

From AI initiatives to AI production systems

Organizations that succeed with AI make an important shift. They stop treating AI as a series of initiatives and start managing it as a production capability.

A production capability emphasizes consistency over novelty. It prioritizes repeatability, visibility, and control. It allows teams to innovate within a shared framework that reduces friction and risk.

This does not require centralizing innovation or slowing teams down. It requires providing a common foundation that makes it easier to operate AI responsibly by default. Most enterprises have navigated similar transitions before with cloud platforms, data infrastructure, and DevOps practices. AI follows the same pattern, but with higher stakes.

Designing for the long run

The next phase of enterprise AI will not be defined by who experiments the fastest. It will be defined by who can operationalize intelligence in a way that is repeatable, governable, and sustainable.

That requires acknowledging a simple reality. AI is never just the AI. It is the system around it that determines success. Leaders who design for that reality early will scale with fewer surprises, lower risk, and far greater impact.

To learn more about Tata Communications AI Cloud.

Many leaders know empowered teams deliver better results, but not all leaders understand how to get there. It all starts with knowing what empowerment truly means.

Put simply: Empowerment is the absence of micromanagement. Empowerment provides the foundation for people to develop autonomy; to take action, responsibility, and accountability; and to have the room necessary to grow to become better at execution.

More to the point, however, empowerment requires leaders who are mature, capable, self-secure, and willing to elevate the organization to the next level. It involves delegating decision-making power, providing training and tools, and creating a supportive environment where staff can innovate, solve problems, and contribute meaningfully without constant oversight.

Empowerment leads not only to higher engagement, higher productivity, and faster and better outcomes, but also higher job satisfaction, ensuring employees stay longer, adding even more value to the long-term success of a company.

As a leader, you can’t empower your teams without the right preparation. You need to first instill confidence in your team to make decisions and contribute meaningfully.

You’ll want to start with your direct reports, and empower them to break things down similarly in their respective teams and sub-teams. This won’t be achieved in a week or even in months, especially in old-fashioned companies that are run in pyramidal structures.

Here’s a practical list of steps leaders should take to implement empowerment throughout their organizations effectively.

Build a foundation of trust

Start by demonstrating trust in your employees’ abilities by avoiding micromanaging and allowing them to handle tasks independently. This creates a safe environment where they feel valued and responsible.

In weekly meetings, lead by example by asking questions — not to control, but to make employees part of the path to a solution. And then ask them to execute it.

In subsequent meetings, focus on where you can help. When things go well, give positive feedback and more freedom. Let things fail early, but don’t place blame; focus instead on lessons learned.

Once when we were rolling out a well-known EDR tool, I knew the settings weren’t tight enough, nor were the received updates applied fast enough. So I asked two people to own this, come up with suggestions for tightening the screws, and guarantee a successful rollout on multiple OSes in parallel. The phased approach took serious time, but it got us there, and without breakdowns or other hiccups. This instilled tremendous trust into the team as they could see I had empowered and entrusted them, and they responded with improved, mature actions that significantly contributed to the successful rollout and optimization.

Set clear goals and expectations

When empowering, it’s vital to define specific, measurable objectives aligned with company vision and goals. I recommend the SMART goals methodology — specific, measurable, achievable, relevant, and time-bound — to ensure everyone understands their role and how it contributes to the bigger picture, reducing ambiguity.

It’s important to involve your people in this exercise. Make them help formulate the objectives and metrics, ask for their input on timing, and what support may be required. Don’t set non-achievable goals and don’t underestimate the relevancy factor. People want to be part of something that makes a difference.

Provide ongoing training and development

Leaders should also invest in skill-building programs, workshops, or online courses. In addition to equipping them with the knowledge and tools to excel, leaders must also ensure their people can leverage these learned skills on the job, by applying them.

This will not only solidify the training they have completed but also lead to broader, more business-relevant learnings and experiences. For example, a project leader fresh off their PMP certification empowered to execute a huge project with hundreds of dependencies will be better set up for long-term career success, and your company will benefit from it.

Delegate authority meaningfully

Assign decision-making power to employees at appropriate levels. If your latest technology solution can be implemented without your involvement, assign a direct report complete responsibility and accountability to roll out the solution with a phased approach, and monitor their progress via status reports, while also measuring outcomes.

Ultimate accountability rests with you of course, but by delegating authority you can better scale your team’s efforts, contributing additional overall results for your organization. If things don’t work out, keep delegated leaders accountable to solve the problems that arise. If the project involves other functions, ensure via your functional leader counterpart that delegated authorities will work cross-functionally.

Foster open communication

Encourage two-way dialogue through regular meetings, feedback sessions, and anonymous channels. Keep in mind that different cultures require different styles, and you need to adapt the channel and facilitation to that, especially in international businesses. Employees must understand, however, that these are opportunities for open dialogue not finger-pointing.

Encourage innovation and risk taking

Create a culture where calculated risks are rewarded, even if they lead to failures sometimes. One way to do that is to implement “innovation time” by setting aside time (say, 5-10% of work hours) for experimentation or improving daily work. Once you continuously require your people to think about and act on improvements, you can see the results quite literally.

For risk taking, ensure people understand this doesn’t mean taking just any security risk, but instead encourage them to calculate security risk versus benefits (impact) and likelihoods, and to present — or when fully empowered, to act on — their findings. For example, At risk: $100,000; potential win of $500,000. Likelihood to win 0.5? Then take the risk. Contrary example: At risk: $500,000. Potential win: $100,000. Likelihood to win > 0.5? Choose not to take this security risk without additional controls and preparations.

Supply necessary resources

Ensure team members have access to the right tools, technology, and support systems. This could mean providing better software, more budget, or cross-departmental collaboration to remove barriers to success. I have teamed in the past with IT, OT, engineering, T&D, legal, HR, compliance, and even sales and marketing to get things over the “budget hump” — shared wins and shared successes will enable strong corporate culture and strong trust relationships.

Solicit and act on feedback

Regularly gather input via surveys or one-on-ones, then implement changes based on it. This shows employees their opinions matter, closing the loop on empowerment and driving continuous improvement. This last one is not to be underestimated in both value, guidance, honesty, integrity, visibility, and, last but not least, empowerment. You can proudly share meaningful work, growth, autonomy, and engagement scores on your resume. That is a true accomplishment.

Implementing these steps requires consistent leadership commitment. Start small, measure progress through employee satisfaction surveys, and adjust as needed for your organization’s context.