What AI implementation actually looks like: a 90-day plan

Most fail for organizational reasons. Researchers at the Rand Corporation note that by some estimates more than 80 percent of AI projects fail, twice the rate of information technology projects without AI, and the 65 experienced data scientists and engineers they interviewed named a misunderstood problem as the most common root cause, followed by a lack of the data needed to train a useful model.

Gartner predicted in July 2024 that at least 30 percent of generative AI projects would be abandoned after proof of concept by the end of 2025, citing poor data quality, inadequate risk controls, escalating costs or unclear business value. In February 2025 it added that organizations will abandon 60 percent of AI projects unsupported by AI-ready data through 2026.

Survey data from adopters points the same way. McKinsey's 2025 State of AI survey found 88 percent of respondents' organizations use AI regularly in at least one business function, yet only 39 percent attribute any impact on earnings before interest and taxes to it, and the roughly 6 percent it classifies as high performers are nearly three times as likely as others to have fundamentally redesigned their workflows.

A Massachusetts Institute of Technology report, as covered by Fortune, found generative AI implementation falling short for 95 percent of companies in its dataset, with the biggest returns in back-office automation. Read together, the lesson is not that AI does not work; it is that projects without a clear problem, ready data and a changed workflow rarely do.

Choose the use case with the shortest, most measurable payback, not the most impressive demonstration. We score every candidate on five questions:

• Volume: does the task happen hundreds or thousands of times a month?
• Cost per occurrence: how many minutes of skilled time, or how much revenue, rides on each one?
• Data: do the inputs already exist in a system or a document set we can read?
• Owner: is there one manager who feels the pain and has the authority to change the process?
• Measurement: can today's baseline be recorded within a week, so day 90 has something to compare against?

Thirteen weeks, six phases, each ending in an output you can inspect. Dates shift with access and approvals; the sequence does not.

A first phase needs a small, named group with time set aside, not a steering committee.

• Executive sponsor: the chief operating officer (COO) or equivalent, who approves scope and clears blockers within days.
• Process owner: the manager whose team does the work today and will own the result.
• Two or three frontline users: the people who will use the system in the pilot and say plainly what is wrong with it.
• Systems and data owner: someone who can grant access, answer questions about the data and approve where it lives.
• Compliance or legal reviewer, where the workflow touches regulated data, brought in during discovery rather than the week before launch.
• The engineering team that designs, builds and later runs the system. At Vantage Systems, those are the same people who join the first call.

Most risks are known in advance and can be contained by a decision made early.

• The data is worse than expected: the week-four audit forces an explicit go, adjust or stop decision before build money is spent.
• Scope grows mid-build: new ideas go on a phase-two list, and the first phase ships what was agreed.
• The model makes mistakes: the pilot logs every error, high-risk outputs get human review, and the system shows its sources so users can check them.
• Users route around it: frontline users are involved from week one, and the launch replaces a step rather than adding one.
• Access and security reviews stall: credentials, environments and data residency are requested in week one, because they often take longest to arrange.
• Nobody owns it after launch: an owner and a support path are named before rollout, and the build team stays on to run and maintain the system.

At day 90 you should have one system in daily use, a measured comparison against the baseline and a costed decision about what to do next. If the pilot showed the use case does not pay, you should know that too, at the cost of one phase rather than a year.

• Adoption: how many of the intended users work in the system each day.
• Result against baseline: time per task, response time, error rate or throughput, whichever measure was agreed in week one.
• Quality: the error rate from the pilot log and how each error was caught.
• Running cost: hosting and model usage per month at real volume.
• Phase-two proposal: the next use case, scored the same way as the first.