Deployer Obligations Checklist for Founders and Compliance Leads

Deployer obligations under the EU AI Act should be checked before a team puts a high-risk AI system into service, changes how it is used, expands it to a new customer or worker workflow, or relies on its output in a consequential decision. The practical checklist is straightforward: confirm the company is acting as deployer, use the system according to provider instructions, assign competent human oversight, control input data quality where the team controls the data, monitor live use, keep logs, manage notices and impact assessment triggers, and define when use must be suspended or escalated.

For SaaS teams, this is an operating workflow rather than a one-page legal memo. Deployer obligations connect product configuration, customer implementation, vendor management, support operations, employee training, security logging, privacy review, and incident response. A founder or compliance lead should be able to open one record and see what system is being used, why the company is a deployer, what the provider instructed, who oversees the system, what evidence exists, and what would force a reassessment.

Use this checklist alongside broader AI governance expectations for SaaS vendors, the practical pressure behind faster AI regulation for SaaS founders, and the risk of letting obligations sit in static compliance documents. It also fits naturally into the way founders prepare compliance evidence before fundraising due diligence.

1. Confirm the system and use case

Start by naming the exact AI system and workflow. Do not record "AI vendor" or "AI feature" as the object of review. Identify the provider, product name, version or configuration, intended purpose, business owner, users, affected people, input data, output, decision point, and whether the system is used for customers, employees, applicants, contractors, or internal operations.

Record whether the system is high-risk, transparency-related, minimal risk, or still being classified. If classification is unresolved, the deployer checklist should not be marked complete. It should show the classification owner, open questions, provider documents requested, and the decision date.

2. Decide whether the company is a deployer

Under the AI Act, deployer status is about using an AI system under an organization's authority, except for personal non-professional use. SaaS companies can be deployers when they use third-party AI inside support, hiring, trust and safety, fraud review, customer scoring, content moderation, or internal operational workflows.

Write down the facts. Who selected the system? Who defines the operational use? Who controls access? Who configures thresholds, prompts, workflow rules, or escalation steps? Who trains staff to use the output? Who decides whether the AI output is accepted, reviewed, overridden, or ignored?

The same company may be provider for one AI product and deployer for another. Keep that distinction visible, because provider obligations and deployer obligations produce different evidence.

3. Collect and lock the provider instructions

Article 26 requires deployers of high-risk AI systems to take appropriate technical and organisational measures so the system is used according to the instructions for use. Operationally, that means the team needs the current provider instructions, release notes, limits, supported use cases, unsupported use cases, monitoring expectations, human oversight instructions, and escalation routes.

Store the instructions where product, security, legal, support, and operations can retrieve them. Record the version reviewed and the date. If customer teams, implementation teams, or support teams receive separate instructions, reconcile them with the official provider instructions before launch.

Do not let local practice drift away from the instructions. If teams create shortcuts, custom prompts, undocumented thresholds, or alternative workflows, record whether that changes the intended use, risk classification, privacy assessment, or contractual position.

4. Assign human oversight with competence and authority

Human oversight is not satisfied by naming a team in a policy. Article 26 requires oversight to be assigned to natural persons with necessary competence, training, authority, and support. The checklist should name the role or people responsible for oversight, the training they received, the decisions they can make, and the situations where they must intervene.

For each workflow, ask:

• Can the reviewer understand what the AI output means?
• Can they see the information needed to challenge the output?
• Can they override, pause, escalate, or reject the output?
• Are they protected from pressure to rubber-stamp recommendations?
• Do they know when the system is outside its approved use?

Keep training evidence practical. A short training record, role-specific guidance, decision examples, and escalation flow are often stronger than a broad policy no one uses.

5. Check input data controls

Where the deployer controls input data, Article 26 requires that data to be relevant and sufficiently representative in view of the intended purpose of the high-risk AI system. This is easy to miss because SaaS teams often think data quality belongs only to the provider.

Record which inputs the team controls: customer data, employee data, support tickets, uploaded documents, prompts, risk labels, CRM fields, transaction records, or configuration data. Then document minimum quality checks, excluded data, stale data handling, bias or representativeness concerns, and who owns remediation.

If the team cannot prove the input data fits the approved use, the launch decision should stay conditional. Bad input data can make a compliant system behave poorly in the real workflow.

6. Monitor operation and define escalation

Deployers must monitor operation based on the instructions for use and, where relevant, inform providers under the AI Act post-market monitoring framework. The checklist should define what will be watched, how often it will be reviewed, who reviews it, and what happens when results change.

Monitoring can include support escalations, user complaints, override rates, unusual output patterns, quality sampling, incident tickets, data drift signals, vendor notices, customer misuse, or repeated manual corrections. The right indicators depend on the use case, but every deployer record should say what evidence will show the system is still being used as approved.

Escalation must be specific. If the team has reason to think use according to the instructions may present a regulatory risk, Article 26 points to informing the provider or distributor and the relevant market surveillance authority, and suspending use. If there is a serious incident, the escalation path should identify provider, importer or distributor, authority, legal, security, privacy, and customer communication owners.

7. Keep logs under your control

Article 26 requires deployers to keep automatically generated logs under their control for a period appropriate to the intended purpose and at least six months, unless other Union or national law provides otherwise. This should be translated into a concrete logging rule before launch.

The checklist should capture what logs exist, which logs are under the company's control, retention period, access owner, security restrictions, privacy review, export process, and incident retrieval process. If the vendor hosts logs, record whether the contract and admin tools allow the team to retrieve what it needs.

Logs should support real questions: what system was used, by whom, for what workflow, with which input or configuration, what output was produced, whether a human reviewed it, and what action followed. Avoid promising logs that the product cannot actually produce.

8. Manage workplace and individual notices

Before putting a high-risk AI system into service at the workplace, employer deployers must inform workers' representatives and affected workers where applicable. That notice should be planned before the system is enabled, not after employees discover it through a workflow change.

Some deployers also need to inform people when they are subject to certain AI-assisted decisions or AI interactions, depending on the system and Article 50 transparency rules. The checklist should identify whether customers, employees, applicants, users, or other affected people need notice, what the notice says, where it appears, and who approves updates.

Keep notices consistent with the provider instructions and product reality. If the notice says a human reviews every decision, the workflow and logs should prove that.

9. Check impact assessment triggers

Article 27 creates fundamental rights impact assessment duties for certain deployers of high-risk AI systems. Separately, Article 26 points deployers toward using provider information to support data protection impact assessment duties under GDPR where applicable.

Do not treat these assessments as automatic for every AI tool, but do not bury the question either. Record whether a fundamental rights impact assessment is required, whether a data protection impact assessment is required, who decided, what facts were considered, and when the decision must be reopened.

Triggers include a high-risk system entering employment, access to essential services, education, law enforcement, migration, democratic processes, or another sensitive context; new categories of affected people; increased automation; reduced human review; or a material change in input data or intended purpose.

10. Build the deployer evidence pack

A useful evidence pack is organized around decisions. Keep the role analysis, classification record, provider instructions, approved use case, human oversight assignment, training evidence, input data controls, monitoring plan, log retention rule, notices, impact assessment decision, vendor contacts, incident route, and reassessment triggers.

The pack should be short enough to maintain but complete enough for a customer, auditor, regulator, or executive review. If the evidence lives across five tools, add an index that points to the authoritative record. The goal is not to collect files; it is to make the deployer decision explainable and repeatable.

11. Set reassessment triggers

Reopen the checklist when the provider changes instructions, the system version changes, the workflow expands, a new customer segment is added, input data changes, human review decreases, automation increases, complaints rise, logs become unavailable, incidents occur, official guidance changes, or the team starts using the output for a more consequential decision.

Add those triggers to product release review, vendor review, customer implementation, security incident response, and privacy intake. A deployer record that is correct only on launch day will not protect a fast-moving SaaS team for long.

Common mistakes

The first mistake is assuming deployer obligations are lighter because the vendor is the provider. Provider instructions matter, but the deployer still controls how the system is used in the real workflow.

The second mistake is assigning human oversight without authority. A reviewer who cannot override, pause, or escalate the output is not a useful control.

The third mistake is forgetting logs until after an incident. If logs are unavailable, too short-lived, or inaccessible, the team may not be able to explain what happened.

The fourth mistake is treating notices and impact assessments as legal paperwork disconnected from product configuration. They need to match the live system.

FAQ

What is the practical purpose of deployer obligations?

The practical purpose is to make sure the team using a high-risk AI system can show it followed provider instructions, assigned competent oversight, monitored live use, controlled input data where relevant, kept logs, managed notices, and escalated risks.

When does deployer obligations apply to SaaS teams?

Deployer obligations can apply when a SaaS team uses an AI system under its authority in a business workflow, especially where the system is high-risk or used in customer, employee, applicant, fraud, safety, or operational decisions.

What should teams document or change first?

Start with one deployer-obligations record per AI workflow. Capture role, classification, provider instructions, approved use, oversight owner, monitoring evidence, logs, notices, impact assessment decision, incident route, and reassessment triggers.

Who should own the checklist?

Product owns the workflow facts, operations owns day-to-day use, security owns logging and access evidence, legal and compliance own interpretation and evidence standards, and a named business owner should make sure unresolved blockers are closed before launch.

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 AI Act Service Desk, Article 27: Fundamental rights impact assessment for high-risk AI systems.
• European Commission AI Act Service Desk, Article 50: Transparency obligations for providers and deployers of certain AI systems.
• European Commission AI Act Service Desk, Article 4: AI literacy.