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.
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:
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.
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:
Compliance is shared across the AI value chain, but each operator must evidence the responsibilities that belong to its own role.
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:
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.
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:
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.
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:
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.
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:
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.
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:
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.
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:
If required logs are unavailable, document the gap and address it with the provider rather than silently accepting it.
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.
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:
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.
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.
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 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 structured assessment helps a deployer move from role determination to an evidence-based conclusion. A practical sequence is:
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.
The evidence will vary according to the system and obligation, but may include:
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?
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:
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.
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.
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.