The Accountability Gap
The Accountability Gap
Over the past weeks I have been speaking with several leaders in enterprise IT. Different industries, different company sizes, different maturity levels. Yet the same tension keeps surfacing in every conversation.
Publicly, the debate looks technical. Can AI really replace SaaS? Will companies rebuild Salesforce, SAP, or Office with coding agents? Is "vibe coding" good enough for production systems? Is governance ready for hundreds of AI agents committing code?
But after enough private discussions, a clearer pattern emerges. The common denominator is not capability. It is accountability.
The build curve has shifted
AI has materially reduced the marginal cost of building software. That is no longer hype. With modern coding agents, teams can assemble workflows, internal tools, even structured vertical systems in weeks instead of quarters. I see it in my own work every day, and I hear it from every engineering leader I talk to. The production curve has shifted.
What has not shifted at the same speed is the cost of organisational risk.
Enterprise IT leaders are not primarily worried about whether something can be built. They know it can. Many of them already run pilots where AI is generating code, tests, infrastructure, even documentation. The capability is real and getting more real every quarter.
The question they keep returning to is different: who owns it when it breaks?
Why SaaS actually won
SaaS did not win because enterprises forgot how to build. It won because it externalised responsibility.
Uptime. Security patches. Compliance. Audit trails. Regulatory updates. Support escalation. And perhaps most importantly, political cover when something fails. When your Salesforce instance goes down, that is Salesforce's problem. When your internally built CRM goes down at 2 AM, that is your team's problem, your VP's problem, your name on the incident report.
SaaS bundled software with accountability. The subscription fee was never just for the features. It was for the transfer of operational risk from the buyer to the vendor. Every enterprise IT leader I have spoken to understands this implicitly, even if they rarely articulate it in those terms.
The gap
AI reopens the build option, but it does not automatically repackage the responsibility layer. When an internal AI-built system fails, the liability does not sit with a vendor. It sits with the organisation. With a named executive. With a team that may or may not have the operational maturity to handle what they have built.
That is why brand still matters in enterprise procurement. That is why SLAs still matter. That is why "no one gets fired for buying IBM" remains a real dynamic in 2026, decades after anyone thought IBM was the most innovative option. The risk is not theoretical. It is personal and structural.
I have seen this play out directly. A team builds something impressive with AI in three weeks. It works in staging. It handles the demo beautifully. Then it hits production and encounters an edge case that the original prompts never anticipated. Suddenly there is no vendor to call, no SLA to invoke, no contractual obligation forcing someone else to fix it by morning. The team that built it is the team that owns it, and they discover at the worst possible moment that building fast and operating reliably are two very different skills.
The governance surface
There is also a second-order effect emerging that not enough people are talking about. As enterprises experiment with fleets of AI agents generating and committing changes, the governance surface expands rapidly.
Leaders are starting to see a potential governance gap. Capability is scaling faster than control frameworks. Hundreds of autonomous or semi-autonomous agents modifying production systems is not just a tooling problem. It is an operating model problem.
Who reviews what an agent commits? Who approves the architectural decisions an agent makes at 3 AM? Who is responsible when an agent introduces a subtle security vulnerability that passes all the automated checks but would have been caught by a senior engineer during code review? These are not hypothetical questions. They are questions I hear in every conversation with CTOs and VPs of engineering who are running these pilots right now.
The organisations that figure this out first will have a genuine competitive advantage. But figuring it out means building internal governance infrastructure that is, ironically, just as complex as the SaaS platforms they are trying to replace.
Two curves diverging
So the debate is not "AI versus SaaS". It is about the divergence between two curves.
The cost of building is collapsing. The cost of being accountable is not.
Until those curves realign, enterprises will not simply abandon SaaS, and they will not blindly internalise everything either. What will change is pricing power and expectations. Vendors that relied on inertia and contractual lock-in will struggle. Vendors that genuinely absorb operational complexity will remain relevant. Internal teams that choose to build will need to professionalise governance to a level historically associated with platform vendors.
After speaking with multiple enterprise IT leaders, I am convinced the next battleground is not model quality. It is not even feature parity. It is operational accountability.
AI changes how fast we can build. It does not change who is responsible when something goes wrong. And in enterprise environments, that is the variable that actually drives decisions.