EU AI Act: classify your use cases and plan the evidence

AI governance starts with knowing which systems the organization provides, deploys, or otherwise makes available. A list of model names is not enough: the intended purpose, deployment setting, and your role determine the obligations to examine.

For leadership, classification is a resource-allocation decision as well as a legal assessment. It determines which projects need specialist review, what suppliers must demonstrate, and what evidence must exist before release. A recruiting tool and an internal writing assistant can use the same model yet require very different assessments.

The useful output is a reviewed use-case register connected to owners, requirements, evidence, and change decisions—not a company-wide label saying “low-risk AI.”

Establish scope and responsibility before assigning risk

The EU AI Act is a regulation with obligations that depend on the activity, system, and operator. Its territorial scope includes providers placing systems on the EU market or putting them into service, deployers established or located in the EU, and certain non-EU providers and deployers where system outputs are used in the EU. Citizenship alone is not the test.

Have legal and technical reviewers establish whether the application meets the Act’s definition of an AI system and whether any relevant scope exclusions apply. Do not assume that every automation script is AI, or that an externally hosted service falls outside your responsibilities.

Then record your role:

• Provider: develops a system, or has it developed, and places it on the market or puts it into service under its own name or trademark.
• Deployer: uses a system under its authority in a professional context.
• Importer or distributor: brings relevant systems into the EU market or makes them available through the supply chain, with associated verification duties.
• Product manufacturer or authorized representative: has responsibilities arising from the particular product arrangement or written mandate.

An organization can occupy different roles across its portfolio. Buying an API does not settle the role of the finished application. Rebranding, substantial modification, or changing an intended purpose can trigger provider responsibilities under the applicable conditions. Fine-tuning is therefore a review trigger, not an automatic legal conclusion.

Distinguish the general-purpose AI model from the system built around it. Model-provider obligations and downstream system obligations are related but not interchangeable.

Build a use-case inventory that supports decisions

Inventory business functions, not just vendors. Interview procurement, HR, product, operations, and IT: AI may arrive through an existing supplier’s new feature rather than a dedicated purchase.

For each use case, capture:

Record actual workflows alongside intended purpose. A tool described as “recruiter assistance” may effectively exclude candidates if staff only inspect its shortlist. A written policy requiring human review does not prove that review occurs.

The deliverable is a versioned record per use case. Unresolved classifications should remain visibly unresolved, with an owner and a decision deadline, rather than defaulting to the least demanding category.

Assess prohibitions, high-risk routes, and transparency separately

The familiar four-tier description—prohibited, high-risk, transparency-related, and lower-risk—is a useful introduction. It is not a complete decision tree. Transparency duties can overlap with high-risk obligations, and AI literacy duties are not confined to high-risk systems.

Screen prohibited practices first

Article 5 prohibits specified practices, subject to the provision’s detailed conditions and exceptions. Relevant screening questions include whether a system uses harmful manipulation or exploits vulnerabilities, performs prohibited social scoring, creates facial-recognition databases through untargeted scraping, or carries out prohibited biometric categorization.

AI-based emotion inference from biometric data in workplaces and educational institutions is also prohibited except for specified medical or safety reasons. Text-only sentiment analysis does not fall within this prohibition merely because it assesses emotional tone. Certain law-enforcement biometric uses have tightly bounded rules; “all facial recognition is banned” is not an accurate substitute for assessment.

Escalate a possible prohibited practice before procurement or deployment. The evidence should describe the functionality and legal reasoning, not merely repeat a supplier’s “ethical AI” statement.

Test both routes to high-risk classification

The regulated-product route, Article 6(1): examine whether the AI is itself a product, or a safety component of a product, covered by the relevant Annex I legislation, and whether that product requires third-party conformity assessment. Both conditions matter. Use the amended legal text for the specific product regime; embedding AI does not alone establish high-risk status.

The Annex III route, Article 6(2): examine whether the intended function matches a listed use case. The eight areas are broad headings, not rules that make every application in an industry high-risk.

Read the detailed entries and exclusions. For example, financial-fraud detection is distinguished from the listed creditworthiness use, and verification of travel documents is excluded from the relevant migration identification entry. Administrative campaign organization is not equivalent to influencing voters.

Assess transparency even when high-risk rules do not apply

Article 50 addresses particular interactions and outputs. Depending on the role and circumstances, obligations concern informing people that they are interacting with AI, machine-readable marking of synthetic outputs, disclosures for deepfakes, and specified AI-generated public-interest text. Emotion-recognition and biometric-categorization uses also have disclosure provisions where permitted.

Do not reduce this to “label every AI-assisted document.” Determine which provision applies, who must act, and whether an exception is relevant. Keep notice wording, placement, output-marking arrangements, and test results as evidence.

Treat the Article 6(3) exception as a documented assessment

Some Annex III systems can fall outside high-risk classification under Article 6(3). This is not a general exemption for tools with a human somewhere in the process.

The assessment must address whether the system poses a significant risk of harm to health, safety, or fundamental rights, including whether it materially influences decision outcomes. The provision identifies circumstances involving narrow procedural tasks, improvement of previously completed human activity, detection of patterns or deviations under specified review conditions, and preparatory tasks. Reliance on the exception requires satisfying at least one of these conditions and establishing that the system does not pose the specified significant risk.

A provider relying on this exception must document the assessment before placing the system on the market or putting it into service, and address the applicable registration obligation. Crucially, an Annex III system performing profiling of natural persons remains high-risk; this does not mean every profiling system in every context automatically becomes high-risk.

Evidence should explain what information the system uses, how outputs affect reviewers, and whether the purportedly preparatory task determines who receives substantive consideration. Include workflow observations and representative outputs. A “human makes the final decision” sentence is inadequate if ranking, filtering, or recommendations effectively determine that decision.

Plan against the current application dates

As checked on 7 October 2026, the European Commission’s current AI Act overview and timeline identifies the following milestones:

Check the amended legal text and your specific transition provisions. Existing systems, model placement dates, changes, and particular operator arrangements may require additional analysis. Older guides may still show earlier high-risk dates.

Do not interpret the updated high-risk timetable as postponement of the entire Act. Budget separately for duties already applicable and preparation for the relevant high-risk regime. Your register should identify the applicable milestone and the source used to establish it.

Turn classification into an evidence plan

Provider and deployer responsibilities are different. Leadership should require a role-specific plan rather than assign every obligation to every team.

If you provide a high-risk system

The high-risk requirements and provider duties encompass risk management, data governance, technical documentation, record-keeping, information for deployers, human oversight, accuracy, robustness, cybersecurity, and quality management. Applicable conformity assessment, declaration, marking, registration, post-market monitoring, and incident processes also need planning.

Translate these into deliverables:

• A lifecycle risk assessment with mitigations, residual risks, and approval decisions.
• Data provenance, suitability, and quality records where relevant to the system.
• Technical documentation identifying purpose, design, dependencies, limitations, and evaluation methods.
• Test results tied to acceptance criteria and the deployment context.
• Oversight instructions explaining intervention, override, and escalation.
• Logging specifications, monitoring arrangements, and incident procedures.
• A conformity work plan identifying the applicable route and required records.

Not every high-risk system follows the same assessment route. Do not budget for a universal third-party audit or treat a security certification as proof of AI Act conformity.

If you deploy a high-risk system

Focus on operating the system according to instructions, assigning competent oversight, monitoring its use, and maintaining required records. Address input-data suitability where you control those inputs, and applicable worker-information or affected-person requirements.

Ask suppliers for relevant instructions, limitations, oversight requirements, and conformity information. Identify what they cannot provide and who will resolve the gap. A supplier assurance statement does not establish that your local configuration is appropriate.

Assess whether a fundamental-rights impact assessment is required for your deployer category and use case. It is not universal for all deployments. Where personal data is involved, assess GDPR requirements separately; a data protection impact assessment and an AI Act assessment serve different legal purposes, even when evidence overlaps.

For every deliverable, specify an owner, reviewer, due date, source location, and acceptance criterion. “Policy uploaded” is not equivalent to “control demonstrated.”

Worked example: one model, two business decisions

Illustrative assumptions: an EU employer uses a third-party language model for an internal writing assistant and a separate recruiting application. The recruiting application scores candidates against job criteria and presents a ranked shortlist. The employer uses both internally; its precise operator roles require review.

For the writing assistant, record permitted drafting tasks, data restrictions, output review, and any applicable transparency requirements. Ordinary internal drafting does not become high-risk merely because it uses AI. Expansion into employment evaluation would trigger reassessment.

For recruiting, Annex III’s employment entry is directly relevant. Review candidate scoring and profiling, not just the interface description. If recruiters consider only shortlisted applicants, the system materially shapes access to employment. Human approval of the final hire does not remove that influence.

The leadership decision is therefore different for each application. The writing assistant may proceed with proportionate controls after review. The recruiting project needs a high-risk readiness plan, supplier evidence, trained oversight, evaluation of local use, and a documented release decision.

If the team proposes changing the recruiting function to interview-calendar scheduling, assess that new purpose and workflow afresh. Scheduling may be a narrow procedural task, but retaining candidate scoring behind the scenes would undermine the revised rationale. Version the decision rather than overwrite the original record.

Make accountability visible in operating decisions

Assign a business owner who can explain the purpose and approve resources, a technical owner who can substantiate behavior, and a legal or compliance reviewer who can challenge classification. Executive approval should resolve funding, release restrictions, and unresolved risk—not replace specialist analysis.

As a practical recommendation, review classification when purpose, users, data, integrations, autonomy, or consequential decision influence changes. Connect that review to procurement renewals and product releases. A model update alone may not change classification, but it can invalidate evaluation evidence or operating assumptions.

Common mistakes include accepting vendor-wide classifications, assuming human review automatically creates an exemption, overlooking already-applicable literacy and transparency duties, and collecting documents without testing local operation. An ISO/IEC 42001 management system can support governance, but certification does not automatically establish AI Act compliance.

Secani can support the evidence workflow by connecting requirements, controls, source material, owners, tasks, and reviewed decisions. Start with one process, attach evidence to what it proves, and keep comments, approvals, and timestamps with material conclusions. Treat AI-assisted suggestions as drafts for human review, not legal determinations. Our AI-agent governance guide provides practical controls for permissions and review.

The next useful step is a focused classification workshop: select the most consequential live use cases, bring their business and technical owners, and produce reviewed records with unresolved questions and evidence tasks. That gives leadership a defensible basis for deciding what can proceed, what needs conditions, and what requires further assessment.