A ferramenta que ninguém lembra quem fez
Alguém do financeiro pediu ajuda ao Claude ou ao Cursor numa sexta à tarde para automatizar a conciliação de um relatório chato. Funcionou. Rodou de novo na semana seguinte. Um colega copiou o script para o próprio notebook porque precisava do mesmo relatório. Seis meses depois, três times dependem daquilo, o token de API é da conta pessoal de alguém que já trocou de time, e ninguém sabe dizer com clareza onde o código está nem quem é o dono.
Esse cenário não é exceção rara. É o normal agora, e tem número por trás.
O dado: a maioria não sabe se já quebrou
A Retool fez uma pesquisa com 307 CTOs, CISOs e CIOs, em parceria com a Wynter, em maio de 2026. Perguntou com que frequência a empresa já teve um incidente de produção causado por uma ferramenta interna feita com IA. O resultado: 59% responderam que não sabem dizer. Só 19% conseguem afirmar com segurança que nunca tiveram, porque têm monitoramento capaz de provar isso. E 22% confirmam que já tiveram pelo menos um incidente.
A mesma pesquisa mostra o motivo por trás da resposta "não sei": 95% dos líderes dizem não ter visibilidade completa do que está rodando em produção. Só 8% descrevem a governança sobre essas ferramentas como forte, e apenas 8% têm algum tipo de controle centralizado sobre elas.
Repara no que esses números dizem juntos. Não é que as ferramentas feitas com IA estejam quebrando muito. É que a maior parte das empresas não tem como saber se estão. O problema não é a qualidade do código gerado, é a ausência de qualquer caminho para observá-lo depois que ele nasce.
O código funciona, é por isso que ele sobrevive
O erro comum é tratar isso como problema de qualidade de IA: "o código gerado é ruim, por isso dá incidente". Não é essa a causa principal. O script da conciliação funcionava. Era simples, resolvia o problema do dia, e por isso ninguém parou para questionar onde ele deveria morar.
O problema é estrutural: essa ferramenta nasceu fora do caminho que qualquer outro pedaço de código passa. Sem repositório com histórico, sem revisão de um segundo par de olhos, sem log de execução, sem segredo vindo de um cofre. Ela funciona até o dia em que a planilha de origem muda de coluna, ou o token pessoal expira porque a pessoa saiu da empresa, e aí ninguém sabe por onde começar a debugar.
Isso não é uma falha de governança que se resolve com uma política escrita. É uma decisão de stack que ninguém tomou.
A decisão que ficou sem dono
Toda vez que alguém do time usa IA para construir uma automação interna, existe uma decisão implícita de arquitetura sendo tomada, mesmo que ninguém chame assim. A pergunta certa não é "podemos usar IA para construir ferramentas internas": isso já está decidido, e proibir não funciona, ninguém obedece proibição que atravanca o trabalho do dia. A pergunta é onde essa ferramenta vai morar depois de pronta.
| Critério | Nasceu fora do pipeline | Passou pelo pipeline |
|---|---|---|
| Onde vive o código | Notebook pessoal, pasta local, conta de automação individual | Repositório da empresa, com histórico de commits |
| Quem é dono | Quem escreveu, até sair de férias ou trocar de time | Time definido, visível para todo mundo |
| Segredo usado | Token pessoal de quem criou | Chave do cofre de segredos da empresa |
| O que acontece quando quebra | Ninguém sabe por onde começar | Log mostra execução, erro e ponto de falha |
A linha da direita não exige um processo pesado. Exige três checkpoints antes de qualquer ferramenta interna tocar dado real ou dinheiro real: ela mora num repositório com dono visível, ela registra o que fez e quando, e ela usa uma credencial que não desaparece quando uma pessoa sai. Três perguntas, respondidas antes de a automação sair do notebook de quem criou.
Um rascunho pessoal, algo que só uma pessoa usa para o próprio trabalho, pode viver fora disso sem problema. A régua muda quando o script passa a ser parte do processo de outras pessoas, e é exatamente aí que a maioria das empresas da pesquisa da Retool perde o rastro.
O que a Overflow aplica nisso
Na implementação de IA que a Overflow conduz, a fase de produção inclui controle de acesso e guardrails desde o primeiro dia, não como camada adicionada depois de um susto. Isso vale tanto para o agente que fica de frente com cliente quanto para o script interno que ninguém batizou de "projeto oficial". Se toca dado ou dinheiro da operação, entra no mesmo caminho que o resto do sistema segue. Tem mais detalhe de como essa fase funciona em overflow.codes/ia-first.
O que fazer na segunda de manhã
Antes de mais nada: liste as automações feitas com IA que o seu time criou nos últimos 90 dias e que não passaram pelo repositório principal da empresa. Não precisa ser exaustivo, precisa ser honesto. Depois, separe as três que tocam o dado mais sensível ou o processo mais crítico, o financeiro, o cadastro de cliente, o que dispara cobrança. Mova essas três para o repositório essa semana: dono definido, log mínimo, segredo saindo do cofre.
As outras podem esperar. Mas essas três não deveriam ter esperado até agora.
Fontes
- As Vibe Coding Tops C-suite's List of Concerns, Retool Unveils First Platform to Extend Enterprise Governance to All AI-Coded Apps (Business Wire, 2026)
- The State of AI Governance in 2026 (Retool Blog, 2026)
- Retool Survey: Only 8% of Tech Leaders Have Strong AI Governance (Cybersecurity Insiders, 2026)
