The EU AI Act and Your GenAI Operating Model: A Compliance-Ready Blueprint

The EU AI Act does not ask you to stop deploying generative AI. It asks you to prove you deploy it deliberately. In practice that means an operating model rather than a policy: named risk owners, one intake funnel, risk classification before build, evaluation before deployment, monitoring after, and an evidence artefact at every step.

#What the AI Act Actually Requires

What this means for you: the Act is tiered by use case, not by technology, and the tier you land in decides how much of the rest of this article applies to you.

The EU AI Act is a risk-tiered regulation. Four tiers decide how much of it lands on you.

• Prohibited. A small set of practices are banned outright, including manipulative techniques, certain forms of social scoring, and specified biometric categorisation.
• High-risk. Defined consequential uses — employment decisions, creditworthiness assessment, access to essential services — carry the heaviest obligations: risk management, data governance, technical documentation, human oversight, and post-market monitoring.
• Transparency. Systems that interact with people or generate synthetic content must make that fact clear.
• Minimal risk. Everything else, with no new obligations attached.

General-purpose AI models sit alongside this scheme with their own provider-side duties around documentation and, for the most capable models, systemic-risk management.

#The Dates That Set Your Planning Horizon

Article 113 phases the obligations rather than switching them on at once. Treat the timeline as a planning horizon and check the specific obligation before you commit a date to a board paper.

• 2 February 2025. Prohibited practices and AI literacy duties applied.
• 2 August 2025. Obligations for general-purpose AI models, plus governance and penalty provisions.
• 2 August 2026. General application, including most high-risk obligations under Annex III.
• 2 August 2027. High-risk systems embedded in regulated products under Annex I.

#Provider or Deployer — the Distinction Most Enterprises Get Wrong

The provider develops a system and places it on the market, carrying the heavier documentation and conformity burden. The deployer uses an AI system under its own authority.

Deployer duties are lighter but real: use the system in line with its instructions, assign human oversight to competent people, feed it input data of appropriate quality where you control that data, monitor operation, and keep logs.

Most enterprises adopting GenAI are deployers. But the line moves. Substantially modify a system, fine-tune a model and offer it onward, or put your brand on an AI system, and you can inherit provider-grade obligations.

#Does Any of This Reach a UK-Only Business?

Under Article 2, a provider or deployer established outside the EU falls in scope wherever the output of its AI system is used in the Union. That captures a large share of UK enterprises regardless of where the model runs.

Those UK safeguards are specific: the affected person must be informed, able to make representations, able to obtain meaningful human intervention, and able to contest the outcome. What it takes to make that demonstrable in a running system is set out in the architecture behind decision traceability.

#Why GenAI, RAG, and Agents Expand the Compliance Surface

What this means for you: the control set that worked for predictive models does not transfer, and the three gaps below are where deployers get caught.

Classical predictive machine learning offered a compliance story auditors could follow: a training dataset, a versioned model, a scored output. Generative systems break that simplicity in three ways.

A governed model wrapped around an ungoverned document store is an ungoverned system.

The corpus behind a retrieval-augmented generation system needs ownership, quality criteria, and change control like any regulated dataset. Point-in-time evaluation stops being a control the moment the vendor ships a new model version, so you need re-evaluation triggered by upstream change, contractual notice where you can negotiate it, and version pinning where the vendor offers it.

Agentic systems compound all three. An agent that chains tools and takes actions has a larger action space than a chatbot, and its failure modes include doing things rather than only saying them. The operating model below treats agents as the highest-scrutiny intake category by default, and the question of whether an agent is the right tool at all is scored separately in our agentic AI readiness framework.

#The Operating Model: Roles, Gates, Artefacts

What this means for you: an operating model answers three questions — who decides, at which moments, and with what proof. If you cannot answer all three for a live system, it is ungoverned.

#The Three Load-Bearing Roles

Committees advise. These three roles decide.

If you cannot name them for a system, that system is ungoverned by definition.

#The Four Gates

Each gate carries a decision and an exit criterion. A gate is not passed until its artefact exists.

1. Use-case intake. Every proposed GenAI use enters one funnel — a light form capturing purpose, users, data touched, and consequence of failure — producing an inventory entry.
2. Risk classification. Each intake is mapped to an Act tier and a provider-or-deployer determination. Minimal-risk uses exit here with light-touch obligations, which is what preserves scrutiny for the systems that warrant it.
3. Pre-deployment evaluation. Before exposure to real users: task-quality evaluation against a defined test set, safety probing proportionate to the tier, groundedness checks for retrieval systems, and verification that transparency notices and oversight mechanisms actually work in the interface.
4. Post-deployment monitoring. Logged interactions, quality sampling, incident capture feeding re-evaluation, and defined triggers for re-running gate three — an upstream model update, a corpus change beyond threshold, or drift in output quality.

The exit criterion is a signed evaluation report, not a demo that went well.

#The Artefacts

Each gate emits evidence: the inventory record, the classification rationale, model or system cards describing capability and limitation, lineage documentation for the corpus and logs, evaluation reports, and monitoring summaries.

The discipline that makes audits cheap is generating these as by-products of the gates rather than reconstructing them when a regulator asks.

#Lifecycle Controls, Evidence, and Sign-Off

#Where the Data Disciplines Sit

What this means for you: two of the Act's deployer duties are data problems in disguise, and they are cheaper to solve with machinery you probably already own.

The Act's deployer duties include ensuring input data is relevant and of appropriate quality. In GenAI systems, input data mostly means the retrieval corpus and the runtime context — so stale policy documents in an index become confidently wrong answers with your company's name on them.

That makes corpus quality a compliance control: freshness thresholds, ownership checks, classification tagging, and validation that superseded content is retired. This is the same machinery mature data teams already run for analytics, pointed at a new consumer. Our DQ Sentinel practice wires those gates into ingestion and update pipelines.

#Where the Sibling Disciplines Take Over

Three of them carry depth this article deliberately does not. Governance as code covers how rules become version-controlled files a build pipeline can enforce. Adaptive data governance covers evaluating them automatically wherever a decision is made. And the data foundation disciplines beneath both decide whether any of it has reliable inputs to act on.

#A Phased Adoption Roadmap

What this means for you: sequencing matters more than speed — classification before evaluation, evaluation before monitoring.

• Phase 1 — inventory and classify. Find every GenAI use already running, including the unofficial ones. Most organisations discover the inventory is larger than leadership believed. Exit: a complete inventory with named owners.
• Phase 2 — stand up the gates. Appoint the three roles, publish the intake form, and run classification and pre-deployment evaluation on new initiatives first, then retrofit the highest-risk existing systems. Exit: no new GenAI deployment reaches users ungated.
• Phase 3 — instrument operations. Logging, monitoring, incident capture, and re-evaluation triggers across the gated estate. Exit: evidence artefacts generated as a by-product for every in-scope system.
• Phase 4 — integrate and mature. Fold the AI operating model into existing risk and security and compliance structures rather than running a parallel bureaucracy, and align the use-case pipeline with your broader data strategy. Exit: one governance motion, not two.

#When This Is Overkill

What this means for you: if your whole GenAI footprint is internal drafting with a general-purpose assistant, four gates and three roles are the wrong answer.

You need an acceptable-use policy, a data-handling rule about what may be pasted into external tools, and a light register of what is in use. Organisations with no EU market exposure and no output reaching the Union face no direct Act obligations — though the Act is becoming the de facto template elsewhere, so the operating model rarely goes to waste.

Invest in governance proportionate to the consequence of your worst-performing system on its worst day.

What is not optional at any scale is knowing what you are running. The inventory is the artefact everyone needs, and it is the one that costs least to produce. If you are unsure whether your estate warrants the full sequence, an AI readiness assessment will tell you before you build the bureaucracy.

#Frequently Asked Questions

#Are we a provider or a deployer under the EU AI Act?

If you use an AI system under your own authority without substantially modifying it, you are generally a deployer, with duties around oversight, input data quality, monitoring, and logging. You can inherit provider-grade obligations if you substantially modify a system, market a fine-tuned model onward, or put your branding on one. Make the determination per use case at the classification gate and record the rationale.

#Does an internal-only chatbot fall under the Act?

Internal use does not exempt a system; classification follows what the system does. An internal assistant answering IT questions is typically minimal-risk. An internal system screening job applications or influencing performance decisions sits in high-risk territory regardless of audience. Run internal tools through the same intake and classification gates — most exit quickly with light obligations, which is the point of gating them.

#Does our model vendor carry the compliance burden?

The provider carries obligations for the model itself, but your use of it is yours to govern: use-case classification, transparency to users, oversight mechanisms, input data quality, and monitoring. Vendor documentation is an input to your evidence, not a substitute for it. Vendor-driven model updates are precisely why re-evaluation triggers belong in your operating model rather than in a contract.

#How does hallucination risk map to compliance obligations?

Indirectly but concretely. Transparency obligations mean users must know they are dealing with AI. Oversight expectations mean consequential outputs need a human check. Monitoring duties mean systematic quality failures should be detected. A deployment where fabricated output can cause harm, with no disclosure, review, or logging, misses all three at once, and general liability law reaches it even where the Act's text does not.

#Where should we start if we have done nothing yet?

Inventory. Every subsequent control depends on knowing what you run, and it needs no new tooling — a spreadsheet and honest asking will do. Classify what you find, and you will typically discover that only a minority of systems need the full gate sequence. That minority is where roles, evaluations, and evidence artefacts earn their cost first, and where a regulator would look first.

---

Unolabs is a Data and AI first engineering consultancy, headquartered in the United Kingdom with engineering operations in Pune and active engagements across the UK, Australia, and Hong Kong. We help enterprises build the architectural foundation for autonomous AI execution — governed data platforms, semantic intelligence, and agentic systems that enterprises can stand behind.

If you are working out whether the EU AI Act reaches your GenAI estate, and what an operating model would cost to stand up, book a discovery call.