Consentimento, idade e compliance em imagens adultas com IA

Toda conversa séria sobre um recurso de imagem adulta termina no mesmo lugar, e não é o modelo. É consentimento, idade e se você consegue provar qualquer um dos dois. Processadores de pagamento perguntam. Lojas de apps perguntam. Reguladores perguntam cada vez mais. Um recurso que não consegue responder é removido depois do lançamento, que é o momento mais caro para isso acontecer.

As duas perguntas que importam

Primeira: a pessoa retratada é adulta e concordou com isso? Segunda: a pessoa operando o seu produto é adulta? São perguntas separadas, com controles separados, e confundi-las é o erro de design mais comum nesse espaço. Uma verificação de idade do visitante não diz nada sobre a pessoa na fotografia.

Consentimento precisa ser capturado, não presumido

Uma linha nos seus termos de uso não é captura de consentimento. O que se sustenta é uma afirmação explícita, por requisição, de que quem enviou tem os direitos sobre a imagem e de que a pessoa retratada é adulta e concordou — registrada contra aquele job específico, com timestamp, e recusada pela API quando ausente.

É essa última parte que torna a coisa real em vez de decorativa. Se uma requisição sem confirmação é rejeitada na fronteira da API, então todo job processado no seu sistema carrega uma afirmação por construção. Você não está confiando que o seu próprio código de cliente fez a pergunta.

Verificação de idade dos seus usuários

Os requisitos aqui mudam rápido e divergem por jurisdição. O Online Safety Act do Reino Unido, o regime alemão de proteção de menores e uma lista crescente de estados norte-americanos impõem deveres a serviços que disponibilizam material adulto, e vários já exigem mais do que uma caixinha autodeclarada.

A implicação prática é arquitetural: coloque a verificação de idade atrás de uma interface que você possa fortalecer sem reescrever o produto. Autodeclaração hoje, um provedor de documento ou estimativa amanhã, se o seu mercado exigir. Times que fixam uma checkbox em uma dúzia de templates pagam por essa decisão duas vezes.

Usos proibidos, ditos com todas as letras

Duas proibições são inegociáveis e pertencem aos seus termos, à sua interface e à sua fiscalização: nada de menores, de forma alguma, sob nenhum pretexto; e nada de imagens de pessoas reais e identificáveis sem o consentimento delas. A segunda é o que separa um produto adulto legítimo de uma ferramenta de assédio, e é cada vez mais objeto de legislação dedicada a imagens íntimas não consensuais.

O que guardar e o que não guardar

Há uma tensão genuína aqui. Investigar abusos exige registros; privacidade e leis de proteção de dados exigem retenção mínima. A solução é separar a prova do conteúdo: guarde os metadados que comprovam o processo — que uma confirmação foi dada, quando, por qual conta — e não guarde as imagens além do que a entrega exigir.

• Reter: identificador do job, conta, timestamp, a afirmação de consentimento e o preset utilizado.
• Não reter: a foto de origem ou o resultado, além da janela curta necessária para entregá-lo.
• Registre o acesso a qualquer um desses dados, porque uma trilha de auditoria que ninguém pode inspecionar não é uma trilha de auditoria.

Moderação é decisão de produto, não algo deixado para depois

Decida antes do lançamento o que acontece quando algo dá errado: como uma denúncia chega a um humano, com que rapidez uma conta pode ser suspensa e quem responde por essa decisão às 2h da manhã. Um canal de denúncia que existe e é atendido é também, na prática, o que distingue uma plataforma que mantém seu processador de pagamento de outra que o perde.

Colocar a sequência na ordem certa

Consentimento aplicado na fronteira da API, verificação de idade atrás de uma interface substituível, usos proibidos declarados e fiscalizados, retenção mínima de imagens com retenção duradoura das provas, e um canal de denúncia que chega a uma pessoa. Nada disso é engenharia exótica. É a diferença entre um recurso que entra no ar e um que é retirado.

Perguntas frequentes