The EU Artificial Intelligence Act reaches its general application date on 2 August 2026. For a developer, that date is not a request to add a generic “AI-generated” badge everywhere. Map each AI system, identify provider and deployer, put Article 50 notices on the user path, preserve traceability signals, and give an authorised person a way to intervene. This article uses the consolidated Regulation (EU) 2024/1689 on EUR-Lex and the Commission’s Article 50 guidelines, checked on 28 August 2026.
This is a technical guide, not legal advice. The Act is an EU regulation with role-specific, use-specific and sector-specific rules. A product team still needs to confirm its facts, applicable national law, data-protection duties, and competent authority. The examples below are implementation patterns. They are not a legal classification of your product.
The dates that change your backlog
Article 50 transparency duties apply from 2 August 2026. A provider of a generative AI system that was placed on the market before that date has a limited transition for the Article 50(2) marking and detection duty, until 2 December 2026. The Commission says content generated and already made available before 2 August does not need to be labelled retroactively. That transition does not turn off the other Article 50 duties that apply to an in-scope system from 2 August. Keep the two dates as separate release gates.
The other dates are easy to mix up. Prohibitions, definitions and AI literacy started on 2 February 2025. Governance and general-purpose AI model obligations started on 2 August 2025. Under amended Article 113, high-risk requirements in Chapter III, Sections 1 to 3, apply to Annex III systems under Article 6(2) from 2 December 2027 and product-related systems under Article 6(1) and Annex I from 2 August 2028. Providers and deployers of high-risk systems intended for public authorities must take the necessary steps by 2 August 2030. These dates do not justify postponing controls, but Article 12 is not a general logging mandate for every chatbot in August 2026.
Use the Commission’s current AI Act overview to check the timeline. Re-check the consolidated EUR-Lex text before a release because later acts or national measures can change the work for a particular system.
Start with the role and the jurisdiction
Article 2 covers providers that place an AI system or general-purpose AI model on the Union market or put it into service in the Union, whether established in the Union or a third country. It covers deployers in the Union and third-country providers or deployers where output is used in the Union. Importers, distributors, product manufacturers and authorised representatives also appear. Article 2 excludes areas outside Union law and systems used exclusively for military, defence or national-security purposes.
Article 3 calls the organisation that develops or commissions an AI system and markets or puts it into service under its own name or trademark the provider. A deployer uses an AI system under its authority, except for personal non-professional use. A cloud vendor may provide the model while your company deploys an agent that calls it. If your company adds its name, substantially modifies a high-risk system, or changes the intended purpose so a non-high-risk system becomes high-risk, Article 25 can make it a provider. Record this value-chain decision.
Create an inventory row for each user-facing system and reusable model or service. Record its provider, deployer, intended purpose, markets, modalities, direct interaction, high-risk assessment, versions, downstream integrations and approving person. A short data-flow diagram is more useful than a product label:
person -> interface -> interaction notice -> model adapter -> output policy
-> provenance mark -> label or review -> publish
-> audit event store -> monitoring and response
Article 50 has four different engineering surfaces
The Commission’s Article 50 FAQ explains the scope and examples. Keep the duties separate in code.
| Act surface | Responsible role | Minimum product consequence |
|---|---|---|
| Direct interaction | Provider | Tell the person they are interacting with AI, unless that is obvious in the context. |
| Synthetic audio, image, video or text output | Provider | Add a machine-readable mark that enables detection of artificial generation or manipulation. |
| Emotion recognition or biometric categorisation exposure | Deployer | Inform the people exposed to the operation and handle personal data under the applicable Union rules. |
| Deepfake or public-interest generated text | Deployer | Give a clear, distinguishable disclosure at the first exposure, subject to the Article 50(4) exceptions. |
Chatbot and agent disclosure
The Commission guidelines describe four cumulative conditions for Article 50(1): the system is an AI system, it is designed for a genuine two-way exchange, the AI communicates directly rather than through a human intermediary, and the other party is a natural person. A background machine-to-machine service differs from a support agent streaming text to a customer. Treat the “obvious” exception narrowly because it removes information from the person.
Render the notice before the first model token. Make it visible in the transcript, accessible to assistive technology and stable across tool calls or a human handoff. “You are interacting with an AI assistant” is clearer than a brand name or human-looking avatar. Store its version and render result in an audit event. For voice-only interfaces, make the disclosure audible before the exchange. A later human review does not remove the initial interaction duty.
Synthetic content and provenance
Article 50(2) puts the marking duty on the provider, including a provider of a general-purpose AI system that generates synthetic audio, image, video or text. The mark must be machine-readable and enable detection of artificial generation or manipulation. The technical solution should be effective, interoperable, robust and reliable as far as technically feasible, taking account of content type, cost and the state of the art. A visible badge alone is not a machine-readable mark, and a machine-readable mark alone is not a deployer’s visible deepfake disclosure.
Exceptions cover an assistive function for standard editing, output that does not substantially alter the deployer’s input or its semantics, and systems authorised by law to detect, prevent, investigate or prosecute crime. The guidelines discuss narrower machine-to-machine and closed-loop production examples. Do not turn these into a blanket internal-tool exception. Record the scope decision and its owner.
Deepfakes and public-interest text
The deployer must disclose AI-generated or manipulated image, audio or video that constitutes a deepfake. The Commission defines it through resemblance to an existing or plausibly existing person, object, place, entity or event and a false appearance of authenticity or truthfulness. The disclosure must be perceivable without a special tool or extra action. Put “AI-generated or manipulated” next to the media, in its accessible name or in an audible cue at first exposure. For an evidently artistic, satirical or fictional work, it can be limited to the existence of the generated content without hampering enjoyment.
The separate text rule applies when generated or manipulated text is published to inform the public about a matter of public interest. Examples include politics, public administration, justice, fundamental rights, public security, public health, the environment, consumer safety, and economic, financial, scientific or cultural developments. The Article 50(4) exception requires human review or editorial control and a natural or legal person with editorial responsibility. Spell-checking is not that review. If your team cannot show substantive review and responsibility, keep the clear label.
Logging without collecting everything
Article 12 applies to high-risk AI systems when their Chapter III requirements apply. It requires technical support for automatic event recording over the system’s lifetime. Logs must support traceability appropriate to the intended purpose, including finding risk or substantial modification, Article 72 post-market monitoring, and Article 26(5) operation monitoring. For the high-risk remote biometric-identification category in Annex III point 1(a), Article 12 adds minimum fields such as use period, reference database, matching input and result verifiers.
Article 19 requires a provider to keep automatically generated logs to the extent they are under the provider’s control for a period appropriate to the intended purpose and at least six months, unless Union or national law says otherwise, especially data-protection law. Article 26(6) sets the same minimum for logs under a deployer’s control. These rules do not permit retaining raw conversations forever. Define a retention class, restrict access, encrypt the event store, and separate telemetry from content. Hash or redact inputs and outputs when raw material is unnecessary. Have the data-protection owner approve identifying fields.
A useful event envelope is:
{
"trace_id": "tr_7f3c",
"system_version": "agent-2026.08.28",
"model_id": "model-release",
"actor_role": "deployer",
"content_class": "text",
"mark_applied": true,
"label_shown": true,
"human_review": "not_required",
"override": false,
"created_at": "2026-08-28T12:00:00Z"
}
The identifiers are examples, not a prescribed EU schema. Connect notice, model version, output handling, human decision and publication without putting secrets or full transcripts in every log. For high-risk use, let provider and deployer retrieve, interpret and correlate events. The AI-agent observability guide covers trace design, metrics and redaction.
Human oversight must be operable
Article 14 concerns high-risk AI systems. Providers must design them, including suitable human-machine interface tools, so natural persons can effectively oversee them while in use. Measures must be proportionate to risk, autonomy and context. Article 14 lists practical capabilities: understand limitations, detect anomalies and unexpected performance, recognise automation bias, interpret output, disregard or override it, and interrupt the system through a stop button or similar procedure that reaches a safe state.
Article 26 makes the deployer assign oversight to people with the necessary competence, training, authority and support. “A person looked at it” is not a control if that person cannot see the evidence, reject the recommendation, or stop the action. Put the approval boundary before an irreversible side effect. Show the model output, relevant inputs, confidence or limitations supplied by the system, policy checks, and the exact action that will follow. Make reject, edit, escalate and stop distinct actions. Record who exercised the control and why, without turning the reviewer into an automatic rubber stamp.
For high-risk systems listed in Annex III point 1(a), Article 14(5) requires separate verification and confirmation by at least two competent, trained and authorised natural persons before a deployer acts on the identification, subject to the specific proportionality exception for law enforcement, migration, border control and asylum in Union or national law. This is a targeted rule, not a universal two-person requirement for every AI output.
A deployable data-flow pattern
Keep the controls in deterministic services around the model. The interaction gateway owns the first-use notice and locale. The model adapter records the selected version and normalises provider metadata. An output service classifies modality and intended destination, applies or verifies a machine-readable mark, and decides whether a visible label or substantive human review is required. A policy gate blocks publication when the required signal is absent. An approval service owns the reviewer, decision, expiry and stop path. The event store receives a minimal correlated record. A monitoring service looks for missing labels, failed marks, unreviewed public-interest text, unexpected tool calls, and stop-button failures.
Do not hide these checks inside a prompt. Only the interface can guarantee a pre-stream notice, and only an output pipeline can preserve a content mark through export. For agent permissions and untrusted tool output, use the prompt-injection and MCP security guide. For separate orchestration, policy and side-effect boundaries, see the production AI-agent architecture guide.
Monitoring and an update cadence
Treat Article 50 as a release invariant. Every build that changes a model, system prompt, interface, output renderer, export path or localization should test that an AI notice appears at the first interaction, a machine-readable mark survives download and transformation, a deepfake receives a visible disclosure, and public-interest text cannot bypass the configured review or label path. Test keyboard, screen-reader, mobile, voice and API clients because Article 50(5) requires clear and distinguishable information that follows applicable accessibility requirements.
At runtime, alert on a missing notice, failed provenance operation, label removed by a transformation, publication with human_review absent, a reviewer without authority, or a stop operation that does not reach a safe state. Review a sample of traces weekly. Review retention, access, training and model or provider changes monthly. Run a documented risk and data-flow review each quarter. Trigger an immediate review after a serious incident, a provider release, a new modality, a changed intended purpose, a substantial modification, or new Commission guidance.
This cadence is engineering practice, not a statutory interval. For high-risk systems, align risk management and post-market processes with Articles 9 and 72. Article 112 schedules evaluation of possible changes to the Article 50 list by 2 August 2028 and every four years thereafter. Keep a source register with the consolidated EUR-Lex text, Commission guidance, code status and the responsible national authority.
Release checklist
- Record provider, deployer, purpose, Union connection, modalities, users and destinations.
- Decide which Article 50 paragraph applies and preserve evidence for exceptions.
- Render the interaction notice before the first token and verify accessibility.
- Apply a machine-readable mark at the provider boundary and test it after export.
- Add first-exposure disclosures for deepfakes and public-interest text.
- Define substantive review, editorial responsibility, authority, override and safe stop.
- For high-risk scope, implement event recording, ownership, access, retention and escalation.
- Link each release to model, policy, label, reviewer and monitoring records.
- Re-check Commission and EUR-Lex sources before material releases and regulatory changes.
The official references used for this guide are the consolidated Regulation (EU) 2024/1689, the Commission’s guidelines on Article 50, Article 50 FAQ, AI Act timeline, and quick facts on transparency rules. The legal text and Commission guidance control. This article does not replace legal, privacy or sector-specific advice.