Risk Classification Under the EU AI Act: How to Categorize Your AI Systems and What Compliance Obligations Apply in Romania

Q: Provider - "we built it, or we sell it under our name"

When you occupy this role: you develop an AI system, or place it on the market or into service under your own name - including "rebranding" a third-party system. The obligation that bites in practice: QMS, technical documentation, conformity assessment, post-market monitoring - particularly for high-risk systems. Common pitfall"We only integrated a third-party model" - but you sell it under your own brand. That's provider territory.

Q: Deployer - "we use it under our own authority"

When you occupy this role: you use an AI system under your own authority, internally or externally. The obligation that bites in practice: use in accordance with instructions, human oversight, logging and monitoring - for high-risk systems. Common pitfall Repurposing the system: moving it from "analytics" to "decision-making" changes the classification - and can change your role.

Q: Importer - "the vendor is non-EU, we bring it to the EU market"

When you occupy this role: you place on the EU market an AI system developed by a non-EU provider. The obligation that bites in practice: conformity verification, document retention, notifications to competent authorities. Common pitfall"The vendor is non-EU, but we're the ones distributing it in the EU" - that makes you the importer, with independent obligations.

In most organizations, the AI inventory looks something like this: a "support" chatbot, a scoring model used "just for prioritization," a workplace productivity-monitoring tool, and a handful of low-code automations in HR or finance. The problem surfaces the moment a board member or auditor asks the one question every governance framework eventually forces: which risk category does each system fall into, and what, concretely, are we required to do about it?

Regulation (EU) 2024/1689 (the "EU AI Act") establishes a risk-based regulatory framework and allocates distinct legal obligations by role - provider, deployer, importer, and distributor. A misclassification is not merely a labeling error: it can trigger a cascade of compliance requirements - a quality management system (QMS), conformity assessment, technical documentation, event logging, and post-market monitoring - or, in the most serious cases, mean that an organization is engaged in a prohibited AI practice.

This article sets out a practical risk-classification framework (decision steps, screening questions, and worked examples), explains the obligations attached to each risk tier, and adds guidance on general-purpose AI (GPAI), the interplay with the GDPR, and considerations specific to Romania.

risk tiers: prohibited, high-risk, limited (transparency), minimal

prohibited practices - 8 applicable since Feb 2025, a 9th from Dec 2026

2 Dec 2027

general date from which core high-risk obligations apply for certain categories

2–4

weeks - a realistic AI inventory and risk-classification sprint

EU AI Act risk classification: five key points for boards and GCs

Classification is use-case-first, not technology-first
Identical technology can carry entirely different legal obligations depending on its purpose and deployment context.
Prohibited practices have no compliance path
Where a use case is prohibited, the only response is stop and redesign - no checklist makes it acceptable.
High-risk status turns on impact, not on "using AI"
What matters is the effect on access to employment, education, credit, or essential services - not the mere presence of ML or an LLM.
Roles decide accountability - and you can become a "provider by accident"
Rebranding a third-party system or changing its intended purpose can shift your obligations dramatically.
The AI Act does not replace the GDPR
High-risk projects typically require a DPIA, aligned transparency notices, and an Article 22 analysis wherever automated decision-making is involved.

Quick glossary: the terms you'll need for classification

Expand each term for the working definition used throughout this framework:

AI system

Software that receives an input (data, text, images, etc.) and generates an output (predictions, recommendations, decisions, or content) with some degree of autonomy - as distinct from, say, a static rules engine or a conventional search function.

Use case / intended purpose

The declared purpose of a system and how it is actually deployed - in which process, for which decision, and with which users. Under the AI Act, classification turns on the use case, not merely the underlying technology.

Provider

The entity that develops an AI system, or that places one on the market or puts it into service under its own name or trademark - including where it "rebrands" a third-party system.

Deployer

The entity that uses an AI system under its own authority, whether internally or in providing services to clients.

High-risk AI system

A system used in sensitive domains (e.g., recruitment, credit scoring, education, biometrics) subject to a robust conformity-assessment and compliance regime.

Limited risk (transparency obligations)

Uses (e.g., chatbots, deepfakes) where the principal obligation - under Article 50 - is to clearly disclose to end users that they are interacting with an AI system or viewing AI-generated content.

GPAI (general-purpose AI)

General-purpose AI models (e.g., large language models) used as a platform underpinning multiple downstream applications - subject to a dedicated regime supervised at EU level via the European AI Office.

The four-tier risk pyramid - and the "use-case-first" logic behind it

"You start from how the AI is deployed within a given process, not from the underlying model architecture. The same model or technology can carry entirely different legal obligations depending on its purpose and deployment context."

- The core classification principle of the EU AI Act

The EU AI Act risk hierarchy at a glance

Who does what (simplified): the provider builds and/or places the system on the market and is responsible for assembling the compliance "package"; the deployer uses the system in accordance with its intended purpose, exercises human oversight, and retains evidence and monitoring records.

Step 0 - Determine whether you actually have an "AI system"

Before classifying anything, confirm whether what you have is legally an AI system within the meaning of the AI Act - as opposed to, say, a static rules engine or a conventional search function. Useful reference points include the European Commission's AI system definition and guidance, and your own internal system documentation: architecture, input/output specification, components, and the degree of autonomy and adaptiveness.

Why this matters

If a system falls outside the statutory definition, the AI Act itself may not apply - though GDPR, cybersecurity law, and consumer-protection law can still be relevant. Document the conclusion either way: "not an AI system" is itself a classification decision an auditor will ask about.

Step 1 - Screen first for "unacceptable risk" (prohibited AI practices)

Effective classification works top-down: start by checking whether the use case falls within a prohibited practice. The European Commission lists nine prohibited practices - eight applicable since February 2025, with a ninth added from December 2026 under the AI Omnibus amendment. The rapid screening questions:

Manipulation or exploitation of vulnerabilities
Does the system manipulate or deceive users, or exploit the vulnerabilities of specific groups (e.g., children, vulnerable individuals) in a manner likely to cause harm?
Social scoring
Does it classify individuals in ways that produce disproportionate or unjustified adverse effects?
Emotion recognition at work or in education
Does it perform emotion recognition in the workplace or in educational institutions?
Biometric categorization of protected characteristics
Does it infer legally protected characteristics from biometric data?
Untargeted facial-image scraping
Does it scrape facial images indiscriminately to build or expand facial-recognition databases?
Real-time remote biometric identification in public spaces
For law-enforcement purposes - subject to the AI Act's narrow exceptions.

An illustrative Romanian example

An employer seeking to deploy webcam-based emotion recognition during working hours to assess employee "engagement" is a strong signal of a prohibited practice - particularly in the employment context - not merely a high-risk classification. There is no compliance checklist that makes it acceptable: halt use or block procurement, redesign the process, and document the decision with a clear audit trail.

Steps 2–4 - High-risk, limited risk, minimal risk

Step 2 - Test for high-risk (primarily Annex III)

Does the system make, or materially support, decisions affecting access to employment, credit, education, or essential services? Does it use biometric data in sensitive contexts? Is it used by or with public authorities or judicial functions? Typical examples: automated CV screening or candidate scoring (HR), credit scoring capable of resulting in loan refusal, exam scoring that determines access to programs, remote identity verification as a condition of accessing services.

Step 3 - Check for limited risk (Article 50 transparency)

Does the system interact directly with individuals (chatbot, voice bot)? Does it generate or manipulate content that could plausibly appear authentic (deepfakes)? Are you publishing AI-generated text on matters of public interest? If yes, clear disclosure obligations apply - the Commission has published dedicated implementation guidelines for Article 50.

Step 4 - Minimal/no risk (but governance still applies)

Most benign internal use cases - code-completion assistance, internal summarization without external publication, document classification with no impact on individuals - fall here. "Minimal" does not mean "no governance": you still need an AI inventory, internal policies, information security controls, vendor management, and GDPR compliance where applicable.

The quick classification test for internal workshops: (1) Could it affect fundamental rights or safety? If yes → check for high-risk status. (2) Is it explicitly prohibited? If yes → stop and redesign. (3) Does it interact with individuals, or produce content that "could pass as real"? If yes → transparency obligations. (4) Purely internal support with no material external effect? → minimal risk, governance still applies.

Quick test: classify the system

Four systems from a typical corporate AI inventory. Pick the risk tier you think is right:

System 1: A webcam-based tool that analyzes employees' facial expressions during working hours to score their "engagement" for management.

Prohibited. Emotion recognition in the workplace is on the prohibited-practices list - this is not a high-risk system with a heavier checklist, it's a practice that cannot be deployed in the EU. Stop, redesign the process, and document the decision.

System 2: An ML model that screens incoming CVs and produces a ranked shortlist that recruiters "almost always" follow.

High-risk. Recruitment is an Annex III domain, and a system that materially supports access-to-employment decisions is a textbook candidate - "just for prioritization" doesn't help when recruiters follow the ranking in practice. Full compliance package before go-live: risk management, data governance, logging, human oversight, technical documentation.

System 3: A customer-support chatbot on the company website, answering product questions with no decision-making role.

Limited risk. Not high-risk - but direct interaction with individuals triggers Article 50: users must be clearly informed they are interacting with an AI system ("You are interacting with an AI system", plus a link to further explanation). "Not high-risk" is not the same as "nothing to do."

System 4: A code-completion assistant used by the internal development team; output is reviewed by engineers and never published as-is.

Minimal risk. Internal support with no material external effect on individuals. No AI Act-specific requirements - but it still belongs in the AI inventory, under acceptable-use policies, vendor due diligence, and information-security controls. AI literacy remains a cross-cutting obligation.

These are screening calls, not legal conclusions

The same system can land differently depending on intended purpose, deployment context, and who relies on its output. Each real system needs a documented classification record. Book an AI inventory and classification sprint.

Value-chain roles: provider, deployer, importer, distributor - and the pitfalls of inadvertent reclassification

A recurring source of internal confusion: the same organization can simultaneously be a deployer of a purchased tool and a provider of an internally built solution made available to other group entities or external clients. The relevant provisions: provider obligations (Article 16), deployer obligations (Article 26), importer obligations (Article 23), distributor obligations (Article 24), transparency obligations (Article 50). Expand each role:

Provider - "we built it, or we sell it under our name"

When you occupy this role: you develop an AI system, or place it on the market or into service under your own name - including "rebranding" a third-party system.

The obligation that bites in practice: QMS, technical documentation, conformity assessment, post-market monitoring - particularly for high-risk systems.

Common pitfall"We only integrated a third-party model" - but you sell it under your own brand. That's provider territory.

Deployer - "we use it under our own authority"

When you occupy this role: you use an AI system under your own authority, internally or externally.

The obligation that bites in practice: use in accordance with instructions, human oversight, logging and monitoring - for high-risk systems.

Common pitfall
Repurposing the system: moving it from "analytics" to "decision-making" changes the classification - and can change your role.

Importer - "the vendor is non-EU, we bring it to the EU market"

When you occupy this role: you place on the EU market an AI system developed by a non-EU provider.

The obligation that bites in practice: conformity verification, document retention, notifications to competent authorities.

Common pitfall"The vendor is non-EU, but we're the ones distributing it in the EU" - that makes you the importer, with independent obligations.

Distributor - "we're just a reseller"

When you occupy this role: you make an AI system available on the market without being its provider or importer.

The obligation that bites in practice: pre-distribution checks and response to non-conformities.

Common pitfall
Assuming you're "just a reseller" - while carrying independent legal obligations of your own.

Obligations by risk tier - and the application dates to internalize

Unacceptable risk: "stop and redesign"

Halt use or block procurement; redesign the process (non-AI mechanisms, or an AI configuration outside the prohibition); document the decision itself, preserving a clear audit trail.

High-risk: robust obligations before go-live

Risk management, dataset quality and governance, logging, technical documentation, information for deployers, human oversight, robustness/cybersecurity/accuracy. In parallel, market surveillance authorities hold extensive investigatory powers - including access to technical documentation, datasets, and, where strictly necessary, source code.

Limited risk: "state clearly that it is AI"

Chat/voice interfaces: a clear notice plus a link to further explanation. Deepfakes: a persistent watermark or label and an audio/video disclaimer. Published AI-generated text: a genuine, documented editorial review process where reliance on the Regulation's exemptions is intended.

Minimal risk: governance still applies

An AI inventory; internal acceptable-use policies; AI literacy training (a cross-cutting obligation under the Regulation); vendor due diligence; information security and access controls.

February 2025 - eight prohibited practices apply

The first tranche of prohibitions has been in force since February 2025 - screening your inventory against them is not a future exercise.

December 2026 - a ninth prohibition (AI Omnibus amendment)

An additional prohibited practice enters into application - inventories screened in 2025 should be re-screened against the updated list.

December 2, 2027 - core high-risk obligations for certain categories

The Commission indicates this as the general date from which core high-risk obligations apply for certain categories - but the compliance build (documentation, logging, oversight design) takes months, and contracts signed today should already allocate AI Act responsibilities.

Interactive: the high-risk compliance checklist

For each system classified (or plausibly classifiable) as high-risk, tick every element that exists today - implemented and documented, not merely planned:

High-risk readiness - nine elements supervisors will ask about

Your role is identified (provider vs. deployer) and contractual responsibilities are delineated accordingly
The intended purpose is defined, with its limits and excluded contexts of use
A risk-management process spans the full system lifecycle
Data governance controls are in place: bias mitigation, representativeness, data quality
Logging and traceability are implemented, with defined retention periods
Technical documentation and instructions for use are prepared
Human oversight is designed: who intervenes, how, and under what conditions the system is halted
The system is tested for accuracy, robustness, and cybersecurity resilience
Post-market monitoring and an incident-management process are operational

Every gap here is a question a market surveillance authority can ask - with document access powers

Supervisors can request technical documentation, training and testing datasets, and, where strictly necessary, source code. "We'll document it if asked" is not a strategy when the request arrives with a deadline. Get a gap analysis of your high-risk systems.

General-purpose AI (GPAI): when the model is a platform, not an application

The GPAI regime is supervised at EU level, with the European AI Office playing a central coordinating role. For implementation, the Commission promotes the General-Purpose AI Code of Practice as a voluntary instrument for demonstrating compliance across transparency, copyright, and safety-and-security obligations.

If you are a deployer of a GPAI model

E.g., using an LLM in internal processes. Focus on: transparency toward end users, data protection, information security, prompt/data governance, prevention of data leakage, and clear internal usage rules.

If you are a provider of applications built on GPAI

You need contracts and documentation that trace obligations from the underlying model to your downstream system: model cards, instructions for use, stated limitations, and testing evidence.

The EU AI Act is complementary to the GDPR, not a substitute for it. In practice, many high-risk AI systems are simultaneously high-risk processing operations for GDPR purposes - involving profiling, decisions with legal or similarly significant effects, or special-category data.

Reference points

Article 22 GDPR governs decisions based solely on automated processing that produce legal or similarly significant effects. EDPB Opinion 28/2024 is the European Data Protection Board's official opinion addressing data-protection aspects of AI models - including the relevance of Article 22 and core GDPR principles.

How to combine the two frameworks without duplicating work: conduct a single, integrated assessment - an AI risk assessment alongside a GDPR DPIA - with separate chapters but a shared factual record; align transparency notices across both frameworks (AI Act obligations and GDPR Articles 13/14) into one coherent user-facing communication; and, wherever profiling or automated decision-making is involved, verify whether Article 22 is triggered and confirm a legal basis or exemption, with adequate safeguards: meaningful human review, the right to contest a decision, and a right to explanation.

Romania-specific considerations: authorities, implementation, penalties

Market surveillance under the AI Act is a new institutional architecture, distinct from the National Supervisory Authority for Personal Data Processing (ANSPDCP), which remains competent for GDPR matters. Romania's designation of competent market surveillance authorities has been under discussion at government level. The most reliable approach for companies in the meantime:

Monitor the Commission's list of Single Points of Contact (SPOCs)
For market surveillance - this is where Romania's designations will surface.
Treat ANSPDCP as the interlocutor for all GDPR-related matters
DPIA, legal basis, data-subject rights - the GDPR track doesn't wait for the AI Act's institutional setup.
Prepare an evidence pack that can be produced on request
Risk classification record, technical documentation, logs, vendor documentation - particularly for high-risk systems.

Penalties are significant

The AI Act provides for substantial administrative fines under Article 99 - with the highest bands attached to prohibited practices. The cost asymmetry is the practical argument for classification-first: a 2–4 week inventory sprint is cheap insurance against building on a use case that must later be shut down.

How Buju, Stanciu & Asociații structures AI Act engagements

The difference between "having a policy" and "being compliant" lies in translating legal requirements into concrete architecture decisions, operational processes, and contractual terms. BSA typically structures this work across four parallel workstreams:

1. Inventory and classification

Structured workshops with IT, Information Security, the DPO, and HR/Compliance teams to produce an AI systems register, use-case fact sheets, and a documented risk classification - including screening for prohibited practices and Article 50 transparency obligations.

2. Governance and role allocation

A RACI matrix mapped across the AI value chain (provider/deployer/importer/distributor), AI usage policies, AI literacy programs, incident-management procedures, and audit-trail design.

3. High-risk / limited-risk compliance package

Technical documentation, transparency measures, logging, human oversight design, post-market monitoring, and preparation for information requests from competent authorities.

DPIAs, legal-basis analysis, data-subject notices, Article 22 assessments, and vendor contracting - including international data transfer mechanisms where applicable.

Key takeaways (suitable for a board deck)

Classification is use-case-first
Identical technology can carry entirely different legal obligations depending on purpose and deployment context.
Prohibited means stop and redesign
No compliance checklist renders a prohibited practice acceptable.
High-risk turns on impact on employment, education, credit, or essential services
Not on the mere fact that ML or an LLM is being used - and limited risk means clear labeling and disclosure.
Value-chain roles determine accountability
An organization can become a "provider" inadvertently, through rebranding or a change in intended purpose.
The AI Act does not replace the GDPR
High-risk projects typically require a DPIA, GDPR-compliant transparency notices, and an Article 22 analysis wherever automated decision-making is involved.

Frequently asked questions

How can I quickly determine whether a system qualifies as "high-risk"?

If an AI system is used to make or materially support decisions in sensitive domains - recruitment or employee management, credit scoring, education, biometrics, or essential services - treat it as a candidate for high-risk classification and verify it against the categories in the Commission's official guidance and Annex III of the Regulation.

Is a customer-support chatbot automatically "minimal risk"?

Not necessarily. Even where a chatbot is not high-risk, direct interaction with end users frequently triggers Article 50 transparency obligations (limited risk): users must be clearly informed that they are interacting with an AI system.

What is the difference between a provider and a deployer?

The provider develops the system or places it on the market under its own name - including rebranding a third-party system - and owns the compliance package. The deployer uses the system under its own authority, with human oversight and logging. The same organization can hold both roles simultaneously for different systems.

Can a prohibited practice be made compliant with extra safeguards?

No. Where a use case falls within a prohibited practice, no compliance checklist renders it acceptable. Halt use or block procurement, redesign the process, and document the decision with a clear audit trail.

Does the EU AI Act replace the GDPR?

No - it is complementary. Many high-risk AI systems are simultaneously high-risk processing operations under GDPR, typically requiring a DPIA, aligned transparency notices, and an Article 22 analysis for automated decision-making. EDPB Opinion 28/2024 addresses AI models directly.

Who supervises AI Act compliance in Romania?

Market surveillance under the AI Act is a new institutional architecture, distinct from ANSPDCP (which remains competent for GDPR). Romania's designations have been under discussion at government level - monitor the Commission's SPOC list, keep ANSPDCP as the GDPR interlocutor, and maintain a producible evidence pack.

How can BSA support EU AI Act compliance in Romania?

Through AI inventory and risk classification, value-chain role mapping, compliance documentation and processes (including high-risk systems and Article 50 obligations), GDPR integration (DPIA, transparency, Article 22), and contractual alignment with AI vendors. Get in touch.

From "we know we use AI" to "we know precisely what our obligations are"

The most practical next step is an AI inventory and risk-classification sprint (typically 2–4 weeks): a systems register, use-case fact sheets, role mapping, and a remediation plan organized by risk category - aligned with GDPR requirements throughout, and calibrated to Romania's evolving 2025–2026 implementation landscape.

Sources and references

Regulation (EU) 2024/1689 (EU AI Act): EUR-Lex · European Commission - AI Act policy page (risk tiers, prohibited practices, high-risk categories, application dates, market surveillance authorities, GPAI Code of Practice, Article 50 transparency guidelines): digital-strategy.ec.europa.eu · AI Act Explorer - article-by-article consolidated text (Articles 16, 23, 24, 26, 50, 99): artificialintelligenceact.eu · EDPB - Opinion 28/2024 on data-protection aspects of AI models: edpb.europa.eu · GDPR (Regulation (EU) 2016/679), incl. Articles 13, 14, 22: EUR-Lex · ANSPDCP - Romania's data protection authority: dataprotection.ro · Buju, Stanciu & Asociații (BSA): bsa.ro

Disclaimer: This article is for general informational purposes only and does not constitute legal advice. Its application depends on the specific facts, systems, and business model of each organization; a dedicated legal analysis is required for a formal opinion.