Arquitetura de IA com governança e segurança desde o dia um

Adotar IA em um time de engenharia sem critérios definidos não é agilidade. É risco aceito sem consciência.

Governança de IA não significa criar um comitê. Significa decidir, antes de ligar qualquer ferramenta, quais dados podem sair da organização, quais decisões ainda precisam de um humano responsável e como o time vai saber, depois, o que a IA gerou. Essas três perguntas formam o núcleo de qualquer framework de adoção responsável.

O que define boa governança de IA em engenharia?

Frameworks maduros como o NIST AI Risk Management Framework e a norma ISO/IEC 42001 convergem em quatro funções: mapear riscos, medir impacto, gerenciar controles e governar de forma contínua. Para times de engenharia, isso se traduz em algo concreto:

• Classificar os dados que o time já usa no dia a dia (logs de produção, contratos, código proprietário, dados pessoais de usuários) e decidir quais desses podem ir para um LLM externo.
• Mapear as decisões que passam a envolver sugestão de IA (revisão de código, arquitetura, triagem de bugs) e definir quais exigem aprovação humana antes de virar artefato ou merge.
• Registrar a origem de cada entrega relevante: o PR foi gerado com apoio de IA? Isso precisa ser rastreável.

Esses três pontos não exigem ferramenta nova. Exigem acordo explícito dentro do time.

Quais são os riscos reais de ignorar isso?

O risco mais comum não vem de um ataque externo. Vem de comportamento cotidiano benigno. Um estudo de incidentes de 2025 mostra que a maioria dos vazamentos em ambientes LLM acontece quando engenheiros colam logs de produção em um chatbot para depurar um problema, ou enviam um trecho de contrato para ser resumido, sem perceber que o conteúdo vai para servidores de terceiros e pode ser usado para ajuste de modelos.

Credenciais e chaves de API aparecem em prompts com frequência alarmante. A OWASP Top 10 for LLM Applications lista vazamento de dados sensíveis e exposição de sistema como dois dos riscos mais críticos em ambientes de produção com LLMs.

Além do risco técnico, há o risco regulatório. O EU AI Act entra em vigor com a maioria das obrigações a partir de agosto de 2026, incluindo rastreabilidade de eventos e requisitos de supervisão humana para sistemas de alto risco. Times que operam com clientes europeus ou com dados de cidadãos da UE precisam começar agora a classificar seus sistemas por nível de risco.

No contexto brasileiro, o LGPD já impõe restrições sobre processamento de dados pessoais por terceiros, e a ausência de controles sobre quais dados vão para LLMs externos pode configurar violação.

Como estruturar as camadas de governança?

Governança não precisa ser pesada para ser eficaz. Uma abordagem em camadas permite começar simples e adicionar controles conforme o uso amadurece:

Camada 1: política de uso. Um documento de uma página que define o que pode ir para LLM externo (código sem dados sensíveis, textos públicos, rascunhos), o que não pode (logs com PII, credenciais, dados de clientes, propriedade intelectual estratégica) e o que requer aprovação caso a caso. Times que adotaram esse nível básico reduziram significativamente incidentes acidentais.

Camada 2: controle de acesso e ambientes. Separar qual ferramenta de IA pode ser usada em qual contexto. LLMs locais (modelos rodando na própria infraestrutura) para tarefas com dados sensíveis; ferramentas SaaS apenas para contextos sem informação confidencial. Variáveis de ambiente e secrets nunca devem aparecer em qualquer prompt.

Camada 3: human-in-the-loop obrigatório. Definir explicitamente quais categorias de decisão exigem revisão humana antes de se tornarem definitivas: código em sistemas críticos, mudanças de infraestrutura, decisões de arquitetura, geração de documentação legal ou contratual. Isso não é desconfiança da ferramenta; é distribuição adequada de responsabilidade.

Camada 4: audit trail. Rastrear, de forma sistemática, quando IA foi usada e em qual entrega. Pode ser tão simples quanto uma tag no PR (ai-assisted) ou tão sofisticado quanto integração com ferramentas de observabilidade. O que importa é que seja consistente e que os dados sirvam para análise posterior.

Se quiser aprofundar os padrões táticos do dia a dia, o post LLMs no fluxo de desenvolvimento: o que funciona cobre isso com mais detalhe.

Como evitar a burocracia sem perder o controle?

A armadilha mais comum ao falar em governança é imaginar um processo que leva mais tempo do que a tarefa em si. Isso acontece quando a governança é adicionada depois, como uma camada de aprovação, em vez de ser embutida nos fluxos que o time já usa.

Alguns sinais de que a governança está mal calibrada: ninguém sabe o que foi gerado com IA no último sprint; o time evita registrar uso de IA por medo de julgamento; as políticas existem mas ninguém as leu.

Alguns sinais de que está funcionando: o time consegue responder “qual percentual dos PRs do mês teve apoio de IA?” sem precisar investigar; incidentes potenciais são identificados na revisão, não em produção; novos integrantes recebem as políticas como parte do onboarding, não como exceção.

O tema de como a IA muda o onboarding de engenheiros tem nuances próprias, tratadas no post IA no onboarding técnico.

Sobre o lado filosófico de onde a IA acelera e onde ela esconde débito técnico, vale a leitura de Vibe coding vs. engenharia real.

Quais métricas indicam maturidade de governança?

Métricas ajudam a tornar o progresso visível e a identificar lacunas antes que virem incidentes:

Métrica	O que indica
% de PRs com origem de IA registrada	Completude do audit trail
Nº de incidentes evitados na revisão obrigatória	Efetividade do human-in-the-loop
Tempo de resposta a incidente de dados via LLM	Prontidão operacional
Cobertura da política de uso entre times	Alcance da governança
Nº de ferramentas externas autorizadas vs. em uso	Controle de shadow AI

Não é necessário medir tudo desde o início. Começar com rastreamento de origem e cobertura de política já dá visibilidade suficiente para os primeiros meses.

Como começar de forma prática?

O ponto de partida mais comum que funciona é um workshop curto com o time de engenharia para mapear três coisas: quais ferramentas de IA já estão sendo usadas (incluindo as não autorizadas oficialmente), quais tipos de dado o time já colocou em prompts, e quais decisões já foram tomadas com base em sugestão de IA sem revisão.

Esse mapeamento costuma revelar lacunas óbvias. A partir daí, um documento de política de uso e um acordo sobre rastreamento de PRs já representam uma governança funcional, sem comitê, sem ferramenta adicional e sem overhead.

A adoção de IA responsável não é uma etapa que vem depois de a ferramenta estar instalada. É a condição para que a ferramenta entregue valor de forma sustentável.