Artificial intelligence governance
The first question is not which tool to buy, but what is already running in the house. We inventory the systems, classify them by risk and set rules that can actually be applied.
The scope of obligations depends on the role
The scope of obligations under the AI Act depends on whether you are a provider or a deployer.
The AI Act, Regulation EU 2024/1689, applies directly in Croatia and does not need transposing into national law. Its approach is risk based, with four categories: unacceptable risk, which is prohibited, high risk, limited risk with transparency obligations, and minimal risk.
Most organisations are deployers, that is they use a finished tool within their professional activity. You become a provider if you place a system on the market under your own name. Article 25 calls for caution: a deployer also becomes a provider if it puts its own name on a high-risk system, substantially modifies it, or repurposes it for a high-risk use.
The obligation already in force and most easily overlooked is AI literacy, under Article 4 of the Act, in force since 2 February 2025. There is no direct fine for it, but it is taken into account in supervision. The prohibited practices of Article 5 are in force from the same date, and they carry the highest fine in the Act.
Our work is to establish first what you actually use, in what role and in what risk category, and only then to write rules. Without an inventory of systems, every rule is written blind.
This page is about the work. The risk categories, the roles, the application deadlines, the fines and the state of Croatian implementation are set out on the page on the AI Act.
How we set up governance
Seven steps that turn the Act into a handful of decisions and one inventory.
Inventory of AI systems in use
Including those nobody formally introduced but which are being used. The inventory is tied to the asset inventory of measure 2 of Annex II to the Cybersecurity Regulation, so it is not kept twice.
Determining the role for each system
For each system we establish whether you are a provider or a deployer. We check Article 25 in particular, because putting your own name on a system, substantially modifying it or repurposing it for a high-risk use changes the role, and with it the scope of obligations.
Classifying by risk level
We go through Annex III and Annex I and establish the category for each system. Most office tools are not high risk but do carry transparency obligations, and that is recorded too.
Rules of use and human oversight
We write a rule that says what is allowed, what is not, and who checks the output before it is acted on. Oversight of outputs is not a formality: it is the difference between a tool that helps and a tool that decides for you.
Transparency obligations
Where a system interacts directly with people, that must be stated unless it is obvious. Content generated or substantially modified by a machine must be labelled. That translates into concrete changes to your interfaces and documents.
AI literacy
Article 4 requires a sufficient level of literacy among staff. That is not a general course but short training tied to the systems your people actually use and the decisions they take on the back of them.
Connecting it to data protection and security
The system inventory is part of the asset register, the risk assessment uses the same matrix, and where a system processes personal data it usually calls for a data protection impact assessment as well. Run separately, the work gets done three times.
Frequently asked questions
The questions we are asked most often before we start.
We only use public tools. Does this concern us?
It does. The deployer role carries obligations, among them a sufficient level of staff literacy, oversight of outputs and transparency towards those interacting with the tool.Are we a provider or a deployer?
Most often a deployer, because you buy the tool ready made. You become a provider if you place a system on the market under your own name, substantially modify it, or repurpose it for a high-risk use, under Article 25. The role determines the scope of obligations, so it is the first thing we establish.Do we need a fundamental rights impact assessment?
It is required of some deployers of high-risk systems, public authorities among them. If you use a high-risk system, that is one of the first things we check, because it is carried out before the system is put into use.How does this connect to the Cybersecurity Act?
The inventory of AI systems is part of the asset register under measure 2, the risk assessment uses the same matrix as measure 3, and where the system processes personal data it usually calls for a data protection impact assessment as well. Run separately, the work gets done three times, and nobody later reconciles the differences between the registers.Do we have to report an incident involving an AI system?
Providers of high-risk systems have a serious incident reporting duty under Article 73, with deadlines that depend on the severity of the consequence. Where the incident is also a cyber incident or involves personal data, the deadlines under the Cybersecurity Act and the General Data Protection Regulation run in parallel.Should we ban AI tools?
That is rarely a good answer, because banned tools get used anyway, just without a trail. What works better is a clear list of permitted tools, a rule on what may be put into them, and a duty for someone to check the output before it is acted on.Where to go next
Neighbouring topics, because artificial intelligence rarely turns up on its own.
From the blog: artificial intelligence
The three latest texts on AI threats and AI governance.
Let us start from a list of what you already use.
Half an hour, no obligation. We go through which systems you have, what role you are in and which of them carry obligations.