A proveniência responde a uma pergunta delimitada
Um ficheiro visual pode circular acompanhado de muitos sinais: uma etiqueta de uma plataforma, dados EXIF, uma marca visível, uma declaração do autor ou uma credencial de proveniência. Nem todos têm o mesmo significado nem a mesma resistência perante alterações posteriores. Para uma redação, uma equipa de marca, um arquivo ou um produto que integra ferramentas generativas, o primeiro passo é formular a pergunta certa: que evidência existe sobre a história declarada deste ficheiro concreto?
C2PA é uma especificação técnica para expressar e verificar informação de proveniência de conteúdos. Em termos práticos, uma credencial pode associar declarações sobre a criação, edição ou combinação de ativos a um ficheiro e proteger essas declarações através de mecanismos criptográficos. O resultado pode ajudar a detetar se a evidência apresentada está intacta e quem a assinou, desde que o validador a consiga verificar e que a confiança no signatário seja justificada.
Esse alcance é importante, mas limitado. Uma credencial válida não transforma automaticamente uma cena num facto comprovado. Também não prova que quem consta como autor detenha todos os direitos necessários, que as pessoas identificáveis tenham consentido a utilização, que uma identidade declarada esteja correta ou que não tenha existido manipulação fora da cadeia registada. Essas questões exigem fontes e controlos separados.
A ausência de uma credencial também não permite concluir que o ficheiro seja falso, manipulado ou gerado por IA. Pode estar ausente porque a ferramenta não a emite, porque foi removida numa exportação, porque uma plataforma a separou do ficheiro ou porque foi utilizado outro formato de proveniência. A decisão editorial deve refletir tanto o que a evidência permite afirmar como aquilo que deixa em aberto.
Quatro evidências que convém manter separadas
As credenciais assinadas são o tipo de evidência mais próximo de uma cadeia verificável de declarações. Podem incluir um emissor, afirmações sobre ações realizadas, referências a ingredientes — ativos utilizados para produzir outro — e uma assinatura. A sua utilidade depende de o ficheiro ou o respetivo manifesto associado permanecerem disponíveis, de a validação ser satisfatória e de o destinatário saber como avaliar o signatário.
Os metadados correntes, como campos de data, software ou câmara, são úteis para catalogação e para orientar uma revisão. Contudo, por si só não oferecem o mesmo modelo de integridade criptográfica e podem perder-se ou ser modificados ao copiar, converter ou publicar. Devem ser tratados como indícios documentais, não como prova conclusiva de origem.
As marcas de água, visíveis ou detetáveis por software, desempenham outra função. Podem informar ou ajudar a identificar conteúdo, mas não demonstram necessariamente toda a sequência de edição nem substituem uma verificação de manifestos. Uma marca visível pode ser recortada; um sinal impercetível pode não sobreviver a certas transformações. O comportamento real deve ser testado no fluxo escolhido.
Por fim, uma declaração do publicador pode ser necessária para explicar ao público como um conteúdo foi produzido ou alterado. Trata-se de uma comunicação atribuível ao responsável pela publicação, e não de uma prova técnica independente. Pode ser apoiada por registos e credenciais, mas deve ser redigida de forma proporcional a essa evidência.
O que cada sinal pode sustentar
| Sinal | Pode apoiar | Não demonstra por si só |
|---|---|---|
| Credencial C2PA validada | Integridade de declarações de proveniência e ações registadas; identidade declarada do signatário | Veracidade factual, licença, consentimento, identidade real de uma pessoa ou ausência total de edições externas |
| Metadados correntes | Catalogação e contexto técnico declarado | Integridade criptográfica ou histórico completo |
| Marca de água | Aviso ou identificação, de acordo com o seu desenho e preservação | Cadeia de transformações, direitos ou exatidão do conteúdo |
| Declaração pública | Informação atribuível ao publicador | Verificação técnica independente |
Como ler uma credencial sem a transformar num selo de autenticidade
A auditoria deve começar pelo ativo recebido, não por uma captura de ecrã de uma interface. Guarde uma cópia sem alterações e calcule ou registe um identificador interno do ficheiro antes de o abrir em ferramentas que possam voltar a guardá-lo. Em seguida, execute um validador C2PA atualizado e guarde o resultado juntamente com a data, a versão do validador e quaisquer avisos.
Reveja quem emitiu ou assinou o manifesto e que nível de confiança a organização lhe pode atribuir. A verificação criptográfica e a confiança organizacional são camadas distintas: um manifesto pode estar bem formado e ter uma assinatura verificável, mas a equipa tem ainda de decidir se conhece e aceita o emissor para a utilização prevista. Se a identidade do emissor for apresentada através de um certificado ou de outro identificador, não a transforme automaticamente numa afirmação sobre propriedade intelectual ou identidade civil.
Examine as ações declaradas. Uma ação pode indicar criação, edição, exportação ou outra operação do fluxo, mas descreve aquilo que o manifesto afirma ter ocorrido. Reveja também os ingredientes e a sua relação com o ativo final. O facto de uma ferramenta constar da cadeia não prova necessariamente que todo o conteúdo visual provenha dela: pode ter sido combinado com fotografias, gráficos, clips, áudio ou outros materiais.
O relatório deve distinguir o estado técnico da decisão de utilização. Registe, por exemplo, se o manifesto foi localizável, se o conteúdo estava corretamente associado, se a assinatura pôde ser validada, que declarações estavam presentes e que limites continuavam a aplicar-se. Evite reduzir esse resultado a uma etiqueta binária como «autêntico» ou «não autêntico».
Auditoria reproduzível de um ficheiro recebido
- 01Isole o ficheiro recebido e guarde uma cópia só de leitura com um identificador interno.
- 02Execute um validador C2PA e guarde o relatório completo, a data e a versão da ferramenta utilizada.
- 03Verifique o emissor declarado, a validade da assinatura, as ações, os ingredientes e os avisos do relatório.
- 04Confronte as declarações técnicas com a documentação disponível sobre encomenda, licença, consentimento e contexto editorial.
- 05Classifique o caso como evidência suficiente, incompleta, ausente ou contraditória; documente quem tomou a decisão.
- 06Repita a verificação sobre o ficheiro descarregado de cada destino de publicação quando a portabilidade for relevante.
Cadeia de custódia: preservar mais do que o ficheiro final
A proveniência torna-se menos útil quando se tenta reconstruí-la no fim da cadeia. O momento mais sólido para documentar um ativo é a sua criação ou receção. Num fluxo de geração ou edição, convém preservar o original entregue pela ferramenta, a respetiva versão exportada, as credenciais que contenha e a documentação operacional que relaciona o ficheiro com uma encomenda ou uma autorização.
Para cada transformação relevante, crie uma nova versão identificável em vez de substituir silenciosamente o original. Anote a ferramenta e a versão utilizadas, o operador, a data, o objetivo da modificação e o ficheiro de entrada. Se uma ferramenta compatível atualizar a proveniência ao editar, valide novamente o resultado. Se uma ferramenta não a preservar, o registo interno torna-se uma evidência contextual especialmente importante, embora não substitua a assinatura do original.
Não confunda armazenamento com publicação. O master de arquivo pode preservar uma credencial incorporada, enquanto uma rede social, um sistema de gestão de conteúdos ou um fornecedor de vídeo pode servir uma cópia recodificada sem ela. Por isso, a política deve definir qual a cópia que constitui o objeto de arquivo, qual a cópia que o público verá e que evidência fica disponível para responder a consultas posteriores.
A especificação prevê formas de transportar manifestos que não se reduzem necessariamente a um único bloco de metadados incorporado. Ainda assim, a organização deve testar a sua própria combinação de formatos, ferramentas e destinos. Não basta assumir que uma credencial sobreviverá porque estava visível na aplicação de origem.
Onde a evidência pode quebrar-se, degradar-se ou separar-se
Uma captura de ecrã cria habitualmente um novo ficheiro e tende a deixar de fora a credencial do ativo original. Pode ser útil como ilustração daquilo que foi mostrado numa interface, mas não deve ser apresentada como prova da proveniência do ficheiro capturado. Sempre que possível, peça o original ou uma ligação interna para o objeto preservado, sem depender da imagem de ecrã.
A recodificação de vídeo, as conversões de formato, a otimização de imagens, o recorte, a remoção de metadados e certas edições podem alterar ou eliminar a informação necessária para validar a proveniência. Algumas ferramentas podem emitir uma nova credencial que reflita a transformação; outras não. O efeito depende da implementação, do formato de entrada e saída e das opções ativas. Por isso, as afirmações sobre compatibilidade devem basear-se em testes documentados do fluxo específico.
Também é necessário distinguir entre uma credencial removida e uma credencial que continua a existir mas está desacoplada do objeto que o público descarrega. Os manifestos podem estar incorporados, ser externos ou ser distribuídos através de outros mecanismos. Se uma interface mostrar um indicador de proveniência, verifique o que acontece ao descarregar, partilhar ou abrir o ficheiro com outro validador. Uma interface não substitui a auditoria do objeto distribuído.
Quando forem detetadas inconsistências — por exemplo, uma declaração pública atribui uma imagem a uma ferramenta, mas o ficheiro disponível não contém a evidência anunciada — não se deve inferir automaticamente má-fé. Deve-se suspender conclusões fortes, preservar as cópias examinadas e pedir o original, o relatório de validação e a explicação do fluxo.
Pontos de falha e resposta operacional
| Situação | Risco para a proveniência | Resposta recomendada |
|---|---|---|
| Captura de ecrã | O novo ficheiro pode não incluir a evidência do original | Pedir e arquivar o ficheiro de origem; tratar a captura apenas como contexto |
| Exportação ou conversão | A credencial pode ser removida, ficar inválida ou ser atualizada | Validar antes e depois de exportar; preservar ambos os resultados |
| Publicação em plataforma | A cópia pública pode estar recodificada ou separada do manifesto | Descarregar e validar a cópia efetivamente distribuída |
| Edição fora de um fluxo compatível | A transformação pode não ficar declarada | Registar internamente a edição e não afirmar uma cadeia completa |
| Manifesto ou declaração contraditórios | Não é possível sustentar uma conclusão simples | Encaminhar para revisão humana e pedir materiais primários |
Protocolo de decisão antes de publicar ou reutilizar
Classifique a evidência em quatro estados operacionais. «Suficiente» não significa certeza total: significa que, para uma decisão concreta e documentada, existe um original disponível, um resultado de validação satisfatório, um emissor avaliado e registos complementares de direitos, consentimento e contexto quando aplicável. Mesmo neste estado, a publicação de uma afirmação factual exige verificação editorial independente.
«Incompleta» significa que existe algum sinal útil — por exemplo, uma credencial válida num original, mas não na cópia de publicação; ou registos de produção sem um manifesto verificável — embora faltem elementos para fazer uma atribuição ampla. Pode ser publicável se o risco editorial for baixo e a comunicação se limitar ao que está confirmado, mas deve ficar uma nota interna sobre as lacunas.
«Ausente» significa que não se dispõe de credencial nem de um registo verificável de proveniência. Não equivale a conteúdo enganador nem a conteúdo gerado. Neste estado, a decisão dependerá do contexto, da confiança no fornecedor, das políticas de aquisição e de outras verificações. «Contraditória» significa que há elementos que não coincidem entre si ou que não é possível explicar uma descontinuidade relevante. Este estado exige revisão humana antes de divulgar uma atribuição sobre origem ou IA.
A classificação deve aplicar-se por versão. Uma validação satisfatória de um master não é automaticamente transferida para uma imagem comprimida para a web, um excerto de vídeo, uma tradução audiovisual ou uma composição posterior. Associe cada decisão a um identificador de ficheiro, e não apenas ao nome comercial do projeto.
Decisão de publicação em seis perguntas
- 01É preservado o ficheiro exato que se pretende publicar ou reutilizar?
- 02A validação de proveniência foi realizada sobre essa versão e produziu um resultado documentado?
- 03Que ações, ingredientes e emissor declara exatamente a credencial?
- 04Que questões continuam por resolver: veracidade, licença, consentimento, identidade ou contexto?
- 05A etiqueta pública proposta corresponde à evidência disponível e evita inferências adicionais?
- 06Uma norma, contrato ou política interna exige uma divulgação adicional para este público e esta jurisdição?
Etiquetas públicas: descrever a evidência, não prometer mais
A etiqueta mais segura descreve o processo conhecido ou o limite da evidência. Se existir uma credencial validada para a versão distribuída e as suas declarações forem pertinentes, uma formulação possível é: «Este ficheiro inclui informação de proveniência verificável sobre as ações declaradas na sua criação e edição». Se a organização quiser mencionar IA, deve fazê-lo apenas quando a evidência técnica e os registos de produção identificarem de forma suficiente essa utilização.
Quando a credencial está presente no original, mas a sua preservação na cópia pública não foi confirmada, é preferível dizer: «O ficheiro master preservado pela organização inclui informação de proveniência verificável; a disponibilidade dessa informação pode variar consoante a plataforma». Esta frase informa sem afirmar que o espetador consiga verificar a mesma evidência em todos os destinos.
Evite frases como «imagem autêntica», «conteúdo real», «sem manipulação», «uso de IA certificado», «com direitos garantidos» ou «sem deepfakes» baseadas apenas numa credencial. Evite também dizer «não gerado por IA» unicamente porque não aparece uma credencial. Estas fórmulas confundem evidência de proveniência com verificação de factos, análise forense, direitos ou ausência de uma técnica.
Na União Europeia, as obrigações de transparência para determinados conteúdos gerados ou manipulados por IA exigem uma análise separada da credencial técnica. A orientação da Comissão Europeia indica que uma marca legível por máquina não basta, por si só, quando for necessário informar as pessoas. A aplicabilidade concreta depende do caso, do papel da organização, das exceções e do calendário regulatório; deve ser analisada com aconselhamento jurídico para cada publicação.
Registo interno mínimo e revisão de fornecedores
Um registo interno consistente permite explicar decisões meses depois, quando uma plataforma já substituiu a cópia publicada ou quando um fornecedor alterou o produto. Inclua um identificador do ficheiro e de cada versão, a localização do original inalterado, a origem da receção ou produção, a ferramenta e versão declaradas, o operador ou responsável, as datas relevantes e a finalidade de utilização. Acrescente o resultado completo da validação, o validador utilizado e os avisos detetados.
Mantenha separadamente a evidência de licença, cessão, autorização contratual, consentimento de pessoas retratadas, restrições territoriais e qualquer revisão de exatidão factual. Se não existir um documento ou se a organização não tiver verificado um ponto, o registo deve indicá-lo expressamente. Misturar essas categorias num único estado de «aprovado» impede saber o que foi realmente verificado.
Antes de contratar ou integrar uma ferramenta visual, peça demonstrações reproduzíveis com ficheiros de teste. Pergunte que formatos suportam credenciais, como estas são preservadas ao gerar, editar, descarregar e carregar novamente, que declarações são emitidas e como os ativos se comportam depois de passarem pelos destinos reais de publicação. Teste tanto casos positivos como ficheiros sem credencial, com credenciais danificadas ou com transformações posteriores.
Esta diligência é especialmente necessária quando são atribuídas capacidades a nomes de modelos ou produtos como GPT‑Image‑2.5 Sunburst, Sora 2 Pro, Nano Banana 2 ou Veo 3.1. Não se deve afirmar que algum deles gera, preserva, atualiza ou remove credenciais C2PA sem documentação técnica verificável e testes sobre a versão concreta. Os nomes comerciais não substituem uma verificação do produto, da configuração e da data.
Campos mínimos do processo interno
| Campo | Finalidade |
|---|---|
| Identificador e versão do ficheiro | Relacionar a evidência e a decisão com um objeto concreto |
| Original e localização de preservação | Permitir uma validação posterior |
| Origem, ferramenta, versão e operador | Documentar o fluxo declarado |
| Relatório de validação e ferramenta utilizada | Tornar a auditoria reproduzível |
| Licença, consentimento e restrições | Separar as condições jurídicas da proveniência técnica |
| Decisão, responsável e etiqueta publicada | Explicar o que foi autorizado e porquê |
Lista de verificação final
Antes de publicar, arquivar, adquirir ou reutilizar um ativo, verifique que a versão exata foi identificada; que o original disponível é preservado; que a validação foi efetuada com uma ferramenta e versão registadas; que as ações, os ingredientes e o emissor foram lidos; e que os avisos foram anotados. Se uma plataforma fizer parte do fluxo, examine também a cópia que entrega ao utilizador final.
Em seguida, reveja fora de C2PA aquilo que a credencial não resolve: licença e âmbito de utilização, consentimento, proteção de dados, identidade das pessoas, exatidão factual, contexto potencialmente enganador e requisitos de divulgação aplicáveis. Uma política útil atribui responsáveis distintos a estas verificações, embora coordene os seus resultados no mesmo processo.
Por fim, comunique apenas aquilo que pode ser sustentado. A proveniência funciona melhor como uma camada de evidência rastreável do que como uma etiqueta definitiva. Adotar esta disciplina permite aproveitar credenciais verificáveis sem converter a sua presença numa promessa de autenticidade total, nem a sua ausência numa acusação infundada.
Questões em aberto
- O comportamento das credenciais numa ferramenta, formato, versão de software ou plataforma concreta deve ser verificado através de testes reproduzíveis; não pode ser deduzido apenas de uma afirmação comercial.
- A confiança que uma organização atribui a um emissor ou certificado depende das suas políticas e do contexto de utilização.
- A aplicação de obrigações legais de transparência depende da jurisdição, da data, do tipo de conteúdo, do papel da organização e de possíveis exceções.
- Não foi fornecida documentação técnica verificada que permita atribuir capacidades concretas de proveniência a GPT‑Image‑2.5 Sunburst, Sora 2 Pro, Nano Banana 2 ou Veo 3.1.
Continue a explorar
Fontes consultadas
Correções e transparência
Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.
Propor uma correção