Artificial Intelligence

The EU AI Act Now Applies: What Operational Compliance Actually Looks Like

The EU AI Act Now Applies: What Operational Compliance Actually Looks Like

Correction, 3 October 2026: An earlier version of this article stated that the EU AI Act’s high-risk obligations applied from 2 August 2026, and treated that date as day one of the high-risk regime. That was not correct. The AI Omnibus, which entered into force on 27 July 2026, moved the high-risk obligations to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems. What did apply from 2 August 2026 was the Act’s general application, the enforcement powers of the AI Office and national authorities, and the Article 50 transparency obligations. The article has been corrected throughout.

On 2 August 2026 the EU AI Act became generally applicable. The enforcement powers of the European Commission’s AI Office and of the national competent authorities now apply, and so do the Article 50 transparency obligations, such as telling people when they are interacting with an AI system and marking AI-generated content. They join the rules already in application: the prohibited practices and the AI literacy duty since 2 February 2025, and the obligations for providers of general-purpose AI (GPAI) models since 2 August 2025.

What 2 August 2026 did not bring is the high-risk regime. The AI Omnibus, which entered into force on 27 July 2026, moved the rules for high-risk AI systems in the areas listed in Annex III (including biometrics, critical infrastructure, education, employment, migration, asylum and border control) to 2 December 2027, and the rules for high-risk AI embedded in products covered by Annex I, such as machinery, toys and lifts, to 2 August 2028.

That extra time is valuable, but it is easy to spend badly. Preparing a documentation pack is a project with an end date. Running a compliant high-risk AI system in production is a discipline that never stops. High-risk compliance is not a binder on a shelf; it is logging that is genuinely being written, oversight that is genuinely happening, and monitoring that is genuinely catching things. This article sets out what applies now, and how we suggest using the time before the high-risk dates to build compliance as a running system rather than a document pack.

A note before we go further: this is McKenna Consultants’ practitioner perspective drawn from hands-on engineering and governance work. It is not legal advice. The Act is complex, some implementation guidance is still to come, and you should take formal legal counsel on your specific obligations.

From documentation to operational discipline

When a deadline moves, the natural response is to keep working on artefacts: risk management files, data governance statements, technical documentation to satisfy Annex IV, a scoped conformity assessment, the CE marking and the EU declaration of conformity. All of this will be necessary, and the extra time makes it more achievable.

But the Act does not merely require that these documents exist on the day high-risk obligations begin to apply. It requires that the things they describe are actually true and continue to be true. There is a meaningful gap between writing a record-keeping policy and having a system that automatically and reliably logs events throughout its lifecycle. There is a gap between describing human oversight in a design document and having named, trained people who can and do intervene, override or halt the system in production. There is a gap between defining a post-market monitoring plan and having that plan running, collecting real signals, and feeding them back into your risk management process.

Those gaps are far cheaper to close before the obligations apply than after. Consider what the Act will continuously expect of a high-risk system once its rules apply:

  • Risk management is described in the Act as a continuous, iterative process across the whole lifecycle, not a one-off exercise. It must be revisited as the system, its use, and the threat landscape evolve.
  • Record-keeping and logging must happen automatically over the system’s lifetime, to a degree appropriate to the intended purpose, so that functioning can be traced and post-market monitoring supported.
  • Human oversight must be effective in operation, with the people overseeing the system able to understand its capabilities and limits, watch for automation bias, interpret outputs correctly, and intervene or stop the system.
  • Accuracy, robustness and cybersecurity must be maintained at appropriate levels throughout, not just demonstrated once at launch.
  • Post-market monitoring must actively and systematically collect and analyse data on real-world performance.
  • Serious-incident reporting will require providers to report serious incidents to the market surveillance authorities of the Member State where they occurred, within defined timelines (Article 73).
  • Transparency will require providers to give deployers clear instructions for use (Article 13), and deployers of Annex III systems that make, or assist in making, decisions about people to tell those people that the system is being used (Article 26).

The shift in mindset is from “have we produced the evidence?” to “is the system behaving the way the evidence claims?” That is what high-risk compliance will actually mean in operation.

What applies and is enforced now

It is worth being calm and realistic about enforcement. Responsibility is shared: the AI Office enforces the rules for providers of GPAI models, for AI systems built on a GPAI model by the same provider or business group, and for AI systems integrated into very large online platforms and search engines; national competent authorities designated by each Member State enforce the rules for other AI systems; and the European Data Protection Supervisor covers AI systems used by EU institutions. Their enforcement powers apply from 2 August 2026, but only to provisions that are themselves in application. The Commission names in particular the prohibited practices, the GPAI obligations and the transparency requirements for certain AI systems, and states that “the enforcement powers for other provisions of the AI Act will start to apply only when those provisions become applicable”.

Two further dates are worth noting. Article 50 applies from 2 August 2026, with a limited grace period only for the marking and detection obligation for AI-generated content, and only for systems placed on the market before that date, which must comply from 2 December 2026. And a new prohibition on AI systems that generate or manipulate non-consensual intimate material or child sexual abuse material applies from 2 December 2026.

Our expectation is that early enforcement will not begin with authorities auditing every system. The Commission has launched an AI Act Complaint Tool for complaints about providers of AI systems that the AI Office supervises, and a whistleblower tool for people connected to providers in a professional capacity, and the AI Office can send requests for information to verify compliance. In our view, the more likely near-term triggers are a complaint from an affected person or a competitor, a whistleblower report, a sectoral regulator already active in your domain (financial services, medical devices, employment), or a request for information that you must be able to answer promptly and accurately.

The penalty regime is the backdrop that focuses minds. Article 99 requires Member States to lay down penalties that are “effective, proportionate and dissuasive”, within tiered ceilings that, for an undertaking, are the higher of a fixed sum or a percentage of total worldwide annual turnover for the preceding financial year: up to €35 million or 7% for breaching the prohibited-practice rules; up to €15 million or 3% for breaching other listed obligations, including those of providers, importers, distributors and deployers of high-risk systems and the Article 50 transparency obligations; and up to €7.5 million or 1% for supplying incorrect, incomplete or misleading information to notified bodies or national competent authorities in reply to a request. For SMEs, including start-ups, each ceiling is whichever of the two figures is lower, and the same applies to small mid-cap companies for the two lower tiers. How authorities exercise their discretion will become clearer as practice develops.

The timetable itself is no longer a matter of speculation. The AI Omnibus, proposed on 19 November 2025 as part of the Commission’s digital omnibus package, entered into force on 27 July 2026. As well as the new high-risk dates, it extends some measures previously reserved for SMEs to small mid-cap companies, simplifies the AI literacy requirement and the registration of exempted systems in the EU database, expands access to regulatory sandboxes, and adds the new prohibition described above. Our practitioner advice is to treat the new high-risk dates as time to build rather than as relief: operational discipline takes longer to establish than documents take to write, and a system that must have a quality management system, a conformity assessment and post-market monitoring in place by December 2027 needs that work to start well before then.

Common gaps to check for before the high-risk rules apply

The gaps worth checking for first are not exotic. They are the difference between a system that looks compliant on paper and one that is compliant in operation.

Logging exists, but it is not the right logging. Application logs and observability dashboards are not the same as logging designed specifically to support traceability and post-market monitoring across the system’s lifetime — capturing the inputs, decisions, oversight actions and version context needed to reconstruct what happened and why. Generic infrastructure logs with short retention windows are not the same thing either; deployers, for example, must keep the logs a high-risk system generates, to the extent they control them, for at least six months unless other Union or national law provides otherwise (Article 26).

Human oversight is named but not operational. A document says a human reviews outputs. The gap to check for is a reviewer who has no practical ability to override the system within the workflow, has not been trained on its known failure modes, and is subject to exactly the automation bias the Act warns about. Oversight that cannot actually stop or correct the system is oversight in name only.

Post-market monitoring is a plan, not a process. The plan describes what will be collected and analysed. But no data is flowing yet, no one owns the review cadence, and there is no defined route from a monitoring signal back into the risk management file or to a corrective action. A monitoring plan that produces no monitoring is a serious gap.

Incident reporting has no playbook. Knowing that serious incidents must be reported is not the same as being able to answer the operational questions: who decides whether something is a serious incident, against what criteria, within what timeframe, to which authority, and with what evidence attached? Article 73 requires a provider to report immediately once it has established a causal link between the system and the incident, or the reasonable likelihood of one, and in any event no later than 15 days after the provider or, where applicable, the deployer becomes aware of it. The outer limit is two days for a widespread infringement or a serious and irreversible disruption of critical infrastructure, and ten days where a person has died. Without a rehearsed playbook, the reporting clock is a liability.

Documentation has drifted from the deployed system. The technical documentation describes the model and pipeline as they were at assessment. Since then there may have been retrains, prompt changes, dependency updates and configuration tweaks, none reflected in the file. The Act requires technical documentation to be kept up to date (Article 11); a snapshot that is already stale undermines everything built on it.

Role confusion at the boundaries. It is easy to be unclear about whether you are acting as a provider, a deployer, or both, for a given system — and therefore unclear about which obligations actually attach to you. That question deserves its own section.

Provider, deployer, importer or distributor: know which hat you wear

The distinction between roles can feel like a planning abstraction while the high-risk dates are still ahead. It is not: it determines exactly what each organisation will have to do, and getting it wrong means either doing work you do not owe or, far worse, missing obligations you do.

Providers develop an AI system (or have one developed) and place it on the market or put it into service under their own name or trademark, whether for payment or free of charge. Providers of high-risk systems carry the heaviest load. They are responsible for ensuring the system meets the requirements for high-risk AI, including risk management, record-keeping, human oversight, and accuracy, robustness and cybersecurity; for the quality management system, the technical documentation, the conformity assessment, the EU declaration of conformity and the CE marking, registration where required, and corrective action (Article 16); and — critically — for establishing the post-market monitoring system (Article 72) and reporting serious incidents (Article 73). If you build the system and ship it under your name, this is you.

Deployers use an AI system under their own authority, other than in a personal, non-professional capacity. For high-risk systems their obligations focus on safe operation (Article 26): using the system in line with the provider’s instructions for use; assigning human oversight to people with the necessary competence, training, authority and support; ensuring input data is relevant and sufficiently representative for the intended purpose, to the extent they control it; monitoring operation and, where they have reason to consider the system presents a risk, informing the provider or distributor and the market surveillance authority and suspending use; reporting any serious incident they identify, first to the provider and then to the importer or distributor and the market surveillance authorities; keeping the logs under their control for at least six months; informing workers’ representatives and affected workers before using a high-risk system in the workplace; and telling people when an Annex III system makes, or assists in making, decisions about them. In defined cases, including deployers that are bodies governed by public law or private entities providing public services, deployers must also carry out a fundamental rights impact assessment before first use (Article 27). If you take someone else’s high-risk system and run it in your business, this is you.

Importers and distributors sit in the supply chain. An importer is established in the Union and places on the market a system bearing the name or trademark of a person established outside it. Before doing so, it must verify that the provider has carried out the conformity assessment, drawn up the technical documentation and appointed an authorised representative, and that the system bears the CE marking and comes with the EU declaration of conformity and instructions for use; it must not place a system it has sufficient reason to consider non-conforming on the market until it has been brought into conformity (Article 23). A distributor is any party in the supply chain, other than the provider or the importer, that makes a system available on the Union market. It must check for the CE marking, the EU declaration of conformity and the instructions for use before doing so, must not make available a system it has reason to consider non-conforming, and must take or secure corrective action, such as bringing the system into conformity, withdrawing it or recalling it, for one it has already made available (Article 24). Where a system presents a risk, both must inform the relevant parties.

The point that is easiest to underestimate: roles are not fixed by who you are, but by what you do with a given system. A company can be a deployer of a third-party tool and a provider of its own. And the Act provides that a distributor, importer, deployer or other third party is considered a provider of a high-risk AI system, inheriting the provider obligations in Article 16, if they put their own name or trademark on a high-risk system already on the market (subject to contractual arrangements that allocate the obligations otherwise), make a substantial modification to one in a way that keeps it high-risk, or modify the intended purpose of a system that was not high-risk so that it becomes high-risk (Article 25). White-labelling a vendor’s high-risk product and re-purposing a system for a high-risk use map directly onto those triggers. In our view, fine-tuning or retraining a high-risk system deserves the same scrutiny, because a change not foreseen in the initial conformity assessment that affects the system’s compliance can be a substantial modification. Now, well before the high-risk rules apply, is the moment to be honest about which hat you are wearing for each system in your estate.

What to do if your high-risk systems are not ready

If you have read this far with a sinking feeling, there is still time, and panic is not a strategy. For systems that will be high-risk, the work below is preparation for December 2027 or August 2028. For anything caught by rules already in application (prohibited practices, AI literacy, Article 50 transparency or the GPAI obligations), a gap is a present compliance issue and should be treated as one. In both cases, a measured, documented, good-faith remediation effort is the right operational response. Here is the approach we recommend.

Triage by risk and exposure first. Inventory your AI systems and classify each by role (provider, deployer, importer or distributor) and by risk category. Confirm first that nothing falls within a prohibited practice and that Article 50 transparency is in place where it applies, because those rules apply now. Then prioritise systems that are clearly high-risk under Annex III, that affect fundamental rights, health or safety, or that have wide exposure. A low-impact internal tool is a lower priority than a system making decisions about people. Do not try to fix everything at once.

Close the gaps that reduce live harm before the gaps that reduce paperwork. If human oversight is not actually operational, or a system is producing unsafe outputs, those are the first fixes — they reduce real-world risk and demonstrate that your priorities are right. Missing-but-low-harm documentation can follow on a planned schedule.

Decide consciously about systems that will not be ready. For each system that will need to meet the high-risk requirements and is unlikely to be ready in time, make and record a deliberate decision: invest to bring it into conformity, restrict its use, or plan its replacement or retirement. Where a system poses real risk today, operate it with compensating controls (such as heightened manual review) in the meantime. The wrong answer is to keep running it while pretending the issue does not exist.

Document the remediation plan with owners and dates. A credible plan — what is wrong, what you are doing, who owns it, by when — is itself evidence of a functioning governance process. Keep it current.

Handle disclosure deliberately and with advice. Where you have reporting or notification obligations, including for serious incidents, meet them. Where engagement with an authority or a customer is warranted, take legal advice on timing and content. When fines are set, the Act lists among the relevant factors the degree of cooperation with the national competent authorities and whether, and to what extent, the operator itself notified the infringement (Article 99).

Our view is that the organisations best placed when the high-risk rules apply will not be those with the thickest document pack. They will be those who can show a living system: monitoring that runs, oversight that works, logs that accumulate, documentation that is maintained, and a clear-eyed plan for the gaps that remain.

How McKenna Consultants can help

We are a UK-based software development and AI governance consultancy with 22 years of engineering experience, and our approach to the EU AI Act is deliberately practical. We sit with the people building and running the systems, not just the people writing the policies. That matters, because high-risk compliance lives in the technical detail: the logging pipeline, the oversight workflow, the monitoring loop, the incident playbook, the documentation that tracks the deployed reality.

As an AI governance consultancy in the UK, we help organisations on both sides of the role divide. For providers, we strengthen technical documentation, validate that record-keeping and post-market monitoring are genuinely operational, and pressure-test accuracy, robustness and cybersecurity. For deployers, we make human oversight real, get input-data governance fit for the intended purpose, and stand up incident-handling that will meet the reporting duties. And where you are not yet ready, we run the triage, prioritise remediation by genuine risk, and help you operate responsibly while you close the gaps.

If you would like a calm, technical second opinion on where your AI systems actually stand, against both the rules that apply now and the high-risk rules to come, we would be glad to talk. A short conversation can be enough to tell whether your position is solid or whether a focused piece of remediation work would materially reduce your exposure.

Sources

This article reflects McKenna Consultants’ practitioner perspective and is provided for general information. It is not legal advice. The EU AI Act is complex and some implementation details continue to evolve; please obtain formal legal counsel on your specific obligations.

Related Articles

Related Case Studies

View all case studies

Have a question about this topic?

Our team would be happy to discuss this further with you.

Get in Touch