The EU AI Act

Artificial intelligence has moved remarkably quickly from experiment to ordinary business tool. Organisations now use AI to screen applications, support recruitment, analyse customers, detect fraud, generate content, prioritise work, assist decision-making and automate activities that would previously have required human judgement.

The European Union's AI Act changes the environment in which many of those systems are developed and used. Rather than treating artificial intelligence as simply another form of software, the Act recognises that some uses of AI can affect safety, fundamental rights and people's opportunities in ways that justify specific controls.

For project teams, the important point is that the AI Act is not merely something for the legal department to consider shortly before a system goes live. Decisions about the purpose of an AI system, the data it uses, the people affected by it, the way humans oversee it, the evidence retained during development and even the way it is purchased can determine which obligations apply.

This article provides a practical introduction to the Act for people who may recommend, specify, develop, test, procure, approve, govern or use AI systems. It does not attempt to reproduce the legislation, and it is not legal advice. Its purpose is to help project teams recognise the questions they need to ask and understand when specialist legal or regulatory advice may be necessary.

What is the EU AI Act?

The Artificial Intelligence Act, formally Regulation (EU) 2024/1689, creates a common legal framework for artificial intelligence across the European Union. Like the GDPR, it is a Regulation rather than a Directive, which means that it is directly applicable in EU Member States rather than requiring each country to create an entirely separate version of the law.

Its basic philosophy is risk-based. The Act does not attempt to regulate every use of AI in exactly the same way. Instead, the degree of regulation depends upon factors including what the system does, how it is used, the role played by the organisation concerned and the potential consequences for people, safety and fundamental rights.

This is important because the familiar shorthand description of the Act as having four neat "risk levels" is useful for teaching, but the legislation is more nuanced than a simple four-box classification. Some AI practices are prohibited. Certain systems are classified as high-risk and attract extensive requirements. Particular AI systems have transparency obligations. Providers of general-purpose AI models have a separate set of obligations, with additional requirements where those models present systemic risk. Many other AI applications attract few or no specific obligations under the Act.

The practical lesson is that an organisation cannot determine its obligations merely by deciding that its AI is "low", "medium" or "high" risk. It needs to understand the system, its intended purpose, its context of use and its own legal role.

Does the Act apply outside the European Union?

Potentially, yes. This matters particularly to UK organisations.

The AI Act is European Union legislation, but being established outside the EU does not automatically put an organisation beyond its reach. Among other situations, the Act can apply where an organisation outside the EU places an AI system or general-purpose AI model on the EU market, or where the output produced by an AI system is used within the EU.

A British organisation should therefore not dismiss the Act simply because the United Kingdom is no longer an EU Member State. A UK supplier selling an AI product into the EU, a company providing an AI service whose output is used there, or an organisation operating across both UK and EU markets may need to consider the Act carefully.

There are exclusions and special cases. Certain activities involving research, development and prototyping before a system is placed on the market are outside the normal scope, and systems exclusively intended for military, defence or national-security purposes are also excluded. The detailed scope rules matter, however, and organisations operating close to these boundaries should obtain appropriate advice rather than relying upon a general summary.

Before thinking about risk, establish your role

One of the easiest mistakes is to talk about "the organisation using AI" as though everybody has the same responsibilities. The Act distinguishes between several roles in the AI value chain, and the obligations differ accordingly.

A provider is broadly the organisation that 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. A deployer is an organisation using an AI system under its authority in a professional context. The Act also recognises importers, distributors, product manufacturers, authorised representatives and providers of general-purpose AI models.

For many ordinary businesses purchasing and using an AI product, the organisation will principally be a deployer. That does not mean it has no responsibilities. Nor should an organisation assume that purchasing a compliant product transfers all responsibility to the supplier.

The distinction can become particularly important when an organisation modifies a system. In some circumstances, making a substantial modification, putting an existing system under your own name or trademark, or changing its intended purpose can cause responsibilities normally associated with the provider to move to the organisation making that change.

Start with the intended purpose

The phrase intended purpose runs through the AI Act and is one of the most important concepts for project teams. An AI system is not classified simply by the technology inside it. What it is intended to do, who will use it and in what context can fundamentally change the regulatory position.

Consider an AI system capable of analysing written text. Used to sort internal documents into folders, it may present little regulatory concern. Used to evaluate examination answers, rank job applicants or contribute to decisions about access to an essential service, the context is very different even though some of the underlying technology may be similar.

This is one reason Business Analysts, product owners and requirements specialists have an important role in AI compliance. A vague statement such as "the system will use AI to improve recruitment" is not merely a poor requirement. It may be inadequate for understanding the regulatory position. The project needs to know what decisions the system supports, what outputs it produces, how those outputs will be used, who is affected and what authority a human retains.

Some AI practices are prohibited

At the most serious end of the framework are uses of AI that the Act prohibits. These are not systems that an organisation can make acceptable simply by adding more documentation, performing additional testing or placing a human nominally in the loop.

The prohibited practices cover particular forms of harmful manipulation and deception; exploitation of vulnerabilities associated with factors such as age, disability or social or economic situation; certain forms of social scoring; particular predictive-policing practices; some uses involving biometric categorisation and emotion recognition; and tightly constrained uses of remote biometric identification. The precise legal definitions, conditions and exceptions matter considerably, particularly in areas such as law enforcement.

The practical lesson for a project team is simple: classification must happen early. Discovering shortly before deployment that the intended use falls within a prohibited practice is not a testing problem waiting to be fixed. It is a fundamental problem with what the organisation intends to do.

High-risk AI

The next major category is high-risk AI. The term can be misleading because it does not simply mean "an AI system that our risk register says is risky". High-risk status is a legal classification under the Act.

Broadly, high-risk systems arise in two ways. One route concerns AI used as a safety component of, or itself constituting, certain products covered by specified EU product-safety legislation. The other concerns specified use cases in sensitive areas identified by the Act.

Those sensitive areas include certain applications involving biometrics, critical infrastructure, education and vocational training, employment and worker management, access to important private and public services, law enforcement, migration and border control, and the administration of justice and democratic processes.

That does not mean that every AI system used somewhere within one of those industries is automatically high-risk. The particular use and function matter. The Act also contains circumstances in which an Annex III system may not be considered high-risk where it does not pose a significant risk of harm to health, safety or fundamental rights and meets specified conditions. Profiling of natural persons within the relevant Annex III use cases receives stricter treatment.

For project teams, this means that classification needs evidence. If a provider concludes that an AI system falling within an Annex III area is not high-risk, that conclusion should not be an undocumented conversation in a meeting. The Act requires the relevant assessment to be documented.

What does high-risk actually mean for a project?

High-risk classification brings a substantial compliance regime. The requirements are not simply legal paperwork placed around an otherwise unchanged development process. Many of them concern activities familiar to quality professionals, developers and testers.

Providers of high-risk systems need an ongoing risk-management system. Data used for training, validation and testing is subject to governance and quality requirements. Technical documentation must be produced and maintained. Systems need appropriate logging and record-keeping capabilities. Users need sufficient information to understand the system and its limitations. Human oversight must be designed into the system, and appropriate levels of accuracy, robustness and cybersecurity must be achieved.

Testing is explicitly part of this regime. High-risk AI systems are to be tested to identify appropriate risk-management measures and to demonstrate consistent performance for their intended purpose. Testing is expected during development as appropriate and, in any event, before the system is placed on the market or put into service. Metrics and probabilistic thresholds should be defined in advance and be appropriate to the intended purpose.

Before a high-risk system is placed on the market, providers may also need to complete the applicable conformity-assessment procedure, prepare the required declaration of conformity, complete registration requirements and apply the appropriate CE marking.

This changes the significance of project evidence. A test report is no longer valuable only because it helps the project decide whether the product is ready. For regulated AI it can form part of the evidence supporting a wider claim that the system has been developed and controlled appropriately.

Data quality is not merely a data-science concern

The Act's treatment of data is particularly relevant to the problem of bias. High-risk systems trained using data need appropriate data-governance and management practices, and the characteristics of training, validation and test datasets matter.

That should change the questions asked by the wider project team. Where did the data come from? Does it represent the population and circumstances in which the system will operate? What assumptions were made when records were labelled? Are important groups poorly represented? Are there gaps or errors? Could historical decisions embedded in the data create discriminatory outcomes?

These are not questions that can safely be left until system testing. By then, the model may already have learned from decisions made much earlier in the lifecycle.

Human oversight has to mean something

"There's a human in the loop" is sometimes offered as though it settles every concern about AI decision-making. It does not.

For high-risk AI, human oversight needs to be effective. The people performing it need to understand the system sufficiently to recognise its capabilities and limitations, interpret its output appropriately and remain alert to the risk of automatically accepting an AI recommendation simply because the computer produced it.

They also need appropriate authority. A human who theoretically reviews an AI decision but is unable, unwilling or organisationally discouraged from overriding it provides very weak oversight.

For a project team, human oversight therefore creates requirements that can and should be tested. Can the reviewer understand what is being presented? Can they challenge it? Can they override the recommendation? What happens when they do? Is the override recorded? Are workload and time pressure likely to reduce the supposedly meaningful review to a rubber-stamping exercise?

Deployers have responsibilities too

Many organisations reading the Act will not develop high-risk AI themselves. They will buy or license systems from somebody else. That does not make their role passive.

Deployers of high-risk systems have obligations concerning their use. They must take appropriate technical and organisational measures to use the system in accordance with its instructions, assign human oversight to people with the necessary competence, training and authority, and — where they control the input data — ensure that it is relevant and sufficiently representative for the intended purpose.

They also need to monitor operation in accordance with the instructions for use. Where there is reason to believe that using the system as instructed may present a relevant risk, the Act provides for escalation, including informing the provider or distributor and the relevant authority and, where appropriate, suspending use. Serious incidents also trigger reporting responsibilities.

This is one of the areas where procurement teams need to think beyond the purchase decision. An organisation needs enough information from its supplier to understand how the system should be used, what its limitations are, what monitoring is required and how incidents will be handled. Contractual relationships and access to evidence therefore become part of practical AI governance.

Fundamental rights impact assessments

Certain deployers of high-risk systems are required to perform a fundamental rights impact assessment before first use. The obligation applies particularly to specified public-sector and public-service contexts and to certain high-risk uses associated with areas such as creditworthiness and insurance.

The assessment considers how the system will be used, who is likely to be affected, the risks of harm to those people or groups, the human-oversight arrangements and the measures that will be taken if those risks materialise. It is therefore much more than a technical description of the model.

For organisations already familiar with the GDPR, there is an important connection with the Data Protection Impact Assessment. Where relevant obligations have already been addressed through a GDPR DPIA, the AI Act allows appropriate cross-reference rather than requiring organisations blindly to duplicate the same work.

This is a good example of why AI compliance should not be built as an isolated programme. The same project may need to consider AI regulation, data protection, cybersecurity, sector-specific regulation, equality law, employment law, consumer protection and existing organisational governance. The AI Act does not make those other obligations disappear.

Transparency: people sometimes need to know that AI is involved

Not every regulated AI system is high-risk. The Act also imposes transparency obligations on particular systems and uses because people should sometimes know that they are interacting with AI or encountering AI-generated or manipulated material.

For example, providers of systems designed to interact directly with people must generally ensure that those people are informed that they are interacting with AI unless this is obvious in the circumstances. Providers of generative AI systems also face requirements concerning machine-readable identification of AI-generated or manipulated outputs.

Deployers have transparency responsibilities in areas including emotion recognition and biometric categorisation, deepfakes, and certain AI-generated or manipulated text published to inform the public on matters of public interest where the relevant human review or editorial control is absent. There are qualifications and exceptions, so the exact provision should be checked for a particular use.

These requirements have immediate implications for requirements, UX design and testing. If the user needs to be informed that they are interacting with AI, where and when does that happen? Is the disclosure understandable? Can it be missed? Does it remain effective on a mobile device? If generated content must be machine-readable as AI-generated, does that marking survive the normal processing and distribution chain?

These are regulatory requirements that eventually become testable product behaviour.

General-purpose AI is treated differently

The explosion of large general-purpose models created another problem for regulation. A model capable of generating text, images, software or analysis may be incorporated into thousands of downstream applications, and its provider cannot know every eventual use.

The Act therefore contains a separate regime for providers of general-purpose AI (GPAI) models. Among other obligations, providers need technical documentation, must make information available to downstream providers so that those organisations can understand capabilities and limitations and meet their own obligations, must maintain a policy addressing EU copyright law, and must publish an appropriately detailed summary of the content used for training.

Providers of GPAI models presenting systemic risk face additional obligations covering areas such as model evaluation, systemic-risk assessment and mitigation, serious-incident reporting and cybersecurity.

Most ordinary organisations using a commercial generative-AI service will not suddenly become the provider of the underlying general-purpose model. Nevertheless, project teams need to understand the distinction between the model, the AI system built around it and the organisation's particular use of that system. Different responsibilities can exist at different points in that chain.

AI literacy is already an organisational obligation

One of the most immediately relevant provisions for ordinary organisations is also one of the easiest to overlook: AI literacy.

Providers and deployers are required to take measures concerning the AI literacy of staff and other people dealing with the operation and use of AI systems on their behalf. The appropriate approach depends upon matters such as people's knowledge and experience and the context in which the AI is used.

This should not be interpreted as a requirement to turn every employee into a data scientist. Someone using a generative-AI assistant to help draft routine documents needs different knowledge from somebody supervising a high-risk system that contributes to employment decisions.

What matters is that people understand enough to use the AI appropriately. That may include understanding limitations, recognising that outputs can be wrong, knowing what information may safely be entered, recognising when human review is required, understanding escalation routes and appreciating the consequences of inappropriate reliance.

The implementation timetable matters

The AI Act has not arrived as a single regulatory "big bang". Its provisions have come into application progressively, and the timetable has itself been amended. That makes old articles, presentations and compliance roadmaps particularly dangerous if they are treated as current without checking them.

The Act entered into force in August 2024. The provisions concerning prohibited practices and AI literacy began applying in February 2025. Governance provisions and obligations concerning general-purpose AI models followed in August 2025. Many of the Act's remaining provisions, including the Article 50 transparency requirements, became applicable in August 2026.

Following the 2026 changes to the legislation, the main high-risk rules for the specified sensitive use cases in Annex III are scheduled to apply from 2 December 2027. High-risk requirements for relevant AI systems embedded in regulated products have a later date of 2 August 2028.

Those dates should not be interpreted as permission to ignore high-risk requirements until the last moment. Systems being conceived and procured now may still be operating when those requirements apply. Retrofitting documentation, logging, data governance, human oversight and test evidence into an established AI system can be substantially harder than designing for them from the beginning.

What about systems already in use?

Existing AI deserves particular attention. Organisations frequently focus their compliance work on new projects while overlooking systems already embedded in business processes, including AI functionality quietly introduced through upgrades to commercial software.

Application of the Act to systems already placed on the market or put into service depends upon the relevant provisions, dates and circumstances. Specific transitional arrangements exist, and some obligations can be triggered by later changes to a system.

The practical response should be an AI inventory. An organisation cannot sensibly govern AI that it does not know it has. That inventory should capture not merely obvious machine-learning projects but purchased applications, embedded AI features, generative-AI services, automated decision-support systems and significant uses of general-purpose models.

What happens if we change the system?

AI systems evolve. Models are updated, data changes, suppliers introduce new capabilities and organisations discover uses that were never contemplated during the original project.

That matters because a substantial modification or change of intended purpose can alter the regulatory position. An apparently modest business decision to reuse an existing AI capability in a new context may therefore have consequences far beyond ordinary change control.

Change requests involving AI should consequently ask more than "Does it still work?" They should also ask whether the intended purpose has changed, whether the risk classification remains valid, whether previous assessments remain current, whether new people or groups are affected, whether the data remains appropriate and whether existing controls and evidence still support the system as changed.

What does this mean for Business Analysts?

Business Analysts are particularly well placed to influence AI compliance because so many regulatory questions begin as requirements questions.

What problem are we solving? What decision will the AI make or influence? Who will use it? Who will be affected? What data will it need? What does the organisation mean by an acceptable result? When must a human intervene? What information must the user receive? What must be recorded? What happens when the system is uncertain or wrong?

These are familiar analysis questions, but under the AI Act some of their answers can determine the regulatory classification and the controls that must eventually be implemented.

The BA should therefore resist requirements that simply say that a system "shall use AI". AI is an implementation capability, not a business objective. The important requirements concern what the organisation is trying to achieve, the constraints under which it may do so and the evidence needed to show that the resulting system is acceptable.

What does this mean for testers?

For testers, the Act reinforces a change already taking place in AI testing. Demonstrating functional correctness is not enough.

Testing may need to provide evidence concerning performance thresholds, robustness, cybersecurity, data and population behaviour, human oversight, logging, transparency and known limitations. For high-risk systems, risk-management activities and testing are explicitly connected.

Testers should also challenge the test oracle itself. An AI system may not have a single predetermined correct output for every input, so testing often depends upon metrics, thresholds, tolerances and distributions. Those measures need to be appropriate to the intended purpose rather than chosen simply because they make the model look good.

The Act also strengthens the case for testing operational behaviour. A model that performed acceptably during development may encounter different data, different populations and different human behaviour after deployment. Monitoring, incident handling and reassessment therefore belong to the quality story.

What does this mean for project and product managers?

The biggest mistake a project manager can make is to create a work package called "AI Act compliance" near the end of the plan and assign it to Legal.

Regulatory requirements can affect architecture, data acquisition, requirements, supplier selection, contracts, UX, logging, documentation, testing, release criteria, training, operational monitoring and incident management. Discovering those requirements late can create expensive rework or prevent deployment entirely.

Project and product managers should therefore ensure that classification and role analysis occur early, that regulatory requirements have identifiable owners, and that evidence is produced as the project progresses rather than reconstructed retrospectively.

What does this mean for managers approving AI?

Senior decision-makers do not need to understand every article of the Regulation, but they do need to know what evidence they should expect before approving an AI initiative.

A useful governance discussion should be able to explain the intended purpose, the organisation's role, the classification of the system, the people who may be affected, the principal risks, the source and suitability of important data, the nature of human oversight, the testing performed, significant limitations, the monitoring arrangements and who owns the residual risk.

If a project can answer only "the supplier says it is compliant", the organisation probably does not yet understand enough about the system it is about to rely upon.

Supplier claims need to be tested too

Many organisations will meet regulated AI through procurement rather than development. That makes supplier assurance critical.

Procurement should establish what role the supplier believes it plays, what classification it has assigned to the system, what evidence supports that classification, what documentation and instructions are provided, what data the product uses, how updates are controlled, what logging is available and how incidents and significant changes will be communicated.

The organisation should also understand what happens when the supplier changes the model underneath the service. In cloud-based AI, the product used today may not behave identically six months from now. Contracts, monitoring and change-management arrangements need to reflect that reality.

The AI Act does not replace GDPR

An AI system can comply with the AI Act and still create problems under data protection law. Conversely, complying with GDPR does not establish compliance with the AI Act.

Where personal data is involved, organisations may still need to consider lawful basis, purpose limitation, data minimisation, transparency, data subject rights, special-category data, automated decision-making, retention, security and Data Protection Impact Assessments under the GDPR. Other legal regimes may also apply depending upon the system and sector.

The useful way to think about this is not "Which law applies?" but "Which obligations apply to what we are doing?" A single AI project may have to satisfy several legal and regulatory frameworks at once.

And it is not only about fines

The AI Act provides for substantial financial penalties. The most serious infringements, including prohibited AI practices, can attract penalties of up to €35 million or, for undertakings, a percentage of worldwide annual turnover. Other breaches can also result in significant penalties, with the precise maximum depending upon the infringement and the organisation concerned.

For most responsible organisations, however, the threat of a fine should not be the main reason for taking the Act seriously. A badly governed AI system can cause harm long before a regulator becomes involved. It can discriminate against customers or employees, expose confidential information, make unsafe recommendations, damage trust, create reputational harm and leave an organisation unable to explain decisions on which people have relied.

Good AI governance is therefore not simply a defensive exercise in avoiding regulatory punishment. Many of the disciplines encouraged by the Act — understanding purpose, managing risk, improving data quality, maintaining traceability, testing properly and ensuring meaningful human oversight — are things a competent organisation should want to do anyway.

Where should an organisation start?

For an organisation that has not yet established formal AI governance, the temptation is to begin by reading hundreds of pages of legislation and creating a large compliance programme. A more useful first step is to understand what the organisation is actually doing.

Create an inventory of AI systems and significant AI uses. Establish their intended purposes and the people affected by them. Identify whether the organisation is provider, deployer or playing another role. Screen for prohibited practices and determine whether any systems may fall within the high-risk provisions or specific transparency requirements. Identify uses of general-purpose AI and the suppliers involved.

Then look at the controls already available. Existing risk management, information security, quality management, data protection, procurement, testing, change control and incident-management processes may already provide much of the machinery required. The objective should not automatically be to create a parallel bureaucracy labelled "AI". It should be to identify where AI creates new obligations or where existing controls need strengthening.

Finally, establish ownership. Somebody needs to know who is responsible for classification, who accepts risk, who monitors regulatory change, who owns supplier assurance, who maintains evidence and who can stop deployment when the evidence is not good enough.

The Act is a lifecycle issue

Perhaps the most important lesson for project teams is that compliance is not an event that occurs at release.

The intended purpose can change. Data can drift. Models can be updated. Suppliers can replace components. New populations can begin using the system. Previously unknown risks can emerge. Incidents can reveal assumptions that were wrong from the beginning.

The regulatory position and the evidence supporting it therefore need to survive beyond the project that originally delivered the system. AI governance has to connect development with operation.

About this guide

This article provides an educational overview of the EU Artificial Intelligence Act for professionals involved in AI projects and organisational decision-making. It is not legal advice and necessarily simplifies a large and evolving body of legislation and guidance.

The AI Act has a staged implementation timetable and has already been amended since its original adoption. Organisations making regulatory or compliance decisions should therefore consult the current legislation, current European Commission guidance and, where appropriate, qualified legal or regulatory specialists rather than relying solely upon summaries such as this one.