The AI feature with no name on it

A platform lead at a retail company inherited a mess he did not create. An AI feature had shipped a year earlier, built by a team that had since been reorganized out of existence. The feature still ran. It still touched customers. And it belonged to no one. When it drifted, no one noticed until support tickets climbed. When the cost crept up, no one owned the bill. When he asked around who was responsible, he got a chain of people who had each touched it once and moved on. It was in production and it was an orphan.

He described the real cost of it, which is not dramatic and is exactly why it is dangerous. An orphaned feature does not crash. It degrades. It gets a little worse, a little more expensive, a little less trusted, and because no one owns it, no one is accountable for noticing. By the time it becomes a problem loud enough to assign, it has been quietly failing for months.

Unowned is worse than killed

A killed feature is a clean decision someone made. An orphaned feature is the absence of a decision, running on inertia and someone else’s credentials. The MIT finding that around 95% of enterprise AI pilots deliver no measurable return includes a lot of features exactly like this: not obviously dead, just never truly owned, quietly costing money and trust while everyone assumes someone is watching.

The root cause is almost always a handoff that never happened. The building team owned it during the build and no one owned it after. Reorganizations, departures, and shifting priorities all break the ownership chain, and AI features break in slow-motion ways that hide the break for a long time. A feature without a permanent home is a liability with a delay on it.

Giving a feature a permanent home

Assign the owner for the running feature, not just the build. The person accountable while it is live matters more than the person who wrote it. Name them before launch.
Make ownership survive reorgs. Tie the feature to a role or team that persists, not to an individual who might be moved. Orphans are usually made by org changes.
Watch the slow signals. Drift, cost creep, and rising tickets are how unowned features fail. Someone has to own noticing them, on a schedule, not by accident.
Have a real off switch. If a feature stops earning its keep, someone must own the decision to retire it. A feature that cannot be killed cannot be owned.

How we approach it at Density Labs

In our AI Opportunity Assessment ($2,500), we insist on an owner for the live feature, not only for the build. We map who is accountable once the launch team disperses, tie that ownership to something that survives a reorg, and name who watches the slow signals that orphaned features fail on. It is far cheaper to assign a permanent home before launch than to inherit an unowned model that has been quietly degrading for a year.

An AI feature with no name on it is abandoned in production, whatever the status board says. Give it an owner who is still there next quarter, or plan to inherit the orphan yourself.