If you have looked into why AI projects fail, you have seen scary numbers. A RAND Corporation report says that by some estimates more than 80 percent of AI projects fail. A preliminary 2025 report from MIT's Project NANDA estimated that only about 5 percent of integrated generative AI pilots showed marked, sustained productivity or P&L impact, and its own authors described the figures as directional. Other surveys report much lower failure rates for narrower populations.
I am a practicing CPA, so let me start with the caveat you will not get from most articles quoting those figures: the numbers are not comparable. One study counts projects abandoned outright, another counts pilots that never reached production, another counts deployments that missed an ROI expectation someone set in a planning meeting. Several of the most-quoted statistics trace back to firms that sell AI consulting, and at least one widely repeated "average cost of failure" figure circulates with no traceable primary source at all. Treat every precise-sounding failure percentage with suspicion. I do.
Here is what I think survives the skepticism. Adoption is real: in an optional module of the 2025 Small Business Credit Survey, published by the Federal Reserve Banks in 2026, 46 percent of employer firms reported using AI in some form and another 15 percent planned to start within twelve months. And while the studies disagree on the failure rate, they agree that failure is routine, so the interesting question is not the exact percentage. It is why projects go wrong, because the published post-mortems point to a recognizable mix of causes: unclear objectives, inadequate data, weak fit with the actual workflow, insufficient infrastructure, and tasks current AI simply cannot perform reliably. Some of those causes are technical. Many are not. And a good number of them, though not all, are visible before anyone spends money, which means they can be checked in advance.
This article walks through the five checks I run before recommending any business spend a dollar on AI. None of them require technical knowledge, and all of them can surface reasons to pause or narrow a project before major spending begins.
The pattern behind failed projects
Strip away the technology and many failed AI projects share one biography. Someone saw a demo. The demo was genuinely impressive, because a demo typically shows clean inputs and a well-understood task. The business bought the tool, pointed it at their real operation, and discovered that their real operation is nothing like the demo: the data lives in four systems, the process being automated was never written down, nobody was assigned to check the outputs, and nobody agreed in advance what success would look like.
Then a slower, quieter problem shows up. When the Small Business Credit Survey asked AI-using small businesses about their biggest challenges, the answers at the top were accuracy of the results, at 46 percent, and finding and adapting tools to how their business actually works, at 43 percent. AI produces confident-looking output, and confident-looking errors are easy to miss if nobody owns the checking.
Readiness for all of that can be assessed. Here are the five checks.
Check 1: If the use case needs your data, can you get to it?
Not every AI use case depends on your business data. Drafting, brainstorming, transcription, and research on public information mostly do not. But the automation projects with real payback, the ones that touch invoices, customers, scheduling, and reporting, run on your records, and the first question is not whether the AI is smart enough. It is whether those records are reachable, lawful to use, and clean enough to trust.
My screening question is practical: can you assemble the records this use case needs, reconcile them, and explain the known gaps, without that becoming a major cleanup project of its own? In my experience, small businesses commonly keep operational data split across separate systems, spreadsheets, and inboxes; test your own process rather than assume you are the exception.
The good news is that this check often reveals the real project. Sometimes the highest-return move is not AI at all. It is finally consolidating the customer list, or getting receipts out of the shoebox and into a consistent system. That work pays off whether or not you ever automate anything on top of it.
Check 2: Is the process written down?
AI struggles hardest when a business tries to automate a process nobody has ever documented. If the process lives entirely in one employee's head, the AI is not automating a process. It is guessing at one.
The test I use: could a new employee follow this process from your written instructions with minimal hand-holding? If the answer is no, document first. This is unglamorous, and it is frequently the highest-value step in the whole project, because writing the process down surfaces every exception, judgment call, and undocumented workaround. Those exceptions are exactly where automation breaks.
The best candidate processes share a shape: repetitive, driven by data rather than relationships, with clear inputs and clear outputs. Invoice intake. Report assembly. Data entry between systems. The worst candidates are the ones where human judgment or a human relationship is the actual product.
Check 3: What controls catch the errors?
This is the check that separates automation that helps from automation that quietly hurts. For any workflow that can materially affect money, customer commitments, or compliance, the design question is: when the AI is wrong, what catches it, and who is accountable?
The answer does not have to be a human reading every output; that fails in its own way at volume. Real control design is risk-based, the same discipline accountants apply everywhere else: a named owner for the workflow, review of high-dollar or unusual items, reconciliation against an independent source like the bank statement, automated validation checks, and a defined path for the system to route items it cannot confidently handle to a person. The failure mode to avoid is the workflow designed to remove people entirely, because in a poorly monitored process, errors can go unnoticed precisely when nobody sees the individual cases anymore.
If you cannot name the workflow's owner and describe the check that would catch a wrong output, this check has found the prerequisite to fix before spending.
Check 4: Does leadership agree on what success means?
Before spending anything, everyone who controls budget needs to agree, in writing, on three things: the first use case, the metric that defines success, and how much error is acceptable while the system is being tuned.
This sounds bureaucratic for a five-person company. It is not. Even in a small business, the classic project killer is misaligned expectations: the owner expects visible savings in a quarter, the person running the project knows the first quarter is setup and cleanup, and six months later the project is "a failure" against a bar nobody ever agreed to. A baseline matters just as much. If you do not measure what the process costs today, in hours and error rates, you will never be able to say whether the automation paid for itself.
On where the effort goes: BCG publishes a 10-20-70 rule of thumb for AI transformations, 10 percent of the effort on algorithms, 20 percent on technology and data, 70 percent on people and processes. That is consulting guidance, not a measured law, but the direction matches what I see. The technology is rarely the hard part.
Check 5: Does your current software play well with others?
The last check is your existing stack. If your business runs on mainstream, well-connected tools, things like QuickBooks, Google Workspace, Microsoft 365, HubSpot, or established industry software with proper integrations, you are in better shape than you probably think. Modern automation mostly works by connecting systems you already have.
If your critical process depends on software that only exports by PDF, or on copy-paste between two systems that do not talk to each other, readiness drops, and the honest recommendation may be a smaller plumbing project before any AI project.
Note what this check does not say. It does not say you need to rebuild your systems or buy an "AI platform." In my practice, what a small business usually needs is strategic additions to what it already runs, not replacement.
What the five checks are, and what they are not
Run honestly, these checks produce something valuable before any tool is purchased: a short list of processes that look like strong automation candidates, a list of prerequisites for the ones that are not there yet, and, just as important, a list of things that should probably be left alone because the numbers do not justify touching them.
That last category is real. Freeing up hours only becomes money when the freed capacity reduces a real expense or gets used on work that earns revenue. Some processes cost too little, or carry too much judgment, for automation to ever pay for itself. A readiness review that never says "leave it alone" is a sales document, not an assessment.
And to keep my own claims inside the lines: these five checks are an initial screen, not a readiness conclusion. Actually deploying something also requires use-case-specific review of the economics, security, privacy, legal obligations, vendor terms, testing, and fallback plans. The screen tells you where that deeper work is worth doing.
Where I fit in, stated plainly
This kind of pre-spend review is the product I sell, so weigh my incentives accordingly. The assessment costs $999 and produces a written report built around these checks, with the material assumptions behind its estimates stated so you and your own accountant can challenge them. If you later hire me for a build, the $999 is credited toward that work. The report is yours either way; you can hand it to your own team or any other builder. Nothing starts until the intake form is complete.
But you do not need me to capture most of this value. Take the five checks above, spend one honest afternoon on them with the person who actually runs each process, and you will have answered questions that many failed projects never asked. An afternoon of checking cannot guarantee a place among the successes; the failure studies describe causes it cannot reach, including technical ones. What it can do is surface the problems that were visible before the spending started, and those, the record suggests, are a large share of the story.
Jared Duncan, CPA. This article is general information, not accounting, tax, or investment advice for your specific situation.