Deployer

What a Deployer is

A deployer is an organisation that uses a high-risk AI system, as opposed to building one. The role comes from the EU AI Act. It sits opposite the provider, the organisation that builds the system and puts it on the market.

Most businesses are deployers and not providers. They buy a tool, switch on a feature inside software they already use, or configure a platform for their own work. They do not train a model or ship a product. The Act still gives them a part to play when the thing they use is classed as high-risk.

The site’s definition has two halves. The first names the role. The second says what follows from it: a deployer has duties of its own, and a vendor handling compliance does not remove them. This page is about both halves. It is not legal advice, and the site says of its own audits that they are a diagnostic and not a legal opinion. For anything that turns on the exact wording of the Act, take advice from a qualified lawyer.

Provider and Deployer

Two roles sit behind most AI use. The governance article describes them as the vendor that builds a system and the business that deploys it. It says the heaviest obligations, a full risk management system run across a product’s lifecycle, representative training data and built-in logging, generally sit with the vendor developing a high-risk system and not with the small business deploying an existing one.

That is the reason small businesses can feel reassured by a vendor’s compliance page. The article’s next step is the one that matters here. “The vendor handles compliance” is not itself a defence. A deployer keeps duties of its own, and a business that buys a tool has not bought its way out of responsibility for how the tool is used.

The HR training article puts the same point in its own field. It describes a deployer as the HR team actually running the system day to day, and it says a deployer carries fewer duties under the Act than the provider, but that fewer is not the same as none. It adds that knowing where the line between provider and deployer sits is part of the same training session as the bias and data-protection material, and not a separate legal briefing.

What a Deployer has to do

The ownership article lists four duties for an organisation that deploys a high-risk system.

Monitor the system. The deployer must watch for anomalies, dysfunctions and unexpected performance. This is not a one-off check at launch. It runs for as long as the system is in use.

Keep its logs. The system’s logs must be kept for at least six months. A log is how a business later shows what a system did and when.

Assign competent people to oversee it. Oversight is a job given to named people who are able to do it. The article says the duty requires people to be assigned, which is more than a policy line saying that oversight should happen.

Inform the provider and the authorities of a serious incident. If something serious goes wrong, a deployer does not handle it alone and in private. There is a reporting route, and the business has to know the route before it needs it.

The article’s source for these duties is a published law-firm summary, and the site reports them as the article does. Read the Act or take advice for the full text.

The duties presume a person

The most useful thing to take from the site’s treatment is what each duty presumes. Monitoring needs someone monitoring. Oversight needs someone assigned. A log kept for six months needs someone who knows where it is and can read it. A serious incident needs someone who knows who to tell.

That is the site’s meaning of the term: the duties presume someone is doing the work, and a business that has not decided who that is will find the deadline arriving without an answer. The duties are written as duties of the organisation, but only a person can carry them out.

This is where the role meets AI ownership. The ownership article says the owner has to exist before the duty applies. Without an owner, the first sign that nobody is monitoring is usually the incident.

Why an owner has to exist first

The ownership article explains why this goes wrong in practice. A rollout is a project with a start, a budget and a date on which it is declared finished. Owning the result is operational work with no end date, and projects do not turn into it on their own. When the project team disbands, the person who understood how the tool was configured returns to their day job, and responsibility spreads across IT, the department, the managing director or legal, and HR. Each holds a slice, and each assumes someone else is watching the rest.

The article says ownership by committee is ownership by nobody. A group can advise and agree principles, but a group cannot be the person who gets the call because the tool did something odd. Its recommendation is one named owner per tool, ideally someone who feels the consequences when it goes wrong, with the authority to pause the tool. Responsibility without that power is only a title.

It also lists what goes wrong after launch when nobody is accountable: quality drifts, access widens, policy goes stale, incidents have no route, and the business cannot show its work. The last two are exactly where the deployer duties bite. An incident with no route has nobody to inform the provider. A business that cannot show its work has no logs worth reading.

The Tool does not stay as it was installed

A reason the monitoring duty cannot be a launch-day exercise is that an AI tool keeps moving. The ownership article says the vendor updates the model behind it, sometimes without an announcement that reaches the people using it. The documents it draws on change, new features switch on and staff find uses nobody planned. A review carried out at launch then describes a tool that no longer exists in quite that form.

The site’s drift page covers this. For a deployer, it is the practical argument for monitoring being continuous, with someone looking at the output on a schedule.

Not every Tool is in scope

The ownership article is careful about scope. The duties apply to deployers of high-risk systems, and most everyday business tools are not in that category. The Act does not ask a business to appoint someone for every chat assistant. The governance article gives drafting, summarising and internal search as examples of use that sits outside the high-risk category altogether.

What decides the class is the use. The high-risk AI system page explains that a classification follows what a system is used for, so the same tool can sit outside the category for one use and inside it for another. The clearest case on the site is recruitment, where the Act classes systems used for recruitment and candidate evaluation as high-risk. A business using a CV filter is a deployer of a high-risk system whichever supplier built it.

The way to find out which of your uses are in scope is to classify each one. The risk classification page covers how.

Size does not exempt a Business

A common assumption is that the Act is written for large enterprises with compliance teams. The governance article says it draws its line at what the AI is used for, not at the size of the organisation. A small organisation running a use case the Act treats as high-risk carries the same core obligations as a large one running the same use case.

The article also reports an easing. Under the Digital Omnibus agreement, a simplified compliance route was extended to qualifying small mid-cap companies, defined as organisations with fewer than 750 employees and either 150 million euro or less in annual turnover or 129 million euro or less in total assets. The article reads this as buying time and easing paperwork, not removing the need to classify a use case correctly and manage the risk it carries.

The dates

The governance article reports that the compliance deadline for stand-alone high-risk systems under Annex III moved from 2 August 2026 to 2 December 2027. Product-embedded high-risk systems under Annex I were given a separate extension to August 2028.

The ownership article draws the right conclusion. This is not an urgent duty for everyone, but a business that has not decided who carries it will find the deadline arriving without an answer. The dates moved and the substance did not. Dates also keep moving, so a business should confirm the current position with its own adviser.

Where to start

The governance article’s order of work applies directly. Start with an inventory of what AI is in use, including tools nobody approved, because a policy built on a guess gets rewritten within a month. The AI tool inventory page covers the list. Then classify each use case by real exposure, and name a specific person and checkpoint for the use cases that carry the most risk.

The ownership article gives the same sequence in a month. Week one is the list of what is in use. Week two is one named owner per tool. If nobody can be found who is willing to be accountable for a tool, the article says that is a finding in itself, and a reason to reconsider whether the tool should be in use.

For the oversight itself, the human in the loop page says the review has to name who checks, at what stage and against what standard. For a high-risk use, that is the deployer’s duty made concrete.

A worked example

This is an illustration, not a real client. A small company has two AI uses. One drafts internal meeting summaries, and a person reads each before it is filed. The other reads incoming CVs and produces a ranked shortlist for a hiring manager.

The first sits outside the high-risk category. The second is a recruitment use, so it falls in the class the HR article describes. The company is a deployer of that second system. It names one person to own it, with authority to pause it. That person monitors the output, keeps the logs, and knows who to tell if something serious goes wrong. The same CV data is personal data under GDPR, so both sets of rules apply at once. Both uses might run in the same tool. The use, and not the tool, sets the class.

In an Audit

Every audit assesses the Act at the Identify step, inside the ranking of opportunities and not as a review added at the end. An audit maps each process in scope against the Act’s own risk scale and does not invent its own. Establishing whether a candidate is high-risk is part of that work, and with it whether the business would be a deployer of it.

The limits are stated on the audit page. An audit identifies and checks against these obligations. It does not certify them, and it is not a legal opinion. The audit methodology explains the five steps.

Mix-ups worth avoiding

Four confusions come up often enough to name. The first is assuming that buying a tool from a compliant vendor ends the matter, when a deployer keeps duties of its own. The second is assuming a small business is outside the Act because of its size. The third is treating every AI tool as high-risk, which the site does not say. The fourth is treating a delay as a removal. The dates moved and the substance did not.

How we use it

The audit page maps the processes in scope against the Act’s own scale, and the ownership article says the deployer duties presume a named person to carry them out. Read what happens when nobody owns the AI you have rolled out for the full argument, and the AI governance article for the deadline and who carries the heaviest obligations. If you want to know which of your own uses make the business a deployer, a discovery call is where to start.

Sources

• What happens when nobody owns the AI you have rolled out: the four deployer duties, why an owner must exist first, the costs of an unowned tool, and the scope caveat.
• AI governance for small and mid-sized businesses: the vendor and deployer split, the dates, the small mid-cap route, and the order of work.
• AI training for HR teams: what should it cover?: the HR team as deployer, and fewer duties but not none.
• High-risk AI system, EU AI Act and human in the loop: the classification of a use, the recruitment example and the review step.
• How we audit: how an audit meets the Act.