EU AI Act Article 50 for UK Software Companies: What AI Products Must Change Now

A UK software company can be outside the European Union and still need to care about the EU AI Act.

Since 2 August 2026, Article 50 transparency obligations have applied to certain interactive and generative AI systems. The European Commission's current guidance says providers can be established outside the EU, and the Act can also apply to third-country providers and deployers where an AI system's output is used in the Union.

For ordinary software teams, the most immediate questions are surprisingly practical:

• Does the product tell people when they are talking directly to AI?
• Does a generative system preserve machine-readable provenance where Article 50 requires it?
• If the business publishes deepfakes or certain public-interest AI text, is the required human-visible disclosure present?
• Can the company prove how those controls work?

This guide focuses on those product and architecture decisions for UK agencies, SaaS companies and development teams serving EU users. It is a technical and operational guide, not legal advice.

What changed on 2 August 2026?

Article 50 of the EU AI Act now applies.

The European Commission's Article 50 transparency guidance says the rules cover certain:

• interactive AI systems
• generative AI systems
• emotion-recognition systems
• biometric-categorisation systems
• deepfakes
• AI-generated or manipulated text published on matters of public interest

For many software companies, the first two categories are the most relevant.

A customer-service chatbot, sales AI agent, AI assistant or conversational product may need to tell a person that the interaction is with AI.

A system generating synthetic text, images, audio or video may have separate machine-readable marking obligations at the provider level.

These are different duties.

Do not reduce Article 50 to:

"Put an AI badge next to the chatbot."

A product can have several transparency responsibilities depending on what it does and whether the organisation is acting as a provider or deployer.

Can the EU AI Act apply to a UK company?

Yes, in relevant circumstances.

The AI Act's territorial scope is not limited to companies incorporated inside the EU.

The official AI Act text applies to providers placing AI systems or general-purpose AI models on the EU market or putting AI systems into service in the Union regardless of whether the provider is established in the EU or a third country.

It also covers providers and deployers established in third countries where the output produced by the AI system is used in the Union.

The Commission's current Article 50 FAQ similarly states that providers outside the EU can fall within the Act when the output of their AI system is used in the EU.

That means a UK company's assessment should be based on the actual product and market relationship, not the sentence:

"Brexit means EU technology rules cannot affect us."

A UK team selling, supplying or operating an AI product for EU use should check the scope deliberately.

Provider or deployer: which role is your company?

This distinction controls much of Article 50.

Provider

The Commission describes a provider as an organisation or person that develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark.

A software company building and selling its own branded AI support platform may therefore be acting as a provider of the AI system.

Deployer

A deployer is an organisation using an AI system under its authority for professional activity.

A retailer that buys an AI system and uses it on its website could be a deployer.

One product can involve several actors

Consider:

Foundation-model company
        ↓
API / model
        ↓
UK software company
builds branded support agent
        ↓
EU retailer
uses agent on website
        ↓
Customer
chats with agent

The responsibilities do not collapse into one actor simply because the UK software company used a third-party model API.

The foundation-model provider may have its own obligations.

The software company may have system-level responsibilities depending on how it develops, brands and supplies the AI system.

The retailer may have deployer responsibilities for how the system is used.

"We only call an AI API" is not a complete compliance analysis.

The important questions are who designed the system, whose name it is supplied under, who operates it, what output reaches EU users, and which Article 50 obligation is being assessed.

Rule 1: tell users when they are directly interacting with AI

Article 50(1) applies to providers of AI systems intended to interact directly with natural persons.

The Commission's current FAQ identifies four cumulative elements:

1. it is an AI system
2. it is designed for a genuine two-way exchange
3. the AI interacts directly with the person rather than only through a human intermediary
4. the interaction is with natural persons

Examples can include:

• customer-support chatbots
• sales qualification agents
• conversational booking assistants
• AI avatars
• voice agents
• interactive AI assistants

The Commission says people must be informed from the start of the first interaction, clearly and distinguishably, unless it is already obvious to a reasonably well-informed, observant and circumspect person that they are interacting with AI.

The Commission also says the "obvious" exception should be interpreted restrictively.

For most commercial software, explicit disclosure is simpler to engineer and easier to evidence than relying on an argument that every user should have realised the assistant was artificial.

What should an AI chatbot disclosure look like?

Article 50 does not require one magic sentence.

A robust product pattern is to make the disclosure:

• visible before or at the first conversational exchange
• written in ordinary language
• distinguishable from terms-and-conditions text
• accessible
• persistent enough that the interaction is not misleading

For example:

AI Assistant
You're chatting with an AI assistant. It can make mistakes.
A human support agent is available when needed.

The exact wording depends on the service.

The technical requirement is better represented as product state:

Conversation starts
        ↓
Has AI disclosure been presented?
        ↓
No → render disclosure accessibly
        ↓
Record disclosure version/context
        ↓
Allow AI interaction

That is stronger than adding a static footer saying:

Powered by AI

where the user may never see it.

Do background AI features need the same chatbot disclosure?

Not necessarily under Article 50(1).

The Commission says systems operating solely in the background, machine-to-machine communication, or systems without direct contact with natural persons fall outside this particular direct-interaction obligation.

For example:

Incoming email
     ↓
AI classifies support category
     ↓
Human agent receives routing result

is different from:

Customer
     ↓
AI speaks directly to customer

The first workflow can still have other legal, privacy or sector-specific requirements.

But for Article 50(1), direct AI-person interaction is a core element.

This is another reason to document architecture rather than writing one company-wide statement that says "we use AI."

Rule 2: providers of generative AI systems may need machine-readable marking

Article 50(2) addresses AI systems that generate or manipulate synthetic:

• audio
• image
• video
• text

The provider must ensure relevant outputs are marked in a machine-readable format and are detectable as artificially generated or manipulated.

The Commission says the technical solution should be effective, interoperable, robust and reliable as far as technically feasible, considering the content type, implementation cost and the generally acknowledged state of the art.

This requirement is different from a visible "AI-generated" label.

Think of two layers:

Machine-readable provenance
→ provider-side system/output responsibility

Human-visible disclosure
→ required in specific deployer/use cases

A visible label does not automatically replace machine-readable marking where Article 50(2) applies.

Likewise, an invisible machine-readable marker does not automatically satisfy a deployer's obligation to visibly disclose a deepfake.

Does every generated output require machine-readable marking?

The Commission's July 2026 guidance describes several exclusions and qualifications.

Its current FAQ says Article 50(2) marking does not apply to certain outputs such as:

• short sequences of numbers, symbols or letters
• source code
• outputs exclusively communicated machine-to-machine and processed automatically without human exposure
• certain closed-loop industrial/product-development outputs before final output
• standard editing that does not substantially alter the input or its semantics

The Commission also describes a narrow proportionality-based exemption for certain business-to-business or industrial contexts when the conditions in the guidelines are met.

Do not convert that into:

"B2B software is exempt."

It is a narrow marking exemption with conditions, not a general escape hatch from Article 50.

If a product generates customer-facing synthetic content, the provider should assess the actual output path.

A good architecture preserves provenance before you need to render it

A generative product often loses origin information too early.

Bad flow:

LLM response
   ↓
plain string
   ↓
database
   ↓
API
   ↓
website

By the time the text reaches the user, the system may no longer know:

• whether it was generated by AI
• which model/system generated it
• whether a human edited it
• whether it was substantially transformed
• which marking mechanism was applied

A stronger design preserves provenance:

Generation request
        ↓
AI system
        ↓
Generated output object
        ↓
{
  content,
  generatedByAI,
  systemVersion,
  createdAt,
  markingStatus,
  reviewStatus,
  editorialOwner
}
        ↓
Channel renderer / exporter

Do not treat this example as the EU's mandated schema.

It is an engineering pattern that makes later marking, disclosure, auditing and policy changes much easier.

Rule 3: deployers must visibly disclose deepfakes

Article 50(4) places a separate obligation on deployers using AI to generate or manipulate image, audio or video that constitutes a deepfake.

The Commission says the disclosure should occur no later than first exposure and should be clear, distinguishable and perceivable without requiring specialist tools.

That means a deployer cannot simply say:

"The provider embedded an invisible machine-readable marker, therefore we are done."

For applicable deepfake content:

Provider machine-readable mark
+
Deployer human-visible disclosure

can be two different controls.

There are specific rules for evidently artistic, creative, satirical, fictional or analogous works, so content teams should not assume every synthetic visual receives identical treatment.

Rule 4: certain public-interest AI text needs disclosure unless meaningful human review applies

Article 50(4) also addresses AI-generated or manipulated text published to inform the public on matters of public interest.

The Commission gives examples of public-interest areas including:

• politics and democratic processes
• public administration
• justice and law enforcement
• fundamental rights
• public security
• public health
• environmental protection
• consumer safety
• economic, financial, scientific or cultural developments relevant to public debate

However, the Commission's FAQ explains an important exception: text that has undergone genuine human review or editorial control and has a responsible person or entity holding editorial responsibility does not need the same AI-generated-text label under this rule.

The review has to be substantive.

The Commission says superficial checks such as grammar or spell-checking are not enough.

This has direct implications for content-management systems.

Human review should be a workflow state, not a checkbox nobody can prove

If your platform lets customers publish AI-assisted public-interest content, a sensible editorial workflow might be:

AI draft generated
      ↓
Status: AI_DRAFT
      ↓
Qualified human reviews substance
      ↓
Fact/source review
      ↓
Human may edit/reject
      ↓
Named editorial responsibility
      ↓
Status: HUMAN_REVIEWED
      ↓
Publish

Keep useful evidence such as:

• reviewer identity
• review timestamp
• version reviewed
• changes made
• approval decision
• final content hash/version where appropriate

Do not create a button called:

[Mark as human reviewed]

with no process behind it.

The value of workflow evidence is that the company can explain what "review" actually meant.

Is there a grace period after 2 August 2026?

There is a limited transition, not a blanket Article 50 grace period.

The Commission's FAQ says Article 50 applies from 2 August 2026.

For AI systems placed on the market before that date, a limited transition applies specifically to the Article 50(2) machine-readable marking and detection obligation for AI-generated content. Those systems have until 2 December 2026 for that obligation.

That should not be misread as:

"Existing chatbots can wait until December before telling users they are AI."

The Commission describes the transition specifically around Article 50(2) marking/detection for pre-existing systems.

A software team should map obligations separately rather than assigning one date to the entire regulation.

What does this mean for a UK agency building an AI chatbot for an EU client?

Consider a realistic agency project:

EU property company
        ↓
hires UK agency
        ↓
agency builds branded website chatbot
        ↓
chatbot uses third-party model API
        ↓
EU users ask about properties
        ↓
agent qualifies leads and writes to CRM

The engineering scope should now include transparency deliberately.

At minimum, investigate:

1. Role allocation — who is provider, deployer and responsible for each control?
2. First-interaction disclosure — how will the UI clearly tell the user the interaction is with AI?
3. Human handoff — can the user reach a person when the business design requires it?
4. Output provenance — which outputs are generated or manipulated by AI, and how is that metadata preserved?
5. Machine-readable marking — does Article 50(2) apply to the system/output, and how will supported content types be marked?
6. Content-use rules — are generated images/video/deepfakes or public-interest text being published?
7. Evidence — can the company demonstrate which transparency version was active?
8. Accessibility — is the disclosure accessible and perceivable?
9. Vendor responsibilities — what does the underlying model provider supply, and what remains downstream?
10. Change control — what happens when the model, system, channel or use case changes?

These are product requirements, not after-launch legal footnotes.

Do API-based AI products inherit compliance automatically from OpenAI, Google, Anthropic or another model provider?

No automatic inheritance should be assumed.

A model/API vendor may provide:

• model-level documentation
• safety capabilities
• provenance features
• contractual terms
• technical metadata
• compliance support

But the downstream product adds another layer.

The application decides:

• how users are told they are interacting with AI
• whether a human appears to be speaking when AI is actually responding
• how outputs are shown
• what content is published
• whether content is transformed
• whether provenance is preserved
• how humans review or approve output
• what the system is called and under whose brand it is supplied

The Commission's Article 50 guidance explicitly discusses expectations across the AI value chain.

So procurement should ask:

What does the upstream vendor provide, and what must our system implement itself?

That is a much better question than:

"Is the model EU AI Act compliant?"

An Article 50-ready product architecture

A practical architecture can keep transparency controls separate from model-specific code.

User / channel
      ↓
Interaction controller
      ↓
AI disclosure policy
      ↓
Model gateway
      ↓
Output + provenance metadata
      ↓
Policy / safety layer
      ↓
Content marking adapter
      ↓
Human review if required
      ↓
Channel renderer
      ↓
Audit / compliance event log

Interaction controller

Knows whether the channel is direct AI-person interaction, whether first-interaction disclosure has been presented, and whether the conversation switches between human and AI.

Model gateway

Abstracts the underlying model provider so transparency behaviour is not hard-coded to one API.

Provenance metadata

Preserves whether an output was generated or materially manipulated by AI and what processing happened afterwards.

Marking adapter

Applies appropriate machine-readable marking mechanisms for supported media/content where required.

Human-review workflow

Handles substantive review when a use case depends on human editorial control.

Audit log

Records significant transparency/compliance events without logging unnecessary personal or sensitive content.

This architecture is more maintainable than scattering:

<span>AI</span>

across several front ends and calling the product compliant.

A provider/deployer responsibility matrix

Use a project-level matrix rather than assuming the contract handles everything.

This table is illustrative, not a legal allocation. Actual roles depend on the product, contract and facts.

Its purpose is to prevent the gap where the provider assumes the deployer handles something while the deployer assumes the provider handles it.

What should developers add to the backlog this week?

For an existing customer-facing AI product used in the EU:

1. Inventory AI entry points

List web chat, messaging channels, email agents, voice, mobile assistants, support portals and AI-generated media/content tools.

2. Classify direct interactions

Identify where AI speaks directly to a natural person.

3. Verify first-interaction disclosure

For every direct channel, ask whether a new user can reasonably miss the disclosure.

4. Inventory generated content types

Record whether the product generates text, code, images, audio, video or mixed media.

5. Map output destinations

Does output stay internal, flow machine-to-machine, reach one user, get published publicly, or become marketing/editorial content?

6. Preserve provenance

Avoid flattening generated output into untraceable raw strings/files before policy decisions happen.

7. Add review state where needed

Particularly for workflows that may rely on meaningful editorial review.

8. Review upstream vendor support

Document what marking/provenance capabilities are supplied by the model or media vendor.

9. Version transparency behaviour

Record disclosure and marking policy versions alongside application releases.

10. Test accessibility

The Commission requires Article 50 information to be clear, distinguishable and compliant with applicable accessibility requirements.

What should teams not do?

Do not hide the disclosure in terms and conditions

The interaction disclosure is about informing the person at the relevant interaction.

Do not rename the AI "Sarah" and hope users infer the truth

A human-style name and profile image can make the AI nature less obvious, not more.

Do not rely only on a model provider's compliance page

Your application controls the final user experience and downstream output workflow.

Do not label every AI-assisted sentence automatically

Article 50 contains distinctions, exceptions and human-review rules. Blanket labelling can be misleading just as under-labelling can be non-compliant.

Do not strip provenance metadata during media processing without checking the consequence

Resizing, transcoding, screenshots, re-encoding and CDN pipelines can destroy marking techniques.

Test the final distributed output, not only the original model response.

Do not treat 2 December 2026 as a universal grace period

The Commission describes that limited transition specifically for Article 50(2) marking/detection for systems placed on the market before 2 August 2026.

Is the Transparency Code of Practice mandatory?

No.

The Code of Practice on Transparency of AI-generated Content is voluntary.

The underlying Article 50 obligations are not.

The Commission and AI Board have assessed the code as an adequate voluntary means of demonstrating compliance with the relevant marking and labelling obligations.

The Commission says signatories can rely on the code's measures to demonstrate compliance, while non-signatories need to demonstrate that their alternative measures are adequate.

For a smaller software company, the useful question is whether following or signing the code reduces uncertainty enough to justify the process, or whether the company can clearly document an alternative implementation.

What are the potential penalties?

The Commission's Article 50 FAQ states that fines for the relevant transparency obligations can reach €15 million or 3% of total worldwide annual turnover for the preceding financial year, with proportionality considered for SMEs and small mid-cap companies.

Maximum penalties are not the right reason to implement a tiny "AI assistant" label.

The better reason is that transparency should be part of product architecture before enforcement exposes ambiguity about who built what, who informed the user, and how synthetic output was handled.

A practical Article 50 readiness test

Score one point for each statement you can answer confidently:

This is not a legal compliance score.

It is a product-readiness check.

A low score means the system probably has important unanswered architecture and responsibility questions.

FAQs

Does the EU AI Act apply to UK software companies after Brexit?

It can. The AI Act covers providers placing AI systems on the EU market or putting them into service in the Union regardless of whether the provider is established in the EU or a third country. It can also apply to third-country providers and deployers where AI-system output is used in the Union.

Do AI chatbots have to tell users they are AI?

Article 50(1) requires providers of AI systems intended to interact directly with people to ensure users are informed they are interacting with AI unless that fact is obvious. The Commission says disclosure should occur from the start of the first interaction.

Does "Powered by AI" in the footer satisfy Article 50?

There is no universal approved phrase. The Commission requires the information to be clear and distinguishable at the relevant first interaction and accessible. A disclosure users are unlikely to see is a weak implementation.

Does every AI-generated text need an "AI-generated" visible label?

No. Article 50 distinguishes provider machine-readable marking obligations from deployer visible-disclosure obligations. For deployers, the specific text rule concerns AI-generated/manipulated text published to inform the public on matters of public interest, and the Commission describes an exception for substantive human review/editorial control with editorial responsibility.

Is source code subject to the machine-readable marking requirement?

The Commission's current Article 50 FAQ lists source code among outputs outside the Article 50(2) marking obligation described in the guidelines.

Is there a grace period until December 2026?

Only in a limited sense. Article 50 applies from 2 August 2026. The Commission describes a transition until 2 December 2026 for Article 50(2) marking/detection obligations for relevant systems placed on the market before 2 August 2026. It is not a blanket extension for every Article 50 duty.

Conclusion

For UK software companies, Article 50 is less about putting a compliance sticker on an AI feature and more about designing truthful product state.

A good system can answer:

Is the user talking to AI?
        ↓
Tell them clearly.

Was this output generated or materially manipulated by AI?
        ↓
Preserve provenance and assess required marking.

Is the business publishing a deepfake or covered public-interest text?
        ↓
Apply the deployer disclosure/review workflow.

Who was responsible?
        ↓
Keep the role and evidence clear.

The most expensive response is to bolt this onto every channel after the product has already flattened model outputs, lost provenance, mixed human and AI messages, and delegated responsibilities ambiguously between supplier and customer.

The cheaper path is to make transparency a reusable layer in the architecture.

If your company is building an AI assistant, lead-qualification agent, generative content workflow or AI-enabled SaaS product for European users, Softotic's AI and machine learning service can help design the system architecture, while custom software development can handle the application, integration and audit workflow around it.

Sources and references

• European Commission: Transparency obligations under Article 50 of the AI Act
• European Commission: Guidelines on transparency obligations for providers and deployers of certain AI systems
• AI Act Service Desk: Article 50 — Transparency obligations
• EUR-Lex: Regulation (EU) 2024/1689 — Artificial Intelligence Act
• European Commission: Code of Practice on Transparency of AI-generated Content
• European Commission: Commission starts enforcing AI Act rules and new transparency requirements on 2 August