A pergunta que todo cliente faz quando descobre que IA esta escrevendo codigo junto com a equipe e sempre a mesma. Ela nao vai mexer no que nao devia? Nao vai ler o segredo do meu banco? Nao vai derrubar minha producao? Resposta curta: aqui ela nao consegue. Nao porque a gente confia muito nela. E porque alguem escreveu quatro regras antes dela comecar a digitar, e essas regras estao versionadas no Git como qualquer outro pedaco de codigo.
Esse texto explica as quatro portas que a IA encontra trancada quando trabalha junto com nossos desenvolvedores, em linguagem de negocio. Quem esta te vendendo "IA com governanca" deveria conseguir te mostrar as portas. Se nao consegue, voce esta pagando por uma boa demo, nao por governanca.
Por que esse texto existe
Quem nunca trabalhou com desenvolvedor pensa que IA escreve codigo sozinha, sem supervisao. Nao e assim. Existe um humano lendo cada alteracao antes dela chegar perto da producao. Mas humano cansa, humano descuida, humano clica em "aceitar" as 18h de sexta. Por isso, alem do humano, montamos uma camada extra: bloqueios automaticos que rodam toda vez que a IA tenta fazer alguma coisa. E essa camada que vamos descrever.
A logica e simples: defesa em camadas. Humano revisa. IA produz. Bloqueio automatico impede o que nao deveria nem ter sido tentado. Tres pontos de checagem, nao um.
Porta 1: A IA nao toca producao. Ponto.
Producao e o ambiente que seus clientes finais usam. Dev e a copia interna onde a equipe testa antes. A regra aqui e dura: IA opera so em dev. Qualquer comando da IA que tente mexer em producao e bloqueado antes de rodar.
Bloqueado o que, na pratica:
- Subir codigo direto pra branch principal do projeto sem revisao.
- Aplicar mudanca de infraestrutura na nuvem (criar servidor, derrubar servidor, mexer em firewall).
- Publicar um pacote de software no registro publico sem revisao.
- Apagar dados, dropar tabela, deletar instancia em nuvem.
Quem aplica em producao e um humano com responsabilidade de DevOps. A IA escreve, o humano aprova e aplica. Dois pares de olhos sempre. Cliente paga por essa cautela: previsibilidade.
Porta 2: A IA nao cria nem le arquivo de segredo
Sistemas guardam credenciais (senha do banco, chave de pagamento, token de integracao) em arquivos chamados .env e parecidos. Esses arquivos nao vao pro Git, ficam fora do controle de versao. A IA nao consegue ler nem criar esses arquivos.
A regra e granular. Templates de exemplo, que mostram o formato do arquivo sem trazer segredo real, sao liberados. Arquivos com segredo real, certificados, chaves privadas de servidor, contas de servico do Firebase, da Google Cloud, tudo barrado antes mesmo da IA comecar a escrever.
Por que isso importa pro seu projeto: se a credencial do seu banco de dados estivesse num arquivo dessa categoria, a IA nem teria visibilidade dele. Nao vaza o que nao consegue ler.
Porta 3: A IA e auditada toda vez que salva um arquivo
Suponha que a IA, num momento de descuido, escreva uma chave de API dentro de um arquivo qualquer. Pode acontecer (ela e estatistica, nao infalivel). Pra esse caso, todo arquivo que a IA salva passa por uma varredura automatica logo depois.
O que a varredura procura, em linguagem de negocio:
- Credencial de servidor em nuvem (AWS, Google, Anthropic, OpenAI).
- Token de integracao de pagamento (Mercado Pago, Stripe).
- Acesso a redes de codigo e comunicacao (GitHub, Slack).
- Link de banco de dados que tenha senha embutida nele.
- Senhas, tokens e qualquer texto que pareca segredo.
Se algum padrao e detectado, a IA recebe alerta imediato e e instruida a remover. Acontece no mesmo segundo. Nao e varredura noturna. Nao e processo agendado pra rodar amanha.
Porta 4: Nada com segredo entra no historico do Git
O Git e o historico permanente do codigo. O que entra la fica registrado pra sempre. Por isso a quarta porta: antes de cada confirmacao de alteracao no Git, uma varredura final e obrigatoria. Se segredo escapou nas etapas anteriores, ele e interceptado aqui. A confirmacao nao acontece.
Esse e o ultimo ponto de defesa. Depois dele, o segredo entraria pro historico, e tirar segredo do historico do Git e trabalhoso e nunca e totalmente limpo. Por isso a interceptacao e dura: bloqueia, devolve mensagem de erro, forca a correcao.
A prova de que a porta tranca mesmo
Aconteceu enquanto a equipe escrevia esse proprio texto. A pessoa estava abrindo o pedido de revisao no Git (uma especie de ata de mudanca) que documentava as quatro portas. Pra explicar o que cada porta faz, a descricao do pedido mencionava palavras como "producao", "chave privada" e o nome de comandos perigosos.
Resultado: a propria porta bloqueou a equipe tres vezes. Recusou a primeira mensagem porque dizia "producao" perto de "comando de infraestrutura". Recusou a segunda porque mencionava "permissao insegura". Recusou a terceira porque o texto descritivo continha o padrao tipico de uma chave criptografica.
Pode parecer engracado. Nao e. E a prova de que a porta nao checa quem esta passando, nao tem lista vip, nao relaxa quando e a propria equipe. Se nem a gente passa quando descuida, segredo de cliente tambem nao passa.
Politica versionada, nao promessa verbal
Tudo isso, as quatro portas, mora num arquivo do Git. Qualquer pessoa do time abre, le, audita, propoe mudanca. Nao e uma promessa que a gente faz numa reuniao. E um arquivo que tem historico de quem mexeu, quando, e por que.
Pro cliente, isso significa tres coisas praticas:
- Auditabilidade real. Voce pode pedir pra ver o arquivo. A gente mostra.
- Politica igual pra todos. Nao tem cliente A e cliente B. A regra e uma so, pra todo projeto que passa pela Steply.
- Evolucao rastreada. Quando a gente endurece uma regra (acrescenta um padrao novo de credencial pra detectar, por exemplo), fica registrado.
LGPD, contrato de processamento de dados, auditoria de fornecedor: tudo isso fica mais simples quando a regra esta num arquivo, nao na cabeca de alguem.
O que muda pro seu projeto
Se voce esta avaliando trabalhar com IA na construcao do seu produto, e e o decisor que tem que responder pro conselho sobre risco, a pergunta certa nao e "voces usam IA?". A pergunta e: como o fornecedor impede a IA de fazer o que nao deveria? Se a resposta envolve frase tipo "a gente confia no time", continue procurando.
A nossa resposta e diferente. A gente trata IA como vendor com guard-rails versionados, igual trataria um estagiario com acesso restrito. Quer entender como aplicar essa logica no seu projeto, conversa rapida resolve: fala com a gente, mostramos as portas funcionando ao vivo.
