Presented by Retool
Forty-four percent of senior tech and security leaders don’t have a clear default for who’s accountable when an AI-generated tool causes a production incident. Most couldn’t say whether they’d even had one in the past year because the monitoring isn’t there to tell them.
Leaders who focus on what happens after tools ship make the productivity gains AI promises without the tool sprawl that quietly eats them. Governance makes that possible.
We surveyed 307 senior technology and security leaders (CTOs, CIOs, and CISOs) on how they’re approaching governance in the era of AI coding. The findings show that accountability hasn’t kept up with capability.
Building is accelerating. Security can’t keep up.
The direction of travel is settled: more people are building more software, faster, and with less traditional engineering involvement. Ninety percent of the leaders we surveyed report increased pressure to enable AI-driven building, and most call it a net productivity win. The organizational structures that determine who owns what those people built haven’t moved at the same pace.
Too many businesses have too little accountability for AI-generated apps
When we asked leaders what happens when an AI-generated internal tool causes a production incident, 32% of respondents said engineering leadership or the CTO is held accountable, 23% said the team or individual who built it, and 34% said it depends on the situation. Ten percent haven’t defined it at all. Taken together, 44% of senior tech and security leaders are operating without a clear default for accountability.
“When anyone can ship a tool in an afternoon, nobody signs up to maintain it,” said one CITO we surveyed, commenting on the silent nature of AI failure. “Rot stays invisible until something breaks.” The result is a growing inventory of production tools with no clear owner or security oversight. Most leaders in our survey couldn’t say with confidence whether they’d even had a production incident from an AI-generated tool in the past year, simply because the monitoring isn’t there to confirm it either way.
New builders are operating outside of traditional governance
The ownership problem has always existed for internal tools. It’s fun to build your own, but painful to manage access and authentication. Someone’s hacked-together solution for a unique pain point works, until it doesn’t — by which time they may be long gone, along with the API key or account information. AI dials those risks up to 11, by empowering more team members to build, more quickly, and less securely.
The standard response to a governance gap is more process, but measures like additional review cycles, clearer policies, and better training for builders made sense when development was centralized and the volume of new tools was manageable. They don’t map well to an environment where a working internal tool can go from prompt to production in the course of an afternoon.
Seventy-eight percent of the leaders we surveyed describe their current governance as either manually maintained or uneven across teams. Most organizations are applying governance per tool, by individual builders — and the leaders we surveyed largely agree that’s the wrong model (just 7% supported this approach).
Policies that depend on individual builders to configure security correctly are always going to be more prone to human error. It’s not realistic to expect this new cohort of builders to get everything right, every time, and we can’t ask IT or engineering teams to be accountable for a firehose of new code.
Security standards should be set once and applied to every app, not rewritten every time
When we asked leaders where primary responsibility for security and access controls should sit, 55% said a centralized platform underneath the app: one that applies regardless of how the app was built or who built it. Security and data access controls ranked as the near-universal governance priority.
When Pierre-Yves Calloc’h was managing AI transformation at Pernod Ricard, he understood the impact of platform-level governance from the outset. When he worked on the company’s first AI projects, he treated governance as a necessary design constraint to be solved for, rather than negotiated around after the fact. By building within a governed platform, “the fact that there was that layer of security that guarantees you will never erase the production database gave everyone a lot of confidence,” Pierre-Yves said. “We got the authorization to go super fast and do things quick and semi-dirty in that environment.”
In Retool, whether a team prompts a tool into existence, imports an existing app, or builds through an AI coding assistant with MCP, it lands inside a governed platform with the permissions, resource model, and deployment controls the organization already trusts. Accountability doesn’t have to be negotiated tool by tool, because the platform enforces it by default.
As more non-engineers ship production software, building will keep outpacing ownership and accountability unless the governance layer moves from individual apps to the platform underneath them.
David Hsu is CEO at Retool.
Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.