AI coding makes internal software easier to create. Businesses still need someone responsible for its permissions, reliability, maintenance and eventual retirement.
AI-generated applications are creating an accountability challenge for technology leaders: the person who builds a useful tool may not be the person equipped to maintain it once colleagues depend on it.
Retool’s State of AI Governance in 2026 report says 44% of surveyed leaders either described responsibility for AI-tool incidents as dependent on the situation or said it had not been defined. That finding indicates the absence of a consistent default—not necessarily the absence of all accountability.
The vendor’s survey, conducted with Wynter in May and published on June 17, covered 307 senior technology and security leaders. Its respondents held CTO, CIO, CISO or closely related titles. These are self-reported findings from the surveyed group, rather than a census of businesses.
For organisations adopting AI coding, the practical question is what happens after a prototype becomes part of everyday work.
Building an app and running a service are different responsibilities
Consider a hypothetical operations employee who creates a dashboard to update delivery records.
Initially, it serves one team. Later, other departments begin using it, scheduled jobs depend on it and its database credentials gain broader access.
The original builder may understand the interface without having responsibility for backups, incident response or credential rotation. If that employee changes roles, the app can remain operational while its support arrangements disappear.
AI did not invent this problem. Faster software creation makes it easier to repeat.
A production app therefore needs an explicit operating arrangement: who approves changes, who responds when it fails and who decides whether it should continue running.
What the survey says about accountability
Retool reported that 32% of respondents assigned incident accountability to engineering leadership or the CTO, while 23% assigned it to the builder or building team. Another 34% said responsibility depended on the situation, and 10% said it was undefined.
The report also says 55% preferred security and access controls to sit in a central platform beneath generated applications. That is a preference expressed by respondents, not proof that a platform alone solves governance.
Situational responsibility can work when the rules are documented. For example, application maintainers might handle software defects while a platform team handles infrastructure outages.
The weakness arises when that division is negotiated during an incident.
Assign responsibilities before production access
A useful ownership model separates business decisions from technical duties.
The following is an illustrative allocation, not a universal organisational requirement:
| Responsibility | Accountable role | Decision or task |
|---|---|---|
| Business purpose | Business owner | Whether the app remains necessary |
| Application maintenance | Technical owner | Fixes, dependencies and releases |
| Data access | Data owner | Which records and operations are permitted |
| Shared infrastructure | Platform team | Hosting, identity integration and availability |
| Security exceptions | Designated risk owner | Whether a documented exception is accepted |
| Incident coordination | Named responder | Containment, communication and recovery |
One person may hold several roles in a small organisation. What matters is that the responsibilities are explicit and the people assigned have the authority and resources to fulfil them.
An owner field containing only a departed employee’s name is not an effective operating model.
Central controls help, but application checks remain necessary
Shared infrastructure can apply consistent authentication, secrets handling, deployment restrictions and audit logging.
This reduces the number of security decisions each builder must implement independently. However, platform permissions do not establish that an application’s business logic is correct.
An expense tool could authenticate every user successfully while approving reimbursements using the wrong calculation. A reporting dashboard could enforce database access correctly while displaying stale information.
Governance therefore needs both shared controls and checks specific to the application’s purpose.
Centralisation also creates dependencies. If many apps rely on one identity service or connector, its failure can affect them together. Availability, recovery and change management remain part of the assessment.
Give each app a minimum operating record
Before an internal tool receives production access, its inventory entry should answer a small set of practical questions:
- Who owns its business purpose and technical maintenance?
- Where do its source, deployment configuration and credentials reside?
- Which systems and data can it access?
- Who receives failure alerts?
- How can access be disabled?
- How can a faulty release be rolled back?
- When will its continued use be reviewed?
These records should connect to the deployed application. An inventory that is never updated can provide false confidence.
Where possible, deployment workflows should require the relevant ownership and access information rather than rely on someone remembering to add it later.
Measure the work that continues after launch
The first version of an app captures only part of its cost.
Maintenance includes dependency updates, security fixes, API changes, user support and checking whether outputs remain accurate. AI-generated code still needs those activities.
Organisations assessing productivity should therefore examine the full operating cycle. Useful measures include review effort, recurring support time, failure rates and the time needed to recover from a faulty change.
A tool that saves a department several hours each week may be valuable. That judgement is stronger when it also accounts for the work required to keep the tool dependable.
Retirement belongs in the ownership plan
Internal apps can outlive their original purpose.
A retirement process should remove deployments, scheduled jobs, credentials and unnecessary data copies while identifying anything that still depends on them. Removing the user interface alone may leave background access intact.
This is where accountable ownership becomes especially useful. Someone must be able to decide that the business no longer needs the app and coordinate its safe removal.
AI coding expands who can create software. Production responsibility still requires named people, enforceable controls and a maintained plan for what happens next.
Reporting note: Survey findings are attributed to Retool, which sells application-building and governance software. TechLayers did not conduct the survey or independently test its products. The report’s stated methodology specifies 307 respondents, while some chart descriptions display different totals; disputed figures have been omitted. Ownership tables and examples are editorial analysis.
