EU AI Act in Romania: What Software Exporters and AI Builders Must Do
How the EU AI Act applies in Romania — directly, no transposition. Why firms building AI for export carry provider duties under Article 16/25, plus penalties.
A 200-person software house in Cluj-Napoca builds a candidate-ranking module for a German recruitment platform, ships it under a tidy contract, and assumes the EU AI Act is its client's problem. It may not be. The obligations follow the product onto the EU market, not the location of the company that wrote the code — and depending on whose name the module carries and who controls its purpose, the Romanian builder can be the provider of a high-risk AI system. That is the question that matters most in Romania.
Romania's affected population is dominated by its software-outsourcing and product-export sector — firms whose code ships into Germany, France, the Nordics and beyond. So this guide spends less time on the name of the national regulator and more on provider exposure: when does building an AI feature for a foreign client turn you into a provider under Regulation (EU) 2024/1689, and what does that cost. Scope: this is a country guide for Romanian builders, deployers and exporters of AI systems, not legal advice on a specific contract.
Why this guide leads on the exporter angle, not the enforcer
Most EU AI Act country coverage opens with the same question: who is the regulator. For Romania that framing buries the lede. The decisive question for a Romanian software house is not "who enforces the Act here" but "when does writing an AI feature for a client in Munich or Stockholm make us a provider." The answer follows the product, not the company's registered office.
The Regulation is directly applicable in Romania under Article 288 TFEU. The deadlines are EU-wide and identical to every other Member State — they do not move because a firm sits in Bucharest rather than Berlin. That uniformity is precisely why this guide treats the national authority as a mechanism-only footnote and concentrates on the Article 25 provider trap that catches export-build work.
This is also where Romania differs from its neighbours. The Germany guide leads on a named authority, the KI-MIG law and Works Council co-determination; the Poland guide leads on a pending collegial body and a draft national Act. Romania's distinguishing feature is its export-facing tech economy and the provider exposure that comes with building AI for someone else's market.
A Regulation, not a directive: no Romanian transposition needed
Regulation (EU) 2024/1689 entered into force on 1 August 2024 and applies directly in Romania by virtue of Article 288 TFEU. No national statute is a precondition for the obligations to bite. A Romanian company does not wait for a Romanian law before the Act reaches it.
Several duties are already live. Article 5 prohibited practices have applied since 2 February 2025. Article 4 AI literacy obligations have applied since 2 February 2025. GPAI model obligations under Chapter V (Articles 51–55) have applied since 2 August 2025. These bind Romanian companies now, irrespective of where the national enforcement machinery stands.
What Romania must supply is enforcement infrastructure, not substantive law. Under Article 70, each Member State designates at least one national competent authority that also acts as a market surveillance authority, plus a single point of contact for the EU AI Office. This guide states the mechanism only — it does not assert a specific Romanian authority name. That designation should be confirmed against the official notification to the European Commission before being relied on. A missing or pending designation does not suspend obligations that already apply.
The provider trap: how Romanian outsourcing and product firms acquire obligations
The Act recognises several operator roles: provider, deployer, importer (Article 23) and distributor (Article 24). Most companies assume a deployer posture. Export-build work frequently lands somewhere heavier: the provider role, which carries the full obligation stack.
The four Article 25 triggers that convert a deployer or contractor into a provider
Article 25 converts an actor into a provider on any of the following: placing a high-risk system on the market under its own name or trademark; making a substantial modification to a high-risk system; or changing the intended purpose of a system so that it becomes high-risk. The related importer and distributor situations can also pull an actor across the line. For a Romanian software house, the first trigger is the one that bites most often.
White-label and own-name deployment: when your client's logo does not shield you
Building a high-risk AI component for a foreign client can make either the Romanian builder or the client the provider, depending on whose name it carries and who controls the intended purpose. If the module ships under the client's brand and the client sets its purpose, the client is more likely the provider. If you market it under your own name, or you define what it is for, you become the provider. Get this allocated explicitly in the build contract — silence in the contract does not default the risk to the larger party.
Substantial modification and fine-tuning on client or proprietary data
Fine-tuning a third-party model on a client's recruitment data, re-pointing a system at a new high-risk use, or materially reworking how it produces decisions can each count as a substantial modification or an intended-purpose change — enough to make the Romanian builder the provider even where the underlying model came from elsewhere.
A provider carries the full Article 16 stack: Article 9 risk management, Annex IV technical documentation, Article 14 human-oversight design, Article 43 conformity assessment, the Article 47 / Annex V Declaration of Conformity, and Article 49 registration — far heavier than a deployer's Article 26 duties. One accuracy guard: only stand-alone Annex III systems take the full Articles 8–15 / 16 / 43 stack directly. Annex I product-embedded AI routes conformity through sectoral acts — Section A via Article 43(3), Section B applying only a limited subset under Article 6(1) plus Articles 102–109 and 112. Do not over-state obligations for product-embedded work.
Which AI exports are high-risk — and which are not
Not everything a Romanian firm builds is high-risk. The classification turns on falling within an Annex III area and not qualifying for the Article 6(3) filter.
The Annex III categories most relevant to Romanian build work
For exporters, the categories that come up most are: Annex III point 3 education; point 4 employment (4(a) recruitment, 4(b) in-employment management); point 5 essential services (5(a) public benefits, 5(b) creditworthiness, 5(c) emergency triage, 5(d) life and health insurance); and point 1 biometrics. Romanian HR-tech, fintech and edtech builders touch these most often. Screen the hard prohibitions out first: Article 5(1)(f) bans emotion recognition in workplace and education contexts, and Article 5(1)(g) bans biometric categorisation that infers sensitive attributes. A build that does either cannot be sold into the EU regardless of how well it is documented.
What is NOT high-risk: ordinary analytics, ITSM and defensive security tooling
For the large IT-services slice of the Romanian economy, this is the reassurance that matters: ordinary business analytics, IT service management tooling, and defensive cybersecurity systems are not Annex III high-risk use cases. Building a dashboard, a ticket-routing engine or an intrusion-detection tool does not, by itself, drop you into the high-risk regime.
The Article 6(3) filter and the duty to document the assessment
A system inside an Annex III area may still escape high-risk classification if it meets one of the four Article 6(3) conditions: a narrow procedural task; improving the result of a completed human activity; detecting decision patterns without replacing or influencing human judgement; or a preparatory task. But the filter is not a free pass — the provider must document that assessment, and Article 49 registration still applies. The verdict has to be written down, not merely assumed.
Penalties and which entity carries them across a build-and-export chain
Article 99 sets three tiers. Each of the three is the higher of a fixed sum or a turnover percentage.
| Tier | Trigger article | Fixed amount | Percentage | Direction |
|---|---|---|---|---|
| Article 99(3) | Article 5 prohibition breaches | €35 million | 7% of total worldwide annual turnover | whichever is higher |
| Article 99(4) | High-risk requirements (Articles 8–15), provider obligations (Article 16), deployer obligations (Article 26), Article 50 transparency | €15 million | 3% | whichever is higher |
| Article 99(5) | Incorrect, incomplete or misleading information to notified bodies or authorities | €7.5 million | 1% | whichever is higher |
The third tier is 1%, never 1.5%. Article 99(6) is the only tier that flips this to the lower of the fixed sum or the percentage, and only for SMEs and start-ups — under 250 staff and turnover at or below €50 million, or balance sheet at or below €43 million. A Romanian micro-studio that has grown past those thresholds, or that is a subsidiary of a larger group, does not get the cap.
The allocation point is blunt: whichever entity is the provider for a given system carries the Article 16-linked exposure. The contract that assigns the provider role also assigns the penalty risk. A Romanian SME builder is neither automatically capped nor automatically shielded by its client's size.
The timeline that applies in Romania (identical to every Member State)
The dates do not shift because a Romanian firm sits outside the destination market. The product's placement on the EU market sets the clock.
Dates already live
Article 5 prohibitions and Article 4 literacy have applied since 2 February 2025. GPAI obligations under Articles 51–55 have applied since 2 August 2025. On 2 August 2026, general application begins, including Article 50 transparency for chatbots, deepfakes and synthetic media; the machine-readable content-marking duties apply from 2 December 2026.
The high-risk dates and the Digital Omnibus caveat
The statute date for stand-alone Annex III high-risk systems under Article 6(2) is 2 August 2026, now deferred to 2 December 2027 under the Digital Omnibus. Annex I product-embedded high-risk AI under Article 6(1) has a statute date of 2 August 2027, deferred to 2 August 2028. Both deferrals were adopted by the European Parliament on 16 June 2026 and the Council on 29 June 2026, and enter into force on publication in the Official Journal, expected before 2 August 2026. The prohibitions and GPAI obligations are not affected by any of this — they are already in force.
Worked example: a Cluj software house building HR-screening AI for a German client
NordCode SRL is a 180-person, roughly €22 million-turnover software-development firm in Cluj-Napoca. It is building a CV-screening and candidate-ranking module for a German recruitment platform. Here is the analysis NordCode should run.
Step 1 — classification. Candidate ranking for recruitment falls under Annex III point 4(a) employment. NordCode runs the Article 6(3) filter and documents the result. Ranking that materially influences hiring decisions is unlikely to qualify for the narrow-task exemption, so the realistic finding is high-risk.
Step 2 — role allocation. If the module ships under the German client's brand and the client sets the intended purpose, the client is likely the Article 25 provider. If NordCode markets it under its own name, or substantially defines its purpose, NordCode becomes the provider. The build contract must state this explicitly — this is the single most consequential clause in the engagement.
Step 3 — obligations if NordCode is the provider. The full stack applies: Article 9 risk management, Annex IV technical documentation, Article 14 human oversight, Article 43 conformity assessment, the Article 47 / Annex V Declaration of Conformity, and Article 49 registration.
Step 4 — sizing and penalties. At 180 staff and roughly €22 million turnover, NordCode is within the SME thresholds, so the Article 99(6) lower-of cap applies to it. But if NordCode were a subsidiary of a larger group, or grew past 250 staff, the cap would fall away.
Step 5 — timing. Build to the Annex III date: statute 2 August 2026, deferred to 2 December 2027 under the adopted Digital Omnibus. Treat the six to twelve months of documentation work as the real constraint, not the headline date.
How Confir helps
A Romanian exporter's compliance workload is documentation-heavy and contract-sensitive: classify each build, pin the provider or deployer role before delivery, and assemble the Annex IV pack for anything high-risk.
Confir is EU-hosted compliance tooling built for this work. Its classification engine is deterministic and rule-based — no model inference, no hallucination. It encodes Articles 5 and 6 with Annex III logic as explicit rules, so the same intake always produces the same finding with a human-readable explanation of which rule fired. Confir generates the Annex IV technical documentation pack and the Article 47 / Annex V Declaration of Conformity, runs the Article 27 Fundamental Rights Impact Assessment where a deployer needs one, and keeps an immutable audit log. Its GPAI workflow is partial and on the roadmap, not a finished compliance product.
What Romanian companies should do now
Immediately. Screen every AI build and deployment for Article 5 prohibitions — especially emotion recognition in workplace and education contexts and sensitive-attribute biometric categorisation. These are live and unconditional, and no documentation can cure them.
For exporters. Run the Article 25 analysis on every client engagement and pin the provider/deployer allocation in the contract before delivery. The clause that assigns the role assigns the liability.
Before 2 August 2026. Bring customer-facing AI — chatbots, generative tools, synthetic media — into Article 50 transparency, with machine-readable marking from 2 December 2026.
Through 2026–2027. Build the AI inventory, run Article 6 plus Annex III classification with a documented Article 6(3) filter, and begin Annex IV documentation for high-risk systems. Treat the adopted deferral to 2 December 2027 as runway, not relief.
Before naming the regulator. Confirm Romania's designated Article 70 authority and single point of contact against the official Commission notification before recording a name in any compliance file.
Related guides
- EU AI Act in Germany: enforcement and the KI-MIG
- EU AI Act in Poland: authorities and the draft Act
- every EU AI Act deadline, mapped
- EU AI Act compliance: where to start
- what is a market surveillance authority?
- EU AI Act extraterritorial scope
Manage your EU AI Act compliance in one place
Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 14-day free trial.
Start free trial →