What the EU AI Act Means in Practice
The EU AI Act in practice, for CFOs and senior decision-makers at mid-sized companies
- AI In Business
You do not need to build AI for the AI Act to apply to you. It is enough to use AI whose output reaches a person in the European Union, even when your company is headquartered in Budapest, Vienna, or outside the EU altogether. The AI Act, the European Union’s regulation on artificial intelligence, is the world’s first comprehensive AI law, and it reaches further than most executives expect.
Running a prohibited system can cost up to €35 million or seven percent of global annual turnover, which sits above the four percent ceiling in the GDPR.
A law built around risk levels
The AI Act sorts AI systems by their intended use and its potential for harm: the greater the risk, the more obligations attach. Four levels describe the whole picture.
- Minimal risk: the scale starts here, and the large majority of everyday business AI sits at this level, from spam filters to most office tools. The Act attaches no new obligations to these.
- Limited risk (transparency): one step up stand the systems people interact with directly, such as chatbots and tools that generate synthetic content. The duty here is disclosure: tell people they are dealing with AI, and label AI-generated content.
- High risk: compliance gets serious from here. This level covers the sensitive domains, recruitment and employee evaluation, credit scoring and essential services, biometrics, critical infrastructure, education, law enforcement, migration, and the justice system. Most of the compliance weight sits here.
- Unacceptable risk (outright ban): the top of the scale, which the Act simply prohibits. This covers social scoring, subliminal or manipulative techniques that cause harm, the exploitation of vulnerable groups, the untargeted scraping of facial images for recognition databases, emotion recognition in the workplace and in schools, and certain cases of real-time biometric identification. These have been prohibited since February 2025.
Classification is rarely self-evident in practice. A system can be high-risk along two routes: as a stand-alone system listed in Annex III, or as a safety component built into a regulated product such as machinery or a medical device under Annex I. The decision turns on the intended purpose, the function, and the actual context of use, so the same technology can fall into two different categories at two different companies.
This is where the most common mistake begins: classification gets settled in conversation. The statement “it is just a chatbot” is no legal analysis on its own. An internal assistant answering general questions is judged differently from a system that ranks CVs, triages claims, or assesses creditworthiness. Where no written, approved rationale explains why a system stays outside the high-risk category, the decision becomes hard to defend when an authority asks.
One point deserves separate attention: the transparency obligations in Article 50 apply to certain systems regardless of risk level. If you use emotion recognition or biometric categorisation, or you generate deepfake-style synthetic content, the disclosure duty holds even when the system otherwise sits in the lower half of the scale.
Your obligations depend on your role
The Act treats every participant in the chain as an operator. The provider develops or substantially modifies the AI system; the deployer puts it to work in its own activities; importers and distributors bring the solutions onto the EU market. Most mid-sized companies are deployers: they license a model or a tool and apply it to a business process.
Start with the most common case, the deployer. Human oversight comes first: a person has to sit in the decision process who can override or stop a given output on the spot, before it takes effect. This is control at the level of the individual case.
The system also has to be watched in live operation. Here the object of attention is the behaviour of the system as a whole, observed in real time: you look for systematic errors, bias, or degrading accuracy, and you flag problems to the vendor. Records matter too: the logs the system generates automatically have to be retained, so that what happened, and why, can be reconstructed and audited afterwards.
Log retention has a concrete yardstick. The deployer keeps the logs the system generates automatically, to the extent they are under its control, for at least six months, and longer where other Union or national law requires it. It pays to clarify before signing: does the vendor’s system generate logs at all, do you have access to them, and can the six-month retention be configured?
Input data is your responsibility as well. Where the input data sits in your hands, you have to ensure it fits the intended purpose and stays sufficiently representative. If the system shows a risk in operation, you suspend use and inform the provider and the market surveillance authority without undue delay. For a serious incident, the notification is immediate.
Two information duties are routinely forgotten. If you introduce a high-risk system at the workplace, you inform the workers’ representatives and the affected workers in advance. And if the system makes or prepares decisions about natural persons under Annex III, those individuals also have to be told that they are subject to such a system.
Certain deployers also carry out a fundamental rights impact assessment before first use. This circle covers bodies governed by public law, private entities providing public services, and the deployers of systems used for creditworthiness assessment and for life and health insurance risk assessment and pricing. Where a data protection impact assessment already exists, the fundamental rights assessment complements it.
And one sentence for the CFO: these obligations cannot be shifted by contract. Operational tasks can be assigned to the vendor, and the responsibility under the Regulation stays with the deployer. A vendor’s certificate or audit report supplements your own evidence, and it never takes their place.
The other end is the provider role, with the heaviest obligations. You land there if you develop an AI system yourself, or substantially modify an existing one. Then you have to operate a risk management system, compile full technical documentation, carry out a conformity assessment, and register a high-risk system in the EU database before it reaches the market. The gap between the deployer and the provider burden is significant, and which side you land on matters a great deal.
One pitfall deserves separate attention: thorough fine-tuning or substantial modification of a model can tip a company from the deployer role into the provider role, along with the much heavier obligations that come with it. If you take a foundation model and adapt it for a regulated purpose, it is worth examining which side of the line you land on.
A widespread misunderstanding attaches here. If you use a large language model through an application programming interface (API), the model provider’s obligations stay with the model provider. Your responsibility is the system you built on top of it, and what you did with it determines whether you count as a deployer or a provider.
The distinction between using AI and building AI is becoming increasingly important. We explored this shift in more detail in From Open to Owned: Will AI Repeat the Internet’s Story →
AI literacy: the obligation that is already live
While attention points to the dates in 2026 and 2027, one obligation has been in force since 2 February 2025. Under Article 4, providers and deployers have to ensure that the staff handling their systems hold a sufficient level of AI literacy. The duty extends to outside contributors acting on their behalf, and it covers every tool in the inventory, including the AI features embedded in other software.
The AI literacy obligation has been live since 2 February 2025, and its supervision begins on 2 August 2026.
The Digital Omnibus softens this point: the text moves towards proportionate measures that support and develop literacy, turning it into an obligation of effort. Supervision and enforcement still begin on 2 August 2026 at the national market surveillance authorities. And for deployers of high-risk systems, the duty to prepare the staff exercising human oversight remains in place.
In practice this means role-based preparation. An executive who has AI draft board papers needs different knowledge from a customer service colleague who handles calls with it, and different again from a developer who builds an AI feature into the product. A general “what is AI” training satisfies none of these needs. Documentation counts here too: who received what preparation, and when.
The deadlines after the 2026 changes
The Regulation entered into force on 1 August 2024 and becomes applicable in phases. The prohibited practices and the AI literacy duty started on 2 February 2025, and the rules for general-purpose AI models on 2 August 2025. The next major date is 2 August 2026: the transparency obligation in Article 50, the enforcement powers over general-purpose AI, and market surveillance authority all become applicable.
The rollout calendar shifted in mid-2026 with the arrival of the Digital Omnibus, a targeted package of amendments. The European Parliament endorsed it on 16 June 2026 and the Council of the European Union approved it on 29 June 2026; the last step is publication in the Official Journal (expected in July 2026), and the rules take effect on the third day after that. The package leaves the risk-based architecture intact, and it pushes out the heaviest deadlines:
- Stand-alone high-risk systems (Annex III), such as recruitment or credit-scoring tools, are covered from 2 December 2027.
- High-risk AI embedded in regulated products (Annex I), in machinery and medical devices, from 2 August 2028.
- The prohibition on AI that generates non-consensual intimate imagery and child sexual abuse material takes effect on 2 December 2026.
- The watermarking duty for AI-generated content also moves to 2 December 2026.
- The deadline for member states to set up AI regulatory sandboxes moves to 2 August 2027, and an EU-level sandbox also opens, operated by the AI Office for SMEs and start-ups.
The practical reading is simple: teams working with high-risk systems gained roughly sixteen months of extra room. The transparency obligations, the general-purpose AI rules, and the enforcement machinery still arrive in August 2026. The reprieve is there so you can build the governance framework properly, and whoever uses it well will be ready long before the deadline.
Two clarifications help avoid the most common misreading. The transparency obligations in Article 50 stay where they are, and they become applicable on 2 August 2026. For watermarking, the four-month reprieve applies to systems already placed on the market before 2 August 2026; those have until 2 December 2026 to comply.
The reason for the postponement is practical. The harmonised standards are unfinished, the notified bodies are not in place, and some member states are behind on designating their authorities. With the supporting infrastructure missing, the legislator gave time.
One important caveat: until the package appears in the Official Journal, the original text of the Regulation governs in law. So plan against the original dates, and use the reprieve to get ahead.
What non-compliance costs
The fines are painful, and they track the seriousness of the infringement. Running a prohibited system can cost up to €35 million or seven percent of global annual turnover, whichever is higher. Breaching the high-risk obligations can reach €15 million or three percent. Supplying incorrect or misleading information to the authorities can reach €7.5 million or one percent. The top band sits above the four percent ceiling in the GDPR. The Regulation applies proportionate amounts to SMEs and start-ups, so smaller companies face smaller figures.
The fines are imposed by the national market surveillance authorities, whose enforcement powers come alive on 2 August 2026. A deployer’s failure can be sanctioned on its own, independently of any provider infringement. Where personal data is involved, a GDPR procedure can run in parallel, so the same case can travel through two authorities.
In Hungary, the framework was laid down by Act LXXV of 2025 and Government Decree 344/2025 (X. 31.). The minister responsible for enterprise development performs the AI market surveillance tasks and operates the single point of contact, the notifying authority is the National Accreditation Authority, and the high-risk systems placed on the market or used in the financial sector are supervised by the Magyar Nemzeti Bank. The Hungarian Artificial Intelligence Council supports consistent application.
The Hungarian implementing decree sets the upper limit of the fines as a fixed forint amount, matching the euro values in the Regulation. The ceiling for prohibited practices comes to 13.3 billion forints.
Where the AI Act becomes a data problem
Read through the high-risk obligations and a pattern appears. Risk management, data governance, technical documentation, logging, and human oversight all rest on a single foundation: you have to know your own data and processes well enough to describe them, defend them, and audit them. A company that cannot say for certain where a number came from will struggle to prove that the AI system built on it is fair, accurate, and under control.
We see this situation often. Master data lives in several systems at once, the same customer or product appears under three slightly different records, and the reports built on them contradict each other. Layer an AI system on top of that, and it will produce confident answers from incoherent data, which is exactly the failure the data governance rules aim to prevent.
The Regulation spells out the expectation for high-risk systems: the training, validation, and test data have to be relevant, sufficiently representative, and as free of errors as possible, and the biases have to be examined. For a deployer, the counterpart is the quality of the input data, which is settled on your side.
So the compliance requirement and the operational fix turn out to be the same task: one clean, well-governed source of truth underneath the AI. Whoever puts master data in order solves a regulatory problem and an operational one at once, and the investment pays back in the quality of the reports.
Poor data governance is often the real obstacle to AI compliance. We explored this challenge in more detail in Which Customer Record Is the Real One →
First steps for a mid-sized company
The work breaks into a short sequence that any leadership team can start now:
- Take inventory of every AI system in use or under procurement, including the tools embedded in software you already license.
- Classify each one by risk level and by your own role (provider or deployer) for that system.
- For the high-risk cases, map the gap against the Regulation’s requirements and assign an owner.
- For chatbots and generative tools, prepare the transparency and labelling disclosures due in 2026.
- Put your AI governance framework in writing, covering data governance, human oversight, and documentation, so you can evidence your work when an authority asks.
- Write an approved classification rationale for every system. When an authority asks, this is the first document they will request.
- Review the vendor contracts and the instructions for use. Check the logging capability, your access to the logs, and the six-month retention.
- Start a role-based AI literacy programme, and document who received what preparation and when.
- Assign an incident path to the high-risk systems: who suspends use, who notifies the provider and the authority, and within what deadline.
Procurement deserves separate attention. Enterprise buyers already write AI Act compliance into their contracts, so a clean compliance record is increasingly a condition of winning deals across the EU.
On the procurement side, two questions move the negotiation forward. The first: which role are we in for this system, and what happens if we fine-tune it. The second: what evidence does the vendor supply for its own compliance, and what do we have to produce ourselves. Ask these two in time, and you spare yourself the later scramble to reconstruct missing documentation.
The takeaway
The AI Act arrives in phases, it rewards preparation, and it punishes drift. The recent deadline changes bought time on the heaviest obligations, and the direction is fixed: every company that uses AI in the EU or for the EU will need a documented, defensible governance framework. Whoever treats this as an operations and data project, and starts early, will find compliance largely a by-product of a well-organised business.
The practical order stays simple regardless. First find out what you have, then which role you are in, and only then start meeting obligations. Without the inventory and the classification, every further step is guesswork. With both in hand, the bulk of the task turns into familiar corporate governance work: owners, processes, documentation, data quality.
Where to start
If the AI Act has moved onto your agenda and the way forward is still unclear, a structured assessment is the fastest way to gain footing. The AI Compass Audit is a four-week, fixed-price engagement that maps your company’s AI use, risk exposure, and system environment, and ends with a clear view of which initiatives are worth pursuing, under what conditions, and with which safeguards. If you would like to clarify your questions first, you can begin with a free 30-minute consultation.
Sources
- Council of the European Union. (2026, June 29). Artificial intelligence: Council adopts the Digital Omnibus package. Council of the European Union. Read article →
- European Commission. (n.d.). AI Act Service Desk: Article 26 – Responsibilities of deployers. European Commission. Read article →
- European Commission. (n.d.). AI Act Service Desk: Article 99 – Penalties. European Commission. Read article →
- European Commission. (n.d.). AI Act Service Desk: Implementation Timeline. European Commission. Read article →
- European Commission. (n.d.). AI literacy: Questions and answers. European Commission. Read article →
- Grant Thornton Hungary. (2025). Institutional implementation of the AI Act. Grant Thornton Hungary. Read article →
- Hungary. (2025). Act LXXV of 2025 and Government Decree 344/2025 (X. 31.). National Legislation Database. Read article →
Csaba Fekszi
Csaba Fekszi is an IT expert with more than two decades of experience in data engineering, system architecture, and AI-driven process optimization. His work focuses on designing scalable solutions that deliver measurable business value.
Related posts
The 70% Below the Surface That Most Quotes Never Show
The real barriers to enterprise AI, and what the companies that succeed do differently
Turning Ambition into Real, Scalable Results
Are you sure AI is the right next step?
We help uncover the real opportunities, limitations, and realistic next steps.