Article 50(3) and (4) AI Act deployer disclosure requirements

What Article 50(3) and (4) require deployers to disclose

If you deploy emotion recognition, biometric categorisation, deepfake generation or AI-written text on matters of public interest, you owe the people exposed to it a clear notice, and for emotion recognition and biometric categorisation you also owe a data protection condition. Article 50(3) covers the first two uses. Deployers of emotion recognition or biometric categorisation systems must inform the people exposed to them and process the personal data involved in line with the GDPR, Regulation (EU) 2018/1725 and Directive (EU) 2016/680. The exception is a system that the law permits to detect, prevent or investigate crime. Article 50(4) covers deepfakes and public-interest text. Synthetic image, audio or video must be disclosed as artificial, and published AI-generated text on matters of public interest must be disclosed unless a human has reviewed it or exercised editorial control and a named person holds editorial responsibility. Under Article 50(5), the notice must be given at the latest at first interaction or exposure, in a clear, distinguishable and accessible form. These duties apply from 2 August 2026.

The hard part is knowing where the obligation sits. Deployers often do not realise that a vendor feature, such as a video interview score, a retail analytics module or a customer-sentiment widget, infers emotion or categorises people by biometric traits. Start with a feature-level review of every AI system in your inventory, and ask each vendor in writing whether any function performs emotion recognition or biometric categorisation. The editorial exception is also easy to claim and hard to prove. It depends on documented human review and a named editor with real responsibility, so an informal sign-off in a shared inbox will not carry the argument. Keep the review record with the publication it covers.

The exceptions for evidently artistic, creative, satirical or fictional works limit the duty to disclosing that such content exists, in a way that does not hamper enjoyment of the work. Confirm with counsel where your content falls, because the boundary between a satirical edit and a misleading deepfake is a judgment call. For the labeling practice that supports these duties, read the Commission's Code of Practice on Transparency of AI-generated Content. Section 2 covers deployers' labeling of deepfakes and AI-generated text, and each section must be signed as a whole, according to the Commission's FAQ. Confirm with the Commission and your national authority how signatory status and the code's current wording apply to your organization before relying on it.

Which systems and teams fall under Article 50(3) and (4)

Article 50(3) and (4) reach deployers, not only the providers who build the tools. The cards below show where that distinction changes the work, from vendor-supplied emotion recognition to editorial teams publishing AI-written text.

Bought emotion recognition and biometric categorisation

If your organization buys a system that infers emotions or sorts people into biometric categories, you are the deployer and owe the people exposed a notice under Article 50(3). The vendor's marketing claims do not discharge this duty. Confirm with the vendor which functions are active in your configuration, because a feature switched on in a pilot still counts. Check that the personal data processing behind the system also meets the GDPR and the EU data protection rules named in Article 50(3).

Law enforcement carve-out for crime detection

Article 50(3) excludes emotion recognition and biometric categorisation systems that are permitted by law to detect, prevent or investigate crime. This exception is narrow and depends on a legal basis, not on the purpose sounding like security work. Organizations outside law enforcement should not assume they qualify. Ask counsel to document the specific legal permission and which deployment it covers before relying on the carve-out.

Marketing and media synthetic video and audio

Creative teams that generate or manipulate images, audio or video of real people, places or events using AI are deployers of deepfakes under Article 50(4). A disclosure must reach the audience at first exposure. Track which campaign assets, social clips, voiceovers and product visuals passed through a generative tool, because agencies and freelancers often hold these files. Ask each agency to record AI use per asset so the disclosure decision can be made before publication.

Newsrooms and communications on public-interest matters

Publishers and communications teams that release AI-generated or AI-manipulated text to inform the public on matters of public interest must disclose it. The disclosure is excused only where the text has undergone human review or editorial control and a person holds editorial responsibility. Map which outlets, press releases and public statements have that named editor, because a reviewed draft without a responsible editor does not qualify.

Artistic, creative, satirical and fictional works

For evidently artistic, creative, satirical or fictional deepfakes, Article 50(4) limits the duty to disclosing that such content exists, in a way that does not hamper the work's enjoyment. Teams often read this as a blanket exemption, but it still requires a disclosure. Decide in advance how the existence notice appears for films, games, parody and art installations, and record the rationale for each classification.

Non-EU deployers whose output reaches the EU

Article 2 applies the Act to non-EU providers and deployers when the output of their AI system is used in the EU. A US or Asian agency producing a video that is published to European audiences can therefore owe the Article 50(4) disclosure. Confirm with counsel where your outputs are consumed, not only where your company is registered, and build the disclosure into the export or publishing workflow that serves EU audiences.

How the deepfake and public-interest text duties differ

The deepfake duty in Article 50(4) and the public-interest text duty in the same paragraph share one structure but differ in what the reader must be told and when a deployer is excused. For deepfakes, the deployer must disclose that image, audio or video content has been generated or manipulated by AI. The law then carves out evidently artistic, creative, satirical or fictional works: there, disclosure is limited to the existence of such content and must not hamper the enjoyment of the work. A film studio, a satirical outlet and a marketing team therefore label differently, and each should be able to show which category a given asset falls into and why.

Public-interest text follows a different test. AI-generated or manipulated text published to inform the public on matters of public interest must be disclosed, unless it has undergone human review or editorial control and a natural or legal person holds editorial responsibility for the publication. The exception turns on facts about the workflow, not on a statement of intent. Before relying on it, confirm who reviews each piece, what they check, whether they can reject or change it, and who is named as responsible for the outcome. Keep dated review records, such as ticket histories, approval steps in a content system or sign-off logs, that tie each published item to a reviewer and an editor. A policy document that says editors review everything will not satisfy an assessor if the logs show otherwise.

Section 2 of the Code of Practice on Transparency of AI-generated Content covers deployer labeling of deepfakes and AI-generated text. According to the Commission's FAQ, each section must be signed as a whole, so an organization cannot sign only the parts it likes. Ask legal counsel to confirm whether the signature commits the organization to the full labeling obligations for every content type it publishes, and check the current signatory list on the Commission's site before citing it in a compliance file. Signing the code is a voluntary route to showing good faith; it does not replace the statutory duties in Article 50(4).

How an assessor tests Article 50(3) and (4) disclosures

This table compares each deployer disclosure duty under Article 50(3) and (4) across the test approach, the evidence an assessor will ask for, and the findings that most often fail. Read each row as a checklist of what to prepare before an assessment or market surveillance inquiry, and treat the last column as the gap to close first.

Duty	What the assessor tests	Evidence requested	Common findings
Emotion recognition and biometric categorisation notices	Whether every person exposed is informed, and whether the notice comes before or at exposure	Notice wording, placement at each deployment point, timestamps of notice display, and a map of where the system runs	Notices given after exposure, or only in general privacy policies
Processing of personal data under emotion or categorisation systems	Whether processing follows GDPR, Regulation (EU) 2018/1725 and Directive (EU) 2016/680, or the crime-detection exception applies	Legal basis analysis, DPIA references, and the legal provision relied on for any law enforcement exception	Exception claimed with no statute named or no documented legal review
Deepfake labels on generated or manipulated images, audio and video	Whether each output is disclosed as artificial at the point the person meets it	Label specifications, sample outputs as published, and logs showing label presence in each channel	Labels stripped when content is exported, reposted or passed to a downstream publisher
Artistic, creative, satirical or fictional works	Whether the work is evidently of that kind and the disclosure is limited so enjoyment is not hampered	Editorial brief, classification rationale per work, and the disclosure text used	Exception applied to content that is not evidently artistic, or with no written rationale
Editorial-control records for AI-generated public-interest text	Whether a human reviewed the text, whether someone holds editorial responsibility, and whether that person is named	Review logs with reviewer identity and date, editorial policy, and the publication record linking text to its reviewer	Editorial exception claimed without a named responsible person or with review that cannot be shown
Timing of disclosures	Whether the disclosure is given at the latest at first interaction or exposure, and whether it is clear, distinguishable and accessible	Screenshots or recordings of the user journey, accessibility checks, and release records for each version	Disclosure present in documentation but not in the interface, or buried below the fold

How to implement the disclosures in order

The sequence turns Article 50(3) and (4) from a legal reading into a working set of notices, labels and records. Each step produces a document or check that the next step depends on, so the disclosures appear where people meet the content and the organization can show why each one is in place.

Inventory every affected system and output
Build a register of every AI system that performs emotion recognition or biometric categorisation, every system that generates or manipulates image, audio or video, and every workflow that produces AI-written text published to inform the public. Include vendor-supplied features and tools staff use directly, since they still fall within the deployer role. The owner of each system is named in the register. Done means every entry has a system name, an owning business unit, the output type and the channel where people encounter it.
Classify each use against the exceptions
For each entry, decide which duty applies. Emotion recognition and biometric categorisation trigger the duty to inform the people exposed, subject to the crime detection, prevention or investigation exception where national or EU law permits it. Deepfakes trigger disclosure, with the narrower rule for evidently artistic, creative, satirical or fictional works. AI-written public-interest text triggers disclosure unless human review or editorial control applies. Legal or compliance staff record the classification and reasons. Done means every entry has a documented duty or a documented exception, reviewed by someone who can speak for the legal basis.
Design the notice or label
Write the wording for each disclosure, keeping it short, plain and accurate about what the AI did. Decide the format for each channel, such as an on-screen notice, a caption on a video, a byline note on an article or a sign at a camera location. Legal review checks that the wording matches the classification from the previous step. Done means each system has an approved notice text and a mock-up showing how it appears in the product, broadcast, publication or physical space.
Place the disclosure at first exposure
Configure each notice so it is shown no later than the first interaction or exposure, in a clear, distinguishable and accessible way. Engineering or the content team implements the placement and tests it with the people who will see it, including on mobile and for users with accessibility needs. For deepfakes in artistic works, confirm that the disclosure is limited to noting the existence of the content and does not interrupt viewing. Done means test records show the notice appears before or at first exposure on every channel listed in the inventory.
Document editorial responsibility for claimed exceptions
Where the organization relies on the human review or editorial control exception for AI-written public-interest text, record who reviews each piece, what they check, and who holds editorial responsibility for publication. Keep the review trail in a system that preserves versions and authorship, so the claim can be shown later. Done means every published item that is not labeled has a linked review record naming a responsible editor, and the exception is not claimed for categories without one.
Confirm GDPR-aligned processing for biometric uses
For emotion recognition and biometric categorisation, the data protection team confirms that the personal data processing follows the GDPR, Regulation (EU) 2018/1725 and Directive (EU) 2016/680 as applicable. This check covers lawful basis, purpose limits, retention and any data protection impact assessment already completed for the system. Done means the data protection lead has signed the processing record for each biometric system, with the notice text attached.
Assign an owner and obtain sign-off
Name one accountable owner for the disclosure program, and a named owner for each system in the register. Route the register, classifications, notice texts, placement tests and editorial records to legal, data protection and the business owner for a joint sign-off. Schedule a review whenever a system, channel or output type changes. Done means a signed record exists for the whole set, and each owner can show which evidence supports their disclosures. Ask any external consultant to prepare this package, but make clear that the organization makes and signs the compliance decisions.

Evidence that shows the disclosures work

Article 50(3) and (4) duties are only as good as the records behind them. A deployer needs to show which systems were in scope, what people actually saw, how the notice wording was approved and changed, and that labels survived publication. The cards below cover the artifacts an assessor is likely to ask for and how to keep them current between reviews.

System inventory with flagged use cases

Start with a register of every AI system your organization deploys, with a flag on each one that performs emotion recognition, biometric categorisation or generates or manipulates image, audio or video content. Record the owner, the channels where the system reaches people, and the date each flag was last reviewed. An inventory that omits a marketing or internal tool is the most common gap, so ask each business unit to confirm its entries quarterly.

Captured notices and labels by channel

Keep dated screenshots or recordings of each disclosure as a person meets it: the kiosk screen, the video call banner, the website caption, the app splash message and the printed sign. Capture the full path to the point of exposure, not only the page where the text lives. An assessor will check whether the disclosure appeared at first exposure and whether it was clear and accessible on that channel.

Notice text version history

Store every version of each disclosure wording in a system that keeps change history, recording what changed, when and by whom. XWiki, for example, keeps page versions under version control and lets you compare or roll back any two versions. Link each captured notice to the exact wording version it displayed so you can show what a person saw on a given date.

Processing records for emotion and biometric data

Where a system processes emotion or biometric data, keep records that align with GDPR, Regulation (EU) 2018/1725 and Directive (EU) 2016/680, as Article 50(3) requires. Document the lawful basis, the data categories, retention periods and who can access the outputs. Confirm with your data protection officer or counsel whether any law-enforcement exception applies, since that exception changes what must be recorded.

Editorial workflow logs naming the responsible person

For AI-generated text published on matters of public interest, the exemption depends on human review and editorial responsibility. Keep logs that name the reviewer, the editorial owner who holds responsibility, the review date and the published version. Without a named person, the exemption is hard to defend, so confirm that each publication path records this before it goes live.

Export and republishing test records

Test whether labels and disclosures survive export, re-encoding, cropping, syndication and republishing, and record each result with the tool version and the date. Run the tests on the output formats your teams actually use. Repeat them after any change to the publishing pipeline, because a label that disappears in a downstream copy weakens the case that the disclosure reached people.

What meeting Article 50(3) and (4) costs

This table breaks down the cost components of meeting the deployer disclosure duties in Article 50(3) and (4), showing who is paid for each, whether it is one-time or recurring, and what pushes it up. Use it to build a quote request, since no price or duration for these duties is supplied here. The main takeaway is that most cost comes from internal review and labeling workflows rather than from the disclosure text itself.

Cost component	Who is paid or who does the work	One-time or recurring	What drives it
Internal legal and product review	Internal legal, compliance and product staff, or an outside lawyer if engaged	One-time, then recurring on change	Number of AI systems that trigger the duties and how often their use changes
Engineering work to add notices and labels	Internal engineers or an implementation partner building the disclosure in each channel	One-time build, recurring maintenance	Number of channels such as web, app, call, video and print, and how each renders labels
Editorial process changes	Editors, communications staff and reviewers who decide when text is exempt from disclosure	One-time setup, recurring operation	Volume of published text on matters of public interest and how often human review is applied
Vendor tools and licenses	Commercial labeling, content or observability vendors	Recurring license fees	Number of vendor tools in the stack and the volume of synthetic content they process
Self-hosted tooling in your environment	Internal platform team, with an implementation partner if engaged, plus infrastructure you already run	One-time setup, recurring hosting and upkeep	Hosting footprint, retention settings and staff time to maintain the tools; can reduce license spend where it replaces paid tools
Evidence upkeep	Compliance and platform staff keeping records of notices, labels, review decisions and exemptions	Recurring	Frequency of content changes and the retention period your policy sets
External legal or assessor review	Outside counsel or an independent assessor if you choose to commission one	Optional, usually per engagement	Scope of systems, number of jurisdictions and whether a regulator or customer asks for proof

Who owns the disclosures and who can help

The deployer owns the disclosure duties in Article 50(3) and (4). That means deciding where emotion recognition or biometric categorisation runs, who is exposed to it, what notice those people receive, whether a deepfake is published, and who holds editorial responsibility for AI-generated text on matters of public interest. Legal confirms which exception, if any, applies. Data protection confirms the GDPR and related processing basis. Product owns the notice placement and the user journey. Editorial owns the publication decision and the human review record.

Editorial responsibility decision: Naming the person or body that holds editorial control is a governance decision that cannot be delegated to a vendor or consultant.
Legal interpretation: Legal decides whether the artistic, creative, satirical or fictional exception or the law enforcement carve-out applies, and documents the reasoning.
Data protection basis: The data protection lead confirms how exposed persons' personal data is processed for emotion recognition or biometric categorisation.
Product notices: Product defines the wording, timing and placement of disclosures at first exposure.
Sign-off records: The accountable owner approves the disclosure design and keeps dated approvals.

Confirm internally who holds each of these roles and where the approvals are recorded before any outside party is engaged.

Open-source tools that produce disclosure evidence

Can Langfuse show which AI-generated content was published and when?

Yes, in part. Langfuse, licensed under MIT, records traces of each request, including LLM calls, retrieval steps, tool executions and custom logic, with timing, inputs, outputs, token usage and metadata. If your publishing workflow calls a model and your application logs the output with an identifier for the published item, those traces can show what was generated, when, and by which model call. Langfuse does not know whether a piece of content was actually published, so you must record the link between a trace and the published item yourself. It also does not create the visible label. Confirm with your engineers that trace retention and access controls meet your own record-keeping rules.

How does XWiki help keep disclosure notice text under control?

XWiki, licensed under LGPL-2.1-or-later, keeps every change to a page under version control, recording what changed, when and by whom. Users can compare any two versions and roll back to an earlier one. For disclosure work, this gives you a dated history of the wording used for deepfake labels, emotion recognition notices and public-interest text disclaimers, which an assessor can review. XWiki stores the text; it does not display labels in your product or publication channel. Confirm that your deployment keeps version history for the pages you rely on and that backups cover that history.

How does BookStack show who can approve public-interest text?

BookStack, licensed under MIT, gives users abilities through the roles assigned to them, and permissions can be overridden per role at the shelf, book, chapter or page level. You can therefore restrict editing and approval of disclosure policies and editorial review pages to named roles, such as an editorial lead or compliance owner. This creates a record of who holds the permission, which supports the Article 50(4) condition that someone holds editorial responsibility. BookStack does not decide who is responsible; your governance must assign that. Review role assignments on a schedule and export them as evidence.

Can garak confirm that generated text is reliable before publication?

garak, licensed under Apache-2.0, probes language models for hallucination, data leakage, prompt injection, misinformation, toxicity generation and jailbreaks. It writes a JSONL report of every attempt and evaluation, plus a hit log of attempts that found a vulnerability. Run against the model your publishing workflow uses, it gives you test evidence about whether the model tends to produce unreliable or misleading output on the kinds of prompts you expect. It does not test your specific articles, and a clean run does not replace editorial review. Treat it as one input to the human review that Article 50(4) relies on.

Do these tools add the visible deepfake or public-interest label?

No. None of Langfuse, XWiki, BookStack or garak creates the label that a person sees. Labels must be designed into the content, the interface or the publication channel, and they must be clear, distinguishable and accessible at first exposure under Article 50(5). Your engineering or publishing team builds and tests that element. These tools only produce records and test results that show the label logic, its wording and its review existed. Ask your team to document where each label is applied and to keep screenshots or test captures of it.

What evidence should a self-hosted setup keep for disclosures?

Keep evidence from each layer of the process. Traces show what was generated and when. Version history shows the wording of notices and policies over time. Role and permission exports show who could approve public-interest text. Test reports show whether the model was probed for unreliable output before use. Together these support an assessor reviewing your Article 50(3) and 50(4) duties. Your organization owns the controls; an independent assessor or auditor decides whether the evidence is sufficient. Confirm retention periods with your legal team and check them against the applicable data protection rules.

Who sets up and maintains these tools, and what does it cost?

The tools are free to download under their licenses, so cost comes from the work around them: hosting, integration, access control, backups, logging design and periodic test runs. Your internal team or a partner can carry out that work. DeployOpen plans, implements, integrates, backs up and supports self-hosted open-source platforms inside your own infrastructure, under a fixed scope agreed in writing. Ask any provider for a written scope listing the systems, integrations, retention settings and handover items. Quotes follow from that scope, and no figure is given here.

Where deployers usually fall short on these disclosures

The most frequent gap is a feature that was never announced. Emotion recognition or biometric categorisation often arrives as a switched-on option inside a vendor's video interview, customer analytics or security product, and the deployer never checks the setting. Before any such feature runs, the deployer should inventory every module that infers emotions or groups people by biometric traits, confirm whether it is enabled in each tenant, and display the Article 50(3) notice where the people exposed will see it. Keep the vendor configuration export and the notice text as evidence, and recheck both after each vendor release, since defaults can change.

Deepfake labels are often lost after publication. A label added in the editing tool can be stripped by a content management system that rebuilds captions, by a template that crops the frame, or by a social export that re-encodes the file without metadata. The closing action is to test the full publishing path with a sample asset, from creation through the CMS to the final channel, and to record what the audience actually sees. Where the artistic or fictional exception is relied on, the deployer should also write a short, dated judgment naming the work, the reason it is evidently artistic, creative, satirical or fictional, and the form of disclosure chosen, so the restraint can be defended later.

Public-interest text is commonly published with no accountable editor. Teams generate drafts for news pages, policy explainers or public health notices, and an editor approves them informally, so no one can show that human review or editorial control happened. The fix is to name an editor who holds editorial responsibility for each publication, record the review in the workflow system, and keep the version history so the review can be shown to a market surveillance authority. Notices shown after exposure are a final gap: a banner that appears once the person has already been analysed or has already read the text does not meet the timing duty in Article 50(5). Move the notice to the point of first exposure and confirm the sequence in a test session.

Questions deployers ask about Article 50(3) and (4)

When do the Article 50(3) and 50(4) deployer disclosure duties start to apply?

The duties apply from 2 August 2026, the date on which the rest of the AI Act generally begins to apply under Article 113. Article 50(5) requires the disclosures to be made at the latest at first interaction or first exposure, and in a clear, distinguishable and accessible way. Deployers who already run emotion recognition, biometric categorisation or generative content tools should treat that date as the point from which people must be informed. Confirm the current application dates against the consolidated text of the Act, since the 2026 amendment changed several dates for high-risk rules, though not the Article 50 timing.

What drives the cost of meeting Article 50(3) and (4)?

The cost depends mainly on how many systems and channels need disclosures, and on how much of the work is engineering rather than wording. Disclosure notices in interfaces, labels on generated media, editorial review workflows for public-interest text and the logs that show the notice was given all take effort. Costs recur when new tools, markets or content types are added. The Act itself does not publish a fee, so ask any provider for a quote built from a written list of systems, channels and evidence items. DeployOpen does not publish a price list, and quotes follow from the agreed written scope.

Does a vendor's compliance statement cover our obligations as a deployer?

No. A vendor's statement usually describes its own duties as a provider, such as marking machine-readable output under Article 50(2) or documenting its system. Article 50(3) and (4) place the disclosure duty on the deployer, meaning the organization that uses the system in its own activities. Ask the vendor which disclosures are built into the product, which must be configured by you, and which remain your responsibility, such as labeling a deepfake you publish or notifying people exposed to a biometric categorisation system in your premises.

Can our in-house team implement Article 50(3) and (4) alone?

Often yes, if the team owns the systems in question and has clear authority over publication workflows. The work splits into legal interpretation, product and interface changes, editorial controls and evidence collection. Legal and compliance staff usually decide which exceptions apply, while engineers build the notices and logs. Teams that lack experience with biometric or emotion recognition data, or that publish large volumes of generated content, may benefit from an outside partner to prepare systems and evidence. An independent auditor or assessor, not an implementation partner, is the party that would examine and report on the result.

What does a readiness review need from the business?

A readiness review needs a written inventory of where the organization deploys emotion recognition, biometric categorisation or generative AI, and who sees or hears the output. It also needs the legal basis for each use, any law enforcement exceptions claimed, the channels where content is published, and the names of the people who hold editorial responsibility for public-interest text. Ask for the current disclosure wording, the points at which users first encounter the system, and any existing logs or approval records. Without these inputs, a review can only describe the gap in general terms.

How do we label deepfakes and AI-generated text without spoiling artistic work?

For evidently artistic, creative, satirical or fictional works, Article 50(4) limits the disclosure to the existence of AI-generated content in a way that does not hamper enjoyment of the work. For text published to inform the public on matters of public interest, the disclosure can be skipped only where the text has undergone human review or editorial control and a person holds editorial responsibility. Document that editorial chain in your publication workflow. The Commission's code of practice FAQ explains that Section 2 covers deployers' labeling of deepfakes and AI-generated text, and that each section must be signed as a whole.

Will an auditor certify our Article 50(3) and (4) disclosures?

No independent auditor issues a certificate for Article 50 compliance in the way an ISO certification is issued. National market surveillance authorities enforce the Act, and they can examine whether disclosures were made. A consultant or implementation partner can prepare the wording, systems, logs and written justifications for each exception, and an assessor can review them if you commission an independent review. Neither the partner nor the consultant issues reports or certificates on the organization's behalf. Ask any provider to state in writing which deliverables are its work product and which are the organization's own decisions.

What evidence should we keep to show that disclosures were made?

Keep the disclosure text, the version history of that text, and records showing where and when each notice was shown. For emotion recognition and biometric categorisation, keep the notices given to exposed people and the data protection basis for processing. For deepfakes and public-interest text, keep the labels and the editorial review records. Version control and access logs help here. XWiki keeps page history that shows what changed, when and by whom, and Langfuse can trace requests in systems that call language models. Confirm with your own tools that they capture the notice itself, not only the model output.

How DeployOpen prepares disclosure systems and evidence

DeployOpen plans, builds and documents the disclosure and logging systems that a deployer of emotion recognition, biometric categorisation or deepfake-generating AI would need to show Article 50(3) and (4) compliance. We prepare the systems and evidence in your own infrastructure, while your organization owns its obligations and an independent assessor or auditor reviews them.

How we scope

We list each AI system in scope that detects emotion, categorises people biometrically, or produces deepfake images, audio or video.
We record where people are exposed to these systems and where disclosure must appear, at first exposure.
The written scope names the systems, deliverables, owners and timelines before any work starts, since engagements are fixed-scope.

How we build

We configure self-hosted platforms to capture traces of AI outputs, labeling decisions and disclosure events in your environment.
We set up version-controlled documentation for disclosure notices, editorial review steps and labeling procedures.
We run prompt-injection and misinformation probes with garak to test whether generated content and text behave as the documented controls expect.

How we hand over

We deliver the disclosure wording, labeling procedures, editorial responsibility records and access roles as documented, versioned artifacts.
We provide a log of configuration changes, test runs and trace samples that an assessor can sample during review.
Your team receives runbooks that explain which evidence supports each Article 50(3) and (4) claim and where it is stored.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
We can re-test disclosure behavior and refresh evidence when a system, model or public-interest content workflow changes.
Confirm with your legal and compliance teams how the Code of Practice on Transparency of AI-generated Content applies to your labeling obligations before you rely on any template.

Article 50(3) and (4) Deployer disclosure of emotion recognition, biometric categorisation and deepfakes