Most AI Teams Build. Very Few AI Teams Maintain.

The data science team builds a model. It ships. The team moves to the next project. The model runs in production. Nobody owns it.

This is not an edge case. This is the default operating model for enterprise AI.

The build-and-move-on culture

Data science teams are structured around building. The hiring profiles select for people who want to build. The performance reviews reward building. The conference talks are about building. The promotions go to people who shipped new models, not to people who kept old models running accurately.

So when a model deploys, the team's attention moves to the next build. This is rational behavior within the incentive system. The team isn't negligent — they're responding to what the organization values. And the organization values new over maintained.

The model, meanwhile, is in production. It's making predictions that influence decisions and affect customers. And the team that understands it best is working on something else. The model is, functionally, orphaned from the moment it ships.

What happens to orphaned models

The first few months are usually fine. The model was trained on recent data. The production environment matches the development environment closely enough. Performance holds.

Then the world changes. It always does. Customer behavior shifts. Data distributions drift. Upstream systems modify their schemas. New categories of input emerge that didn't exist in the training data. The model's accuracy degrades — not catastrophically, not all at once, but steadily.

Nobody notices. Not because nobody cares, but because nobody is looking. The team that built the model doesn't monitor it — they're building the next thing. The operations team keeps the infrastructure running but doesn't evaluate model performance — that's not their skill set or their mandate. The business team that uses the model's outputs notices that recommendations seem less accurate but attributes it to "edge cases" or "tough market conditions."

By the time the degradation is undeniable — a bad outcome traces back to a model prediction, a business metric moves in the wrong direction, a customer complaint escalates — the model has been underperforming for weeks or months. The remediation is now urgent, expensive, and visible. What should have been routine maintenance becomes an incident.

The maintenance gap

The gap is structural. Organizations have built the capacity to create AI systems but not the capacity to sustain them.

Building a model requires data scientists, ML engineers, and a project with a timeline. Maintaining a model requires ongoing monitoring, periodic retraining, performance evaluation against current conditions, documentation updates, and incident response capability. Building is a project. Maintenance is a function.

Most organizations fund projects. Very few fund functions for AI maintenance. There's no "model maintenance team." There's no "AI operations" role with clear responsibilities and career progression. There's no budget line for "keeping deployed models accurate." The organizational infrastructure for maintenance simply doesn't exist in most enterprises.

The result is predictable: every deployed model is slowly becoming an unmanaged risk. It's running. It's producing outputs. Those outputs are influencing decisions. And the gap between what the model was trained to do and what the current environment requires grows wider every day, unobserved and unaddressed.

Maintenance is where governance lives

Governance isn't primarily about what happens before deployment. It's about what happens after.

The model in the Jupyter notebook doesn't affect anyone. The model in production does. The decisions that matter — is this model still performing as intended, is it still appropriate for this use case, are the conditions that justified its deployment still valid — are all post-deployment questions. And they can only be answered by someone who is actively maintaining the system.

When I talk about AI governance, I'm not primarily talking about pre-deployment review boards or ethics committees or approval workflows. Those have their place. But the governance that matters most is the ongoing, unglamorous work of maintaining the systems that are already running: monitoring performance, detecting drift, retraining when necessary, updating documentation, and ensuring that every model in production has an owner who is accountable for its behavior.

If you don't have that, you don't have governance. You have launch governance. You governed the deployment decision. You did not govern the system.

The incentive problem

Maintenance doesn't get promoted, doesn't get conference talks, doesn't get LinkedIn posts. A data scientist who maintains ten models in production, keeping them accurate and well-documented, is less visible than a data scientist who ships one new model. The maintainer's work is invisible when it's done well — the models just keep working. It only becomes visible when it fails, at which point it's a problem, not an achievement.

This is the same dynamic that exists in traditional software engineering, and some organizations have solved it there — SRE teams, platform teams, dedicated operations roles with their own career ladders. The AI field hasn't built the equivalent yet. The result is that AI maintenance is either nobody's job or everybody's job, which amounts to the same thing.

Until organizations create roles, incentives, and accountability structures specifically for AI maintenance, every deployed model is degrading without anyone watching. The accuracy will degrade, the drift will accumulate, and the risk will grow. And the organization will discover the gap when a model fails visibly enough that someone asks: "Who was watching this?"

The answer, in most cases, will be: nobody. Not because nobody cared. Because nobody was assigned to.