Most of the EU AI Act will not touch you. The prohibited-AI headlines — social scoring, real-time facial recognition in public spaces, subliminal manipulation — are real but they apply to a narrow slice of use cases. The provisions that will generate the first wave of substantial fines are quieter, more technical, and sitting unread in the middle sections of a 113-page regulation most leadership teams have delegated to someone who hasn't read it either.
I read all 113 pages. Here is what actually keeps me up at night when I'm sitting across from a company deploying AI in a regulated sector.
Why Everyone Is Reading the Wrong Part
The AI Act conversation in boardrooms is almost entirely about prohibited AI (Article 5) and the high-risk AI annex (Annex III). That's understandable — the fines are largest and the examples are dramatic. But the enforcement that will actually land first is more mundane: documentation failures, missing logging, inadequate human oversight mechanisms, and deploying a third-party AI system without doing the required checks.
These aren't edge-case interpretations. They're explicit requirements with clear penalties and relatively straightforward evidence trails for regulators to follow.
Here are the six clauses that will generate the first real fines — and what you need to do about each.
Clause 1: Technical Documentation Before Deployment (Article 11)
If you are a provider of a high-risk AI system — meaning you develop or substantially modify one — Article 11 requires comprehensive technical documentation to exist before the system is placed on the market or put into service. Not shortly after. Not in a future sprint. Before.
The documentation must include: a general description of the system and its intended purpose; design specifications including the architecture, training methodology, and data used; information on the system's performance across different groups; and risk management measures. Appendix IV specifies the full list in detail.
The failure mode I see most often: companies that built an AI system internally, deployed it to production, and have documentation that consists of a Confluence page written six months after launch by someone who joined after the original team. That is not Article 11 documentation. That will not pass a conformity assessment.
What to do: Treat technical documentation as a pre-deployment gate, not a post-deployment artifact. Assign a named owner. Review it against Annex IV before any high-risk system goes live.
Clause 2: Automatic Logging That You Cannot Disable (Article 12)
High-risk AI systems must be designed to automatically log events throughout their lifecycle "to an extent appropriate to the intended purpose of the system." The logs must enable, at minimum: verification that the system operated as intended; traceability of outputs to inputs; and identification of circumstances that led to outputs that present risks.
Article 12 also specifies that these logs must be kept for a defined retention period — and for certain systems (e.g., those used by public authorities) the retention requirement is explicit in the regulation.
The failure mode: a company using an AI system for credit scoring or employment screening that has excellent application-level logging but no AI-specific audit trail linking the model's decision to the specific input features that drove it, the model version that ran, and the confidence score at the time. Generic application logs do not satisfy Article 12.
What to do: Implement model-specific logging that captures input data hash, model version, inference timestamp, output, and confidence. Store separately from application logs with explicit retention policies.
Clause 3: Human Oversight That Is Actually Functional (Article 14)
Article 14 requires that high-risk AI systems are designed and developed to be effectively overseen by natural persons. "Effectively" is the operative word — and it has teeth.
The system must enable human overseers to understand the system's capabilities and limitations, detect and address potential biases, remain aware of automation bias, and be able to intervene or override the system. Crucially, Article 14(4) states that the measures must be appropriate to the risk and implemented by the deployer if not built in by the provider.
The failure mode I see most often: a company that has added a "human in the loop" to satisfy a checkbox but the human reviewer is processing 400 AI decisions per day with 30 seconds per decision and no tooling to surface the edge cases, low-confidence outputs, or statistically anomalous decisions. That is not functional human oversight. A regulator will not accept it.
The automation bias trap
Article 14 specifically names automation bias — the tendency of humans to defer to automated recommendations — as something providers and deployers must design against. If your human oversight layer is reviewing AI decisions with no visibility into model confidence, decision rationale, or historical accuracy for similar cases, you have built a rubber stamp, not oversight. The regulation knows this. The fines will reflect it.
What to do: Audit your human review workflows. Calculate the actual time per decision. Instrument the review interface to surface confidence scores, flagged edge cases, and recent model accuracy on similar inputs. Document the oversight process formally.
Clause 4: Transparency to Users — Including Machine-Generated Content (Article 50)
Article 50 is the clause most companies outside the "traditional high-risk" categories need to pay attention to. It applies broadly and covers four distinct transparency obligations:
First, systems that interact directly with humans must inform those humans that they are interacting with an AI — unless it is obvious from context. Second, AI systems that generate synthetic audio, video, image, or text content must mark that content as AI-generated in a machine-readable format. Third, deployers of emotion recognition or biometric categorisation systems must inform affected persons. Fourth, providers of deep-fake systems have specific disclosure requirements.
The "machine-readable format" requirement for AI-generated content is where most companies are currently non-compliant. Watermarking standards are still evolving, but the obligation exists now. Using an LLM to generate product descriptions, customer communications, or social content without any machine-readable attribution is an Article 50 exposure.
What to do: Audit every customer-facing touchpoint where AI generates or substantially modifies content. Implement visible disclosure where appropriate. Begin tracking developments on the Commission's watermarking technical specifications — they are expected to clarify this in 2026.
Clause 5: Third-Party AI Systems — The Deployer Is Still Liable (Articles 25–26)
This is the clause that will catch the most companies off guard. If you are deploying a third-party high-risk AI system — think an AI hiring tool from a vendor, a credit-scoring API from a fintech, a medical decision-support system licensed from a software provider — you are the deployer under the AI Act. And Article 26 imposes substantial obligations on deployers.
Deployers must: ensure the system is used in accordance with instructions of use; implement human oversight; monitor the system's operation; and report serious incidents or malfunctions to the provider and competent authorities.
The critical point: you cannot contract your way out of deployer liability by pointing at the vendor's terms of service. The regulation explicitly makes deployers accountable for operational compliance. If your vendor's system violates Article 12 logging requirements and you're using it, you share the exposure.
| Obligation | Provider Responsibility | Deployer Responsibility |
|---|---|---|
| Technical documentation | Must create and maintain | Must receive and review |
| Conformity assessment | Must conduct | Must verify was conducted |
| Logging | Must build into system | Must ensure it operates correctly |
| Human oversight | Must enable technically | Must implement operationally |
| Incident reporting | Must report to market authorities | Must report serious incidents to provider and authorities |
| Post-market monitoring | Must establish plan | Must provide data to provider |
What to do: For every third-party AI system you deploy in a high-risk use case, request the technical documentation and conformity assessment records from the vendor. If they cannot provide them, you have a procurement problem that is also now a compliance problem.
Clause 6: Risk Management as a Living System, Not a One-Time Audit (Article 9)
Article 9 requires that providers of high-risk AI systems establish, implement, document, and maintain a risk management system. The word "maintain" is doing a lot of work there. This is not a point-in-time assessment. It is an ongoing process that must be updated throughout the lifecycle of the system.
The risk management system must identify and analyse known and reasonably foreseeable risks, estimate and evaluate risks that may emerge when the system is used as intended and when it is misused, adopt appropriate risk mitigation and control measures, and test the system to address residual risks.
The failure mode: a company that conducted an AI risk assessment during the build phase, documented it in a report that went to the compliance file, and has not revisited it since. The regulation requires that the risk management system reflects the current state of the deployed system — meaning any model update, any change in use case, any new data input type potentially triggers a risk management review.
Article 9 is a process, not a document
I've reviewed "risk management documentation" that was genuinely thorough at the time of writing. It was also two years old, and the model had been retrained three times since. Article 9 compliance requires version-controlled risk documentation that updates with the system. If your risk management lives in a PDF that nobody has opened since launch, it is not compliant.
What to do: Map your AI risk management to your model change management process. Any model update — retraining, fine-tuning, threshold change — should trigger a risk management review with a documented disposition. This is infrastructure, not a one-time deliverable.
Where You Probably Stand Right Now
Based on the engagements I've run since the Act came into force, here is what the compliance landscape actually looks like for mid-market companies with AI deployments:
| Compliance Area | Typical Status in Companies I've Assessed | Primary Gap |
|---|---|---|
| Article 11 — Technical documentation | 30% adequately documented | Documentation post-dates deployment; gaps on training data |
| Article 12 — Automatic logging | 25% AI-specific logging in place | Application logs conflated with model audit trail |
| Article 14 — Human oversight | 40% have a process | Oversight is nominal; automation bias not addressed |
| Article 50 — Transparency | 20% disclosing AI-generated content | No machine-readable marking; disclosure only in T&Cs |
| Articles 25–26 — Third-party deployer | 15% have reviewed vendor compliance | Vendor attestations accepted without documentation review |
| Article 9 — Risk management lifecycle | 35% have a living process | Static document; not updated with model changes |
None of these are heroic compliance gaps. They are addressable with a structured sprint — typically 6–10 weeks — if you start with a clear baseline of what you have and what you don't.
The Enforcement Timeline You Need to Know
The prohibited AI provisions (Article 5) have been in force since February 2025. The obligations for high-risk AI systems (Articles 9–14) come into full force in August 2026 for new systems, with a transition period for systems already on the market. General-purpose AI model requirements are in force from August 2025.
The enforcement timeline looks like this:
This means you have a narrowing window to treat this as a roadmap rather than a fire drill. Companies that start now can approach August 2026 with documented compliance. Companies that start in Q2 2026 will be doing a fire drill.
The first enforcement actions will not be against the companies doing the most egregious things. They will be against the companies with the clearest paper trail of non-compliance — the ones where documentation is absent, logging was never built, and the risk management file has not been opened in two years. Regulators follow evidence.
If your organisation is deploying AI in any regulated or high-risk context and you have not yet mapped your exposure against these six clauses, the time to start is now — not August 2026. Let's talk — book a 30-minute discovery call and we can scope a structured AI Act compliance review against your actual deployments.