EU AI Act Compliance for Compliance Professionals

EU AI Act compliance for compliance professionals is less about reading the regulation and more about turning it into work an organization can run, test, and evidence. The AI Act applies in stages to different actors, for different AI systems, and for different purposes. The position changed again in July 2026, when Regulation (EU) 2026/1744, the Digital Omnibus on AI, entered into force. The current consolidated text of the AI Act reflects the 27 July 2026 version and is the legal baseline for this article.

Two points frame what follows. First, the AI Act places obligations on defined operators such as providers and deployers. "Compliance professional" is not a role it creates. Second, a compliance function may coordinate mapping, controls, evidence, testing, and assurance inside an organization, but internal ownership does not change who is legally responsible.

The article follows one operating cycle: Identify → Determine → Map → Assign → Evidence → Test → Remediate → Monitor → Assure. Where something is a legal requirement, the article says so. Where it is an internal control or a governance practice, it says that instead.

What the EU AI Act Means for the Compliance Function

Obligations attach to specific actors in specific circumstances. A provider of a high-risk AI system has different duties from a deployer of that system, and one organization can hold different roles for different systems. Article 25 also provides that a deployer or other party can be treated as a provider in defined situations, such as a substantial modification or a change of intended purpose that makes a system high-risk. Role determination is a recurring question, not a one-off label.

Within that structure, a compliance function typically coordinates the Identify, Map, Assign, Evidence, Test, and Monitor stages. It does not replace legal, technical, privacy, security, procurement, business, or internal audit teams. The table below is an illustrative organizational model, not an AI Act requirement.

Build an AI Compliance Register

An AI Compliance Register is an AGC-recommended internal governance construct. The AI Act does not require a document by that name, and none of the fields below is legally mandatory. Its value is practical: one place where AI use, roles, applicable provisions, controls, owners, evidence and open issues can be reviewed together.

Useful fields include the AI system or use case, intended purpose, the organisation's role (provider, deployer or other), business and technical owners, third-party provider, applicable AI Act provisions, risk classification, relevant controls, control and evidence owners, review date, open issues, and remediation status.

Determine Which AI Systems Require Further Assessment

Discovery is not classification. A workable sequence is:

Discover AI use → Determine whether the AI Act applies → Identify the organization's role → Identify the relevant provision → Determine applicability → Assess classification → Determine obligations → Map controls

Not every AI system needs the same depth of assessment. High-risk status does not follow from a sensitive sector, the use of personal data, business criticality, or potential for harm. It follows from the classification rules in Article 6, which separate Annex III use cases from AI that is a safety component of products under Annex I. The Commission's high-risk classification guidelines are the best starting reference. The Omnibus also amended the definition of "safety component," so older classification notes should be rechecked.

Document Reasoning Behind Classification Decisions

As a governance practice, record the conclusion, the relevant facts, the applicable provision, the decision date, the reviewer, the assumptions relied on and any later changes. These records let the function show why a system was treated as it was.

One legal requirement is worth noting. Where a provider concludes that an Annex III system is not high-risk under Article 6(3), the Act itself requires the assessment to be documented before the system is placed on the market. Most other classification records are internal practice.

Translate EU AI Act Requirements Into Compliance Controls

This is where EU AI Act compliance becomes operational. Each applicable obligation moves through a chain: regulatory obligation → compliance risk → control objective → control → owner → evidence → testing.

Identify the Applicable Obligation

Start with the organization's role, the AI system, its intended purpose, the relevant provision, whether it applies, and from when. Article 26 shows why this matters. It sets deployer obligations for high-risk AI systems, including assigning human oversight to people with the necessary competence and authority, monitoring operation, and keeping logs under the deployer's control. It applies only to relevant deployers of high-risk systems and only from the applicable date.

Define the Control Objective

Typical objectives include preventing prohibited uses, supporting applicable transparency requirements, supporting AI literacy, maintaining required records, monitoring relevant systems, and managing incidents. Not every objective applies to every organization.

Transparency shows the need for precision. Article 50 is not one uniform duty. Providers and deployers have different obligations under different paragraphs, for example interaction disclosure and machine-readable marking of synthetic content for providers, and deepfake or certain AI-generated text disclosure for deployers. The Commission's guidelines on transparency obligations explain scope and exceptions.

AI literacy is an example of a control objective with a different legal character. As rewritten by the Omnibus, Article 4 requires providers and deployers to take measures to support the development of AI literacy among staff and others using AI on their behalf, taking account of knowledge, experience, education, training and context. It does not require them to guarantee a specific level of literacy for any individual.

Assign Control and Evidence Ownership

Separate the roles. The policy owner sets the requirement. The operational control owner runs the control. The evidence owner produces and retains proof that it ran. The compliance reviewer challenges design and results. Independent assurance, where the organisation has it, sits outside the first and second lines. One person can hold several roles in a small organisation, but the distinctions should stay visible.

Establish Control Testing

For each control, define the test objective, frequency, sampling approach where appropriate, the quality of evidence expected, how exceptions are handled and how failures feed remediation. The table is an internal compliance framework example, not a legal checklist.

Build Evidence for EU AI Act Compliance

Evidence is what turns a control into something a compliance function can defend. It helps to keep three categories apart:

1. Documentation the AI Act explicitly requires of relevant operators, such as the Article 6(3) assessment record for a provider, or deployer log retention under Article 26 where it applies.

2. Internal control evidence, such as approvals, test results, monitoring records, incident records and corrective actions.

3. Recommended governance records, such as the AI Compliance Register, classification decisions, obligation mapping, AI literacy records, vendor assessments and review history.

Categories two and three are not legal mandates unless a specific provision makes them so. The core principle is that a mature programme can show what was assessed, what conclusion was reached, who decided, why, which control applies and what evidence supports it.

Manage AI Vendor and Third-Party Compliance Risk

Most organisations meet the AI Act through suppliers, so compliance should fold AI vendor due diligence into existing third-party risk processes rather than build a parallel one. Begin by identifying which external AI providers are relevant, then establish who holds which role for each system.

A vendor's statement that a product is "AI Act compliant" is a claim to test, not proof. Contracts can support information flow, change notification, incident cooperation and escalation, but they do not by themselves change which obligations attach to which operator.

What Should Compliance Ask AI Vendors?

Keep the request proportionate to the system and its use. Common categories include:

• Intended purpose and role: what the system is designed for and how the vendor sees its own and your role

• Classification information: the vendor's view on whether any high-risk or transparency provisions apply, and its basis

• Documentation: instructions for use and other information you need to meet your own obligations

• Transparency and human oversight: what the system discloses, and what oversight it supports

• Monitoring and incident handling: how issues are detected, reported and shared with customers

• Material changes: how model, purpose or data changes are notified

• Conformity evidence, where applicable: what the vendor can provide and how current it is

Coordinate AI Compliance Across Existing Compliance Functions

Legal and Regulatory Compliance

Legal owns interpretation, especially of roles and classification. Compliance maintains the regulatory map, runs change management and escalates unresolved questions.

Privacy and Data Protection

AI use often involves personal data, so GDPR governance, DPIAs where applicable and DPO input need to connect with AI Act work. This is coordination, not duplication. The AI Act does not create a general requirement for an AI-specific DPO.

Information Security and Technology

Security and technology teams own technical controls, cybersecurity, monitoring and logging where relevant, and much of the technical evidence compliance will later test.

Procurement and Third-Party Risk

These teams run vendor assessment, contract terms and supplier monitoring. Compliance supplies the AI-specific requirements and reviews exceptions.

Risk Management and Internal Audit

Risk connects AI Act exposure to enterprise risk reporting. Internal audit provides independent assurance according to the organisation's governance model, and should not design the controls it later audits.

Business and AI System Owners

Owners define the intended purpose, control how the system is used in operations, apply oversight and escalate changes. Most compliance failures start when use drifts from what was assessed, so this relationship carries real weight.

Address Fundamental Rights and Data Protection Assessments

Fundamental rights and data protection considerations can overlap, but they arise under different legal frameworks and should be handled as such.

Fundamental Rights Impact Assessment

Article 27 does not require every deployer of high-risk AI to carry out a Fundamental Rights Impact Assessment (FRIA). It applies before deployment of certain high-risk systems referred to in Article 6(2), excluding Annex III point 2, for deployers that are bodies governed by public law or private entities providing public services, and for deployers of the systems in Annex III points 5(b) and (c), which cover creditworthiness and certain life and health insurance uses. It follows the Annex III application date.

Where it applies, the compliance function may coordinate stakeholders, maintain evidence, track resulting actions and feed findings into remediation. The Omnibus also directs the AI Office to develop a questionnaire template to help deployers with this assessment.

Relationship With GDPR DPIAs

A FRIA and a Data Protection Impact Assessment (DPIA) may cover overlapping subject matter, but one does not automatically replace the other. As amended, Article 27(4) allows a deployer to cross-reference or reuse relevant parts of a DPIA where an Article 27 obligation is already met through it. That permits coordination with the DPO; it does not remove the need to check the FRIA requirements separately.

Test and Audit EU AI Act Compliance Controls

These activities are often blurred. The table sets out an organisational governance model, not a statutory requirement.

Compliance Gap Assessment

A gap assessment identifies applicable requirements that lack a control, or controls that lack evidence. It is usually the first exercise and is repeated when scope or law changes.

Compliance Control Testing

Testing asks whether controls are appropriately designed and operating as intended. Use the test objective, sampling and evidence-quality criteria defined earlier, and log exceptions consistently.

Internal Audit

Internal audit gives independent assurance according to the organisation's governance model. The AI Act does not universally require an internal audit. Where an organisation commissions an EU AI Act compliance audit, the scope should follow applicable obligations, not the whole Regulation.

Remediation and Issue Management

Each finding should carry a risk rating, an owner, a corrective action, a deadline, validation and closure evidence. Closing an issue without validation is a common weakness.

Monitor AI Act Changes and Compliance Obligations

The regulatory position is still moving. Compliance teams may need to track amendments, European Commission guidance, AI Office materials, national authority activity and relevant standards, alongside internal change: new AI systems, altered intended purposes, vendor changes and control changes. The European Commission's AI regulatory framework page and the AI Act Service Desk are practical starting points.

Key AI Act Dates Compliance Professionals Should Track

The Service Desk's implementation timeline, which reflects the Omnibus, is the basis for the table. There is no single universal deadline, and transitional rules may apply to systems already on the market.

Applicability, enforcement powers and enforcement action are separate questions. The timeline places the start of national and EU enforcement for general-purpose AI models, prohibitions, transparency rules and AI literacy on 2 August 2026, while the high-risk rules have later dates. The Commission's overview of the enforcement framework explains how enforcement is shared between the AI Office and national authorities.

Update Internal Compliance Materials After Regulatory Changes

Each change should trigger a review of the affected materials: policies, controls, training content, vendor questionnaires, risk assessments, audit programmes, the AI Compliance Register and monitoring procedures. The Omnibus's rewrite of Article 4 is a good example, because literacy policies and training records written against the earlier wording may need reframing.

What Compliance Professionals Should Do Now

1. Identify AI systems, uses and the organisation's role for each.

2. Determine which obligations apply, from which date.

3. Map obligations to compliance risks and controls.

4. Assign control, evidence and review ownership.

5. Document decisions, reasoning and evidence.

6. Test controls against defined objectives.

7. Remediate gaps with validated closure.

8. Monitor regulatory, vendor and system changes.

9. Assure through appropriate review or audit.

Developing EU AI Act Capability Across the Compliance Function

Compliance professionals need enough AI Act knowledge to carry out the responsibilities their organisation gives them. That is different from AI literacy under Article 4, which concerns measures supporting literacy among staff and others using AI on the organisation's behalf. Needs vary by role: a control tester, a third-party risk analyst and a legal adviser need different depth.

When comparing EU AI Act training courses, consider whether the content reflects the current consolidated text and 2026 amendments, whether it fits your role, whether it moves from requirement to implementation, how updates are handled, and whether it separates legal requirements from recommended practice.

AI Governance Courses (AGC) is a private training provider, not an EU body or regulator. Its EU AI Act compliance training covers provider and deployer duties, classification decision records, vendor governance, monitoring and audit evidence. Training supports capability; it does not replace legal advice or organisational controls.

Conclusion

EU AI Act compliance for compliance professionals is primarily about translating applicable regulatory obligations into accountable controls, evidence, testing, remediation, monitoring and assurance. The legal analysis stays with the actors and provisions the Act defines. The operating cycle is how a compliance function makes it work day to day. To build the underlying knowledge, explore AGC's EU AI Act compliance training.