The high-risk deadline is a product decision.

Why "we're not a European company" stopped being a defence

The most common reaction we hear when the EU AI Act comes up on a sales call is a version of "that's a European problem, and we're not in Europe." It was never quite true, and on August 2, 2026 it stops being useful at all. The Act's scope clause (Article 2) is written around where the output of the system is used, not where the vendor is incorporated. A provider or deployer established outside the EU still falls under the regime when the output produced by the AI system is used inside the Union. A document AI vendor headquartered in São Paulo, New York or Singapore whose extraction feeds a hiring decision, a credit line or a benefit determination for a person in the EU is in scope — through its customer, if not directly.

This is the part that catches product teams flat. Compliance exposure arrives through the customer's use case, not through the vendor's address. The customer exports the decision into a regulated context; the pipeline that produced the field the decision rested on inherits the obligation to be documentable. And the obligation is not satisfied by a clause in the master agreement that says "customer is responsible for regulatory compliance." The deployer carries deployer obligations under Article 26, the provider carries provider obligations under Article 16, and the split is decided by who does what to the system — not by who signed which paragraph.

For a platform this is a runtime problem, the same shape we argued in the audit-evidence post: the obligation does not live in a policy, it lives in what the pipeline can emit. The difference now is the clock. The framework has a date on it, and the date is close.

What actually becomes enforceable on August 2, 2026

The Act phased in over three years, and the phases matter because teams conflate them. It entered into force on August 1, 2024. The prohibited-practice rules and the AI-literacy duty applied from February 2, 2025. The general-purpose AI (GPAI) model obligations applied from August 2, 2025. The milestone that lands in 2026 — August 2, 2026 — is the one that turns on the bulk of the high-risk regime for Annex III systems, together with the governance, notified-body and penalty machinery that gives it teeth. (A further tranche, high-risk AI embedded in regulated products under Annex I, follows on August 2, 2027.)

For an Annex III system, the high-risk obligations are concrete and testable. They are not a statement of values:

• Risk-management system (Article 9) — a continuous, documented process that identifies and mitigates risks across the lifecycle, not a one-time assessment filed at launch.
• Data governance (Article 10) — evidence that training, validation and test data are relevant, representative and examined for bias, with the lineage to prove it.
• Technical documentation (Article 11 / Annex IV) — the dossier a market-surveillance authority can request, describing the system, its design choices, its data and its performance.
• Record-keeping (Article 12) — automatic logging of events over the system's lifetime, at a granularity that lets someone reconstruct what a specific decision rested on.
• Transparency (Article 13) — instructions and information that let the deployer understand and use the system correctly.
• Human oversight (Article 14) — oversight designed into the system so a person can understand, intervene in and override its output.
• Accuracy, robustness and cybersecurity (Article 15) — declared performance levels the system actually holds, and resilience against manipulation.
• Conformity assessment, CE marking and registration — the provider runs a conformity assessment, affixes the CE marking, and registers the system in the EU database before it goes on the market.

On penalties, the honest detail matters because the headline number is widely misquoted. The €35M-or-7%-of-turnover ceiling applies to prohibited practices — the things you cannot do at all. Breaching the high-risk obligations above sits in the next tier: up to €15M or 3% of global annual turnover, whichever is higher. Supplying incorrect or misleading information to authorities carries up to €7.5M or 1%. None of those are rounding errors, and all of them are calculated on group revenue, not on the contract value of the deal that put you in scope.

There is also the calendar noise, and pretending it away would be dishonest. Through the first half of 2026 there has been real momentum behind simplifying the digital rulebook, including proposals to push back parts of the high-risk timeline — particularly for systems newly placed on the market or substantially modified. A team could read that as a reprieve. It is not. A delay that has not been enacted is not a plan, the existing obligations for systems already in the field do not vanish, and the inventory-and-classification work is the same work whether the enforcement date is August 2026 or some months later. The teams that treat the noise as permission to wait are the ones that discover, under an audit schedule they do not control, that the preparation takes quarters.

Classify by use, not by technology

The single most expensive mistake we see is classification by model type. A team reasons: "we use a general-purpose vision-language model, so we look at the GPAI rules and stop there." Or the mirror image: "we only do OCR and field extraction, that's low-risk technology, so Annex III doesn't apply to us." Both are reading the wrong axis. The Act does not classify the technology. It classifies the use. The same extraction model is minimal-risk when it reads a receipt into an accounts-payable ledger and high-risk when the field it extracts feeds a creditworthiness assessment for a natural person.

Annex III is a list of use contexts, and the ones that touch document AI most directly are access to essential private and public services (including creditworthiness evaluation and credit scoring, and risk assessment and pricing in life and health insurance), employment and worker management (including CV screening and candidate evaluation), education and vocational training, and — depending on deployment — biometrics, migration and border control, and administration of justice. The classification turns on what the output is used to decide, which means the same platform can host limited-risk and high-risk pipelines side by side.

The operational consequence is that classification is not a one-line answer the vendor can give on behalf of every customer. It is a per-use-case determination, made against the customer's deployment context and their counsel's reading — the same boundary we refuse to cross at the end of this post. What the platform can do is make the determination cheap: know which tenants run which use cases, tag each pipeline with its risk class, and hold the evidence that lets the classification be defended either way.

The framework that survives the conformity assessment

Knowing the obligations is not the same as being ready for them. The teams that pass a conformity assessment without a three-quarter fire drill share a small number of habits, and none of them are about writing a better policy document.

An inventory of AI systems, classified by use and jurisdiction

You cannot govern what you have not listed. The first artifact is a live register of every AI system in production, each row tagged with its Annex III use context (or explicit "not high-risk, here's why"), the jurisdictions its output reaches, and the provider/deployer role the company holds for it. This is the artifact that converts "are we in scope?" from a panic into a query.

Data governance with lineage, not a data-quality slide

Article 10 wants evidence that the data behind the system is relevant and examined for bias. That means lineage — where the data came from, how it was selected, what was checked — recorded as the pipeline runs, not reconstructed from memory. A quality dashboard that shows the current state and nothing about provenance answers the wrong question.

Technical documentation the pipeline emits, not the team assembles

Annex IV is long, and the teams that dread it are the ones planning to write it by hand at assessment time. The ones that do not treat it as a chore have the pipeline produce most of it as a by-product: model and prompt versions, performance metrics, data descriptions and change history are logged as the system operates, and the dossier is a view over that log rather than a document someone drafts under deadline.

Human oversight as architecture, not a banner

Article 14 is not satisfied by a sentence in the UI that says "a human reviews these results." Oversight has to be real: a routing rule that sends low-confidence or high-stakes cases to a named reviewer, an interface that shows the reviewer what the model saw, the ability to override, and a record that the override happened. This is the same human-in-the-loop shape a regulated buyer already asks for in diligence, which is why the pre-launch access post and this one converge on the same architecture.

An audit trail that survives an external examiner

Record-keeping under Article 12 is the obligation that most resembles what a good pipeline logs anyway — but "most resembles" is not "is." The trail has to be automatic, per-decision, immutable and retained for the window the use case demands. Reconstructing it from git history and support threads is exactly the failure the requirement is written to make impossible.

The conformity assessment does not test your intentions. It tests whether the pipeline can produce the evidence it was supposed to have been producing all along.

Four ways the deadline catches vendors out

The failure modes below are not exotic. Each one has a defensive pattern that costs far less applied early than discovered late.

Treating the address as an exemption

"We're not a European company" is the first-order error, and it fails on Article 2's output-based scope. The customer exports the decision into the EU and the exposure follows the output. The fix is to map, per tenant, where the output actually lands — and to stop assuming that a non-EU headquarters is a wall.

Reading calendar noise as dispensation

A proposed delay becomes, in the retelling, "the high-risk rules got pushed back, we have time." Proposals are not law, the delay under discussion is partial, and the preparation is unchanged either way. The fix is to plan against the enacted date and treat any slippage as schedule relief, not as a reason to defer the work.

Classifying by model type instead of use context

The team looks at the model — "it's a VLM, it's GPAI" — and never asks what the customer decides with the output. Annex III is a list of uses, and the same model crosses the high-risk line the moment the output feeds credit, hiring or a benefit. The fix is a per-pipeline risk tag driven by the use case, reviewed when the customer's use case changes.

Leaving it to legal without instrumenting the pipeline

Compliance gets assigned to counsel, who produce a policy and a questionnaire response — and the pipeline emits none of the evidence the policy promises. At assessment time the gap between the document and the runtime is the whole story. The fix is to treat the obligations as engineering requirements: the inventory, the lineage, the logging and the oversight ship as features, on the same clock as the product.

The trade-off, stated honestly

There is a real cost to preparing early, and it is worth naming rather than waving away. Building the inventory, wiring lineage through the data pipeline, making technical documentation a by-product, and designing oversight as architecture is engineering work that competes with roadmap features a customer can see today. A team that does all of it for a use case that turns out to be limited-risk has spent effort it did not strictly owe. That is the honest downside.

The other side of the trade is exclusion. A vendor that cannot answer the conformity questions is not merely fined — it is disqualified from the deal, at the first procurement filter, in exactly the regulated verticals (finance, insurance, public sector, healthcare) where document AI is worth the most. The cost of early compliance is a known quantity, paid in engineering weeks. The cost of being unready is a market you cannot sell into and a penalty computed on group revenue. For any vendor with real European exposure, the trade favours doing the work before the date, not after the finding — and doing it once, as architecture, rather than repeatedly, as fire drills.

What we ship at Cogneris

Cogneris was built as an audit-instrumented platform, not as an extraction engine with a compliance layer bolted on afterward. The choices that show up in the architecture are the ones the high-risk regime happens to reward:

• Per-pipeline risk tagging — every tenant pipeline carries its use-case classification and the jurisdictions its output reaches, so "is this one in Annex III scope?" is a field, not an investigation.
• Lineage recorded at runtime — data sources, selection and checks are logged as the pipeline runs, giving the Article 10 evidence without a reconstruction project.
• Technical documentation as a view — model and prompt versions, performance metrics and change history are emitted by the pipeline, so the Annex IV dossier is assembled from the log rather than drafted under deadline.
• Human oversight built into routing — confidence thresholds and high-stakes rules send cases to a named reviewer with the context the model saw, the ability to override, and a record that it happened — the Article 14 shape, wired in by default.
• Per-decision, immutable audit trail — the record-keeping the Act asks for is the same envelope we described in the audit-evidence post, retained per the tenant's risk class rather than a single global default.

Where we deliberately stop

An honest list of the obligations we do not absorb on the customer's behalf, because absorbing them would be wrong or impossible.

The classification of the customer's use case. Whether a specific deployment clips Annex III is a determination for the customer's counsel against the customer's context. We make the determination cheap to defend by holding the evidence; we do not issue the verdict, because the wrong verdict is far more expensive than an honest "this is yours to decide."

The conformity assessment itself. Where a use case requires third-party assessment, that is run by a notified body, not by the vendor. We support it with the technical documentation, the lineage and the audit trail; we do not grant the CE marking, and we will not pretend our evidence is a substitute for the assessment.

Jurisdictional legal advice. Everything in this post is operational, not legal. The article references, the tiers and the dates are our working understanding, and the Act's own timeline has moved under political pressure before. The customer's counsel owns the reading that the customer relies on; we refuse to substitute for it.

Closing thought

August 2, 2026 is not a compliance event with its own roadmap sitting beside the product. It is a property the pipeline either has or does not have — the ability to be classified, documented, overseen and audited on demand — and the regulator assumes the property is there whether the team built it in or not. The teams that will pass treat the obligations as engineering requirements shipped on the product clock: an inventory that answers scope in a query, lineage recorded as data flows, documentation the pipeline emits, oversight designed into routing, and an audit trail that survives an external examiner. The teams that will struggle treat the date as a legal problem and discover, under an assessment schedule they do not control, that the preparation was architecture all along. The framework has settled and the date is fixed. The choice between the two is no longer strategic; it is operational, and it is the choice Cogneris was built around.

If you are working out whether your document AI pipeline clips the EU AI Act's high-risk threshold — and the conversation with internal audit starts the same week — see our data-protection page for the control posture we ship, or talk to our team and we will walk you through the evidence your program needs before the date, not after the finding.