From Discovery to Classification: The Step Most AI Governance Programmes Get Wrong

Ask a compliance team whether they have an AI inventory and most will say yes. Ask them how many of those inventoried systems have been correctly classified against the EU AI Act, GDPR, NIS2, and DORA - and whether that classification reflects how each tool is actually being used inside the organisation, not just what the vendor markets it as, and the picture looks different.

Discovery is the entry point. Classification is where governance either becomes real or stays on paper.

The two are routinely collapsed into a single step, and that collapse is responsible for a category of compliance exposure that most enterprises have not yet fully mapped. An AI system sitting in an inventory without an accurate risk classification is not a governed system - it is a documented liability, and the gap between the two is where most enterprise AI governance programmes currently sit.

This piece focuses on the classification problem - why it is harder than it looks, where organisations consistently misread their exposure, and what accurate, regulation-specific classification of discovered AI tools actually requires in practice.

Why Classification Is Not Simply the Next Step After Discovery

The mental model most organisations bring to AI classification is borrowed from GDPR's data processing records - identify what you have, document a few attributes, assign a category. That approach works when the category is defined by what data is processed. Under the EU AI Act, the risk category is defined by how the system is used and what decisions it influences. That distinction changes everything about how AI governance has to be structured, and it is the distinction most organisations miss when they borrow their classification approach from GDPR data mapping.

The same AI tool can fall into four different risk tiers depending on its deployment context. A general-purpose language model used to draft marketing copy is minimal risk. The same model, configured to screen job applications, is high risk under Annex III. The same model, used to prioritise emergency response dispatch, is high risk under a different Annex III category. The model has not changed. The regulatory obligation has shifted entirely based on use cases.

The Eight Annex III Domains - and Why They Catch Most Enterprises Off Guard

Annex III lists the eight high-risk use-case domains where AI triggers the Act's most stringent requirements. These domains are defined not by technology but by the nature of the decision being influenced:

The domain that surprises most enterprises is employment. AI tools embedded in ATS (applicant tracking systems), performance management platforms, and workforce analytics tools routinely fall into high-risk classification - not because they are obviously regulatory in scope, but because they influence consequential decisions about people's working lives. Most organisations have several of these tools active. Few have classified them as high-risk.

According to the Larridin State of Enterprise AI Report 2026, 75% of organisations lack AI governance frameworks, a finding consistent with readiness assessments conducted across financial services, healthcare, and technology sectors. The root cause, in most cases, was not that the tools were hidden - they were in the SaaS stack. It was that no one had done the use-case-level classification exercise to understand what those tools actually triggered under the Act.

The Role Determination Problem

Classification under the EU AI Act depends not only on what the system does but on what role your organisation plays in relation to it. Provider, deployer, and operator carry different, and overlapping - compliance obligations. Misidentifying your role is its own category of exposure.

This is where the majority of enterprises are getting it wrong in 2026, particularly in relation to the AI already inside their SaaS stack.

Provider, Deployer, Importer: The Roles the Act Defines

The deployer role is what most enterprises underestimate. Under Article 26 of the EU AI Act, deployers are responsible for using the AI system according to its provider's instructions, implementing human oversight, ensuring operators are trained, and monitoring for risks in the deployment context. None of these obligations can be contractually transferred to the SaaS vendor.

The practical consequence: an organisation that procures an AI-powered HR tool from a vendor, uses it to rank job candidates, and has not completed a Fundamental Rights Impact Assessment (FRIA) and put human oversight mechanisms in place is non-compliant, regardless of what the vendor's terms of service say about compliance responsibility.

That is not a theoretical interpretation. It is how the regulation is written and how enforcement under analogous GDPR provisions has operated for years. The deployer responsibility is real, and classifying your role accurately is the prerequisite to understanding what your AI governance framework actually obligated to do.

Cross-Framework Classification: Where It Gets Operationally Complex

The EU AI Act does not exist in isolation. An AI system classified as high-risk under the Act simultaneously creates obligations under GDPR, potentially triggers NIS2 requirements if it sits within critical infrastructure, and - for financial services organisations, falls under DORA's operational resilience framework. All four frameworks apply concurrently. Classification under one does not discharge obligations under the others.

The operational complexity of cross-framework classification is significant, and it is the dimension most compliance programs are least prepared for. Teams that have built EU AI Act classification workflows have rarely integrated them with the GDPR impact assessment process, the NIS2 cybersecurity risk assessments, or the DORA ICT third-party risk reviews already running in the organisation. The result is four parallel compliance processes touching the same AI system, none of them aware of the others.

These are not sequential risks. An AI system used in financial services for credit risk scoring that also processes personal data and sits in the institution's core infrastructure can simultaneously attract exposure under all three frameworks, for the same underlying system.

What Cross-Framework Classification Actually Requires

Effective cross-framework classification maps each discovered AI system to a single regulatory profile that captures all applicable frameworks simultaneously. That profile needs to answer four questions for every system in the inventory:

• Does it process personal data? - GDPR scope determination, lawful basis assessment, DPIA trigger evaluation
• Does it fall under Annex III use cases or perform profiling? - EU AI Act risk tier and conformity assessment obligations
• Does it sit within or interface with critical infrastructure, or operate inside a regulated sector? - NIS2 cybersecurity requirements and incident reporting obligations
• Does it serve financial services operations or is it a third-party ICT tool for a financial entity? - DORA operational resilience, contractual requirements, and third-party risk management obligations

Most organisations are performing these assessments separately - GDPR impact assessments owned by the DPO, AI Act classification owned by legal, NIS2 assessments owned by security, DORA reviews owned by IT risk. Each team has partial visibility. None has the complete regulatory profile of the AI systems they collectively govern.

This is the structural inefficiency that a classification-integrated governance platform resolves - not by replacing those teams' expertise, but by giving them a single, shared view of every system's cross-framework obligations, so that effort is coordinated rather than duplicated.

The Misclassification Scenarios That Create the Most Exposure

Classification errors fall into two types, and both carry regulatory consequences. Under-classification, treating a high-risk system as limited or minimal risk - creates direct enforcement exposure. Over-classification, treating a minimal-risk system as high-risk - creates resource misallocation and operational drag. The first is the more urgent problem in 2026.

Four patterns account for the majority of misclassification in enterprise environments:

1. Classifying at the Tool Level, Not the Use-Case Level

An enterprise purchases an AI content generation platform. IT classifies it as minimal risk because the vendor markets it as a general productivity tool. Three months later, the HR team is using it to draft performance improvement plans. The legal team is using it to summarise employment tribunal documents. Both use cases implicate Annex III categories. The tool-level classification missed both.

The remediation for this pattern is a use-case intake process that triggers a classification review every time a new application of an existing tool is identified, the kind of operational discipline that separates a working AI governance framework from one that exists only on paper.

2. Assuming Vendor Compliance Documentation Settles Your Classification

Vendors increasingly provide EU AI Act compliance statements, CE declarations, and risk tier certifications as part of their sales materials. These documents are relevant to the provider's obligations. They do not settle the deployer's classification decision.

A vendor's self-assessment that their tool is limited risk covers the tool as designed and marketed. It does not cover how your organisation deploys it, what data you feed into it, or what decisions you use it to inform. Your deployment context is your classification responsibility.

3. Missing the Profiling Trigger in Analytics and CRM Tools

The automatic high-risk classification for profiling systems (Article 3, EU AI Act) is not widely understood outside specialised legal teams. Enterprise analytics tools, CRM AI features, and customer data platforms that model individual behavior, even for entirely commercial purposes - can trigger the profiling definition and therefore high-risk classification, without anyone having flagged them as AI Act in scope at all.

4. Treating Historical AI Systems as Out of Scope

Article 111 of the EU AI Act addresses AI systems already on the market or in service before the relevant deadlines. For high-risk systems under Annex III, obligations apply even to systems deployed before August 2, 2026, unless they meet a narrow transitional exemption. The widespread belief that 'legacy AI' is exempt from the Act's requirements is incorrect. If a system is actively deployed and falls within Annex III, it requires classification and compliance action.

What Accurate Classification Unlocks

Classification is not the end of the compliance process. But it is the gate through which every other obligation must pass. Getting it right - at the use-case level, across all applicable frameworks, and continuously as tools and use cases evolve - is what separates an AI compliance programme that can actually demonstrate conformance from one that holds a list of tools with a risk column that nobody audited.

For High-Risk Systems: What Classification Triggers

Once a system is correctly classified as high-risk, a specific, documented compliance workflow begins. For deployers, that workflow includes:

• Fundamental Rights Impact Assessment (FRIA): required for deployers of all Annex III high-risk systems in the public sector, and recommended best practice for private sector deployers
• Human oversight mechanism documentation: Article 26 requires deployers to ensure trained operators can intervene, override, or switch off the system. This must be evidenced, not stated.
• Logging and monitoring configuration: high-risk AI system logs must be retained for a minimum of six months under Article 12; technical documentation must be maintained for ten years
• Registration in the EU AI Act database: deployers of high-risk systems in certain Annex III categories must register in the public EU database under Article 49
• Incident reporting: substantial modifications or serious incidents involving high-risk systems must be reported to national market surveillance authorities

None of these obligations can be triggered without accurate classification first. And none of them are lightweight. The organisations that have built the compliance infrastructure to satisfy these requirements are the ones that started classification work early - before the enforcement deadline forced it.

For Limited-Risk Systems: The Transparency Obligations

Limited-risk classification is not a free pass. AI systems that interact with users - chatbots, deepfake generators, emotion recognition systems, generative AI producing content that could be mistaken for human, must disclose their AI nature to users. For organisations using customer-facing AI extensively, limited-risk classification carries real operational requirements around disclosure design, user notification, and audit trails that demonstrate disclosures are working as intended.

For Minimal-Risk Systems: Document the Reasoning

Minimal-risk classification still requires documentation. Under Article 6(3), a provider that believes its Annex III system does not pose significant risk must document that assessment before placing the system on the market or putting it into service. For deployers, the same logic applies: a system that appears to touch an Annex III domain but has been assessed as not materially influencing decision-making requires a documented rationale that can be presented to a regulator if questioned.

Undocumented minimal-risk classifications are the most common audit finding in organisations that have done classification work. The classification exists; the evidence of the reasoning does not.

Building Classification Into the AI Governance Workflow

The organisations that are ahead on classification in 2026 are not the ones with the most sophisticated legal teams. They are the ones that have made classification a repeatable, operationalised process, and that operationalisation is what enterprise AI governance looks like when it moves from policy to practice.

Three structural changes distinguish their approach:

Classification at Point of Procurement, Not After Deployment

The most efficient place to classify an AI system is before it is deployed, when the use case is being defined, the vendor is available for questions, and the compliance documentation can be built into the procurement process rather than retrofitted. Organisations that trigger a classification review as part of every AI tool procurement decision have fundamentally different risk exposure than those that classify retrospectively.

This requires a short, mandatory intake process that captures: the intended use cases (not the vendor's marketing description), the data the tool will process, the decisions it will inform, the population it will affect, and the departments that will use it. That information is sufficient to determine regulatory scope and flag classification uncertainty for escalation.

Continuous Reclassification as Use Cases Evolve

Classification is not a property of a tool. It is a property of a tool as deployed, for a specific purpose, by a specific organisation. When any of those parameters change - the use case expands, the tool is integrated with new data sources, it is adopted by a new team for a different purpose, the classification may need to change too.

The Commission has authority to update Annex III over time, meaning classification is not a one-time exercise even if a tool and its use cases remain static. Governance programs that treat first-time classification as permanent are creating a compliance maintenance liability.

Classification Decisions as Auditable Evidence

Regulators under the EU AI Act explicitly consider documented compliance effort as a mitigating factor in penalty calculations. A classification decision that can be presented as evidence - with the reasoning documented, the use cases considered, the Annex III domains reviewed, the role determination made, the GDPR and NIS2/DORA scope assessed, and the outcome recorded with a named reviewer, is itself a compliance artifact.

The goal is not a risk column in a spreadsheet. It is a classification record for every AI system in the organisation's estate, maintained continuously, and available for regulatory review on demand, the AI risk management standard that enforcement will test first.

The Distinction That Changes Everything

Most AI governance conversations treat discovery and classification as a single step. Find the tools, document what you have, move on. The regulatory environment in 2026 does not support that simplification.

Discovery tells you what is running in your environment. Classification tells you what those systems are obligated to be - high-risk, limited-risk, minimal-risk, and across which frameworks. The two are connected but distinct, and the work between them - use-case analysis, role determination, cross-framework mapping, profiling trigger assessment, documentation - is where the majority of enterprise compliance programs currently have a gap.

The window to close that gap before enforcement intensifies is measured in months, not years. The enterprises building classification infrastructure now will navigate that enforcement environment from a position of documented, demonstrable compliance. Those that arrive at the deadline with a discovery list and unclassified systems will be building the infrastructure under regulatory scrutiny - a significantly harder and more expensive version of the same work.

Frequently Asked Questions

Can we use a vendor's EU AI Act compliance documentation as the basis for our own classification?

Vendor documentation is a starting input, not a final answer. A vendor's self-assessment covers the tool as designed and marketed, it does not cover your specific use case, the data you feed into it, or the decisions it informs. Your organisation remains responsible for assessing whether its deployment falls within Annex III, regardless of what the vendor's documentation states. If your use case brings the tool within a high-risk category the vendor's documentation does not address, the obligations apply to you regardless.

What triggers a reclassification of an AI system already in the approved register?

Four events should trigger immediate reclassification review: the use case expands beyond its original scope, the tool is adopted by a new team for a different purpose, the input data sources change materially, or the tool becomes integrated into a decision-making process it was not originally part of. The classification is not a property of the tool, it is a property of the tool as deployed for a specific purpose. When any of those parameters change, the classification may change with them.

What is the profiling trigger under the EU AI Act and why does it catch organisations off guard?

Profiling is not a standalone trigger for high-risk classification under the EU AI Act, but it features inside specific Annex III categories in ways that are not widely understood. A recruitment system profiling candidates, a credit system profiling borrowers, or an employment tool evaluating individual behaviour may fall within Annex III depending on the specific use case and the decisions the output influences. A marketing platform profiling customers for advertising purposes is not automatically high-risk. The risk is that enterprise analytics tools and CRM AI features are often assessed at the tool level rather than the use-case level, and the profiling dimension of their deployment is overlooked entirely.

How does cross-framework classification work in practice, do we need four separate assessment processes?

Not if the classification exercise is designed correctly from the start. Each discovered AI system should be mapped to a single regulatory profile that answers four questions simultaneously: does it process personal data (GDPR scope), does it fall under Annex III (EU AI Act obligations), does it sit within critical infrastructure or a regulated sector (NIS2), and does it serve financial services operations (DORA). Running four separate processes for the same system is the least efficient approach and typically produces four incomplete pictures rather than one accurate one.