InsightsEU AI Act
Seven mistakes organisations make with the AI Act.
The AI Act already applies, but many organisations look at the wrong things. These are the seven mistakes we see most often, and what to do instead.
The first obligations of the AI Act have applied since February 2025. The Digital Omnibus of July 2026 moved a few deadlines, but the core stands. In conversations with organisations we keep seeing the same patterns. Not from unwillingness, but because the AI Act works differently from the rules people are used to.
1. Assuming the AI Act only applies to AI developers
The most common assumption: we don’t build AI, so the supplier is responsible. The AI Act, however, distinguishes between the provider, who develops an AI system or places it on the market under its own name, and the deployer, who uses an AI system under its own authority. Both roles carry their own obligations.
Every organisation that uses AI has been subject to the AI literacy duty (Article 4) since 2 February 2025, and the prohibited practices of Article 5 apply to use, not just to development. Transparency obligations have applied since 2 August 2026, for example when you publish deepfakes or use emotion recognition. For high-risk systems, Article 26 adds more: use in line with the instructions for use, human oversight by competent people, monitoring, keeping logs, and informing employees and affected persons.
What goes wrong
Responsibility is placed with the supplier, and nobody inside the organisation owns it.
What works
Determine your role for each system and record who owns it internally. As a deployer you have your own obligations, whatever the supplier arranges.
2. No complete overview of the AI already in use
Many AI registers start with in-house innovation projects. Most of the AI in an organisation sits elsewhere: in features suppliers add to existing software through updates, in SaaS services for HR, customer contact or finance, and in tools employees adopt on their own initiative. That last group, shadow AI, is often the largest and the least visible.
Without a complete register, every next step is guesswork. You cannot classify what you don’t know about, and a regulator or client asking which AI you use expects an accurate answer.
What goes wrong
The register only contains what was built in-house, and goes stale as soon as a new tool or update arrives.
What works
Include procured AI, AI inside existing software and shadow AI. Link the register to procurement so it stays current.
3. Classifying by technology instead of by use
“It’s just a language model” or “we don’t use deep learning” says little about the risk class. The AI Act classifies by intended purpose: what is the system used for, and which decisions about people does it influence?
The same language model can fall into two classes. Summarising meeting notes is minimal risk. Ranking job applicants falls under employment in Annex III and is therefore high risk. Conversely, not every piece of smart software is an AI system: the definition centres on systems that infer from input how to generate output. Simple, predefined rules usually fall outside it.
What goes wrong
A tool is classified once, regardless of what departments use it for.
What works
Classify per use case: what does the system do, for whom, and which decisions does it support?
4. Becoming a provider without noticing
This is the most expensive mistake on the list. Under Article 25, a deployer becomes the provider of a high-risk system when it puts its own name on it, substantially modifies it, or changes its purpose so that it becomes high risk.
An example: a team uses a general-purpose AI assistant to pre-screen incoming job applications. The supplier never intended the system for that. Through the new purpose, you have become the provider of a high-risk system, with every obligation that comes with it: risk management, technical documentation, a quality management system, conformity assessment and registration.
What goes wrong
New uses of existing tools emerge on the work floor, without anyone assessing the consequences.
What works
Have every new use of an AI tool briefly checked for risk class and role before it goes live. Half an hour up front saves months of work later.
5. Reading the delay as “we have until 2027”
The Digital Omnibus moved the deadlines for high-risk systems: to 2 December 2027 for the use cases in Annex III and to 2 August 2028 for AI in regulated products. That news is often read as a delay of the whole AI Act. It isn’t.
The prohibited practices and AI literacy have applied since February 2025, the rules for general-purpose AI models since August 2025 and the transparency obligations since August 2026. New prohibitions follow in December 2026. Violating the prohibitions can lead to fines of up to 35 million euros or 7 per cent of worldwide annual turnover. On top of that, setting up risk management, data quality, documentation and human oversight for a high-risk system takes months. If you need to be ready in December 2027, you start now.
What exactly changed is covered in our article on the Digital Omnibus.
6. Treating AI literacy as a single e-learning
Article 4 requires providers and deployers to take measures that support the AI literacy of their staff, and of others who work with AI on their behalf. The Digital Omnibus rewrote the text as a best-efforts obligation, but the duty still applies. And the text explicitly asks you to take knowledge, experience and the context of use into account.
One generic e-learning for everyone fits that poorly. A recruiter working with a screening tool needs different knowledge from a developer, a board member or the employee providing human oversight of a high-risk system.
What goes wrong
Everyone gets the same hour of training, and afterwards nobody knows who learned what.
What works
Tailor the content to the role, record who completed what, and repeat when tools or use cases change.
7. Treating the AI Act separately from the GDPR and existing processes
Some organisations set up a separate AI compliance project alongside privacy, information security and procurement. That leads to duplicate work: a DPIA under the GDPR and a fundamental rights impact assessment under the AI Act largely address the same questions. Besides, most AI applications process personal data, so the GDPR applies anyway.
A second pitfall is treating compliance as a one-off project. Models change, suppliers push updates and use cases drift. What is minimal risk today can be high risk after a change.
What goes wrong
A stand-alone AI track with its own forms, which is no longer maintained after delivery.
What works
Build AI governance into existing processes, with one coherent impact assessment and periodic reassessment. ISO/IEC 42001 connects to ISO 27001 and your quality system.
Quick check: where does your organisation stand?
Tick what your organisation can demonstrably show is in place. The check stays in your browser; nothing is stored or sent.
Seven questions, one per mistake
Demonstrably means: you can show it to a client or regulator.
Sources
- Regulation (EU) 2024/1689 (AI Act), EUR-Lex, in particular Articles 3, 4, 5, 6, 25, 26, 27, 50 and 99 and Annex III.
- Regulation (EU) 2026/1744 (Digital Omnibus on AI), EUR-Lex.
This article is for information only and is not legal advice. Current as of October 2026.