Consent, age and compliance for adult AI imagery

Every serious conversation about an adult imaging feature ends up in the same place, and it is not the model. It is consent, age, and whether you can prove either one. Payment processors ask. App stores ask. Regulators increasingly ask. A feature that cannot answer gets removed after launch, which is the most expensive moment for it to happen.

The two questions that matter

First: is the person depicted an adult who agreed to this? Second: is the person operating your product an adult? These are separate questions with separate controls, and conflating them is the most common design error in this space. An age check on the visitor says nothing about the person in the photograph.

Consent has to be captured, not assumed

A line in your terms of service is not consent capture. What holds up is an explicit, per-request affirmation that the uploader has the rights to the image and the depicted person is an adult who agreed — recorded against the specific job, with a timestamp, and refused by the API if absent.

That last part is what makes it real rather than decorative. If a request without confirmation is rejected at the API boundary, then every processed job in your system carries an affirmation by construction. You are not trusting your own client code to have asked the question.

Age assurance for your users

Requirements here are moving quickly and diverging by jurisdiction. The United Kingdom's Online Safety Act, Germany's youth protection regime and a growing list of US states all impose duties on services making adult material available, and several now demand more than a self-declared checkbox.

The practical implication is architectural: put age assurance behind an interface you can strengthen without rewriting your product. A self-declaration today, a document or estimation provider tomorrow if your market requires it. Teams that hard-code a checkbox into a dozen templates pay for that decision twice.

Prohibited uses, stated plainly

Two prohibitions are non-negotiable and belong in your terms, your interface and your enforcement: no minors, in any form, under any pretext; and no images of real, identifiable people without their consent. The second is what separates a legitimate adult product from a harassment tool, and it is increasingly the subject of dedicated legislation for non-consensual intimate imagery.

What to keep, and what not to

There is a genuine tension here. Investigating abuse wants records; privacy and data-protection law want minimal retention. The resolution is to separate the evidence from the content: keep the metadata that proves process — that a confirmation was given, when, by which account — and do not keep the imagery any longer than delivery requires.

• Retain: job identifier, account, timestamp, the consent affirmation, the preset used.
• Do not retain: the source photograph or the result, beyond the short window needed to deliver it.
• Log access to any of it, because an audit trail nobody can inspect is not an audit trail.

Moderation is a product decision, not an afterthought

Decide before launch what happens when something goes wrong: how a report reaches a human, how quickly an account can be suspended, and who owns that decision at 2am. A reporting path that exists and is answered is also, in practice, what distinguishes a platform that keeps its payment provider from one that loses it.

Getting the sequence right

Consent enforcement at the API boundary, age assurance behind a swappable interface, prohibited uses stated and enforced, minimal retention of imagery with durable retention of proof, and a reporting path that reaches a person. None of this is exotic engineering. It is the difference between a feature that ships and one that gets pulled.

Frequently asked