Enterprises are making AI easier to build without making it clear who will operate and improve what gets built.
A business team can create an assistant that interprets service manuals, prepares customer proposals or answers internal policy questions. The demonstration works. The pilot attracts support. The application goes live.
Who is responsible for keeping it useful a year later?
In The POC-to-Production Gap, I explored the organisational work required to turn a demonstration into a production application. Reaching production opens another question: who takes lasting responsibility for what has been built?
Traditional enterprises understand this responsibility. Industrial equipment comes with service arrangements. Field engineers visit sites. Remote teams diagnose faults. Software has application owners, support processes and maintenance budgets. These arrangements are imperfect, but the ongoing work is recognised.
With AI, the ability to build is spreading to teams that were never organised to maintain what they create.
Think of a building. Utility providers supply electricity and water. A contractor constructs it. An owner or facilities team takes responsibility for its ongoing condition.
If the neighbourhood loses water, the utility responds. If the roof leaks, a specialist repairs it. The building’s operator coordinates the response and plans improvements after the original contractor has left.
Enterprise AI needs the same clarity. IT provides shared infrastructure and access to approved models. Developers, implementation partners or business teams build applications on top. Someone must then take lasting responsibility for how those applications perform.
And with AI, failure can be difficult to see.
Imagine an assistant helping service engineers diagnose equipment faults. It responds quickly. Every technical dashboard is green. But it recommends an outdated repair procedure because a revised service manual never reached its knowledge base.
The infrastructure works. The service fails.
A business expert recognises the bad advice but may lack the skills to fix its cause. IT sees a functioning platform but may lack the domain knowledge or mandate to judge the answer. The original builder has moved to the next project.
The result is an application that everyone depends on and nobody fully owns.
This problem predates AI. What AI adds is a greater need to evaluate behaviour alongside technical availability. Changes to source information, model versions and business requirements can affect whether an answer remains acceptable. Google’s guidance for operating generative AI applications therefore includes continuous evaluation, monitoring and improvement after deployment. Google Cloud
DevOps and related AI engineering practices provide essential methods for doing this work. The enterprise still has to decide who performs it, who funds it and who can authorise changes.
The answer should be a durable operating capability with a named business owner accountable for outcomes, supported by people who combine domain knowledge and engineering expertise. Its responsibilities must be explicit alongside those of IT.
That team needs to do more than resolve support tickets. It must keep knowledge current, test changes, investigate unreliable answers and turn user feedback into improvements. It also needs the authority to change the surrounding workflow when the application creates extra work instead of removing it.
A team that builds and operates its own AI product may already cover these responsibilities. The challenge grows when innovation teams build applications for departments across the enterprise.
In my article on forward-deployed engineering, I argued that successful teams leave behind a stronger operating capability and less dependence on themselves. That requires a receiving organisation equipped to take over. Every new application creates an ongoing commitment; a handover document cannot substitute for people, budget and skills.
This is where the operating model affects returns. Poor answers create rework. Rework weakens trust. Users abandon the application, and the expected productivity gains disappear. A successful launch cannot compensate for an unfunded operating life.
Before approving the next AI application, leaders should ask three questions:
- Who owns its business performance after launch?
- Which team has the skills and authority to maintain and improve it?
- Does the business case fund that work?
The capacity to build AI must be matched by the capacity to operate it. Otherwise, every successful pilot adds another responsibility the enterprise has not equipped itself to carry.