RatedWithAI

RatedWithAI

Accessibility scanner

AI RegulationAugust 19, 2026

EU AI Act Enforcement After August 2026: Who Actually Knocks on Your Door

The checklists were written for the deadline. This is written for the week after it. The high-risk obligations now apply, the national authorities exist on paper, and the question that matters has changed from "what do we need" to "who asks, in what order, and what do they see when they do."

27
Member states, each with its own market surveillance authority and penalty regime
1%
Turnover cap for giving an authority incorrect or misleading information — a separate offence
Annex IV
The technical documentation set that is normally the first thing requested

There Is No "The EU AI Regulator"

The most common planning error after the deadline is imagining a single Brussels inbox. Enforcement is layered, and the layers do different jobs:

Member state
Market surveillance authorities. Designated per member state. They police AI systems already on their national market — request documentation, order corrective action, restrict or withdraw a system, and propose penalties under national law.
Member state
Notifying authorities and notified bodies. The conformity assessment machinery. Relevant before you ship, when a third-party assessment route applies to your high-risk category.
Commission
The European AI Office. Sits in the Commission and supervises general-purpose AI models directly, including systemic-risk models. If you build on someone else's foundation model, this is the layer that governs your supplier, not you.
EU-level
The AI Board and scientific panel. Coordination and consistency across national authorities, plus alerting. Not where your file opens, but where a divergence between two countries eventually gets reconciled.

The practical consequence: your exposure is not one relationship, it is as many relationships as you have markets. A system sold into Germany, Ireland and Spain can be examined three times on the same facts, with three penalty schedules, and the authorities are not obliged to move at the same speed.

How a File Actually Opens on a Non-EU Vendor

Very few enforcement stories begin with a regulator discovering your product. They begin with someone else being asked a question they cannot answer without you:

  • Your EU customer gets asked. A deployer using your system for hiring, credit, education or worker management is subject to its own obligations, and the first thing it does under pressure is forward the request upstream to you, usually with a contractual deadline attached.
  • Your importer or distributor gets asked. Whoever placed your system on the EU market must verify that the provider carried out conformity assessment and drew up documentation. They cannot verify what you never gave them.
  • A complaint arrives. Affected persons can complain to a market surveillance authority. Complaints from works councils, unions and rejected applicants are a live channel, not a theoretical one.
  • A serious incident is reported. Post-market monitoring obligations mean incidents get reported into the system, and a report is a natural trigger for a documentation request.

The authorised representative gap. A provider established outside the EU offering a high-risk system must appoint an authorised representative in the Union by written mandate before placing the system on the market. Companies that skipped this step do not thereby become unreachable — they become reachable only through their own customers, which is the worst possible way to learn that a file exists.

What the First Request Contains

Assume a documentation request, in an official language the authority chooses, with a deadline measured in weeks. The recurring items:

EU declaration of conformity
Signed, identifying the system, the provider, and the requirements it claims to meet. Kept for 10 years after placing on the market.
Annex IV technical documentation
General description, development process, design specifications, system architecture, data requirements, human oversight, accuracy and robustness metrics, and the risk management record.
Risk management system evidence
Not a policy PDF — the iterative record: identified risks, mitigations adopted, residual risk judgement, and testing against the intended purpose.
Data governance description
Training, validation and testing data: provenance, collection, preparation, assumptions, bias examination, and gap assessment.
Automatically generated logs
The system must log by design over its lifetime, and the provider keeps logs under its control for the period required. 'We do not retain that' is itself a finding.
Human oversight measures
What the deployer is actually able to do — interpret output, override, halt — described concretely enough that an authority can test it.
Instructions for use given to deployers
Because deployer obligations are built on them, gaps here convert into your customer's non-compliance and back into yours.

Notice what is not on the list: your model weights, your source code, your prompts. Access to source code exists as an escalation route where documentation and testing are insufficient to assess conformity, and it is bounded. The realistic risk is not that a regulator takes your IP — it is that thin documentation is what forces the escalation.

The Third Penalty Tier Is the One Teams Forget

Everyone quotes the headline numbers — up to 35 million euros or 7% of worldwide turnover for prohibited practices, up to 15 million or 3% for the main provider and deployer obligations. The tier that catches ordinary, well-intentioned companies is the third: up to 7.5 million euros or 1% of turnover for supplying incorrect, incomplete or misleading information to authorities or notified bodies.

That converts your response process into a compliance surface of its own. An engineer answering a regulator's questionnaire from memory, a sales team describing the product more capably than it performs, a documentation set that describes the intended architecture rather than the shipped one — each is a route to a penalty that has nothing to do with whether the underlying system was compliant.

Corrective Action Comes Before the Fine

The enforcement path is not finding-to-fine. Where an authority establishes non-compliance it requires corrective action within a set period: bring the system into conformity, withdraw it from the market, or recall it. Restriction and prohibition are the escalation for operators who do not act.

This matters for how you triage. The expensive outcome in year one is rarely the penalty — it is a withdrawal order in a market you sell into, arriving with a remediation window shorter than your release cycle, while your EU customers read the same order.

A Two-Week Readiness Pass

  1. Name the authority per market. For each member state where your system is made available, identify the designated market surveillance authority and the language it operates in. This is a lookup, not a project.
  2. Confirm the authorised representative. If you are outside the EU and in a high-risk category, confirm a written mandate exists and that the representative holds the documentation it is required to hold.
  3. Dry-run the Annex IV request. Give a colleague two weeks and the actual document set. Whatever they cannot find is what an authority will not be given either.
  4. Reconcile documentation to the shipped system. Diff the described architecture, data sources and oversight controls against production. Documentation drift is the most common finding and the easiest to fix before anyone asks.
  5. Write the response protocol. One named owner, one legal review gate, no direct engineer-to-regulator answers. The 1% tier is avoidable purely by process.
  6. Check your logs are actually retained. Logging by design plus a retention window you can evidence. Sampling and short TTLs are normal engineering practice and abnormal compliance practice.

Frequently Asked Questions

We only sell to EU businesses, never consumers. Does that change enforcement exposure?

No. The AI Act is product regulation, not consumer protection law — the trigger is placing a system on the EU market or putting it into service, and the high-risk categories are overwhelmingly B2B contexts: employment, credit, education, essential services, critical infrastructure. Selling only to businesses puts you squarely inside the categories rather than outside them, and adds a second effect: your business customers are deployers with their own obligations, which makes them an active channel for requests to reach you.

Our system is not high-risk. Do we still have anything to answer for?

Possibly. Transparency obligations apply to systems that interact with people, generate synthetic content, or perform emotion recognition and biometric categorisation, independent of high-risk classification. Prohibited-practice rules apply to everyone. And where you rely on the derogation that an Annex III system is not high-risk because it performs a narrow procedural task, you must document that assessment and register the system — the derogation is a paperwork obligation, not an exemption from paperwork.

If we build on a third-party foundation model, whose problem is a model-level issue?

Both, in different places. The general-purpose AI model provider answers to the AI Office for model-level obligations including documentation for downstream providers, copyright policy, and training data summary. You answer to the market surveillance authority for the system you built, and the information your supplier gives you is an input to your Annex IV documentation, not a substitute for it. Contractually, the question worth asking now is whether your supplier is obliged to provide that information on a regulator's timeline, not on its own.

How much does the penalty regime actually vary by member state?

Enough to matter. The Act sets ceilings and requires penalties to be effective, proportionate and dissuasive, but member states lay down the rules — including the procedure, the aggravating and mitigating factors, and whether public authorities in that state are subject to fines at all. Identical facts can produce materially different outcomes in two countries, which is a reason to know which authority is likely to move first on your product.

Is there any benefit to self-reporting a gap we found ourselves?

Often yes, though it is jurisdiction-specific. Where a provider has reason to consider that a system it placed on the market is not in conformity, it is expected to take corrective action, inform distributors, deployers and the authorised representative, and where the system presents a risk, inform the relevant authorities. Doing that on your own initiative is both an obligation and the strongest available mitigating factor — the alternative is the same disclosure made later, under a deadline, with the 1% information tier now in play.

The Document Set Is the Product Now

Before the deadline, compliance work looked like a classification exercise: are we high-risk, which annex, which route. After it, the exercise is evidentiary. An authority does not experience your system — it experiences your documentation, your logs, and the speed and accuracy of your answers.

The cheapest week you can spend right now is the dry run: hand someone the Annex IV list and see what actually comes back. Everything missing in that exercise is missing in the real one, except that the real one has a deadline and a penalty tier attached to getting it wrong.