The Hidden Costs of DIY Enterprise AI

A system you build yourself is not a purchase, whatever the business case called it. It is a tenancy, and the rent comes due in the attention of whoever happens to be holding it two years later.

The screenshot lands in a channel on a Tuesday afternoon, posted by someone in sales operations who is more puzzled than annoyed. The internal assistant — the one the platform team built, the one that was genuinely good, the one that answers questions about entitlements and contract terms by reading across the CRM, the billing system, and a shared folder of legal templates — has started returning renewal dates that are about three weeks off for a particular class of accounts. Nobody has touched it in seven months. Nobody needed to, and that fact had quietly been taken as evidence that the thing was finished.

What actually changed happened somewhere else entirely. The CRM vendor shipped a minor release in which a field that used to hold a contract's effective date began, for accounts migrated onto a newer billing plan, holding the date of the migration instead. The change was documented in release notes nobody on the platform team subscribes to, because when the assistant was built there was no platform team, only two engineers and a mandate. One of them is now on the payments team and the other left last spring. The person who picks up the ticket spends the better part of two weeks reading a codebase in which every decision was reasonable and almost none of the reasoning was written down, finds the field, patches the mapping, and closes the incident.

The interesting part is that it was filed as an incident at all — as an anomaly, a thing that went wrong, a deviation from a steady state the system was assumed to have. It was nothing of the kind. It was the system behaving exactly the way systems of that kind behave when they are wired into half a dozen others that are all changing on their own schedules. The build had a start date and an end date and a budget line. What the build produced was not a project but a standing obligation with no end date and no budget line at all, and the gap between those two things is where the money in do-it-yourself enterprise AI actually goes.

The build has an end date; the system does not

Organizations are very good at pricing events and very bad at pricing obligations, and every artifact in the approval process pushes in the same direction. A build gets a scope, a team, a timeline, and a number that is defended, sometimes aggressively, and then met or missed before the project closes and someone gets credit. Nothing in that machinery is designed to represent the far larger figure that follows, which is the sum of every hour anyone will spend for the rest of the system's life keeping it aligned with a world that did not agree to stop moving.

It should not be surprising that this cost dominates, because it already dominates everywhere else in software. A SonarSource developer survey found that developers spend under a third of their time — roughly 32 percent — writing or improving code, with the remainder going to maintenance, testing, security response, and operational work, and an IDC analysis put actual coding as low as about 16 percent of the working day. Whichever figure you find more credible, the shape is the same and it has been stable for years: construction is the small part. There is no particular reason to expect a bespoke AI system to be the exception, and several good reasons to expect it to be worse, because the entire value of such a system comes from the breadth of what it touches.

That breadth is the thing being underpriced. Every connection into a CRM, a ticketing system, a data warehouse, a document store, an identity provider, and a model endpoint is a standing promise that someone else's schema, authentication model, rate limits, and — most importantly — semantics will continue to mean what they meant on the day the integration was written. You control none of that, you are typically not on the announcement list for any of it, and much of it changes without an announcement, because from the upstream team's point of view nothing broke. The surface area that made the system valuable is the same surface area that makes it permanently unfinished, and those are not two properties in tension. They are one property described twice.

Drift is quieter than breakage, and that is what makes it costly

There is a useful distinction between a system that breaks and a system that drifts, and almost all the expensive failures are the second kind. Breakage is loud: an endpoint returns a 500, an authentication token expires, a schema change throws a type error, and something pages someone. Drift produces no errors at all. A status value gets repurposed by an operations team that needed somewhere to record a new case type. A policy is revised and the instructions encoded in a prompt still describe the old one, faithfully and confidently. A document library is reorganized and retrieval starts surfacing the superseded version of a procedure rather than the current one, with no signal anywhere that anything is different. The system keeps answering, and it is simply, increasingly, wrong.

Catching that requires its own apparatus — evaluation sets that encode what correct looks like, canaries that check known answers on a schedule, provenance checks that make it possible to ask why a particular answer was given, and someone whose job includes reading the results. That apparatus is not free and, more to the point, it is itself software with the same properties as the software it watches: the golden question set goes stale as the business changes, and the harness depends on the same APIs that drift. Custody turns out to be recursive, since the machinery you build to detect decay is a thing that decays, and it is invariably the first component quietly abandoned when the team that cared about it disperses into a reorg.

This is the unglamorous mechanism behind a lot of failed programs. When Gartner predicts that over 40 percent of agentic AI projects will be canceled by the end of 2027, citing escalating costs and unclear business value, it is tempting to read that as a verdict on whether the technology works. Often it is something more mundane and more structural: the thing worked at launch, the ongoing cost of keeping it working became visible somewhere in year two, and nobody had ever assigned that cost an owner or a number. Cancellation is what happens when a standing obligation meets a budget process that only knows how to fund projects.

The people who decide are rarely the people who will be holding it

Here is the part that explains why the calculation comes out wrong so consistently, rather than merely sometimes. The decision to build is typically made by a director or a vice president with a planning horizon of about eighteen months and a personal horizon that is often shorter — a promotion, a reorganization, a lateral move, a new company. The expensive phase of custody begins in roughly year two and compounds from there. The person doing the estimate is, structurally, not the person who will pay it. This is not a character flaw and it is not dishonesty; the numbers get produced in good faith by someone whose exposure genuinely does end before the costly part starts, which is exactly why an honest process reliably produces an optimistic answer.

Layered on top of that is a concentration problem that no amount of process discipline fully solves. In almost every internally built AI system there is one person who holds the whole shape of it — not the code, which is readable, but the reasons: why the fallback exists, which upstream field lies under certain conditions, why the retrieval step excludes a particular folder, what the weird retry logic is protecting against. That knowledge is situational and mostly unwritten, not because engineers are lazy but because it accumulates as a series of small accommodations, none of which felt at the time like it warranted a document. When that person moves to another team, the system usually does not break. Something subtler happens: it becomes unmodifiable. People stop changing it because nobody is confident about what a change will disturb, and then they start routing around it, and eventually it is a thing the organization owns, depends on, and will not touch.

None of which means building is the wrong answer, and it is worth being plain about when it is clearly the right one. If a capability sits on a data model or a process that your organization understands better than any outside party ever will, if it encodes a regulatory or contractual posture nobody else would underwrite, or if you intend to staff it permanently with a named team because being the world expert in that particular thing is part of the strategy — then the custody is one you actually want, and the cost of it is a cost of doing business rather than a hidden tax. Plenty of organizations build for exactly these reasons and are entirely right to. It is also true that buying does not delete custody so much as relocate it: a vendor's deprecation schedule, upgrade cadence, and roadmap divergence become your problem in a different form, and you still own your half of every connection. When a platform carries the connective machinery — Model Context Protocol connections into enterprise systems, an LLM Gateway that absorbs model deprecations, human-in-the-loop gates that are somebody's product rather than somebody's side project — what has changed is that a full-time team is holding the drift-prone parts. That is a real difference, and it is a transfer, not an elimination. The body of work published on how autonomous operations get sustained after launch tends to arrive at a similar place: the interesting question was never who writes the first version.

So the reframe worth carrying is to stop estimating a build and start drafting a tenancy agreement. Name the person who will be holding this system in year three and confirm they know it. State the term, the standing hours it will consume, and what happens to the arrangement when that person moves on, because they will. If nobody in the room is willing to sign that document, the organization has already produced the honest answer and simply hasn't read it yet. The question was never whether you can build it, since the answer is now almost always yes. The question is whether you are prepared to still be responsible for it on the day when nobody left in the building remembers why it works.