By Kevin M. Hyams 

Why I wrote this article

I wrote this article because many organisations will encounter the EU AI Act primarily as deployers of AI systems. They may not design or market AI, but they use it under their authority to support work, services, decisions and interactions with people.

That can create a misleading sense of distance from the Regulation. Buying an AI system from a provider does not transfer every responsibility to the supplier. The provider may be responsible for designing and documenting the system, but the deploying organisation controls how the system is introduced, who uses it, what data is entered, how outputs are acted upon and how emerging problems are handled.

For a deployer, the practical compliance question is therefore not simply:

“Has the provider said that the system complies?”

It is:

“Are we using this AI system in the way required, with the people, controls, monitoring and evidence needed to support our own obligations?”

This is the practical problem NORVA is designed to solve. NORVA helps compliance teams assess the requirements that apply to their role, connect each requirement to controls and evidence, and identify what must be corrected before a weakness becomes an incident or regulatory issue.

What is a deployer under the EU AI Act?

In practical terms, a deployer is a natural or legal person, public authority, agency or other body using an AI system under its authority, except where the system is used in the course of a personal, non-professional activity.

The role is system-specific. An organisation may be a deployer of one externally supplied system and a provider of another system that it develops, substantially modifies, rebrands or puts into service under its own name. Role determination should therefore be recorded for each AI system and use case, rather than assumed across the whole organisation.

Common deployer situations can include using AI to:

• support recruitment, workforce management or employee decisions;
• assist decisions about access to services or benefits;
• analyse customer, operational or security information;
• prioritise cases, applications, alerts or investigations;
• generate recommendations, content or communications; or
• support professional judgement in regulated or higher-impact activities.

The precise obligations depend on the system, its classification, its intended purpose, the context of use and the people affected. A deployer assessment should therefore follow the applicability and classification decision, not replace it.

Why provider assurance is not enough

Provider documentation is essential, but it does not demonstrate how the system is used inside the deploying organisation. Even a properly designed system can be used in ways that depart from its instructions, rely on unsuitable input data, weaken intended human oversight or create risks that were not adequately managed in the local deployment context.

A deployer should be able to demonstrate, where applicable, that it has:

• obtained and understood the instructions for use;
• assigned competent people to human oversight;
• confirmed that controlled input data is relevant and sufficiently representative;
• monitored system operation on the basis of the instructions;
• retained automatically generated logs under its control;
• informed workers, their representatives and affected persons where required;
• completed required impact assessments;
• reported risks and serious incidents to the appropriate parties; and
• suspended use where the conditions requiring suspension are met.

Compliance is shared across the AI value chain, but each operator must evidence the responsibilities that belong to its own role.

Start with AI Literacy

Article 4 requires providers and deployers to take measures to support the development of AI literacy among staff and other people who deal with the operation or use of AI systems on their behalf. This means that AI literacy should be treated as an operational control, not merely as a one-off awareness exercise.

A practical deployer assessment should identify:

• who operates or uses each AI system;
• who reviews or acts on its output;
• who performs human oversight;
• who monitors performance and incidents;
• who manages the provider relationship; and
• what each group needs to understand to perform its role safely and effectively.

The measures should reflect the system and the work being performed. A general introduction may be appropriate for ordinary users, while system owners, human overseers, compliance personnel and incident responders may need more detailed, role-specific support.

Useful evidence can include training materials, attendance records, role descriptions, system guidance, practical exercises, knowledge checks, and records showing how training was updated following system or regulatory changes.

Use high-risk AI systems in accordance with their instructions

Article 26 requires deployers of high-risk AI systems to take appropriate technical and organisational measures to ensure that the systems are used in accordance with the accompanying instructions for use.

The assessment should not stop at confirming that instructions were received. It should examine whether they have been translated into working controls, including:

• approved purposes and operating conditions;
• authorised users and access restrictions;
• required input-data characteristics;
• configuration and integration controls;
• human-oversight arrangements;
• monitoring methods and escalation thresholds;
• logging and record-retention requirements; and
• conditions for restricting or suspending use.

Local changes also matter. New prompts, thresholds, workflows, integrations, data sources or decision rules can alter how the system behaves. Material departures from the provider’s instructions should be assessed before use. The organisation should also consider whether a changed intended purpose or substantial modification could change its regulatory role or the system’s classification.

Make human oversight real, not just a formality

For high-risk systems, human oversight must be assigned to natural persons with the necessary competence, training and authority. Naming an overseer is not enough if that person cannot understand the system, challenge its output or intervene when necessary.

Effective oversight should answer practical questions:

• Does the overseer understand the system’s intended purpose, capabilities and limitations?
• Can the overseer recognise when an output may be incorrect or inappropriate?
• Is there enough time and information to review the output meaningfully?
• Can the overseer disregard, override or reverse an output where appropriate?
• Can the system or its use be stopped safely when required?
• Are interventions and overrides recorded where they are relevant to monitoring or investigation?

The organisation should also guard against automatic reliance on AI output. A control described as “human in the loop” is weak if the workflow, volume, incentives or interface encourage routine acceptance without meaningful review.

Control the input data you supply

Where the deployer controls input data for a high-risk AI system, Article 26 requires that data to be relevant and sufficiently representative in view of the system’s intended purpose.

The deployer should therefore assess whether the data used in its own operational context is suitable for the task. That can include controls to:

• confirm that required data fields are available and relevant;
• identify material errors, omissions or outdated information;
• assess whether the data reflects the population or circumstances in which the system is used;
• prevent unauthorised personal, confidential or sensitive information from being entered;
• detect changes in the data that may affect system performance; and
• record significant data-quality issues and corrective action.

This is an important boundary between provider and deployer responsibility. The provider may specify the characteristics required of inputs, while the deployer may control the operational data actually supplied. Both parts of the assessment need to connect.

Monitor operation and act when risks emerge

Article 26 requires deployers of high-risk systems to monitor operation based on the instructions for use. Monitoring should be designed to identify when the system is no longer operating as expected or when its use may present a risk.

Relevant monitoring information may include:

• errors, malfunctions and unexpected outputs;
• differences between expected and actual outcomes;
• complaints, challenges and requests for human review;
• overrides and interventions by human overseers;
• changes in input data or operating conditions;
• patterns suggesting inappropriate bias or unequal effects;
• misuse or use outside approved conditions; and
• provider notices, updates, vulnerabilities and corrective actions.

Where the deployer has reason to consider that use in accordance with the instructions may pose a risk to the system, Article 26 requires communication with the provider or distributor and the relevant market-surveillance authority. Where a serious incident is identified, the required parties and authorities must be informed. The organisation should define in advance who makes those decisions, how evidence is preserved, and when use must be suspended.

Retain the logs under the deployer’s control

Article 26 requires deployers to keep automatically generated logs under their control for the applicable period. The retention period must reflect Article 26 and any applicable Union or national law. Financial institutions must also address the specific documentation arrangements referenced by the Article.

A practical log-control assessment should establish:

• which logs are generated and which are under the deployer’s control;
• how logs are linked to the relevant system, version, configuration and period of use;
• who may access or retrieve them;
• how they are protected against unauthorised alteration or deletion;
• how long they are retained under the applicable requirements; and
• whether they can support monitoring, investigation, audit and regulatory enquiry.

If required logs are unavailable, document the gap and address it with the provider rather than silently accepting it.

Inform workers before workplace use

Before putting a high-risk AI system into service or using it in the workplace, Article 26 requires deployers to inform workers’ representatives and affected workers that they will be subject to the system's use, in accordance with applicable Union and national rules and practices on worker information.

The assessment should confirm not only that a communication exists, but also that it is provided at the required time and through the appropriate process. Depending on the applicable rules and workplace arrangements, evidence may include notices, consultation records, collective-agreement analysis, meeting records, acknowledgements and approved communications.

The communication should accurately describe the intended use and its relevance to affected workers. Generic wording that does not explain the deployment may not provide a useful or supportable record.

Inform affected persons where high-risk AI supports decisions about them

Where a high-risk AI system makes or assists in making decisions concerning natural persons, Article 26 requires those persons to be informed that they are subject to the system’s use where the provision applies.

A deployer should determine:

• which decisions are made or supported by the system;
• which persons are affected;
• when the information must be provided;
• what the communication must explain;
• how accessibility and clarity will be addressed; and
• how the organisation will evidence that the information was provided.

Complaint handling and human review should also connect to the deployment. Concerns, explanations, review outcomes, and recurring issues can provide important monitoring evidence and may reveal broader weaknesses in the system or its controls.

Connect the deployment to data protection assessment

Where applicable, Article 26 requires deployers to use the information supplied by the provider to meet their data protection impact assessment obligations. The AI Act assessment and the data protection assessment should therefore support one another rather than proceed as disconnected exercises.

The deployer should identify whether personal data is processed and whether a data protection impact assessment is required. The resulting analysis should align on matters such as purpose, data used, affected persons, risks, safeguards, retention, security, individual rights, and the use of AI-generated outputs.

Alignment does not mean treating the assessments as interchangeable. Each serves its own legal purpose, but evidence and conclusions should be consistent and traceable.

Complete a fundamental-rights impact assessment where Article 27 applies

Article 27 requires certain deployers of high-risk AI systems to perform a fundamental-rights impact assessment before deployment. The first control question is therefore whether the organisation and the particular deployment fall within that requirement.

Where the assessment is required, it should address the elements specified by Article 27, including:

• the deployer’s processes in which the system will be used;
• the period and frequency of intended use;
• the categories of natural persons and groups likely to be affected;
• the specific risks of harm likely to affect them;
• the human-oversight measures to be implemented;
• the measures to take if identified risks materialise;
• internal governance and complaint-handling arrangements where required;
• notification to the market-surveillance authority where required; and
• updating the assessment when relevant factors change.

The assessment should be completed before deployment and connected to risk acceptance, approval, monitoring, incident response and change management. It should lead to controls and decisions, not remain a standalone document.

A practical deployer assessment sequence

A structured assessment helps a deployer move from role determination to an evidence-based conclusion. A practical sequence is:

• Confirm the AI system, intended purpose, actual use, and deploying legal entity.
• Verify the organisation’s role and the system’s regulatory classification.
• Identify which deployer obligations apply to the particular system and context.
• Obtain the provider’s instructions and required supporting information.
• Assign accountable owners, authorised users and competent human overseers.
• Assess controlled input data, operational configuration and local integrations.
• Complete worker, affected-person, data protection and fundamental-rights assessments where required.
• Define monitoring, logging, escalation, notification and suspension arrangements.
• Link each assessed requirement to evidence, findings, remediation and approval.
• Reassess after material changes, incidents, complaints, provider updates or altered use.

This sequence turns the deployer obligation into a working control pathway. It also helps prevent a common failure: treating procurement approval as the end of the assessment rather than the start of controlled operational use.

What evidence should a deployer retain?

The evidence will vary according to the system and obligation, but may include:

• the AI inventory record and approved role determination;
• risk-classification and applicability decisions;
• provider instructions and technical information;
• procurement due diligence and contractual responsibility allocation;
• approved use cases, configurations and change records;
• human-oversight appointments, procedures and training records;
• input-data checks and correction records;
• monitoring reports, complaints, overrides and review outcomes;
• system-generated logs and retention records;
• worker and affected-person communications;
• data protection and fundamental-rights impact assessments;
• risk and serious-incident notifications;
• decisions to restrict, suspend or resume use; and
• remediation, retesting and management approval.

The central evidentiary question is: can the organisation show not only what control was intended, but whether it operated for this AI system in this deployment?

The practical conclusion for compliance practitioners

For many organisations, deployer compliance will be the most immediate operational part of the EU AI Act. The organisation may depend on a provider’s system and documentation, but it remains responsible for the way the system is used under its authority.

A defensible deployer assessment should show that the organisation understands the system, follows its instructions, appoints competent human oversight, controls relevant input data, monitors use, retains logs, informs people where required, completes applicable impact assessments and acts promptly when risks or incidents emerge.

The better approach is to ask:

• What AI system are we using, for what purpose and under whose authority?
• Are we clearly acting as a deployer, or has our activity created another role?
• Which deployer obligations apply to this system and use case?
• Who owns each obligation and how does the control work in practice?
• What evidence supports the answer?
• What would trigger suspension, notification or reassessment?

That is the difference between relying on a supplier’s assurance and producing a clear, traceable and supportable assessment of the organisation’s own compliance responsibilities.

How NORVA can help

Do not leave deployer compliance to provider assurance and informal operating practice.

NORVA’s Excel-native compliance assessment tools help organisations and advisers assess AI deployer obligations in a familiar, structured format, with regulatory source links, practical assessor guidance, evidentiary support and automatically generated reporting. Teams can connect each requirement to the control relied upon, the evidence examined, any identified weakness, and the required remediation.

Clear compliance assessment. Practical evidence. No heavy GRC platform required.

Source and Legal Review Note

This article is based primarily on Regulation (EU) 2024/1689, including Articles 4, 26 and 27, together with the 2026 amendment to Article 4 reflected in the source material used for this article. It is written for practical compliance-assessment purposes and should be reviewed against the current consolidated legal text, applicable European Commission guidance and relevant regulatory or judicial developments before reliance. Organisations should obtain qualified legal advice where role classification, high-risk status, impact-assessment requirements, notification duties or another legal issue remains uncertain.

This article provides general information and does not constitute legal advice.