How it gets there
Someone needed data from one system in another, wrote something small to move it, and it worked. It was never a project, so it was never reviewed, documented, or assigned an owner. Years later the business depends on it and the author has left.
The cost is invisible until it isn’t
Unowned integrations fail quietly. They stop syncing, drop records, or silently transform something incorrectly, and the discovery usually happens through a customer noticing a discrepancy rather than through a monitor. By then the bad data has propagated.
Unowned code doesn’t announce that it broke. It just stops being right.
Find them before they find you
They are locatable: look for scheduled jobs nobody scheduled recently, API keys attached to a personal account, scripts on a machine under someone’s desk, and any process where the answer to “what happens if this stops?” is a shrug.
Three questions decide what to do
Does the business notice within a day if it stops? Can anyone currently employed explain it? Is there a supported product that does the same thing? The answers sort each one into keep-and-own, replace, or delete — and a surprising number are genuinely deletable.
Owning one means four things
A named owner, credentials on a service account rather than a person, an alert when it fails rather than when someone notices, and a page describing what it does. That is a day of work, and it converts a liability into infrastructure.
It is also the prerequisite for anything smarter later: you cannot add AI to a workflow whose data arrives through a pipe nobody understands.