EU AI Act Preparation for Hungarian SMEs: What to Do and When

The EU AI Act classifies AI systems by risk, and the obligations follow from the category. Preparation therefore starts with one question: which category the systems you run and plan fall into. In this article we walk through the four categories, the provider and deployer roles, what the high-risk obligations mean in practice, and a realistic preparation sequence.

The obligations become applicable in stages between 2025 and 2027. There is time to prepare, but the order matters: without the classification you don't know which obligations apply to you, or from when.

Which category does your system fall into?

The regulation uses four risk categories: unacceptable, high, limited (transparency) and minimal risk. The higher the category, the more obligations come with it.

Most AI applications running in companies — document processing, customer service assistants, internal knowledge bases — are limited or minimal risk. The obligations there are typically about transparency, such as the user knowing they are talking to an AI. Systems that make or prepare decisions about people typically fall into the high-risk category.

Run the classification per system, with written reasoning. The reasoning pays off twice: your legal counsel can review it, and you can produce it when someone checks later.

What do the high-risk obligations mean in practice?

Through an engineering lens, the obligation classes for high-risk systems look like this:

• Risk management. It is written down what can go wrong, who it affects, and what you built in against it. A living document: it gets updated when the system changes.
• Data quality. You know which data the system uses, where it comes from, and who owns its quality. Bad source data shows up in the output, so checking it is part of the process.
• Logging. The system's decisions can be traced back: what the input was, what the output became, and who approved it.
• Human oversight. Review points built into the process: who looks at the decision, what the reviewer sees, and where they can intervene.
• Technical documentation. It is written down how the system works, which data it uses, and which risk-management steps belong to it.

Most of this is system design. Building it in afterwards is more expensive and more painful, so on our projects the review points and the logging are built as part of the system, and the documentation is written alongside the development.

Is your role provider or deployer?

The regulation assigns separate obligations to the provider and the deployer of a system. Which role is yours is worth clarifying together with the classification, because on a custom build the two can differ — and the scope of the obligations depends on the role as well. Write the role down in the classification reasoning, per system: later it decides which documentation is whose job.

What is a realistic preparation sequence?

Five steps, in this order:

• Inventory. You list the AI systems you run and plan — including the tools bought as finished products.
• Classification. Each system has its risk category and your role, with written reasoning.
• Gap assessment. Of the obligations the category carries, what exists today and what is missing — in documentation, logging, review points.
• Documentation and logging design. The gap list becomes a scheduled plan: which document gets written, what has to change in which system. Whatever can be carried over from your existing material, you carry over.
• Oversight process. It is written down who authorizes an AI system going live, who owns it, what you measure on it, and when it has to be reclassified.

The first two steps are covered by our AI opportunity assessment, from HUF 500,000 + VAT; the output is a written plan you can use even if you continue without us. The full schedule is on the EU AI Act compliance preparation page.

From when do you have to comply?

The obligations become applicable in stages between 2025 and 2027, and which one applies from when depends on the risk category of the system. The dates that concern you can therefore be given after the classification, based on the text in force. The regulation is on EUR-Lex, and the European Commission's regulatory framework page collects the related material; you find both in the sources at the end of this article.

The classification looks like a one-off job, but it has to be re-run when the system changes. That is why it belongs in the oversight process: that is where it is written down when to reclassify and who owns it.

Where does engineering end and legal advice begin?

The technical and organizational preparation is our work: classification with written reasoning, compliance documentation, human review points, logging, governance. The legal assessment and the question of legal liability stay with your legal counsel; the documentation is handed over in a form they can review. The two work well together: we build into the system what the category calls for, and they check it against the text in force.

Our team has been building production enterprise systems since 2013, has closed 46+ projects, and has experience implementing high-risk AI systems. If AI adoption is still ahead of you, our AI adoption guide for SMEs walks the steps from assessment to production; the risk classification happens at the start of the project there too. You tell us which AI systems you run or plan, and we tell you what the EU AI Act touches and what the preparation involves.