Resposta direta
A contratação precisa tratar o comportamento após erro como requisito verificável, não como característica técnica do fornecedor. Isso significa descrever, antes de assinar, o que a automação faz quando uma etapa falha: para, reprocessa, acumula para revisão ou segue adiante. Cada opção tem custo e responsabilidade diferentes. O contrato deve nomear quem observa a falha, qual evidência fica registrada e quem responde pela decisão de continuar. Sem essa definição, a discussão sobre o que deveria ter acontecido começa no incidente, quando o processo já parou.
- Objetivo
- Orientar avaliação e contratação
- Formato indicado
- Workshop executivo
- Atualizado em
O que esta página acrescenta: Trata a contratação como o momento de fechar o comportamento após erro em obrigação verificável, com responsável e evidência nomeados.
Onde o erro entra na avaliação da proposta
Propostas de automação descrevem bem o caminho em que tudo funciona. O comportamento após falha costuma ficar em uma linha genérica, tratada como detalhe de implementação. Essa é a parte que decide o custo real da operação e não deveria ficar fora da avaliação.
A pergunta útil ao fornecedor não é se ele trata erros, mas o que acontece na etapa seguinte a uma falha. Reprocessar, parar a fila, acumular para revisão e seguir adiante são respostas diferentes, com consequências diferentes para prazo, margem e risco. A proposta deve indicar qual delas se aplica a cada etapa crítica.
Responsabilidade e evidência no contrato
Contrato que só descreve função não resolve comportamento em falha. O que precisa estar escrito é quem observa o erro, em quanto tempo a falha é tratada, qual registro fica guardado e quem decide continuar ou interromper. Sem responsável nomeado, a automação continua porque ninguém é dono da parada.
A evidência é o que permite reconstruir a decisão depois. Cada execução com falha deve deixar registro do que entrou, do que foi tentado e do que foi feito em seguida. Se o fornecedor não consegue entregar esse registro, o compromisso de interrupção existe apenas no papel.
O que o contrato não cobre
Cláusula não impede falha. Ela define obrigação, evidência e responsabilidade, e serve para reduzir discussão depois. O comportamento real da automação depende de configuração, dados e operação do dia, coisas que o contrato descreve mas não controla.
Em automações pequenas e internas, formalizar tudo pode custar mais do que o risco que se quer reduzir. Nesses casos, o registro simples do ponto de parada e de quem responde já resolve. O contrato detalhado faz sentido quando a falha atinge cliente, margem ou obrigação regulatória.
Recurso prático
Da proposta à cláusula: onde o erro entra na avaliação
- Separar as etapas em que a automação decide sozinha das que têm conferência humana. Só as primeiras exigem definição explícita de parada.
- Pedir ao fornecedor a descrição do que acontece na etapa seguinte a uma falha: reprocessa, para a fila, acumula para revisão ou segue adiante.
- Levar essa descrição para o contrato como obrigação verificável, com responsável nomeado e evidência registrada por ocorrência.
- Definir como a falha será testada antes da entrada em produção e quem aceita o resultado do teste.
O erro mais comum é aceitar a resposta de que a automação trata exceções, sem a descrição do ponto exato de parada. A discussão fica aberta justamente no dia do incidente.
Sobre o que está escrito aqui
Conceitos relacionados: ponto de interrupção · tratamento de exceção · cláusula de responsabilidade · evidência de execução · teste de falha assistida. 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
- Ausência de registros: o que implementar prim… — ausência de registros
- Dados enviados indevidamente: como rastrear a… — dados enviados indevidamente
Páginas relacionadas
O mesmo problema em outro objetivo
- Falha na automação: como saber o que continuou rodando — Diagnosticar
- Automação que rodou após o erro: dono da decisão e registro — Organizar um processo
- Automação após erro: comparar quatro modos de parada — Comparar alternativas
- Falha que segue rodando: o que medir na automação — Explicar medição
- Automação que continua após erro: como definir a interrupção — Orientar implementação
Outras leituras em Governança e controle de automação
- Envio indevido de dados: como contratar a resposta — O que avaliar e o que fixar em contrato quando o risco é envio indevido de dados por automação, e o que essa cobertura não alcança.
- Incidente repetido: como chegar à causa, não ao culpado — Etapas para separar sintoma, gatilho e condição de causa em incidentes de automação, com dono da correção e critério de encerramento.
- Log sem retenção definida: como definir prazo e descarte — Responde por quanto tempo guardar os logs de automação, onde a decisão fica registrada e como o descarte acontece sem perder o histórico que ainda importa.
- Automações sem inventário: por onde começar o registro — Reconstrução do registro de automações a partir de evidências de execução, com responsável nomeado, processo afetado e critério de revisão.
- Segregação de função ausente: o que contratar e como aceitar — O que definir no escopo, nas evidências e na aceitação ao contratar segregação de função para uma automação que já opera sem ela.