It drifts. Not dramatically, and not all at once. The person who championed it leaves. The workflow it was built around changes. A software update alters a default nobody notices. The team develops a workaround and stops mentioning it, because after three weeks a workaround is simply how things are done. The tool keeps running, the invoice keeps arriving, and the gap between what it does and what everyone believes it does widens quietly for years. Ownership is what prevents this, and it costs almost nothing: a named person who would notice, a written line about where the tool may be used, a retirement it was meant to trigger, and a date in the calendar to check. The AI Alignment Filter™ gates the purchase. This is what happens the day after.
Introduction
There is a specific kind of organizational object I want to describe, because once you have a name for it, you will find several in your own operation this week.
It is a tool that works. Nobody complains about it. It appears on the invoice, it appears in the onboarding for new staff, and it has been there long enough that its presence requires no justification. If you asked why you have it, somebody would say it came in with the practice management change, or that the previous manager set it up.
Nobody owns it. Which means nobody checks it, nobody has evaluated it against what it costs since the day it was bought, and nobody has the standing to suggest removing it.
That object is not a disaster. It is a small permanent tax, and most organizations are paying several of them simultaneously.
This week is about not creating any more.
Key Takeaways
• Tools do not fail dramatically. They drift through staff turnover, workflow change, silent updates, and workarounds that nobody reports.
• Ownership means one named person who would notice if the tool started behaving differently, and whose job includes noticing.
• Adoption without a retirement is addition. The retirement was the justification, and if it never happens, the case for the purchase quietly expired.
• A review date set at purchase is worth more than any amount of scrutiny before purchase, because it is the only mechanism that catches a decision that turned out wrong.
• Silent adoption is the most common governance failure in small organizations, and four written lines prevent it.
• Installation is not adoption. Phased implementation exists because people need time to actually use a thing.
The Four Ways a Tool Drifts
The champion leaves. Almost every tool has one person who understood it properly, configured it, and knew its quirks. When that person moves on, the configuration stays, and the understanding does not. What remains is a system operating on settings nobody can explain.
The workflow moves underneath it. A tool is fitted to how you worked in a particular year. Then you add an associate, change your recall interval, restructure the front desk. The tool is still doing what it was set up to do, competently, for a process that no longer exists in that shape.
The software updates. Vendors change defaults, alter thresholds, and add features that are switched on by default. These arrive in release notes nobody reads. A system can behave differently on Monday from how it behaved on Friday without anyone in your building having made a decision.
The workaround becomes the process. This is the most common and the least visible. Someone finds the tool awkward for one case and handles it another way. Within a month, that is simply how it is done, and it does not get reported, because it no longer feels like a workaround. It feels like the job.
None of those is a failure of the tool or the team. All four are what happens to any system that nobody is responsible for looking at.
What Ownership Actually Means
Ownership is a specific and small thing, and it is routinely confused with three others.
It is not who bought it. It is not who uses it most. It is not who is senior enough to be blamed.
The owner is the person who would notice if the tool started behaving differently, and whose job explicitly includes noticing.
That definition has consequences. The owner has to be a user, because only users notice. It usually should not be the practice owner, because the practice owner is not in the system daily and will not see the change. And the owner needs enough standing to raise a problem and be listened to, which is a culture question rather than a job-title one.
One name per tool. Written down, in the same place as the invoice.
When you do this exercise for the first time, expect to find that two or three tools have no plausible candidate at all. That is the finding, and it is more useful than anything else the exercise produces.
The Retirement Was the Justification
Here is a discipline worth installing at the point of purchase rather than discovering later.
When a tool is approved, three things get written down. Who owns it. What it retires. And when you will decide whether it worked.
The middle one is the one people skip, and it is the one that carries the argument. Almost every purchase is justified on the basis that it will replace something: a manual process, a spreadsheet, a step, another tool. That replacement is the business case.
If the retirement never happens, the business case quietly expires, and nobody notices, because the tool is working and the old process is also working, and both are being paid for in time or money.
So write it down at approval, and put a date on it. Not "this will replace the manual recall list," but "the manual recall list stops on the fifteenth of March."
A retirement without a date is an intention. Intentions do not survive a busy quarter.
And if you genuinely cannot name a retirement, that is worth pausing on. Sometimes a tool adds a capability you did not have and should have, and that is a legitimate reason to buy. But a stack where every entry is an addition has only ever grown, and growth without retirement has a ceiling that arrives whether or not you planned for it.
The Review Date Is the Whole Mechanism
Of everything in this article, the review date does the most work, and it is the cheapest.
Before purchase, you are guessing. However carefully you evaluate, you are predicting how a tool will behave in your practice with your team and your patients, and you will sometimes be wrong. That is not a failure of diligence. It is the nature of prediction.
What separates organizations that recover from a bad purchase from organizations that carry it for years is not better evaluation. It is having a moment already in the calendar where somebody asks whether this is working.
Ninety days for something small. Six months for something that changed a workflow. And the question at that review is specific rather than general: did the thing it was supposed to replace actually stop? Is anyone running a parallel process? What has it cost in time that we did not count?
Put it in the calendar at the moment of approval, with the owner's name on it. A review that has to be remembered will not be held.
Silent Adoption
There is a governance failure specific to this class of tool, and it is now the most common one I hear about.
Nobody buys anything. Somebody starts using a free or personal AI tool for a work task because it is genuinely helpful. Somebody else does the same, differently, for a different task. Nothing is announced, because nothing feels like it needs announcing.
Within a few months, drafts are being produced one way by one person and another way by another, quality varies invisibly, and it is not clear what has been reviewed by a human and what has not. Nobody made a bad decision. No decision was made at all.
The remedy is four lines, written down and shared once.
Where AI is encouraged. Where it is limited. What must always be reviewed by a person before it leaves the building. And who holds final responsibility.
That is not a policy document, and it should not become one. It is four sentences that turn an unmanaged practice into a managed one, and most organizations have none of it.
Installation Is Not Adoption
One last distinction, drawn from Alex Zarifis's work on leading through AI transitions.
Zarifis argues against the wholesale approach, and his reasoning is practical rather than cautious. Leaders consistently underestimate how long a team needs before it is genuinely working in a new system rather than around it, and they mistake the moment the software goes live for the moment the change happened.
Those are separated by months, and the gap is where parallel processes breed.
His related point is that staging the change, and sometimes halting it for a spell, is the wiser option. That is uncomfortable advice in a market where everyone is being told they are behind. It is also the advice most likely to result in a tool that is actually used.
The practical test: a tool is adopted when the thing it replaced has stopped. Not when it is installed, not when training is complete, and not when the vendor's onboarding call is finished. When the old way has stopped.
Until then, you are running two systems and paying for both.
Frequently Asked Questions
We have tools nobody owns. Where do we start?
Pull the actual payments, list them, and put a name against each. Do the ones with no name first. For each of those, the question is not whether to keep it; it is whether anyone can describe what it does for you now.
What if the owner does not want the responsibility?
Then it is too heavy as you have defined it. Ownership here is noticing and raising, not fixing and defending. If it feels like being blamed for the tool, the definition needs correcting before the name does.
How do we handle the workaround problem?
Ask directly and ask safely. "Where do we do something both ways?" framed as looking for places the system failed the team, not places the team failed the system. That framing is also accurate, which is why it works.
Is a written AI policy overkill for a small practice?
It matters more in a small practice, not less. A large organization has compliance staff who will notice an unwritten rule. In a small practice, the policy is whatever the owner happens to do, and it gets copied by everyone who joins.
How often should tools be reviewed?
Annually for the full list, quarterly for the payments. The payment review catches the subscription with no users, which there almost always is.
Final Thoughts
None of this is difficult, and none of it takes long. That is precisely why it does not happen. Work that is neither urgent nor hard has to be scheduled, or it does not occur.
So schedule it. A name against every tool, a retirement with a date, a review in the calendar, and four lines about where AI may and may not be used.
An afternoon to set up. Twice a year to maintain. And it is the difference between a practice that owns its systems and a practice that is quietly maintained by them.
A tool nobody owns is a tool nobody checks.