Does the Annex III use-case route make our AI system high-risk?
A system is high-risk by the use-case route when its intended purpose falls within one of the eight Annex III areas, as Article 6(2) provides. The test is what the system is designed and marketed to do, not how sophisticated its model is or whether it is a small tool. Start by listing every AI system in production or in planning, then write down the intended purpose of each in the provider's own words and check that purpose against the Annex III points on biometrics, critical infrastructure, education, employment and workers' management, essential private and public services, law enforcement, migration and border control, and justice and democratic processes. Note that Annex III point 1 carves out biometric verification whose sole purpose is confirming that a person is who they claim to be, and that Annex III point 5 excludes financial fraud detection from the credit scoring use case.
The date matters for planning. As amended by Regulation (EU) 2026/1744, the high-risk rules in Chapter III Sections 1 to 3 apply to Annex III systems from 2 December 2027, not 2 August 2026. That gives organizations a defined window to build the risk management system, data governance, technical documentation, logging, human oversight and quality management that a high-risk system must carry before it reaches the EU market or is put into service. Systems that are already on the market may be subject to transitional rules, so confirm with counsel how the Act treats each system's placing on the market date. Do not wait for the final months of the window: the design changes that high-risk status requires, such as logging and oversight, are expensive to retrofit into systems already in production.
The classification decision itself is difficult to evidence. Article 6(3) lets a provider conclude that an Annex III system is not high-risk when it poses no significant risk, but that conclusion must be documented before the system is placed on the market, and a market surveillance authority can challenge it. Practical evidence includes a dated intended-purpose statement, a record of each Annex III point considered, the reasoning for any exclusion, and a log of changes when the system or its use shifts. Commission guidelines on high-risk classification were published in draft on 19 May 2026 and still carried a draft label at the 23 July 2026 update, so confirm the current status before relying on any example. Your AI system inventory is the natural place to hold these records, and an implementation partner can prepare the inventory and classification files, but the classification judgment and any Article 6(3) claim remain the organization's decision, open to review by its authorities.
Which AI systems and teams fall inside the Annex III areas
Annex III lists eight areas, but the area name alone does not settle the outcome. Each card names the scoping decision that changes the work in that area, along with the exclusion or carve-out that most often matters. Intended purpose decides the classification, and the underlying model does not.
Biometric systems
Annex III point 1 excludes biometric verification whose sole purpose is to confirm that a person is who they claim to be, such as a device unlock or a one-to-one login check. Identification, where the system works out who a person is from a group, stays in scope. Record the purpose statement for each biometric deployment, because a system that also searches a database for matches can lose the exclusion.
Critical infrastructure
Annex III point 2 covers AI used as a safety component in critical infrastructure, road traffic, and the supply of water, gas, heating and electricity. The scoping question is the component's role. A system that only reports on a grid asset differs in risk from one that controls switching or flow, and the second is where the classification usually lands. Confirm with the operator which assets fall under the national definitions that apply to you.
Education and training
Annex III point 3 covers AI that decides admission or assignment to educational institutions, evaluates learning outcomes that steer the learning process, assesses the appropriate level of education, or monitors prohibited behavior during tests. A study assistant that suggests material sits outside this area. A grading or admissions model inside it does. Ask whether the output changes a learner's path or result.
Employment and workers
Annex III point 4 covers AI used to recruit or select people, including targeted job adverts and the filtering of applications, and AI used for decisions on promotion, termination, task allocation and workforce monitoring of performance and behavior. Productivity dashboards and shift schedulers can fall inside the area when their output feeds those decisions. Map every HR and workforce tool to the decision it supports, not only to the vendor's product category.
Essential services
Annex III point 5 covers AI that evaluates creditworthiness or sets credit scores, excluding financial fraud detection, assesses risk and prices life and health insurance, decides eligibility for public benefits, and triages emergency calls. A fraud model that is reused to set credit limits moves into scope for that second purpose. Check whether the output decides or materially shapes a person's access, price or priority.
Law enforcement, migration and justice
The remaining Annex III areas cover law enforcement, migration, asylum and border control, and justice and democratic processes. These areas usually involve public authorities and the suppliers that build tools for them. The key question is who operates the system and which decision it informs. An illustrative case: a vendor tool used by a border agency to prioritize case files keeps its classification in that agency's hands, whoever built it.
How an assessor tests the high-risk classification
This table sets out what an assessor checks for each part of the classification decision, the evidence they will ask to see, and the findings that most often appear. Read it as a checklist of records to have ready before an examination, since a classification that cannot be traced to documents usually fails regardless of how sound the reasoning was.
| Test area | Evidence requested | Common findings |
|---|---|---|
| Intended-purpose documentation | Written intended purpose for each AI system, including the decision it supports, the users, the affected people and the deployment context | Intended purposes exist only in sales material or engineering tickets, or are described too broadly to map to any Annex III point |
| Mapping to Annex III points | A record showing which of the eight Annex III areas and which numbered point applies to each system, with the reasoning | Systems marked as not high-risk without naming a point, or matched to a point by product category instead of use |
| Testing of exclusions | Evidence that any exclusion relied on applies to the actual use, such as the biometric verification carve-out in point 1 or the fraud detection carve-out in point 5 | Verification or scoring features bundled into a wider product, where the exclusion covers only one function |
| Review of Article 6(3) claims | A documented assessment of why the system poses no significant risk, the conditions relied on, the profiling check and the registration record | Exemption claimed for a system that performs profiling, or assessment dated after the system was already in use |
| Inventory matches production | Current AI system inventory compared with production configurations, deployment records and change tickets | Systems in production that are absent from the inventory, or model or feature changes that were never reclassified |
| Records of reclassification | Change log showing each reclassification with date, reason, approver and the version of the classification it replaced | Systems reclassified after a change in scope or use without a record of the decision or its approval |
| Use of Commission guidance | Notes showing which guidance was consulted and how it was applied, noting that the draft guidelines on high-risk classification published on 19 May 2026 were still labeled draft at the Commission's 23 July 2026 update | Organizations treating the draft guidelines as final, or ignoring them without recording why |
| Independent review of the decision | Sign-off by a named accountable owner and evidence of a second review of borderline cases | Classification decided by a single engineer or vendor questionnaire, with no owner accountable for the result |
How to classify an AI system against Annex III
This sequence takes an AI system from a loose idea of what it does to a documented, reviewable decision on whether Article 6(2) and Annex III make it high-risk, and whether Article 6(3) might exempt it. Each step ends with a record that an assessor or market surveillance authority could follow.
Build the AI system inventory
List every AI system the organization develops, buys, integrates or runs, including systems embedded in vendor software and tools staff adopt on their own. The owner for each entry is the business unit that uses the system, with the technical owner named alongside. The step is complete when the inventory has one row per system and no known system is missing from it. Asset registers such as GLPI or endpoint inventories from Wazuh can help locate software, but they will not identify AI use on their own, so confirm coverage with business owners.
Record intended purpose and actual use
For each system, write the purpose the provider declared and the way the organization actually uses it, including any change in input data, population or decision role. Where these differ, record both and treat the actual use as the one to test. The provider's instructions for use, contract terms and internal change requests are the sources to check. The output is a classification record with the intended purpose, actual use, affected people and the decision the output feeds into.
Test each use against Annex III wording
Read the record against the eight Annex III areas and the specific points within them, such as recruitment and worker monitoring under the employment area, or creditworthiness and insurance pricing under essential services. Apply the exact wording of each point, not a loose sense of the topic, and note any point that is clearly not engaged. The Commission's draft guidelines on high-risk classification, published on 19 May 2026 and still labeled draft, give practical examples to compare against. The output is a matched or unmatched finding for each candidate point, with the reasoning written out.
Document the classification decision
Turn the test results into a signed decision memo that states the classification outcome, the Annex III point relied on, the evidence reviewed and the named approver, usually the accountable executive or the compliance lead with legal input. A system that matches no point is recorded as not Annex III high-risk, with the reasons, so the absence of a finding is also evidenced. The memo is complete when every inventory entry has a dated classification and approver.
Apply the Article 6(3) check where it might exempt
For any system that matches an Annex III point, assess whether it performs only a narrow procedural task, improves a previously completed human activity, detects deviations from prior decision patterns without replacing human assessment, or performs a preparatory task. Confirm that none of these conditions is undermined by profiling of natural persons, which removes the exemption. If the exemption is relied on, record the documented assessment and the registration duty that the Act attaches to it. The output is a separate exemption assessment, or a note that the exemption does not apply.
Set review triggers for changes in use
Define the events that reopen a classification, such as a new use case, a new population of affected people, a change in the decision the output feeds, a vendor model update, or a substantial modification. Assign an owner to watch each trigger and link the triggers to change management tickets. The Commission can amend the Annex III list by delegated act under Article 7, so also assign someone to track changes to the list and to the application dates set by Regulation (EU) 2026/1744. The output is a review schedule attached to each classification record.
How the Commission can add or remove Annex III use cases
The Annex III list is not fixed. Under Article 7, the Commission can add or modify use cases within the existing eight areas, and it can remove them, by adopting delegated acts. Before using that power, the Commission weighs criteria the Act names, including the scale of use of the system, the degree of autonomy the system has, how reversible its outcomes are, and how vulnerable the affected persons are. For an organization, the practical consequence is that a system classified as out of scope today can move into scope through a later amendment without any change to its own design. A classification made once and filed away is therefore a weak control.
Treat the classification as a living record. Keep each AI system's Annex III mapping, the date it was made, the person who approved it, and the Article 7 criteria that could change its status, such as a rise in the number of people affected or a shift toward more autonomous decisions. Assign an owner to watch for delegated acts and for updates to the Commission's guidelines on high-risk classification, which were still in draft at the time of the last update supplied for this page. Confirm the current status of any draft or adopted act directly on the Commission's pages and EUR-Lex before relying on it, because a classification that was correct at launch may need review at each amendment.
Plan the review cadence around the dates that already apply. Under the 2026 amendments, the high-risk rules for Annex III systems apply from 2 December 2027, so a system that is added to the list by a delegated act close to that date may leave little time for the obligations to be met. Ask your legal or compliance function to set a trigger for reassessment whenever a delegated act is published, and record the outcome in the same register. The aim is that a change to the list leads to a documented decision within a defined period, not a scramble to find out which systems it touches.
Evidence that shows a classification holds up
A high-risk classification is only as strong as the records behind it. The artifacts below show how a system was classified, why, and who approved that decision, and each one needs a review trigger so it stays accurate after launch.
System inventory entries
The inventory is the register of every AI system the organization builds, buys or operates, with its owner, provider or deployer role, deployment location and the Annex III area it touches. Auditors start here to test whether any system was left out of the classification exercise. Check that entries are added when procurement approves a new AI feature, not only when a project is formally launched. Owners should confirm the entry each quarter and after any change to the system's users or data sources.
Intended-purpose statements
An intended-purpose statement records what the provider designed the system to do, for which users and in which context. Under Article 6(2), the Annex III area is read against that purpose, so a statement that says "CV screening" and a statement that says "shortlist support with human decision" can lead to different outcomes. Check that the wording matches what the product actually does in production, and that marketing and sales material does not claim a broader or narrower purpose.
Annex III mapping memos
A mapping memo links each system to a specific Annex III point, such as point 4 for recruitment or point 5 for credit scoring, and explains why the match holds or does not. It should name the criteria used, the data reviewed and the people consulted. Refresh the memo whenever the use case, population affected or decision weight changes, and check it against the Commission's draft guidelines on high-risk classification as they are finalized.
Article 6(3) assessments where relied on
Where the organization concludes that an Annex III system is not high-risk because it poses no significant risk, the documented assessment is the only proof of that position. It must address the four conditions in the Article and the profiling override, and it must be kept ready for a market surveillance authority that challenges the conclusion. Confirm that the assessment is dated, signed and re-run when the system's purpose or data changes, because an exemption that no longer holds is a misclassification.
Change logs for classification drivers
A change log records every modification that could move a system into or out of Annex III, including new features, new user groups, retraining on different data or expansion to a new country. The Act's substantial modification concept makes these changes material for providers, so each entry should state whether it was assessed and what was decided. Review the log at each release and before any new deployment, and link each entry to the updated mapping memo.
Sign-off and review records
Sign-off records show who approved each classification, with the role, date and version of the decision they approved. Legal, compliance, product and the business owner should each have a defined part in the approval, and the record should show any open objections. Set a review cycle and a trigger list, such as a new Annex III amendment under Article 7 or a change in the Commission's guidance, so that sign-offs are revisited rather than left in place from launch day.
What classifying AI systems costs in money and effort
Most of the classification effort falls on internal staff. Legal, compliance and risk teams must read each Annex III area, decide whether a system's intended purpose fits, and record the reasoning. This work is paid through salaries and time, not invoices, so it often goes unbudgeted. It is largely one-time for each system, then recurs whenever the system's purpose, user population or data changes, and whenever the Commission's guidelines or delegated acts change the list.
- Intended purpose review: Staff must read the provider's stated intended purpose and compare it with the actual use in the organization, which are not always the same.
- Decision records: Each classification decision needs a written rationale that an assessor or market surveillance authority can follow.
- Recurring reviews: Re-classification is needed after material changes, such as new features, new hiring criteria or new eligibility rules.
- Scope of the inventory: The number of systems to review is the largest driver of internal time.
- Training time: Reviewers need enough working knowledge of Annex III to make consistent calls.
Ask your team to estimate hours per system and per review cycle before you agree on a budget, and confirm the reviewers who can sign off on decisions.
Classification depends on knowing what AI systems exist and how they behave in production. Engineering teams build the inventory, identify where models and AI features are embedded, and collect the logs that show purpose and usage. This cost is front-loaded in the first inventory and then recurs as systems change. Open-source asset and telemetry tools can reduce manual discovery, but they still need configuration, tagging and maintenance by people.
- Discovery work: Engineers must find AI components in applications, cloud services and endpoints, including features that teams enabled without central approval.
- Telemetry setup: Traces of inputs, outputs and tool use help show what a system actually does, which supports classification.
- Integration: Connecting asset data to a governance register requires custom fields, owners and update rules.
- Ongoing maintenance: Inventories go stale quickly when teams add features, so someone must own updates.
- Data protection constraints: Logging personal data for classification evidence adds design work and may trigger other obligations.
Ask the implementation partner which systems will be instrumented, what data each source will collect, and who maintains the register after handover.
Some organizations engage outside counsel or consultants to review borderline classifications, especially where the Article 6(3) exemption may apply or where a system touches several Annex III areas. An external review adds a second opinion and can document due diligence. It does not transfer legal responsibility from the organization, and it does not replace an independent assessment where one is required. External fees are usually one-time for the initial review and recur when the organization asks for re-assessment after changes.
- Scope of the review: A review of a few clearly classified systems costs far less than a review of a large catalog with many grey areas.
- Depth of analysis: Written opinions on exemption cases take more time than confirmation of a clear high-risk case.
- Jurisdiction questions: Multi-country organizations may need local counsel to confirm national enforcement details.
- Re-review triggers: Ask whether the fee covers future updates when guidelines or delegated acts change the list.
- Deliverables: Decide whether you need a memo per system, a summary table or a board paper.
Request a written scope, the number of systems covered, the named reviewers and the deliverable format before you accept a quote.
Tooling covers the software that holds the inventory, collects evidence and tracks decisions. Open-source options can lower license costs, but they carry hosting, integration and support costs. Most of the spend is setup, which is one-time, followed by hosting and maintenance, which recur. Tool costs vary with the environment: a single-node deployment has very different needs from a high-availability setup or an air-gapped network. Where a supplied capability exists, it is named below. Confirm any other capability with the project before you rely on it.
- Asset inventory: GLPI's Assets module can record computers, software and network equipment, which helps locate the infrastructure that runs AI systems.
- Endpoint inventory: Wazuh's Syscollector module collects installed software, services and running processes from endpoints, which can reveal AI tools in use.
- LLM observability: Langfuse traces capture LLM calls, retrieval steps, tool executions and token usage, which can show how a generative system is used.
- Hosting and backups: Self-hosted tools need compute, storage, backup and patching, which recur every year.
- Licensing and support: Open-source licenses are free to use, but support contracts and upgrades are separate costs.
Ask for a list of every tool in scope, its hosting model, who patches it, and the recurring cost of running it.
Self-hosted tools that produce classification evidence
This table maps four self-hosted open-source tools to the evidence they can help produce for an Article 6(2) classification file. Read each row as a record source: the tool captures facts about systems, use and testing, while the classification decision still rests on the Annex III analysis and the organization's own judgment.
| Tool and license | Evidence it helps produce | What it does not decide |
|---|---|---|
| GLPI Assets (GPL-3.0-or-later) | Inventory of the computers, servers and software where AI systems run, entered manually or pushed by the GLPI Agent, supporting a list of systems in scope for review | Whether a system falls under an Annex III area, its intended purpose, or whether it is high-risk |
| Wazuh Syscollector (GPL-2.0-only) | Endpoint records of installed software, running processes, services and users, showing where AI tooling is present on managed hosts | Whether software found on an endpoint is an AI system, or whether its use case is an Annex III use case |
| Langfuse traces (MIT) | Timed records of LLM calls, retrieval steps, tool executions, inputs, outputs and metadata, showing how an AI system is used at runtime for a given purpose | Whether the observed use is a high-risk use, or whether Article 6(3) conditions are met |
| garak reports (Apache-2.0) | JSONL logs of every probe attempt and evaluation, plus a hit log of vulnerabilities found, supporting test records for a language model component | Whether the model or system is high-risk, or whether test results are sufficient for conformity assessment |
| Retention and access (all four) | Exports and timestamps that show records existed at a given date, which helps show the classification file was kept current | Who is accountable for the classification, which remains with the provider or deployer and its governance process |
| Verification (all four) | Confirm version, configuration and export settings against each project's current documentation before relying on any report as evidence | The auditor or market surveillance authority's view of the evidence, which an independent reviewer decides |
Who owns classification, who prepares evidence, and who assesses it
The organization that places an AI system on the market or puts it into service remains responsible for deciding whether that system falls under an Annex III area. That decision depends on the system's intended purpose, meaning the use the provider specifies, and on how the system is actually deployed. The organization must also decide whether an Article 6(3) exemption applies, and it must document the reasoning so that a market surveillance authority can follow it later.
- Intended purpose: Record the purpose the provider has declared, the people affected and the decisions the system informs or makes.
- Annex III mapping: Match the use to the relevant point of the eight areas, such as employment under point 4 or creditworthiness under point 5.
- Exclusions: Check carve-outs, for example biometric verification whose sole purpose is identity confirmation under point 1.
- Documented reasoning: Keep a dated classification memo, signed by an accountable owner, for every system in the inventory.
- Change control: Reassess when the purpose, the user population or the decision logic changes.
Before relying on any outside advice, confirm with your own legal and product owners that the classification record names who signed it and when it was last reviewed.
An implementation partner such as DeployOpen can build the technical tooling that supports classification and prepare the records the organization uses to reach its decision. It does not decide the classification, set the intended purpose on the organization's behalf, or confirm to a regulator that a system is or is not high-risk. Work is usually fixed in scope and agreed in writing before it starts.
- Inventory tooling: Set up self-hosted asset and software inventory so that AI systems, their hosts and their dependencies are listed in one place.
- Telemetry for evidence: Configure logging and tracing so the organization can show how a system is used in practice, not only how it was described.
- Record preparation: Draft templates for intended purpose statements, Annex III mapping worksheets and decision logs for the owner to review.
- Systems and access: Harden the hosting environment and keep the evidence store tamper-evident and retained for the required period.
- Handover: Document where each record lives and who maintains it after the engagement ends.
DeployOpen does not issue audit reports, attestations or certifications. Ask any partner to state in writing which records it prepares and which decisions remain with your staff.
Independent parties test classification decisions. Market surveillance authorities enforce the Act for AI systems in their member state and can challenge a classification that appears wrong. Independent auditors and certification bodies may test controls in management system standards that organizations use alongside the Act. Neither type of party issues a certificate that a system is or is not high-risk, and neither should be asked for one.
- Market surveillance: National authorities can request documentation, examine the reasoning and reclassify a system if the evidence does not support the organization's decision.
- Auditor testing: An external auditor reviews the classification method, the inventory completeness and the sample of decisions for consistency.
- Conformity assessment: Most Annex III systems use internal control under Annex VI, so the organization performs the assessment itself. Notified bodies are involved only for some biometric systems and Annex I products under Article 43.
- Scope of opinion: Ask any assessor to state the criteria used and the limits of its opinion in writing.
Confirm with the relevant authority in your member state which body supervises your systems, and ask the auditor whether its engagement covers classification or only the surrounding controls.
Where classification efforts usually fall short
Most misclassification under Article 6(2) and Annex III comes from a handful of habits: judging the tool instead of the use, missing AI that teams adopt on their own, and letting records fall behind the system. Each card names one gap, why it matters for the high-risk route, and the check that closes it.
Classifying by model, not purpose
Teams often ask whether a model is high-risk, but Annex III attaches to the intended purpose of the AI system. The same language model can sit outside Annex III when it drafts marketing copy and inside it when it ranks job applicants. For each system, record the intended purpose as the provider states it, the people affected and the decision the output feeds. Check that the purpose statement names the Annex III use, not the underlying model.
Missing shadow AI in HR and lending
Recruiters, credit analysts and team leads often adopt AI features inside existing SaaS tools, browser extensions or spreadsheets without a procurement record. These uses can fall into the employment or creditworthiness areas of Annex III without anyone reviewing them. Ask each HR, lending and operations lead to list every tool that scores, ranks, filters or recommends, including features switched on by a vendor update. Treat an unlisted tool as unclassified until someone assesses it.
Relying on Article 6(3) without records
Article 6(3) lets a provider conclude that an Annex III system does not pose a significant risk, but the conclusion must be documented before the system is placed on the market, and the profiling exception still makes it high-risk. Many teams cite the exemption in a single sentence in a project ticket. Keep a written assessment that states the conditions met, the reasoning, the reviewer and the date, and confirm with counsel which registration duties apply. Do not treat the exemption as a default.
Stale records after feature changes
A system classified last year may have gained a new decision step, a new population or a new data source. Any of these can move it into an Annex III area or change the scope of its purpose. Put a trigger in change management so that changes to inputs, outputs, affected groups or decision authority force a classification review. Confirm the review date and version history for each record. Check the classification date against the most recent release.
Inventories that omit third-party AI
Asset inventories built for IT often list servers and licensed software but not the AI capabilities inside vendor products or APIs that the organization calls. Yet the deployer, not only the provider, carries obligations for high-risk use. Extend the inventory to record the provider, the model or service used, the intended purpose and whether the organization changed that purpose. Tools such as GLPI or Wazuh can supply software and endpoint data, but they will not reveal AI features by themselves. Confirm each external AI service has an owner and a classification entry.
Questions buyers ask about Annex III classification
Is a chatbot used in HR automatically high-risk under the AI Act?
A chatbot is high-risk under Annex III only when its use falls within a listed area. Annex III point 4 covers AI used to recruit or select people, including filtering applications and targeted job adverts, and AI used for decisions on promotion, termination, task allocation and monitoring of worker performance or behavior. An HR chatbot that answers leave policy questions usually sits outside that list, although it may still carry transparency duties. A chatbot that screens candidates, ranks applicants or scores employee behavior falls inside it. The deciding factors are the chatbot's intended purpose, what its outputs feed into, and whether a human reviews them. Document that reasoning for each system, because the classification rests on it.
How long does Annex III classification take, and what does it need from our team?
The duration depends on how many AI systems you run, how well each is documented and how many owners must be interviewed. No fixed timeline applies to every organization, so ask any partner or consultant for a timeline written into the scope. The work needs an inventory of AI systems that records each system's intended purpose, data sources, outputs, user groups and the decisions it influences. It also needs a product owner who knows the system, a technical owner who can confirm how it behaves, and a legal or HR reviewer who can read Annex III against the actual use. Classification goes faster when the inventory already exists and the intended purpose is written down.
Can we classify our AI systems in-house without outside help?
Yes. The organization owns the classification decision, so an internal team can carry it out if it has the legal reading and the technical knowledge. The main risk is interpretation. The Commission published draft guidelines on high-risk classification with practical examples on 19 May 2026, and its page still labeled them draft at the 23 July 2026 update, so track the final version before you rely on any reading. Internal teams often struggle to prove how a system behaves in production, to capture the evidence that shows its outputs, and to keep the classification current as systems change. Those gaps are where outside help is most often useful.
What does an implementation partner add to Annex III classification work?
An implementation partner prepares the systems and evidence that support your classification. DeployOpen, for example, plans, implements and documents self-hosted open-source platforms inside your own infrastructure, and it can set up the logging and inventory that make classification defensible. Langfuse traces can show which inputs and outputs an LLM-based tool produced, GLPI's Assets module can record the hardware and software hosting each system, and Wazuh's Syscollector can record the software and services on each endpoint. The partner does not decide whether a system is high-risk and does not issue reports or certificates. Independent auditors and assessors do that. Agree that division of roles in writing before work starts.
When do the high-risk obligations for Annex III systems apply?
For Annex III systems, the high-risk rules in Chapter III Sections 1 to 3 apply from 2 December 2027. Regulation (EU) 2026/1744 moved this date from 2 August 2026, and the same amendment moved the date for Annex I product systems to 2 August 2028 from 2 August 2027. Chapters I and II have applied since 2 February 2025. Classification still matters now, because you need to know which systems will carry obligations before the date arrives. Build the inventory and classification record before 2 December 2027 so that design, documentation and conformity work can start with a clear list of systems. Confirm the current text in the consolidated EUR-Lex version before you set internal deadlines.
What will an assessor ask for when checking an Annex III classification?
An assessor will ask for a written classification record for each system that shows the Annex III area relied on, the intended purpose, and the reasoning behind the conclusion. If you claim the Article 6(3) exemption, expect requests for the documented assessment that supports it. Assessors also look for evidence of how the system behaves, such as logs, test results, data descriptions and records of human oversight. For most Annex III systems, conformity assessment uses internal control under Annex VI. Notified bodies are involved for some biometric systems and Annex I products under Article 43. The assessor is independent of the implementation partner, so the evidence must be understandable to someone who did not build the system.
Does the biometric exclusion in Annex III point 1 cover identity checks?
Annex III point 1 excludes biometric verification whose sole purpose is to confirm that a person is who they claim to be. A system that only performs that one-to-one check falls outside the biometric area on that basis. A system that identifies people, categorizes them or performs any other function alongside verification does not get the same treatment, so each function needs its own analysis. Document the system's sole purpose in writing and check that the system cannot be used for other purposes in practice. Because the exclusion depends on exact wording and intended use, have counsel confirm the boundary for each deployment before you rely on it.
What fines apply if we misclassify an Annex III system?
Misclassification is not itself listed as a fine category, but a system that should have met high-risk obligations and did not can breach them. Under Article 99, the maximum fine for most operator obligations is EUR 15 million or 3% of worldwide annual turnover, whichever is higher. Misleading information given to authorities carries a maximum of EUR 7.5 million or 1% of worldwide annual turnover, whichever is higher. Market surveillance authorities enforce the Act for AI systems, so a misclassification may come to light through an inquiry. Keep a dated classification record for every system so you can show the reasoning at the time of the decision, not just today.
How DeployOpen prepares inventory and evidence for classification
DeployOpen's part in Annex III classification is preparation, not decision. Before any work starts, the scope is written down: which business units, which AI systems and which intended purposes are in the review, who on the client side owns each use case, and which records the client expects at the end. Engagements of this kind are fixed-scope, so the deliverables and timeline are agreed in writing before work begins. The legal classification of each system stays with the organization, supported by its counsel and compliance team.
The technical groundwork is an inventory the client can keep. DeployOpen deploys self-hosted tooling inside the client's own cloud accounts, data centers or air-gapped networks. GLPI's Assets module can record the applications, servers and network equipment that host AI components, and its native inventory, pushed by the GLPI Agent, reduces manual entry. Wazuh's Syscollector module can collect installed software, services and running processes from endpoints into the Wazuh indexer for reports. Where a system is a language-model application, Langfuse traces capture inputs, outputs, tool calls and retrieval steps, which help show what the system does in use. Confirm with your own engineers which of these sources cover each AI system before relying on them.
The output is a set of records that the organization can review: a use-case register, the purpose and affected groups for each system, the Annex III area each case was screened against, and the supporting logs. Ask for a written list of artifacts, their owners and their storage location in the quote. Keep in mind that the Commission's draft guidelines on high-risk classification, published on 19 May 2026 and still labeled draft at the 23 July 2026 update, are the reference to check screening decisions against. Because the classification guidance and the Digital Omnibus dates may change, DeployOpen offers retainers for ongoing review of new use cases and updated records, which the client can scope separately from the initial engagement.
