Numa página publicada parecem idênticos. Uma linha a dizer que o conteúdo foi produzido com apoio de IA, e um registo que mostra o que foi produzido, por quem e quando. Mesma frase, mesma posição, mesmo tipo de letra. A diferença só aparece quando alguém tem motivo para questionar, e nessa altura já é tarde para criar o segundo.
Duas coisas que parecem iguais
Um rótulo é uma declaração. Está a descrever os seus próprios conteúdos, nas suas palavras, numa superfície que controla. Ao abrigo do artigo 50 do Regulamento de IA da UE é exatamente essa declaração que é pedida, e acertar nela importa.
Um registo é diferente em natureza, não em grau. É um objeto criado num momento preciso, ligado a um ficheiro preciso, guardado de tal modo que nem o senhor nem quem o lê o podem rever discretamente. Não descreve o que fez. Mostra-o.
Toda a conversa de conformidade que corre mal corre mal exatamente no ponto em que alguém tomou a primeira coisa pela segunda.
Quanto vale uma autodeclaração
Vale algo, e desvalorizá-la seria o erro no sentido contrário. Uma divulgação clara, exata e aplicada de forma coerente é o que a regra pede. Sinaliza um processo que funciona. É a primeira coisa que um cliente razoável quer ver. Se não a fez, faça-a antes de se preocupar com qualquer outra coisa nesta página.
O que ela não é: prova de si mesma. Uma autodeclaração é uma afirmação, e uma afirmação sustenta-se sozinha apenas enquanto ninguém tiver interesse em testá-la. Normalmente é muito tempo, e é precisamente por isso que a falha passa despercebida até ao dia em que conta.
As três perguntas a que um rótulo não responde
Coloque qualquer declaração de divulgação ao lado destas e a forma da falha torna-se óbvia.
O que foi produzido? Não o que está hoje na página. O objeto exato que saiu. As páginas são editadas. Uma declaração escrita hoje sobre uma versão entretanto revista duas vezes descreve algo que já não existe nessa forma.
Por quem, e com o quê? Que partes foram geradas, quais foram editadas por um modelo, quais foram escritas por uma pessoa. Uma única linha no fim da página comprime tudo isso numa palavra, e essa palavra é escolhida pela parte a quem convém escolhê-la.
Em que data isso era verdade? É esta a pergunta que destrói em silêncio a maioria das respostas internas. Uma declaração feita em agosto sobre trabalho de março é uma memória. A data dela é a data em que escreveu a declaração, não a da coisa que descreve.
Onde as equipas julgam ter as suas provas
Peça a uma equipa de marketing ou de conteúdos para sustentar uma declaração e saem quatro coisas, mais ou menos por esta ordem. Cada uma é útil. Nenhuma aguenta quando é contestada em vez de simplesmente consultada.
Datas de modificação de ficheiros. A resposta mais comum e a mais frágil. Uma data de modificação é um metadado dentro de um sistema que o senhor administra. Muda quando um ficheiro é copiado, sincronizado, exportado ou aberto pela aplicação errada, e pode ser definida de propósito. É uma nota de trabalho sobre os seus próprios ficheiros, não uma declaração que outra pessoa tenha motivo para aceitar.
Fios de e-mail. Melhor, porque envolve uma segunda parte que guarda cópia. Ainda assim frágil para este fim. Um e-mail mostra que algo foi discutido numa data. Raramente se prende a uma versão específica do ficheiro, os cabeçalhos podem ser construídos, e um fio que parece conclusivo a quem o viveu costuma ler-se como ambíguo para quem não esteve lá.
Histórico de gestão de projeto. Transições de tarefas, comentários, anexos, um registo de auditoria. Parece sólido porque é detalhado e com carimbos temporais. O problema é administrativo: os administradores do espaço podem editar ou apagar entradas, as políticas de retenção eliminam discretamente o que é antigo, e todo o arquivo pertence à parte que faz a afirmação. Detalhe não é independência.
Histórico de versões na nuvem. O mais sólido dos quatro e, ainda assim, na mesma armadilha. O histórico mostra uma sequência de estados de um documento. Está na mão de um fornecedor com quem contrata, sob condições que pode alterar, numa conta que controla, e normalmente expira. Responde ao que mudou. Não responde de forma independente a quando, perante alguém que decidiu não acreditar na sua palavra.
O fio comum não é que estes sistemas sejam pouco fiáveis. É que os quatro estão na mão da parte cuja afirmação está em causa. É um problema estrutural, e nenhuma quantidade de registo interno adicional o corrige.
O que muda quando o registo é selado
Selar move uma coisa concreta para fora do seu controlo: a data.
Calcula-se um hash criptográfico a partir do próprio ficheiro, de modo que o registo fica preso a uma versão exata e não a um documento que continua a mudar. A declaração sobre como o trabalho foi produzido é ligada a esse hash. Um prestador qualificado de serviços de confiança emite depois um carimbo temporal eletrónico qualificado sobre ambos.
Ao abrigo do Regulamento eIDAS, Regulamento (UE) n.º 910/2014, um carimbo temporal eletrónico qualificado beneficia de presunção legal quanto à data e à hora que indica e à integridade dos dados a que está associado. Na Suíça, a ZertES regula os serviços de certificação para assinaturas eletrónicas, ao passo que a equivalência com a assinatura manuscrita vem do art. 14 n.º 2bis do Código das Obrigações suíço. São dois textos distintos e vale a pena citá-los como dois.
O que isso lhe traz na prática é estreito e valioso. Não torna verdadeira a sua declaração. Torna a data da sua declaração algo que não pode ter alterado depois, e essa é exatamente a propriedade que falta aos quatro registos internos acima. Um hash num registo público dá um resultado próximo mas mais fraco, por razões que vale a pena ler por extenso na comparação com a marcação temporal em blockchain.
Um exemplo desenvolvido
Uma agência entrega uma campanha em fevereiro. Página de destino, seis anúncios, um vídeo de lançamento. Parte dos textos foi esboçada com um modelo, tudo foi revisto por uma pessoa, uma ilustração foi gerada. A entrega inclui uma linha de divulgação, o que é mais do que a maioria das agências fez nesse mês.
Em agosto o cliente é adquirido. A equipa jurídica do comprador faz uma auditoria de conteúdos e envia uma pergunta: para cada peça, o que foi gerado por IA, o que foi assistido por IA, e que provas sustentam a resposta. O prazo é de duas semanas e o tom é processual, não hostil.
A agência tem agora de reconstruir fevereiro. O designer que gerou a ilustração saiu. O documento foi editado onze vezes desde a entrega, a última pelo próprio cliente. O espaço de gestão de projeto foi migrado em maio e os comentários com mais de noventa dias não transitaram. Resta um fio de e-mail a dizer que a campanha está pronta para revisão, e uma linha de divulgação de data desconhecida.
Nada disto envolve má-fé. Cada um fez o seu trabalho. A agência simplesmente não consegue responder a uma pergunta para a qual não teve motivo de se preparar, e o comprador não é desrazoável ao fazê-la. O custo são duas semanas de tempo de quadros seniores, uma relação tensa, e uma resposta que termina em "tanto quanto nos recordamos".
A versão em que a agência selou cada entregável no momento da entrega demora cerca de dez minutos. Reencaminham quatro certificados. O comprador verifica-os sem contactar ninguém. A conversa acaba ali.
O ponto prático
Rotule os seus conteúdos. É essa a obrigação e não é opcional. Depois faça uma segunda pergunta, que a regra não faz mas os seus clientes acabarão por fazer: se alguém sem motivo para confiar em nós nos pedir para sustentar isto daqui a seis meses, o que lhe entregamos?
Se a resposta for uma pasta de capturas de ecrã e uma memória, a falha merece ser fechada enquanto ainda sai barato. A nossa página sobre o artigo 50 expõe o que a obrigação abrange e onde se encaixa uma declaração selada.
