A procurement team can call a tool “decision support”, a product team can call it “automation”, and a supplier can call it “AI-enabled”. None of those labels determines the legal position. The question is whether the system meets the EU AI Act definition of an AI system, how it is used, where its output has effect, and which organisation is responsible for placing it on the market or operating it. That is when do AI rules apply in practice: not at the point of marketing language, but at the point of function, role and risk.
For compliance teams, the immediate task is to replace informal judgement with a documented decision trail. A defensible AI inventory should show what each system does, who owns it, the legal role of the organisation, its risk classification, the applicable obligations and the evidence supporting that conclusion.
When do AI rules apply to an organisation?
The EU AI Act applies where an AI system is placed on the EU market, put into service in the EU, or where its output is used in the EU. Its reach is deliberately wider than the location of a company’s headquarters or cloud environment.
A UK organisation can therefore be in scope even if it has no EU establishment. If it provides an AI system to customers in the EU, deploys a system whose output affects individuals in the EU, or acts as an importer or distributor for an EU-facing system, the Act may apply. The same logic matters to international suppliers used by European businesses: contractual assurances do not remove statutory responsibilities.
The first threshold is whether the technology is an AI system under Article 3. Broadly, the Act covers machine-based systems designed to operate with varying levels of autonomy and which may adapt after deployment, generating outputs such as predictions, content, recommendations or decisions that influence physical or virtual environments. This captures much more than generative AI. It may include candidate-screening tools, fraud models, biometric systems, credit decisioning engines, customer-service assistants, forecasting tools and software that prioritises cases for human review.
Not every rules-based workflow belongs in scope. Conventional software that follows fixed, human-defined logic without the relevant AI characteristics may fall outside the definition. That distinction should be assessed against the actual system design and use, not assumed from a supplier’s sales material.
Certain activities and systems are excluded or treated differently, including AI used solely for military, defence or national security purposes, and some research and development activity before market placement or service. Free and open-source AI systems may receive limited treatment in specific circumstances, but that is not a blanket exemption, particularly for prohibited practices, high-risk uses and general-purpose AI models. A compliance team should record exclusions with the same care as in-scope classifications.
The role you play changes the duties
The EU AI Act does not impose one universal set of duties on every business using AI. Obligations depend heavily on the organisation’s role in the supply chain.
A provider develops an AI system or has one developed and places it on the market or puts it into service under its own name or trademark. Providers carry the most substantial obligations for high-risk systems, including risk management, technical documentation, logging capability, quality management, conformity assessment and post-market monitoring.
A deployer uses an AI system under its authority. Most organisations buying or operating AI for recruitment, HR, customer operations, security or public-facing services will be deployers. Their responsibilities include using the system in accordance with instructions, assigning human oversight, monitoring operation, retaining relevant logs where under their control and reporting serious incidents or malfunctions as required. For certain high-risk uses, deployers must also conduct a fundamental rights impact assessment before use.
Importers and distributors have separate duties to verify that systems entering or moving through the EU market carry the required documentation, marking and provider information. A distributor that simply resells a system is not automatically a provider. However, the position can change rapidly.
An organisation can become a provider if it places its name or trademark on a high-risk system, makes a substantial modification, or changes the intended purpose so that the system becomes high-risk. This is a recurring governance failure in enterprise deployments. A business buys a general HR analytics product, configures it to rank applicants, then assumes the vendor retains every legal responsibility. The original contract may say one thing; the operational reality may say another.
Risk classification determines what applies
The Act is risk-based, but “risk-based” does not mean only high-risk systems matter. Every AI programme needs a classification process capable of identifying four practical outcomes: prohibited, high-risk, subject to transparency obligations, or subject primarily to the baseline duties that apply to the organisation’s role.
Prohibited AI practices
Some uses are banned because the legislature considers the risk unacceptable. These include certain manipulative or exploitative techniques, social scoring, specified predictive policing practices, untargeted scraping of facial images to build biometric databases, and several uses involving emotion recognition, biometric categorisation and real-time remote biometric identification.
The details and exceptions matter. A system that infers emotion in a workplace or educational setting, for example, requires particular scrutiny. A generic supplier assurance that its product is “ethical AI” is not evidence that a prohibited-practice assessment has been completed.
High-risk AI systems
High-risk systems include AI used as a safety component of, or itself as, products regulated under specified EU product legislation. They also include systems used in listed areas such as biometric identification, critical infrastructure, education, employment, access to essential private or public services, law enforcement, migration and border management, and administration of justice or democratic processes.
Employment is a material exposure area for many organisations. AI used to recruit or select candidates, make decisions affecting terms of work, allocate tasks based on individual behaviour or traits, or monitor and evaluate worker performance may be high-risk. The fact that a human signs off on a recommendation does not automatically remove the classification. The relevant question is the system’s intended purpose and its effect on people.
High-risk classification is not a synonym for “do not use”. It means the organisation needs a controlled operating model and evidence that the system meets the required safeguards. For providers, this includes documented risk management, data governance, technical documentation, record-keeping, transparency instructions, human oversight, accuracy, robustness and cybersecurity. For deployers, it means proving that those controls are used and monitored in the real operating environment.
Transparency duties
Certain systems trigger specific disclosure requirements even where they are not high-risk. People should be informed when interacting directly with an AI system, subject to defined exceptions. AI-generated or manipulated content may require machine-readable marking or disclosure, particularly where it could mislead people about authenticity. Employers, communications teams and product owners should not leave these decisions to an isolated model configuration.
The application dates matter, but they are not a reason to wait
The EU AI Act entered into force on 1 August 2024, but its obligations apply in stages. The earliest operational requirements are already live.
From 2 February 2025, the prohibitions on certain AI practices apply. Article 4 AI literacy obligations also apply from that date. Organisations must take measures to ensure a sufficient level of AI literacy among staff and others operating AI systems on their behalf, taking account of technical knowledge, experience, education, training and the context of use. A one-off awareness slide is unlikely to be enough for teams operating high-impact systems.
From 2 August 2025, rules for general-purpose AI models began to apply, alongside governance provisions and penalties. Organisations developing, integrating or procuring foundation-model capability should establish who supplies the model, what downstream system is being built, and which documentation and contractual commitments are available.
Most obligations for high-risk AI systems apply from 2 August 2026. High-risk systems connected to certain regulated products have a later application date of 2 August 2027. These dates should not be treated as implementation start dates. High-risk conformity evidence, supplier due diligence, data governance, logging design, human oversight procedures and incident routes cannot be assembled credibly in the final quarter before a deadline.
The practical implication is simple: apply the legal timeline to each system, but build the governance capability now. A system introduced in 2026 may have an implementation cycle that extends beyond the point at which the relevant controls become enforceable.
Build an auditable applicability decision
A useful AI register does more than list tools. For each system, capture the business owner, supplier or development team, purpose, affected individuals, input data, outputs, geographic use, deployment status, model dependencies and human decision points. Then document the legal assessment: whether it is an AI system, the organisation’s role, the applicable risk category, relevant AI Act articles, dates and control actions.
This record should connect to evidence. For a high-risk recruitment system, that may include supplier technical documentation, instructions for use, a fundamental rights impact assessment, training records for recruiters, human oversight procedures, logs, performance testing, DPIA alignment, incident escalation and board-level risk reporting. A spreadsheet can start the process, but it becomes fragile when classifications change, evidence is versioned, owners leave or an auditor asks why a system was judged out of scope six months earlier.
The same operating model supports ISO/IEC 42001. The standard does not replace statutory analysis, but its management-system disciplines – defined roles, risk treatment, operational controls, monitoring, internal audit and continual improvement – make AI Act compliance more sustainable. Endaxi AIG is designed to bring those activities into one evidence-led system of record rather than leaving legal, risk, security and procurement teams to reconcile separate trackers.
The useful question is not whether your organisation “uses AI”. It is which systems create legal exposure, who is accountable for each one, and whether you could show a regulator, customer or board the basis for every decision. Start with the systems already influencing people, access, employment, safety or material business outcomes. Those are the systems most likely to turn an unstructured AI programme into a compliance problem.