Building AI Systems for High-Stakes Industries: What Actually Works

Most AI projects fail. But they don’t fail randomly. The research shows a clear, repeatable reason why a small number of companies succeed — and it has almost nothing to do with which AI tool they picked.

Here’s a number worth sitting with: a 2025 study by RAND Corporation looked at more than 2,400 companies and found that over 80% of their AI projects never delivered real business value. That’s about twice as often as regular tech projects fail. A separate study from MIT looked at 300+ real AI projects and found something even more striking: 95% of them didn’t make companies any more money. And research from IDC found that out of every 33 AI test projects a company starts, only about 4 ever actually get used in real day-to-day work.

Those numbers get shared a lot, usually to make the point that “AI is all hype.” We don’t think that’s the right takeaway. The same studies that found these scary numbers also found a clear pattern in what the few successful companies did differently — and that pattern matters a lot more than the scary headline.

The one number that actually matters most

Here’s a detail from that MIT study that doesn’t get talked about enough: companies that bought their AI tools from an outside specialist, or worked with an outside partner, succeeded about 67% of the time. Companies that tried to build the same kind of thing entirely on their own, in-house, succeeded only about a third as often.

In plain terms: whether an AI project works out has less to do with your budget, or even your industry, and a lot more to do with whether you had help from people who’ve actually done this before. If you’re deciding whether to build something yourself or bring in outside help, this is probably the single most useful number in this whole article.

Healthcare has the same problem, but worse

Healthcare runs on oceans of heavy documentation — policy manuals, compliance rules, operational protocols, and vendor contracts. Finding a straight answer in a 200-page PDF can take twenty minutes, but making a mistake can compromise compliance or trigger massive fines. Naturally, it’s one of the most tempting places to throw AI.

It’s also where broad AI projects fail hardest. In high-stakes industries, close enough isn’t good enough. If an AI tool gives a wrong answer even 5% of the time, staff lose trust and stop using it completely.

This is the exact trap we designed around when we built an AI document assistant for a large U.S. non-profit trauma hospital.

Instead of building a broad search engine that tried to index every piece of paperwork at once, we kept the system strictly bounded: it reads and answers questions exclusively from verified, official policy files, attaching every response directly to the exact source page. By treating healthcare documentation as a precision data problem rather than a general AI playground, we gave staff answers they could instantly verify and actually rely on.

Why bad data is usually the real problem, not the AI itself

A 2025 report from Fivetran, a data company, found that most AI project failures traced back to messy or disconnected data — not the AI tool itself. A lot of companies simply couldn’t get their AI tool the up-to-date, connected data it needed to actually be useful. Gartner, a well-known research firm, has warned the same thing: without properly organized data, a lot of company AI projects are at real risk of being abandoned.

None of this is really an “AI problem.” It’s an old-fashioned data organization problem that happens to have AI attached to it. The AI model itself is usually the easy part to swap out or upgrade. The harder, less exciting work is making sure the information behind it is clean, current, and actually connected — and that’s usually the part companies skip.

A fair pushback, and why we still think we’re right

It’s worth mentioning a fair counterpoint here: some researchers point out that big, ambitious tech projects have always failed a lot, even before AI existed. One well-known study of large tech projects found failure rates as high as 98%. So maybe AI projects aren’t uniquely bad — maybe any big, ambitious tech project is just genuinely hard to pull off.

We think that’s a fair point, and honestly, it supports our argument rather than weakening it. If AI projects fail for the same old reasons big tech projects have always failed — nobody’s clearly in charge, the requirements were vague, the underlying data was a mess, or the project tried to do too much at once — then the fix was never going to be “use a smarter AI model.” It’s the same basic discipline that’s always separated projects that work from projects that quietly die. AI didn’t invent this problem. It just makes the cost of ignoring it show up faster.

The three patterns we see over and over

Across our own projects, everything above boils down to three simple, avoidable mistakes:

1. Nobody is clearly in charge of the decision. Every AI pilot starts with excitement. Very few have one specific person responsible for deciding, by a specific date, whether to keep going or shut it down. Without that, projects don’t fail cleanly — they just quietly linger for months, costing money without anyone officially admitting it isn’t working.
2. The data behind it was never actually cleaned up and organized. This is the single most common real reason projects fail, and also the least exciting one to fix, which is exactly why it gets skipped.
3. The project tried to do too much. An AI tool that’s supposed to handle everything ends up trusted with nothing. The projects that actually work tend to do one specific job really well, built on real information, and checked against how people actually work day to day.

How we approach this at DreamLit

We work with organizations in a few different ways, depending on what they need:

• Advisory — we help you figure out the right path forward before you’ve committed to building anything
• Embedded Partnership — we work alongside your own team from planning through to launch
• Build — we handle the whole thing, start to finish

Which one makes sense depends on how much of the planning, data cleanup, and decision-making your team can already handle on its own. There’s no universally “right” amount of outside help — it depends on what you’re actually trying to solve.

Two real examples of this in action

We’ve done this kind of work before: the AI assistant we built for a non-profit trauma hospital, and a real project we built for an education company that lets AI translate a live classroom lecture into another language in close to real time. We’ll be writing these up in more detail soon so you can see exactly how “keep it narrow, keep it grounded, keep someone accountable” played out step by step — for now, reach out if you’d like to hear more about either one.

Three questions to ask before you start your next AI project

1. Who is personally responsible for deciding whether this gets scaled up or shut down, and by when?
2. Has anyone actually checked that the data behind this is accurate and up to date — or are we just assuming it is because the demo looked good?
3. Could you explain, in one plain sentence, exactly what this tool does and doesn’t do?

If you can’t answer all three confidently, that’s not a reason to give up on the idea. That’s actually the right place to start the conversation. It’s usually where we start too.

---

Sources

• RAND Corporation’s research on why AI projects fail — summary of the 2,400-company study finding an 80%+ failure rate
• MIT Project NANDA’s “GenAI Divide” findings, via Fortune — the 95% failure rate and the vendor-vs-in-house success gap
• MIT NANDA findings, via Trullion — additional context on which pilots survive
• IDC/Lenovo’s AI CIO Playbook, summarized by SoftwareSeni — the “4 out of every 33” production statistic
• Summary of Fivetran, Gartner, and RAND data on AI failure causes, Pebblous — data-readiness findings
• A critical look at whether AI project failure rates are actually unusual — the comparison to historical IT project failure rates

Note: these links go to articles and write-ups that summarize the original research (RAND, MIT, IDC, Gartner, Fivetran), since that’s what we pulled these numbers from. We’d recommend double-checking the specific figures against the original reports before quoting them elsewhere.

Written by Vijay and Nikoloz at DreamLit. Vijay leads engineering, with 20+ years building data-intensive systems for teams in finance and healthcare. Nikoloz works on product and customer experience, helping translate technical work into what it actually means for the businesses using it. If you’re working through a similar decision, we’re happy to talk it through — no pitch required.