EU AI Act compliance: which services, deliverables and documentation you need to pass an audit

Do you use AI in recruitment, scoring, chatbots, anti-fraud, customer support or the automation of internal workflows? Then the question is no longer whether the technology delivers efficiency, but whether you hold a genuine EU AI Act compliance and GDPR file that will withstand an audit, a negotiation with a vendor or scrutiny by an authority.

The pressure in 2026 is tangible: you need a classification of your systems, a risk assessment, internal policies, AI literacy, an AI register and a clear separation between the provider and deployer roles. From 2 August 2026 the majority of the rules take effect, including transparency and the main regime applicable to many high-risk systems.

This article sets out the services offered by Buju, Stanciu & Associates on EU AI Act compliance in Romania: the dedicated practice, the deliverables, the risk levels covered and a structured, neutral comparison with other law firms active in this field.

What EU AI Act compliance means and how BSA approaches it

Buju, Stanciu & Associates has a visible artificial intelligence practice, supported by specialist content, privacy expertise and an in-house technical component - the team includes both business and data protection lawyers and a dedicated Chief AI Strategy Officer role.

Our approach starts from the overlap between the AI Act and the GDPR: a company may be compliant on one front and exposed on another - training data, profiling, the right to an explanation, DPIA versus FRIA, the provider-deployer relationship and vendor contracts. In terms of positioning, BSA works mainly with companies that implement or use third-party AI systems (the deployer role) rather than those developing a foundation model - which is the position of most organisations in the local market.

Concrete deliverables: from risk assessment to training

A typical project begins with an inventory of the use cases and continues with documents that can genuinely be used by compliance, the DPO, procurement, HR and management:

1. 01

   AI Act applicability assessment

   Initial risk assessment: whether the solution falls within the definition of an AI system and which regime applies to it, by reference to Regulation (EU) 2024/1689 and to the Commission's guidelines on the definition of an AI system and on prohibited practices.

2. 02

   Classification by risk level and role

   Classification of each system as minimal risk, transparency, high-risk or potentially prohibited, together with a definition of the organisation's role: provider, deployer, importer or distributor.

3. 03

   AI register

   An internal register of AI systems: purpose, vendor, data flow, internal users, type of output, impact on rights, GDPR legal basis, human oversight, log retention and approval status.

4. 04

   AI Act + GDPR gap analysis

   A combined AI Act-GDPR analysis: legal basis, profiling, art. 22 GDPR, minimisation, retention, transfers, contracts and documentation, in line with the EDPB opinion of 18 December 2024.

5. 05

   Internal policies and AI governance

   AI use policy, approval procedure for new tools, vendor due diligence, labelling and transparency rules, escalation process, human oversight and AI literacy. Art. 4 on AI literacy has applied since 2 February 2025.

6. 06

   DPIA, FRIA and integrated assessments

   Integrated risk assessments for systems with material impact, aligned with internal processes so that they can actually be used in implementation decisions.

7. 07

   Vendor contracting and negotiation

   Review of clauses on performance, explainability, audit assistance, incident reporting, rights of access to documentation and logs, plus remedies for non-compliance.

8. 08

   Scenario-based training and workshops

   AI literacy sessions for management, HR, product, legal, IT and compliance, built around concrete scenarios: automated recruitment, scoring and customer support.

Obligations by risk level and role

The AI Act is risk-based, and obligations differ according to the organisation's role. In short, who owes what:

This role × risk mapping is the backbone of any compliance file: without it, you cannot know which documents and which controls you are missing.

Working process and indicative timelines

The typical flow of an AI Act compliance project. The timelines are indicative and vary with the number of systems, the complexity of the organisation and the availability of internal information. Stages 4–7 may run partly in parallel.

1. Discovery (1–2 weeks). Mapping AI use cases and identifying vendors and data flows.
2. Classification (1–2 weeks). Assigning systems to risk tiers and roles (provider/deployer).
3. AI register (1 week). Building the internal register of AI systems.
4. Internal policies (2–3 weeks). Drafting the AI use policy and related procedures.
5. DPIA / FRIA (2–4 weeks). Impact assessments for systems presenting relevant risk.
6. Contracting (2–4 weeks, in parallel). Reviewing and renegotiating clauses with AI vendors.
7. Training (1–2 weeks). AI literacy sessions for the relevant teams.

Discuss the process for your company

What an operational AI register contains

A working AI register will typically include minimum fields such as:

• System name and purpose / use case
• Vendor and organisational role (provider, deployer, importer, distributor)
• AI Act risk tier and the Annex III category, where applicable
• Personal data processed: categories and GDPR legal basis
• Internal users and type of output (score, decision, generated content)
• Impact on the rights of data subjects
• Human oversight measures and log retention policy
• Vendor documentation available and internal approval status
• Date of last review

The structure of an internal AI use policy

A workable internal policy will typically cover the following sections:

• Purpose and scope
• Definitions and key terms (AI system, provider, deployer, high-risk)
• Roles and responsibilities (AI committee, DPO, IT, business owners)
• The approval process for new AI tools
• Vendor due diligence requirements
• Labelling and transparency rules for users/clients
• Human oversight protocol for high-risk systems
• Incident handling and escalation process
• Documentation and log retention requirements
• AI literacy programme and periodic training
• Periodic review of the policy

Market comparison: public visibility, not a ranking

The matrix below draws exclusively on publicly available materials (July 2026) and reflects identifiable information, not opinions. Rows marked “not publicly specified" indicate that no public confirmation was identified, not that the firm lacks the capability.

The comparison reflects differences in public visibility between firms, not necessarily differences in actual capability - hence the need to verify directly with each firm.

Expert insights

According to the European Commission, AI Act is the world's first comprehensive legal framework for AI, built on a risk-based approach, with high-risk systems subject to strict requirements on risk management, data quality, logging, documentation, human oversight, robustness and cybersecurity.

Under the standard timetable, most of the rules take effect on 2 August 2026, including the transparency rules and the main regime for the high-risk systems listed in Annex III. Where this meets data protection, the EDPB stresses the role of the GDPR principles in supporting responsible AI development, including as regards anonymisation, legitimate interest and the use of data.

From the perspective of the Romanian market, Romania remains primarily an AI ecosystem regulated at EU level, with local implementation built around the designated authorities and sector-specific obligations.

Key takeaways

• BSA has a dedicated EU AI Act & Compliance practice, evidenced by specific public content.
• The deliverables are concrete: risk assessment, system classification, AI register, internal policies, GDPR-AI Act gap analysis and training.
• The offering covers high-risk AI, HR AI, credit scoring, chatbots and projects in which the provider and the deployer share obligations.
• A defensible compliance file requires both the documents above and a repeatable internal updating process.

Frequently asked questions