Your AI tools are already breaking the law

In August 2026 the high-risk and transparency provisions of the EU AI Act come into full force. I was a chief operating officer at a high-growth technology firm through the GDPR build-up, and on the face of it this is a similar beast. The reaction and the preparation, however, are noticeably more muted.

Here is the thesis. European businesses are dramatically underestimating the repercussions, and the misjudgement is structural rather than a matter of effort.

This is not a warning about frontier models or autonomous agents. It is about the AI already embedded in your business today: the chatbot routing customer queries, the scoring model behind your outreach decisions, the automated system filtering job applications, the recommendation engine shaping what your users see. Every one of them exposes the organisation to liability under a framework most compliance teams have not yet read in full.

The deployer is not a passive party

The Act draws a distinction that matters enormously and is routinely misunderstood. It separates providers, the entities that build and supply AI systems, from deployers, those that use AI in a professional context. Most organisations assume that buying a compliant product from a compliant vendor moves the burden across. It does not.

Article 26 is unambiguous. Deployers carry independent, non-delegable obligations. They must ensure the people assigned to human oversight of a high-risk system have the competence, the training and the authority to do it. They must monitor operation against the provider’s instructions. They must keep logs. In specific sectors they must complete a fundamental rights impact assessment before the system goes live.

The practical consequence is significant. If your organisation uses an AI system inside the Act’s high-risk categories, your organisation is a regulated party, regardless of where the system was built, who built it, or what certificates the vendor can produce.

How wide high-risk actually is

What makes this acute is the breadth of the classification. Annex III lists the application domains that attract mandatory obligations, and the list is not limited to exotic or obviously dangerous uses. A tool that screens CVs and ranks candidates is high-risk. A system that monitors and evaluates employee performance is high-risk. So is AI used in allocating employee benefits, in pricing, or in credit decisions. Any AI producing individual-level predictions or assessments through profiling is always classified high-risk, with no derogation available, regardless of how narrow its stated purpose.

What the Act requires, and why most deployments cannot meet it

These are not tick-box requirements. They demand a different relationship between an organisation and its AI tools.

Article 9 requires a continuous risk management system, established before deployment and maintained throughout the operational lifetime. Not an annual review: an iterative, documented process covering known risks, foreseeable misuse, post-market monitoring data and the interaction between mitigations. It must be running before the AI is used, not assembled retroactively when a regulator comes asking.

Article 12 requires that high-risk systems automatically record events in logs sufficient to identify risks, support post-market monitoring and enable human oversight. This is a technical design requirement. If the system you are deploying was not built with compliant logging architecture, it is non-compliant however carefully you use it.

Article 14 requires that a human can effectively oversee operation, and the Act is explicit about what effective means. Oversight personnel must understand the system’s capabilities and limitations, detect anomalies, stay alert to the pull towards automatically deferring to an AI output, interpret results correctly, and where necessary disregard or reverse them. The right to override is not procedural. It is a substantive guarantee deployers have to actively protect.

Article 13 requires providers to supply instructions for use carrying validated performance metrics, known failure modes, the conditions under which performance degrades, and guidance on interpreting outputs. Where those instructions exist, deployers are bound by them. Where they are vague or absent, deployers face a compounding problem: they are expected to deploy appropriately without the information the Act says they are entitled to receive.

And Article 4 requires AI literacy. Providers and deployers must take active measures so staff dealing with AI systems understand enough to discharge their responsibilities. That covers product managers, compliance officers, salespeople making representations about AI capability, and managers using AI outputs in decisions affecting employees or customers. A one-hour onboarding module will not satisfy it in a regulated deployment.

The transparency problem underneath all of it

Article 50 is one example of a contravention sitting in plain sight today. Any AI system interacting directly with a natural person, customer-facing chatbots included, must clearly inform the user at the point of interaction that they are talking to an AI. Not buried in a footer, not disclosed in terms and conditions: at the start, in a manner a reasonably attentive person would notice and understand. A significant proportion of deployed customer-facing tools currently fail this.

The obligation extends to content. Systems generating synthetic audio, image, video or text must disclose that the content is artificially generated, and that applies to marketing copy, automated reports and synthetic voice in call centres. The duty falls on the deployer, not only the provider.

The governance gateway problem

Here is the structural issue that existing compliance approaches have not addressed.

The Act does not require that AI systems produce good outcomes. It requires that the processes by which they produce outcomes are governed, documented, auditable and subject to meaningful human oversight.

The distinction matters. A system can generate accurate outputs and still be non-compliant if the governance around them falls short. Conversely, a system with known limitations can be deployed compliantly if those limitations are documented, disclosed and built into an appropriately calibrated oversight process.

Most organisations are deploying AI with nothing between the system and the decision it influences. The AI produces an output. The output is acted upon. No logging captures what inputs produced it. No trained human reviews it against documented criteria for when to override. No risk process identified the foreseeable misuse before go-live. No instructions set out the conditions under which the system performs below its validated accuracy.

This is not wilful non-compliance. It is the natural consequence of adopting AI through commercial procurement processes designed before the framework existed.

What the Act demands, at its core, is an auditable trace. For every consequential AI-assisted decision there should be a record of what the system received, what it produced, who was responsible for oversight, whether an override was applied and on what basis, and how long the record is kept. That trace is the evidentiary infrastructure on which regulatory inspection, incident investigation and fundamental rights accountability all depend.

The architecture implication

Treating the trace as an afterthought, something that might be assembled from existing system logs if a regulator ever asks, is not viable. Logging capability has to be an architectural feature present before deployment. Retrofitting audit infrastructure onto a system already running will not satisfy Article 12.

So organisations deploying AI in Annex III use cases need to revisit the architecture of those deployments. The question is not whether the model is capable. It is whether the deployment context, the governance wrapper around the model, provides the structure the Act requires.

This is where a governance gateway becomes architecturally and legally imperative rather than administratively convenient. It is the layer between an AI system’s output and the decision that output informs. It captures the relevant inputs, records the output, applies the oversight protocol, enforces the rules about when and how override is permitted, and produces the log entry the Act requires. It is the point at which operation becomes auditable, transparent to the deployer and subject to meaningful human control.

Without such a layer the system is a black box relative to the compliance requirements, even where its internal workings are technically explicable. With it, a deployment can demonstrate to a regulator, and to an affected individual, how a decision was reached, who was responsible, and what human judgement was applied before it was acted upon.

What to do now

The firms that will get through August 2026 without a suspended system are the ones starting the classification exercise before the enforcement regime is fully active and before they are asked to demonstrate compliance under pressure.

• Map every deployment

  Against Annex III and the Article 5 prohibitions. Which are high-risk, which trigger transparency duties, which must be removed entirely.

• Gap-check Article 26

  Is there a risk management system? Are logs compliant? Is oversight genuine, meaning the assigned person can actually override?

• Fix the architecture

  The step most often skipped. Documenting a non-compliant deployment does not make it compliant.

This is no small undertaking, but the alternative is exposure under active regulatory surveillance, with authorities empowered to demand documentation at short notice, audit, and suspend systems pending remediation. Under Article 99, penalties for high-risk non-compliance reach 3% of global annual turnover, and for prohibited practices 7%.

The window is narrower than it looks. Conformity assessment, where required, must be completed before the system goes live under full enforcement. Risk management systems must already be established and documented, not initiated when the clock starts. Organisations treating August 2026 as a distant problem will find, as they did with GDPR, that genuine compliance is not addressable in the few weeks before a deadline.

If you are using AI in a professional context in the EU, the Act applies. There are no exceptions. The question is whether the architecture of your deployments can demonstrate it when asked, and almost every implementation falls short today.