5 Signs Your AI Initiative Is Going Nowhere

Brian Carpio·

Most enterprise AI initiatives don’t fail loudly. There’s no outage, no postmortem, no line item that gets cancelled in a board meeting. They fail quietly — budget keeps flowing, slides keep getting prettier, everyone stays busy — and then eighteen months in, someone finally asks the question nobody wanted to ask out loud: what do we actually have?

I’ve spent twenty years inside enterprise transformations, on both sides — as the consultant selling the vision and as the practitioner who had to make it real after the consultants left. I’ve watched this pattern enough times to recognize it early. So here are the five signs, and if two or three of them describe your program, you’re not building an AI capability. You’re funding someone’s roadmap and calling it a strategy.

1. You’ve been shown a vision, not a running system

Ask yourself a simple question: can someone on your team open the thing and use it today, without the vendor in the room?

If the answer is no — if every demo requires their people driving, if what you’ve seen is a superspec, a reference architecture, a compelling story about what the platform will do once it’s mature — then you haven’t bought a product. You’ve bought a vision, and you’re paying to build it.

There’s nothing wrong with buying a vision, as long as you know that’s what you’re doing. The problem is that most organizations think they’ve bought a system when they’ve actually bought a concept with a delivery team attached. The tell is simple: a product works when your people use it. A concept works when their people are present. If the capability walks out of the building when the engagement ends, it was never yours.

2. It gets smarter the more you pay, not the more you use it

Watch where the value actually comes from.

In a real product, value scales with adoption — the more your teams use it, the more useful it gets, and your cost curve flattens while your value curve climbs. That’s the whole economic promise of software: you build it once, everyone benefits, marginal cost approaches zero.

In a consulting engagement wearing a product costume, value scales with hours. The system gets better because more of their consultants are working on it, tuning it, extending it, sitting in your sprints. Your cost curve and your value curve move together, forever, because the thing generating the value is the engagement, not the software. You will never reach the flat part of the curve, because there isn’t one.

If your “platform” gets more capable every time you increase the engagement — and quietly stalls whenever you try to reduce it — you’re paying a services meter. You just can’t see the meter because it’s labeled “platform.”

3. Your context is leaving your building

This is the one that should stop a regulated CIO cold.

The entire value of an organizational AI capability is that it understands your world — your code, your standards, your architecture decisions, your institutional knowledge. Which means, by definition, that capability has to be fed everything that makes you you. The question is: fed to what, and where?

If the answer is “our context gets sent to their platform to be understood,” you’ve made a decision most people never consciously made. Your source code, your proprietary logic, the accumulated tribal knowledge that is arguably your most valuable and least-protected asset — it’s now transiting to, and being processed in, an environment you don’t control. In a regulated shop — pharma, financial services, aerospace, anything with GxP, SOX, PCI, or ITAR in the air — that’s not a convenience tradeoff. That’s a finding.

The right architecture is the opposite: the capability comes to your data, runs inside your boundary, and nothing that makes you you ever leaves. If you can’t answer “where does our code actually go” with “nowhere,” you have a problem that a governance slide won’t fix.

4. When a requirement changes, you file a ticket with them — not a change in your system

Here’s a live test you can run today. A real requirement changed last quarter. What happened?

If your own team updated the system and moved on, good. If instead the change became a request to the vendor — a ticket, a scoping conversation, a line in next sprint’s engagement — then you don’t operate the thing. They do. You’re a passenger in your own AI initiative.

This is dependency dressed up as partnership, and it’s the most expensive kind because it compounds. Every change deepens the reliance. Every new requirement is another reason you can’t leave. The relationship isn’t a partnership; it’s a subscription to their continued involvement, priced as though it were software but structured so you can never actually take the wheel. The measure of whether you own a capability is whether you can change it without permission. If you can’t, you don’t.

5. You’ve seen this exact movie before, under a different category name

This is the one that takes a little scar tissue to recognize, so let me save you the scars.

There is a playbook, and it’s a good one — I’ve watched it run from the inside. It goes: coin a compelling category with a memorable name. Publish the thought leadership — the manifesto, the conference talks, the blog series, the big-name imprimatur. Establish the category as the obvious future. Then sell multi-year engagements to implement the category, with the client funding the maturation of the concept as you go.

I’m not going to name the categories, because the point is that there have been several, a new one every few years, and they rhyme. If you’ve been through one of these before — if the last big transformation concept you bought turned out to be a brilliant idea wrapped around a very long consulting engagement — then run the pattern-match on your current AI initiative. Does it feel structurally identical? Compelling category, heavy thought leadership, a vision that’s always a little ahead of what actually runs, and a delivery team that’s somehow always necessary?

If the AI initiative feels exactly like the last concept you bought, that’s because it is the same play. New category, same economics. The tell is that you can’t find the product underneath the idea — because there isn’t one yet, and you’re the one paying to build it.

What the opposite looks like

Invert all five and you get a clear picture of what a real AI capability actually is: a system your own team can open and use today. Value that scales with your adoption, not the vendor’s hours. Your context staying inside your boundary, never leaving. Changes you make yourself, without filing a ticket. And a product that exists before you pay for it — not a concept you’re funding into existence.

None of this means consulting is bad, or that vision is bad, or that the big categories were wrong. Data-era categories were often right. The failure isn’t the idea. The failure is confusing the idea for the thing, and paying product prices for concept work while telling your board you have a platform.

So run the five signs against your own program. If one is true, watch it. If three are true, you already know what I’m going to say: you don’t have an AI initiative. You have someone else’s roadmap, and your name is on the invoice.

The good news is that the fix isn’t more budget. It’s asking, out loud, the question this whole piece is built around — can my team run this without them in the room? — and refusing to accept a slide as the answer.

OutcomeOps: The Future of AI Engineering

Opens Substack in a new tab to confirm. No spam — unsubscribe anytime.

A Product, Not a Roadmap.

OutcomeOps deploys into your own AWS account, ingests your code, ADRs, Confluence, and Jira, and your team runs it — no vendor in the room, nothing leaving your boundary.

You can open it today. You can change it without asking. Your context never leaves.

Related reading