A chatbot added by a business unit, a fraud model bought from a supplier and an internal CV-screening tool can all create EU AI Act obligations. The practical question is not whether a tool is marketed as AI. It is which AI systems qualify as in scope, what role your organisation performs, and which evidence must be retained to defend the decision.
This distinction matters because an incomplete inventory is not a low-risk position. It is an untested assumption. Compliance teams need a repeatable method that identifies systems early, applies the legal tests consistently and records why a system has been classified as prohibited, high-risk, subject to transparency duties or subject only to baseline governance measures.
Which AI systems qualify under the EU AI Act?
The starting point is the EU AI Act definition of an AI system in Article 3(1). In plain terms, it covers a machine-based system designed to operate with varying levels of autonomy that may adapt after deployment and that infers, from inputs, how to generate outputs such as predictions, content, recommendations or decisions that can influence physical or virtual environments.
That is broader than a traditional machine learning model. It can capture generative AI assistants, predictive scoring engines, recommendation tools, biometric systems, decision-support applications and software that combines rules with inferential techniques. A product label is not determinative. Calling a system analytics, automation or intelligent workflow software does not remove it from scope if its actual functionality meets the definition.
The Act applies where a provider places an AI system or general-purpose AI model on the EU market, or puts it into service in the Union. It also reaches deployers established or located in the EU. Organisations outside the EU can be caught where the output of their AI system is used in the Union. For UK organisations, this means an EU customer, EU-based workforce, EU applicants or EU-facing service can be sufficient to trigger a serious scope assessment.
There are limited exclusions, including AI systems used exclusively for military, defence or national security purposes, systems used solely for scientific research and development, and certain personal non-professional uses. These exclusions should be applied narrowly and documented. A system may begin as a research project yet move into an operational environment, at which point its status changes.
In scope does not automatically mean high-risk
One of the most costly mistakes is treating the EU AI Act as a binary test. A system is either in scope or it is not. That is only the first decision. Once in scope, the system must be assigned to the appropriate regulatory category and obligations.
Some practices are prohibited under Article 5. These include certain harmful manipulative or exploitative practices, social scoring in specified contexts, particular forms of biometric categorisation and emotion recognition in workplaces or educational institutions, subject to defined exceptions. A prohibited-use review should happen before deployment, procurement renewal or material repurposing. It is not a control that can be fixed through better documentation after the fact.
High-risk AI systems are subject to the most extensive obligations. There are two principal routes into this category. Under Article 6(1), a system may be high-risk where it is a safety component of a product, or is itself a product, covered by specified EU product safety legislation and subject to third-party conformity assessment. Under Article 6(2), systems used in the Annex III areas may be high-risk.
Annex III covers use cases including biometrics, critical infrastructure, education and vocational training, employment and worker management, access to essential private and public services, law enforcement, migration and border management, and the administration of justice and democratic processes. A recruitment screening system, creditworthiness model or benefits eligibility tool is therefore not merely another entry in an IT register. It requires a specific legal assessment of its intended purpose and impact.
There is a qualification within Annex III. A system that does not pose a significant risk of harm to the health, safety or fundamental rights of natural persons may fall outside the high-risk category, for example where it performs a narrow procedural task or does not materially influence a decision. This is not an exemption to assume. The provider must assess and document the basis for that conclusion. If the system profiles natural persons, the exemption does not apply.
General-purpose AI needs a separate assessment
General-purpose AI models and systems built on them require their own governance path. A provider of a general-purpose AI model has obligations relating to technical documentation, downstream information, copyright policy and training-content transparency. Models presenting systemic risk have additional duties, including model evaluation, adversarial testing, serious incident reporting and cybersecurity protections.
For most organisations, the immediate issue is not that they develop a foundation model. It is that they procure one and build an internal or customer-facing application around it. The underlying model supplier’s obligations do not remove the deployer’s responsibility to assess the resulting system’s intended purpose, data flows, human oversight and use-case risk.
A general-purpose model used to draft internal meeting notes will not be assessed in the same way as one used to rank job candidates or assist clinical triage. The model may be the same. The deployment is not.
A defensible qualification workflow
A practical assessment should begin with the system, not a policy statement. Record the product name, supplier, business owner, technical owner, intended purpose, users, affected individuals, inputs, outputs, deployment locations and whether outputs influence decisions. This creates the minimum factual record required for classification.
Next, establish your organisation’s role. You may be a provider if you develop an AI system or have it developed and place it on the market or put it into service under your name. You may be a deployer when using a system under your authority. The same organisation can be both, particularly where it customises a third-party model into an internal decision tool or customer product.
Then apply the scope and risk tests in sequence: confirm whether the tool meets the Article 3 definition; assess territorial connection and exclusions; screen for prohibited practices; test Article 6 and Annex III high-risk conditions; and determine whether transparency obligations apply. Article 50 can require users to be informed when they interact with certain AI systems and can impose labelling or disclosure requirements for AI-generated or manipulated content.
The assessment should be revisited when the intended purpose changes. Connecting a chatbot to HR records, giving it authority to initiate transactions, expanding its audience to the EU or using its output in a decision process are material changes. A one-time spreadsheet review cannot provide reliable control over that lifecycle.
Evidence is part of the compliance decision
A classification without evidence is difficult to defend to an auditor, regulator or board. Retain the system description, supplier documentation, assessment date, legal rationale, decision-maker, risk controls and review trigger. Where a system is high-risk, the evidence set expands significantly to include risk management, data governance, technical documentation, logging, human oversight, accuracy, robustness and cybersecurity measures.
The governance challenge is operational: keeping that evidence current across procurement, legal, security, data protection and business teams. A central register with assigned ownership, approval workflows and mapped controls is more reliable than chasing versions of a spreadsheet during an audit. Endaxi AIG is designed for this exact progression from inventory entry to classification, assessment, control evidence and regulatory reporting.
The EU AI Act does not reward organisations for having the longest AI policy. It rewards, and regulators will scrutinise, decisions that can be traced from a real system and real use case to a clear legal classification and an accountable owner. Start with the systems already operating quietly across the business. They are usually where the governance gap is widest.