Resposta direta
A contratação se faz sobre o que é verificável sem o código: comportamento observável, entradas e saídas, dados que circulam, obrigações de suporte e condições de saída. Código fechado não impede contratar; impede auditar a lógica interna. O contrato desloca a verificação para resultados testáveis e para a passagem de operação. Três pontos decidem a compra: quem responde pelo comportamento em produção, o que acontece se o fornecedor encerrar a operação, e como o dado retorna em formato utilizável. Sem resposta escrita para os três, o risco é transferido sem que o controle acompanhe.
- Objetivo
- Orientar avaliação e contratação
- Formato indicado
- Workshop executivo
- Atualizado em
O que esta página acrescenta: Trata a inacessibilidade do código como condição de contrato e de verificação, não como falha a ser corrigida depois.
O que a falta de código impede de conferir
Sem o código, não é possível ler a regra que decide cada passo. Isso limita a auditoria da lógica, não a verificação do comportamento. A automação pode ser observada por fora: entradas aceitas, saídas produzidas, erros devolvidos, versões registradas, quem alterou o quê.
A distinção importa na hora de contratar. Quem confunde as duas coisas compra promessa de transparência e recebe caixa fechado. A exigência razoável recai sobre o que dá para testar e documentar, com registro de versão e aviso de mudança que altere o resultado.
Cláusulas que substituem a leitura do código
Três obrigações fazem o papel da auditoria impossível. Casos de aceitação acordados por escrito, com entrada, saída esperada e comportamento em erro. Aviso prévio quando a lógica mudar. Registro de versão em execução, para que um resultado possa ser ligado ao estado da automação naquele momento.
A quarta obrigação é a saída. Exportação dos dados em formato utilizável, cooperação durante a transição e definição de quem opera o quê depois do encerramento. Depósito de código em custódia só ajuda se houver regra clara de liberação; sem isso, vira documento que ninguém consegue usar.
Quando comprar assim não se sustenta
Há casos em que o comportamento observável não basta. Decisão sobre pessoas, crédito, saúde ou dinheiro exige explicação da regra, e isso raramente sai de teste de caixa preta. Se a atividade é regulada ou o erro atinge direito de alguém, a ausência de código é impedimento, não detalhe contratual.
Também não se sustenta quando o fornecedor hospeda tudo e recusa exportação, ou quando o volume não justifica o custo de manter verificação própria. Nesses casos, a decisão honesta é não contratar, ou contratar assumindo dependência e mantendo operação paralela enquanto o risco for tolerável.
Recurso prático
O que verificar quando o código não está disponível
| Ponto a verificar | Prova aceitável sem acesso ao código |
|---|---|
| Lógica de decisão | Casos de aceitação acordados por escrito, com entrada, saída esperada e comportamento em erro, executados antes da aceitação formal |
| Continuidade da operação | Plano de saída com exportação de dados em formato utilizável, cooperação na transição e definição de quem opera o quê após o encerramento |
| Responsabilidade por execução indevida | Cláusula que nomeia quem responde pelo comportamento em produção e como o prejuízo é apurado e ressarcido |
O erro mais comum é aceitar demonstração como prova. Demonstração mostra o caminho que funciona; a verificação sem código depende dos casos em que a automação deveria recusar, parar ou devolver erro.
Sobre o que está escrito aqui
Conceitos relacionados: código-fonte · caso de aceitação · plano de saída · exportação de dados · registro de versã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
- Acessos excessivos: como reduzir sem travar o… — acessos excessivos
- Dados enviados indevidamente: como prevenir a… — dados enviados indevidamente
Páginas relacionadas
O mesmo problema em outro objetivo
- Automação sem código-fonte: o que dá para saber — Diagnosticar
- Automação sem código-fonte: o que dá para controlar — Organizar um processo
- Automação sem código-fonte: o que comparar antes de decidir — Comparar alternativas
- Automação sem código: o que dá para medir por fora — Explicar medição
- Automação sem código-fonte: controle pelo comportamento — Orientar implementação
Outras leituras em Governança e controle de automação
- Dependência de fornecedor: desenhar a saída antes do contrato — Como definir, no contrato de automação, o que acontece com dados, regras, credenciais e histórico quando a relação com o fornecedor termina.
- Dependência de fornecedor: comparar rotas de saída — Compara caminhos de saída para automação presa a um fornecedor: substituir, internalizar ou reduzir escopo, com critérios de custo e tempo de troca.
- Dependência de fornecedor: o plano de saída como rotina — Itens que precisam ficar sob controle próprio quando a automação depende de um fornecedor único, com responsável interno e estado verificado.
- Dependência de fornecedor: o que falta para conseguir sair — Como diagnosticar dependência de fornecedor em automação: sinais de aprisionamento, o que precisa estar documentado e o que testar antes de precisar trocar.
- Mudança em produção sem aviso: como medir a alteração — Descreve como registrar e comparar alterações de automação em produção, definindo estado esperado, responsável e momento da verificação.