As of 2 August 2026, the high-risk obligations of the EU AI Act apply. The countdown is over. For the first time, organisations that build, sell, import or deploy high-risk AI systems in the European Union are operating under a live regulatory regime, with national competent authorities empowered and market surveillance functions switching on. The EU AI Act is now in force in the fullest practical sense, and the question has shifted overnight from “what do we need to ship before the deadline?” to “what does it actually mean to operate under the law every working day?”
This article is written from the practitioner’s chair, two days after the milestone. Over the past months we have run readiness assessments, helped clients assemble technical documentation, and stress-tested human-oversight arrangements. What we are seeing now is a different kind of challenge. Preparing a documentation pack is a project with an end date. Running a compliant AI system in production is a discipline that never stops. EU AI Act day one 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.
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 details remain in flux, and you should take formal legal counsel on your specific obligations.
From documentation to operational discipline
In the run-up to 2 August, most of the effort across the market went into artefacts. Risk management files were written. Data governance statements were drafted. Technical documentation was assembled to satisfy Annex IV. Conformity assessments were scoped, CE-style markings considered, and the EU declaration of conformity prepared. All of this was necessary and correct.
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.
Day one is where those gaps become visible, because the obligations are no longer prospective. Consider what is now continuously expected of a high-risk system:
- 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 obligations are now active, with defined timelines for notifying the relevant authorities.
- Transparency obligations require that deployers and affected people receive the information the Act mandates, and that AI-generated or manipulated content is marked where required.
The shift in mindset is from “have we produced the evidence?” to “is the system behaving the way the evidence claims?” That is the real meaning of EU AI Act day one compliance.
What enforcement and market surveillance look like in the first weeks
It is worth being calm and realistic about enforcement in the opening period. The Act establishes a governance architecture: each Member State designates national competent authorities, including market surveillance authorities, while the European Commission’s AI Office coordinates at Union level, particularly around general-purpose AI. These bodies now have powers to request documentation, investigate, require corrective action, restrict or withdraw systems from the market, and ultimately impose penalties.
In practice, regulators do not flip a switch and audit every system on day three. Market surveillance is typically risk-based and complaint-driven, especially in the early weeks while authorities themselves build capacity. The more likely near-term triggers are a serious incident you are obliged to report, a complaint from an affected person or a competitor, a sectoral regulator already active in your domain (financial services, medical devices, employment), or a request for documentation that you must be able to satisfy promptly.
The penalty regime is the backdrop that focuses minds. The Act sets tiered administrative fines, with the most serious breaches — notably the prohibited-practice rules — carrying the highest ceilings, expressed as the greater of a fixed sum or a percentage of total worldwide annual turnover. Non-compliance with other obligations and the supply of incorrect or misleading information to authorities sit at lower tiers, but they are still substantial. The precise figures and how authorities exercise discretion will become clearer as practice develops, but the design intent is unambiguous: penalties are meant to be effective, proportionate and dissuasive at the scale of large global businesses.
We would also add a careful caveat. There is ongoing discussion at EU level — frequently referred to as the “Digital Omnibus” simplification agenda — about adjusting aspects of timing, administrative burden and the interaction between overlapping digital rules. Commentary on possible changes continues to circulate. Our practitioner advice is to treat the obligations as live and binding as they currently stand, while watching official sources for confirmed changes rather than acting on speculation. Building genuine operational discipline is robust regardless of how those discussions resolve; betting on relief that has not been enacted is not.
The most common day-one gaps we are seeing in real assessments
Across recent readiness work, a consistent set of gaps recurs. None of them are 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. Many teams have application logs and observability dashboards. Far fewer have 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.
Human oversight is named but not operational. A document says a human reviews outputs. In reality, the reviewer 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 common and serious gap.
Incident reporting has no playbook. Teams know serious incidents must be reported, but cannot 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? 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 have been retrains, prompt changes, dependency updates and configuration tweaks — none reflected in the file. The Act expects documentation to be kept up to date; a snapshot that is already stale undermines everything built on it.
Role confusion at the boundaries. Organisations are unclear about whether they are acting as a provider, a deployer, or both, for a given system — and therefore unclear about which obligations actually attach to them. This is common enough that it deserves its own section.
Provider versus deployer versus distributor, now the rubber has met the road
Before the deadline, the distinction between roles was a planning abstraction. Now it determines exactly what each organisation must do, and getting it wrong means either doing work you do not owe or, far worse, missing obligations you do.
Providers develop a high-risk AI system (or have one developed) and place it on the market or put it into service under their own name or trademark. Providers carry the heaviest load. They are responsible for the conformity assessment, the technical documentation and the EU declaration of conformity, the quality and risk management systems, ensuring the system meets the accuracy, robustness and cybersecurity requirements, registration where required, and — critically — establishing the post-market monitoring system and reporting serious incidents. If you build the model and ship it, this is you.
Deployers use a high-risk AI system under their own authority in a professional capacity. Their obligations are real but more focused on safe operation: using the system in line with the provider’s instructions for use, ensuring relevant input data is appropriate for the intended purpose, assigning competent human oversight, monitoring operation and suspending use and informing the provider where they identify risks or serious incidents, keeping the logs the system generates where under their control, and meeting transparency duties towards affected people. Public-sector deployers and certain others also have obligations around fundamental-rights impact assessment in defined cases. If you take someone else’s high-risk system and run it in your business, this is you.
Distributors and importers sit in the supply chain. Importers must verify that the provider has carried out the conformity assessment, that documentation and markings are in place, and that the provider is identifiable; they must not place a non-conforming system on the market. Distributors must check that the required markings and documentation accompany the system and act with due care before making it available. Both have duties to take action and inform the relevant parties if they have reason to believe a system is non-compliant.
The pivot most organisations 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 deployer (or distributor or importer) can be treated as a provider — inheriting provider obligations — if, for example, they put their own name or trademark on a high-risk system, make a substantial modification to it, or modify the intended purpose of a system in a way that brings it into the high-risk category. Fine-tuning a model, re-purposing a system for a new high-risk use, or white-labelling a vendor’s product can quietly move you up the chain. Day one is the moment to be honest about which hat you are wearing for each system in your estate.
What to do if you are not compliant on day one
If you have read this far with a sinking feeling, you are not alone, and panic is not a strategy. A measured, documented, good-faith remediation effort is both the right operational response and the posture regulators generally respond to far better than silence or denial. Here is the approach we recommend.
Triage by risk and exposure first. Inventory your AI systems and classify each by role (provider/deployer/distributor) and by risk category. Prioritise systems that are clearly high-risk under Annex III, that affect fundamental rights, health or safety, or that have wide exposure. A non-compliant low-impact internal tool is a lower priority than a non-compliant 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 continued operation. For each materially non-compliant high-risk system, make and record a deliberate decision: continue operating with compensating controls (such as heightened manual review), restrict its use, or temporarily suspend it. 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. Transparency handled well is a mitigating factor; concealment is an aggravating one.
The organisations weathering day one most comfortably are not necessarily those who were perfect on 2 August. They are 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 25+ years of engineering experience, and our work on 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 now, because day-one 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 meets the active reporting duties. And where you are not yet compliant, 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 now the law is live, we would be glad to talk. A short conversation is often enough to tell whether your day-one position is solid or whether a focused piece of remediation work would materially reduce your exposure.
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.
