O cliente diz que nunca aprovou aquilo: como ter prova de aprovação que ninguém edita depois
Quando a aprovação vive num print, num áudio ou numa planilha editável, ela não vale como prova. Veja como montar um registro que só cresce, quem precisa ter acesso a quê e o que a LGPD cobra de você nesse caminho.
A conversa sempre começa do mesmo jeito: "a gente nunca aprovou esse criativo". Ou "eu não autorizei subir a verba". Ou, no caso mais desconfortável, "esse relatório não é o que você me mandou".
E aí você vai procurar. Encontra um print de WhatsApp com a data cortada, um áudio de 40 segundos onde o cliente diz "pode ir" sem dizer de quê, uma linha numa planilha compartilhada que três pessoas podem editar. Nada disso é prova. É lembrança com aparência de documento.
O problema não é a sua memória estar errada — na maioria das vezes ela está certa. O problema é que o registro que você tem pode ser alterado por você. E um registro que a parte interessada pode alterar não convence ninguém: nem o cliente, nem o jurídico dele, nem um auditor, nem a ANPD se o assunto virar dado pessoal. É por isso que vale entender como funciona uma camada de segurança e LGPD feita para que o próprio operador não consiga reescrever o passado.
Este artigo é sobre como montar esse registro na prática.
Por que print e áudio não sustentam uma aprovação
Uma prova se sustenta em três coisas: quem, quando e o quê. Falha em qualquer uma e ela desmonta.
Quem: um print de grupo não diz qual pessoa jurídica autorizou. "Pode ir" vindo do estagiário do cliente não é autorização de orçamento.
Quando: data de celular é configurável. Mensagem apagada desaparece dos dois lados. Áudio não tem carimbo verificável.
O quê: "pode ir" se refere a qual versão? Se o criativo foi trocado depois, a aprovação continua valendo? Na cabeça do cliente, não.
E tem um quarto item que quase ninguém considera: imutabilidade. Mesmo que você tenha quem, quando e o quê num documento perfeito, se esse documento está num arquivo que você pode editar, ele vale o quanto a confiança no momento permitir. Em discussão de boa-fé, vale muito. Em discussão de má-fé, vale zero.
O que é um registro que só cresce
A solução técnica para isso tem um nome simples: tabela que só aceita inserção. Em inglês, append-only. Você grava eventos e nunca altera nem apaga os anteriores.
Pense no extrato bancário. Você não corrige um lançamento errado editando a linha — você lança um estorno. A linha errada continua lá, visível, e a história completa fica registrada. Isso é o que dá credibilidade ao extrato: ele não esconde o erro, ele mostra a correção.
Aplique isso ao seu fluxo de aprovação:
O cliente abre a versão 3 do plano de mídia. Grava-se um evento de visualização: usuário, horário, versão.
O cliente aprova. Grava-se um evento de aprovação, vinculado ao identificador daquela versão específica.
Você altera o plano. Isso não apaga a aprovação anterior — cria a versão 4, que nasce sem aprovação.
Se o cliente reclamar depois, a linha do tempo inteira está disponível: o que ele viu, quando, e qual versão ele liberou.
A diferença em relação a uma planilha de controle é que ninguém digita esses eventos. Eles são consequência de um clique real, gravados pelo sistema no momento em que aconteceram.
O detalhe que muda tudo: quem grava
Essa é a parte que separa um log decorativo de uma prova. Se o registro é gravado pelo navegador do usuário, ou se o aplicativo manda para o banco "a aprovação aconteceu às 14h32", quem controla o aplicativo controla a história.
A gravação tem que ser do servidor, com o horário do servidor, sem campo editável vindo de fora. Na Blocos, aprovação, log, consentimento e snapshot são gravados só pelo servidor, em tabelas que só crescem. Significa que nem o dono da agência tem um botão para mudar a data de uma aprovação — e é exatamente essa impossibilidade que torna o registro útil quando alguém questiona.
Se a ferramenta que você usa hoje permite que você edite um log, esse log não é prova. É anotação.
Snapshot: a aprovação precisa apontar para algo congelado
Tem um erro clássico aqui. A agência registra bonito: "Fulano aprovou o relatório de outubro em 03/11 às 10h12". Perfeito. Só que o relatório de outubro é uma página dinâmica, que recalcula a cada carregamento, lendo a API da Meta ao vivo.
Seis meses depois, essa página mostra números diferentes — porque a Meta reprocessou atribuição, porque uma conversão offline entrou atrasada, porque o fuso mudou. A aprovação continua registrada, mas aponta para um conteúdo que mudou. Você provou que ele aprovou alguma coisa.
Aprovação sem snapshot é meia prova. O registro precisa guardar o estado exato do que foi visto: os números daquele momento, a versão do texto, o criativo específico. É a diferença entre "ele aprovou o relatório" e "ele aprovou este relatório, com estes números".
Cargos: a prova também depende de quem podia fazer o quê
Uma aprovação só vale se a pessoa tinha autoridade para aprovar. E isso não se resolve com combinado verbal.
Se todo mundo na sua conta tem acesso total, você não consegue afirmar que uma ação partiu de quem deveria. Pior: numa discussão interna, qualquer pessoa da equipe pode ter mexido em qualquer coisa, e o log vai apontar para um usuário genérico compartilhado.
O caminho é permissão por cargo — dono, analista, cargos criados por você, cada um com o seu escopo — e nenhuma conta compartilhada. Login individual com verificação em duas etapas não é paranoia de TI: é o que faz o log ter nome. Sem isso, o registro diz "alguém com a senha do e-mail da agência aprovou", o que não resolve nada.
Vale a mesma lógica para o isolamento entre clientes. Se o filtro que separa os dados de uma agência dos de outra está só na aplicação, basta um bug de parâmetro para vazar. Quando a regra de acesso nasce no próprio banco, por tabela, o erro de código não vira incidente de dados — e é assim que a arquitetura de isolamento deveria funcionar em qualquer ferramenta que guarde dados de terceiros.
Onde a LGPD entra nessa história
Até aqui falamos de prova comercial. Mas o mesmo mecanismo resolve uma obrigação legal que muita agência ainda trata no improviso.
Se você capta leads, você trata dado pessoal. A LGPD exige que você demonstre a base legal desse tratamento — e, quando a base é consentimento, que você consiga comprovar que ele foi dado. Comprovar com registro, não com "a gente tinha um checkbox no formulário".
Três pontos práticos:
Consentimento é evento, não configuração. Precisa estar gravado com data, versão do texto aceito e identificação de quem aceitou. Se o texto da sua política mudou, você precisa saber qual versão cada pessoa aceitou — daí a importância de documentos públicos e versionados.
Pedido do titular tem prazo. Quando alguém pede para saber quais dados você tem ou para excluí-los, há um prazo a cumprir. O padrão de 15 dias para resposta ao titular só é viável se você souber onde o dado está sem precisar caçar em planilha.
Credencial de cliente é ativo sensível. Token da Meta, token do Google, senha do cofre: tudo isso cifrado em AES-256-GCM, com a chave guardada fora do banco. Um dump de banco vazado não deveria entregar acesso às contas de anúncio dos seus clientes.
O teste de três perguntas
Antes de confiar em qualquer fluxo de aprovação — o seu ou o da ferramenta que você usa — responda:
Eu consigo editar o registro de uma aprovação? Se sim, não é prova.
A aprovação aponta para um conteúdo congelado? Se o conteúdo recalcula, a prova envelhece sozinha.
O log tem nome de pessoa ou de conta compartilhada? Nome de pessoa exige login individual e 2FA.
Se as três respostas estiverem boas, aquela conversa de "nunca aprovei isso" acaba em dois cliques, sem desgaste e sem você precisar levantar a voz. A prova fala.
Se alguma resposta estiver ruim, vale olhar como a camada de segurança e LGPD da Blocos resolve cada uma — isolamento no banco, cargos e permissões, cifragem das credenciais e registros que só o servidor grava. É menos sobre tecnologia e mais sobre dormir tranquilo no dia em que a pergunta chegar.
