What the ban on nudification and CSAM generation requires
The ban on nudification and child sexual abuse material generation covers AI systems, not only the words a user types into them. If your product can generate or manipulate images, video or audio of a real person, a compliance lead or product owner needs to answer one question early: is the system built and used in a way that produces intimate or sexually explicit depictions of identifiable people, or child sexual abuse material, without consent? Point (ba) of Article 5(1), inserted by Regulation (EU) 2026/1744, targets intimate imagery of an identifiable person created without that person's freely given, specific, informed, unambiguous and explicit consent. Point (bb) targets AI systems that generate or manipulate child sexual abuse material within the meaning of Directive 2011/93/EU, subject to a without-right defense under national law. The harm is direct and personal, which is why the Commission cites nudification apps as the clearest example of what the prohibition is meant to stop.
The test turns on design and deployment. Under Article 5(1a), placing such a system on the market is prohibited where this output is its intended purpose, or where it is a reasonably foreseeable and reproducible outcome without significant modification and the system lacks reasonable and adequate safeguards to prevent it and correct misuse. A deployer is caught where it uses the system for the purpose of generating such material. Article 5(1b) excludes edits that do not increase exposure of intimate parts or change depicted sexual activity. Your product team should document the intended purpose, run structured abuse testing against the image, video and audio generation paths, and record how safeguards such as input filtering, output classification and account controls respond to misuse. Confirm the exact safeguard expectations with counsel or a national authority, because the Act does not list specific technical controls.
The prohibition applies from 2 December 2026, and fines for breach can reach EUR 35 million or 7% of total worldwide annual turnover for the preceding financial year, whichever is higher (Article 99(3)). The hard part is proving safeguards, not writing a policy. Plan for a dated evidence set: the intended purpose statement, red team results from an adversarial test program, logs of blocked and escalated requests, and a record of how misuse reports lead to corrective changes. Open-source probing tools such as garak can exercise language model interfaces and produce a report of every attempt, which helps document testing, though image and audio generation paths will need additional, modality-specific testing. Tracing tools such as Langfuse can help you show what happened in each request. Ask any external testing or consulting partner to define the test scope in writing before work begins.
Which AI systems and actors fall under points (ba) and (bb)
Points (ba) and (bb) reach a narrow set of AI systems and the organizations that place them on the market or use them. Four elements decide scope: the generated content, the identifiable person or minor depicted, the absence of consent, and the purpose or foreseeable output of the system. Work through each card before deciding whether a system is caught.
Generative image, video and audio systems
Point (ba) covers systems that generate or manipulate realistic images, video, audio or similar material. Text-only models fall outside the wording, but a multimodal model or image pipeline that outputs such material does not. Map every output modality your system can produce, including edited uploads and outputs from third-party model APIs, before deciding whether the prohibition is engaged.
Nudification applications
The Commission cites nudification apps as the example this prohibition targets. An app that takes a photo of a clothed identifiable person and produces an image of their intimate parts is caught if the person has not given the required consent. Check whether the app's stated features, marketing, prompts or templates make that output the intended purpose.
Identifiable person and explicit consent
The person depicted must be identifiable, and consent must be freely given, specific, informed, unambiguous and explicit. A generic or synthetic face may fall outside the wording, but a face that a reasonable viewer could link to a real individual does not. Build consent capture and face-matching checks into any feature that accepts real person images as input.
General-purpose models exposed to users
Where a model provider's system reaches users who can prompt it for intimate or sexual imagery, the question is whether that output is a reasonably foreseeable and reproducible outcome without significant modification. If it is, and the system lacks reasonable and adequate safeguards to prevent it and correct misuse, placing it on the market is prohibited. Document the safeguards, refusal testing and misuse response, and confirm with counsel how these duties apply to your model.
Deployers who run these systems
A deployer is caught under the use limb only where it uses the system for the purpose of generating such material. Running a general image tool for marketing, for example, is not that purpose. Where a deployer configures a system to produce such material, or allows staff or customers to do so on its platform, the deployer's own purpose and controls become the question. Record the intended use, access rules and monitoring for each deployment.
CSAM and the without-right defense
Point (bb) refers to child sexual abuse material as defined in Article 2(c) and (e) of Directive 2011/93/EU, so that definition, not a company's own policy, sets scope. The prohibition also contains an exception where a without-right defense applies under national law. How that defense operates in each Member State is a matter for qualified counsel, not for the system owner's engineering team.
When a provider or deployer is caught under Article 5(1a)
A provider is caught under Article 5(1a) when it places on the market an AI system whose output falls within point (ba) or (bb) and that output is either the system's intended purpose or a reasonably foreseeable and reproducible outcome without significant modification, where the system lacks reasonable and adequate safeguards to prevent that output and to correct misuse. The test is not whether the provider intended harm. It asks whether the provider can show the safeguards it built, tested and maintains. For a provider, the practical question is what evidence exists that the model refuses requests for intimate images of identifiable people and sexual content involving minors, and that the refusals hold after fine-tuning, prompt changes and plug-in additions. Teams should record the safeguard design, the adversarial test results and the process for handling reported misuse. Security testing with a tool such as garak can produce repeatable attempt logs for that purpose, but the provider must confirm with counsel which test coverage a regulator would expect.
A deployer is caught on a different route. Under Article 5(1a)(b), the prohibition applies where the deployer uses the system for the purpose of generating such material. Ordinary use of a system that happens to be capable of this output does not meet that test, but deliberate use does, and so does configuring a deployment to produce it. Organizations that run self-hosted models should review who can access generation endpoints, which prompts and images are logged, and whether internal users have been told that these outputs are prohibited. Logs from Langfuse can show requests, outputs and metadata for each trace, which helps an investigation, but retention and access to those logs involve personal data and should be checked with the data protection officer.
Article 5(1b) excludes some edits from the prohibition: edits that do not increase the exposure of intimate parts and do not change depicted sexual activity are not treated as manipulation. The line is fact-specific. Whether a particular edit increases exposure, and whether a given depiction is of an identifiable person, can turn on the image, the instructions and the surrounding facts. Organizations should not rely on a general reading of this carve-out. They should document the edit types they permit, obtain written legal review before offering any image-editing feature that touches people, and confirm the position with the national market surveillance authority where the answer is unclear. The Commission's own guidance and the consolidated text of the Act should be read alongside that advice.
How an assessor tests the prohibition
The first question is whether the system is placed on the market for, or can reasonably be expected to produce, the prohibited output. Under Article 5(1a), the test turns on whether generating intimate imagery of identifiable people or child sexual abuse material is the intended purpose, or a reasonably foreseeable and reproducible outcome without significant modification. An assessor starts with the provider's own description of the system, its marketing and its terms of use, then compares them with what the system does when tested. Market surveillance practice on this point is still developing, so confirm the approach with the authority that supervises your product.
- Intended purpose statement: The assessor samples the instructions for use, product pages, API documentation and sales material, and looks for any description that presents nudity or sexual content of real people as a feature.
- Foreseeable misuse analysis: Request the documented misuse scenarios, the threat model and the risk assessment that considered generation of intimate images of real people.
- Reproducibility tests: The assessor may ask for test prompts and outputs showing whether the system produces the prohibited material with ordinary or lightly modified inputs.
- Common findings: Misuse analysis that never mentions identifiable people, marketing that implies undress features, and no record of adversarial testing before release.
Before engaging, check that the product documentation makes no claim the assessor could read as the prohibited purpose.
Where the prohibited output is foreseeable, placing the system on the market is only permitted if it has reasonable and adequate safeguards to prevent the output and to correct misuse. The assessor therefore tests the controls themselves: input and output filtering, refusal behavior, account controls, and the process for removing harmful content. Whether a given safeguard is adequate is a judgment the assessor makes on the evidence, so the provider should expect to show how each safeguard was tested and how often it is re-tested.
- Filter and refusal testing: Request results from red teaming of image, video and audio generation paths, including attempts to bypass refusals through rephrasing, editing and multi-step prompts.
- Safeguard design records: Samples include the safeguard architecture, classifier thresholds, the list of blocked request types and the change log for each.
- Misuse response process: Request the procedure for detecting, reporting and removing prohibited outputs, and evidence that it has run.
- Testing tools: Automated probing with tools such as garak can produce a JSONL report of every attempt and a hit log of successful attempts, which helps show the testing was systematic.
- Common findings: Safeguards tested only on direct requests, no retest after model or filter updates, and no logs of blocked attempts.
Check that each safeguard has a documented test, a result and a re-test date that follows every material change.
A deployer is caught only where it uses the system for the purpose of generating the prohibited material. The assessor therefore looks at how the system was actually used, not only at its design. Deployers that host or configure generative systems in their own infrastructure hold the logs that show use, so the assessor will sample them. Confirm with the authority how it expects deployers to demonstrate that use was not for a prohibited purpose.
- Use logs: The assessor samples prompts, outputs, timestamps, user identities and the system configuration in place at the time, drawn from the observability platform or application logs.
- Access and purpose controls: Request role assignments, approved use cases and the policy that bars generating sexual content of real people.
- Trace coverage: Tools such as Langfuse record inputs, outputs, tool calls and metadata per request, which lets the deployer show what happened in a given session. Confirm the retention period in your own configuration.
- Alert and review records: Request evidence of monitoring for flagged prompts, the review of those flags and the actions taken.
- Common findings: Logs that do not record user identity, no review of flagged events, and deployers unaware that the platform could generate such content.
Check that logs can be pulled for a specific date range and user within a short, documented period.
Assessors tend to ask for the same core set of documents from each party, and a provider and deployer that have them ready shorten the review. The list below describes what is typically requested. It is a planning aid, not a checklist published by an authority, and the authority that reviews your system may ask for more.
- Provider file: Intended purpose statement, misuse analysis, safeguard design, red-team results, change log and misuse response records.
- Deployer file: Approved use cases, role matrix, trace and log samples, flagged-event reviews and the deployer's own risk assessment.
- Link between the two: A written statement of which obligations the provider covers and which the deployer covers, so each party can show its part.
- Testing cadence: Dates of the last test of each safeguard and of the last material change to the system.
- Confirm with the authority: The format, the level of detail and the retention period it expects, and whether it requires any notice to it.
Collect these files before any request arrives, and keep the provider and deployer files separate.
How to build safeguards that hold up to a market surveillance review
The sequence below moves from defining what the system is for and what it must never produce, through testing and layered controls, to monitoring and a documented fix cycle. Each step leaves evidence a market surveillance authority can examine.
Document intended purpose and prohibited outputs
The provider writes down what the AI system is built to do, who will use it, and which outputs are off limits: non-consensual intimate imagery of identifiable people and child sexual abuse material. Product, legal and trust and safety owners sign the statement, which then becomes the baseline for every later test. Done means a versioned intended-purpose record exists, lists the prohibited output categories in plain terms, and is approved by a named owner. Because Article 5(1a) turns on whether such output is the intended purpose or a reasonably foreseeable and reproducible outcome, this record is the first document an authority will ask for.
Run adversarial testing for sexual and CSAM generation
Test the system with adversarial prompts, image and audio inputs, and multi-turn jailbreak attempts aimed at the prohibited outputs. Garak, an Apache-2.0 probe framework for language models, can run structured jailbreak and toxicity probes, and its JSONL attempt log and hit log record each attempt and any success. Teams with image or video generation capabilities need test suites matched to those modalities, which garak does not cover on its own. Confirm coverage with the tool's current documentation before relying on it. Done means every prohibited category has a documented test set, the results are archived, and any successful bypass is logged as a finding.
Implement input and output filtering and misuse controls
Engineers add classifiers and rules that screen prompts and uploaded media before generation and check outputs before they reach a user. They also restrict features that make nudification easy, such as editing a photo of a real person into a sexual context, and block requests involving minors. Controls are versioned and deployed in the production path, not only in a test environment. Done means each control has a configuration record, a test showing it blocks the cases from step two, and a documented decision on what happens to blocked requests. The authority will look for proof that these controls exist in production, so keep deployment records.
Set abuse monitoring and escalation paths
Operations teams monitor request patterns, repeated attempts from the same account, and flagged outputs, then route confirmed cases to a named escalation owner with a defined path to legal and, where required, to law enforcement reporting channels. Tracing tools such as Langfuse capture inputs, outputs, tool calls and metadata for each request, which lets reviewers reconstruct what happened. Confirm that trace retention and access rules meet your data protection obligations, since traces can contain personal data. Done means an escalation runbook exists, the on-call owner is named, and a sample incident has been walked through end to end.
Define corrections after a safeguard bypass
When a bypass is found, either in testing or in production, the team records the failure, tightens the relevant filter or model behavior, reruns the original probe and the wider test set, and confirms the fix in production. Affected accounts are reviewed and the change is recorded in the change log. Engineers should also check whether the same weakness exists in deployed copies or downstream integrations. Done means each bypass has a ticket linking the finding, the fix, the regression test result and the approval, and the intended-purpose record is updated if the scope of risk changed. Repeated bypasses in one category should trigger a review of the whole control set, not only a patch.
Evidence that shows safeguards work and stay current
Article 5(1)(ba) and (bb) turns on whether a provider's safeguards actually stop generation of prohibited output and whether misuse gets caught and corrected. The artifacts below show that story: what the system is for, how it was tested, how its controls changed, and how misuse was handled. Each one needs an owner and a refresh trigger, because a record that predates the last model or filter change proves little.
Intended-purpose statement
Article 5(1a) asks whether prohibited output is the system's intended purpose or a reasonably foreseeable and reproducible outcome. Write a statement that names the permitted uses, excludes image editing of real people and sexual content, and states what the provider will not support. Review it whenever the product's features, marketing or access model change, since an intended purpose drifts quickly in practice.
Red-team test records
Keep a dated log of adversarial prompts and image or audio edits aimed at intimate imagery and CSAM, with the input, the output and the pass or fail result. Run tests against the deployed configuration, not a development build. Ask your testers to record jailbreak attempts that split a harmful request into harmless-looking steps, because those are the attempts most likely to succeed and most likely to be missed.
Safeguard configuration and change history
Record every filter, classifier threshold, blocklist, prompt policy and access restriction, with version numbers and the reason for each change. An assessor will ask who approved a loosened threshold and when. Store configuration in version control so that a diff shows exactly what changed between two releases.
Abuse-report logs with response times
Log every user report, automated flag and law enforcement request about generated intimate or CSAM content. Capture the time of receipt, the time of containment, the account action taken and any report made to authorities under national law. Measure response times against targets you set internally, and confirm with counsel which external reporting duties apply in each member state where you operate.
Retest records after model or filter changes
Every new base model, fine-tune, filter update or change in deployment region triggers a retest against the same prompt set used before. Keep the before-and-after results side by side. A safeguard that passed in one release can fail in the next, so a retest record dated after the last change is the evidence that matters most.
Garak and Langfuse evidence exports
garak writes a JSONL report of every probe attempt and evaluation, plus a hit log of attempts that found a vulnerability, which can be archived with each test run. Langfuse traces record inputs, outputs, tool executions and metadata for production requests. Confirm that your retention settings keep both sets of records for as long as your review cycle requires, and that personal data in prompts is handled under your GDPR obligations.
What meeting this prohibition costs in money and effort
This table breaks down the cost components of keeping an AI system outside the Article 5(1)(ba) and (bb) prohibitions, who is paid for each, whether it is one-time or recurring, and what drives it up. No fee figures are supplied for this prohibition, so use the drivers and quote requests in the right-hand columns to compare written proposals. The main takeaway is that the largest recurring costs usually come from abuse review staffing and retesting after model or filter changes, not from tooling licenses.
| Cost component | One-time or recurring, and who is paid | What drives it up or down |
|---|---|---|
| Adversarial testing labor | Recurring. Internal red team or an external security testing provider, per test cycle | Number of modalities (image, video, audio), number of model versions, depth of jailbreak and edit-bypass coverage. Ask for scope in writing. |
| Filter and classifier engineering | One-time build, then recurring tuning. Internal engineers or implementation partner | Whether safeguards are built into the model, a separate classifier, or both. Reuse of existing content safety components lowers effort. |
| Consent and identity controls | One-time design, recurring operation. Product and engineering teams | Whether the system can depict identifiable people at all. Systems that block such generation by design need less ongoing review. |
| Logging and evidence storage | Recurring. Infrastructure owner, cloud or data center budget | Volume of prompts and outputs, retention period set by legal counsel, and whether logs hold personal data that needs its own safeguards. |
| Abuse review staffing | Recurring. Trust and safety staff, internal or outsourced | Request volume, flagged-output rate, required response times, and whether trained reviewers are needed for CSAM-related escalation. |
| Legal review of the without-right defense and consent language | One-time for policy text, recurring on law or product change. Counsel in each EU member state where the system is offered | Number of member states, differences in national defenses under Directive 2011/93/EU, and how often terms of use change. |
| Retesting after changes | Recurring. Testing team, triggered by each model, filter or prompt change | Release frequency, use of third-party base models, and whether regression tests are automated. Automated regression suites lower per-release cost. |
| Open-source tooling license spend | Low or none for the tools themselves. Engineering time to integrate and operate | Garak (Apache-2.0) and Langfuse (MIT) carry no license fee, but integration, hosting and staff time still apply. Confirm current license terms with each project. |
| Quote requests | Ask each provider for a written scope with testing hours, staffing model, retention period, retest triggers and named deliverables | Compare proposals on the same scope. Fixed-scope proposals show the cost of each component separately. |
Who owns the controls, who prepares evidence and who reviews it
Your organization owns the legal position under Article 5(1)(ba) and (bb). Whether a system is caught depends on facts only you can establish: whether you place a system on the EU market, whether you deploy one, what it is built to output, and whether its output is a reasonably foreseeable result that your safeguards fail to prevent. Those decisions sit with your management, legal counsel and the product or security owners who accept the residual risk. An outside partner can inform them but cannot make them.
- Scope decisions: Confirm which systems you provide and which you deploy, including third-party models you wrap in your own product.
- Safeguard design: Decide which technical and policy safeguards prevent intimate imagery and CSAM generation and how misuse is corrected.
- Accountability: Name an owner for each system who signs off on the risk position and on any exception.
- Legal interpretation: Obtain advice on consent requirements, the without-right defense under national law and reporting duties.
- Governance records: Keep the approved policy, risk acceptances and review minutes.
Check that every system in your inventory has a named owner and a documented decision on whether Article 5 applies.
An implementation partner such as DeployOpen prepares the technical work on self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. The partner builds the test harness, configures logging and tracing, and assembles the records that show how safeguards behaved. The partner does not decide whether your system is prohibited, does not accept risk on your behalf, and does not issue any finding about compliance.
- Test records: Run adversarial probes against generative systems with tools such as garak and store the JSONL reports and hit logs.
- Trace and request logging: Configure tools such as Langfuse to capture inputs, outputs, tool calls and metadata that show how a request was handled.
- Evidence mapping: Organize records in a tool such as CISO Assistant against the controls your organization selects.
- Hardening and change control: Document configuration baselines, access restrictions and the process for updating safeguards.
- Handover documentation: Explain how each record is produced so your staff can repeat the work.
Ask any partner to state in writing what it will deliver, what it will not do, and who keeps the underlying data. Engagements are typically fixed-scope, so confirm deliverables and timelines before work starts.
Independent review comes from parties that have no stake in the outcome of the system. Under the AI Act, national market surveillance authorities enforce the prohibitions for AI systems, and the AI Office has exclusive competence in certain cases under Article 75(1) as amended in 2026. Those authorities may investigate, request documentation and impose fines under Article 99. Where a voluntary assurance is sought, an external auditor or certification body may review your records, but its findings belong to it, not to your implementation partner.
- Who reviews: Market surveillance authorities for enforcement, and external auditors or certification bodies for any voluntary assessment.
- What reviewers test: Whether your scope is defined, whether safeguards exist and operate, and whether records support your claims.
- What partners cannot issue: Audit reports, attestations, certificates or statements that a system is compliant.
- Conflict limits: Do not use the same firm to design safeguards and to certify them without considering the independence rules that apply to your engagement.
- Timing: Confirm with the reviewer which records it needs and when it will examine them.
Before engaging any reviewer, ask what it will examine, what it will not examine, and whether it has a conflict with your implementation partner.
Organizations commonly outsource the technical work that is hard to staff in-house: building test suites, configuring logging, and producing repeatable evidence. They usually keep the legal interpretation, the safeguard policy and the risk decisions. The line is drawn by whether a task requires judgment that others will rely on as your position. Preparing records can be delegated; deciding that a system is lawful, or that residual risk is acceptable, cannot.
- Usually outsourced: Probe design, test execution, logging architecture and evidence packaging.
- Usually kept in-house: Scope determinations, consent and legal analysis, safeguard policy and incident decisions.
- Shared: Safeguard implementation, where the partner builds and your engineers operate and review.
- Recurring work: Re-running tests after model or configuration changes, and reviewing logs over time.
- One-time work: Initial scoping, architecture and baseline records.
When you request a quote, ask for each deliverable to be listed against one of these roles so you know who signs what.
Where providers and deployers usually fall short
Most gaps under Article 5(1)(ba) and (bb) are not exotic technical failures. They are missing decisions and unexamined assumptions: no written intended purpose, tests that skip images, safeguards that drift after updates, logs that cannot tie a prompt to an output, and no route for reporting abuse material. Each card names one gap and the check that closes it.
No documented intended purpose
The provider's intended purpose is the first thing a regulator will read, because Article 5(1a) turns on whether generating prohibited output is the purpose or a reasonably foreseeable outcome. Many teams describe a product as a photo editor or creative tool without writing down which uses are excluded and why. Confirm that the intended purpose, prohibited uses and terms of service are written, versioned and aligned with what the product actually does.
Testing text prompts only
Teams often red team the chat interface with text and assume image, video and audio pipelines are covered. Image-to-image edits, inpainting, uploaded reference photos and voice cloning can produce the prohibited output through paths the text tests never touch. Confirm that the test plan covers every input modality and every generation endpoint, and that each one has recorded results.
Safeguards not retested after updates
A filter that blocked a category of request last quarter may fail after a base model swap, a fine-tune, a prompt template change or a new release of an open-weight model. Safeguards are only evidence for the configuration that was tested. Confirm that each model, filter and system prompt change triggers a documented retest against the same probe set before release.
Logs that do not link prompts to outputs
When a complaint or regulator request arrives, the organization must show what was asked, what was generated, which model and safeguard version produced it, and what action followed. Logs that store prompts and outputs in separate systems, or drop metadata, cannot answer that question. Confirm that each generation event carries a shared trace identifier, model version, safeguard decision and timestamp, and that access to these records is restricted and retained under a documented policy.
No CSAM reporting path
Generating or manipulating child sexual abuse material is prohibited under point (bb), and operators also face reporting obligations under national law. Teams frequently have no named owner, no legal review of the report route and no preserved-evidence procedure, so a detection event stalls. Confirm who decides, how material is preserved without further distribution, which authority receives the report under the applicable national law, and how the decision is recorded.
Questions buyers ask about the 2 December 2026 start date and effort
Does the 2 December 2026 start date apply to systems already in use?
Yes, if the system is placed on the market or used in the EU on or after that date, the prohibition in points (ba) and (bb) applies to it. The prohibition applies from 2 December 2026 under Article 113 as amended by Regulation (EU) 2026/1744, so any generative tool that can produce intimate imagery of identifiable people or child sexual abuse material should be assessed before that date. Existing systems are not exempt because they were deployed earlier. Confirm the exact application rules for your role and product with counsel, and read the amending regulation's text directly. Regulation (EU) 2026/1744 on EUR-Lex is the primary source for the dates.
What drives the cost of meeting Article 5(1)(ba) and (bb)?
The main cost drivers are the number of generative systems in scope, whether you build or only deploy them, and how much control you have over the model's outputs. Engineering time goes to blocking or limiting generation pathways, adding safeguards that prevent and correct misuse, and logging decisions. Legal time goes to consent wording, national law and contracts. Testing and monitoring recur whenever a model, prompt set or filter changes, so budget for them as an ongoing cost, not a one-time project. Ask any quote to itemize scope, the systems covered, who performs testing, and which deliverables are included. DeployOpen does not publish a price list, and each engagement is quoted from a written scope.
Can our team handle Article 5(1)(ba) and (bb) work in-house?
Many teams can do the technical work in-house if they already run machine learning and security engineering functions. The harder questions are whether you can show, with evidence, that safeguards prevent and correct misuse, and whether anyone independent has tested them. Ask yourself whether your team can run adversarial tests against generation features, keep a record of every test and fix, and explain the results to counsel and to regulators. If the answer is no for any of these, an implementation partner can prepare the systems, tests and records. The organization still owns the decision and the controls, and only an independent auditor or assessor issues reports or certificates.
What do engineering and legal teams need to provide?
Engineering needs to supply a current inventory of every system that can generate or edit images, video, audio or similar material, with the model source, deployment location and the generation pathways open to users. It also needs the safeguards in place, the logs that show how they operate, and the process for handling misuse reports. Legal needs to interpret the consent standard in point (ba), review the national position for point (bb), and check customer terms, supplier contracts and acceptable use policies. Both teams should agree who signs off on the risk decision, and that decision should be documented before 2 December 2026.
Do fines under Article 99(3) apply to deployers as well as providers?
Yes, a deployer can be fined if it uses an AI system for the purpose of generating prohibited material under Article 5(1a)(b). Breaching this prohibition carries fines of up to EUR 35 million or, for an undertaking, 7% of total worldwide annual turnover for the preceding financial year, whichever is higher, under Article 99(3). Provider exposure is narrower: placing a system on the market is prohibited only where the output is its intended purpose, or a reasonably foreseeable and reproducible outcome without significant modification, and the system lacks reasonable and adequate safeguards. Deployers should review how they use third-party tools, not only who built them.
How do we confirm the without-right defense with counsel?
Ask counsel to identify the national law in each member state where you operate, because point (bb) excludes cases where a without-right defense applies under that law. Give counsel the exact definitions in Article 2(c) and (e) of Directive 2011/93/EU, the product behavior you are assessing, and the markets and user groups involved. Ask for a written opinion that states the assumptions, the jurisdictions covered and the conditions under which the view would change. Record the opinion in your compliance file and schedule a review whenever the product, market or national law changes. Do not rely on a technical team's reading of the law.
What does a DeployOpen engagement cover for this prohibition?
DeployOpen works from a written, fixed scope agreed before work starts. Within that scope, it can implement and harden self-hosted open-source platforms inside your own infrastructure, add tracing to generative workflows, and run security testing against AI systems and agents, including red teaming aimed at misuse of image and audio generation. It can then organize the test results, configuration records and logs into evidence that your legal and compliance teams can review. DeployOpen does not issue audit reports, attestations or certifications, and it does not make the legal determination about the without-right defense. Ongoing testing after launch is available as a retainer.
Which open-source tools produce evidence for misuse testing?
garak, released under Apache-2.0, probes language models for issues including toxicity generation and jailbreaks. It writes a JSONL report of every attempt and evaluation, and a hit log of attempts that found a vulnerability, which gives you a record of what was tested. Langfuse, under the MIT license, captures each trace of a request, including LLM calls, tool executions and custom logic, with inputs, outputs and metadata. Together they can show what users asked, what the system returned and how your team responded. Confirm whether a given tool covers image, video or audio generation in your version, because these tools are not designed for every modality. Langfuse observability documentation describes the tracing model in detail.
How DeployOpen prepares safeguard evidence for this prohibition
DeployOpen starts with a written, fixed scope that names the AI systems, the self-hosted platforms behind them, the environments in which they run and the safeguards to be examined. For this prohibition, that scope usually has to separate two situations: a system that is placed on the market or offered to users, and a system the client's own staff use internally. Under the Article 5(1a) conditions, the first question for each system is whether generating intimate or sexualized material is its intended purpose, or a reasonably foreseeable and reproducible outcome that the safeguards do not prevent. The client decides the answers and its counsel reviews them. DeployOpen's role is to turn those decisions into a bounded list of components, deliverables and dates before any work begins.
Inside the client's own cloud accounts, data centers or air-gapped networks, the work consists of testing and documenting the safeguards. Test plans can use garak, which probes language models for jailbreaks, toxicity generation and other failure modes and writes a JSONL report of every attempt plus a hit log of successful ones. The results show whether refusal controls hold under adversarial prompting and what happens to image or audio generation pipelines when they are pushed toward prohibited output. Configuration records for input filters, output classifiers, access controls and misuse-handling workflows are captured as files and screenshots tied to a version. Where the client wants to show how the system behaved in production, DeployOpen configures Langfuse tracing so that each request's inputs, outputs, tool calls and metadata are retained under the client's retention policy. Logging decisions, such as which fields are masked, must be agreed in advance because they affect both evidence and personal data obligations under the GDPR.
At handover, the client receives the test records, configuration baselines, trace retention settings, a change log and a short register of open findings with owners. DeployOpen does not issue reports, attestations or certifications, and it does not state whether a system falls within Article 5(1)(ba) or (bb) or whether a fine could apply. Those conclusions belong to the client's legal counsel and, where relevant, to the national market surveillance authority. Before engaging, ask the vendor to confirm which fine tier and which sources of turnover counsel will rely on, and ask the client's counsel to review the scope document, since it defines what evidence will exist.
