Duty ownership

AI Act Article 50 Provider vs Deployer Duties for SaaS Teams

For document AI SaaS, Article 50 readiness fails when the vendor assumes the customer will disclose output, and the customer assumes the vendor has handled everything. The split needs to be visible in product docs, contracts, and evidence records.

Last verified: 2026-07-27. This page is operational guidance, not legal advice.

The split to make explicit

Article 50 is titled "Transparency obligations for providers and deployers of certain AI systems." That title matters. The party building or placing the AI system into service may have one duty; the party using, exposing people to, or publishing generated output may have another.

Answer first: document the role split per workflow. For a SaaS vendor, keep evidence for provider-owned controls such as interaction disclosures and machine-readable marking. For customer publication workflows, document what the deployer owns and where the contract assigns that duty.

Provider and deployer duties in document AI

ScenarioProvider-side evidenceDeployer-side evidence
Chatbot in a customer portalFirst-interaction notice, UX copy, accessibility check, release ticket.Customer deployment context, support policy, user-facing help text if customized.
Drafting assistant generating textOutput marking method, technical test results, exception decision if relied on.Internal policy for use, review workflow before publication, retained labels if output is published.
AI-generated public-interest articleSystem documentation and any marking capability made available to the customer.Publication label, editorial-control evidence, owner responsible for final publication.
Document summarizer sold to EU customersApplicability assessment, marking or exception evidence, customer documentation.Customer use-case classification, publication or sharing controls, contract acceptance.

Contract questions to answer

  1. Who is the provider and who is the deployer for each workflow?
  2. Who implements machine-readable marking for generated or manipulated content?
  3. Who displays user-facing disclosure at first interaction?
  4. Who labels deepfakes or AI-generated text published on matters of public interest?
  5. Who keeps evidence that the label or mark was present at release or publication?
  6. What happens if the customer removes metadata, changes labels, or publishes output in another system?
  7. Who updates the record when Article 50 guidance or the Code of Practice changes?
Do not bury this in procurement replies. If the answer changes by product tier, customer workflow, or publication channel, keep it in a controlled record and point contracts to the current owner.

How Compliance Glossary fits

Provider, deployer, output, disclosure, marking, deep fake, public interest, and editorial control are not casual labels. They are duty-routing terms. Compliance Glossary helps legal and product teams govern those definitions in Confluence, scan contract playbooks and customer docs stored in Confluence for inconsistent wording, and export the evidence trail.

Controlled definitions

Approve the duty-routing terms once instead of rewriting them in every contract note.

Confluence scans

Find pages where teams still say user when they mean deployer, or vendor when they mean provider.

Version history

Show who changed the role definition, why, and when counsel approved it.

CSV export

Hand procurement or counsel a current evidence record without rebuilding it manually.

Sources

Compliance for Confluence

See how Compliance for Confluence turns approved terminology into audit evidence inside Confluence.