Written by: Zsolt Czimbalmos, PMP, PBA, ACP, DASSM
21 AI adoption mistakes and how to handle them
AI tools have now appeared in almost every organisation, yet tangible business results are still missing in many places. According to a KPMG survey of 2,110 senior executives in 20 countries, conducted in February and March 2026, 95% of organisations have an AI strategy, but only 8% report demonstrable return on investment, and in Europe just 6%. The pattern may feel familiar in Hungary too: plenty of pilots, little use in production.
A further figure from the MIT Project NANDA 2025 report is telling: only 40% of companies have purchased an official LLM subscription, whilst at more than 90% of companies employees regularly use their own AI tools for work. This so-called shadow AI usage carries a great deal of risk.
In this article we have collected, grouped into categories, the adoption mistakes we see most often in our consulting and training work, together with possible solutions.
Contents
1. Strategic and leadership mistakes
This category is at the top of the list for a reason: these mistakes cause the most problems after adoption. What they have in common is that most of them are tied to leadership roles.
1.1. The adoption has no owner
As with so many transformations and complex changes, it is essential that AI adoption is also represented at leadership level. Without this, the initiative can slowly fade away or fragment into isolated experiments. Without an owner, nobody thinks the use case through from every stakeholder’s perspective at the boundaries between teams, for example at handover points, so the partial solutions never come together.
Symptom: IT buys the licences, HR organises a training session, but nobody is responsible for turning AI into business results.
Solution: appoint a business-side owner who has both the decision-making authority and the time for the task. It also matters that this person believes the results are achievable and has a vision for the adoption.
1.2. The AI adoption has no goal
We do not start AI adoption because it is the current „hype”, but because we expect business results from it. Without a measurable goal there is no basis for deciding whether to scale up or stop, so pilots either run indefinitely or are closed on subjective grounds.
Symptom: the goal is simply to „introduce AI”. After the pilot, nobody can say whether it was worth it.
Solution: set one or two metrics for every use case in advance (e.g. lead time, hours spent, error rate), and measure the baseline before and after adoption. Without a baseline, you can later only talk about feelings.
1.3. The wrong target metric
Using the wrong metric for your AI adoption goals is at least as serious a problem as having no defined goal at all. It is critical that the value delivered by the adoption is business-relevant and measurable.
Symptom: a target such as the average monthly volume of tokens consumed, or usage data and activity, is not value in itself. These measurements cannot yet tell you what return or business benefits the AI adoption delivers.
Solution: think in terms of roles for your AI use cases, and involve business-side representatives whose teams plan to use AI. Ask questions such as: if AI supported this task, how much of your time would be freed up each month? What business value could we deliver to our customers with this AI-based solution?
2. Methodological mistakes
The success of AI adoption is fundamentally determined by whether it follows a well-considered, deliberate process. This is perhaps the most subjective category, as there is no single successful approach. The assessment, the analysis of the selected task and the trial rarely follow each other in strict order: they progress iteratively and influence each other. The result of a PoC can, for example, reshuffle priorities, and the analysis may reveal that a use case is not a good first candidate after all. None of them is worth skipping, because a skipped step comes back later at a higher cost. We deal with the organisational effects of adoption in chapter 8.
2.1. No use case assessment
In our experience, AI adoption is effective when there is an initial picture of which areas of the organisation, which tasks and to what depth AI can support. Without such an overview, selection is haphazard: whatever is most eye-catching, whatever someone saw in a demo, or whatever someone asks for loudest gets prioritised. The organisation can then easily spend its first, limited resources on a task with little business benefit, or one that is technically too difficult for a first project. If the first attempt fails, it also damages the credibility of the entire AI initiative, and the better use cases never get a chance.
Symptom: the first idea, or the loudest colleague’s request, becomes the project or the pilot. Later it turns out that the benefit is small, or that you picked the hardest task to solve.
Solution: run a short assessment. Involve several stakeholders, collect the needs and possible cases, and evaluate them at least by business impact and feasibility or complexity.
2.2. The upfront analysis is skipped
Once the use cases have been selected, each chosen task also needs to be understood in detail. We do not usually refer to AI adoption as a project, since it far more closely resembles digital and agile transformations (although the market is starting to wear out that term too), yet there are a number of factors worth seeing clearly before implementation. Without them we are flying blind, and the expected benefits can easily fail to materialise.
Symptom: the solution is already being built, but nobody has written down exactly what the task is, which process it relates to, who the user is, what the input is and what the expected output is.
Solution: clarify the current process, the requirements and the acceptance criteria, just as you would for any other organisational change. With AI this is even more important, because if you have not written down what a good answer looks like, you cannot test it either.
2.3. Straight to agents, without a PoC
Social media, and often various AI conferences too, are full of the (frequently exaggerated) promises of agentic operation. So it is entirely understandable that the leader of a department or organisation would turn straight to agents that promise high productivity and results. However, this can have several drawbacks:
- It is not worth building on a promise: until there is proof (a Proof of Concept, PoC) of the business value of the task performed by the agent, we are talking about a hypothesis at most. Yet introducing such an agent requires far more effort than simpler solutions covered by basic features, so the risk is also higher.
- When a ready-made agent is handed over, users do not necessarily understand the underlying logic and have no first-hand experience of what depth of input and context the agent bases its results on. This can cause problems, especially at human checkpoints.
- Agents can indeed add serious value, but not necessarily for every task. There are still a great many tasks for which simpler tools deliver a higher return and easier customisation.
Symptom: the conversation is already about developing, integrating and automating the agent, whilst it has not yet been proven that the task itself can be performed valuably and reliably with AI.
Solution: proceed step by step, and verify at each step that the solution works:
- Manual prompting: you test on a few real examples whether the model is capable of the task at all.
- Persistent project: a workspace with permanent background material and instructions (for example a Claude Project) used by several people. This is where you find out whether the results are stable.
- Skill: you capture the proven steps in a reusable instruction package, so everyone gets the same quality.
- Agent or automation: only if it has proven itself at the previous levels and manual execution has become a bottleneck.
For many tasks, the second or third level is already enough. Stop where the solution delivers value; deploying agents must not become a matter of prestige.
3. Process mistakes
Seasoned experts know from recent years, whether from implementing an IT system or steering a larger-scale transformation, that solutions and initiatives are often built on business processes. Knowing the as-is (current) and to-be (target) processes in itself helps to clarify needs and goals and, just as importantly, helps to bring problems to the surface before implementation.
3.1. Speeding up bad processes
A very common problem is that processes are not rethought before AI adoption. We take what does not work well as a given, which essentially speeds up the delivery of poor results, or even further entrenches the faulty way of working.
Symptom: the existing steps are performed one-to-one with AI, but the unnecessary approvals, the duplicate data entry and the waiting times remain. The result is a faster but equally cumbersome process.
Solution: review the process first. Which step is unnecessary, where is the most time lost, what has remained purely out of habit? Then decide where AI should go.
3.2. The human role is not defined
LLMs work probabilistically, that is, on the basis of probability. This is a huge difference compared with deterministic process automation. Most users are looking for deterministic behaviour, yet the simple configuration and low entry cost of AI tools push these tools to the fore in many places. In AI adoption it is critical to place human checkpoints at the right points and times in the process. Nobody wants to end up in a situation where a document, client proposal or report produced by AI reaches its audience with errors or inappropriate content. Human review is mandatory!
Symptom: it is unclear who checks the AI output and when a human decision is needed. In that case either everything is checked twice and the gain is lost, or nothing is checked and errors can slip through.
Solution: define the checkpoints: what can go ahead without review, what needs to be checked, and who is responsible for the end result.
4. Data mistakes
Good decisions and results can only come from good data. This basic statement holds true for AI adoption too. The context and input often exist in people’s heads, but AI obviously cannot use them there. Ideally they need to be available somewhere in a structured form. Without adequate data, or with poor-quality data, the result will not be adequate either.
4.1. Poor data quality
Although improving data quality has been a hot topic in recent years, it is still a constraint in many places. Manual data entry and inadequate data validation all pose risks. If data quality is inadequate and unstable, the outcome of AI adoption will only cause more problems later on.
Symptom: outdated, contradictory or duplicated documents in the knowledge base. The AI answers confidently, just from last year’s policy or from incorrectly recorded data.
Solution: tidy up the sources belonging to the selected use case: one valid version, a clear owner, archiving of old material. You do not have to clean up the whole company at once, only the part the AI works from. It is also advisable to run regular data validation for the sake of stability.
4.2. Missing data structure
How structured the data is has a major impact on the results of AI adoption. Operating costs (e.g. token consumption), the level of model required and the results themselves all depend on the structure in which the data is available.
Symptom: important information sits in emails, in people’s heads and in free-text spreadsheets, and some CRM fields are empty. The AI has nothing to work from, or produces false results.
Solution: introduce minimal structure for critical data (mandatory fields, consistent naming, templates) before you introduce an AI-based solution or automate.
4.3. Let's connect everything to AI
Connecting a connector, an MCP server or an integration takes just a few clicks today. That is why many organisations connect every available system to AI: email, document store, CRM, finance system. The AI thus gains access to data it does not need for the task in hand, and since the data is not categorised, nobody knows how much of it is confidential or personal.
Symptom: every connector is switched on for every user, but nobody can say which use case needs which one. Fragments of a confidential contract or an HR document end up in the answer to a simple question, and it is hard to find out afterwards what data has been passed on this way.
Solution: decide for each use case which systems, and which data within them, need to be accessed, and connect only those. To do this, first categorise your data (for example public, internal, confidential, personal) and record which category may be accessed through AI. Review the connected connectors regularly, as you would any other access right. The practical challenge is that we often want to give AI less data than the employee in question has access to, for example in the case of an HR or finance colleague. Connectors typically work with the user’s permissions, so this has to be solved separately, for example with a dedicated folder, restricted access or a separate technical account.
5. People and competence
Unfortunately, in many AI adoptions leaders tend to forget about the users. It matters a great deal what experiences, prejudices, fears, skills and, of course, aspirations the users bring with them when they start using the solutions. If we leave this out of the equation, the whole adoption becomes shaky, however much attention we pay to data, methodology and goals.
5.1. Licences without training
If we only hand out licences, users will not necessarily start experimenting with the tool. Many cannot or do not want to explore the possible uses on their own, since alongside their working hours this is not a given. Many get stuck, and if there is no immediate sense of success, they put the tool aside.
Symptom: clients often approach us with this sentence: „We need support. We have distributed the AI licences, but for some reason colleagues are not using the tool.” Token usage is too low, the way work is done does not change, and requests are limited to a holiday plan or an email summary or two.
Solution: role-specific or hands-on training based on the participants’ own tasks, followed by time to practise and ongoing support. A business analyst, a project manager and an HR professional benefit from different use cases, so the way they use the tool may also differ.
5.2. Unrealistic expectations
However much it may seem so at first, AI is not a silver bullet. It has limitations, and expectations should be managed accordingly. With unrealistic expectations, the solution can disappoint, which weakens the willingness to use it later.
Symptom: half of the team expects AI to solve everything, the other half passes judgement at the first wrong answer.
Solution: show the limitations in training too: wrong but confident answers, the need for context, responsibility for checking. Anyone who knows where the tool makes mistakes can also make good use of it.
5.3. No internal champion or power user
One important element of every transformation is the role of internal change agents. These are people who support the transformation and change with their own experience and knowledge. In AI adoption, without key users, internal champions or power users (whatever we call them), the adoption will be highly exposed and continuous improvement may also suffer.
Symptom: the knowledge sits with one or two enthusiastic colleagues. If they are overloaded or leave, everything grinds to a halt. Staff cannot handle changes to processes or requirements.
Solution: build a network of key users, and share the proven prompts, projects, skills and solutions. Build a community, set up Communities of Practice, and help those involved keep up with fast and frequent technological change.
6. Security and compliance mistakes
One of the biggest challenges in AI adoption is creating a framework for secure operation and use. Using AI without an appropriate data security, information security and cybersecurity framework is risky, and on top of all this the regulatory layer (the AI Act, GDPR and, where relevant, ISO 27001 and NIS2) can impose further tasks on us.
6.1. Shadow AI and bans
Especially at larger companies, it happens that the organisation bans the use of AI. In our experience there can be several reasons for this; the ones we encounter most often are:
- the organisation does not yet have an established strategy and does not know what to use AI for or how, so it would rather ban it until this is clarified
- they are developing their own solution and do not want to invest in AI tools until it goes live
- they do not see the business value in it, or senior management is opposed to AI
Every employee has their own devices, and with personal AI accounts uncontrolled use and a risk of data leakage can develop.
Symptom: employees use AI with their own free or poorly configured accounts and paste client data, contract extracts and sensitive information into it. According to the MIT figure quoted in the introduction, this is typical at most of the companies surveyed.
Solution: a ban on its own rarely works. Provide a secure, official alternative, support safe use through training, and set out clearly what data may and may not be entered into an AI tool. Most personal AI accounts may, under their default settings, also use your data to train the large models, so using company licences is recommended.
6.2. "The AI Act doesn't affect us"
Many organisations find the requirements of the AI Act hard to interpret. Everyday office use of AI typically does not fall into the high-risk category, yet certain general obligations apply to these uses too. As a result, it is unclear exactly what compliance tasks the company has.
Symptom: regulation is seen as the developers’ business, or ignored for lack of specific requirements. However, Article 4 of the AI Act has applied since 2 February 2025, and in amended form since July 2026: organisations using AI systems must take measures to develop their staff’s AI literacy. At the same time, the regulation does not prescribe a specific number of training hours, an exam or a certificate. (source).
Solution: assess which AI tools you use and for what purposes. Identify which uses carry actual legal obligations and align the necessary measures with them. Ensure that your staff’s AI knowledge is developed appropriately, and document the steps taken. Examine the processing of personal data under the GDPR, and information security matters under the applicable ISO 27001 or NIS2 requirements.
7. Technology mistakes
Technology decisions are long-term: the choice of tool, the knowledge built on it and the integrations determine for years what the organisation can achieve with AI and at what cost. These mistakes are rarely visible at the start, because the initial pilots work with almost any tool. They come to light when the solution needs to be scaled, extended or replaced.
7.1. A tool chosen for convenience
Many organisations look for AI where they already have a contract, or where it is easiest to procure. There are good reasons for this: no new supplier needs to be vetted, licensing is simple, and the tool already fits the existing systems. The problem starts when the decision rests solely on these criteria and nobody checks how well suited the tool is to the selected use cases, and at what cost. The same task can be solved with different quality and at a different price depending on the tool, and a poorly fitting tool damages the perception of the whole adoption through user disappointment.
Symptom: the AI tool was chosen through a procurement or IT decision, without testing it on use cases. Meanwhile some users rely on a personal tool because they feel it does the job better, or more add-on licences than expected are needed to achieve the same result.
Solution: before you buy licences for the whole organisation, compare at least two tools on the selected use cases with real tasks. Ease of procurement should be one criterion among many. It may also turn out that several tools are justified in the organisation, for different tasks.
7.2. Everything is built on a single tool
The AI market changes quickly: providers change prices and terms, phase out features, and new products appear. If the organisation’s AI-related knowledge (instructions, knowledge base, process descriptions) accumulates in a single provider’s closed format, every such change directly affects operations, and the cost of switching grows over time.
Symptom: the prompts, the knowledge base and the integrations live in a single provider’s proprietary format. If the pricing, the terms or the product itself changes, there is nowhere to go, and a significant part of the accumulated knowledge is lost.
Solution: keep the knowledge (instructions, process descriptions, proven prompts) in your own document store, in a provider-independent form. For integrations, favour open standards such as MCP, so that a change of tool does not mean rebuilding the entire solution.
8. Organisational development mistakes after adoption
AI adoption does not end with distributing licences and the first working solutions. If job roles, task allocation, recruitment, processes and organisational structure do not follow the changed way of working, the organisation tries to exploit the new possibilities within the old structure. Meanwhile, people’s motivation and relationship with their work also change.
8.1. Nobody reallocates the freed-up capacity
One of the most important promises of AI adoption is freed-up capacity. However, this capacity appears unevenly: it is significant in certain roles and tasks and barely noticeable elsewhere. If nobody deliberately manages the freed-up time, it leaks away or creates an uneven workload within the team. In our experience, for example, AI can support a large part of project managers’ administrative tasks, but if we do not rethink which genuinely value-adding tasks PMs should spend their freed-up time on, the business impact cannot materialise directly.
Symptom: suppose AI frees up 30% of a team’s capacity on average. If nobody rethinks how the remaining tasks are allocated, some people will spend all day giving tasks to AI, whilst others remain just as overloaded as before.
Solution: after adoption, review task allocation, job descriptions and processes, and decide deliberately what you will spend the freed-up time on. If the nature of the work has changed, it is also worth reviewing team structures and approval levels.
8.2. Career paths are not rethought
Much professional knowledge is built through practice: junior colleagues typically learn the trade on routine tasks and become seniors over the years. If AI takes over exactly these tasks, the learning path is also broken. In the short term this looks like a saving, but in the longer term it leads to a talent pipeline problem, and it is worth starting to plan how to handle it now.
Symptom: you do not hire juniors because AI already does the routine tasks. In a few years there is nobody to grow into a senior role, and experienced colleagues can only be replaced from the external market.
Solution: rethink career paths: what does a junior learn from if AI does the routine work? Where and how should AI use be built into the expected competences? The role of juniors could, for example, be the professional review of AI outputs with senior mentoring, so that learning does not drop out of the process.
8.3. The human side is overlooked
AI adoption also changes people’s relationship with their work. What someone takes pride in, what they are considered an expert in, and what a job well done means to them are all changing. These changes do not show up in efficiency metrics, but they directly affect motivation, engagement and, ultimately, whether the tools introduced are actually used.
Symptom: we have come across a client situation where developers were given AI access, combined with a management expectation: productivity gains through the tool were set as the goal. The developers, however, resisted using it, because they felt the tool was taking away the essence of their profession. Elsewhere it is the fear of losing one’s job that surfaces, but in both cases motivation falls whilst management waits for the efficiency figures.
Solution: communicate openly about what is changing and what is not. Offer new areas of responsibility and development opportunities, and regularly ask the team how they are experiencing the change.
Stuck at any of these points?
If you recognised yourself in any of the mistakes above, you do not have to untangle it alone. The ProMan Consulting team can support you across the entire adoption journey: with use case assessment and AI strategy at the start, role-specific AI training for users, AI compliance support (AI Act, ISO 27001, NIS2) on the security side, and AI-augmented organisational development after adoption.
Write to us, and in a short conversation we will look at where you are and what the next step could be!
Frequently asked questions about AI adoption
Where should AI adoption start?
With a short use case assessment. Collect the tasks where AI could help, evaluate the candidates by business impact and feasibility, and start with the best two or three. Set a metric and a baseline for each in advance, so that you can later decide whether it was worth it.
What should you pay attention to during AI adoption?
In our experience, most mistakes are made before the technology even comes into play. Make sure the adoption has an owner and a measurable goal, test the solution in small steps before you automate, put the relevant data and access rights in order, and prepare your staff with training tailored to their own tasks.
Why is shadow AI a problem?
Shadow AI is when employees use AI tools with their own accounts, without the organisation’s knowledge or permission. In such cases client data, contract extracts or internal figures may end up with a provider whose terms nobody has checked, and personal accounts may also use the data entered to train the models. The risk is reduced by a secure, official tool and a clear rule on what data may be entered into AI.
Is AI training for staff mandatory?
Article 4 of the AI Act has applied since 2 February 2025, and in amended form since July 2026: organisations using AI systems must take measures to develop their staff’s AI literacy. The regulation does not prescribe a specific number of hours, an exam or a certificate. And in practical terms, licences without training rarely deliver results.
When is it worth building an AI agent?
When the solution has already proven itself at the simpler levels: it delivers stable results with manual prompting, in a persistent project and as a skill, and manual execution has become the bottleneck. For many tasks, the project or skill level is already enough.
How can you tell whether AI adoption is paying off?
Not from usage data (token consumption, active users) alone. You need a business metric defined in advance for each use case, such as lead time, hours spent or error rate, together with its baseline before adoption. The change can then be measured against that.
Which AI tool should we choose?
The one that best fits the selected use cases. Before you buy licences for the whole organisation, compare at least two tools on real tasks. Ease of procurement is an important criterion, but it cannot be the only one, and it may well turn out that different tools are justified for different tasks.
What changes in the organisation after AI adoption?
Capacity is freed up, but unevenly, so task allocation, job roles and processes need to be rethought. Career paths are also worth reviewing, because if AI does the routine tasks, juniors’ learning path can be broken. People’s relationship with their work also changes, so attention must be paid to motivation and professional identity too.
