EU AI Act Deadline: Your AI Inventory Doesn't Exist

A national supervisory authority sends your organization a request: produce your AI system register. List every AI system you deploy or make available in the EU. Classify each by risk tier. Name the owners. Provide documentation of your risk management system.

You don't have one.

This isn't a hypothetical for 2030. The EU AI Act's obligations for high-risk AI systems become enforceable in August 2026. That's 15 months from today. And most organizations can't answer the three questions that every enforcement action will start with: How many AI systems do you operate? Which ones are high-risk? Who owns each one?

What the regulation actually requires

The EU AI Act is 458 pages. Most coverage focuses on headline prohibitions and big fines. The real compliance burden is in the operational obligations for high-risk AI systems.

Article 6: High-risk classification. An AI system is high-risk if it falls under Annex III categories (biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, justice) or is a safety component of a regulated product. If your system fits, the full set of obligations applies.

Article 9: Risk management system. High-risk systems require lifecycle-long risk management. Not a one-time assessment. Article 9.2 explicitly requires ongoing, iterative risk management that accounts for risks emerging after deployment.

Article 10: Data governance. Training, validation, and testing datasets must meet quality criteria. Bias examination is required. If you use a third-party model, you still need to understand its data governance practices.

Article 11: Technical documentation. System descriptions, design specs, development process details, and risk management system documentation must exist before market entry and stay up to date.

Article 13: Transparency. Systems must be transparent enough for deployers to interpret outputs appropriately, with documented intended purpose, accuracy levels, known limitations, and performance conditions.

Article 14: Human oversight. Humans must be able to understand the system, interpret its output, override decisions, and halt operation.

Article 49: Registration. Providers and deployers must register high-risk systems in an EU database before market placement.

Article 62: Serious incident reporting. Providers must report incidents involving death, health damage, infrastructure disruption, fundamental rights breaches, or serious property/environmental damage.

Each article creates specific evidence requirements. A policy document doesn't satisfy any of them. As we explore in AI Governance Beyond the Policy PDF, the gap between having a policy and running an operational program is where most organizations get stuck.

Obligations by risk tier

The EU AI Act creates four risk categories. Each carries different obligations.

Risk Tier	Definition	Key Obligations	Evidence Required
Unacceptable	Social scoring by governments, real-time biometric identification in public spaces (with exceptions), manipulation of vulnerable groups, emotion recognition in workplace/education	Prohibited. Must not deploy.	Documentation that you've identified and removed any such systems
High	Annex III categories: biometrics, critical infrastructure, education/training, employment, essential services, law enforcement, migration, justice; safety components of regulated products	Full compliance with Articles 9-15, conformity assessment, registration, post-market monitoring	Risk management system docs, technical documentation, data governance records, transparency disclosures, human oversight procedures, registration confirmation, incident reporting procedures
Limited	AI systems that interact with people (chatbots), emotion recognition systems, deepfake generators	Transparency obligations: users must know they're interacting with AI, content must be labeled	User notification mechanisms, content labeling systems, disclosure records
Minimal	All other AI systems (spam filters, AI-enabled video games, inventory management)	No mandatory obligations (voluntary codes of practice encouraged)	None required, but voluntary compliance documentation demonstrates good governance

The problem for most organizations isn't the unacceptable tier (those use cases are obvious) or the minimal tier (no obligations). It's the high-risk tier. Most enterprises don't know whether their AI systems fall into Annex III categories, because they've never done the classification exercise.

That HR screening tool your recruitment team adopted last year? Annex III covers AI systems used in employment. The credit scoring model in your lending platform? Annex III covers AI systems used to evaluate creditworthiness. The AI-assisted diagnostic tool your healthcare subsidiary uses? Annex III covers medical devices.

If you haven't inventoried and classified, you don't know your exposure.

"We don't deploy AI in the EU"

This is the most common objection, and it's wrong more often than people think.

The EU AI Act has extraterritorial scope. Article 2 is explicit: the regulation applies to providers placing AI systems on the EU market or putting them into service in the EU, regardless of where the provider is established. It also applies to deployers of AI systems who are located within the EU.

But here's the part that catches people: it applies to providers and deployers located outside the EU if the output produced by the AI system is used in the EU.

That means: if your AI system generates a credit decision that affects an EU resident, you're in scope. If your AI-powered HR tool screens candidates for roles in EU offices, you're in scope. If your customer service chatbot handles queries from EU-based customers, you're in scope.

The territorial trigger isn't where your servers sit or where your company is headquartered. It's where the AI system's output has effect.

For multinational organizations, this means the classification exercise isn't limited to your EU subsidiaries. Every AI system that could produce outputs affecting people in the EU needs to be assessed.

The inventory problem is harder than it looks

Here's why organizations struggle with the first step.

Shadow AI is pervasive. Business units adopt AI tools without going through procurement. Marketing's writing assistant, sales' lead scoring tool, finance's forecasting model inside the ERP. None went through IT. None have been risk-classified.

Embedded AI is invisible. Your CRM vendor added AI features in a product update. Your cloud provider enabled AI-powered threat detection by default. These aren't systems you deployed. They're capabilities that appeared inside tools you already use. Under the EU AI Act, deployers have obligations too. This fourth-party AI risk, where your vendors' vendors introduce AI into your supply chain, is a growing blind spot we examine in Fourth-Party AI Risk in the Supply Chain.

The definition of "AI system" is broad. Article 3 covers any machine-based system that operates with varying autonomy and infers how to generate predictions, content, recommendations, or decisions. That captures a lot of software organizations don't think of as "AI."

Most organizations find 3-5x more AI systems than expected when they do a thorough inventory.

How Kyudo addresses this

Kyudo's approach to EU AI Act compliance starts with the Compliance Graph and the AI Governance module, a knowledge graph connecting controls, evidence, risks, policies, frameworks, and vendors.

AI system inventory through Controls Hub. The SCF's AAT domain includes specific controls for AI system asset management. Kyudo's Controls Hub maps these to Article 49 registration requirements. Each AI system gets a record: owner, purpose, data sources, deployment context, risk tier, deployment date, last assessment date. The inventory isn't a spreadsheet. It's a node in the graph, connected to the controls that govern it and the evidence that proves those controls are operating.

Risk classification mapped to EU AI Act tiers. The Controls Hub includes controls for AI risk classification that map directly to Article 6 criteria. The classification rationale gets documented as evidence, scored, and linked. When an auditor asks why a system was classified as high-risk (or why it wasn't), the reasoning and approval chain are traceable.

Continuous assessment via CMCAE. The Continuous Multi-Framework Control Assessment Engine runs assessments on a schedule. Evidence freshness matters: artifacts less than 7 days old are fresh, 8-30 days is aging, over 30 days is stale. For high-risk AI systems requiring post-market monitoring under Article 9.2, continuous assessment isn't optional. Kyudo automates the cadence.

Evidence collection for each obligation. Evidence Hub collects artifacts from operational systems, not just uploaded documents. Every artifact carries a hash (proving integrity), full lineage (showing where it came from), and a confidence score. For EU AI Act compliance, evidence sources include model deployment records, risk assessment outputs, bias testing results, transparency disclosures, human oversight logs, and incident reports.

Sovereign deployment. Kyudo deploys inside your Azure tenant. Your governance data stays in your environment. For organizations subject to EU data residency requirements, your AI governance platform shouldn't create its own data sovereignty problem.

The Two-Layer Trust architecture keeps scoring and validation (Layer 1) deterministic, with no AI involved. Advisory capabilities like policy drafting (Layer 2) carry confidence scores and citations. You always know whether you're looking at calculated fact or AI-generated advice.

Your Monday morning checklist

You have 15 months. Here's how to use the first four weeks.

Week 1: Inventory discovery

Survey every business unit: what AI tools are you using? (Include free tools, browser extensions, and SaaS features)
Pull your software asset management data and flag anything with AI/ML capabilities
Check your cloud resource inventories (Azure AI Studio, AWS SageMaker, GCP Vertex AI endpoints)
Ask your top 10 SaaS vendors: have you added AI features in the last 12 months?

Week 2: Classification

Apply EU AI Act risk tiers to every identified system
Document classification rationale for each (especially border cases between high and limited)
Identify systems where output reaches EU residents (extraterritorial scope)
Count your high-risk systems and assign preliminary owners

Week 3: Gap assessment

For each high-risk system, check whether technical documentation exists (Article 11)
Identify which systems have human oversight mechanisms (Article 14)
Check whether data governance documentation exists for training and validation data (Article 10)
Assess whether you have incident reporting procedures that cover AI-specific events (Article 62)

Week 4: Program design

Define your risk management system structure (Article 9)
Assign roles: who owns the AI system register, who approves classifications, who reviews evidence
Select a control framework (SCF's AAT domain gives you 156 controls pre-mapped to EU AI Act articles)
Set a timeline for closing gaps before August 2026 enforcement

The organizations that start this quarter will have a functioning program by enforcement. The ones that wait until Q1 2026 will be scrambling.

AI that reasons over governance, not just chats about it.

Ready to see where you stand? Try the AI risk assessment and get a baseline inventory of your AI governance gaps mapped to EU AI Act obligations.