What You Need to Comply with the EU AI Act

EU AI Act compliance requirements are the practical rules and controls companies must address for each AI system.

EU AI Act compliance begins with a simple question: what relationship does your organisation have with each AI system? The requirements differ depending on whether you develop a system, use one supplied by another company, import it into the European Union or place it on the market under your own name.

Risk is equally important. A customer service chatbot, recruitment system, medical product and general purpose AI model do not create the same obligations. Before creating policies or purchasing compliance software, the organisation needs to understand what its systems do, who may be affected and which legal category applies.

Most companies will need an AI inventory, documented classifications, clear responsibilities, supplier controls, AI literacy measures and an ongoing review process. In its compliance work, PrivaLex often finds that organisations already have parts of this information across privacy, security, procurement and technology systems. The challenge is connecting those records into one coherent governance programme.

The short answer

To comply with the EU AI Act, your organisation needs to address six core areas:

• Identify AI systems and determine your regulatory role for each one.
• Screen for prohibited practices and classify systems according to risk.
• Assign owners and introduce proportionate legal, technical and operational controls.
• Review suppliers, provide transparency and establish meaningful human oversight.
• Maintain assessments, approvals, training records, logs and other evidence.
• Monitor systems, reassess material changes and respond to incidents.

Not every organisation will need every requirement. The final compliance scope depends on the system, regulatory role, intended purpose and risk classification.

Does the EU AI Act apply to your organisation?

The AI Act can apply to organisations established inside and outside the European Union.

It may apply when an organisation places an AI system or general purpose AI model on the EU market, uses an AI system within the EU, imports or distributes an AI system, manufactures a product containing AI or produces AI outputs that are used within the European Union.

A company should not assume that it falls outside the regulation simply because its headquarters or technology supplier is located elsewhere.

The first assessment should identify where the system is offered, where it is used, where affected individuals are located and whether its outputs influence activities within the EU.

The organisation must also determine whether the technology falls within the legal definition of an AI system. Conventional software does not automatically become an AI system because it performs calculations or automates a process. The company should document the system’s features, level of inference, autonomy and outputs.

Determine your role for every AI system

A company can hold several roles under the AI Act. It may be a deployer of one system and a provider of another.

Provider

A provider develops an AI system or general purpose AI model and places it on the market or puts it into service under its own name or trademark.

A company may also assume provider responsibilities if it makes a substantial modification to another organisation’s system, changes its intended purpose or places the system on the market under its own identity.

Deployer

A deployer uses an AI system under its authority for professional activities.

Many companies purchasing AI software will act as deployers. However, they still need to understand the system, follow the provider’s instructions, assign oversight and monitor its use where required.

Importer

An importer places an AI system bearing the name or trademark of a provider established outside the EU on the European market.

Importers must verify that the provider has completed the relevant compliance steps before making the system available.

Distributor

A distributor makes an AI system available in the EU supply chain without acting as its provider or importer.

Distributors need to check the required documentation and take action if they believe the system is not compliant.

Product manufacturer

A manufacturer may become responsible where an AI system is placed on the market with a regulated product under the manufacturer’s name or trademark.

This is especially important for products covered by European product safety legislation.

General purpose AI model provider

An organisation developing and supplying a general purpose AI model has a separate set of obligations. Additional requirements apply when the model presents systemic risk.

The role decision should be recorded for every system. PrivaLex recommends documenting the facts behind the decision, particularly where the company modifies an external model or incorporates it into its own product.

How EU AI Act requirements change by role

The following table provides a general comparison. The requirements for an individual organisation depend on the facts of the system and its use.

Role	Typical responsibilities	Evidence the organisation may need
Provider	Classification, risk management, documentation, testing, conformity assessment, registration, monitoring and incident response	Technical documentation, risk records, test results, logs, instructions, declarations and monitoring reports
Deployer	Proper use, human oversight, input data controls, monitoring, transparency and incident escalation	Use approvals, oversight records, staff instructions, monitoring records, notices and incident reports
Importer	Verification of provider compliance, documentation checks and cooperation with authorities	Provider documentation, conformity records, registration checks and commercial records
Distributor	Verification before distribution and action where noncompliance is suspected	Product checks, supplier records, notices and corrective action records
Product manufacturer	Integration of AI requirements with relevant product safety obligations	Product technical files, risk assessments, testing and conformity evidence
General purpose AI model provider	Model documentation, downstream information, copyright compliance and training content summary	Model documentation, copyright policy, information packages and published summaries

Create an accurate AI system inventory

An organisation cannot comply with the AI Act if it does not know where AI is being developed, purchased or used.

The inventory should cover internally developed systems, AI features embedded in software, external models, application programming interfaces, copilots, automated scoring tools, experimental systems and AI used within business processes.

Each record should identify the system’s purpose, business owner, technical owner, provider, data, users, affected individuals, regulatory role and preliminary classification. It should also reference assessments, contracts, instructions, controls and evidence.

The inventory should remain active throughout the system’s lifecycle. Procurement, privacy, security and technology teams should be able to register new systems and report material changes.

Companies establishing this foundation can compare different AI system inventory tools. PrivaLex can then help determine which information those tools should collect and how the inventory should connect with legal and operational decisions.

Check for prohibited AI practices

The organisation should examine prohibited practices before completing a wider risk classification. If an activity is prohibited, ordinary risk controls will not make it acceptable.

Prohibited practices include certain forms of harmful manipulation, exploitation of vulnerabilities, social scoring and criminal risk prediction based solely on profiling. The Act also restricts particular uses involving facial image databases, emotion recognition, biometric categorisation and remote biometric identification.

The European Commission’s guidelines on prohibited AI practices provide explanations and practical examples.

Companies should include prohibited practice screening in procurement, product development and approval workflows. Employees also need a clear route for escalating uncertain use cases before the system is purchased or deployed.

Determine whether the system is high risk

High risk classification depends on the purpose and context in which the system is used.

A system may be high risk because it is a safety component of a regulated product or because it falls within a use case identified in Annex III of the AI Act.

Relevant areas include biometrics, critical infrastructure, education, recruitment, worker management, access to essential services, creditworthiness, certain insurance decisions, law enforcement, migration, border control and the administration of justice.

Not every system operating in one of these areas will necessarily be high risk. The company must assess the precise intended purpose, decision making role and applicable exclusions.

The reasoning should be documented. A system name, supplier statement or selection from a dropdown menu is not enough to support the classification.

The updated timetable introduced by Regulation (EU) 2026/1744 provides that obligations for systems classified as high risk under Article 6(2) and Annex III apply from 2 December 2027. Requirements for high risk systems connected with regulated products under Annex I apply from 2 August 2028.

The additional time should be used to establish controls and documentation. Delayed application does not remove the need to identify affected systems, correct unsuitable supplier arrangements and prepare the required compliance system.

7 Requirements for providers of high risk AI systems

Providers carry the most extensive responsibilities. They need a compliance system covering the complete lifecycle of the AI system.

1. Risk management

The provider needs a documented and continuous risk management process. It should identify foreseeable risks, evaluate their likelihood and severity, establish controls and assess whether residual risks are acceptable.

Risk management should continue after deployment and incorporate monitoring, complaints and incident information.

2. Data governance

Training, validation and testing data must meet relevant quality requirements. The provider should document data sources, preparation, assumptions, known limitations and measures used to identify errors or bias.

The required controls will depend on the system’s purpose and the individuals who may be affected.

3. Technical documentation and records

Technical documentation should explain how the system was designed, developed, tested and intended to operate. It should allow relevant authorities and assessors to determine whether the system complies with applicable requirements.

High risk systems must also support appropriate logging. Logs can help reconstruct system operation, investigate incidents and support post market monitoring.

4. Information and human oversight

Deployers need clear information about the system’s capabilities, limitations, intended purpose and correct operation.

High risk systems must be designed so that people can understand relevant outputs, recognise inappropriate reliance and intervene where necessary. The oversight arrangement should reflect the nature of the system and the consequences of its decisions.

5. Accuracy, robustness and cybersecurity

Providers must establish suitable levels of accuracy, robustness and cybersecurity. They should define performance measures, test the system under relevant conditions and respond to vulnerabilities or unexpected behaviour.

6. Quality management and conformity

A provider needs a quality management system covering responsibilities, procedures, documentation, testing, suppliers, changes, monitoring and corrective action.

The provider may also need to complete a conformity assessment, register the system and satisfy other product compliance requirements before placing it on the market.

7. Post market monitoring

The provider must monitor the system after deployment and use the information collected to identify new risks or compliance failures.

Monitoring should connect with complaints, incidents, technical changes and feedback from deployers.

Requirements for deployers of high risk AI systems

A company using a high risk AI system does not inherit every provider obligation. However, it remains responsible for how the system is used within its organisation.

Deployers must generally follow the provider’s instructions, assign appropriately trained people to human oversight and ensure that input data under their control is relevant and sufficiently representative. They also need to monitor system operation and preserve logs under their control where required.

If a serious risk, incident or unexpected behaviour is identified, the deployer may need to stop or restrict use and inform the provider or relevant authority.

Where high risk AI is used in the workplace, affected employees and worker representatives may need to be informed before deployment. If the system assists in making decisions about individuals, additional information duties can apply.

Certain deployers, including public bodies and organisations providing public services, may need to complete a fundamental rights impact assessment before using relevant systems. Similar requirements can apply to particular systems used for creditworthiness or insurance decisions.

The organisation should confirm whether a fundamental rights impact assessment is required rather than treating it as a universal obligation for every deployer.

Meet the transparency requirements

Some AI systems trigger transparency obligations even when they are not classified as high risk.

These requirements can apply to systems that interact directly with people, generate synthetic content, perform emotion recognition or use biometric categorisation. They can also apply to deepfakes and AI generated text published to inform the public on matters of public interest.

The correct disclosure depends on the system and the organisation’s role. Providers may need to ensure that synthetic outputs are marked in a machine readable format. Deployers may need to inform people that they are interacting with AI or that particular content has been artificially generated or manipulated.

Transparency information should be clear, accessible and provided at an appropriate time.

The European Commission published AI transparency obligations to support implementation of Article 50. These obligations have applied since 2 August 2026.

Address general purpose AI model obligations

Companies should distinguish between using a general purpose AI model and providing one.

An organisation that integrates an external model into a product is not automatically the provider of that underlying model. However, it may become the provider of the resulting AI system and will need to assess its obligations accordingly.

Providers of general purpose AI models need to maintain technical documentation, provide information to downstream system providers, establish a policy for compliance with EU copyright law and publish a sufficiently detailed summary of training content.

Providers of models with systemic risk face additional requirements relating to model evaluation, systemic risk assessment, incident reporting and cybersecurity.

The General Purpose AI Code of Practice is a voluntary tool that can help model providers demonstrate how they meet relevant transparency, copyright, safety and security obligations.

Companies using external models should obtain sufficient information from the provider to understand limitations, acceptable uses and downstream responsibilities.

Provide appropriate AI literacy

Providers and deployers must take measures to ensure an appropriate level of AI literacy among staff and other people operating AI systems on their behalf.

The level of training should reflect the person’s role, technical knowledge, the type of system and the potential impact on affected individuals.

A general awareness session may be appropriate for employees using approved productivity tools. People approving sensitive systems, reviewing automated decisions or monitoring technical performance will require more specialised training.

The company should maintain evidence of the measures provided. Useful records include training materials, attendance, role specific instructions, completed assessments and refresher activities.

Review AI suppliers and contracts

Most organisations depend on external suppliers for AI software, models, infrastructure or data. Supplier documentation is therefore part of the company’s compliance system.

Due diligence should cover four main areas:

• The intended purpose, limitations, classification and regulatory roles.
• Data sources, testing, performance, security and human oversight.
• External models, subcontractors, updates and material changes.
• Documentation access, incident support and cooperation with authorities.

Contracts should address documentation access, material changes, incidents, data use, audit assistance, security, responsibility and termination support.

The company should not accept a general statement that a product is compliant without examining what the claim covers and which responsibilities remain with the deployer.

PrivaLex can help turn supplier responses into a structured decision rather than leaving completed questionnaires in a procurement folder. It can also identify which evidence should be contractual, which should be reviewed periodically and which issues require escalation.

How PrivaLex can help with EU AI Act compliance

Understanding the regulation is only the beginning. The harder part is translating it into responsibilities, workflows and evidence that legal, technology, privacy, security, procurement and business teams can maintain.

PrivaLex helps organisations determine what the AI Act requires based on their actual systems, roles and markets. For organisations still assessing the regulatory framework, the EU AI Act explained: who it affects and what it requires provides a useful overview of the regulation, its risk categories and key obligations.

The work begins with the company’s current AI use, rather than a generic collection of policies or assessment templates.

A typical engagement can include:

• Mapping AI systems, models, suppliers and regulatory roles.
• Screening prohibited practices and reviewing risk classifications.
• Creating obligation registers, policies and approval workflows.
• Designing risk and impact assessment methods.
• Establishing human oversight, transparency and AI literacy measures.
• Reviewing suppliers, contracts and supporting evidence.
• Connecting AI Act work with GDPR, security and procurement.
• Preparing evidence for customers, auditors and regulators.

PrivaLex can also help the organisation decide what level of governance is proportionate. A company using a limited number of standard AI tools may need an inventory, acceptable use rules, supplier checks and basic oversight. A provider placing sensitive AI systems on the European market will require a more extensive compliance and technical documentation programme.

Where the organisation wants to formalise its operating model, PrivaLex can align the programme with ISO 42001 as an AI governance framework. The AI Act and ISO 42001 can work together by connecting regulatory obligations with structured governance, risk management, documentation and continual improvement.

PrivaLex can also distinguish between evidence the organisation must create, information that should come from suppliers and assessments requiring independent technical or conformity review. This prevents internal teams from accepting unsupported vendor claims or creating documents that do not demonstrate how controls work in practice.

The aim is not to increase paperwork. It is to create a compliance system that people can operate on and that clearly explains what each AI system does, which obligations apply, who is responsible and what evidence demonstrates compliance.

PrivaLex is not a notified body and does not replace an independent conformity assessment where one is legally required. Its role is to help the organisation establish, document and test the system that management and any independent assessor will need to examine.

Connect the AI Act with GDPR and other requirements

AI Act compliance does not replace GDPR compliance. When an AI system processes personal data, both legal frameworks may apply.

The organisation may need to address lawful basis, transparency, data minimisation, special category data, data protection impact assessments, automated decision making, individual rights, international transfers, security and retention.

Privacy, AI, security and supplier assessments should reference one another. Maintaining separate and inconsistent descriptions of the same system creates unnecessary risk.

Organisations may also need to consider product safety rules, consumer law, employment law, accessibility, intellectual property, sector regulation and contractual requirements.

For a broader explanation of these overlaps, companies can review the AI regulatory compliance framework.

Maintain a practical AI Act compliance file

The company should be able to retrieve the records supporting its compliance position without reconstructing them before an audit, customer review or regulatory request.

A practical compliance file should cover:

• Inventory, role decisions and risk classifications.
• Policies, approvals, assessments and escalation records.
• Supplier documents, contracts and instructions.
• Technical documentation, testing and data governance evidence.
• Training, human oversight and transparency records.
• Logs, monitoring, incidents, changes and corrective actions.

These records do not all need to sit in one platform. They do need consistent ownership, references, version information, review dates and access controls.

PrivaLex can help design this evidence structure and configure it within the company’s existing GRC, privacy, document management or workflow environment. If new software is required, PrivaLex can also define the functional criteria the company should use when comparing tools that support AI Act compliance.

Is ISO 42001 required for AI Act compliance?

ISO 42001 certification is not generally required by the AI Act. It is a voluntary international standard for establishing and improving an AI management system.

The standard can help organise governance responsibilities, policies, objectives, risk assessments, controls, suppliers, documentation, internal audits, management reviews and continual improvement.

ISO 42001 does not determine whether a system is prohibited or legally high risk. It also does not replace conformity assessment where the AI Act requires one.

Its value is operational. It gives the organisation a repeatable management system for maintaining controls and evidence instead of treating every AI system as a separate compliance project.

PrivaLex uses this management system approach when it is proportionate to the organisation’s size, risks and commercial objectives. Certification may be appropriate for some companies, while others may benefit from applying the structure without immediately pursuing certification.

Conclusion

EU AI Act compliance does not begin with buying software or downloading a policy template. It begins with understanding what AI the organisation uses, what role it holds and how each system is classified.

From there, the company can apply the correct obligations. For some organisations, this may mean supplier reviews, transparency notices and AI literacy. For providers or deployers of high risk systems, the programme may also require formal risk management, technical documentation, testing, human oversight, conformity activities and ongoing monitoring.

The compliance system should remain proportionate, but it must also remain current. New models, suppliers, purposes and technical changes can alter the organisation’s responsibilities. Inventory, classification, evidence and review therefore need to become part of ordinary business operations.

PrivaLex can help connect these requirements into a practical governance model that works across legal, privacy, security, technology and procurement teams. Companies seeking a structured management system for these responsibilities can explore ISO 42001 implementation and certification support.

Frequently Asked Questions (FAQs)