Who enforces the AI Act, and how the buck stops with you

Shared oversight, but the work stays with you

The AI Act is now in force, and the Commission has set out who enforces what. The framework ^[1] divides the job between the AI Office in Brussels, national competent authorities in each member state, and the European Data Protection Supervisor. The split reflects the Act's range: some rules apply to every AI on the market, some to high-risk systems only, and some to the EU's own institutions.

For anyone building or using AI, the real point is simpler. The enforcer changes depending on the rule and the sector, but the burden of showing compliance doesn't. Think of it like a car inspection: the garage tests what you bring, but you're the one who has to keep the brakes working all year.

The framework clarifies who knocks on the door when something goes wrong, and what powers they bring with them.

The AI Office: models, cross-border providers and codes of practice

The AI Office enforces the rules on general-purpose AI models, meaning systems like the ones behind chatbots and code assistants that can be used for many tasks ^[1]. That includes the transparency requirements in Chapter III, Section 4 of the Act, and the obligations on systemic risk models in Article 55.

The Office also acts as the one-stop shop for providers placing AI systems in more than one member state, coordinating with national authorities to avoid contradictory inspections. And it approves codes of practice under Article 56, which let model providers show how they meet their obligations.

If you're a provider of a general-purpose model, or you place high-risk systems across several countries, the AI Office is your main contact. For everyone else, enforcement is national.

National authorities: high-risk systems and market surveillance

Each member state designates at least one competent authority to enforce the AI Act within its borders ^[1]. These authorities oversee most of the regulation, including all the high-risk obligations in Chapter III, Section 2: risk management, data governance, documentation, logging, human oversight and post-market monitoring.

They also handle market surveillance, checking that AI systems comply before and after they reach users. If a system doesn't meet the rules, the authority can order it withdrawn, restrict its use or fine the provider. Penalties for breaching high-risk requirements go up to €15 million or 3 per cent of global annual turnover, whichever is higher, though smaller amounts apply to SMEs ^[2].

Notified bodies, appointed by member states, assess conformity for high-risk systems before they are placed on the market. The national authority supervises the notified bodies and coordinates with the AI Office when needed.

For high-risk AI under Annex III, all of this applies from 2 December 2027 ^[3]. For systems under Annex I, the date is 2 August 2028.

The European Data Protection Supervisor: EU institutions and bodies

The EDPS enforces the AI Act for EU institutions, agencies and bodies ^[1]. That means it supervises how the Commission, Parliament, agencies and other EU entities comply when they use or provide AI systems.

The EDPS works with the AI Office on providers that serve both EU institutions and the wider market, to keep enforcement consistent.

What this means for you

Compliance is something you show, not something you claim. The guidance makes clear that providers and deployers carry the burden of proof, and enforcement happens through document requests, on-site inspections, testing and audits.

Here are the questions worth asking now:

• Do you know which national authority oversees your sector, and have you checked its published guidance?
• Can you produce the technical documentation, risk assessments and test records an inspector would ask for?
• If you're using a high-risk system, can you show that you're meeting the deployer obligations in Article 26, including logging, human oversight and informing affected people?
• For logs, can you prove they haven't been edited since the events they record?

The last question is the evidence question. Article 12 asks high-risk systems to log events automatically ^[4]. It doesn't say how to protect those logs, but when an inspector or an auditor questions a decision made months ago, the side without a provable record starts on the back foot.

How a digital witness fits here

Here, the thing to seal is each log record as it is written: the input reference, the model version, the output and, if there was one, the human reviewer. Sealing takes a fingerprint of the record, not the record itself, so the log never leaves your systems.

If a decision is challenged later, anyone you share the record with—an auditor, a supervisor or the person affected—can check that it matches the fingerprint sealed at the time. Change a single character in the log and the fingerprint won't match.

Internal audit, supervisors and courts can all check it. The check is independent: it doesn't rely on trusting whoever keeps the log.

What it shows is that the record is exactly what was written on the day. What it doesn't show is that the decision was fair, lawful or complete, or that the log contains every event it should. It makes one thing provable: that the record you're showing is the one you wrote.

You seal log records as they are written, with the REST API, the SDK or the MCP server, through WitniumChain. The content stays with you. The first 2,000 witnesses a month are free, and the technical documentation walks through integration.

How it would work

1. Your system writes a log record and sends its fingerprint to the sealing service.
2. The service returns a witness ID and stores the fingerprint on a chain where any later change would show.
3. When the record is questioned, you or an auditor calculates the fingerprint again and compares it with the sealed one.

What to watch

The guidance is final, but member states are still appointing their competent authorities and notified bodies. Check your national authority's website for sector-specific guidance, and for the forms and timelines it expects.

For high-risk systems under Annex III, the clock runs to 2 December 2027. The question to settle before then is whether you can show, not just tell, that you've met the obligations.