The EU AI Act entered into force in August 2024, and its obligations have been rolling out in phases since then. Prohibited practices became enforceable in February 2025. General-purpose AI (GPAI) model obligations — which apply to the providers of frontier models like GPT-4, Claude, and Gemini — became applicable in August 2025. The most consequential phase for enterprise deployers arrives in August 2026: Annex III high-risk AI system requirements, which apply to any organisation that deploys AI in high-risk contexts including employment, education, credit, essential services, law enforcement, migration, and justice.

This guide is a practical compliance checklist for enterprise deployers — organisations that use AI tools built by others, rather than organisations that train and publish AI models. Providers (OpenAI, Anthropic, Google, Microsoft) have their own set of obligations; this guide focuses on what deployers must do.

The EU AI Act structure in brief

The Act creates four risk categories:

Prohibited AI practices (Article 5) — banned outright, enforceable from February 2025. These include social scoring systems by public authorities, untargeted scraping of facial images to build recognition databases, real-time biometric identification in public spaces (with narrow law-enforcement exceptions), emotion recognition in workplaces and educational institutions, AI that exploits vulnerabilities of specific groups, and subliminal manipulation techniques.

High-risk AI systems (Annex III) — permitted but subject to significant pre-deployment and ongoing obligations, enforceable from August 2026 for systems already on the market. Covers AI in eight domains: biometrics and biometric categorisation, critical infrastructure, education and vocational training, employment and workers management, access to essential private services, law enforcement, migration and border control, and administration of justice.

Limited risk (Article 50) — transparency obligations only. AI systems that interact with humans must disclose they are AI. Deepfakes must be labelled. Enforceable from August 2025.

Minimal risk — the broad remainder. No specific obligations under the Act, though other law (GDPR, product liability) still applies.

Most enterprise AI use — using ChatGPT or Claude for drafting, summarising, or researching — falls in the minimal-risk category. The high-risk category applies only when AI is used as a substantial component in decisions about employment, credit, benefits, or similar consequential outcomes.

Phase 1: Prohibited practices (February 2025) — checklist

These are absolute prohibitions. There is no compliant version of a prohibited practice.

[ ] No social scoring systems. AI systems that evaluate individuals' trustworthiness based on social behaviour or personal characteristics for purposes unrelated to the context of data collection are prohibited. This includes employee monitoring systems that generate behavioural scores for HR decisions.
[ ] No untargeted biometric scraping. Building or expanding facial recognition databases by scraping images from the internet or CCTV without authorisation is prohibited. Any existing systems in this category should have been decommissioned by February 2025.
[ ] No real-time remote biometric identification in public spaces — except for specifically authorised law enforcement purposes. Commercial operators (retailers, venues) cannot deploy live facial recognition of members of the public.
[ ] No emotion recognition at work or school. AI systems that infer the emotions of workers during the performance of their duties, or students in educational settings, are prohibited. This includes affect-detection tools in video interviews and proctoring software that infers emotional states.
[ ] No exploitation of vulnerabilities. AI systems designed to exploit age, disability, or social or economic circumstances to materially distort behaviour in harmful ways are prohibited.
[ ] No subliminal manipulation. AI that operates below a person's level of consciousness to influence behaviour in a way that causes harm is prohibited.

If any of the above are in scope for your organisation, cease operation and document the decision. There is no grandfathering for prohibited practices.

Phase 2: GPAI provider obligations (August 2025) — what deployers need from providers

GPAI obligations run to providers, not deployers. But deployers need evidence that their AI providers are meeting them.

[ ] Request GPAI technical documentation from your AI vendors. Under Article 52, GPAI providers must maintain and make available technical documentation including model architecture, training data sources and policies, and performance evaluation results. Add this to your vendor risk management file.
[ ] Confirm training data copyright compliance. Providers must publish a summary of training data and comply with the Article 53(1)(d) copyright policy requirement. For providers who have published this information (Anthropic, OpenAI, Google DeepMind), verify the disclosure is current.
[ ] Note which providers have experienced serious incidents. Article 62 requires providers to report serious incidents to the AI Office. Ask your providers whether any reportable incidents have occurred.
[ ] Systemic risk providers (frontier models). The highest-capability GPAI models are subject to additional obligations including adversarial testing, model evaluations, and cybersecurity incident reporting. OpenAI, Anthropic, and Google are expected to be designated systemic-risk providers. Request evidence of their compliance with these obligations.

For most deployers using established AI providers, the primary action is adding GPAI compliance to vendor due diligence — requesting the technical documentation and verifying it exists, rather than performing the compliance yourself.

Phase 3: High-risk AI systems (August 2026) — deployer obligations checklist

This is where deployers face the heaviest direct obligations. The following checklist applies to any organisation deploying AI in an Annex III high-risk context.

Step 1: Determine whether your AI use is high-risk

High-risk contexts under Annex III:

Employment: AI used for recruitment, CV screening, interview evaluation, promotion, task allocation, performance monitoring, or termination decisions. This includes tools that rank applicants, score interviews, or generate recommendations for HR decisions.
Education: AI used for admission, assessment, grading, or monitoring of students in educational institutions.
Essential private services: AI used in creditworthiness assessment, credit scoring, insurance risk assessment, or prioritisation of emergency services.
Law enforcement: AI used to assess crime risk, analyse evidence, or assist in investigations.
Migration and border control: AI for risk assessment of travellers, asylum claim processing, or border checks.
Justice: AI assisting courts or arbitration bodies in interpreting facts or applying law.
Critical infrastructure: AI operating systems in energy, water, transport, or digital infrastructure.
Biometric systems: AI that categorises individuals based on biometric characteristics.
[ ] Inventory all AI systems in use across the organisation.
[ ] For each system, determine whether it is used as a substantial component in a decision that affects a natural person in one of the above domains.
[ ] Document the determination. If high-risk, proceed with the full checklist below. If not high-risk, document why and retain for audit.

A key clarification: using ChatGPT to draft a job description is not high-risk. Using a tool to score and rank job applicants, or to recommend which applicants to interview, is high-risk. The distinction is whether the AI meaningfully participates in a consequential individual decision.

Step 2: Risk management system (Article 9)

[ ] Establish a risk management process for each high-risk AI system. This is a cycle — not a one-time exercise. It includes: identification and analysis of known and foreseeable risks, estimation of risks that materialise if controls fail, evaluation of risks after mitigations, and adoption of measures to address remaining risks.
[ ] Document the risk management process and maintain records.
[ ] Update the risk management process when the system, its use, or the regulatory environment materially changes.

Step 3: Data governance (Article 10)

[ ] Review the training data used in each high-risk AI system for relevance, representativeness, and freedom from errors that could bias decisions.
[ ] If you receive AI services from a third party (most enterprise deployers do), request data governance documentation from the provider demonstrating that Article 10 requirements were met during training.
[ ] Document your data governance review.

Step 4: Technical documentation (Article 11)

[ ] Obtain or create technical documentation for each high-risk AI system. For off-the-shelf systems (HR screening tools, credit-scoring AI), request the provider's Article 11 documentation. For custom or fine-tuned systems, document your own.
[ ] Retain technical documentation for ten years after the system is taken out of service.

Step 5: Record-keeping and logging (Article 12)

[ ] Confirm that each high-risk AI system has automatic logging capabilities to the extent technically feasible.
[ ] Ensure logs allow tracing of decisions to specific inputs and to the system version that generated them.
[ ] Retain logs for at least six months (longer if sector-specific rules require it; financial services typically require longer).

Step 6: Transparency to users (Article 13)

[ ] Ensure that natural persons interacting with a high-risk AI system are informed that they are doing so, unless obvious from context.
[ ] Provide information to operators sufficient to allow meaningful oversight: the system's capabilities and limitations, level of accuracy, conditions for reliable operation, and criteria for human oversight.
[ ] Document the transparency disclosures made.

Step 7: Human oversight (Article 14)

This is often the most operationally significant obligation for deployers.

[ ] Designate individuals ("operators" under the Act) who are responsible for overseeing the high-risk AI system's outputs.
[ ] Ensure those individuals have the competence, authority, and capacity to actually review and override the system's outputs.
[ ] Establish a procedure for rejecting, correcting, or escalating AI decisions that appear erroneous, inconsistent, or discriminatory.
[ ] Do not configure high-risk AI systems to make final decisions without human review. The Act requires meaningful oversight — rubber-stamping AI outputs does not satisfy Article 14.
[ ] Document the oversight procedure and retain records of material decisions.

Step 8: Accuracy, robustness, and cybersecurity (Article 15)

[ ] Verify the accuracy levels claimed by your AI provider against the metrics required for your specific use case.
[ ] Assess robustness against errors, faults, and adversarial inputs relevant to your deployment context.
[ ] Apply appropriate cybersecurity controls to the AI system, including access controls and incident-response procedures.

Step 9: Conformity assessment (Article 43)

[ ] For internally developed high-risk AI systems: complete a conformity assessment and, if the system falls in specific categories (biometrics, certain critical infrastructure), involve a notified body.
[ ] For third-party high-risk AI systems: verify the provider has completed the relevant conformity assessment and obtained the required CE marking.
[ ] For off-the-shelf AI components integrated into your product: understand where provider obligations end and deployer obligations begin; this is an active area of regulatory interpretation.

Step 10: Registration (Article 49)

[ ] Register high-risk AI systems in the EU database (eu.aiact.db — the Commission is building this). Registration is required before placing a high-risk system in service. Check the Commission's current registration portal and requirements; they continue to evolve.

Step 11: Post-market monitoring (Article 72)

[ ] Establish a post-market monitoring plan for each high-risk AI system. This should include systematic collection of data on system performance, adverse outcomes, and user feedback over the system's operational life.
[ ] Assign responsibility for monitoring and set review cadences.
[ ] Report serious incidents to the relevant national market surveillance authority within 15 days (Article 73).

The GDPR-AI Act overlap

The AI Act and GDPR are complementary and frequently overlap:

High-risk AI Act classification is essentially per se DPIA-triggering under Article 35 of the GDPR. If you've determined a system is high-risk under Annex III, you almost certainly need a DPIA.
Article 10 data governance obligations mirror GDPR's data-minimisation and data-quality requirements.
Article 14 human oversight intersects with GDPR's Article 22 restrictions on solely automated decisions with legal or similarly significant effects.
Article 50 transparency overlaps with GDPR Articles 13–14 transparency obligations.

Practically, many organisations are aligning their AI Act compliance programs with their existing GDPR governance infrastructure. A DPIA that covers both frameworks is more efficient than two separate documents.

Sonomos and the AI Act

Sonomos is a local-first browser extension that detects and masks sensitive personal data before any prompt leaves the device. From an AI Act perspective, Sonomos provides:

Article 9 risk management support: pseudonymising personal data before it enters a high-risk AI system is a meaningful risk mitigation for the data-governance and accuracy risks the Act addresses.
Article 32 GDPR security measure: the same pseudonymisation that supports AI Act compliance satisfies the GDPR's Article 32(1)(a) technical measure requirement.
Audit evidence: Sonomos' local detection logs provide a record of what categories of personal data were detected and how they were handled — useful evidence for Article 9 risk management documentation.

Sonomos is not a conformity-assessment or registration tool. It is one component of the technical control layer that the AI Act expects to be in place for high-risk deployments.

Frequently asked questions

Does the EU AI Act apply to AI tools we use but didn't build?

Yes, for high-risk applications. The Act distinguishes between providers (who build and place AI systems on the market) and deployers (who use those systems in a professional context). Deployers of high-risk AI systems have obligations under Articles 9, 12, 13, 14, 15, 26, and 72 regardless of whether they built the system themselves.

We use a third-party HR screening tool. Is that high-risk?

Almost certainly yes. AI used for recruitment, CV screening, interview scoring, or employment decision support is explicitly listed in Annex III. The obligations for deployers include: risk management, ensuring the provider has provided Article 13 documentation, implementing human oversight, maintaining logs, and post-market monitoring.

Does the AI Act apply to AI used only internally?

Yes. The high-risk classifications in Annex III are not limited to systems sold to customers. AI used internally for employment management, credit decisions affecting employees, or other Annex III purposes is subject to the Act when it affects natural persons in the relevant domains.

When exactly do high-risk obligations apply?

The primary deadline is August 2026 for systems classified as high-risk that were on the market before the Act came into force. New systems placed on the market after August 2026 are subject to full requirements from deployment. Systems already in service before August 2026 have until August 2027 to comply (a one-year transition period for legacy systems).

What are the penalties for non-compliance?

Fines for prohibited practices: up to €35 million or 7% of global annual turnover. Fines for other violations (including high-risk failures): up to €15 million or 3% of global annual turnover. Fines for providing incorrect information to supervisory authorities: up to €7.5 million or 1% of global turnover. National market surveillance authorities are responsible for enforcement; the AI Office at the European Commission oversees GPAI provider obligations.

Is there a grace period for existing AI systems?

High-risk systems already in service before August 2026 have until August 2027 to meet all Annex III requirements. New systems deployed from August 2026 onward must comply from deployment. Prohibited practices had no grace period — they became enforceable in February 2025.

A practical timeline for enterprise deployers

Now: Audit all AI tools in use. Identify any that operate in Annex III domains. Document the analysis.

Q3 2025: Complete GPAI provider due diligence — obtain technical documentation from AI vendors, add to vendor risk files.

Q4 2025: For each high-risk system identified: begin risk management documentation, engage with providers on Article 11 technical documentation, design human-oversight workflows.

Q1–Q2 2026: Implement the full high-risk compliance stack: logging, transparency disclosures, oversight procedures, accuracy validation, post-market monitoring plans.

August 2026: Deadline for new high-risk systems. Ensure all high-risk AI in production meets Annex III requirements.

August 2027: Deadline for legacy high-risk systems.

The bottom line

The EU AI Act in 2026 is not a compliance hurdle for most enterprise AI users — the vast majority of generative AI use for drafting, research, and summarisation is minimal-risk and subject only to the Article 50 transparency disclosure obligation. The organisations that face substantial compliance work are those that use AI as a meaningful component in high-stakes decisions about employment, credit, education, or essential services.

For those organisations, the deadlines are real and the obligations are significant: risk management, human oversight, technical documentation, logging, registration, and post-market monitoring. The best time to start that work was before the Act came into force; the second-best time is now.

EU AI Act Compliance Checklist for Enterprise Deployers (2026)