Most AI projects that fail did not fail during the build. They failed at the start, when a model was chosen before anyone had agreed what the system was for, and the gap only became visible months later when the result had nowhere to go.
The seven questions below are the ones worth answering before any budget is committed. None of them are about models, frameworks, or vendors. They take a few days to answer honestly and they change the shape of the project more than any technical decision that follows.
If several cannot be answered, that is the finding. A project that starts without them does not avoid the questions - it discovers them one at a time, at the point where each one blocks progress and each one is most expensive to resolve.
1. Which Decision Should This Improve?
Not which process, and not which department. Which decision, made by which person, how often.
"Use AI in customer support" cannot be evaluated. "Reduce the time an agent spends locating the applicable warranty clause before replying" can: it names who acts, what they do now, and what changes.
The test is whether you can describe the current path in one sentence and the intended path in one sentence. If the current path cannot be described, the process is not understood well enough to automate part of it, and mapping it is the first task.
This question also filters out projects that are really reporting requests. If the output is a dashboard nobody acts on, the system will be built, admired briefly, and abandoned.
2. Who Uses the Output, and Inside Which Tool?
Adoption is decided by where the output appears.
Users do not open a second application to check what the AI thinks. Output that lives in a separate portal gets used during the pilot, when people are being observed, and then quietly stops being opened. The capability has to reach the tool where the work already happens - the CRM, the ticketing system, the ERP screen, the email client.
Ask which system that is, whether it can display the output, and who controls that surface. If the answer is a vendor product that cannot be extended, the integration constraint is real and it should shape the design rather than surprise it at the end.
Ask also what the user is supposed to do differently. If the honest answer is "the same thing, but with extra information," the value is smaller than it appears and the metric in question one will be hard to move.
3. Is the Data Reachable?
Existing and reachable are different states, and confusing them is the most common source of timeline overruns.
Data is reachable when it can be retrieved programmatically, at the frequency the system needs, containing the fields the task requires, with permission to use it for this purpose.
The only honest test is to pull a real sample through the actual production access path - not an export prepared by a colleague, which conceals every problem you are looking for. One week of doing this reveals more than a month of data-strategy meetings.
What typically appears: the source system has no API; the fields exist but are free text where a category was assumed; records are consistent only after a certain year; access requires approval from a team with no incentive to move quickly; or legal has never established whether this data can be used this way.
None of these end a project. All of them lengthen it, and all are far cheaper to find now.
4. What Does Success Mean, in Numbers That Already Exist?
Define success against a metric the organization already tracks, and record its current value before anything is built.
Two things go wrong here. The first is a success criterion nobody measures - "better customer experience" - which cannot be evaluated and so the project gets judged on impressions. The second is a model metric standing in for a business metric. Accuracy of 94% is not a result; the result is fewer escalations, faster handling, less rework, or lower scrap.
Also decide what would count as failure. A project with no failure condition cannot be evaluated honestly and tends to survive well past the point where it earns its cost. Agreeing in advance what result would mean "stop" is uncomfortable and it is the single cheapest piece of governance available.
5. Where Must It Connect?
List the systems this must read from and write to, and check each for three things: does an interface exist, who owns it, and what does a change to it require.
The write side deserves particular attention. Reading is usually possible; writing into a system of record often involves validation rules, approval workflow, audit obligations, and a team that will reasonably want to know what is being written and by what authority.
If a required system has no write interface, building one is part of this project and belongs in the estimate. It is frequently larger than the AI work itself, and discovering it late is what turns a three-month project into a nine-month one.
6. Where Does a Human Decide?
Every AI system is wrong sometimes. This question asks what happens then, and it has to be answered before the design rather than after the first incident.
Decide which outputs act automatically and which require a person. The useful signals are reversibility, magnitude, and breadth: an irreversible action, a large one, or one affecting many records at once belongs behind a human decision regardless of model quality.
Then decide what catches the errors that pass through - review before the action, an audit sample afterwards, a downstream check, or nothing. "Nothing" is a legitimate answer for genuinely low-stakes output, but it should be a decision rather than an omission.
The related question is asymmetry. A false positive and a false negative rarely cost the same, and that ratio - not a default threshold of 0.5 - should set the operating point. Someone with authority has to state it.
7. Who Owns It After Launch?
The most common cause of quiet failure is organizational, not technical. A system is built by a project team, the project ends, and the system keeps running with nobody responsible for it.
Name the owner before the build starts, with a defined scope: who watches quality, who is contacted when it degrades, who approves a change, who can roll it back, and how quickly. Include what happens when that person leaves.
The test is simple. When this system produces a wrong result in six months, who finds out, and what are they empowered to do? If the answer is "the project team, but that project will have ended," the system is unowned - and unowned systems degrade until someone external notices, usually a customer.
This is the question most often skipped because it sounds administrative. It determines whether the system is still working a year later more reliably than any architectural choice.
Reading the Answers
Clear answers to all seven mean the project has a real path, and the remaining risk is execution.
One unclear answer identifies the first piece of work. Sequence it before the build rather than alongside it - particularly for questions three and five, where an unresolved answer produces a system that demos on a sample and cannot run on production data.
Three or more unclear answers mean this is not yet an AI project. It is a process and data project that will enable one later. Teams that accept this and spend a quarter on the foundation reach production sooner than teams that start building and meet the same gaps one at a time.
The questions are not a gate to pass. They are the design. A project that can answer them has largely been specified; a project that cannot has only been imagined.