Who enforces the EU AI Act, and what that means for your system
The first question to answer is which authority would examine your AI system, and what that authority can require of you. Articles 64 to 75 of the AI Act set up the pieces that answer it: the Commission's AI Office, the European Artificial Intelligence Board, national notifying authorities, national market surveillance authorities, and the sectoral bodies that supervise certain regulated products. The enforcer is not one body for everything. It depends on the kind of system you run and on who built the general-purpose model it relies on. For most AI systems, a national market surveillance authority in each Member State where the system is used or placed on the market is the first point of contact. For AI systems built on a provider's own general-purpose model, and for AI inside very large online platforms and search engines, the AI Office is exclusively competent under Article 75(1) as amended in 2026. For AI inside Annex I regulated products, the sectoral authority usually leads.
The main risk is that you cannot tell who to deal with when a complaint, an information request or an inspection arrives. The AI Act also lets anyone who considers it infringed complain to the relevant market surveillance authority under Article 85, so a complaint can reach you before any regulator has contacted you. The Commission's market surveillance authorities page, updated 7 September 2026, still showed the national designation decision as pending in 12 Member States, and no single point of contact listed for Austria, Belgium, Bulgaria, Croatia, Slovakia and Hungary. Confirm the current designations for every Member State where your system is used, and do not assume a regulator is ready to receive your documentation because the Act is in force.
Start by mapping each system to a likely enforcer: note the Member States of use, whether the model is your own or a third party's, and whether the system sits inside an Annex I product. Then check the Commission's page and the national contact details for each of those states, and record the date you checked. Plan for the powers that changed in 2026: under the new Articles 75a to 75d the AI Office can inspect, accept binding commitments, issue non-compliance decisions with Article 99 fines, and impose periodic penalties of up to 5% of average daily turnover, with a five-year limitation period. Ask your legal team and your AI system providers which authority each of them expects to deal with, and keep your technical file in a form that can be produced on a short notice to any of them.
Which authority supervises which AI system
Under the AI Act, the authority that holds your file depends on what the system is, who built the model it runs on, and whether it sits inside a regulated product. The four cases below cover most of the scoping decisions organizations face, and each one should be settled in writing before a supervisory contact arrives.
National market surveillance authorities
Most AI systems fall to the market surveillance authority of each Member State where the system is placed on the market, put into service or used. Article 74 applies the Market Surveillance Regulation to AI systems, so the national authority runs inspections, requests documentation and can order corrective action. Check which authority your Member State has named, because the Commission's market surveillance page still lists designations as pending in several Member States. Confirm the current contact point before you need it.
Sectoral authorities for Annex I products
When an AI system is a safety component of, or is itself, a product covered by the Annex I Section A legislation, the sectoral market surveillance authority responsible for that product is generally the one that supervises the AI Act obligations. A medical device or machinery maker may therefore deal with a product regulator rather than the AI authority. Confirm with your legal team which product legislation applies and which authority already oversees that product line, since one file may need to be coordinated across two regulators.
AI Office for same-provider systems
Under Article 75(1) as amended in 2026, the AI Office is exclusively competent for AI systems built on a general-purpose model supplied by the same provider or undertaking, with listed exceptions such as certain Annex I products. The test is common ownership of the model and the system. If your system uses a model from a different provider, the national authority normally keeps the file. Document the model provenance in your AI inventory so that you can show which side of the line each system falls on.
AI Office for very large platforms
The AI Office is also exclusively competent for AI in very large online platforms and very large online search engines. Providers and deployers running AI features inside such services should confirm whether a feature is covered by this route, because the answer moves the file away from the national authority. Ask your platform team to map each AI feature to a service designation and record the reasoning, so the supervisory route is clear if a complaint is lodged under Article 85.
AI Office for general-purpose model rules
Under Article 88, the Commission acting through the AI Office holds exclusive powers over the obligations for general-purpose AI models in Chapter V. This applies to the model provider, not to every organization that fine-tunes or deploys the model. If you build or substantially modify a general-purpose model, confirm with counsel whether your activity makes you a model provider in its own right. Keep records of the model documentation and copyright policy you hold, because the AI Office may request them directly.
What the AI Office can require since the 2026 amendment
Since the 2026 amendment, the Commission's AI Office can do more than supervise general-purpose AI models. Under Article 75(1), it is exclusively competent for AI systems built on a general-purpose model from the same provider or undertaking, with exceptions such as Annex I products, and for AI in very large online platforms and search engines. New Articles 75a to 75d give it inspection powers, the ability to accept binding commitments from an operator, and the power to issue non-compliance decisions that carry Article 99 fines. Where the AI Office finds an operator in breach, it can also impose periodic penalties of up to 5% of average daily turnover until the operator complies. An operator that falls under this supervision should confirm with counsel whether its system falls within the exclusive competence rule, since the exceptions determine which authority applies.
For an operator supervised by the AI Office, the practical consequence is speed and consistency of evidence. An inspection can start without a long lead time, so the technical file, the AI system inventory, the model and system documentation, logs and the records of any changes should be retrievable on short notice and in a single, consistent format. Operators should ask internally who holds each record, where it is stored, how it is versioned and how it can be exported. Documentation that exists only in one engineer's notes or in a chat thread will be difficult to produce under pressure. Teams should also agree in advance who can speak for the organization in an inspection and who can accept or reject a proposed binding commitment.
The amendment also sets a five-year limitation period for the AI Office's powers, which means operators should retain relevant records for at least that long rather than assuming a shorter retention period is safe. Retention schedules should be checked against the rest of the organization's obligations, including data protection rules, before they are set. Operators should also confirm with the AI Office or their legal advisers how the powers will be applied in their sector, because this page does not predict how often the powers will be used. The sensible planning assumption is that any system in scope must be able to produce its evidence at any point in the limitation period.
Preparing your organization for an authority request
This sequence gets your organization ready to answer a market surveillance authority or the AI Office before a request arrives. Each step produces a document or register that your team can use under time pressure, and the final step confirms that the team can act on it.
Confirm your competent authority and published contacts
Start by checking which national authority will supervise you, since Member States must designate notifying and market surveillance authorities and publish their contact details. Confirm the designation status in your country against the Commission's market surveillance authorities page, because some designations were still pending when that page was last updated. Record the authority name, the published contact route and the date you checked. The output is a verified authority record that legal and compliance can cite, and you know this step is done when every jurisdiction where you place or use AI systems has an entry.
Map each AI system to its enforcer
Build an authority map that lists each AI system in your inventory, its role (provider, deployer or other operator), the market where it is used, and the authority responsible for it. Check whether the AI Office holds exclusive competence, which the 2026 amendment extends to AI systems built on a provider's own general-purpose model and to AI in very large online platforms and search engines. Where an Annex I product falls under a sectoral authority, note that authority as well. The map is complete when every system has one named enforcer and a reviewer has signed off the reasoning.
Build a contact register for authorities and complainants
Create a contact register that lists the authority contacts, the single point of contact for each jurisdiction, and the internal owners who receive letters, emails and portal notices. Include a route for complaints that anyone may lodge with a market surveillance authority, so that a complaint from a customer, employee or competitor reaches the right owner quickly. Assign a backup for every role. The register is complete when a test message sent to each internal mailbox reaches a named person who can confirm receipt.
Assemble a request-ready documentation pack
Gather the technical documentation, risk management records, data governance notes, logging and monitoring evidence, instructions for use and any conformity assessment records for each in-scope system, indexed by system and by requirement. Keep a version history so you can show which document applied on a given date. Where you rely on a provider's documentation as a deployer, store the copy you received and the date. The pack is ready when a reviewer can locate the evidence for any system within a short working session, and the owner has confirmed each file is current.
Set up complaint and correspondence handling
Define how an incoming request, complaint or information demand moves from intake to a response. Specify who logs it, how it is classified by system and jurisdiction, who drafts the reply, and who approves it before release. Record each item and its status in a single tracker so that deadlines set by the authority are visible to the whole team. The step is complete when the tracker has been used for at least one dry-run item and the approvers have confirmed they can see it.
Define the internal escalation path with legal
Agree in writing when a matter moves from the system owner to legal counsel, the data protection officer, the security lead and senior management. Include triggers such as a request for a product withdrawal, a request to inspect systems, a suspected serious incident, or a potential fine. Name the decision owner for each trigger and state whether outside counsel is engaged for that matter. The output is a one-page escalation matrix that legal has approved, and it is done when each trigger has a named owner.
Rehearse the response in a tabletop exercise
Run a tabletop exercise based on an illustrative request, such as an authority asking for the documentation of one high-risk system within a short window. Walk through the authority map, contact register, documentation pack, tracker and escalation matrix, and record every gap the exercise exposes. Update the runbook, then repeat the exercise when the inventory or the authority designations change. The output is a tested response runbook with a dated exercise record, and the step is complete when the owners have closed the gaps found in the exercise.
Evidence that answers an authority request
When a market surveillance authority, the AI Office or a complainant asks for proof, the organization needs records that were already true before the request arrived. The six artifacts below are the ones that answer most governance questions under Articles 64 to 75, and each one only works if it is updated as events happen rather than rebuilt for an audit.
Authority map by system
A table that links each AI system to the authority that supervises it, the legal basis for that supervision and the sectoral regulator where Annex I product law applies. Under Article 74, Annex I Section A products fall to the sectoral authority, while Article 75(1) as amended in 2026 can make the AI Office exclusively competent for some systems built on a provider's own general-purpose model. Review the map whenever a system changes purpose, provider or model, and check it against each Member State's current designations, since some remain pending.
Published contact and single point of contact register
A record of the contact details the organization or its national authority has published, the designated single point of contact and the date each entry was last verified. Authorities need a route in that works on the day they call. Test the published address and the named contact on a fixed schedule, and confirm with the national authority whether its designation is final, because the Commission's list shows some Member States still pending.
Technical documentation index
An index that points to the current technical documentation for each high-risk system, with the version, the date of last change and the owner of each document. Authorities will ask for documentation first, so the index should show what exists, where it lives and whether it matches the system in production. Tie each entry to the release record so that a documentation gap is found at release time rather than during an inspection.
Complaint and correspondence log
A log of every complaint received under Article 85, every request from a market surveillance authority and every response sent, with dates, owners and status. The record shows whether the organization answered within the time the authority set and whether the same issue came up more than once. Store the original correspondence with the log entry, and review open items at a fixed interval so that nothing waits for a request to be discovered.
Record of roles held
A register that states, for each AI system, whether the organization acted as provider, deployer, importer or distributor, and why. Roles can change when a company modifies a system, rebrands it or builds on a third-party model, and the supervising authority follows the role. Record the basis for each determination, and reassess it when contracts, product changes or model changes occur, not only when the next assessment starts.
Decision log for supervised systems
A dated log of material decisions about each supervised system, including go or no-go calls, risk acceptances, human oversight actions, suspensions and corrective measures, with the person who made each decision. Authorities test whether oversight was real and whether it was recorded when it happened. Write the entry at the time of the decision, link it to the evidence it relied on and keep the retention period aligned with the limitation period set in the 2026 amendment.
What meeting Articles 64 to 75 costs in money and effort
This table lists the cost components an organization carries to meet the enforcement-facing duties tied to Articles 64 to 75, who is paid for each, whether the cost is one-time or recurring, and what drives it up or down. No supplied fact gives a price, so use the drivers and quote requests in the table to compare written proposals.
| Cost component | Who carries the cost | One-time or recurring, and what drives it |
|---|---|---|
| Internal legal and compliance time to map competent authorities | Your legal and compliance staff, sometimes with outside counsel | One-time for the initial map, then recurring as authorities are designated or change. Rises with the number of Member States where the system is placed and with the number of sectoral authorities involved. |
| Contact register upkeep | Compliance operations, with IT for the published contact record | Recurring. Rises with the number of systems and authorities tracked. Falls when one owner holds a single register tied to the system inventory. |
| Documentation pack preparation for authority requests | Internal teams, plus any implementation partner you engage to assemble evidence | One-time for the initial pack, then recurring as systems change. Rises with the number of systems, the number of AI Office involvements and the depth of technical files. Falls when evidence is generated from the platform on a schedule. |
| Complaint handling staff time | Internal support, legal and product owners who review complaints under Article 85 | Recurring and variable. Driven by complaint volume and by how many systems a complaint touches. Falls with a documented intake route and clear triage rules. |
| Rehearsal of the response runbook | Security, legal, product and communications staff, plus any external facilitator you hire | Recurring, usually on a set schedule. Rises with the number of systems in scope and with the number of authorities that may ask questions. Falls when exercises reuse one scenario library. |
| External legal review | Outside counsel or consultants, billed under a written scope | Recurring at review points and after amendments. Rises with the number of Member States, the number of AI Office-supervised systems and any change to the Digital Omnibus obligations. Ask whether the fee covers each re-review. |
Who does what: your team, a partner and the independent assessor
Your organization owns its AI systems, its legal position and every communication with a national market surveillance authority or the AI Office. Under the Act, the provider or deployer is the party that must demonstrate compliance, so the decisions cannot be handed to a vendor or consultant. The internal team should hold the authority map, decide which authority is competent for each system, and approve any response that makes a legal statement.
- Authority map: Record which national market surveillance authority, sectoral authority or the AI Office is competent for each AI system you provide or deploy, and confirm it against the Commission's current listing.
- Request handling: Name one owner for inbound requests, complaints and inspections, with a documented escalation path to legal counsel.
- Legal positions: Decide whether a system is high-risk, whether an exception applies and whether an incident must be reported, and record the reasoning.
- Regulatory contacts: Keep the single point of contact details for each Member State where you operate, and check them after national designations change.
Confirm with counsel which national designations are still pending in each Member State where you operate before you rely on any single authority.
An implementation partner such as DeployOpen prepares the systems and records that let your team answer an authority quickly and accurately. Work is typically scoped in writing before it starts, and it is delivered inside your own infrastructure. The partner builds the material; it does not represent you, sign statements for you or present itself as an authority-recognized body.
- Documentation packs: Assemble technical documentation, system descriptions and version histories so that the team can locate evidence within a short period.
- Logging and traceability: Configure logs that record model versions, inputs, outputs and human oversight actions in self-hosted environments, subject to your retention rules.
- Runbooks: Write procedures for responding to an information request, an inspection or a complaint, including who gathers what and in what order.
- Rehearsals: Run tabletop exercises in which the internal team answers a simulated authority request using the prepared packs.
- Limits of the role: The partner cannot speak for the organization to an authority, cannot issue reports or certificates, and cannot decide legal questions.
Ask any partner to state in the written scope which deliverables are documents and tests, and which decisions remain with your staff.
Independent conformity assessment is a separate function. Most Annex III high-risk systems use an internal-control route, where the provider assesses its own conformity under Annex VI. Notified bodies are involved for some biometric systems and for certain Annex I products under Article 43. Where a notified body is required, only that body can issue the conformity outcome, and the organization cannot substitute its own review or a partner's preparation for it.
- Internal control: Most Annex III systems rely on the provider's own assessment, which the provider must document and keep available for authorities.
- Notified bodies: Where Article 43 requires one, a notified body reviews the system and issues the outcome. Confirm which bodies are designated for your category.
- Authorities are not auditors: A market surveillance authority inspects, requests information and enforces the Act. It does not certify systems or issue conformity reports.
- Partner limits: An implementation partner cannot act as the notified body or issue any attestation, including for internal-control systems.
- Scope of independence: Ask any assessor to confirm in writing its designation status, scope and any conflict of interest with the implementation work.
Check the designation status of any notified body or assessor with the national authority before you sign a contract.
Where organizations fall short on enforcement readiness
Enforcement under Articles 64 to 75 depends on knowing which authority will act, how to reach it, and what evidence you can produce on short notice. The gaps below are the ones that most often leave organizations unprepared when a regulator, a complainant or a customer asks questions.
Assuming the enforcer is known
Designations are still pending in some Member States, so the authority that will supervise your AI system may not yet be named in your country. Under Article 70, each Member State must designate notifying and market surveillance authorities, but the Commission's page updated 7 September 2026 still marked decisions as pending in 12 Member States. Check the current designation for every country where your system is placed or used, record the date you checked, and set a review date to recheck it.
No confirmed contact or single point of contact
Article 70 requires each Member State to publish contact details and name a single point of contact, and the Commission's page listed none for six Member States. An organization that cannot identify a reachable contact cannot respond to an information request within the deadline it is given. Confirm the published contact for each relevant authority, store it in your compliance register, and name an internal owner who checks it on a fixed schedule.
Documentation held by a vendor
Technical documentation, logs and test records for a high-risk system are often held by the provider, the cloud host or an integrator. If the contract does not give you a right to obtain them within a set time, a market surveillance request can expose a gap you cannot close quickly. Ask each supplier which records they hold, where they are stored, how fast they can be produced, and whether the contract allows you to retrieve them directly.
Unclear provider and deployer roles
The authority you face depends on whether you are a provider placing the system on the market or a deployer using it, and some organizations are both after customizing or rebranding a model. A role decided late can leave the wrong duties unmet and the wrong evidence unprepared. Map each AI system to a documented role, record the reason in your inventory, and reassess the role whenever you change the model, the purpose or the branding.
No owner for Article 85 complaints
Article 85 lets anyone who considers the Act infringed complain to the relevant market surveillance authority, and a complaint can reach your organization from a customer, employee or regulator before you know it exists. Without a named owner, a complaint may sit in a general mailbox while the response clock runs. Assign a single owner, define how complaints are logged and triaged, and agree who speaks to the authority.
An untested enforcement runbook
A written runbook that has never been run tends to fail at the first real request, when staff discover that evidence is scattered and approvals are unclear. Test the runbook with a tabletop exercise that simulates an inspection request and a complaint about one high-risk system. Record the time each step took, the gaps found and the owner of each fix, then repeat the exercise after material changes.
Questions buyers ask about AI Act enforcement readiness
How much effort does it take to prepare for an authority information request?
The effort depends on how quickly you can produce a current, accurate picture of every AI system you provide or deploy. Market surveillance authorities work under the framework of Regulation (EU) 2019/1020, as Article 74 applies it to AI systems, so an authority can ask for documents, technical information and access. The main cost drivers are the number of AI systems, whether any fall under Annex III or Annex I, how much technical documentation and logging already exists, and whether ownership is clear for each system. Organizations that already run an AI governance or quality management process usually need less new work. No effort figure is available here, so ask your counsel and readiness assessor to estimate effort against your own inventory before you commit budget.
How long does preparation take before the AI Act high-risk rules apply?
The dates in the Act set the deadline, and the 2026 amendment moved the high-risk clock. As amended, the high-risk rules in Chapter III Sections 1 to 3 apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I product systems. Some duties already apply: Chapters I and II have applied since 2 February 2025, and the general-purpose AI and governance chapters since 2 August 2025. Authority readiness also depends on national designations. The Commission's market surveillance authorities page, updated 7 September 2026, showed the designation decision still pending in 12 Member States. Confirm your own timeline with counsel, and confirm which authority covers each Member State where you operate. The effective duration of your program is not a fixed figure and depends on your inventory and gaps.
Can an in-house team prepare for AI Act enforcement alone?
Many organizations can start internally, especially if they already run security, privacy or quality programs. The harder question is whether the team has the right roles and time. Preparing for enforcement needs an AI system inventory, role decisions (provider or deployer for each system), risk classification, documentation, logging and a process for answering authorities. Most Annex III systems use internal-control conformity assessment under Annex VI, so the organization carries that work itself. Notified bodies are involved for some biometric systems and Annex I products under Article 43. An outside partner can prepare systems, controls and evidence under a written scope. Only an independent auditor, assessor or certification body issues reports or certificates, and the organization stays accountable throughout.
What does enforcement readiness need from legal and engineering teams?
Legal and engineering each own parts of the answer, and the work fails when either side is missing. Enforcement readiness typically needs:
- Legal: role classification, jurisdiction mapping across Member States, a view of penalty exposure under Article 99, and a procedure for complaints under Article 85.
- Engineering: a versioned inventory of models and systems, logs, technical documentation, monitoring records and incident records that can be produced quickly and accurately.
- Joint ownership: a named contact for each authority, a response workflow with deadlines, and regular mock requests to test how fast evidence can be assembled.
Confirm with your counsel which national procedures apply to information requests and inspections. Engineering can build the evidence trail only if legal has defined what an authority is likely to ask for.
Can a consultant or partner represent our organization to an authority?
No. A consultant or implementation partner cannot represent your organization before an authority or stand in for your accountable people in an inquiry. DeployOpen prepares systems, controls and evidence, and it does not issue audit reports, attestations or certifications. Responsibility for the AI Act obligations stays with your organization as provider or deployer. Your legal counsel decides who may appear in any proceeding under the relevant national procedure, so confirm that with them before you plan the response. A partner can support preparation by assembling evidence packs and running mock requests under a written scope, but a named internal owner should answer the authority.
What changes for enforcement after the 2026 amendment?
Regulation (EU) 2026/1744 amended the AI Act on 8 July 2026, was published on 24 July 2026 and entered into force on 27 July 2026. The main enforcement change is in Article 75(1). The AI Office becomes exclusively competent for AI systems built on a general-purpose model from the same provider or undertaking, with exceptions such as Annex I products, and for AI in very large online platforms and search engines. New Articles 75a to 75d give the AI Office inspection powers, binding commitments, non-compliance decisions with Article 99 fines and periodic penalties of up to 5% of average daily turnover, within a five-year limitation period. Your first task is to confirm which authority supervises each system, because that determines who requests evidence and who can fine you.
How DeployOpen prepares your systems for AI Act enforcement
DeployOpen helps organizations get their AI systems, records and evidence in order for the authorities that enforce the AI Act under Articles 64 to 75. We plan, implement and document self-hosted open-source platforms inside your own infrastructure, then hand over the evidence that supervisors and auditors will ask to see. We do not issue compliance decisions or certifications.
How we scope
- We confirm which AI systems are in play and which authority your organization would likely deal with, such as a national market surveillance authority or the AI Office.
- We agree the scope in writing before work starts, covering systems, environments, deliverables and timelines.
- We record which national designations and contact points you must confirm, since some Member States had not finalized them when this was written.
How we build
- We deploy and configure self-hosted open-source platforms in your cloud accounts, data centers or air-gapped networks, keeping data under your control.
- We set up logging, access records and version history so that system documentation can be produced for a market surveillance request.
- We test the configured controls and document the results so you can show how each system was checked before being queried.
How we hand over
- We deliver a documented register of AI systems, owners, roles and the evidence location for each control.
- We provide runbooks for responding to an authority's information request, complaint or inspection, including who is contacted first.
- We walk your team through the handover so the people who must answer regulators can locate and explain the evidence.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, so the evidence stays current as the AI Act timeline develops.
- We can update documentation when national designations, harmonised standards or Commission guidance change the position for your systems.
- Independent auditors, notified bodies and authorities make the final determinations. We prepare your systems and evidence for their review.
