EU AI Act in 90 Days: Mapping Table Article → Krasper Raigate Feature

TL;DR. The EU AI Act is no longer a future problem — its high-risk obligations are in force, and most enterprises that rolled out LLMs casually in 2023–2024 are now on the wrong side of Articles 9 through 15. This post is a working mapping: each article, what it actually requires in operational terms, and how a transparent AI governance layer like Krasper Raigate addresses it. It also lays out a 90-day plan in three phases for teams who are starting late.

Contents

1. The compliance clock you should already have started
2. Risk classification — where LLM use actually lands
3. A 90-day plan, in three phases
4. The mapping at a glance
5. Pre-deployment obligations (Articles 9, 10, 11)
6. Operational obligations (Articles 12, 13, 14)
7. Quality obligations (Article 15)
8. The deployer's lens (Article 26)
9. What 90 days actually buys you
10. Sources and the actual text of the Act

1. The compliance clock you should already have started

The EU AI Act entered into force on 1 August 2024. The headline dates that matter for any organization deploying LLMs in production:

• 2 February 2025 — prohibitions on unacceptable-risk AI take effect, plus obligations on AI literacy for staff.
• 2 August 2025 — obligations for general-purpose AI (GPAI) models and their providers take effect.
• 2 August 2026 — the bulk of high-risk AI obligations take effect, including the full weight of Articles 9 through 15.
• 2 August 2027 — high-risk obligations also apply to AI that is a safety component of products covered by other EU legislation.

The naive reading is that high-risk obligations are still in the future. The realistic reading is that compliance evidence is retrospective: when an authority opens a file in 2027, they will ask what your governance looked like in 2026 — and you will need to be able to produce records, not promises. The compliance clock you should have started is not the day the obligations bite, but the day you can prove the controls were in place.

This is why a 90-day plan is plausible at all: most of the work is in instrumentation and evidence, not in writing a brand-new policy framework. If you have a transparent AI governance layer in place, much of the evidence is already a byproduct of normal traffic.

2. Risk classification — where LLM use actually lands

The first question is whether a given AI use case is classified as high-risk under the Act. The decision tree:

Most enterprise LLM deployments fall into one of two categories. High-risk if the use case is on Annex III: HR/recruitment screening, credit scoring, education and exam grading, critical infrastructure management, law enforcement support, migration and asylum, judicial decisions. Limited risk if the AI interacts with people (a customer-service chatbot, a content generator that produces text or images delivered to end users). General-purpose models that are integrated into either category inherit the obligations of the category they are deployed in.

The mistake is to assume "we just use ChatGPT internally for productivity" puts you in the minimal-risk bucket. The moment that internal use feeds output back into a high-risk decision — a hiring shortlist, a credit assessment, a triage of customer claims — the high-risk obligations attach to the LLM as well.

3. A 90-day plan, in three phases

Three phases, thirty days each, with explicit deliverables:

The phases are sequential because the artifacts depend on each other. You cannot instrument controls before you know which use cases need controlling. You cannot document a system before the controls are in place. And you cannot get sign-off on documentation that has not been ratified by the people accountable for the system.

4. The mapping at a glance

The compact mapping for the operational articles:

• Art. 9 — Risk Management System. Required: continuously identify, evaluate, and mitigate risks throughout the lifecycle of the AI system. Proxy delivers: asset registry with risk tiers per registered system; periodic review workflow with decision records.
• Art. 10 — Data Governance. Required: training, validation, and testing data must meet quality criteria; provenance and bias must be examined. Proxy delivers: for inference-time governance — enforce that data leaving the organization to a third-party model meets data-protection rules, with policy gates before requests are forwarded.
• Art. 11 — Technical Documentation. Required: maintain technical documentation that demonstrates compliance, available to authorities. Proxy delivers: policy bundles, audit trails, and evaluation reports exportable as a compliance pack.
• Art. 12 — Record-Keeping. Required: automatic recording of events ("logs") to ensure traceability of the system's functioning. Proxy delivers: per-call audit events with hash-chained tamper-evidence; append-only storage.
• Art. 13 — Transparency / Information to Deployers. Required: provide clear and adequate information about the system's capabilities, limitations, and intended use. Proxy delivers: per-system documentation surfaced through the governance UI; trace endpoints showing what policy applied to what call.
• Art. 14 — Human Oversight. Required: enable human oversight; people must be able to interpret outputs and intervene. Proxy delivers: approval workflows with SLA deadlines; override controls; explicit "this decision was made / overridden by [principal]" in audit.
• Art. 15 — Accuracy, Robustness, Cybersecurity. Required: achieve and maintain appropriate levels of accuracy, robustness, and cybersecurity. Proxy delivers: evaluation framework for periodic testing; cybersecurity controls baked into the proxy itself (fail-closed, signed policy bundles, role-gated reverse paths).

The next sections walk through each article in operational terms — what it requires in practice, where the obligation lands operationally, and what concretely is in place when the governance layer is properly deployed.

5. Pre-deployment obligations (Articles 9, 10, 11)

Article 9 — Risk Management

The Act requires a risk management system, not just a one-off risk assessment. The distinction matters: a system is a documented process that runs continuously over the lifecycle of the AI, with periodic reviews triggered by either time or material change.

The operational core is an asset registry: every AI system in the organization is a registered entry, with a defined risk tier (Low / Medium / High / Critical), a defined owner, a defined dependency graph (which datasets feed it, which downstream systems consume its output), and a defined review cadence. When the system changes materially — a new model version, a new data source, a new deployment context — a review is triggered automatically and a fresh decision is recorded.

What an authority will ask: "Show me the risk assessment for this AI system as it stood eight months ago." What you need to produce: a versioned record from the asset registry with timestamped decisions, the rationale, and the people who signed off.

Article 10 — Data Governance

For training data, the Act sets out criteria around relevance, representativeness, freedom from errors, and statistical bias. Most enterprises deploying LLMs do not train their own models, but Article 10 still has teeth — because the data your applications send to a third-party model is itself a governance question.

A transparent governance proxy enforces the inference-time interpretation of Article 10: every request is inspected before it leaves the network, sensitive data is redacted or blocked according to policy, and the decision is logged. The proxy does not replace the upstream provider's training-data governance, but it does establish what the deployer did to control the data flowing through it.

Article 11 — Technical Documentation

Annex IV of the Act lists what the technical documentation must cover: a general description of the AI system, design specifications, data requirements, training methodology (where applicable), the validation and testing procedures, the metrics used to measure accuracy and robustness, the cybersecurity measures, and the system architecture.

For a deployer, the practical answer is to maintain a single compliance pack per AI system, with all of these sections, and to keep it generated rather than hand-written wherever possible. Audit trails, policy versions, and evaluation reports are evidence — not narrative. The narrative wraps around the evidence; the evidence is the load-bearing part.

6. Operational obligations (Articles 12, 13, 14)

Article 12 — Record-Keeping

Article 12 is the article that quietly changes how AI systems have to be built. It requires automatic logging of events that allows the system's functioning to be traced. The standard most regulators are converging on, in practice: logs that are tamper-evident, append-only, and reconstructable.

This is where a hash-chained audit trail comes in. Every governed LLM call produces one audit event. Each event references the hash of the previous event. Any after-the-fact modification breaks the chain in a way that can be detected mechanically. A nightly integrity check walks the chain forward from a known-good anchor; any break creates an automatic incident.

A sample audit event with explicit Article references:

The compliance_refs field is what makes the audit trail useful for a regulator. When an authority asks for evidence on Article 14 oversight, you query the audit store for events where compliance_refs contains EU_AI_ACT_ART_14 and produce them as evidence.

Article 13 — Transparency to Deployers

Article 13 places an obligation on providers of high-risk AI to give deployers clear and adequate information. From the deployer's side, the equivalent obligation is to consume that information correctly: to know what the system can and cannot do, what its limitations are, and where the boundaries of intended use sit.

A governance proxy contributes to transparency by making per-call traces available — what was sent, what was returned, what policy applied — and by surfacing the system-level metadata (model version, policy bundle version, redaction strategy in force) on every audit event. Transparency is not a single document, it is a set of queryable properties of the system.

Article 14 — Human Oversight

Article 14 is one of the most operationally specific articles in the Act. It requires that natural persons can effectively oversee the AI system, understand its outputs, intervene when necessary, and disregard or override its decisions. The scope of "natural persons" includes both the deployer's staff and, depending on context, the affected end users.

The operational shape of human oversight: an approval workflow that triggers on defined conditions, an SLA on how quickly an approver must respond, an audit record of who approved what and when, and a clear override path. A request that meets a high-risk policy condition is held pending approval; an authorized human reviews the request, decides allow or block, and the decision is recorded with their identity. If no human responds within the SLA, the request is blocked by default — fail-closed extends to oversight, not just to scanning.

7. Quality obligations (Article 15)

Article 15 — Accuracy, Robustness, Cybersecurity

Article 15 is the article that closes the loop. The earlier articles cover what the system should do; Article 15 covers how well it actually does it, and how resilient that performance is.

Three sub-obligations:

• Accuracy. The system must achieve appropriate levels of accuracy for its intended purpose, and the metrics used to measure accuracy must be declared in the technical documentation.
• Robustness. The system must be resilient against errors, faults, and inconsistencies — including adversarial inputs and out-of-distribution data.
• Cybersecurity. The system must be designed and developed to ensure an appropriate level of cybersecurity throughout its lifecycle.

Operationally, this lands on three components. An evaluation framework runs periodic test suites against the deployed system and produces accuracy reports tied to the model version and policy bundle version. A drift monitor watches production traffic for distribution shifts that would invalidate the accuracy claims. A cybersecurity baseline includes the proxy itself: fail-closed defaults, signed policy bundles, role-gated reverse paths, mTLS for east-west service traffic, and supply-chain attestation for the artifacts that make up the deployment.

8. The deployer's lens (Article 26)

Most of the obligations described above target providers of high-risk AI systems. Article 26 is the deployer's article: the organization that uses a high-risk AI system has its own set of duties, including using the system in accordance with its intended purpose, monitoring its operation, ensuring human oversight, keeping logs for at least six months, and notifying authorities of serious incidents.

For an organization that integrates a third-party LLM into a high-risk workflow, this is the mirror image of Articles 9–15. The provider is on the hook for the model. The deployer is on the hook for what the deployer does with the model. The audit trail produced by the governance layer is the deployer's primary evidence base for Article 26 compliance.

9. What 90 days actually buys you

Ninety days is enough time to go from no defensible compliance posture to a defensible posture for an LLM-using organization that did not pre-plan for the AI Act. It is not enough time to build a bespoke governance platform from scratch — which is why almost every successful 90-day rollout uses a transparent governance layer that is already built and ready to be configured.

What you have at the end of 90 days, done well:

• A complete inventory of AI use cases, classified by risk tier
• A governance layer enforcing Articles 9, 10, and 13 controls in production traffic
• An audit trail that satisfies Article 12, with hash-chained tamper evidence
• Approval workflows in place for Article 14 oversight
• An evaluation baseline for Article 15 accuracy and robustness reporting
• A compliance pack that can be handed to an auditor, an internal risk committee, or a customer's procurement team

What you do not have at the end of 90 days: a finished problem. The Act's obligations are continuous. The point of 90 days is to start them.

10. Sources and the actual text of the Act

The full text of Regulation (EU) 2024/1689 is published in the Official Journal of the European Union and freely available on EUR-Lex. The articles referenced in this post:

• Article 5 (Prohibited AI practices)
• Article 6 and Annex III (High-risk AI systems)
• Article 9 (Risk management system)
• Article 10 (Data and data governance)
• Article 11 (Technical documentation)
• Article 12 (Record-keeping)
• Article 13 (Transparency and provision of information to deployers)
• Article 14 (Human oversight)
• Article 15 (Accuracy, robustness, and cybersecurity)
• Article 26 (Obligations of deployers of high-risk AI systems)
• Article 50 (Transparency obligations for providers and deployers of certain AI systems)

Reading the actual text takes longer than reading any summary, including this one. For the parts that materially affect a deployment decision, there is no substitute.