Foreign investment • AI governance • Romania

AI due diligence in Romania asks whether a target company’s AI use, data, contracts and public claims support the investment case. It is not a technical demonstration of a model and it is not a generic AI policy review. For a buyer, investor or lender, the question is whether the target has identified the systems it uses, can lawfully operate them, owns or can use the assets it relies on, and has a credible plan for the risks that will remain after closing.

What is AI due diligence in a Romanian transaction?

AI due diligence is a transaction-focused legal and commercial review. It identifies whether the target’s use of AI creates liabilities, restrictions, missing rights or implementation costs that could affect price, risk allocation or post-closing operations.

For a Romanian target, the review should cover the target’s Romanian operations and any AI outputs used in the European Union. The EU AI Act is directly applicable across the EU and operates alongside the GDPR where personal data is processed. A seller’s statement that it uses only a third-party AI tool does not end the inquiry: the target may still be a deployer, customer, controller, employer or regulated business with its own duties.

This guide has a different purpose from our analysis of AI vendor contracts in Romania, which focuses on the agreement with a supplier, and from DPIA vs FRIA in Romania, which focuses on assessment triggers for a deployment. Here, the investor is deciding what must be verified before, at and after a deal.

Start with the target’s actual AI footprint

Do not begin with a broad question such as “Does the company use AI?” Ask what system or model is used, for which decision, with which data, by whom, and whether the target sells, deploys, develops, fine-tunes or merely accesses the tool.

A useful data-room request separates customer-facing products from internal tools. It should identify models, APIs, software providers, hosting and cloud dependencies, integrations, datasets, prompts or knowledge bases, material outputs, users and the decisions influenced by each use case. The inventory should also record planned products or features that have not yet launched but are material to the investment thesis.

Which legal and commercial issues should an investor test?

Click or tap a row to highlight the diligence takeaway. On a small screen, swipe the table sideways.

The European Commission describes the AI Act as a risk-based framework for developers and deployers. It identifies employment, credit scoring and access to essential services among the examples that may be high-risk. See the Commission’s AI Act overview and application timetable.

AI Act review: classify before you value the risk

Do not treat “AI Act compliant” as a sufficient diligence answer. Contractual, sector-specific, data-protection and AI Act obligations must be assessed separately. The investor should identify the system, its intended purpose, the target’s role and the rules that apply now or later. The relevant date can affect both risk allocation and integration planning.

The AI Act’s prohibitions, AI literacy obligations, governance rules, GPAI-model obligations and transparency rules have different application dates from the rules for high-risk systems. The Commission states that Annex III high-risk use cases, including employment and credit-scoring examples, are scheduled to apply from 2 December 2027, while high-risk systems embedded in regulated products have a later date of 2 August 2028. A diligence report should distinguish obligations already applicable from future obligations that could require a funded implementation plan. At the time of publication, the applicable AI Act timetable should be verified against the latest EU legislation and implementation guidance, including the official AI Act Service Desk timeline.

The analysis should also ask whether the target is developing an AI system, placing it on the market, deploying it in its own business, importing it, distributing it or using a third-party service. These labels are not interchangeable with GDPR controller and processor roles. For the contract-facing part of that review, see AI Vendor Contracts in Romania.

GDPR and data review: look beyond the privacy policy

The decisive question is what happens to personal data at each stage of the AI lifecycle. A target may process personal data in training, testing, deployment, monitoring, logs, prompts, support and human review, even where the product is marketed as automated or anonymised.

The review should map the data categories, purposes, retention, recipients, access, transfer mechanisms and contractual roles. Where the use involves profiling, recruitment, credit, insurance, pricing or decisions that may significantly affect individuals, check the actual decision flow and safeguards rather than relying on a generic human-review statement. Article 35 GDPR requires a DPIA where processing is likely to result in a high risk to the rights and freedoms of natural persons; Article 22 has separate rules for certain solely automated decisions.

The European Data Protection Board has also confirmed that the anonymity of an AI model trained with personal data must be assessed case by case. That matters for a target relying on a statement that a model, dataset or output is anonymous. Read EDPB Opinion 28/2024. For the broader framework, see our guide to GDPR compliance when using AI in Romania.

Data, intellectual property and contract rights

AI value is often dependent on rights that sit outside the target’s own code. The investor should trace the legal basis for using data, third-party models, cloud infrastructure, open-source components, output and confidential information.

Review the complete contract suite, not only the signed master agreement. Order forms, online terms, acceptable-use policies, data-processing agreements, security schedules, open-source notices and API terms can all affect the target’s rights. In particular, check whether a provider can use customer or target data for model training, whether the provider can change the model or service unilaterally, and whether the target can export its data and configurations on exit.

Ownership language for AI-generated output should be read carefully. A contractual promise may create a licence or allocation between the parties, but it does not necessarily guarantee exclusivity or copyright protection in every output. The copyright status of AI-generated content may vary depending on the level of human creative input and the applicable jurisdiction. The review should identify the use the target needs to make of the output and whether third-party rights, human authorship requirements, confidentiality or contractual restrictions could limit that use.

What should the investor request in the data room?

1. Request a current AI inventory. Include internal tools, customer-facing products, models, APIs, plugins, fine-tuning, integrations and material planned features.
2. Obtain a use-case map. Record intended purpose, users, affected people, decisions, data inputs, outputs, human review and country of deployment.
3. Collect AI governance records. Ask for role assessments, policies, training records, system documentation, risk logs, testing, monitoring and incident procedures.
4. Review AI Act screening. Identify prohibited practices, potential high-risk systems, transparency obligations, GPAI dependencies and the applicable timetable.
5. Map personal-data processing. Review privacy notices, legal bases, Article 22 analysis, DPIAs, processor arrangements, security controls and transfers.
6. Trace data rights. Check source, licence, consent or other permission for data used in development, testing, fine-tuning and ongoing service delivery.
7. Review the contract stack. Read supplier, customer, cloud, API, DPA, security, outsourcing and change-control documents together.
8. Confirm IP and open-source position. Request code provenance, licences, notices, ownership assignments, third-party claims and output-use restrictions.
9. Test material statements. Compare product marketing, investor materials and customer commitments against the available technical and legal evidence.
10. Assign the deal response. Separate issues requiring price, warranty, indemnity, condition, remediation, disclosure or post-closing integration action.

How should findings affect the transaction documents?

Translate each material finding into an owner, timing and remedy. A diligence report is useful only if the SPA, investment agreement, disclosure process and integration plan reflect the issues that have been identified.

The appropriate response will depend on the transaction structure and the seller’s ability to remediate. A buyer may need targeted warranties concerning data rights, AI-related regulatory compliance, ownership, contract compliance, absence of claims or material incidents. Confirmed gaps may justify a specific indemnity, a pre-closing remediation covenant, a post-closing plan, a condition or a tailored disclosure. The drafting should not assume that a general compliance warranty captures the actual issue.

Post-closing planning is equally important where the buyer will integrate systems, move data, introduce a new group policy, change suppliers or expand the target’s use case. These changes can alter the GDPR and AI Act analysis. If an assessment is required, the timing should be addressed before the relevant processing or deployment begins. Our DPIA vs FRIA guide explains why those two assessment routes must be screened separately.

When does a separate specialist review become necessary?

A focused AI legal review should be coordinated with corporate, technical, information-security, employment and commercial due diligence when the target develops AI products, relies on proprietary datasets, makes regulated-sector decisions, uses AI in recruitment or credit processes, processes sensitive personal data, markets compliance claims, or has important dependencies on a small number of providers. The workstreams should share the same factual inventory, but each should retain its own legal questions and conclusions.

How Atrium Romanian Lawyers can assist

Atrium Romanian Lawyers can coordinate the legal workstream for AI-related due diligence in a Romanian investment, acquisition or internal reorganisation. The review can cover AI Act role and use-case screening, GDPR and data-contract questions, supplier and customer terms, intellectual property, employment and operational governance, and the translation of findings into transaction documents or an integration plan.

AI governance • Romania • Assessment decisions

DPIA vs FRIA in Romania is a question of two different legal tests. A data protection impact assessment (DPIA) addresses risks arising from personal-data processing under the GDPR. A fundamental rights impact assessment (FRIA) under the AI Act applies to specified deployers of certain high-risk AI systems. Your project may require one, both, or neither mandatory assessment.

When do these obligations apply?

The GDPR assessment requirements already apply. Under the AI Act’s consolidated timetable, Chapter III Sections 1–3, including Article 27, apply to Annex III high-risk systems from 2 December 2027. The corresponding date for Article 6(1)/Annex I product systems is 2 August 2028; that does not extend Article 27 to every product system.

Article 111 contains separate transition provisions for existing systems. A project review should record when the system was placed on the market or put into service and whether subsequent design changes affect its treatment. The future FRIA timetable does not postpone GDPR duties. Source: consolidated AI Act, Articles 111 and 113.

DPIA vs FRIA: the differences that change your project

Both assessments examine potential harm to people. A DPIA is not limited to confidentiality or cybersecurity: it also examines other rights and freedoms affected by personal-data processing. FRIA addresses the impact of the specified AI deployment on fundamental rights.

Click or tap a row to reveal its practical takeaway. Keyboard users: Tab to a green label and press Enter or Space. Swipe the table sideways on a small screen.

GDPR Articles 28, 35–36 and 39; AI Act Article 27.

When does an AI project need a DPIA?

AI use alone does not automatically trigger a DPIA. The controller must assess whether the nature, scope, context and purposes of the processing make a high risk to people likely. Article 35 expressly recognises the relevance of new technologies.

The GDPR identifies particular situations, including systematic and extensive automated evaluation underpinning decisions with legal or similarly significant effects, large-scale processing of special-category or criminal-offence data, and large-scale systematic monitoring of publicly accessible areas. Applicable supervisory-authority lists must also be checked.

For a Romanian deployment, the file should therefore address the applicable requirements and guidance of the Romanian data protection authority, ANSPDCP, alongside Article 35. Record the reasons for a negative screening conclusion too. A supplier’s description of a product as “low risk” is not an assessment of your processing.

Where required, the DPIA must describe the processing and purposes, assess necessity and proportionality, evaluate risks to individuals and specify safeguards. This is a substantive project assessment, not simply a signed template. Source: GDPR Article 35.

For the broader data-protection framework, see our guide to GDPR compliance when using AI in Romania.

Who needs a FRIA under the AI Act?

The Article 27 obligation does not cover every business using high-risk AI. It concerns Article 6(2) high-risk systems and specified categories of deployer, with an exclusion for the critical-infrastructure area in Annex III point 2.

• Bodies governed by public law deploying qualifying systems.
• Private entities providing public services deploying qualifying systems. This status requires analysis; it is not synonymous with every company selling services to the public.
• Deployers of qualifying creditworthiness or credit-scoring systems for natural persons under Annex III point 5(b), which excludes systems used to detect financial fraud.
• Deployers of qualifying life and health insurance risk-assessment or pricing systems for natural persons under Annex III point 5(c).

Classification under Article 6 must be checked first, including the conditions of any applicable exception. The exact intended purpose matters. A financial-sector tool is not automatically a creditworthiness system, and a medical product is not automatically within the Article 27 FRIA route. Source: AI Act Articles 6 and 27 and Annex III.

Explore four deployment scenarios

These hypothetical examples explain the screening logic. They assume the stated facts and do not replace an assessment of the actual system, applicable dates or transition rules.

Can one assessment document cover DPIA and FRIA?

A coordinated file can reduce duplicated work, provided each legal requirement remains identifiable. The consolidated Article 27(4) expressly allows relevant DPIA sections to be cross-referenced or incorporated into FRIA where they already meet the corresponding obligations.

Start with a shared description of the system, purposes, data flows, affected people and safeguards. Then keep a requirement map showing which sections satisfy GDPR Article 35 and which satisfy AI Act Article 27. Identify gaps rather than renaming a DPIA “FRIA”. Source: AI Act Article 27(4)–(5).

As a practical drafting approach, include a separate deployment chapter addressing who may be affected beyond the immediate users, how mistakes influence access to opportunities or services, who can intervene, and how complaints lead to corrective action. Avoid treating GDPR as only a privacy checklist: the DPIA itself must consider risks to rights and freedoms.

What the FRIA needs to address

Article 27 requires the deployment process and intended use, duration and frequency, affected people and groups, specific risks of harm, implementation of human oversight, and measures if risks materialise, including governance and complaint mechanisms. Reusing a supplier assessment in similar cases is permitted, but the deployer must check its fit and update changed or outdated elements. Source: AI Act Article 27(1)–(2).

Who prepares, reviews and owns the decision?

The controller remains responsible for the DPIA; the covered deployer remains responsible for FRIA. A consultant, DPO or supplier can contribute without taking over the organisation’s statutory role.

For the DPIA, seek the designated DPO’s advice and preserve their independent advisory and monitoring function. Obtain relevant processor assistance. For the deployment review, involve the business owner, technical team and people responsible for oversight and complaints. A useful internal decision records outstanding conditions, the person accountable for each safeguard and the circumstances requiring a fresh review. Source: GDPR Articles 28(3)(f), 35(2) and 39; AI Act Article 27.

Contractual cooperation should cover the evidence you need to assess the deployment. Our AI vendor contracts guide addresses information rights, changes and supplier responsibilities.

Must the assessment be sent to an authority?

A DPIA and a FRIA follow different authority procedures. Under GDPR Article 36, prior consultation is required where high residual risk remains that cannot be sufficiently mitigated. There is no general GDPR obligation to submit every DPIA for approval.

Article 27(3) provides for notification of FRIA results to the market surveillance authority using the relevant template, subject to the Article 46(1) exception. That notification is not the GDPR prior-consultation procedure and should not be described as automatic permission to deploy. Confirm the competent authority and operational submission arrangements for the specific deployment. GDPR Article 36; AI Act Article 27(3).

A practical assessment file before deployment

1. Define the use case. Identify the system, version, intended purpose, users, affected people and decisions it informs.
2. Map roles separately. Record GDPR controller/processor roles and the relevant AI Act roles.
3. Screen the legal route. Check prohibited practices, AI classification, DPIA triggers and Article 27 deployer coverage.
4. Record timing. Distinguish existing GDPR duties from future AI Act requirements and applicable transition provisions.
5. Collect evidence. Obtain data-flow information, supplier instructions, meaningful performance limitations, oversight arrangements and relevant testing.
6. Assess harms and safeguards. Describe how the actual deployment may affect people and how controls reduce those risks.
7. Map shared sections. Make each DPIA and FRIA requirement traceable, retaining any necessary separate analysis.
8. Resolve escalation. Identify prior consultation, notification, unresolved risks and conditions preventing launch.
9. Assign review triggers. Consider changes in purpose, model, data, affected groups or decision authority, and evidence from incidents or complaints.

How Atrium Romanian Lawyers Assisted an International Manufacturing Group

Anonymised client matter. The description below omits identifying information and focuses on the legal work performed.

A focused consultation can clarify which assessment route applies and what your team needs before making deployment commitments.

A GDPR data breach in Romania creates an immediate legal decision window. The company must contain the incident, determine whether personal data were compromised, assess the risk to individuals and decide whether the Romanian supervisory authority, the ANSPDCP, must be notified within 72 hours.

This guide is designed for Romanian companies, foreign investors, directors, compliance teams and data protection officers responding to an actual or suspected incident. It should be used together with an incident-specific legal and technical assessment. For preventive support and breach response, see our data protection services in Romania.

What qualifies as a personal data breach?

Article 4(12) of the General Data Protection Regulation defines a personal data breach as a security breach leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of or access to personal data. The concept is wider than a cyberattack and covers confidentiality, integrity and availability incidents.

A security event that does not involve personal data is not a personal data breach under GDPR. Conversely, a small incident can still be a breach. Under the data protection rules applicable in Romania, the number of affected people matters, but so do the sensitivity of the data, the ease of identification, the possible consequences and the vulnerability of the people concerned.

When does the 72-hour notification period start?

Article 33 requires notification without undue delay and, where feasible, no later than 72 hours after the controller becomes aware of the breach. According to the EDPB breach-notification guidelines, awareness exists when the controller has a reasonable degree of certainty that a security incident occurred and led to personal data being compromised.

A brief initial investigation may be necessary to determine whether personal data were actually affected. That does not permit an organisation to delay investigation or postpone escalation. Once there is reasonable certainty, the clock runs even if the full cause, exact number of records or final consequences are still being investigated.

Do not wait for a final forensic report before making the legal notification decision. Article 33 expressly permits phased notification when all information cannot be provided at the same time.

Must every breach be notified to the ANSPDCP?

No. Every breach must be recorded internally, but not every breach must be reported to the authority. The controller must assess the likely impact on the rights and freedoms of natural persons. The result falls into one of three practical levels.

Risk is not determined by a single formula. The company should consider the type of breach, nature and volume of data, identifiability, severity and likelihood of consequences, number and characteristics of affected people, and the effectiveness of safeguards such as encryption. The EDPB’s practical breach examples are useful benchmarks, but the actual incident must be assessed on its own facts.

What must an ANSPDCP notification contain?

Article 33(3) establishes the minimum information. The ANSPDCP’s current online notification form requests additional operational details that allow the authority to understand the incident and the controller’s response.

If exact figures are not yet available, provide reasonable estimates and state that the investigation continues. Under Article 33(4), missing information may be supplied in phases without undue further delay. If the filing occurs after 72 hours, it must include reasons for the delay.

How is a breach notified in Romania?

The ANSPDCP maintains a dedicated personal data breach notification page with access to its online form. Before submission, the company should identify the correct controller, confirm whether the incident also affects other group entities or joint controllers, and determine whether the ANSPDCP is the competent or lead supervisory authority for any cross-border processing.

The notification should be consistent with the internal breach register, technical evidence, communications plan and any supplemental filing. A company should not understate confirmed facts, speculate beyond the evidence or present an incomplete notification as final.

Who should be involved in the response?

A data breach cannot be handled by IT alone. The legal assessment depends on verified technical facts, while technical containment must preserve evidence and avoid creating inconsistent records. A small decision team should be activated immediately, with clear authority and one incident chronology.

• Security and IT: containment, forensic preservation, affected-system analysis, eradication, recovery and evidence of technical safeguards.
• DPO and legal counsel: awareness timestamp, controller or processor status, risk assessment, authority competence, notification drafting and privilege strategy where applicable.
• Management and communications: decision authority, resources, operational continuity, messaging and escalation to insurers or relevant corporate bodies.
• Processors and vendors: incident facts, contractual notification, audit cooperation, subprocessor information and coordinated remedial action.

What is the difference between a controller and a processor?

The controller decides why and how personal data are processed and carries the Article 33 duty to notify the competent supervisory authority. A processor must notify the controller without undue delay after becoming aware of a personal data breach. GDPR does not give processors a separate 72-hour period for notifying the controller.

Data processing agreements should therefore establish an immediate escalation channel, minimum incident information, continuous updates, preservation duties and cooperation with notifications and communications. A processor’s delayed or incomplete report does not remove the controller’s obligation once the controller becomes aware.

Vendor and technology contracts should be reviewed before an incident occurs. Our IT law services in Romania cover data-processing terms, security obligations, audit rights and incident-response clauses.

When must affected individuals be informed?

Under Article 34, the controller must communicate the breach to affected individuals without undue delay when it is likely to result in a high risk to their rights and freedoms. This obligation is separate from the 72-hour authority-notification rule. The communication must use clear and plain language and explain the nature of the breach, the contact point, likely consequences and measures taken or proposed.

Communication is not required when one of the Article 34(3) conditions applies:

• appropriate protection measures applied to the affected data and made them unintelligible to unauthorised persons, such as effective encryption;
• subsequent measures ensure that the high risk is no longer likely to materialise; or
• individual communication would involve disproportionate effort, in which case a public communication or similarly effective measure is required.

The message should help people protect themselves. Depending on the incident, practical steps may include changing credentials, enabling multi-factor authentication, contacting a bank, monitoring accounts, watching for targeted phishing or using a dedicated support contact. Avoid minimising the event or overwhelming recipients with technical detail.

How should breach risk be assessed?

The legal threshold concerns risk to people, not only damage to the company. Business interruption, contractual liability and reputational harm matter to the response, but they do not replace the individual-rights analysis required by Articles 33 and 34.

High-risk indicators include sensitive or criminal-offence data, authentication credentials, detailed financial or identity information, data concerning children or other vulnerable people, large-scale exposure, malicious exfiltration, weak safeguards and consequences that are difficult for individuals to reverse. Effective encryption, rapid verified retrieval from a trusted recipient and prompt credential revocation may reduce risk, but each control must be tested against the facts.

What evidence and documentation should be preserved?

Article 33(5) requires the controller to document every personal data breach, including the facts, effects and remedial action. The record must allow the supervisory authority to verify compliance. A defensible incident file should include:

• the original alert, detection data and a precise incident chronology;
• the awareness timestamp and the facts supporting it;
• affected systems, processing activities, data categories, people and record estimates;
• logs, forensic images, access records, emails, vendor reports and chain-of-custody information where relevant;
• containment, eradication, recovery and mitigation actions;
• the risk and high-risk assessments, including reasons and assumptions;
• the decision to notify or not notify, approvals and any delay explanation;
• copies of the initial and supplemental ANSPDCP filings;
• data-subject communications or the documented Article 34 exception; and
• post-incident findings, corrective actions and responsibility for completion.

Records should distinguish confirmed facts from estimates and hypotheses. The company should also consider cybersecurity, contractual and insurance requirements, DORA and other sector-specific reporting duties, and criminal-law reporting duties. These may use different thresholds and deadlines from GDPR.

A practical 72-hour response checklist

1. Activate the incident team. Establish one decision lead, secure communications and a contemporaneous chronology.
2. Contain without destroying evidence. Isolate affected resources, revoke compromised access and preserve logs and forensic material.
3. Confirm whether personal data are involved. Identify the controller, processor, systems, processing activities and data flows.
4. Record the awareness timestamp. Explain when reasonable certainty was reached and what facts supported it.
5. Map the scope. Identify data categories, affected people, approximate record volumes, jurisdictions and vulnerable groups.
6. Assess risk to individuals. Analyse likelihood, severity, safeguards, realistic misuse and reversibility of harm.
7. Decide on authority notification. Notify unless the breach is unlikely to create risk. Use phased notification if necessary.
8. Assess high risk separately. Decide whether individuals must be informed and prepare clear protective guidance.
9. Coordinate other duties. Review processors, insurers, contractual partners, cybersecurity rules and sector regulators.
10. Continue and close the response. Supplement filings, verify recovery, complete remediation and retain the breach record.

For a broader preventive review, use our GDPR compliance checklist for Romanian companies. Even though the checklist was published earlier, the core governance controls remain relevant and should be checked against current processing and security practices.

Frequently asked questions

Legal disclaimer: This article provides general information and does not constitute legal advice. The applicable response depends on the facts, the company’s role, the data and individuals affected, the competent authority and any sector-specific obligations. Obtain advice for the specific incident.

AI Notice: AI-assisted content, reviewed and approved by a qualified Romanian lawyer.