Resposta direta
Antes de contratar, o critério é separar automação que lê de automação que apaga. Toda operação com permissão de escrita precisa de ponto de restauração verificável, janela de retenção declarada e um teste de restauração feito antes da entrada em produção. O contrato deve nomear quem responde pela perda, quanto tempo o dado leva para voltar e como o erro é detectado. Sem isso, o risco deixa de ser técnico e passa a ser de responsabilidade: o buraco no backup só aparece no dia em que ele é necessário.
- Objetivo
- Orientar avaliação e contratação
- Formato indicado
- Workshop executivo
- Atualizado em
O que esta página acrescenta: Trata a contratação como decisão sobre operações destrutivas, definindo o que exigir por escrito sobre restauração, responsabilidade e detecção do erro, e o que essa exigência não cobre.
O que separar na avaliação
A pergunta útil não é se a automação funciona, mas o que ela pode destruir. Automação que só lê tem risco baixo de perda. Automação que escreve, sobrescreve ou apaga concentra o problema. O primeiro passo é um inventário das operações destrutivas por rotina, com o dado que cada uma toca e a frequência com que a toca. Esse inventário é o que sustenta qualquer exigência posterior.
Para cada operação irreversível, o que importa é o estado anterior. Onde ele está guardado, por qual intervalo de tempo e em que condições pode ser recuperado. Isso não é um valor a inventar agora: é o que deve ser declarado pelo fornecedor e verificado pela contratante antes da entrada em produção.
O que precisa estar no contrato
Três pontos não podem ficar implícitos. O primeiro é a responsabilidade: quem responde quando o dado some e em que condições a responsabilidade muda de lado. O segundo é a obrigação de avisar: qual evento dispara a comunicação, para quem e por qual meio. O terceiro é a restauração: quem executa, com qual evidência de que o dado voltou íntegro.
A existência de backup não é cláusula suficiente. A exigência razoável é uma prova periódica de restauração, com registro de quem executou e do que foi recuperado. O critério de aceite da automação passa a incluir essa prova, e não apenas o funcionamento normal. Se o fornecedor não consegue demonstrar a volta, a contratação assume um risco que não está descrito.
O que essa exigência não resolve
Cláusula nenhuma impede o erro. O que o contrato faz é distribuir custo, prazo e responsabilidade, e obrigar a detecção. O backup também tem limites próprios: não cobre dado alterado no lugar sem cópia anterior, nem perda descoberta depois da janela de retenção, nem tabelas que ficaram fora da rotina. Nesses casos a restauração existe no papel e não na prática.
A abordagem faz pouco sentido para automação que apenas lê ou para processos sem estado reversível. E mesmo com tudo escrito, a responsabilidade final sobre o dado continua com a contratante, porque é ela que concedeu a permissão de escrita. Contratar bem reduz a exposição; não a elimina.
Recurso prático
Roteiro para avaliar automação que apaga dados
- Listar, por automação, toda operação com permissão de escrita: inserir, atualizar, sobrescrever e apagar.
- Marcar quais dessas operações são irreversíveis e qual dado deixaria o processo parado se desaparecesse.
- Pedir a evidência de restauração: onde o backup fica, quem executa a volta e em quanto tempo o dado volta a estar disponível.
- Verificar o que a rotina de cópia não cobre: dados alterados no lugar, tabelas fora do escopo e o intervalo entre duas cópias.
- Definir no contrato quem avisa, quem restaura e quem responde pelo dado perdido.
- Repetir a verificação sempre que a automação muda de escopo ou ganha nova permissão de escrita.
O ponto mais ignorado é aceitar a existência do backup sem nunca testar a restauração. Um backup que nunca foi restaurado uma vez é uma suposição, não uma proteção, e a diferença aparece justamente no incidente.
Sobre o que está escrito aqui
Conceitos relacionados: backup restaurável · operação destrutiva · ponto de restauração · permissão de escrita · janela de retenção. Exemplos são ilustrativos. Não há cliente, resultado, preço, prazo ou certificação nesta página. Quando o formato indicado é Workshop executivo, ele descreve uma possibilidade de trabalho — a conversa inicial avalia contexto e aderência.
Para continuar
- Governança e controle de automação — Página central do tema
- Logs de automação: o mínimo necessário para r… — ausência de registros
- Acessos excessivos: como reduzir sem travar o… — acessos excessivos
Páginas relacionadas
O mesmo problema em outro objetivo
- Erro que apaga dado sem backup: como achar a origem — Diagnosticar
- Deleção de dado por automação: o critério antes do erro — Organizar um processo
- Apagar dado sem backup: comparar as proteções — Comparar alternativas
- Exclusão sem backup: como medir o erro na automação — Explicar medição
- Automação que apaga dado sem backup: o que implantar antes — Orientar implementação
Outras leituras em Governança e controle de automação
- Ausência de registros: como medir o que não foi gravado — Mostra onde procurar quando a automação não deixou registro: fontes externas, eventos órfãos e o que passa a ser exigido por contrato.
- Ausência de registros: o que precisa de comprovação — Como definir quais automações exigem registro, a partir das decisões que precisam ser comprovadas, e o que fazer com o período que já ficou sem histórico.
- Incidente comunicado informalmente: o que medir — Define o que contar quando o relato de falha chega por conversa, reunião ou mensagem direta, e como comparar esse volume com o que entra no sistema.
- Documentação desatualizada: o que contratar e o que exigir — O que definir antes de contratar a atualização da documentação: escopo, responsável, formato entregue, critério de aceite e o que o contrato não cobre.
- Alerta que ninguém recebe: como definir o destinatário — Define quem recebe cada alerta, quem responde por ele e em que prazo, com registro de ciência e revisão periódica da lista de destinatários.