When Deployer Obligations Applies and What to Do Next

Deployer obligations apply when a company uses a high-risk AI system under its own authority, especially where the company decides how the system is put into service, used in a workflow, monitored, supervised, and documented. For SaaS teams, the practical question is not only whether the company built the AI system. It is whether the team is using, configuring, or operating a high-risk AI system in a way that creates deployer responsibilities under the EU AI Act.

The next step is to translate that role into a working process. Identify the AI system, confirm whether it is high-risk, decide whether the company is acting as deployer, assign a responsible owner, follow the provider's instructions for use, set human oversight, monitor the system, preserve relevant logs, and document what happens when risk signals or incidents appear.

This should sit beside existing AI governance expectations for SaaS vendors, internal AI-tool review, compliance owner models, and the risk of leaving requirements in static compliance documents.

When the issue usually appears

Deployer obligations matter when the company uses a high-risk AI system in a business, product, employment, customer, public-sector, financial, education, essential-service, or other consequential workflow. A team may be the provider for one AI feature and the deployer for another. The role depends on the concrete workflow, not the company's preferred label.

Common SaaS triggers include using a third-party AI system inside an HR, credit, insurance, education, public-sector, healthcare, worker-management, biometric, or critical-infrastructure workflow; configuring a vendor AI tool for customer decisions; allowing customers to deploy a sensitive AI workflow through the platform; or using AI output to support decisions that can affect individuals in a high-risk context.

The question can also arise during customer reviews. A buyer may ask whether the vendor provides high-risk AI, deploys high-risk AI internally, or enables customer deployments that might be high-risk. If the team cannot separate those cases, every answer becomes a one-off legal escalation.

When it may not apply

Not every AI-enabled SaaS workflow creates Article 26 deployer obligations. A drafting assistant, support summarizer, code helper, product analytics assistant, or knowledge-search feature may sit outside high-risk use if it is not used in a high-risk context and does not fall into another regulated route.

That does not mean the workflow is outside compliance. It may still require privacy review, security review, vendor assessment, transparency checks, contractual limits, AI inventory entry, or ordinary governance evidence. The important point is routing: ordinary AI use should not be forced into a high-risk process, and plausible high-risk use should not be waved through as ordinary automation.

Teams should document the no-high-risk conclusion. A short record should explain the system, purpose, user group, data types, output, human role, geography, review date, reviewer, and reason no deployer-obligation workflow was triggered. That record protects speed later because the team does not need to restart the same debate during procurement, audit, or fundraising.

What deployers need to control

Article 26 focuses on practical operation. Deployers of high-risk AI systems must take appropriate technical and organisational measures to use the system according to the instructions for use. They must assign human oversight to people with the necessary competence, training, authority, and support.

Where the deployer controls input data, it must ensure that input data is relevant and sufficiently representative in view of the intended purpose. That matters for SaaS teams because a vendor model can become risky when the customer, operator, or internal team feeds unsuitable data into a sensitive workflow.

Deployers must monitor operation on the basis of the instructions for use. If they have reason to consider that use according to the instructions may result in a risk, they must inform the provider or distributor and the relevant market surveillance authority without undue delay and suspend use. Serious incidents create additional notification duties.

Deployers also need log retention where logs are under their control. Article 26 sets a minimum of six months unless another Union or national law provides otherwise, including data protection law. In workplace use, employers must inform workers' representatives and affected workers before putting a high-risk AI system into service or use.

Some obligations are role-specific. Public authorities and Union institutions have registration-related duties. Certain post-remote biometric identification uses by law enforcement have authorisation and documentation rules. Financial institutions may satisfy some monitoring or log documentation expectations through existing financial-services governance arrangements. SaaS teams should capture these differences rather than flattening them into one generic checklist.

A practical first workflow

Start with an AI deployment intake. The intake should be short enough for product, operations, security, and procurement teams to use before launch or enablement.

Capture the system name, vendor or provider, owner, business purpose, user journey, affected people, geography, data categories, output, who relies on the output, whether the system is high-risk or potentially high-risk, whether the company is provider, deployer, or both, and where instructions for use are stored.

Then route the workflow into one of three lanes. Lane one is ordinary AI use with no high-risk signal. Lane two is uncertain or sensitive use where more facts are needed before launch. Lane three is likely high-risk deployment, where Article 26 controls need to be implemented and documented before use.

For lane three, create a deployer decision record. It should name the owner, reviewer, role analysis, high-risk basis, provider instructions, human oversight design, training expectation, input-data control, monitoring method, log retention, incident escalation path, worker-notification requirement, customer or internal communication, and reassessment trigger.

The record should be stored where teams actually work. Product launch records, vendor review files, security review notes, data protection impact assessments, architecture records, and release approvals are often better than a detached spreadsheet. The aim is not a perfect document. The aim is evidence that the team can find and reuse.

Common mistakes

The first mistake is assuming deployer obligations belong only to customers. SaaS vendors often deploy AI internally, support customers with configured AI workflows, or operate AI systems in managed-service or customer-success contexts. Those uses still need role analysis.

The second mistake is relying on vendor documentation without mapping it to actual use. Provider instructions are essential, but the deployer must still decide how the system is used, who oversees it, what input data enters it, how operation is monitored, and what happens when the system behaves unexpectedly.

The third mistake is assigning human oversight without authority. A reviewer who lacks training, access, time, escalation rights, or decision power is not a meaningful control. Oversight needs a real owner and a practical stopping rule.

The fourth mistake is forgetting logs. Teams often discuss model quality and privacy but miss whether logs exist, who controls them, how long they are retained, whether they include personal data, and how they would be produced during an incident or authority request.

The fifth mistake is treating workplace AI as just another internal tool. Where a high-risk AI system is used at work, worker information duties may apply before use. HR, legal, security, procurement, and works-council or employee-representative processes may need to be involved early.

Examples SaaS teams can use

An HR SaaS team that uses a vendor AI system to rank candidates should trigger deployer review if the tool is used by the company for recruitment decisions. The team should document the intended purpose, provider instructions, human oversight, reviewer authority, input-data controls, monitoring, log retention, and worker or candidate communications where relevant.

A customer-support assistant that drafts suggested replies for agents may not be high-risk if humans remain responsible and the workflow does not affect access to essential services or other Annex III areas. The team should still keep privacy, security, vendor, and transparency evidence.

A platform that lets customers configure AI decision workflows needs a different analysis. The vendor may not know every customer use in advance, but it can define prohibited configurations, high-risk use triggers, admin controls, customer instructions, contractual limits, and escalation channels. Those controls help prevent sensitive deployments from bypassing review.

An internal operations team using AI to evaluate worker performance or allocate shifts should not treat that as an ordinary productivity tool. Employment and worker management can be sensitive. The team should review high-risk status, oversight, worker information, input data, monitoring, and escalation before the workflow becomes operational.

FAQ

What is the practical purpose of deployer obligations?

The practical purpose is to make sure a high-risk AI system is used responsibly after it leaves the provider's hands. The deployer controls the operating context, people, input data, monitoring, logs, and escalation path.

When do deployer obligations apply to SaaS teams?

They apply when a SaaS team uses a high-risk AI system under its authority. The team should review vendor tools, internal workflows, customer-enabled configurations, managed services, workplace uses, and any workflow that affects people in a sensitive context.

What should teams document or change first?

Start with a role and workflow record. Document the AI system, purpose, owner, high-risk screening, provider instructions, human oversight, input-data controls, monitoring, logs, incident escalation, worker notification, and the next review trigger.

Sources

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence.
• European Commission AI Act Service Desk, Article 26: Obligations of deployers of high-risk AI systems.
• European Commission, Navigating the AI Act.