EU AI Act: What Must Be Operational by August 2026

Your legal team signed off on an AI governance policy in Q1. It's a PDF. Twelve pages. It references "appropriate measures" and "ongoing monitoring" in the abstract. It has no technical architecture, no evidence pipeline, no ownership assignments.

August 2, 2026 is 90 days away. That's when the EU AI Act's obligations for high-risk AI systems become enforceable under Article 113(1). Not "documented." Not "planned." Operational. Producing evidence. Withstanding supervisory inspection.

A policy PDF doesn't run. And national competent authorities aren't going to ask what you planned to build. They're going to ask what's producing records right now.

What "operational" actually means under the regulation

The EU AI Act doesn't use the word "operational" as a compliance standard. It uses something more precise. Article 9(1) requires that a risk management system "shall be established, implemented, documented and maintained." Article 17(1) requires that a quality management system "shall be in place." Article 12(1) requires that logging capabilities "shall allow" automatic recording.

These are present-tense obligations. They describe systems that are running, not systems in procurement. Article 99 grants penalties up to EUR 15 million or 3% of worldwide annual turnover for violations of Articles 9 through 15.

The regulation was published in June 2024. Two years is what you got.

The seven operational requirements, article by article

Each of Articles 9 through 15 creates a distinct operational obligation for providers of high-risk AI systems. Here's what each one demands in running form, not documented form.

Article 9: Risk management system

Article 9(2) requires "a continuous iterative process planned and run throughout the entire lifecycle of a high-risk AI system, requiring regular systematic updating." The key word is "run." This isn't an annual risk assessment. It's a system that identifies risks, estimates them, evaluates them, and produces mitigation measures on an ongoing basis.

Operational means: automated risk identification triggers, scored risk registers with lifecycle tracking, scheduled re-evaluation cadences, and documented risk treatment decisions with timestamps.

Article 10: Data governance

Article 10(2) specifies that training, validation, and testing data sets "shall be subject to data governance and management practices appropriate for the intended purpose." Article 10(2)(f) requires examination for biases likely to affect health and safety or fundamental rights.

Operational means: documented data lineage for every model in production, bias testing results with dates, data quality metrics updating as new training data enters the pipeline, and version-controlled records linking model versions to datasets.

Article 11: Technical documentation

Article 11(1) requires technical documentation "drawn up before that system is placed on the market or put into service and shall be kept up to date." Annex IV lists 15 specific elements the documentation must contain.

Operational means: living documentation that updates when the system changes. A documentation system with version history, change triggers, and completeness scoring against Annex IV requirements.

Article 12: Record-keeping (logging)

Article 12(1) requires that high-risk AI systems "shall technically allow for the automatic recording of events (logs) over the lifetime of the system." Article 12(2) specifies that logging shall include "the period of each use, the reference database against which input data has been checked, the input data for which the search has led to a match," and identification of natural persons involved in verification.

Operational means: automated logging infrastructure that captures events without human intervention, retention policies that cover the system's lifetime, and log integrity guarantees (immutability, timestamps, chain of custody).

Article 13: Transparency and provision of information

Article 13(1) requires systems to be "designed and developed in such a way that their operation is sufficiently transparent to enable deployers to interpret the system's output and use it appropriately." Article 13(3)(b) requires information about the "level of accuracy, including its metrics, robustness and cybersecurity" and "any known or foreseeable circumstances" that may impact performance.

Operational means: deployer-facing documentation that updates with each model version, accuracy metrics that are measured and published (not estimated once and never recalculated), and known-limitation disclosures that reflect current operational experience.

Article 14: Human oversight

Article 14(1) requires high-risk AI systems to be "designed and developed in such a way, including with appropriate human-machine interface tools, that they can be effectively overseen by natural persons during the period in which they are in use." Article 14(4)(d) requires the ability "to decide, in any particular situation, not to use the high-risk AI system or to otherwise disregard, override or reverse the output."

Operational means: built intervention mechanisms (not planned ones), trained operators (not identified ones), escalation procedures that have been tested, and override logs that record when and why a human overrode a system decision.

Article 15: Accuracy, robustness, and cybersecurity

Article 15(1) requires systems to "achieve an appropriate level of accuracy, robustness and cybersecurity, and perform consistently in those respects throughout their lifecycle." Article 15(4) requires resilience to "errors, faults or inconsistencies that may occur within the system or the environment."

Operational means: ongoing accuracy measurement against declared benchmarks, adversarial testing programs, incident detection for performance degradation, and cybersecurity controls that are monitored (not just implemented).

The operational readiness matrix

Here's what "running" looks like versus what "documented" looks like for each requirement:

Article	Requirement	"Documented" (insufficient)	"Operational" (required)
Art. 9	Risk management	Risk assessment PDF from 2024	Continuous risk scoring with automated triggers, lifecycle tracking, treatment audit trail
Art. 10	Data governance	Data governance policy	Automated lineage capture, bias metrics per model version, quality dashboards updating in production
Art. 11	Technical docs	Static Annex IV document	Versioned documentation with change detection, completeness scoring, auto-update on system changes
Art. 12	Logging	"Logs are enabled"	Immutable audit trail with retention policies, automated event capture, integrity verification
Art. 13	Transparency	User-facing FAQ page	Measured accuracy metrics, version-specific performance disclosures, limitation registry
Art. 14	Human oversight	"Operators can escalate"	Built override mechanisms, trained operators, tested escalation procedures, override audit logs
Art. 15	Accuracy/robustness	Initial benchmark results	Continuous performance monitoring, adversarial test programs, degradation alerting

The pattern is consistent: documentation is necessary but not sufficient. Every article requires a system that runs, produces evidence, and can demonstrate its own operation to a supervisor.

The 90-day problem

Ninety days isn't enough to build these systems from scratch. It is enough to get existing infrastructure producing the right evidence in the right format, if you've already done the groundwork of building your AI inventory and moving beyond the policy PDF.

If you can't do everything, prioritize by enforcement likelihood. National competent authorities will start with registration checks (Article 49 is binary and easy to verify). Then they'll request technical documentation (Article 11 is visible in a desk review). Then they'll probe operational evidence: is the risk management system running? Do logs exist? Can operators override?

Start with what's auditable from a desk review: registration, documentation, and logging. Then build toward the obligations that require system-level evidence.

How Kyudo addresses each article

Kyudo's AI governance solution maps the EU AI Act's operational requirements to 156 controls from the SCF AAT (Artificial & Autonomous Technology) domain. Each control is scored, monitored, and evidence-linked.

Risk management (Art. 9): The Risk Registry maintains AI system risk profiles with continuous scoring and lifecycle tracking. CMCAE evaluates risk controls across all frameworks simultaneously, so the system serving the EU AI Act also serves ISO 42001 and NIST AI RMF.

Data governance (Art. 10): Evidence Hub captures data lineage artifacts, bias testing results, and data quality metrics. Each evidence artifact has a freshness score. Stale evidence (older than 30 days) gets flagged, not silently credited.

Technical documentation (Art. 11): PolicyPilot manages documentation as living artifacts with version control, completeness scoring against Annex IV, and change-detection triggers.

Record-keeping (Art. 12): Integration with Azure Monitor, Microsoft Sentinel, and Defender for Cloud captures AI system logs automatically. The integrations layer pipes log data into Evidence Hub with immutability guarantees.

Transparency (Art. 13): Controls Hub scores transparency obligations at the control level. Accuracy metrics and deployer notifications are tracked as control evidence, not one-off documents.

Human oversight (Art. 14): Controls Hub includes controls for override mechanism existence, operator training completion, and escalation procedure testing. Evidence of tested override is required for full credit.

Accuracy and robustness (Art. 15): CMCAE's continuous assessment treats performance monitoring as an ongoing control. When accuracy drops below declared thresholds, the control score degrades automatically.

All of this maps through the Controls Hub. The STRM Engine ensures that work done for the EU AI Act also credits ISO 42001, NIST AI RMF, and Singapore's Model AI Governance Framework where requirements overlap.

The counter-argument: "We'll wait for enforcement guidance"

Some organizations are betting that national competent authorities won't enforce aggressively in the first year. They're waiting for guidance documents, precedent decisions, and clarity on exactly how supervisors will conduct inspections.

This is a rational short-term bet with three problems.

First, the regulation is already in force. If a supervisory authority inspects you on August 3 and you have nothing operational, "we were waiting for guidance" is not a defense.

Second, the AI Office has already published guidelines on prohibited practices (February 2025) and is publishing high-risk classification guidance. The trajectory is toward more specificity, not less.

Third, the market signal matters independently of enforcement. Article 49 registration is public. The EU database of high-risk AI systems is visible. Organizations that register early signal maturity.

The informed position: build the operational layer now, refine as guidance emerges. The cost of building logging, risk scoring, and documentation management doesn't increase if guidance changes. It only increases if you wait.

Your 90-day action checklist

Complete high-risk classification for every AI system in your inventory. If you don't have an inventory, that's day-one work. Use the Annex III categories as your filter. If it might be high-risk, treat it as high-risk until you've documented why it isn't.
Activate logging for all classified high-risk systems. Article 12 compliance is infrastructure. It doesn't require policy decisions or organizational change. It requires that logs exist, are retained, and are immutable. Start here because it's the hardest to backfill.
Score your Annex IV documentation completeness per system. Annex IV has 15 elements. Score each system 0-15. Anything below 12 needs immediate documentation work. This is the most likely first-pass check by supervisory authorities.
Assign human oversight operators by name, with documented training. Article 14 requires effective oversight by natural persons. "The team" is not a natural person. Name the operators. Document their training. Test the override mechanism.
Register any system that meets high-risk classification. Article 49 registration is a prerequisite. It's also the most visible compliance signal. Do it before August, not on August 1.

Regulatory clocks don't pause for implementation roadmaps. The EU AI Act's clock started in August 2024. It lands in August 2026. What runs on that date is what counts.

Kyudo maps 156 AI governance controls from the SCF AAT domain across the EU AI Act, ISO 42001, NIST AI RMF, and Singapore's Model AI Governance Framework. One operational layer. Every AI regulation.

Download the framework map to see how EU AI Act requirements map to controls you may already operate.