Article 26: what deployers of high-risk AI must do

Use the system in line with the provider's instructions for use. A high-risk system is assessed and approved for a particular purpose; pushing it into a different job, or feeding it inputs it was never designed for, can undo that and put the risk squarely back on you.

This is the cheapest duty to meet and one of the easiest to breach by accident. Read the instructions, and make sure the people operating the system know what it is and is not meant to do.

Assign oversight to people who have the competence, training, and authority to do it, and give them the time and support to act. This is the deployer side of Article 14, and it is where a great deal of real-world compliance actually lives.

Oversight is not a name on an org chart. The person has to understand the system well enough to catch its mistakes, and be genuinely able to override or stop it without that being a career risk.

Where you control the data fed into a high-risk system, you have to make sure it is relevant and sufficiently representative for the purpose. Poor or skewed input data is one of the quickest ways for a high-risk system to produce unfair or simply wrong results.

You are not responsible for how the provider trained the underlying model, but you are responsible for the data you put in. If you feed it your own records, their quality is your concern.

Keep an eye on how the system performs in practice, not only on the day you switched it on. If you have reason to think its use creates a risk, you have to inform the provider or distributor and, where needed, suspend use.

If a serious incident occurs, one that leads or could lead to serious harm, you have to report it, working with the provider, within the tight timeframes the Act sets under Article 73. Agree that path before you ever need it.

Where the logs a high-risk system generates are under your control, retain them for an appropriate period, generally at least six months unless other law requires longer. Logs are how you reconstruct what happened if a decision is later questioned.

In practice this is usually a matter of switching retention on and storing the logs somewhere you can produce them, rather than building anything new.

Before you put a high-risk system to work on your own staff, inform the affected workers and their representatives. This is a genuine obligation, not a courtesy, and it comes before go-live rather than after.

Separately, where a high-risk system makes or supports decisions about individuals, applicants, customers, and the like, those people generally have a right to be told it is being used. Decide how you will tell them and put it in place.

Use the provider's information to carry out a data protection impact assessment where the GDPR requires one. For high-risk AI that processes personal data this is common, and the AI Act and GDPR work together here.

Certain deployers, mainly public bodies and some creditworthiness and insurance uses, also have to complete a fundamental rights impact assessment under Article 27, and public authorities register their use in the EU database under Article 49.

Veillo turns this list into a tracked roadmap. It works out which of these duties apply from what is in your register, generates the documents for the ones that need them, and lets you confirm the operational steps like log retention and worker information.

Every change is written to an append-only audit log, so the record of who did what and when, the thing an authority would ask for, builds itself as you work.