Artigo 50 do AI Act: quando transparência vira propriedade operacional do sistema

Em 8 de maio de 2026, a Comissão Europeia publicou a minuta das diretrizes de transparência do Artigo 50 do AI Act, com consulta aberta até 3 de junho e aplicação das obrigações a partir de 2 de agosto de 2026. O texto trata de quatro situações: interação direta com sistemas de IA, conteúdo sintético gerado por IA, reconhecimento de emoções ou categorização biométrica, e deepfakes ou textos gerados por IA publicados para informar o público sobre temas de interesse público. A novidade técnica não está na existência de um aviso de “gerado por IA”. Está no fato de que a transparência passa a ser uma propriedade operacional do sistema, emitida no momento certo, no canal certo e com evidência suficiente para auditoria.

Transparência como lógica de runtime

Essa distinção muda a forma de projetar produtos de IA. Um aviso estático em termos de uso não resolve um problema que aparece dentro de uma conversa, em uma imagem exportada, em um vídeo republicado, em uma chamada de voz, em um relatório editorial ou em um fluxo automatizado que interage com pessoas fora da interface principal. O Artigo 50 exige que a informação seja clara, distinguível e acessível no máximo no momento da primeira interação ou exposição. Isso transforma transparência em lógica de runtime, não em documentação de compliance anexada depois do deploy.

Provedor e implantador: obrigações distintas na mesma cadeia

A separação entre provedor e implantador é o ponto que mais aproxima a regra da arquitetura real. O provedor do sistema que interage com pessoas precisa desenhar o sistema para informar que a interação é com IA. O provedor de sistema gerador de áudio, imagem, vídeo ou texto precisa marcar os outputs em formato legível por máquina e torná-los detectáveis como artificiais ou manipulados. Já o implantador que publica deepfake, usa reconhecimento de emoções, aplica categorização biométrica ou publica texto gerado para informar o público recebe obrigações próprias de disclosure. A mesma cadeia pode envolver todos esses papéis em momentos diferentes.

Essa divisão impede uma leitura simplista de que basta o modelo “saber” que gerou algo. Um modelo pode produzir uma imagem; uma aplicação pode recortar, comprimir, redimensionar e publicar; uma plataforma pode reencodar; um CMS pode anexar título, legenda e autoria; um editor pode revisar ou não revisar. A obrigação de marcação legível por máquina fica próxima da geração e da preservação de metadados. A obrigação de disclosure visível fica próxima da exposição ao público. A fronteira técnica relevante passa a ser o pipeline inteiro de geração, transformação e distribuição.

Código de Prática: defesa em camadas

A minuta do Código de Prática reforça essa leitura ao organizar o trabalho em dois grupos: um focado em provedores, com saídas marcadas em formato legível por máquina e soluções efetivas, interoperáveis, robustas e confiáveis; outro focado em implantadores, com disclosure de deepfakes e de publicações textuais geradas por IA sobre temas de interesse público. A Comissão também trata o código como instrumento voluntário para demonstrar conformidade com as obrigações de marcação e rotulagem. Isso sugere uma arquitetura de defesa em camadas: marca técnica, detecção, rótulo perceptível, registro de decisão e responsabilidade editorial.

A dificuldade de “detectável”

A parte difícil está na palavra “detectável”. Metadados de proveniência, marcas invisíveis, assinaturas criptográficas e classificadores não têm o mesmo comportamento sob compressão, recorte, remix, OCR, transcrição, tradução ou republicação. O C2PA, por exemplo, define um padrão aberto para estabelecer origem e histórico de edições de conteúdo digital por meio de Content Credentials. Ele é relevante porque traduz “proveniência” em infraestrutura técnica, mas não elimina o problema de preservação e verificação ao longo da cadeia.

Pesquisas recentes mostram por que essa camada não pode ser tratada como solução única. Um whitepaper técnico de abril de 2026 argumenta que as especificações atuais do C2PA ainda não devem ser usadas sozinhas para casos de alto risco, como jornalismo, evidência legal ou divulgações financeiras. Outro trabalho, revisado em abril de 2026 e aceito em workshop da CVPR, demonstra conflitos possíveis entre proveniência criptográfica e watermarking invisível: um ativo pode carregar uma manifestação criptograficamente válida e, ao mesmo tempo, um sinal de watermark que aponta para outra origem. O próprio estudo propõe auditoria cruzada entre as camadas e reporta 100% de acurácia em 3.500 imagens no protocolo testado.

A implicação para engenharia é que “marcar conteúdo” vira um contrato entre componentes, não uma chamada isolada de API. Um sistema maduro precisa carregar um estado de transparência junto com o artefato: modalidade, origem, modelo ou sistema gerador, grau de manipulação, transformações aplicadas, política de jurisdição, finalidade de publicação, revisão humana, responsabilidade editorial e forma de disclosure escolhida. Esse estado não precisa ficar inteiro visível ao usuário, mas precisa existir para que a interface consiga exibir a informação correta e para que a auditoria consiga reconstruir a decisão.

O caso do texto: gatilho específico e exceção editorial

O caso de texto é especialmente importante porque evita tanto o sublabeling quanto o excesso de rótulos inúteis. O Artigo 50 não diz que todo texto assistido por IA publicado em qualquer contexto recebe o mesmo tratamento. O gatilho específico envolve texto gerado ou manipulado por IA publicado com o propósito de informar o público sobre temas de interesse público, com exceção quando há processo de revisão humana ou controle editorial e uma pessoa natural ou jurídica assume responsabilidade editorial. Isso cria uma diferença técnica entre “post gerado e publicado automaticamente” e “texto produzido com assistência de IA dentro de uma redação com revisão real”.

Essa exceção só é útil se o sistema consegue provar o fluxo. Um campo booleano human_reviewed=true é frágil demais quando o conteúdo circula por CMS, filas de aprovação, ferramentas de tradução, geradores de resumo e plataformas externas. A alternativa mais sólida é tratar revisão como evento: quem revisou, quando revisou, que versão revisou, que alterações foram feitas depois e qual entidade assumiu a responsabilidade editorial. Sem essa cadeia, a exceção vira apenas uma alegação posterior. Com essa cadeia, ela vira propriedade verificável do processo.

Agentes e propagação de identidade

O mesmo raciocínio vale para agentes. Um chatbot de atendimento, um assistente de voz, um agente que responde tickets ou um sistema que envia mensagens em nome de uma empresa pode interagir com pessoas em canais que não foram originalmente desenhados como “interface de IA”. A obrigação de informar no início da interação pressiona a arquitetura a propagar identidade de agente para e-mail, chat corporativo, central telefônica, comentários em sistemas de suporte e integrações com ferramentas externas. A transparência não pode depender apenas do front-end principal se a interação real acontece fora dele.

Trade-off de produto: nem rótulo demais, nem de menos

Há também um trade-off de produto. Rótulos excessivos perdem valor informacional; rótulos insuficientes criam risco regulatório e aumentam a assimetria entre sistema e usuário. Um vídeo satírico com personagem claramente fictício, uma imagem fotorealista de uma pessoa inexistente em anúncio, um áudio sintético de atendimento, um texto institucional sobre política pública e um relatório revisado por editor não pertencem à mesma categoria operacional. A arquitetura precisa classificar contexto, mídia e finalidade antes de decidir a marca, o disclosure e o nível de evidência necessário.

Transparência como parte do ciclo de vida do artefato

O movimento mais relevante das diretrizes não é jurídico no sentido estreito. Ele força sistemas de IA a manterem uma trilha consistente entre geração, transformação, publicação e exposição. Transparência deixa de ser uma frase adicionada ao final e passa a ser parte do ciclo de vida do artefato. A parte difícil não é escrever “gerado por IA”. É garantir que o sistema saiba, no caminho inteiro, quando essa frase é verdadeira, quando precisa aparecer e que evidência sustenta essa decisão.

Referências

European Commission — Consultation on draft guidelines on transparency obligations under AI Act
European Commission — Draft guidelines Article 50 AI Act
European Commission — Commission opens consultation on draft guidelines
European Commission — Code of Practice on marking and labelling
AI Act Service Desk — Article 50
Future of Life Institute — Transparency rules Article 50 practical guide
Bird & Bird — Reading the Commission’s Draft Article 50 Guidelines
C2PA — Content Provenance and Authenticity
Golaszewski et al. — Verifying Provenance of Digital Media
Nemecek et al. — Authenticated Contradictions from Desynchronized Provenance and Watermarking