The EU AI Act in Bulgaria: What Binds Your Bulgarian Entity Now

The question arrives in a particular form, usually from a group risk or legal function: does our Bulgarian entity need its own AI Act work, or does the group programme already cover it? The honest answer is that the group programme almost certainly does not cover it, and the reason is structural rather than a matter of effort.

Obligations under the AI Act attach to the legal person that supplies or deploys a system. Not to the group, not to the parent, not to the function that wrote the policy. A Bulgarian subsidiary, shared-service centre or development site is a deployer in its own right, and in more cases than most groups expect it is a provider too.

What already applies, as of September 2026

Regulation (EU) 2024/1689 entered into force on 1 August 2024 and applies in stages. It is a Regulation, so it binds the Bulgarian entity directly — there is no national transposition to wait for, and no local implementing act that could soften it.

The last two dates moved under the Digital Omnibus, in force since 27 July 2026. What moved was the application dates — not the obligations, not the classification rules, and not the work they require. The Commission maintains the current position on its AI Act page and the article-by-article sequence sits in the AI Act Service Desk implementation timeline. What that deferral did and did not change is covered separately in the high-risk delay note.

A group policy is not a deployer’s measures

Article 4 requires providers and deployers to take measures on AI literacy for their staff and for others operating systems on their behalf, calibrated to those people’s knowledge, experience, education and training, to the context of use, and to the people the systems are used on.

Two things about this article are worth knowing before it is quoted in a contract or a group standard. First, it has applied since February 2025 and is not tied to the high-risk timetable — the deferral to December 2027 defers nothing here. Second, the Digital Omnibus rewrote it: the requirement is simplified, with the Commission and member states taking a larger role in promoting AI literacy, as the Commission itself describes it. As of 10 September 2026 the Service Desk page for Article 4 still displays the pre-Omnibus text under an explicit notice that it has not been updated. Anyone still quoting “ensure a sufficient level” is quoting superseded wording, and the difference between ensuring a level and taking measures is the difference between an obligation of result and an obligation of effort.

Either way, the duty sits on the entity that deploys. A group AI policy signed in London, Munich or Paris is evidence that measures exist; it is not itself the measure, and it does not answer the only question a supervisor will ask — who in Sofia or Plovdiv uses what, for what, and what were they told about it.

The shared-service centre problem

The provider/deployer distinction decides the weight of everything else, and groups with Bulgarian operations tend to cross it in the same place. The Bulgarian entity is frequently where a bought tool gets adapted — connected to internal data, tuned to local process, pointed at a workflow the vendor never described.

Article 25 sets out when a third party is treated as the provider of a high-risk system. Three of the triggers are reachable without writing a line of code:

• Own name or trademark. Putting your name or mark on a high-risk system already placed on the market, absent a contractual allocation that says otherwise.
• Substantial modification. Substantially modifying a high-risk system that remains high-risk.
• Change of intended purpose. Changing the intended purpose of a system so that it becomes high-risk — including where it was not high-risk before.

The third is the one that catches groups. A general assistant, tuned on internal data and pointed at recruitment screening or creditworthiness assessment, has changed its intended purpose. The entity that did that is the provider, with conformity assessment, technical documentation, a quality management system and post-market monitoring attached — and the entity that did it is usually the local one, acting on a group instruction, without anyone treating the moment as a legal event.

The answer is given per system, never once for the company. The same entity can be a deployer of one tool, a provider of a second, and out of scope for a third.

Supervision in Bulgaria is still settling

Article 70 requires member states to designate national competent authorities — a notifying authority and a market surveillance authority — and a single point of contact. Article 57 required at least one national regulatory sandbox by 2 August 2026, a deadline now past.

Here is the thing most summaries leave out: which Bulgarian authority supervises which system is not a question an article can answer reliably, and the picture is still moving. The practical conclusion does not depend on the answer. The obligations come from a directly applicable Regulation; designating the authority settles who you report to, not whether you owe anything.

Check the position at source rather than through commentary — single points of contact and national measures are published by the Commission, not by consultancies. If a contract, a group risk register or a board paper turns on who the competent authority is, that is a reason to confirm it on the date you sign, not to carry forward a note written months ago.

The support measures, and why a subsidiary rarely qualifies

Article 62 gives SMEs, including start-ups established or with a branch in the Union, priority access to regulatory sandboxes, with conformity assessment fees reduced in proportion to size, alongside training, dedicated communication channels and easier participation in standardisation. Since July 2026 the Omnibus extends measures previously reserved for SMEs to small mid-cap companies, and adds an EU-level sandbox alongside the national ones.

For a subsidiary of a larger group, read that with care. The EU’s SME test looks at the enterprise together with the undertakings linked to it, not at the local payroll — so a 200-person Bulgarian entity inside a 6,000-person group is generally not an SME for this purpose, whatever it looks like locally. Independent Bulgarian mid-market companies are the ones this was written for, and the mid-cap extension brings more of them inside it. Test the threshold against the definition that applies rather than against headcount at the Sofia office.

What is not deferred at all

The most expensive assumption after “this is a 2027 problem” is that nothing else applies while the AI Act waits. The GDPR applies now, independently of the AI Act timetable, and the Commission for Personal Data Protection is the supervisory authority for personal data processing in Bulgaria. The European Data Protection Board holds the Union-level position.

A system processing personal data without a lawful basis is not protected by a 2027 date. Automated decisions with significant effects on people carry their own requirements today. Deferring the data work defers nothing that the AI Act granted — it defers something already owed.

Where preparation starts

Order matters, because documentation written against the wrong classification is rewritten rather than corrected.

1. An inventory, by legal entity. What AI is actually in use in the Bulgarian entity, including what is embedded in bought software that nobody internally calls AI. This is where the underestimate lives, and a group-level inventory that stops at approved vendors will miss it.
2. A role for each system. Provider or deployer, tested against Article 25, with the reasoning written down — and recorded against the entity, not the group.
3. Provisional classification. Which systems plausibly fall under Annex III or Annex I. Revisit when classification guidelines are issued.
4. The long-lead items. Data provenance, traceability and human oversight that is real rather than nominal. These are engineering changes, not documents, and they cost substantially more after deployment.
5. What is already unlawful. Prohibited practices and data protection breaches are exposure today, not in 2027.

For pace and capacity — who does this work when there is no dedicated AI function — see sequencing adoption to the team you have. For what data readiness looks like in practice, the nine checks give the concrete list.

What this note cannot do

It does not classify your systems. Classification turns on facts — intended purpose, deployment context, role — and in borderline cases needs legal advice against the consolidated text. Nor is it a complete map of supervision: national designations and classification guidelines are still developing, and the harmonised standards that application depends on are still being drafted.

What can be said with confidence is narrower and more useful. The direction of the obligations has not changed. The earliest and hardest work does not depend on the deferred dates. And a group that cannot produce an inventory of the AI systems running in its Bulgarian entity has a problem that no deferral will solve.

Further reading: EUR-Lex: Regulation (EU) 2024/1689; European Commission: AI Act; European Commission: AI Omnibus enters into force; AI Act Service Desk: implementation timeline; Commission for Personal Data Protection; European Data Protection Board.

If the first step — the inventory and the role for each system — is where it stalls, the AI readiness and governance assessment builds exactly that view in five days.