An AI project has not succeeded when the agent answers. It has succeeded when it produces a measurable result, safely, adopted and sustainable over time.
The gap between those two is where projects stall, and it is not a matter of opinion. Salesforce reports that the main obstacle for organisations trying to get value from data and AI remains data quality - incomplete, out of date or unreliable - and that only 43% of data & analytics leaders have formal data governance frameworks and policies (State of Data and Analytics). Gartner, for its part, links project abandonment to four recurring causes: data quality, inadequate risk controls, escalating costs and unclear business value.
The problem is not only technical
An AI project brings together technology, data, processes, people and accountability. The platform you choose - Salesforce, Agentforce, Data 360, ChatGPT, Claude, Slack or a headless architecture - is one part of the solution, not the solution. It has to fit into a real process, use reliable data, respect existing permissions and produce a result the company can measure.
When one of those is missing, the project can reach go-live without becoming an operating system. Below are the six causes that recur most often, and what to do about each.
1. Nobody owns the outcome
IT runs the platform, the business runs the process, a data team runs the sources. None of those functions, on its own, answers for the overall result.
After release somebody has to decide which use cases take priority, which data is reliable enough for the agent, which users reach which information, when to correct a behaviour, and when to extend, change or stop the initiative.
Without an owner who has authority over the process and the priorities, the solution stops evolving: users hit exceptions, data changes, new needs emerge and nobody has the mandate to act.
What to do: name a business owner before kickoff. Not the person who collects feedback and attends the meetings, but somebody with authority over priorities, process, metrics and stakeholder engagement.
2. The data is not ready for AI
An agent can draw on CRM data, documents, knowledge bases, ERP, ticketing and external sources. If those sources are incomplete, duplicated, stale or in conflict, the risk is not just an imprecise answer: it is that users stop trusting the solution, and at that point the project is over even though the system works.
Across a sample of 1,203 data management leaders, Gartner found that 63% of organisations either do not have, or are unsure whether they have, data management practices suitable for AI, and predicted that through 2026, 60% of AI projects unsupported by AI-ready data would be abandoned (Gartner, February 2025).
What to do: before designing the agent, test the use case against a sample of real data.
- Which are the systems of record?
- Which fields are indispensable?
- How complete and current are they?
- Are there duplicates or inconsistent values?
- Who is accountable for the quality?
- Which data must the agent not use?
Remediation does not have to cover the whole CRM. It has to cover the data the first use case cannot do without.
3. Access and security arrive too late
A person reads the CRM inside roles, profiles and sharing rules that are already defined. An agent retrieves and combines information across several objects, documents and systems to answer one request: that is a way of reading the existing visibility model was never designed to anticipate.
The questions to ask during analysis, not afterwards:
- Which data can the agent read, and in what context?
- Does the answer change depending on who is asking?
- Which confidential data has to be excluded?
- Which actions can it take autonomously, and which need approval?
- How are requests, sources and actions logged?
This is not a theoretical concern: in organisations with high AI maturity, 48% of leaders name security threats among the top three barriers to implementation (Gartner, June 2025). Those are the companies furthest ahead - the ones who have already been through it.
What to do: build an access matrix during analysis, together with the business owner, IT, security, privacy and legal, that for every use case and user type states what they can see, what they can ask, what they can change, what the agent does on its own, when approval is required and which data has to be masked or excluded.
4. The use case is not concrete enough
Many projects start from "how do we use AI?" rather than from a specific operational problem. In that case the partner may propose a reasonable, well-constructed use case that is simply not a priority for you. The risk is not that the solution is wrong: it is that it automates a marginal activity, with few users, whose value does not justify the cost and the maintenance.
On top of the use case choice sits a market problem. Gartner calls it "agent washing": existing products - assistants, RPA, chatbots - rebranded as agentic without substantial agentic capability. The estimate is that only around 130 of the thousands of vendors presenting themselves as agentic AI genuinely are (Gartner, June 2025). Many of the use cases presented as agentic today do not require an agentic implementation at all.
Organisations with the highest AI maturity choose projects by combining business value and technical feasibility, and that discipline shows in the numbers: 45% keep initiatives in production for three years or more, against 20% of low-maturity organisations.
What to do: assess every use case on four dimensions and pick the first one that scores on all four, not the one with the best demo.
| Criterion | Question |
|---|---|
| Volume | How many times a month does this activity happen? |
| Repetitiveness | Does the process follow reasonably stable rules? |
| Data | Is the necessary information available and reliable? |
| Value | How much time, cost or risk can it remove? |
5. Value was never defined upfront
A project can be used and still not produce enough value. Without a baseline taken before it starts, it is difficult after go-live to demonstrate whether time, tickets, cost, quality or productivity genuinely improved. What is left are individual testimonials: useful, but not enough to defend a recurring investment in front of whoever holds the budget.
Here too the difference between those who succeed and those who do not is measured: 63% of high AI maturity organisations adopt formal metrics, and 57% say business functions trust new AI solutions and are ready to use them - against 14% of low-maturity organisations.
What to do: before starting, define a primary metric, its initial value, the expected result, the measurement date, the data source to calculate it from and who will verify it. For example:
Cut internal HR request tickets by 20% within six months of go-live, measured on tickets closed in the service desk.
"Improve the user experience" is an objective. It is not yet a success criterion.
6. There is no criterion for stopping
A pilot does not have to prove that AI works in general. It has to establish whether one specific use case is sustainable in your context.
Without criteria set beforehand, a pilot extends without an explicit decision: it is not convincing enough to scale, but nobody closes it. It consumes resources and occupies the slot a better use case could have had. In July 2024 Gartner predicted that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025 (Gartner, July 2024); for agentic projects the more recent forecast is over 40% cancelled by the end of 2027. The number changes, the cause does not: escalating costs, unclear value, inadequate risk controls.
What to do: define before you start how long the pilot runs, which users and data it involves, which metrics you will watch, which minimum threshold it has to reach, which risks force a suspension and who takes the final decision. For example:
After eight weeks we extend the pilot only if the agent resolves at least 60% of in-scope requests without escalation, with positive user feedback and no significant security incidents.
A stop criterion is not a prediction of failure. It is how you run a controlled experiment.
The common denominator
Data, governance, access, use case selection, value measurement and stop criteria are not activities ancillary to the implementation. They are the project.
The partner can supply method, platform, technical skills and support. The company has to keep accountability for the decisions on process, data, priorities, risk and value. That distribution has to be settled before the start, and it is the subject of what to ask a partner before signing.
Early warning signs
You are accumulating risk if, once the project is under way:
- nobody can name the business owner of the use case;
- there is no list of data sources with their owners;
- the team cannot say what the agent can see or do for each type of user;
- testing uses only demo data or an unrepresentative environment;
- the success metric has no baseline;
- consumption, recurring costs and the support model have not been discussed;
- many critical decisions are being deferred to go-live.
One sign on its own does not mean the project will fail. Several signs together mean it is worth stopping, clarifying the scope and updating the plan, the accountability or the architecture.
Frequently asked
Is the vendor accountable if the project creates no value?
The partner answers for the scope, the quality of delivery and the contractual commitments agreed. The client remains accountable for priorities, the process owner, data availability, access decisions, adoption and value measurement. That is why those elements have to appear in the project plan and in the governance, not only in the opening conversations.
Can a project that started badly be recovered?
Often yes. The first step is working out whether the problem is technical or whether a decision is missing on process, data, access, accountability or metric. Then you narrow the scope to a manageable use case, name an owner, establish a baseline and decide which data and integrations are genuinely needed. A new platform is not always required: sometimes what is required is defining the problem precisely.
Can an AI project be small?
Yes, and it often should start that way. A bounded use case, with real users, representative data, verified permissions and a clear metric produces more learning than a broad programme with no priorities. The initial objective is to find out whether the solution creates value in your context; only then does extending it make sense.
Related reading
- Is Agentforce worth it? - the four conditions to check before starting.
- What to ask a partner before signing
- Readiness assessment - process, data, governance and expected value checked against your situation, in two days.