Since August 2, 2026, the transparency obligations under Article 50 of the European Artificial Intelligence Act have been applicable, and national authorities can enforce compliance. In Spain, that authority is AESIA.

In the months leading up to the summer, there was some confusion because the AI Omnibus delayed part of the regulation’s timeline, and many companies assumed that the extension also applied to them. For most of them, it does not.

This article explains what came into force, what was delayed, and what it means in terms of architecture for a team that already has AI features in production.

Regulation (EU) 2026/1744, known as the AI Omnibus, entered into force on July 27, 2026, and postponed the obligations for high-risk systems under Annex III until December 2, 2027. This is the delay that was discussed over the summer.

Article 50 was not included in that postponement and has applied since its original date. The prohibited practices under Article 5 and the obligations for general-purpose AI models also remain on their original schedule.

This is important because Article 50 has a much broader scope than the rest of the regulation. It does not depend on whether your system is high-risk: it applies to any system that falls under one of the four scenarios it covers, even if the use case is trivial.

There is only one temporary exception, which we will discuss later.

The article covers four different scenarios, each with its own obligations:

• Systems that interact with people. Chatbots, voice assistants, and conversational agents. Users must be informed that they are interacting with a machine, unless this is obvious from the context.
• Generation of synthetic content. Text, images, audio, or video generated or modified using AI. The content must include a machine-readable marking that allows third parties to detect its artificial nature.
• Emotion recognition and biometric categorisation. People exposed to the system must be informed, and the data must be processed in accordance with data protection regulations.
• Deepfakes and texts on matters of public interest. Hyper-realistic content depicting real people, places, or events must be visibly labelled. The same applies to texts published to inform the public about matters of general interest when there has been no human editorial review.

The regulation excludes systems that perform auxiliary editing functions and do not substantially alter the input content. A spell checker, a translation tool, or a formatting tool falls outside its scope.

Processes that do not produce content intended for people are also excluded: a pipeline that classifies internal tickets, an entity extractor for contracts, or a scoring system that feeds an internal dashboard.

The line becomes less clear when human review is involved. If a person edits, validates, and assumes authorship of a text generated with the help of AI, the labelling obligation under Article 50(4) no longer applies. The key is whether that review is genuine and documented, or merely a formality applied to content that is published exactly as it comes from the model.

This is the distinction that is causing the most problems, because it determines which obligations apply to you.

You are a provider if you develop the AI system and place it on the market under your own name. The technical marking obligation under Article 50(2) applies mainly to this case. 

You are a deployer if you use an AI system under your own authority. This is where the information and visible labelling obligations apply: informing users that they are interacting with AI, labelling deepfakes, and informing people who are exposed to an emotion recognition system.

Most companies that integrate AI into their product are deployers rather than providers, because they use third-party models through an API. This makes the technical work considerably simpler, although it does not eliminate it.

There is an important nuance: if you substantially modify a third-party AI system or market it under your own brand, you may be considered a provider, with all the obligations that this entails. A legal review is advisable if your product wraps a third-party model or if you have made substantial changes to an existing model.

Generative AI systems that were already on the European market before August 2, 2026, have a transitional period until December 2 to comply with the marking obligation under Article 50(2). Systems introduced on or after August 2 must comply from day one.

The transitional period only covers the machine-readable marking obligation that applies to the provider. The deployer’s obligations — informing users, labelling deepfakes, and providing notice when emotion recognition is used — have applied since August, with no transitional period.

Content published before August 2 does not need to be labelled retroactively.

The Commission published the Code of Practice on Transparency of AI-Generated Content on June 10, 2026, developed by the European AI Office together with independent experts and representatives from industry. Both the Commission and the AI Board have endorsed it as an appropriate instrument for demonstrating compliance.

Adherence is voluntary, and the obligations under Article 50 remain enforceable regardless of whether you sign up to the Code. Its practical value lies in translating an article of the regulation into concrete measures, providing a common European framework instead of twenty-seven different national interpretations.

For a company that regularly generates content using AI, aligning with the Code is the fastest way to demonstrate due diligence to an authority, client, or auditor.

In addition, on July 20 the Commission adopted its Guidelines on the application of the Article, clarifying its scope, definitions, and exceptions. This is the key reference document for determining whether a specific use case falls within its scope.

We divide the implementation into three parts:

1. The notice in the interface

This is the easiest part to implement. A support chatbot needs to indicate that the response comes from an automated system, and that notice must be placed where the user can see it before they start typing, not in the terms of use. If the system escalates to a human agent at any point, the change must be noticeable. The user has the right to know when they stop talking to the machine.

2. Provenance in the data layer

We cannot leave labelling entirely to the frontend. When information about the origin exists only in the interface, it is lost as soon as that content is passed to another consumer: a public API, a feed, or a client integration.

The fact that content is synthetic should travel with the data from the moment it is generated. In a decoupled architecture using Symfony and API Platform, this can be handled by extending the schema of your resources and propagating that metadata through serializers and event listeners that intercept domain objects before they are persisted or exposed:

The humanReviewed field determines whether Article 50(4) requires you to label a text on matters of public interest, and modelling it from the outset avoids costly manual reviews later on.

For B2B integrations, it is also advisable to expose this information in headers, so that an automated consumer can read it without having to parse the response body:

3. The auditable trail

If an authority asks about the origin of published content, you need to be able to trace the process backwards: what prompt generated it, which model and version were used, with what parameters, and who reviewed it.

The pattern that works best without affecting response times is to write the audit trail asynchronously. The application publishes the event to a queue — Pub/Sub, for example — and a consumer persists it in PostgreSQL using JSONB fields or in object storage.

When required by the sector, these audit trails are stored using immutable retention policies, so that no one can modify them during the retention period, even with administrator permissions.

A note on LLM observability tools. Langfuse and similar tools handle tracing well, but it is important to review where the prompts are stored: they may contain corporate information and sometimes personal data. Langfuse can be deployed on your own infrastructure, and in regulated environments this is often a better option than using the managed service.

If you use models through closed APIs, you cannot intervene in the generation process to insert a watermark into the text. That obligation falls on the model provider (OpenAI, Anthropic, and similar providers), while your responsibility is to propagate and preserve the provenance information that you do control.

If you deploy your own models, you enter the realm of probabilistic watermarking based on logits. It works reasonably well for long, high-entropy text, but becomes less effective for short or structured responses, or those with a restricted vocabulary, where biasing token selection can affect quality. It is worth measuring that impact before deciding whether the trade-off is worthwhile.

Penalties for non-compliance with Article 50 can reach €15 million or 3% of the company’s total worldwide annual turnover, whichever is higher.

Before it gets to that point, the more likely day-to-day risk is a different one: a corporate client includes AI Act compliance in its supplier questionnaire and rejects companies that cannot provide a clear answer. This is already happening in procurement processes, and it comes before any regulatory inspection.

A reasonable order for the next few weeks:

1. Inventory. Identify which AI systems you have in production, which ones generate content, which ones interact with people, and which ones are used only internally.
2. Classification. For each one, determine whether you act as a provider or a deployer, and which Article 50 scenario it falls under.
3. Notices first. They are the most immediate obligation, the most visible, and the least expensive to implement.
4. Provenance model. Add the relevant fields to the schema and propagate them through the API before the volume of content makes this costly. 
5. Traceability. Asynchronous ingestion and persistence, with immutability if required by your sector.
6. Document. Record your decisions and the reasons behind them. An authority values demonstrable due diligence as much as the outcome.

We work with teams that have had software in production for years and now need to incorporate these obligations without rebuilding their architecture.

Our approach is to provide the level of governance appropriate to each scale. An oversized traceability system drives up computing and storage costs without providing additional safeguards, while poorly implemented marking can degrade the quality of the product you were trying to protect.

If you are designing the architecture of your AI services or need to adapt applications and APIs that are already in production, we can review your case and propose a realistic adaptation plan.