Article 50 of the EU AI Act has applied since 2 August 2026. For software companies, its immediate effect appears in chat interfaces, voice agents, automated emails, generated documents, output metadata, editorial approval and release testing.

The obligations depend on who provides the AI system, who deploys it, whether a person interacts with it and where its output goes. A single B2B workflow can therefore contain steps that require disclosure or machine-readable marking alongside internal machine-to-machine steps that fall outside those requirements.

The practical task is to classify each interaction and output, then place the required controls into the product.

What Article 50 changes in practice

• Chatbots, voice assistants and agents need an explicit identity no later than the first human interaction.
  
• Agents communicating externally need to identify who they represent during correspondence, purchases, bookings or negotiations.
  
• Covered generated content needs machine-readable marking and detection, in addition to any visible disclosure.
  
• B2B status alone provides no exemption - meaning AI-generated emails, proposals and reports produced by a B2B software product are not automatically exempt from marking. The provider must assess these product outputs under Article 50(2). Only strictly technical outputs confined to a predefined professional group in controlled provider and deployer environments can use the narrow B2B exception.
  
• Deployers need disclosure and approval paths for deepfakes and certain public-interest text.
  
• Transparency becomes a release requirement with acceptance criteria and regression tests.

The European Commission’s current AI Act timeline confirms that Article 50 applies from 2 August 2026. The AI Omnibus moved the high-risk rules for Annex III systems to 2 December 2027 and those for regulated products under Annex I to 2 August 2028.

Providers of generative AI systems already on the market before 2 August 2026 have until 2 December 2026 for the machine-readable marking and detection requirement in Article 50(2). The Commission’s Article 50 guidelines state that this transition does not extend the deadline for disclosing direct interaction with an AI system.

Six implementation actions for software companies

The six sections below describe the implementation actions needed to apply Article 50 to an existing software product.

1. Determine the company’s role for each AI feature

Article 50 assigns obligations to providers and deployers, and a company may hold both roles across one product. A provider develops an AI system, or has it developed, and places it on the EU market or puts it into service under its name. A deployer uses a system under its authority for professional purposes, taking responsibility for why it is used and how its outputs are handled.

This has a direct effect on products built on third-party models. A B2B platform that integrates a model API into a customer-facing agent may become the provider of the resulting AI system, even though another company supplies the model. The same platform may be a deployer when its finance team uses an off-the-shelf AI tool internally.

The feature register should record the system presented to users, the underlying model, the company placing it into service, its intended users, channels and output destinations. Blocshop’s article on AI agents in B2B software examines the wider product changes involved.

2. Add disclosure to every human-facing channel

Article 50(1) covers chatbots, voice systems, avatars, agents and systems communicating through email or other responsive channels.

Rule-based responses and systems collecting information without a responsive exchange fall outside this specific obligation.

The disclosure must be clear, distinguishable and accessible, and it must appear no later than the first interaction. The Commission expressly treats a notice hidden in terms of use or several layers below the interface as insufficient.

In the product, this creates channel-specific work:

• Chat: place the disclosure beside the interface or in the first message.
• Voice and telephone: play a spoken disclosure at the start and repeat it after a material change of role.
• Email and messaging: identify the artificial sender and state who the agent represents.
• Multilingual products: include the disclosure in every supported language and test its accessibility.

An AI badge elsewhere in the product does not cover every channel. A supplier receiving an agent email may never have seen the disclosure shown in the web application.

Blocshop’s framework for agent identity, delegation, approvals and auditability provides the related control structure for connecting each agent communication to an authorised customer, a defined scope and a recorded result.

3. Classify each output and implement marking

Article 50(2) requires providers of systems that generate or manipulate synthetic text, audio, images or video to mark covered outputs in a machine-readable format and make them detectable as artificially generated or manipulated.

A visible label does not satisfy this technical requirement by itself. The official Article 50 text requires effective, interoperable, robust and reliable measures. Possible components include watermarks, metadata and cryptographic provenance, supported by a corresponding detector.

Before selecting a marking method, the team should classify each output through three questions:

1. Is the output intended to be perceived, interpreted or acted on by a person?
2. Is it source code, an API payload, a machine-only message or an intermediate result retained inside a closed production process?
3. If it is technical B2B output, does it meet every condition of the limited B2B exception?
   

The Commission places source code, SDKs, SQL, infrastructure-as-code, JSON, APIs and exclusively machine-to-machine outputs outside the marking requirement. A final report, media file or outbound message intended for a person requires a separate assessment.

Marking must remain available after conversion into PDF, image resizing, audio encoding, export or delivery through another service. QA should test the final item received by the user and confirm that the selected detector still identifies it.

4. Document any B2B exception by workflow

The Commission recognises limited industrial and business-to-business cases where marking and detection may provide little transparency benefit. All three conditions must be present:

1. The output is strictly technical, such as an engineering design, production instruction, predictive-maintenance result or internal documentation used before a final result is released.
   
2. Only a limited and predefined group of people acting professionally within the provider and deployer organisations is intended to perceive and process it.
   
3. The output is not intended for external use or sharing, with safeguards such as cloud isolation or role-based controls addressing foreseeable misuse.
   

A generated customer proposal, account summary, support response or report shared outside that controlled group is unlikely to satisfy the test. The product team should record why an output class qualifies, who may receive it, how external distribution is prevented and what event would require the decision to be reviewed.

Practical example:

A B2B CRM platform includes an AI feature that generates a renewal proposal as a PDF using the customer’s contract, usage and pricing data. An account manager reviews the figures and sends the PDF to the client.

The CRM vendor is the provider of the AI system. The generated proposal is a product output intended to leave the controlled platform and be read by people outside a restricted technical group. It therefore cannot use the narrow B2B exception merely because both sender and recipient are companies. The CRM vendor must assess how to make the PDF machine-readably marked and detectable as AI-generated under Article 50(2).

This does not mean the proposal must visibly say “written by AI.” Visible disclosure and machine-readable marking are separate obligations.

By contrast, an AI-generated equipment-failure report available only to named engineers inside an access-controlled industrial platform may qualify for the B2B exception if it is strictly technical and protected against wider distribution. European Commission guidance

5. Apply the requirements across the complete workflow

Consider an invoice-reconciliation agent operating inside a customer’s finance platform.

1. The agent retrieves invoices and payment records through internal APIs. These machine-to-machine requests do not create a direct human-interaction disclosure, and the API payloads are outside the marking requirement when they remain machine-readable and are not exposed to people.
   
2. The agent produces a JSON exception record for the workflow engine. The output remains machine-only, while the platform should still retain the agent identity, system version and workflow reference for operational auditability.
   
3. The agent asks a finance employee to resolve an ambiguous payment. The chat or task interface must identify the AI system at the first interaction. The employee should also see which records the agent used and what action it is requesting.
   
4. The agent sends a supplier an email proposing a reconciliation. The message should identify the sender as AI and state which customer it represents. Because the generated text reaches an external person, the provider must also assess and implement the Article 50(2) marking and detection requirement.
   
5. The approved reconciliation updates the accounting record. The platform should connect the human approval, agent request and final state change, following the same permission and audit controls that apply to the underlying business workflow.

This sequence shows why Article 50 cannot be implemented as one global AI label. The requirement changes as information moves from internal processing to a human interaction and then to external communication.

6. Assign ownership and add release controls

An Article 50 review should produce owned implementation work. The delivery plan should assign:

• Product ownership for role classification, audiences and approved output routes.
• Frontend and channel ownership for disclosures across chat, voice, email, messaging and supported languages.
• Backend ownership for output classification, marking, detection, agent identity and version records.
• Content ownership for deepfake disclosure and human review of public-interest text where the company acts as deployer.
• QA ownership for first-interaction tests, accessibility, metadata persistence and detector results across exports.
• Vendor ownership for confirming what the model or media supplier provides, what is passed through its API and which obligations remain with the product company.

The voluntary EU Code of Practice on Transparency of AI-Generated Content provides a Union-wide method for demonstrating compliance with Article 50(2), (4) and (5). Companies using other measures must be ready to show how they meet the requirements.

Article 50 also operates alongside privacy rules. Where the workflow processes personal data, the system must address purpose, access, retention and lawful handling. Blocshop’s analysis of AI and GDPR covers this adjacent part of product and data design.

Implement Article 50 in an existing product

Once the legal and product teams have determined which Article 50 obligations apply, the difficult part is making those decisions enforceable across an established software platform.

That requires tracing where AI-generated content enters and leaves the system, distinguishing machine-only processing from human-facing communication, preserving provenance through APIs and export pipelines, and recording enough technical context to reconstruct what the system produced, for whom and under which model or agent version.

Blocshop’s senior developers help implement these controls in existing .NET, Java, Azure, AWS, API and data environments. The work can include extending output schemas with provenance metadata, applying machine-readable marks to supported document and media formats, ensuring those marks survive conversion and download, connecting third-party AI services to existing identity and permission systems, and adding the approval records, logs and automated release tests required for reliable operation and audit (see Blocshop’s AI integration and LLM API development services).

If your platform already uses chatbots, AI agents, generated reports or synthetic media, book a discovery meeting with Blocshop to review the technical changes required across its data flows, integrations and control layer.