EU AI Act: practical compliance for the enterprise

What the AI Act actually changes

The European regulation on artificial intelligence (the AI Act) is not a marketing badge. It is a framework of obligations proportionate to the risk of the system. For a CIO, CISO, or compliance lead, the question is no longer “do we have AI?” but “which regime applies to this use case, with these data, this autonomy, this impact on people?”

Teams already running agents, RAG, or industrial vision often discover a gap: the POC works, the vendor promises compliance, and nobody has classified the system or defined who carries the duty (provider vs deployer). The AI Act forces exactly that work (classification, documentation, governance, human oversight) before volume or an incident does it for you.

This article turns the text into concrete actions for an enterprise AI platform: how to classify, which obligations to keep, how to produce evidence you can reuse (logs, audit, oversight), and where data sovereignty meets compliance.

Classification: start from the use case, not the model

The AI Act thinks in systems, not model brands. The same LLM can power a low-risk HR assistant and a scoring flow that affects access to a service, two different regimes. Classification depends on purpose, context, and sometimes the annex of high-risk domains (employment, education, essential services, critical infrastructure, and more).

Four levels useful for internal prioritization:

1. Prohibited practices: subliminal manipulation, citizen-style social scoring, exploitation of vulnerabilities, certain real-time biometric uses in public space (with strict exceptions). If your use case looks like this, stop and requalify, do not “mitigate” a ban.
2. High-risk: systems listed or used in sensitive domains where impact on rights and safety is high. This is where most heavy obligations live (risk management, data governance, technical documentation, logging, transparency, human oversight, accuracy / robustness).
3. Limited risk: mainly transparency duties (e.g. disclose that the user is interacting with AI, marking of certain synthetic content).
4. Minimal risk: no heavy AI Act-specific duties; good practices (security, privacy, quality) remain recommended and often required by other texts (GDPR, NIS2, sector rules).

High-risk: what changes

Risk management, data governance, documentation, logs, and human oversight: provable, not declarative.

Pragmatic method: for each use case, write a one-page sheet: purpose, users, decisions made or assisted, personal / sensitive data, autonomy level, impact on error. Have it classified by a business + compliance pair (not by the vendor alone). Revisit the sheet when autonomy rises (assisted → semi-autonomous) or when new write tools are connected.

Concrete obligations for high-risk systems

If your system falls under high-risk (or you anticipate it to avoid a late requalification), translate the articles into operational controls:

Risk management

Not a frozen PDF: a cycle. Identify risks (bias, drift, bad RAG citation, out-of-scope tool action), assess severity / likelihood, treat (guardrails, thresholds, fallback), retest after a model or prompt change. Tie this cycle to releases, as you would for a critical ERP change.

Data governance

Origin of training / fine-tuning / evaluation sets, relevance criteria, handling of known biases, train / eval separation, traceability of RAG sources. For a deployer who does not train, still document the inference data perimeter: what goes to the model, what stays in retrieval, what is logged.

Technical documentation and instructions

Architecture, model versions, usage limits, expected / out-of-scope behavior. Instructions for professional users must be readable by the business, not only by the AI lab. Version them with the system.

Recording and traceability

Logs that reconstitute relevant events: input (within privacy limits), model / version, tools called, policies triggered, output, human approvals. Without a replayable timeline, you do not have evidence, you have an anecdote.

Transparency and human oversight

A human must be able to understand, contest, and take back control on sensitive decisions. “An Approve button” is not enough without context, alternatives, and an identifiable owner. Define the thresholds where the agent stops.

Accuracy, robustness, cybersecurity

Measures under load, degraded modes, resistance to prompt / data injection, access control to tools. Here the AI Act meets your existing security posture, do not create an “AI compliance” silo disconnected from the SOC.

Audit and traceability

One timeline: input, plan, tools, policies, output, human validation. Otherwise compliance stays declarative.

Provider, deployer, integrator: who carries what?

The text distinguishes roles. In enterprise practice:

• Provider: places the system on the market (often the platform or model vendor).
• Deployer: uses the system under its authority (your organization).
• Importer / distributor: supply-chain roles.

Many projects are hybrid: you deploy AI for leaders (or equivalent) with your connectors, prompts, and policies. You become co-responsible for the compliance of the system as operated. Contractually require: documentation, exportable logging capabilities, audit support, commitment on regulatory updates. Reject black boxes that say “trust us, we're compliant” without artefacts.

General-purpose AI models (GPAI) add a layer: transparency duties and, for the most powerful ones, evaluation and systemic-risk management on the provider side. That does not free the deployer from classifying their use case.

Application calendar: key dates and what to anticipate

The AI Act (Regulation (EU) 2024/1689) applies in waves. The Digital Omnibus on AI deferred high-risk Annex III / Annex I obligations, useful for planning, not for pausing work. For the official timeline and framework, see also the Commission AI Act page. Anchor these milestones in a CIO / compliance calendar, with what you should have ready before each deadline.

1 August 2024: Entry into force

The regulation is published and the clock starts. No operational duties are enforceable yet, but the legal frame is fixed.

Anticipate: name a sponsor (IT / compliance), define the enterprise “AI systems” perimeter, and start the inventory, otherwise later waves arrive without a map.

2 February 2025: Prohibited practices and AI literacy

Chapter I (definitions, literacy) and Chapter II (prohibitions) apply. Unacceptable-risk practices are banned: this is not a mitigation regime. Article 4 requires proportionate AI literacy measures for teams that design, deploy, or oversee systems.

Have ready beforehand: review of sensitive use cases (biometrics, social scoring, emotion in workplace / education, facial scraping…); stop or redesign if a case falls under a ban; a proportionate literacy / training plan (not a cosmetic certificate); a clear RACI for go / no-go decisions.

2 August 2025: GPAI, governance, and penalties

Obligations for providers of general-purpose AI (GPAI) models, governance structures (national authorities, AI Office), and an operational penalty regime. As a deployer, you depend on the artefacts your GPAI / platform vendor can produce.

Have ready beforehand: vendor contract review (technical documentation, training-data / copyright summary, audit rights, regulatory updates); requirements for exportable logs and instructions for use; clear provider vs deployer roles per platform; exit black-box vendors that cannot produce evidence.

2 August 2026: General application and transparency

General application date: most remaining rules apply, including transparency duties (Article 50), chatbot / AI interaction disclosure, marking of certain synthetic content, notices for certain biometric / emotion uses. Enforcement of already-applicable provisions densifies.

Have ready beforehand: up-to-date inventory and stable classification; UX disclosures (“you are interacting with AI”); marking / watermarking policy if you generate synthetic content; authority-response procedures; GDPR / NIS2 alignment on one control map.

2 December 2026: Additional prohibitions and marking transition

New prohibitions (including non-consensual sexual / CSAM generated or manipulated content) and a transitional deadline for certain providers already on the market regarding synthetic-content marking (Article 50(2)).

Have ready beforehand: review of generative pipelines (image, video, audio, text); usage and distribution controls; a marking-compliance calendar for systems placed before August 2026.

2 December 2027: High-risk Annex III systems

Core obligations for high-risk systems listed in Annex III (employment, education, essential services, critical infrastructure, permitted biometrics, etc.), deferred by the Digital Omnibus. This is the structural deadline for most enterprise “business” deployments.

Anticipate 12–18 months ahead (from 2026): final Annex III classification vs Article 6(3) filter; named owner + living risk register; inference / RAG data governance; versioned technical documentation; replayable logging; human oversight with thresholds; QMS / conformity criteria; declaration / registration prep; incident tabletop. Do not start technical docs in Q4 2027.

2 August 2028: High-risk embedded in Annex I products

AI systems that are safety components of already regulated products (medical devices, machinery, etc.). AI Act compliance intersects the existing sectoral regime.

Anticipate: if you are a manufacturer / integrator of regulated products, align product and AI conformity files (same assessment cycle, same post-market monitoring); otherwise, verify that critical-component vendors have a credible 2028 plan.

Operational compliance rollout

A realistic quarter-long roadmap, schedule it against the calendar above, not instead of it:

Weeks 1–2: Inventory. List AI systems in prod, pilot, and shadow IT (business copilots included). One row = one use case, not one vendor.

Weeks 3–4: Classification. Business + legal/compliance workshops. Mark prohibited / high-risk / limited / minimal. Escalate grey zones (temporary over-classification beats a blind spot).

Month 2: Missing controls. For each high-risk (or candidate): owner, risk register, logging policy, human-oversight points, exit criteria from pilot. Connect audit exports to your existing compliance tool where possible.

Month 3: Evidence and routines. Tabletop exercise: a bias incident / bad tool action / context leak. Check that N2 + compliance can rebuild the timeline. Fold AI Act review into CAB / risk committees.

Sovereignty, models, and the AI Act: the same perimeter

AI Act compliance and sovereign AI are not separate topics. Data residency, log control, choice of a model catalog (local SLM vs external API), and the data perimeter determine what you can prove:

• If inference leaves the EU without guarantees, data governance and traceability get fragile.
• If you do not control model versions or tool policies, technical documentation lies.
• If a human cannot see the agent's plan, oversight is cosmetic.

A useful enterprise platform therefore provides: assisted use-case classification, per-role policies, exportable audit, deployment in your perimeter, and multi-model routing without losing the evidence trail.

“AI Act compliance is won in logs and process, not on the launch slide.”

Actionable checklist

Before promoting a use case to production:

• Signed classification sheet (business + compliance)
• Named owner (product / IT) and vendor RACI
• Living risk register, tied to releases
• Inference and RAG data perimeter documented
• Logging: replayable timeline, defined retention, controlled access
• Human-oversight thresholds and contestation procedure
• User transparency if “limited risk” regime or sector duty applies
• Degraded modes and incident plan (bias, tool, model down)
• Vendor contract review (docs, audit rights, regulatory updates)
• GDPR / NIS2 / sector alignment, one control map if possible

Conclusion

The AI Act rewards organizations that treat AI as an operable system: classified, documented, supervisable, auditable. It penalizes POCs that skipped governance. The good news: the same foundations (perimeter, logs, scoped tools, human-in-the-loop) are those of a production AI platform, not a parallel burden.

To ground data control, read data and AI: the sovereign perimeter; for model building blocks, the 8 specialized model types; for the strategic “why”, why sovereign AI matters.