AI Regulation for Romanian Companies: A Practical Compliance Guide

Artificial intelligence is already part of ordinary Romanian business. A bank ranks applications, a retailer personalizes offers, a manufacturer predicts maintenance, a shared service centre summarizes calls, an employer filters CVs, and a finance team extracts information from invoices. Many companies also use generative assistants through productivity software without a separate technology project. The practical question is no longer whether your company uses AI. It is whether you know which systems are in use, what information they receive, whose interests they affect, and what evidence you can produce when a customer, employee, regulator, auditor, or business partner asks.

This guide is for Romanian company directors, legal and privacy teams, HR and procurement leaders, product owners, security professionals, and operations managers. It describes the position as of September 2026 and is practical business guidance, not legal advice. The EU AI Act, GDPR, Romanian implementing measures, sector rules, and regulator interpretations must be checked against the facts of each deployment. Pay particular attention to the role your company plays, the location of affected people, the sector, and whether a supplier or customer contract adds requirements.

The legal position in plain English

Romanian companies do not wait for a standalone Romanian artificial intelligence code before acting. Regulation (EU) 2024/1689, the EU Artificial Intelligence Act, is directly applicable as an EU regulation. It entered into force on 1 August 2024 and has a staged timetable. Definitions, prohibited practices, and the AI literacy obligation have applied since 2 February 2025. Governance provisions, penalties, and general-purpose AI model obligations started applying on 2 August 2025. The main body of obligations applies from 2 August 2026, with some product-related high-risk rules applying from 2 August 2027. Check Article 113 and the consolidated text for the exact transition and any later amendments.

The Act uses a risk-based architecture. Some practices are prohibited. Certain systems are high risk and carry detailed duties. Some interactive, emotion recognition, biometric categorisation, and generated-content uses have transparency duties. Other systems may not have a special AI Act obligation, but they remain subject to GDPR, consumer, employment, safety, intellectual property, cybersecurity, financial, and contract law. A general purpose model provider has obligations that differ from an enterprise deploying a model inside a customer workflow.

Keep a legal register with clear labels. A directly applicable EU regulation and an enacted Romanian law are binding law. A Romanian government memorandum about proposed authorities is an implementation step, not itself a complete private-sector compliance code. ANCOM web information is useful official information about the developing framework, while a Commission guideline, EDPB opinion, voluntary code, technical standard, or industry framework should be labelled guidance unless incorporated into a contract or binding instrument. A bill, consultation, strategy, parliamentary resolution, or proposed amendment is a proposal or policy document until it becomes applicable law. Future dates should remain future dates in your register.

Romania’s national implementation framework

Article 70 of the AI Act requires every Member State to designate at least one notifying authority and at least one market surveillance authority. A market surveillance authority must also act as the national single point of contact. Authorities must act independently, impartially, and without bias and have adequate technical, financial, and human resources. National law must also provide the institutional arrangements and sanctions needed for effective application.

As reported by ANCOM in its official AI Act implementation materials in 2026, the Romanian Government memorandum identifies ANCOM as proposed market surveillance authority and national single point of contact. The Authority for the Digitalisation of Romania, or ADR, is identified as the notifying authority for conformity assessment bodies. The memorandum also identifies sectoral roles for the National Bank of Romania and the Financial Supervisory Authority in relevant financial services, the National Supervisory Authority for the Processing of Personal Data in specified biometric, justice, migration, and border contexts, and other authorities responsible for regulated products and sectors.

This distinction matters. The memorandum and ANCOM’s public explanation show the direction of Romania’s implementation and help companies prepare for the right supervisory contacts. They do not remove duties already contained in the directly applicable AI Act, GDPR, or sector legislation. ANCOM has stated that the national legislative framework is still being developed to establish powers, cooperation mechanisms, and the applicable sanctioning procedure. Monitor the official ANCOM AI pages, ADR, the Romanian Government, and the European Commission’s list of notified authorities for changes. Record the last review date and do not state that a draft institutional arrangement is final law.

Who is in scope?

Do not decide scope by looking only at where a model provider is incorporated. The AI Act can apply to providers placing an AI system or general purpose AI model on the EU market, deployers using a system in the EU, providers and deployers outside the EU where the output is used in the EU, importers, distributors, product manufacturers, authorised representatives, and affected operations. A Romanian subsidiary can therefore have duties even when the model, hosting company, or parent organisation is elsewhere.

For every use, identify your role. A Romanian software company that develops a recruitment model may be a provider. A company configuring a third-party model to make decisions for its own staff is generally a deployer, but could become a provider if it places the system on the market under its name or makes a substantial modification. A manufacturer incorporating AI into a regulated product may have combined responsibilities. A procurement team buying an AI feature does not transfer all accountability to the supplier.

Prohibited practices require an early stop

The AI Act prohibits specific uses because their risk is considered unacceptable. The list includes practices such as manipulative or deceptive techniques that materially distort behaviour and cause or are likely to cause significant harm, exploitation of vulnerabilities, social scoring in the prohibited circumstances, certain predictive policing practices, untargeted scraping of facial images to build facial recognition databases, and some biometric categorisation and emotion recognition uses. The precise wording, exceptions, and dates are in Article 5 and should be assessed against the current consolidated text.

High-risk systems and Romanian operations

High-risk classification generally comes from two routes. An AI system can be a safety component of a product, or itself a product, covered by the Union legislation listed in Annex I. It can also fall into an Annex III area such as biometrics, critical infrastructure, education, employment, access to essential private or public services, law enforcement, migration and border control, administration of justice, or democratic processes. A system used for a high-risk purpose may be high risk even when the underlying model is a general purpose model.

Providers of high-risk systems face requirements including risk management, data and data governance, technical documentation, records, transparency to deployers, human oversight, accuracy, robustness, cybersecurity, quality management, conformity assessment, and registration where applicable. Deployers must use systems according to instructions, assign competent human oversight, monitor operation, keep logs under the applicable rules, use relevant input data, and take corrective action. Providers and deployers also need processes for serious incidents and fundamental rights considerations where the Act requires them.

A public authority or private operator providing public services that deploys certain Annex III high-risk systems must complete a fundamental rights impact assessment before deployment under Article 27. A private company delivering a public contract should ask whether it is itself the deployer, a provider to a public deployer, or part of the product supply chain. The AI Act assessment does not replace a GDPR data protection impact assessment. They may share facts, but their questions, owners, and evidence should remain distinguishable.

AI literacy is already a duty

Article 4 requires providers and deployers to take measures to ensure, to the best of their ability, a sufficient level of AI literacy for staff and other people operating or using AI on their behalf. The measures should consider technical knowledge, experience, education, training, the context of use, and the people or groups affected. The provision does not require a provider or deployer to guarantee a particular level of literacy in every individual. It does require a deliberate, proportionate programme.

A Romanian company should maintain an AI literacy plan by role. General users need to recognise hallucinations, confidential data exposure, unsafe prompts, automation bias, and escalation routes. HR reviewers need to understand discrimination, accommodation, meaningful review, and candidate communications. Developers need secure integration, evaluation, access controls, prompt injection, logging, and change management. Managers need to know that approving an AI recommendation does not remove accountability. Record attendance, learning objectives, scenario exercises, refresher dates, and the systems covered.

GDPR and the Romanian data protection authority

The EU AI Act does not replace the GDPR. The National Supervisory Authority for Personal Data Processing, commonly called ANSPDCP, supervises GDPR compliance in Romania. If an AI system processes personal data, the controller and processor analysis, lawful basis, purpose limitation, data minimisation, accuracy, storage limitation, security, transparency, accountability, and data subject rights remain relevant. Personal data can appear in prompts, uploaded documents, retrieval results, outputs, evaluation sets, embeddings, telemetry, support tickets, and backups.

Start with a data map. Identify the source and lawful basis for each field, who determines purposes and means, whether the supplier is a processor or an independent controller, where processing occurs, which subprocessors are involved, how long data remains, whether it is used for training or service improvement, and how access, correction, erasure, objection, and restriction requests are handled. A supplier’s statement that it does not train on customer data may still leave retention, support access, abuse monitoring, and logs to examine.

The EDPB’s Opinion 28/2024 on AI models is guidance from the European data protection supervisory system, not a new Romanian statute. It addresses anonymity, legitimate interest, unlawful training data, and the lifecycle of model processing. It emphasises case-by-case analysis, reasonable expectations, data minimisation, transparency, accuracy, and the possibility that unlawful development data can affect deployment. Use it as a serious interpretive input and record how your facts support the chosen legal basis.

Privacy by design and by default under GDPR Article 25 should shape the architecture. Filter fields before transmission, separate identities from task data, use pseudonymisation where appropriate, restrict retrieval to the minimum records, disable unnecessary history, protect prompts and outputs, and define retention for derived indexes. Test re-identification and memorisation risks. Make deletion and correction procedures account for caches, vector stores, evaluation sets, and exports where technically and legally feasible.

Automated decisions, profiling, and Article 22

GDPR Article 22 gives a person the right not to be subject to a decision based solely on automated processing, including profiling, that produces legal effects or similarly significantly affects them, subject to the specified exceptions. The fact that a human sees the score later does not automatically make the process non-automated. EDPB and former Article 29 Working Party guidance ask whether the human intervention is meaningful, informed, and able to change the result.

Romanian companies should examine credit eligibility, insurance pricing, fraud flags, employee selection, productivity monitoring, customer prioritisation, debt collection, access decisions, and service termination. A recommendation can still be consequential if it consistently controls which cases receive attention. Map the decision chain from input to output to action. Record the role, timing, authority, information, and training of the reviewer. Give the person a genuine way to obtain human intervention, express a view, and contest the result where Article 22 applies.

ANSPDCP Decision no. 174/2018 lists Romanian processing situations for which a DPIA is mandatory, including systematic and extensive automated evaluation or profiling that supports legal or similarly significant decisions, certain systematic monitoring, employee monitoring, and innovative large-scale processing. The precise text and exceptions should be checked against the current legal record. Do not assume that a vendor’s pre-deployment assessment satisfies the Romanian controller’s DPIA accountability.

Explain outcomes at a useful level. A person does not necessarily need source code or every model weight. They need to understand that automation was used, the relevant categories of information, the role of the result, material limitations, the review route, and how to correct an error. Do not claim an explanation is meaningful if staff cannot inspect the evidence or if the reviewer has no authority to disagree. Keep samples of notices, review records, challenges, overrides, and corrections.

Employment and workplace use

Employment AI receives special attention under the AI Act and existing labour, equality, privacy, and occupational rules. Systems used to recruit or select people, make decisions about work relationships, allocate tasks based on individual behaviour or characteristics, monitor performance, or evaluate people can be high risk under Annex III. Emotion recognition in the workplace is generally prohibited except for medical or safety reasons, subject to the Act. The high-risk employment designation does not eliminate local employment law, consultation, or accommodation duties.

Before using an AI CV ranking, interview analysis, scheduling score, absence prediction, productivity dashboard, or termination recommendation, define the job-related purpose and alternatives. Check proxy discrimination, disability and language effects, age, gender, nationality, pregnancy, religion, and other protected grounds under applicable Romanian and EU equality law. Offer a channel for accommodation and correction. Tell candidates or employees what the system does when notice is required or necessary for fair treatment. Consult works councils, employee representatives, or collective arrangements where applicable.

A person in the loop is a control only when the person can understand the output, see relevant context, question the data, override the recommendation, escalate an uncertainty, and stop the process. Measure override patterns and outcomes. If every recommendation is accepted because of targets, workload, or a manager’s instruction, the process may be rubber-stamping. Keep evidence of reviewer training, review time, decision reasons, appeals, and corrective action.

Transparency and generated content

Sector rules and procurement

The same model can create different obligations in different Romanian sectors. Banks and financial firms should coordinate AI reviews with BNR or ASF expectations, outsourcing, operational resilience, model risk, consumer protection, anti-money laundering, credit, fraud, and complaint handling. Health organisations and suppliers should consider health data, clinical safety, medical device rules, professional duties, and patient communication. Manufacturers should connect AI controls to product safety, machinery, quality, industrial cybersecurity, and worker safety.

Procurement is the earliest practical control point. Classify the use before signing. Ask the provider for model and system role, versions, training and fine-tuning sources, hosting, subprocessors, support access, retention, data use, evaluation limitations, incident history, security evidence, change management, and exit arrangements. Contract for confidentiality, processor obligations where relevant, deletion, breach notice, cooperation with ANSPDCP or another authority, material change notice, audit evidence, service continuity, export, rollback, and termination assistance.

Your supplier cannot accept responsibility for your purpose and downstream decision by using a label such as compliant AI. The company chooses the data, users, prompts, workflow, thresholds, reviewer, and customer communication. For an agent that can send email, modify a record, approve a payment, or change a production setting, use least-privilege credentials, transaction limits, approval gates, logging, anomaly alerts, and a tested stop mechanism. Ask what happens when the vendor is unavailable or changes the model without your team noticing.

Build an AI governance inventory

A policy written before discovery describes an imaginary company. Ask every function to list purchased software, embedded AI features, browser extensions, APIs, open source models, experiments, spreadsheet add-ons, agents, and supplier-operated systems. Reconcile answers with software asset records, expense data, cloud bills, identity groups, product roadmaps, data processing records, procurement files, and security logs. Shadow AI is a finding to manage. It should not be excluded from the inventory because it was not approved.

• System, feature, model or provider, version, use case, owner, users, purpose, lifecycle stage, and connected actions.
• Input and output data, personal and special-category data, confidential information, children’s data, biometrics, retention, and locations.
• Affected people, Romanian or other EU geographies, sector, decision impact, autonomy, reviewer, override authority, and stop path.
• Provider role, contract, hosting, subprocessors, data training settings, security controls, incident contact, and exit plan.
• Legal classification, limitations, evaluation results, fairness and accuracy risks, open questions, approval conditions, and review date.

Risk tiering and accountable governance

Use an internal tiering model to allocate effort. State clearly that internal tiers are a management tool, not a replacement for the AI Act’s legal classification. A low tier might cover drafting or summarisation with no personal or confidential input and no decision effect. A medium tier might cover internal retrieval, customer assistance, or workflow recommendations that require verification. A high tier might cover employment, credit, health, eligibility, safety, biometrics, essential services, legal rights, regulated products, or autonomous action. A prohibited tier stops uses that breach the AI Act or cannot be made safe.

Reclassify after a new model, data source, geography, user group, integration, threshold, or business purpose. A low-risk writing assistant can become high risk when it receives employee records. A customer chatbot can become consequential when it gains account access. An invoice tool can become a payment control when its recommendation automatically releases funds. Record who accepted residual risk, the evidence relied on, the conditions of approval, and the event that triggers reassessment.

Assign practical roles. An executive sponsor sets risk appetite and funding. Legal and privacy teams maintain the legal interpretation, DPIA process, and rights route. Security owns threat modelling, access, monitoring, and incident coordination. Product and engineering own design, testing, release, and change control. Operations owns the real workflow and human review. Procurement owns supplier evidence and contracts. HR, quality, finance, safety, and sector specialists join when their expertise is needed. Every use case needs one accountable owner.

Human oversight that works

Design human oversight around a decision, not a button. Give the reviewer the output, important input context, known limitations, uncertainty signals, and enough time to assess the case. Define when review is mandatory, what evidence must be checked, how to escalate, who may override, and how to pause the system. Avoid targets that reward acceptance of every recommendation. For customer and employee outcomes, provide a route to correct source data and reconsider a decision.

Monitor after launch. Sample outputs by language, customer segment, location, disability accommodation, and other relevant populations where lawful and statistically meaningful. Track false positives, false negatives, harmful content, hallucinations, override rates, waiting time, complaint outcomes, and changes after model or prompt updates. If performance crosses a threshold, contain the workflow, review affected cases, notify the right owner, and decide whether to rollback or redesign.

Evidence and incident response

Compliance is easier to defend when evidence is created as work happens. Keep the inventory record, classification analysis, legal register, data map, DPIA, fundamental rights assessment where applicable, vendor review, contract, model and system documentation, test results, training records, notices, approval, change history, monitoring, incidents, complaints, overrides, and corrective actions. Link evidence to a system version and review date. Avoid storing unnecessary sensitive prompts in broadly accessible tickets.

An AI incident can be a personal data breach, fabricated customer advice, discriminatory outcome, unsafe recommendation, prompt injection, data poisoning, unauthorised tool action, synthetic-content confusion, model outage, lost logs, or failed human review. Connect the response to existing GDPR, security, continuity, and product safety procedures. Add model-specific fields: version, input or retrieval reference, output, action, reviewer, affected people, reproducibility, containment, vendor escalation, and restart approval.

A practical implementation roadmap

Days 1 to 30 should create visibility. Appoint an executive sponsor and named owners for privacy, security, procurement, HR, product, and operations. Publish an interim rule for sensitive information, unapproved public tools, autonomous actions, and high-impact decisions. Inventory use cases and suppliers. Screen each use for AI Act role and classification, GDPR, Romanian sector rules, employment effect, customer transparency, vendor training, and connected actions. Give every unknown an owner and deadline.

Days 31 to 60 should turn findings into controls. Approve internal risk tiers and a use-case decision record. Create an approved tool catalogue and role-based AI literacy programme. Update procurement questionnaires and priority contracts. Complete DPIAs and AI impact reviews for the highest exposure uses. Configure access, redaction, retention, logging, notices, human escalation, and incident intake. Build a legal register separating binding law, official implementation information, guidance, standards, strategy, proposals, and future effective dates.

Days 61 to 90 should test the operating model. Run accuracy, robustness, fairness, privacy, security, accessibility, and Romanian-language tests suited to each use. Sample human overrides and customer corrections. Run a tabletop involving a data leak, a biased employment result, and an agent taking an unauthorised action. Test rollback and vendor outage procedures. Add a change gate for models, prompts, data, integrations, and user groups. Report open high risks, overdue evidence, training coverage, incidents, correction time, and upcoming official developments to leadership.

KPIs for a Romanian AI programme

Measure coverage and effectiveness together. Coverage indicators include the percentage of discovered uses inventoried, systems with accountable owners, uses with a legal classification, completed DPIAs, completed high-risk reviews, approved-tool adoption, trained staff by role, vendors with required evidence, and material changes reviewed before release. Effectiveness indicators include human review completion, meaningful override rate, error rate by relevant group and language, privacy incidents, time to contain, time to correct an affected record, rollback success, complaints, and unresolved high risks by age.

Common failure modes

• Waiting for a Romanian AI statute while ignoring directly applicable EU AI Act, GDPR, labour, consumer, safety, and sector duties.
• Calling a Government memorandum, National AI Strategy, ANCOM announcement, EDPB opinion, standard, or proposal binding law without checking its legal status.
• Assuming that a supplier’s AI compliance badge replaces your role analysis, DPIA, deployment instructions, human review, or contract controls.
• Treating an internal risk tier as if it were the AI Act classification, or relying on a narrow procedural exclusion without testing material influence.
• Calling a reviewer human oversight when the person cannot understand, challenge, override, or stop the result.
• Putting CVs, health details, customer files, payroll information, secrets, or privileged material into an unapproved public tool.
• Forgetting prompts, outputs, embeddings, retrieval indexes, telemetry, backups, evaluation sets, and support access when setting retention and deletion.
• Testing average accuracy in English while ignoring Romanian language quality, accessibility, edge cases, protected groups, and affected people.
• Launching an agent with broad credentials, no transaction limits, no approval gate, and no tested rollback or stop function.
• Creating an inventory or governance committee that is disconnected from procurement, identity, release management, privacy rights, security response, and operational ownership.

Build versus buy

Buy mature commodity capabilities such as identity and access management, asset discovery, training delivery, evidence storage, ticketing, vendor questionnaires, logging, and controlled model access. Build or configure the judgment-heavy parts: your Romanian and EU legal register, use-case taxonomy, risk appetite, classification decision, DPIA and fundamental rights workflow, human oversight design, Romanian-language evaluation, escalation rules, approval conditions, and executive reporting.

Official sources to monitor

Use the consolidated EU AI Act on EUR-Lex for binding text, dates, definitions, and transition rules. Monitor ANCOM’s Romanian AI Act implementation pages for national governance and enforcement developments, ADR for digitalisation policy and conformity assessment information, and ANSPDCP for Romanian data protection materials and decisions. The EDPB AI models opinion is useful European guidance. Check each source’s publication date and legal status before relying on a summary.

What can we do for you?

Magna Products helps Romanian companies turn AI experimentation into controlled, useful operations. We can inventory your AI systems and suppliers, map EU AI Act, GDPR, ANSPDCP, employment, procurement, and sector considerations, design practical classification and impact workflows, strengthen vendor controls, build role-based AI literacy, test human oversight and Romanian-language performance, and connect monitoring, incidents, and evidence to the tools your teams already use. Talk with Magna Products to schedule a focused discovery workshop and leave with a prioritised 30, 60, and 90-day implementation backlog.