EU AI Act Article 50: A Practical Guide for Developers Using AI APIs

Your application uses an API to answer customers, write text, or generate images. Who must inform users? Who must ensure content marking? And can a Swiss company be covered?

The transparency obligations of Article 50 of the EU AI Act apply from 2 August 2026. A transition runs until 2 December 2026 for the marking obligations under Article 50(2), only for systems placed on the market before 2 August 2026.

Using a third-party model does not, by itself, determine your obligations. Your role, your application, and its use matter too.

The timeline to keep in mind

The AI Act, Regulation (EU) 2024/1689, entered into force on 1 August 2024. Its requirements apply in stages.

The final two dates reflect Regulation (EU) 2026/1744, the Digital Omnibus on AI. Delaying part of the high-risk regime does not delay all transparency obligations.

Sources: Article 113, Article 111, and the amending regulation.

Developer, provider, or deployer?

The model provider develops and markets the underlying model. The system provider develops, or has developed, an AI application and markets it or puts it into service under its own name. The deployer uses a system under its authority, excluding personal, non-professional activities.

Does your company buy an existing assistant for employees? It will generally act as a deployer. Does it commercialise its own support assistant built on a third-party API? It may be the system provider, even without training the model.

One organisation can hold several roles. Your model provider’s compliance does not automatically establish your application’s compliance.

Source: Article 3 definitions.

What Article 50 requires in practice

Inform people when they interact with AI

For systems intended to interact directly with people, providers must ensure people know they are interacting with AI, unless this is obvious in context. The information must be clear, accessible, and provided by the first interaction at the latest. Burying it in terms and conditions is a poor practical implementation.

Mark synthetic content

Providers of systems generating text, images, audio, or video must ensure machine-readable marking and detectability of artificial origin under the conditions of Article 50(2). A visible interface label and a technical mark serve different purposes.

Exceptions include certain standard editing functions. The guidelines also clarify that source code and certain outputs exclusively processed between machines, without human exposure, fall outside this obligation. A call between your server and an API does not, by itself, exclude content subsequently shown to a person.

Disclose certain uses and publications

Specific duties concern deployers of emotion recognition or biometric categorisation systems, deepfakes, and text published to inform the public on matters of public interest.

For such text, an exception applies when human review or editorial control addresses the substance and a natural or legal person assumes editorial responsibility. Spell-checking is insufficient. This exception does not remove other obligations applicable to the system.

Sources: Article 50 and the Commission FAQ.

Three situations to check in your application

These examples follow the distinctions in the Commission FAQ. They help organise your checks; they are not a compliance certification.

Can a Swiss company be covered?

Yes. Article 2 covers, among others, certain providers established outside the Union that place a system or model on the EU market. It also covers providers and deployers in third countries where their system’s outputs are used in the Union.

A Swiss AI product offered to European customers therefore needs a scope assessment. Swiss hosting does not create an automatic exemption. Exclusively Swiss activities may fall outside the EU territorial scope while remaining subject to applicable Swiss law.

The Swiss Federal Data Protection and Information Commissioner confirms that the Federal Act on Data Protection already applies to AI-based processing of personal data where its conditions are met.

Sources: Article 2 and the Commissioner’s position.

Example: a support assistant for European customers

Imagine a Swiss company commercialising its own support assistant to European businesses. The assistant uses a model API and responds directly to those businesses’ customers.

Here is a practical approach to adapt to the product:

1. Identify the roles. The Swiss company may be the system provider; its business customer may be a deployer. Document who handles each obligation.
2. Show the notice at the right time. Before the first exchange, display something such as: “You are chatting with an AI assistant. Its answers may contain errors.” Adapt the language and accessibility to the user.
3. Check output marking. Ask the provider how it works and verify whether streaming, format conversion, or export preserves it. Adding an ai_generated: true field does not, on its own, establish that the solution meets the requirements.
4. Document dependencies. Record the requested model, published route, relevant processing terms, and user notice version. Plan a fresh review when a provider changes.
5. Keep useful evidence. Retain a screenshot of the notice and verification results. Separately define application logging needs, access permissions, and retention periods.

This is an example of technical organisation. The legal classification depends on the product and its use.

Is an independent audit required?

Article 50 does not impose a general independent audit on every business using an AI API. Documentation, logging, and conformity assessment requirements for high-risk systems arise under other provisions; procedures depend on the system involved.

You may still need to answer a customer’s or security team’s questions: which model processes requests, which organisations receive data, and what information is retained? Preparing those answers makes vendor reviews easier.

Sources: Article 12, Article 26, and Article 43.

How RouterLab supports this work

RouterLab centralises access to published model routes, permissions, usage tracking, and credits. Its dashboard shows the published logical route and consumption; it does not expose detailed internal routing.

The open-source models offered by RouterLab are hosted on its infrastructure in Switzerland and Germany. Proprietary routes use external providers, depending on the selected model and route. Those providers’ processing and retention terms apply.

RouterLab does not log or durably archive prompt and response content. Its technical response cache is configured with a 10-minute time to live. It may therefore temporarily retain the content of an exchange; this is not a zero-retention promise. This duration applies to RouterLab's cache, not external providers' retention policies. Operational events and metadata are retained for usage, credits, and support.

This visibility helps describe your dependencies. It does not replace application notices, content provenance, compliance evidence, or logs specific to your use case. Legal commitments remain governed by the applicable contractual documents.

Read about our infrastructure and its boundaries and how RouterLab works.

Your starting checklist

• Identify your role for each application.
• Check territorial scope, especially for European customers.
• Test notices in human-facing interactions.
• Review content marking and transformations.
• Document providers and processing terms.
• Define useful evidence and proportionate retention.

To start with infrastructure, explore the API documentation and the model catalogue. Your application should remain understandable when its model, provider, or user journey changes.

Test your first API journey

Start a RouterLab trial, choose a model available in the trial, and follow the API guide to make a first request using synthetic data. Then inspect consumption in the dashboard and check the AI notice in your own interface. This trial helps verify integration and usage tracking; it does not establish your application's legal compliance.

---

Regulatory information verified as of 10 October 2026. This article provides general technical and regulatory information, not legal advice. Obligations depend on the system, its intended purpose, the organisation’s role, and the applicable jurisdiction.