On August 2, the EU AI Act's transparency rules started applying to AI systems that interact with people, synthetic content, deepfakes, and certain biometric tools. Article 50 violations can attract fines up to €15 million or 3% of worldwide annual turnover. For SMEs, the law uses the lower of the fixed amount or percentage, but that is still a number no founder should treat as a distant problem.
We disagree with the idea that compliance means adding one sentence to a privacy policy. A disclosure that nobody sees does not fix an unlabeled AI interaction. A label added after publication does not restore machine-readable information that was stripped from an image pipeline.
The practical work begins by finding every place where AI reaches a customer, employee, candidate, or member of the public. Most companies do not have that list yet.
The rule can apply outside Europe
An Indian or American company does not automatically sit outside the EU AI Act.
The regulation covers providers placing AI systems on the EU market. It also covers providers and deployers outside the EU when an AI system's output is used in the Union. A SaaS product available to European customers, a campaign aimed at buyers in France, or an AI feature used by an EU branch may create exposure even when the development team sits elsewhere.
This is why location alone is a poor filter. The better question is where the system and its output are used.
There is another distinction that matters. A provider develops an AI system or puts it on the market under its name. A deployer uses that system in its business. The same company can be both, depending on the workflow.
If a marketing team uses an image generator, it is usually deploying someone else's system. If the company sells a branded application that generates those images for customers, it may also be the provider of that application. The obligations are not identical.
What Article 50 requires
The transparency duties cover several different situations. Treating them as one generic AI label creates gaps.
People should know when they are interacting with AI
Providers must design AI systems that interact directly with people so those people are informed they are dealing with AI, unless that fact is already obvious to a reasonably informed person in the context.
For a business, this can affect an AI sales assistant, an onboarding guide, or a voice system that answers calls. The notice should appear by the first interaction. Hiding it in terms and conditions is hard to defend as clear and timely disclosure.
Synthetic output needs machine-readable marking
Providers of systems that generate synthetic text, audio, images, or video must make the output detectable as artificially generated or manipulated. The marking needs to be machine-readable.
This is different from a caption visible to a person. It may involve content credentials, metadata, or another technical signal that downstream systems can inspect. The solution also has to survive the path from generation to storage, editing, resizing, and publication.
There is a transition detail worth noticing. Providers of synthetic-content systems placed on the market before August 2, 2026 have until December 2, 2026 to comply with this part of Article 50. That is a short implementation window, not a reason to wait until November.
Deepfakes need disclosure
Businesses deploying a system to generate or manipulate image, audio, or video that constitutes a deepfake must disclose that the content was artificially generated or manipulated.
The rule includes a limited treatment for clearly artistic, fictional, or satirical work, where disclosure can be made without spoiling the experience. It is not a broad marketing exemption.
Some public-interest text needs disclosure too
AI-generated or manipulated text published to inform the public on matters of public interest also needs disclosure. The regulation includes an exception where the content has undergone human review or editorial control and a person or legal entity holds editorial responsibility.
That exception should not become a rubber stamp. If an employee clicks approve without checking claims, sources, and meaning, the business has a workflow problem even before a regulator asks questions.
Emotion recognition and biometric categorisation create another disclosure duty. People exposed to those systems must be informed that they are operating. A quiet analytics label in an administrator dashboard will not inform the person being analysed.
A blanket AI label is the wrong fix
Some companies will respond by placing "AI may be used" in every footer. It is quick. It is also a weak substitute for understanding the product.
Over-labeling can confuse customers and train them to ignore notices. Under-labeling leaves the business exposed. The correct disclosure depends on what the system does, who encounters it, whether the company provides or deploys it, and what happens to the output.
Start with an AI system register. For every workflow, record:
-
The business owner and technical owner
-
The model or vendor being used
-
Who receives the output and in which countries
-
Whether the company is the provider, deployer, or both
-
The type of content or decision produced
-
The current disclosure and where it appears
-
What evidence is retained after publication
This is not paperwork for its own sake. It reveals the forgotten automation that creates the real risk. A team may remember the public chatbot and miss the AI voice clone used in campaign videos, or the recruitment tool inferring candidate sentiment during recorded interviews.
Build compliance into the content pipeline
Manual labels work for a handful of assets. They break when a business publishes hundreds of product descriptions, localised videos, or personalised messages each week.
The safer approach is to make disclosure part of the workflow.
An AI interaction should load the correct notice before the first exchange. Generated media should receive its machine-readable marking when it is created, then be checked again after each transformation. The publishing system should block an asset if required provenance information is missing.
Logs matter too. Keep the model name, output identifier, disclosure version, publication destination, and review decision. If a vendor changes its metadata format, the team should be able to identify which assets need another check.
Suppose a retailer has eight AI workflows across product copy, campaign images, translations, support, and internal analytics. An inventory finds that two customer-facing tools have no first-interaction notice and the social publishing pipeline removes image metadata during compression.
Fixing those three paths before the next campaign is contained work. Discovering the same problem after a platform complaint means tracing months of assets, changing production systems under pressure, and explaining the gap to customers. The expensive part is rarely the label. It is not knowing where the output went.
Buy the standard, build the control layer
Do not build a proprietary content credential format when an accepted standard and vendor implementation meet the need. Compliance improves when other systems can recognise the signal.
Custom development becomes useful around that standard. A company may need to connect model APIs with a digital asset manager, preserve metadata through image processing, insert disclosures into several product interfaces, and keep one audit trail across vendors.
That control layer should not depend on employees remembering a checklist for every asset. It should detect the content type and destination, apply the right policy, and stop publication when a required step fails.
There is an honest limitation here. The regulation is detailed, technical standards continue to develop, and a business may need qualified EU counsel to decide how a specific use case is classified. Software cannot replace that legal judgement.
But legal interpretation does not implement a banner, preserve provenance through a media pipeline, or produce evidence from five disconnected tools. Product and engineering teams still have to make the requirement work in production.
We would start with the system register, identify the highest-exposure customer workflows, and fix the first-interaction and content-marking paths before expanding the project. Compliance should become an operating capability, not a document created once and forgotten.
Axentia builds AI applications and full-stack systems with the controls, integrations, and audit trails businesses need to operate them responsibly. If your company serves EU users and you need to turn AI Act requirements into a working product plan, book a call with us. We can map the systems that need attention first.