EU AI Act and Compliance Basics

EU AI Act basics – what it means for your business

The EU AI Act does not ban AI for normal business use. It sets risk-based rules and expects you to keep AI lawful, transparent, and safe. In 2026, the practical work is readiness: map your AI use cases, classify risk levels, align with GDPR, and make sure vendors and logs do not create surprises later – especially as the main obligations apply from August 2026. Think of this as an EU AI Act compliance checklist that supports real shipping – not a paperwork project.

Most teams can start with a simple structure:

• Map use cases: where AI touches customers, employees, or important decisions.
• Tag risk: prohibited, high risk, or limited risk with clear transparency duties.
• Add oversight: decide where humans must review or approve AI outputs.
• Document: lawful basis, data sources, logging, vendors, and user notices.

If you only buy or use AI, you are classed as a deployer. Deployers still need lawful basis, transparency, logging, and oversight. Providers and manufacturers have extra duties such as technical documentation and, for high-risk systems, conformity assessment and CE marking.

Key EU AI Act compliance dates to track

The Act phases in over several years. In 2026, the key milestone to prepare for is 2 Aug 2026 when most remaining rules apply. Mark these dates early so you can update contracts, documentation, and audit trails in time – especially if you use general-purpose AI models or build internal assistants that touch sensitive workflows.

Once the dates are in your calendar, map responsibilities by role so you know who owns what.

Who is responsible – providers, deployers, and distributors

Your role decides which obligations apply. Many businesses are deployers only, but some also act as providers when they build, fine-tune, or sell AI systems in their own name.

Once you know your role, you can size the work using the official risk levels.

Risk levels under the EU AI Act and what they mean

The Act uses tiers to right-size controls. The same model can be limited risk in one context and high risk in another, depending on how you use it – especially when AI influences access to jobs, credit, education, healthcare, or critical services.

• Prohibited: manipulative or exploitative AI that seriously harms users, unlawful social scoring, and certain real-time remote biometric identification in public spaces.
• High risk: AI in hiring, credit, education access, medical or safety functions, or critical infrastructure. These require risk management, data governance, testing, logging, documentation, and human oversight.
• Limited risk: most business AI such as chatbots, content generation, summarisation, and analytics. These focus on transparency duties and user controls.

When in doubt, treat systems as at least limited risk and apply transparency and logging by default. GDPR still applies in all cases, so lawful basis and privacy controls are always required.

Data privacy, consent, and lawful basis for AI

The EU AI Act sits alongside GDPR. Every AI use case still needs a clear purpose, lawful basis, and data minimisation approach. You also need to decide when a DPIA (or an AI annex to an existing DPIA) is required.

GDPR alignment for AI projects

• Define purpose and lawful basis per use case such as contract, legitimate interests, or consent.
• Run a DPIA or DPIA annex for AI features that affect rights, shape outcomes, or use sensitive data.
• Minimise personal data in prompts, training sets, and logs, and apply retention limits.
• Use role-based access for prompts, datasets, fine-tunes, and evaluation sets.
• Add user-facing privacy notices that explain AI use in plain language.

Consent and training or fine-tuning

• Use explicit consent for biometric or special category data where you rely on consent.
• Filter scraped content for copyright and personal data risks where practical.
• Document dataset sources, licences, and removal processes for opt-out requests.

With lawful basis and purpose set, the next step is to make AI behaviour traceable.

Logging, record keeping, and audit trails

Logs should let you reconstruct important decisions without storing more personal data than you need. Aim for traceability and audit readiness – not a permanent transcript of everything users ever type.

What to log

• Prompts, system messages, parameters, and model version.
• Key outputs and scores that feed into decisions.
• Human overrides, the reason, and the final outcome.
• Incidents, drifts, and model or dataset updates.

Retention and security

• Use short retention for raw prompts and auto-redact PII where practical.
• Encrypt logs at rest and in transit and restrict access by role.
• Tag logs by use case so audits and data subject requests remain manageable.

Once you can reconstruct what happened, you need to be clear with users about when AI is in the loop.

Transparency, chatbot notices, and deepfake labels

Transparency duties are one of the easiest obligations to meet and often improve UX immediately. Users should never be surprised that they are dealing with AI.

• AI in use notice: tell users they are interacting with an AI assistant and how to reach a human.
• Data and limits: explain what data you use, known limitations, and escalation options.
• Deepfake disclosure label: add a visible label on AI-generated or synthetically altered images, audio, and video.
• Provenance: use watermarking or metadata where feasible and keep an internal provenance log.

With user expectations clear, turn to suppliers and contracts so the backend matches the front-end story.

Vendor due diligence and AI contracting

Vendors can make or break compliance. Your job is to understand their controls, decide if they are enough for your risk level, and lock protections into contracts – especially in 2026 as teams prepare for broader AI Act duties.

Due diligence checklist

• Security posture such as SOC 2 or ISO 27001, data location, SSO, and key management.
• Model lineage and documentation such as base models, fine-tunes, evaluations, and red teaming summary.
• Privacy posture such as processing locations, retention periods, and training on customer data options.
• Support and lifecycle such as incident SLAs, export options, and deprecation policy.

Contract clauses to add

• A DPA with purpose limitation and a clear sub-processor list.
• Audit rights for logs, evaluations, and security controls where proportionate.
• IP and copyright indemnities for generated content at the right risk level.
• Opt out of training on your data by default unless you clearly choose otherwise.

If you build or use high-risk AI, you also need a structured checklist before and after release.

High risk AI checklist – core requirements

High-risk systems need more formal controls. The goal is not to block projects, but to show that you understand risks and have a clear plan to manage them.

Before release

• Risk management plan and testing plan covering likely failure modes.
• Data governance controls and dataset documentation.
• Technical documentation and a model card template.
• Evaluation results for accuracy, robustness, and cybersecurity.
• Human oversight instructions and fallback paths when the system fails.
• Conformity assessment and CE marking where required by the Act.

After release

• Post-market monitoring and an issue register.
• Serious incident reporting workflow with clear triggers.
• Change management for model versions and datasets.

General purpose AI (GPAI) – what changed since August 2025

General-purpose AI models come with extra documentation and governance expectations. In 2026, even if you are only a deployer, you should collect provider documentation and mirror the relevant parts for your own deployments – so your AI use cases stay explainable, traceable, and contract-ready.

• Collect model documentation from providers including training sources, limitations, and evaluations.
• Use a simple model card template internally for major deployments.
• Respect copyright and data provenance controls at the API and application layers.
• Adopt parts of the GPAI Code of Practice where your provider supports them.

If your provider participates in a recognised GPAI code, use their documentation and policies to reduce your own admin load while still meeting your duties as a deployer.

Incident response, monitoring, and human oversight

The Act expects meaningful human oversight. That means more than a box on a form. People need to know when to intervene, how to escalate, and what signals to watch.

Oversight playbook

• Define when humans must review or approve an AI outcome.
• Set escalation routes for risky cases and vulnerable users.
• Use shadow testing before production and canary rollout for new models.

Monitoring signals

• Error rates, bias metrics, drift, and override frequency.
• Customer complaints, appeal patterns, and data subject requests.
• Security signals such as jailbreaks, prompt injection attempts, and data leakage tests.

Documentation templates – what to prepare now

You do not need a heavy framework to be compliant. A simple project folder with the right documents will already put you ahead of many teams – and makes 2026 readiness much easier.

Project folder checklist

• AI use case brief with lawful basis and purpose rationale.
• DPIA or AI annex and data mapping for the AI feature.
• Model card template and key evaluation results.
• User notices and deepfake disclosure label text.
• Audit log configuration and retention policy.
• Vendor due diligence file and DPA records.

Evaluation set basics

• Representative tasks and realistic edge cases.
• Fairness metrics where relevant to your domain.
• Security tests for prompt injection and data leakage.

If you still have questions on edge cases, the FAQ below addresses the most common ones for business teams.

Final thoughts – keeping EU AI Act compliance practical