30 mistakes I see enterprises make with AI transformation: 1. Buying AI licences and calling it a strategy. Decide which problems you want to solve, how people will use the tools and what improvement you expect to see. Access alone doesn’t answer those questions. 2. Expecting every employee to become an AI engineer. People need different levels of training and responsibility. Helping someone use AI in their work doesn’t automatically prepare them to build and maintain a system for others. 3. Asking AI for answers before agreeing on what a good answer looks like. Start with real examples and clear criteria. Keep verified corrections as test cases, and rerun those tests when you change the system. 4. Blaming the model before checking the whole setup. A failure can come from the model, instructions, missing information, tools or the surrounding software. Investigate where it went wrong before deciding what to replace. 5. Automating a process nobody can explain from start to finish. We spoke to a team whose work moved between calls, emails, spreadsheets and shared folders. Understanding how the work actually got done was a substantial job in itself. 6. Giving an agent more access than its job requires. Limit what it can read and change, and require approval for consequential actions. Enforce those permissions in the software. An instruction telling the agent to be careful is not an access control. 7. Making data protection depend on someone remembering to delete a name. Use appropriate access controls and automated checks to limit sensitive information before it reaches the model. Removing names alone won’t address every way confidential information can be exposed. 8. Letting an agent spend money without a limit. We still meet teams with no budget cap. Set spending limits, request limits and stopping conditions, then decide what the system should do when it reaches them. 9. Counting AI usage as proof of business progress. Token consumption can help you understand adoption and cost. It doesn’t tell you whether useful work got finished. Measure results, quality and the time spent reviewing or fixing the output. 10. Letting company data end up in accounts nobody has checked. Know which services employees use, what happens to the information they enter and which settings and agreements apply. Make the approved way of working clear. 11. Choosing a model without considering what switching would involve. Understand which parts of your system depend on that provider. A different model may need different instructions and fresh testing, even when the technical connection is easy to change. 12. Paying for discovery without agreeing on what it must deliver. We heard about an engagement where the estimate kept growing, then the consultant left for another commitment. Set clear deliverables and a point at which you decide whether to proceed. 13. Committing to a plan with no way to act on what you learn. A long project isn’t automatically a mistake. The problem is having no checkpoints where real results can change the priorities or the proposed solution. 14. Launching an agent nobody is responsible for. Assign responsibility for its operation, monitoring, updates and eventual retirement. The people responsible need the authority and resources to do those jobs. 15. Buying a custom system without a plan for when the supplier leaves. Agree on documentation, access, support and handover while the relationship is working. Know who could maintain it if that relationship ended. 16. Waiting for users to tell you something has broken. You should have telemetry installed so you don't find a problem weeks later than you should have. 17. Making an agent read everything to find one thing. Give it tools that search, filter and return relevant information. Large responses full of unrelated data consume context and make the task harder to handle reliably. 18. Letting the people who built it be the only people who test it. Involve the people who do the job and understand the business. They can help identify answers that look reasonable but would cause problems in practice. 19. Testing only the situations where everything goes smoothly. Include exceptions, ambiguous requests and cases where the system should stop or ask for help. Confusing five cases with five individual items is exactly the sort of mistake your tests should catch. 20. Keeping essential knowledge in the heads of people who might leave. One company was trying to capture how experienced colleagues made decisions before they retired. Record their reasoning and examples while they can still explain and check them. 21. Assuming every AI project must wait for the ERP migration. Some read-only work may be possible against existing data. Check freshness, permissions and the work needed to adapt it later. A replica can help, but it may lag behind the live system. 22. Assuming one company’s AI success will transfer to the whole portfolio. Use that success as a starting point. Each company still needs to check whether the approach fits its work, data and business needs. 23. Expecting AI to understand terms your own departments use differently. Explain business terms, calculations and database fields. If several measures could reasonably mean “sales,” specify which one applies to the question. 24. Producing code faster than anyone can review it. Research describes how faster generation can increase the burden on reviewers. We spoke to a team where changes were piling up because every one still needed manual acceptance testing. 25. Hiring an AI engineer and assuming the rest will sort itself out. That person still needs a clear problem, access to useful data, suitable infrastructure and colleagues who understand the work. Hiring doesn’t remove those responsibilities from the business. 26. Expecting people to forget the last failed pilot. Earlier disappointments can make people less willing to trust another system. Find out what went wrong and show what has changed before asking them to invest their time again. 27. Calling a project “90% done” before testing the difficult workflows. We’ve seen projects move quickly, then spend weeks on a couple of remaining workflows. Check what is still unproven before using the feature count to estimate the work left. 28. Expecting an agent to follow rules it cannot access. Pricing exceptions, product substitutions and informal agreements may live in someone’s spreadsheet. Make the relevant rules available, keep them current and test whether the system applies them correctly. 29. Feeding AI conflicting numbers without explaining the differences. Systems may use different definitions, update schedules or reporting periods. Establish which source and definition apply to each question before expecting a dependable answer. 30. Assuming a data feed contains the whole picture. Check which customers it covers, which fields are missing and how far back it goes. Make those limitations visible so users know what the answer is based on. What else?