If your product has one AI feature in it, a support chatbot, a summariser, an image generator, a voice agent, a set of EU obligations became enforceable on 2 August 2026 whether or not you have an employee, server or entity in Europe. These are not the famous high-risk obligations, which got pushed to December 2027. They are the transparency duties in Article 50 of the AI Act.
Most coverage of the AI Act is written for companies with a compliance function, and it spends its length on risk classification, conformity assessments and notified bodies. For a six-person startup with a model API behind a text box, almost none of that is the live question. The live question is narrower: does a user have to be told, does the output have to be marked, and who owes the duty, you or your model vendor.
This post covers what applies to a small team shipping one AI feature: whether you are in scope, what each Article 50 paragraph requires in engineering terms, and what the transitional dates mean for something already in production. Practitioner judgement is labelled inline, and none of this is legal advice.
Quick context: where the AI Act stands in September 2026
The AI Act is Regulation (EU) 2024/1689, and it does not switch on all at once. Prohibited practices and the AI literacy duty in Article 4 applied from 2 February 2025. General-purpose AI model obligations followed in August 2025. Article 50 transparency applied from 2 August 2026, and the Commission's own FAQ confirms that date.
What confused a lot of teams this summer is that a second regulation changed the timetable while Article 50 was approaching. The Digital Omnibus on AI, Regulation (EU) 2026/1744, was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026. It deferred the standalone high-risk obligations under Annex III from 2 August 2026 to 2 December 2027, and those for regulated products under Annex I to 2 August 2028. Headlines read "EU delays AI Act". The transparency rules were not part of that delay.
1. What landed on 2 August 2026, and what moved to 2027
Separate the two cleanly, because the reporting merged them. What moved: conformity assessment, technical documentation and EU database registration for standalone high-risk systems in Annex III, covering biometric identification, critical infrastructure, education, employment, credit scoring, law enforcement, migration and justice. If you build hiring software or a credit model, you gained roughly sixteen months.
What did not move: Article 50. The Omnibus left the transparency duties and the Article 4 AI literacy duty where they were, though it reworded Article 4 so the obligation is to take appropriate measures supporting staff knowledge rather than to guarantee a level of competence. It also added documentation flexibility aimed at SMEs, with the package targeting a compliance cost reduction of at least 35 percent for smaller companies.
One transitional date matters if your feature is already live. Generative systems placed on the market before 2 August 2026 have until 2 December 2026 to meet the Article 50(2) marking obligation. That is the only breathing room in the article, it covers marking only, and it is roughly three months away.
Takeaway: if you shipped a generative feature before August, you have a December deadline for marking and no grace at all on the disclosure duties.
2. The scope question: you are in scope from Bengaluru, Singapore or Austin
Teams outside Europe routinely assume this is somebody else's regulation. Article 2 says otherwise. The Act applies to providers and deployers established in a third country where the output produced by the AI system is used in the Union. The test is where the output lands, not where you are registered or which region your workloads run in.
So a self-serve SaaS product with EU users on the free tier is in scope. So is an API whose customers embed your output in a European product. There is no revenue threshold below which it stops applying, and the only real escape is an enforced geographic restriction, and blocking EU traffic to dodge a disclosure that costs a sentence of UI copy is a bad trade.
Practitioner opinion: the useful exercise is not scope analysis but a one-page inventory: every AI feature, what it outputs, whether a human interacts with it directly, and whether the output is published. That inventory drives everything below, and it is the artefact an enterprise buyer will eventually ask for.
Takeaway: assume scope, build the inventory, and spend your time on the duties rather than arguing your way out.
3. Provider or deployer: the role decides which paragraph you owe
Article 50 splits its duties by role. Paragraphs 1 and 2 land on providers. Paragraphs 3 and 4 land on deployers. Get the role wrong and you will build the wrong control.
The common early-stage pattern is that you call somebody else's model through an API and wrap it in your own product. The widely stated reading is that you are then the provider of the AI system you built, while remaining a deployer of the underlying general-purpose model. Your vendor carries its own obligations for the model. The system your users touch is yours.
Article 25 adds a separate reclassification path for high-risk systems: putting your name or trademark on one, making a substantial modification, or changing the intended purpose so it becomes high-risk, each turns you into the provider with the full obligation set. That is not Article 50, but it is the mechanism that catches white-labelled products.
Takeaway: if users interact with a system you assembled, plan on being its provider, and do not assume your model vendor's compliance flows down to your UI.
4. Article 50(1): tell people they are talking to a machine
Providers of AI systems that interact directly with people must ensure those people are informed they are interacting with an AI system, unless it is obvious. There is a carve-out for law-enforcement systems, which almost certainly does not apply to you.
The trap is "obvious". Founders read it generously: our chat widget is clearly a bot, everyone knows. The Commission's guidance sets the standard as an average person who is reasonably well-informed, observant and circumspect, and the FAQ states the exemption is to be interpreted restrictively because it deprives people of transparency. A named assistant with a human-sounding voice and a friendly avatar is the opposite of obvious.
Article 50(5) fixes timing and manner: the information must be given clearly and distinguishably at the latest at the first interaction or exposure, and must meet accessibility requirements. A disclosure buried in a terms page or revealed on hover fails both tests. This is the cheapest obligation in the article to satisfy: a visible line at the top of the conversation, an equivalent spoken line at the start of a voice session, and a screenshot in your evidence folder.
Takeaway: put the disclosure in the first frame of the interaction, in text a screen reader reaches, and stop relying on "obvious".
5. Article 50(2): machine-readable marking, the engineering-heavy one
This is the paragraph that costs real work. Providers of AI systems generating synthetic audio, image, video or text must ensure outputs are marked in a machine-readable format and detectable as artificially generated or manipulated. The solutions must be effective, interoperable, robust and reliable as far as technically feasible.
Note the qualifier. The obligation is not to build an unbreakable watermark, it is to implement what is technically feasible and show your reasoning. Note also the exception: the duty does not apply where the system performs an assistive function for standard editing, or does not substantially alter the input data. Spell check is not caught. A feature that rewrites a user's paragraph in a different voice probably is, and that judgement is worth documenting at design time.
Machine-readable is the operative phrase. A visible "generated with AI" badge in your UI does not satisfy 50(2), because the requirement is a signal that survives the file leaving your product and can be read by a machine downstream. In practice that means signed metadata on the artefact, a watermark in the content itself, or both.
Takeaway: treat marking as a pipeline change at the point of generation, not a UI change, and write down why any exempt feature counts as standard editing.
6. Article 50(4): deepfakes and public-interest text are deployer duties
Paragraph 4 sits on deployers and has two limbs. If you deploy a system that generates or manipulates image, audio or video content constituting a deepfake, you must disclose that the content is artificially generated or manipulated. Where the work is evidently artistic, creative, satirical or fictional, the disclosure only has to be appropriate and must not hamper enjoyment of the work.
The second limb catches more startups than founders expect. Text generated or manipulated by AI and published to inform the public on matters of public interest must be disclosed, unless it has undergone human review or editorial control with a person or entity holding editorial responsibility. The FAQ is specific that this means substantive review by someone with relevant expertise and the authority to approve, alter or reject, not a superficial skim.
If you run an AI-assisted content pipeline for your own marketing, that is a question about your own site, not just your product. Practitioner opinion: the cheap and honest answer is a named reviewer with authority to reject, recorded per piece. Labelling is equally fine. The failure mode is doing neither while telling yourself an edit pass counts.
Paragraph 3 deserves a check rather than an assumption. Deployers of emotion recognition or biometric categorisation systems must inform the people exposed to them and process personal data in line with the GDPR, Regulation (EU) 2016/679. Sentiment scoring on support calls, engagement detection in a video product and tone analysis in a sales tool can all land inside those definitions even when the marketing copy calls it something friendlier. If a feature of yours does, read Article 5 first: some emotion recognition in workplace and education contexts is prohibited outright rather than merely notifiable.
Takeaway: decide per publishing surface whether you are claiming editorial control or applying a label, make the reviewer a real named person, and check paragraph 3 against your feature list rather than assuming it is somebody else's problem.
7. The Code of Practice: what signing buys, and what it does not
Article 50(7) invites codes of practice, and one now exists. The Commission published the Code of Practice on Transparency of AI-Generated Content in June 2026 and the final version of its Article 50 Guidelines in July 2026, and together with the AI Board confirmed the Code as an adequate means of demonstrating compliance with the marking and labelling duties.
The Code is voluntary and split into two independent sections, one for providers who mark content and one for deployers who label it, and you can sign either or both. Around 190 organisations signed ahead of 2 August 2026, including most frontier model vendors. Adherence is one route to demonstrating compliance; the Guidelines are explicit that equivalently adequate alternatives are also open to you.
What signing does not do is answer the engineering question. The Code avoids mandating a single technical solution and instead pushes layered approaches combining metadata, watermarking and provenance. Reporting on it notes that providers are asked to apply at least two machine-readable techniques, such as signed tamper-evident metadata alongside imperceptible watermarking, and not to give users a supported path to strip the marking.
Takeaway: read the Code as a specification even if you never sign it, because it is the clearest published statement of what a regulator currently considers adequate.
8. Why no single marking technique passes all four tests
The four adjectives in Article 50(2), effective, interoperable, robust and reliable, are not decorative, and the Code itself acknowledges that no single technique currently satisfies all of them. Understanding why tells you what to build.
Provenance metadata in the C2PA Content Credentials format is interoperable and carries a rich, signed history: what generated the asset, when, and what happened to it since. Its weakness is that it lives in the container. Re-encode the file, pass it through a platform that rewrites metadata, or take a screenshot, and the manifest is commonly gone. Pixel-domain and audio watermarks have the opposite profile: they survive screenshots, compression, resizing and cropping because they live in the content itself, but they carry little information and are weaker against deliberate attack, and published work on diffusion-based manipulation documents their failure modes under editing.
Hence the layered recommendation: signed metadata gives you interoperability and detail, a watermark gives you survivability through the screenshot path, and each covers the other's gap. Text is the hard case, with no container and no reliable perceptual watermark, which is why the Act handles published text through disclosure and editorial responsibility rather than marking.
Takeaway: implement both layers where the artefact is a file, document the limits you know about, and do not claim a robustness property your technique does not have.
9. Enforcement: who knocks, and what it costs
Enforcement sits with the national market surveillance authorities designated by member states, not with the AI Office directly. Article 50 breaches fall in the middle penalty tier of Article 99: up to 15 million euro or 3 percent of total worldwide annual turnover for the preceding financial year, whichever is higher. The top tier, 35 million euro or 7 percent, is reserved for the prohibited practices in Article 5. For SMEs and startups, the lower of the two amounts applies rather than the higher.
A percentage of a pre-revenue startup's turnover is not what should motivate you. Two other things should. These duties are unusually easy to check from outside: either the disclosure is on the screen or it is not. And enterprise procurement has already absorbed this, so an unanswerable AI transparency question stalls a deal long before any authority takes an interest.
Practitioner opinion: the realistic first-year risk for a small non-EU startup is commercial rather than regulatory, and it arrives through a buyer's questionnaire. That is good news, because the evidence a buyer wants is the evidence an authority would ask for.
Takeaway: keep dated evidence of each control, because the same folder answers a procurement reviewer and a market surveillance authority.
The obligations at a glance
| Duty | Whose | What it requires | Live from |
|---|
| Art. 50(1) interaction disclosure | Provider | Tell people they are interacting with AI unless obvious, read restrictively | 2 Aug 2026 |
| Art. 50(2) machine-readable marking | Provider | Mark synthetic audio, image, video, text as machine-detectably generated | 2 Aug 2026, or 2 Dec 2026 if already on the market |
| Art. 50(3) emotion and biometric notice | Deployer | Inform exposed persons, process data under the GDPR | 2 Aug 2026 |
| Art. 50(4) deepfake disclosure | Deployer | Disclose manipulated media, lighter form for artistic works | 2 Aug 2026 |
| Art. 50(4) public-interest text | Deployer | Disclose, unless substantive review and editorial responsibility | 2 Aug 2026 |
| Art. 50(5) manner and timing | Both | Clear, distinguishable, at first interaction, accessible | 2 Aug 2026 |
| Annex III high-risk obligations | Provider | Conformity assessment, documentation, EU registration | 2 Dec 2027 |
What to do at your stage
Pre-seed, one AI feature, no EU entity. Write the feature inventory, add the interaction disclosure to the first frame of every AI surface, and decide in writing whether each generative feature is caught by 50(2) or falls under standard editing. If any feature outputs files and shipped before August, put 2 December 2026 in the calendar now.
Seed, generative output leaving the product. Implement layered marking at the point of generation: signed C2PA-style metadata plus a watermark for images and audio. Read the Code of Practice as your specification. Decide per publishing surface whether you claim editorial control or apply a label, and name the reviewer.
Series A, or selling into regulated buyers. Add AI transparency to your questionnaire answer library before a buyer asks. Confirm your provider or deployer classification with counsel, since Article 25 can reclassify you. If anything you build touches Annex III territory such as hiring, credit or education, use the deferral to December 2027 deliberately rather than late.
If you want a second pair of eyes on what your AI features would actually have to disclose and mark, that is what an outside review is good for: reading your real pipeline against the obligations before a buyer's reviewer does it for you. MatrixGard runs a free cloud posture check covering identity, logging, data handling and recovery, and returns a written report. Start it from the cloud security checklist on the homepage.
About the author
Avinash S is the founder of MatrixGard, a fractional DevSecOps practice that acts as the cloud, infrastructure and security team for early-stage startups, funded or bootstrapped, across India, Singapore, the UAE, the US and the UK. He works on cloud cost, platform stability and security posture for teams too small for a dedicated platform hire and too exposed to keep postponing one.
Methodology note
Every regulatory claim here comes from a named public source, linked inline: Article 50 and Article 99 text from the AI Act, Regulation (EU) 2024/1689; the applicability date, the restrictive reading of the "obvious" exemption and the editorial-control test from the European Commission's Article 50 FAQ and its Guidelines on transparency of AI-generated content; the Digital Omnibus on AI, Regulation (EU) 2026/1744, and its deferral of the Annex III obligations, from law-firm analyses of the adopted text; Code of Practice details from the Commission's transparency policy page and published commentary. Technical claims about provenance metadata and watermarking come from the C2PA project and published research on watermark robustness. Judgement is labelled practitioner opinion inline, and nothing here is legal advice. No client engagements, customer names or deal outcomes appear anywhere in this post, and no figures have been estimated or invented.
