AI projects often fail for a reason that has little to do with ambition. Organizations want more than 90% of employees to use AI for more than 50% of their working day, yet fewer than 10% of chief AI officers’ employees use AI as much as those leaders do. That gap shows how far many companies remain from turning AI plans into everyday work.
The problem is not only adoption. AI performance on business data is often poor, and one wrong answer can change how people use the system from that point forward. As Rajoshi Ghosh puts it: “When AI gives you a wrong answer, you notice. You correct it. Maybe you try again, and then you quietly stop trusting it for anything important.”
That loss of trust creates a difficult cycle. AI adoption stays concentrated in a small pocket of enthusiastic early adopters, while other employees hold back from using it for important tasks. At the same time, leaders face pressure from the board level and the C-suite to automate and innovate, even when the systems are not ready for the data environments that employees rely on.
Trust breaks when data leaves the lab
AI benchmarks can make a system look ready before it faces real enterprise data. Existing industry benchmarks for AI accuracy are disappointing, and they often fail to reflect the conditions found inside organizations. Most use datasets with simple schemas, clean data, and a single database, which creates a much easier test than the one many businesses must pass.
Real work can involve data across MongoDB, SQL Server, and Postgres at the same time, with queries that cross database boundaries. That setup is more complex than a clean dataset in one database, and it gives AI more chances to misunderstand the information or return a wrong answer. A system that performs well in a simple test may struggle when the same task involves multiple sources and different data structures.
Ghosh describes the gap directly: “Most of them were text-to-SQL benchmarks built on datasets that bore almost no resemblance to what real enterprise data environments look like.” The issue is not just whether AI can generate an answer. The answer also has to match the company’s actual data, which may be spread across several databases and connected through cross-database queries.
That distinction matters because users judge AI through the results they receive, not through its benchmark score. If the answer fails on a task that matters, users notice. They may correct the result once, try again, and then stop trusting the system for important work. A low-trust tool cannot reach the level of daily use that organizations want.
The accountability gap is getting wider
Data leaders are being asked to deliver automation and innovation while facing consequences when data work fails. The accountability gap for CDOs and CDAOs is widening, with outcomes that include fraud losses, compliance failures, and increased investigation costs. These are not abstract measures of system quality; they are business consequences tied to how organizations handle data and decisions.
This pressure makes weak AI performance harder to ignore. A system that struggles with real enterprise data can affect the work surrounding fraud, compliance, and investigations. Yet the people responsible for data outcomes are also being pushed to make AI useful across the organization, creating a mismatch between expectations and the conditions needed for reliable results.
The adoption numbers show the scale of that mismatch. Fewer than 10% of chief AI officers’ employees use AI as much as they do, while most organizations aim for more than 90% of employees to use AI for more than 50% of their working day. Enthusiasm at the top has not turned into broad use across the workforce.
What a better fix needs to address
The first fix is to test AI against the data people actually use. Benchmarks built on simple schemas, clean data, and single databases cannot answer whether a system will work across MongoDB, SQL Server, and Postgres with cross-database queries. Real enterprise conditions need to shape the test, because those conditions shape the user’s experience.
The second fix is to treat trust as a working requirement rather than a side effect. An AI system that gives a wrong answer loses value even when it performs well in controlled tests. Users need results they can rely on for important tasks, or adoption will remain limited to a small group of early adopters.
The third fix is to connect AI goals with the accountability already carried by CDOs and CDAOs. If leaders face fraud losses, compliance failures, and increased investigation costs, AI projects must account for those outcomes instead of focusing only on adoption targets. The pressure from the board level and C-suite to automate and innovate will keep growing, but adoption depends on whether the systems work with real data.
Code security is stuck at 56%, another sign that high expectations do not guarantee dependable results. The broader lesson is simple: AI projects do not succeed because an organization wants more people to use them. They succeed when the data is realistic, the answers earn trust, and the system fits the work employees must do.
Based on
