What the Regulation Asks of You

Regulatory requirements vary by jurisdiction and sector, and this lesson describes the EU AI Act because it is the most developed framework and is influencing others. It is not legal advice, the picture continues to move, and your legal function should confirm what applies to you.

Provider or deployer

The distinction that determines almost everything about your obligations.

A provider develops an AI system and places it on the market. A deployer uses one under its own authority.

Most organisations reading this are deployers. That matters because deployer obligations are substantially lighter than provider obligations — but they are not nothing, and one of them applies to essentially everyone.

A caution worth holding: you can become a provider without intending to. Putting your own name on a system, or substantially modifying one, can move you across that line. If you are white-labelling an AI capability as your own product, ask your legal team where you stand.

The risk tiers

The framework scales obligation to risk:

📅 Timeline

ProhibitedA small set of practices banned outright, including certain manipulative techniques, some social scoring, and specified biometric applications.

High riskSystems in defined sensitive areas — employment and worker management, education access, essential services, credit, law enforcement, and safety components of regulated products. Substantial obligations attach.

Limited riskTransparency obligations, principally telling people when they are interacting with an AI system or when content is artificially generated, in defined circumstances.

Minimal riskThe large majority of business applications. No specific obligations under the Act beyond general law.

For a manager, the practical significance is that the high-risk tier is where the cost sits, and it is defined by application area rather than by technical sophistication. A simple model used to filter job applicants attracts far more obligation than a sophisticated one recommending inventory levels.

This is why the HR boundary from module 2 matters so much. Employment and worker management is explicitly a sensitive area. A CV screening system is not merely ethically fraught; it is likely to sit in a tier with real compliance costs.

The dates

The Act applies in stages:

2 February 2025 — the prohibitions took effect, and so did the AI literacy obligation in Article 4.
2 August 2025 — the penalties framework applied, and member states were to have designated their national competent authorities.
2 August 2026 — the remainder of the Act came into application.

The obligation almost everyone has

Article 4 requires providers and deployers to ensure a sufficient level of AI literacy among their staff and others operating AI systems on their behalf, taking into account their technical knowledge, experience, education and the context of use.

Three things make this the obligation most likely to touch you:

It applies to deployers, not just builders. If your staff use AI systems, it is your obligation.

There is no size exemption. It applies regardless of company size.

It applied from February 2025, making it one of the earliest obligations to bite.

The Act is flexible about how you satisfy it — training is the obvious route, tailored to role, with deeper coverage for those making decisions about AI use and basic coverage for general users.

On exposure, be careful with what you read. A major law firm's published analysis takes the view that no dedicated fine attaches to Article 4 specifically, with exposure running instead through market-surveillance action and civil liability; various commercial training vendors quote large headline penalty figures. Those are different claims. Treat the training as worth doing on its own terms — competent staff make better decisions and cause fewer incidents — rather than buying it on the strength of a quoted fine.

Which of your systems will attract obligations

A quick screen, in descending likelihood:

Anything making or materially influencing decisions about people — hiring, promotion, performance, access to services, credit, insurance pricing.
Anything customer-facing that could be mistaken for a human, where transparency obligations may apply.
Anything generating content published as genuine, where labelling questions arise.
Anything in a sector with its own regulator — financial services, healthcare, legal — where sector rules may bind before general AI rules do.
Anything processing personal data, where data protection law applies independently of AI regulation and has done for years.

That last point is worth emphasising because it is routinely missed: data protection obligations exist regardless of AI regulation. Many organisations worrying about future AI rules have unaddressed obligations under law that already applies.

The single most common compliance mistake is reconstructing documentation afterwards. It is expensive, incomplete and unpersuasive.

Keep these from day one. All are things a well-run project produces anyway, which is the point:

A system record. What it does, what it decides or influences, who it affects, what data it uses, what it is not to be used for. One page, updated when the system changes.

The purpose and the alternatives considered. Why this approach. Regulators and courts consistently ask why a less intrusive option was not chosen, and an answer written at the time is worth vastly more than one composed later.

Testing evidence. What you measured before deployment, on what data, with what result — including performance broken down by group where the system affects people. The bias lesson in AI for Non-Technical Teams explains why aggregate figures are insufficient.

The human oversight design. Who reviews what, when they can override, and how that is recorded. "A human is in the loop" is not evidence; a documented route with logged overrides is.

Incident records. What went wrong, when, who was affected, what you did. An organisation with an incident log and clear responses is in a far stronger position than one with no incidents recorded, which reads either as luck or as not looking.

Version and change history. Which version was live when, and what changed. Essential if you ever have to answer for a decision made on a particular date.

The reason to keep these is not fear of a regulator. It is that an organisation that cannot answer "what does this system do, who does it affect, and how do you know it works?" does not actually have the system under control — regardless of who is asking.

❓ Knowledge Check

A 40-person company uses a bought AI assistant. Which EU AI Act obligation is most likely to apply to it?

📚 Flashcards1 / 6

Term

Provider versus deployer

Click to flip

Definition

A provider develops and places an AI system on the market; a deployer uses one under its own authority. Most organisations are deployers, with substantially lighter obligations — but naming or substantially modifying a system can make you a provider.

Click to flip back

💡Key Takeaway

Establish whether you are a provider or a deployer, because it determines almost everything — and note you can become a provider by naming or substantially modifying a system. Obligations scale with application area rather than technical sophistication, which is why anything deciding about people carries the most. The AI literacy duty under Article 4 reaches deployers of any size and applied from February 2025. Keep the documentation from day one, because an organisation that cannot say what a system does and how it knows it works does not control it.