The EU AI Act, for Vision Systems

The EU AI Act is the most specific law bearing on this field. Its structure is risk-tiered, and vision systems appear in every tier.

General orientation, not legal advice. Obligations depend on your role, your use case and your jurisdiction.

The shape of it

Regulation (EU) 2024/1689, published in the Official Journal in July 2024 and entering into force twenty days later.

Four tiers: prohibited practices, high-risk systems, limited-risk systems with transparency duties, and everything else.

Obligations differ by role. A provider who develops or places a system on the market carries more than a deployer who uses one, and both carry something.

Extraterritorial reach: it applies to systems placed on the EU market or whose output is used in the EU, regardless of where the organisation is based.

The dates

2 February 2025: prohibited practices became applicable and enforceable.

2 August 2025: obligations for general-purpose AI models.

2 August 2026: the main body of high-risk obligations, and the transparency duties under Article 50.

2 August 2027: obligations for AI embedded in regulated products such as machinery and medical devices.

The prohibitions are not forthcoming. They have applied for some time.

What is prohibited

Relevant to vision, in summary form.

Untargeted scraping of facial images from the internet or CCTV to build or expand facial recognition databases.

Inferring emotions of a natural person in the workplace or educational institutions from biometric data, except for medical or safety purposes.

Biometric categorisation inferring sensitive attributes such as race, political opinions, religious beliefs or sexual orientation.

Real-time remote biometric identification in publicly accessible spaces for law enforcement, with narrow exceptions subject to authorisation.

Social scoring and certain manipulative practices, which reach vision systems in some applications.

Penalties for prohibited practices reach the highest tier in the Regulation — up to €35 million or seven percent of worldwide annual turnover, whichever is higher.

What is high-risk

Biometric identification systems, and emotion recognition where it is not prohibited outright.

Systems used as safety components in products already regulated.

Certain uses in employment, including for monitoring and evaluation of workers.

Critical infrastructure safety components.

High-risk brings a substantial apparatus: risk management, data governance, technical documentation, logging, human oversight, accuracy and robustness requirements, registration, and post-market monitoring.

Transparency duties

Deployers of emotion recognition or biometric categorisation must inform the people subject to it, under Article 50, from August 2026.

Informing does not make a prohibited practice permitted, which is the most common misreading. Test the prohibition first; the disclosure duty applies only to what is not prohibited.

What to do about it

Classify each system you operate or plan. Prohibited, high-risk, transparency-only, or minimal.

Start with the prohibitions, because they are in force and carry the largest penalties.

Check your vendor's classification and ask for their documentation. A provider unable to say which tier their product falls in is a finding.

Note the GDPR runs alongside, not instead. Biometric data remains special-category data with its own requirements, and the AI Act adds to them rather than replacing them.

Document the assessment at the time, because the reasoning cannot be reconstructed convincingly two years later.

Classifying what you already run

The first practical step, and most organisations have not taken it.

List every deployment from the inventory.

For each: prohibited, high-risk, transparency-only, or minimal?

Start with the prohibitions, which are in force and carry the highest penalties.

Check the vendor's own classification and ask for the documentation supporting it.

Where the classification is unclear, record it as unresolved with a date, rather than assuming the favourable reading.

Redo it after every vendor upgrade, because a new feature can move a system between tiers.

Provider or deployer

The role determines which obligations attach, and organisations frequently misjudge which they are.

A deployer uses a system placed on the market by someone else.

A provider develops one, or places it on the market under their own name.

Substantially modifying a system, or putting your name on it, can make you a provider, which carries considerably more.

Fine-tuning a purchased model on your own data may cross this line.

Establish which you are before assuming the vendor carries the burden, because they carry theirs and you carry yours regardless.