Tech Leads Club · Guia de Referência Completo
Framework de Adoção de IA
Um guia de 7 fases para times de engenharia que querem adotar IA de forma estruturada e sustentável — do diagnóstico organizacional à escala corporativa. Construído com base em experiência prática de desenvolvedores e líderes técnicos da comunidade Tech Leads Club. Este documento é autossuficiente: contém todas as perguntas, metodologias, conteúdos e critérios do framework para uso sem acesso ao app.
Beta · v0.5 · Distribuído gratuitamente pela comunidade Tech Leads Club · Construído com base em experiência de devs e líderes técnicos · comece.techleads.club
Mapa da jornada
1 · Diagnóstico → 2 · Time AI Enablers → 3 · Time Piloto → 4 · Gargalos → 5 · Adoção Progressiva → 6 · Governança → 7 · Escala
Objetivo da fase
Mede o nível de prontidão da organização e da engenharia para adoção de IA, identificando lacunas de cultura, maturidade operacional e capacidade técnica. O resultado orienta todas as fases seguintes e serve como baseline para medir evolução.
Metodologia de pontuação
Cada dimensão recebe pontuação de 1.0 (baixo), 2.0 (médio) ou 3.0 (alto) com base na resposta selecionada. O score geral é a média das 9 dimensões. O gargalo principal é a dimensão de menor pontuação — em caso de empate, o critério de desempate é a dimensão de maior impacto operacional na adoção de IA.
Baixo
Score < 1,67
Organização tem bloqueios significativos para adoção de IA
Médio
1,67 ≤ Score < 2,34
Organização tem base, mas com gaps que precisam de atenção
Alto
Score ≥ 2,34
Organização está pronta para adoção acelerada de IA
Os 3 macro-blocos
A
Cultura & Autonomia
Avalia o grau de autonomia das equipes, a flexibilidade organizacional e o senso de responsabilidade sobre entregas e decisões técnicas.
Dimensões: Autonomia de Engenharia · Flexibilidade Organizacional · Ownership e Accountability
B
Maturidade Operacional
Mede a capacidade de entrega contínua, os padrões de qualidade adotados e a velocidade com que as equipes recebem e processam feedback.
Dimensões: Maturidade de Continuous Delivery · Maturidade de Qualidade · Velocidade de Feedback
C
Capacidade Técnica & IA
Examina a experiência do desenvolvedor no código, o nível de adoção de inteligência artificial e a senioridade técnica média das equipes.
Dimensões: Developer Experience e Qualidade do Código · Maturidade no Uso de IA · Senioridade da Engenharia
As 9 perguntas do diagnóstico
Questão 1 · Autonomia de Engenharia
Os engenheiros do seu time conseguem liderar funcionalidades de ponta a ponta — do design técnico ao deploy — sem depender de aprovações externas ao squad?
Mede: Grau de autonomia técnica real dos engenheiros para tomar decisões e entregar sem bloqueios externos.
Impacto na adoção de IA: Times com baixa autonomia não conseguem incorporar IA no fluxo de trabalho porque cada mudança de processo exige aprovação de fora do squad.
Baixo · 1,0
Engenheiros dependem de múltiplas aprovações externas para a maioria das decisões técnicas. Funcionalidades passam por arquitetos centrais, comitês ou outras equipes antes de qualquer avanço. O ciclo de decisão é longo e previsível somente para quem está fora do squad.
Médio · 2,0
Engenheiros têm autonomia para a maioria das decisões técnicas rotineiras, mas ainda dependem de aprovação externa para mudanças de arquitetura, tecnologia ou impacto cross-squad. A exceção vira regra com alguma frequência.
Alto · 3,0
Engenheiros lideram funcionalidades de ponta a ponta com ownership técnico completo. Decisões de arquitetura, tecnologia e deploy são feitas dentro do squad. Coordenação com outros times é por convenção, não por aprovação.
Questão 2 · Flexibilidade Organizacional
Quando seu time identifica uma nova prática, ferramenta ou tecnologia relevante, quanto tempo leva para experimentá-la formalmente no ambiente de trabalho?
Mede: Velocidade com que a organização consegue avaliar e adotar novas práticas tecnológicas sem burocracia excessiva.
Impacto na adoção de IA: Organizações com baixa flexibilidade levam meses para aprovar ferramentas de IA, perdendo janelas de adoção enquanto a tecnologia avança rapidamente.
Baixo · 1,0
Adoção de novas práticas ou ferramentas leva meses e exige múltiplos níveis de aprovação. O processo de avaliação é informal ou inexistente, resultando em decisões lentas e frequentemente bloqueadas por fatores políticos ou organizacionais.
Médio · 2,0
Existe um processo de avaliação de novas tecnologias, mas o ciclo médio leva de 4 a 8 semanas. Há critérios definidos, mas aprovações ainda passam por múltiplas camadas. Times conseguem fazer experimentos controlados, mas a adoção formal é lenta.
Alto · 3,0
Times conseguem iniciar experimentos formais em menos de 2 semanas. O processo de adoção é claro, rápido e com critérios objetivos. Decisões de tecnologia são descentralizadas e baseadas em evidências, não em hierarquia.
Questão 3 · Ownership e Accountability
Quando algo falha em produção em um sistema do seu time, o processo de resolução e aprendizado é conduzido pelo próprio squad — incluindo análise de causa raiz e ações preventivas?
Mede: Grau em que times assumem responsabilidade completa pelos resultados das suas entregas, incluindo operação e incidentes.
Impacto na adoção de IA: Times sem ownership real de produção não têm incentivo para usar IA em observabilidade e detecção de problemas, pois não se sentem responsáveis pelo sistema em execução.
Baixo · 1,0
Incidentes são frequentemente escalados para equipes externas (SRE, ops, arquitetura) para resolução. O squad que desenvolveu não é o responsável primário pela operação. Análises de causa raiz são raras ou conduzidas por outra equipe.
Médio · 2,0
O squad é responsável pelo on-call mas ainda delega parte da resolução para equipes de suporte especializadas. Análises de causa raiz acontecem para incidentes maiores, mas ações preventivas têm acompanhamento inconsistente.
Alto · 3,0
O squad tem ownership completo do sistema em produção — detecta, resolve, analisa e age preventivamente. On-call é rotativo dentro do time. Cada incidente gera aprendizado documentado e melhorias rastreáveis.
Questão 4 · Maturidade de Continuous Delivery
Com que frequência seu time realiza deploys em produção e qual o nível de automação desse processo?
Mede: Frequência e previsibilidade das entregas em produção, com o grau de automação que as suporta.
Impacto na adoção de IA: Pipelines manuais e deploys infrequentes tornam impossível usar IA em code review, análise de PR e sugestões de refatoração de forma integrada ao fluxo real de entrega.
Baixo · 1,0
Deploys acontecem mensalmente ou com menor frequência e envolvem processos manuais significativos. Cada deploy é um evento de alto risco que requer coordenação entre múltiplas equipes. O pipeline de CI existe mas não garante deploy automatizado.
Médio · 2,0
Deploys acontecem semanalmente com automação parcial. O pipeline de CI/CD cobre build e testes, mas o deploy para produção ainda tem etapas manuais ou janelas de manutenção. A frequência é limitada por processo, não por capacidade técnica.
Alto · 3,0
Deploys acontecem múltiplas vezes por semana ou diariamente, com pipeline totalmente automatizado do commit ao deploy. Feature flags separam deploy de release. O processo é previsível e reversível, com rollback automatizado quando necessário.
Questão 5 · Maturidade de Qualidade
Qual é o nível de automação de testes e o grau em que o próprio time de engenharia é responsável pela qualidade do código em produção?
Mede: Maturidade da automação de testes e do ownership de qualidade pelo time de engenharia.
Impacto na adoção de IA: Código sem cobertura de testes torna arriscada a adoção de IA para geração e refatoração de código, pois não há rede de segurança para validar o output da IA automaticamente.
Baixo · 1,0
Testes automatizados cobrem menos de 30% da base de código ou são inconsistentes entre módulos. Qualidade é responsabilidade de QA manual separado do time de desenvolvimento. Bugs em produção são frequentes e difíceis de rastrear.
Médio · 2,0
Há cobertura de testes automatizados para as principais funcionalidades, mas a cobertura é desigual e testes de integração são limitados. QA ainda tem papel separado, mas o time de engenharia assume mais responsabilidade pela qualidade do que antes.
Alto · 3,0
Cobertura de testes automatizados é alta e consistente. O próprio time de engenharia define e mantém a qualidade. Quality gates no pipeline bloqueiam código com cobertura insuficiente ou falha em testes. QA automatizado é parte integral do processo de desenvolvimento.
Questão 6 · Velocidade de Feedback
Quanto tempo leva desde um commit até o feedback completo — testes, build, análise estática — e até o primeiro sinal de comportamento em produção?
Mede: Velocidade dos ciclos de feedback desde o código até a observabilidade em produção.
Impacto na adoção de IA: Ciclos de feedback longos limitam a eficácia de IA em code review e pair programming, pois o custo de validar sugestões da IA é alto quando o loop de feedback demora horas.
Baixo · 1,0
O pipeline de CI leva mais de 30 minutos para dar feedback. Monitoramento de produção é reativo — problemas são detectados por usuários antes de alertas internos. O ciclo completo de commit a sinal de produção leva horas ou dias.
Médio · 2,0
O pipeline de CI entrega feedback em 10 a 30 minutos. Há monitoramento básico de produção com alertas configurados para os principais erros. O tempo de detecção de problemas em produção é medido em horas.
Alto · 3,0
O pipeline de CI entrega feedback em menos de 10 minutos. Monitoramento de produção é proativo com detecção de anomalias antes de impacto ao usuário. O ciclo completo de commit a sinal de produção é medido em minutos.
Questão 7 · Developer Experience e Qualidade do Código
Como você avalia a qualidade da arquitetura do código e a produtividade real dos engenheiros no dia a dia de desenvolvimento?
Mede: Saúde da arquitetura de código e a experiência real de desenvolvimento — tempo de onboarding, facilidade de mudança, nível de débito técnico.
Impacto na adoção de IA: Código com alto débito técnico e arquitetura acoplada limita o que IA consegue ajudar — sugestões de IA são ineficazes quando o contexto do código é fragmentado e difícil de entender mesmo para humanos.
Baixo · 1,0
A base de código tem alto débito técnico que torna mudanças arriscadas e lentas. Onboarding de novos engenheiros leva semanas devido à falta de documentação e à complexidade acidental. Ambiente de desenvolvimento local é instável e difícil de configurar.
Médio · 2,0
Há partes da base de código bem estruturadas e outras com débito técnico significativo. Onboarding é possível em alguns dias com acompanhamento. Ambiente de desenvolvimento funciona mas tem inconsistências entre membros do time.
Alto · 3,0
A arquitetura é clara, modular e documentada. Onboarding de novos engenheiros acontece em menos de 2 dias produtivos. Ambiente de desenvolvimento é reproduzível e consistente. Débito técnico é monitorado e priorizado sistematicamente.
Questão 8 · Maturidade no Uso de IA
Em que extensão ferramentas de IA já estão integradas ao fluxo de desenvolvimento do seu time — desde sugestões de código até automação de tarefas de engenharia?
Mede: Grau de integração de IA no fluxo de desenvolvimento e a profundidade do uso além do básico.
Impacto na adoção de IA: Dimensão de auto-referência: o nível atual de uso de IA revela a prontidão do time para aprofundar a adoção e o quanto a organização está preparada para extrair valor das próximas ondas de IA.
Baixo · 1,0
IA não é usada sistematicamente no fluxo de desenvolvimento. Alguns membros podem usar ferramentas individualmente, mas sem padronização, incentivo ou política organizacional. O time não tem visão clara do que IA pode oferecer para o desenvolvimento.
Médio · 2,0
Assistentes de código com IA são usados pela maioria do time, mas o uso está limitado a sugestões de código e completions. IA ainda não é usada sistematicamente para testes, revisão de código, documentação ou refatoração.
Alto · 3,0
IA está integrada em múltiplas etapas do fluxo de desenvolvimento — sugestão de código, revisão, geração de testes, documentação e análise de pull requests. O time mede o impacto do uso de IA e usa os dados para otimizar a adoção.
Questão 9 · Senioridade da Engenharia
Qual é a proporção de engenheiros sêniores e staff no seu time — profissionais capazes de tomar decisões técnicas complexas com autonomia real?
Mede: Capacidade técnica coletiva do time para operar com autonomia, avaliar trade-offs e liderar decisões de arquitetura.
Impacto na adoção de IA: Times com baixa senioridade não conseguem avaliar criticamente o output da IA, resultando em adoção superficial ou em código gerado por IA que cria novos problemas não detectados.
Baixo · 1,0
Menos de 20% do time é composto por engenheiros sêniores ou staff. Decisões técnicas complexas frequentemente dependem de consultoria externa ao squad ou estão concentradas em 1–2 pessoas. O time tem dificuldade em operar autonomamente em problemas novos.
Médio · 2,0
Entre 20% e 40% do time são sêniores ou staff. Há capacidade técnica para a maioria das decisões rotineiras, mas problemas de arquitetura ou escala ainda requerem apoio externo frequente. O time está em transição para maior autonomia técnica.
Alto · 3,0
Mais de 40% do time são sêniores, staff ou principal. O time tem capacidade técnica para tomar decisões complexas de forma autônoma. Há engenheiros de referência que elevam o nível técnico coletivo e mentoram a progressão dos demais.
Recomendações por dimensão e nível
| Dimensão | Baixo | Médio | Alto |
|---|---|---|---|
| Autonomia | Mapear dependências externas que bloqueiam decisões técnicas dos times. Implementar ownership por squad com escopo claro. | Estabelecer critérios objetivos para escalada de decisões versus decisão local. Criar fóruns de arquitetura que preservem autonomia. | Documentar os mecanismos de autonomia para replicar em novos times. Auditar periodicamente se a autonomia está gerando coerência técnica. |
| Flex. Organizacional | Identificar os principais pontos de aprovação burocrática que atrasam adoção de tecnologia. Criar processo de experimentação controlada. | Formalizar um framework de decisão para avaliação de novas tecnologias. Reduzir o ciclo de feedback entre proposta e decisão para menos de 2 semanas. | Documentar o modelo de adoção como referência para novos times e produtos. Avaliar se a velocidade de adoção está criando débito de governança. |
| Ownership | Definir SLOs por squad e torná-los visíveis para toda a engenharia. Estabelecer on-call rotativo por produto, não por componente. | Conectar métricas de negócio aos resultados de engenharia de cada squad. Implementar revisões regulares de incidentes com ownership explícito. | Verificar se o ownership está distribuído de forma sustentável ou concentrado em poucos. Usar dados de incidents para orientar priorização técnica. |
| Cont. Delivery | Automatizar o processo de build e deploy antes de qualquer outra iniciativa de CD. Medir lead time atual para estabelecer baseline. | Implementar feature flags para separar deploy de release e reduzir risco. Reduzir o tamanho médio dos pull requests para acelerar o ciclo. | Garantir que a frequência de deploy não esteja degradando a estabilidade de produção. Explorar deployment progressivo (canary, blue-green). |
| Qualidade | Estabelecer cobertura mínima de testes automatizados como critério de merge. Criar testes de integração para os 5 componentes mais críticos. | Mover testes manuais de regressão para automação progressivamente por release. Implementar quality gates no pipeline de CI. | Medir o custo de manutenção dos testes para prevenir debt em automação. Avaliar a eficácia dos testes em detectar defeitos antes de produção. |
| Vel. de Feedback | Instrumentar o pipeline de CI para medir tempo médio de feedback de testes. Criar alertas de produção com detecção de anomalias. | Reduzir o tempo de execução do pipeline de CI para menos de 10 minutos. Implementar monitoramento de experiência real do usuário (RUM). | Avaliar se a velocidade de feedback está sendo usada ativamente em decisões de produto. Documentar o fluxo como padrão para novos produtos. |
| DX & Código | Realizar auditoria de débito técnico nas áreas de maior volume de alteração. Medir tempo de onboarding de novos engenheiros. | Padronizar ambiente de desenvolvimento local com containers reproduzíveis. Criar convenções de código documentadas e aplicadas via linting. | Medir a correlação entre qualidade do código e velocidade de entrega. Investir em abstrações internas que reduzam código repetitivo. |
| Uso de IA | Adotar assistentes de código com IA para toda a engenharia como ponto de partida. Definir casos de uso concretos onde IA gera ganho mensurável. | Medir o impacto do uso de IA em velocity, qualidade e tempo de ciclo. Expandir uso de IA para revisão de código, geração de testes e documentação. | Explorar agentes de IA para tarefas de refatoração e automação de fluxos repetitivos. Estabelecer governança para uso de IA. |
| Senioridade | Criar plano de carreira técnico com critérios explícitos de progressão para sênior. Identificar engenheiros com potencial e oferecer mentoria estruturada. | Revisar distribuição de tarefas complexas para desenvolver sêniores emergentes. Criar fóruns técnicos onde sêniores compartilhem decisões. | Avaliar se a senioridade está sendo usada para elevar o nível técnico coletivo. Documentar critérios de promoção para staff/principal. |
Objetivo da fase
Define quem é o dono da jornada de adoção de IA antes de qualquer experimento começar. Consolida o Time AI Enablers com papéis, responsabilidades e rituais — garantindo que o piloto (Fase 3) tenha patrocínio, estrutura e um responsável por transformar aprendizados em expansão. Dimensiona o time em um de 3 arquétipos baseados no tamanho da engenharia.
Os 3 arquétipos de Time AI Enablers
Lean
Empresas pequenas · Sizing: 0,5–1 pessoa em part-time
Responsabilidades técnicas
- Avaliar e recomendar ferramentas de IA para o contexto do time
- Criar guias de configuração e boas práticas de prompts
- Monitorar qualidade do código gerado com assistência de IA
- Definir guardrails mínimos de uso: o que pode e não pode ir em prompt, revisão obrigatória, dados sensíveis
- Definir governança básica: política de ferramentas aprovadas, critério de revisão e owner das decisões
Responsabilidades de processo
- Facilitar retrospectivas focadas em uso de IA mensalmente
- Documentar casos de uso validados e lições aprendidas
- Manter o backlog de experimentos de IA atualizado
Responsabilidades de cultura
- Criar ambiente seguro para experimentação sem punição por falhas
- Compartilhar aprendizados informalmente via canais de chat
- Celebrar pequenas vitórias de adoção de IA com o time
- Estabelecer Definition of Done que inclua critério mínimo de qualidade — o dev é dono dos testes do seu código, não QA
- Introduzir o conceito de Shift Left: identificar problemas antes do merge, não depois do deploy
Anti-responsabilidades
- Não é responsável por desenvolver features com IA no lugar de outros
- Não centraliza todas as decisões de ferramentas de IA
- Não substitui o papel de tech lead ou engineering manager
Ritual principal
Check-in quinzenal de 30 min com o time completo para compartilhar aprendizados, desbloquear impedimentos e ajustar prioridades de experimentação.
Métricas de saúde
- Leading: % do time usando IA semanalmente, # experimentos iniciados/mês, tempo médio de onboarding em nova ferramenta
- Lagging: variação de velocity antes/depois, taxa de defeitos em código com IA
Plano 30/60/90 dias
- 30d: Escolher 1–2 ferramentas, onboarding de todo o time
- 60d: Documentar 2 casos de uso validados com ganho mensurável
- 90d: Revisar governança básica e critérios de expansão
Dedicado
Empresas médias · Sizing: 2–3 pessoas dedicadas
Responsabilidades técnicas
- Avaliar, pilotar e standardizar ferramentas de IA em múltiplos times
- Criar e manter biblioteca de prompts, templates e integrações internas
- Definir critérios de qualidade para código assistido por IA e implementar gates no pipeline
- Definir e manter guardrails formais priorizados por criticidade (CRÍTICA → ALTA → MÉDIA)
- Definir governança estruturada: políticas de uso, ciclos de revisão, compliance básico e processo de aprovação de novas ferramentas
- Desenvolver infraestrutura compartilhada básica: MCPs internos para acesso padronizado a contexto e ferramentas da organização
Responsabilidades de processo
- Facilitar cerimônias de adoção bi-semanais com representantes de cada squad
- Gerenciar backlog de iniciativas de IA com priorização por impacto e esforço
- Reportar métricas de adoção para liderança mensalmente
Responsabilidades de cultura
- Treinar tech leads de todos os squads nas melhores práticas de uso de IA
- Criar conteúdo interno (guias, videos curtos, demos ao vivo)
- Identificar e apoiar campeões de IA em cada squad
- Implementar e disseminar Shift Left: quality gates em pre-commit e PR — nada chega em staging sem passar por testes e análise estática automáticos
- Padronizar Definition of Done cross-squad com critérios de qualidade e cobertura mínima como requisito de merge
- Promover cultura de "dev é dono da qualidade" — IA gera testes junto com o código, não depois
Anti-responsabilidades
- Não é o único time que pode usar ou avaliar ferramentas de IA
- Não substitui a autonomia técnica de cada squad
- Não é responsável por resultados de produto dos outros times
Rituais principais
- Weekly sync interno (30 min) para alinhamento do Time AI Enablers
- Bi-weekly com representantes dos squads para disseminação de aprendizados
Plano 30/60/90 dias
- 30d: Mapa de maturidade de todos os squads + priorizar 3 iniciativas de alto impacto
- 60d: Pelo menos 50% dos squads com pelo menos 1 ferramenta de IA padronizada
- 90d: Relatório de impacto consolidado + roadmap de adoção para próximo trimestre
Distribuído
Empresas grandes · Sizing: 4–6 pessoas centrais + 1 campeão por squad
Time central — responsabilidades
- Definir a estratégia e o roadmap de adoção de IA para toda a organização
- Estabelecer e manter governança corporativa de IA: políticas, auditoria, ciclos de revisão e alinhamento regulatório
- Definir e evoluir guardrails de segurança e compliance para toda a engenharia, com revisão contínua de riscos emergentes
- Desenvolver e operar infraestrutura compartilhada avançada:
- MCPs internos — servidores Model Context Protocol para expor dados, APIs e ferramentas internas aos agentes de IA de forma padronizada e segura
- Marketplace de skills — catálogo centralizado de prompts, agentes, templates e fluxos de IA validados e reutilizáveis pelos squads
- AI Harness — infraestrutura de orquestração, sandboxing e observabilidade para agentes de IA rodando em contexto produtivo
- Treinar e apoiar os campeões de IA em cada squad
Campeões de IA por squad
- Ser o ponto focal de adoção de IA no squad (não dedicação exclusiva)
- Adaptar as melhores práticas centrais ao contexto do squad
- Reportar bloqueios e aprendizados ao time central mensalmente
Anti-responsabilidades (time central)
- Não é um gargalo de aprovação para iniciativas de IA nos squads
- Não é responsável pela execução técnica de IA em cada squad
- Não substitui a liderança técnica local dos squads
Plano 30/60/90 dias
- 30d: Identificar e onboarding dos campeões de IA + mapa de maturidade por squad
- 60d: Framework de governança v1 publicado + pelo menos 30% dos squads com adoção ativa
- 90d: Plataforma interna de IA v1 + 60% dos squads com métricas de adoção reportando
Programa de Capacitação Contínua
O Time AI Enablers é o dono do programa de capacitação. Capability humana não é um evento pontual — é fio condutor de todas as fases. A matriz abaixo define 4 níveis de proficiência e 4 áreas de competência que formam o currículo de AI fluency da organização.
Matriz de 4 níveis de proficiência
| Nível | Característica | Critério prático | Gate de avanço |
|---|---|---|---|
| L0 · Curioso | Ouviu falar, ainda não usa IA sistematicamente | Não tem ferramenta configurada no fluxo diário | Obrigatório sair do L0 antes de usar IA em contexto produtivo |
| L1 · Aplicador | Usa IA no fluxo diário com fluência básica | Pelo menos 1 ferramenta ativa; sabe estruturar prompts básicos e iterar | Gate de entrada para Fase 3 (Piloto): 100% do time piloto em ≥ L1 |
| L2 · Crítico | Avalia output com senso crítico; sabe quando NÃO usar IA | Reverte sugestões ruins; identifica hallucinations; distingue uso seguro de arriscado | Gate para nível "team" na Fase 5: ≥ 60% do time em L2 por estágio |
| L3 · Multiplicador | Ensina, padroniza, audita o uso de IA nos outros | Cria templates de prompt, treina peers, define guidelines técnicas; campeão de squad | Meta de escala: ≥ 1 L3 por squad; ≥ 5% da engenharia total em L3 |
4 áreas de competência (currículo)
| Área | O que cobre | Exemplo de atividade formativa |
|---|---|---|
| 1. Prompt Engineering & Colaboração | Como dialogar com IA, dar contexto, iterar, usar system prompts e templates | Workshop prático: reescrever prompts reais do time para melhorar qualidade de output |
| 2. Crítica de Output | Avaliar qualidade, identificar erros sutis, calibrar confiança por tipo de tarefa | Lab de "caça ao hallucination": exercícios com outputs propositalmente errados |
| 3. Segurança e Governança de Uso | Quando IA pode/não pode ser usada, dados sensíveis, PI, compliance, guardrails | Simulação de incidente: "O que você faria se a IA gerasse código com PII hard-coded?" |
| 4. Tooling Específico do Stack | Configuração, atalhos, integrações e boas práticas das ferramentas aprovadas | Sessão hands-on no editor com o setup padrão da organização |
Modelo de aprendizado 70/20/10
70%
Experiencial
Prática real no fluxo de trabalho — usar IA em tasks reais do sprint, experimentar no contexto do próprio código
20%
Social
Pair programming com IA, demos quinzenais de casos de uso, retros de aprendizado, office hours com campeões
10%
Formal
Workshops estruturados, leituras curadas, assessments de proficiência, trilhas online de AI literacy
Cadência de assessment: auto-avaliação trimestral com validação por par (peer review do nível declarado). O campeão de squad (L3) é o validador local. Resultados publicados no heatmap de capability (Fase 7 · MET-A04).
Objetivo da fase
Com o Time AI Enablers formado e o dono da jornada definido, esta fase seleciona qual squad de produto vai ser o primeiro a experimentar IA em contexto real de produção. Avalia prontidão do time candidato e gera um plano operacional completo para o ciclo piloto.
Dimensões avaliadas (scoring ponderado)
O formulário coleta dados sobre 5 dimensões do time candidato ao piloto. Autonomia, Senioridade e Velocidade de Feedback têm peso 2× (mais determinantes para o sucesso do piloto). Segurança psicológica e estabilidade de roadmap têm peso 1×. Score total ÷ 8 = score de prontidão (mesmos thresholds da Fase 1).
| Dimensão | Peso | Pergunta avaliada |
|---|---|---|
| Autonomia Técnica | 2× | O time candidato pode tomar decisões técnicas e experimentar ferramentas sem aprovações externas ao squad? |
| Senioridade | 2× | O time tem engenheiros sêniores capazes de avaliar criticamente o output da IA e orientar adoção responsável? |
| Velocidade de Feedback | 2× | O pipeline de CI/CD do time permite ciclos de feedback rápidos (<10 min) e deploys frequentes? |
| Segurança Psicológica | 1× | O time se sente seguro para experimentar, cometer erros e reportar problemas sem medo de julgamento? |
| Estabilidade de Roadmap | 1× | O roadmap do time tem estabilidade suficiente para dedicar capacidade ao piloto sem interrupções frequentes? |
Exemplos de ferramentas de IA por categoria
Lista ilustrativa — não exaustiva e não endossada. O mercado de ferramentas de IA evolui rápido; use como ponto de partida para avaliação, não como lista definitiva. Critério de seleção para o piloto deve considerar stack, contexto de segurança e maturidade do time.
GitHub Copilot
Codificação Autocompletar e geração de código inline no editor. Prioritário para times com baixo DX ou feedback_speed.
Cursor
Codificação IDE com IA integrada para edição conversacional de código. Prioritário para times com baixo DX ou autonomia.
Amazon Q Developer
Codificação Assistente de código AWS-nativo com integração a repositórios. Indicado para stacks AWS.
Codeium
Codificação Autocompletar gratuito compatível com múltiplos IDEs. Boa opção de entrada sem custo.
CodeRabbit
Revisão Revisão automática de PRs com sugestões contextualizadas. Prioritário para times com baixa velocidade de feedback ou qualidade.
Notion AI
Planejamento Síntese e geração de documentação técnica assistida. Indicado para times com baixo ownership ou org_flexibility.
Linear
Planejamento Gestão de projetos com triagem e priorização assistidas. Indicado para times com baixa autonomia ou org_flexibility.
Playwright + AI Codegen
Testes Geração automática de testes E2E via gravação e IA. Prioritário para times com baixa qualidade ou continuous delivery.
Testim
Testes Testes funcionais com manutenção autoadaptativa por IA. Indicado para times com baixa maturidade de qualidade.
Datadog AI Insights
Monitoramento Detecção de anomalias e análise de causa raiz assistida. Prioritário para times com baixo feedback_speed ou continuous delivery.
Métricas de sucesso do piloto (por nível de prontidão)
Baseado em: MIT/Microsoft/Accenture RCT (4.867 devs, 2025) · Jellyfish (146k tickets) · McKinsey AI Software (2025) · DORA State of AI 2025. Atenção: DORA 2025 confirma que IA é amplificador — times sem qualidade e testes sólidos registraram aumento de bugs com IA. Métricas de nível baixo priorizam adoção segura antes de velocity.
| Baixo — foco em adoção e segurança | Médio — foco em tempo e qualidade | Alto — foco em outcomes |
|---|---|---|
| ≥ 80% dos membros usando ao menos 1 ferramenta de IA ativamente após 4 semanas (benchmark Accenture: 80%+ de adoção) | Redução de 20% no tempo de revisão de PRs em relação ao baseline (benchmark Jellyfish: -26% PR review time) | Aumento de 25% em tasks completadas por sprint em relação ao baseline (benchmark MIT: +26% completed tasks) |
| ≥ 70% do time relata confiança no código gerado por IA após revisão (DORA 2025: 30% ainda não confiam — construir confiança é pré-condição) | Redução de 15% no coding time em tarefas cobertas por IA (benchmark Jellyfish: -20% coding time) | Redução de 20% em defeitos reportados por cliente ou QA nos módulos do piloto (benchmark McKinsey top performers: -20–30% defects) |
| Zero incidentes de produção causados diretamente por código gerado por IA sem revisão adequada | Taxa de bugs em código com IA igual ou inferior ao código manual — ausência de regressão de qualidade (alerta: Uplevel registrou +41% bugs sem guardrails) | Pelo menos 3 estágios do SDLC com IA no nível "team" e métricas de impacto documentadas |
| Processo de revisão obrigatória de código gerado por IA documentado e seguido por 100% do time | Pelo menos 2 casos de uso documentados com ganho mensurável e reproduzível | DORA baseline estabelecido e ao menos 1 métrica (deployment frequency ou change failure rate) com melhora mensurável |
| Satisfação do time com ferramentas de IA ≥ 7/10 após 8 semanas (Accenture: 90% maior satisfação, 95% curtem mais programar) | Guia interno de boas práticas de prompt publicado e adotado por ≥ 80% do time | Piloto documentado e apresentado a ao menos 1 squad candidato à expansão — playbook validado e reutilizável |
Gate de capability (pré-requisito de entrada)
Antes de iniciar o piloto, 100% dos membros do time selecionado devem atingir L1 · Aplicador. O Time AI Enablers (Fase 2) coordena o onboarding de capacitação antes do kickoff — o piloto não começa com ninguém em L0.
Critérios de expansão além do piloto (por nível de prontidão)
| Baixo | Médio | Alto |
|---|---|---|
| Todos os membros do time piloto completaram onboarding nas ferramentas de IA e conseguem usá-las de forma independente | Pelo menos 2 fluxos de desenvolvimento com IA estão documentados com métricas de ganho | Todos os critérios de sucesso do piloto atingidos e documentados com dados |
| Pelo menos 1 processo de revisão de código gerado por IA está documentado e sendo seguido consistentemente | Time piloto atingiu as metas de velocity e qualidade definidas no início do piloto | Time piloto capaz de integrar, avaliar e padronizar novas ferramentas de IA de forma autônoma |
| Nenhum incidente de produção causado por adoção de IA não supervisionada nos últimos 30 dias | Pelo menos 1 membro sênior do time piloto preparado para liderar adoção em outro time | Governança básica de uso de IA definida (critérios de qualidade, revisão obrigatória, casos de uso aprovados) |
| Liderança técnica do time piloto capaz de treinar ao menos 1 outro time nas práticas adotadas | Playbook de adoção de IA revisado e validado pelo time antes da expansão | Ao menos 1 apresentação interna realizada com resultados do piloto para candidatos à expansão |
Objetivo da fase
Consolida os gargalos identificados nas fases anteriores, prioriza-os por impacto, esforço e risco, e gera um plano sequenciado em 3 trilhas com marcos relativos. O diferencial desta fase é que o usuário pode editar a lista de gargalos antes da geração — adicionando, removendo ou ajustando itens.
Fórmula de priorização
Score = (impacto × 3) + (esforço_inverso × 2) + (risco × 2)
Cada variável é avaliada de 1 a 3. Esforço inverso: esforço baixo = 3, médio = 2, alto = 1.
Score máximo: 15 · Score mínimo: 7
Crítico: score ≥ 11 · Médio: score 7–10
As 3 trilhas do plano
Trilha Técnica
- Débito técnico impedindo adoção de IA
- Pipeline de CI/CD com automação insuficiente
- Cobertura de testes abaixo do mínimo seguro
- Ambiente de desenvolvimento instável ou não reproduzível
- Arquitetura acoplada que dificulta integração de ferramentas
- Ausência de observabilidade adequada em produção
Trilha Organizacional
- Processos de aprovação lentos para adoção de ferramentas
- Falta de ownership claro sobre iniciativas de IA
- Ausência de estrutura dedicada (Time AI Enablers)
- Roadmap instável que interrompe experimentos continuamente
- Dependências externas não gerenciadas que bloqueiam decisões
- Falta de patrocínio executivo claro para a iniciativa
Trilha Cultura
- Resistência ativa ou passiva à adoção de IA
- Medo de julgamento ao experimentar e errar com IA
- Ausência de reconhecimento para iniciativas de adoção
- Falta de capacidade técnica para avaliar output de IA
- Comunicação deficiente sobre valor e objetivos da adoção
- Ausência de campeões de IA nos squads
Estrutura de milestones
| Marco | Foco | Critério de conclusão |
|---|---|---|
| +30 dias | Itens críticos de maior impacto e menor esforço — as "vitórias rápidas" | Bloqueadores imediatos removidos; time consegue experimentar com IA sem impedimentos do dia a dia |
| +90 dias | Itens de médio esforço que criam infraestrutura para adoção sustentável | Base técnica e organizacional suficiente para expandir adoção além do time piloto |
| +180 dias | Itens estruturais de alto esforço que garantem escala e sustentabilidade de longo prazo | Organização operando com IA de forma sistemática, com governança e métricas estabelecidas |
Gargalos típicos por dimensão (contexto para o diagnóstico)
| Dimensão | Gargalo típico (baixo) | Gargalo típico (médio) |
|---|---|---|
| Autonomia | Baixa autonomia do time limita a capacidade de experimentação com IA sem aprovação constante, reduzindo o ritmo de adoção. | Autonomia parcial pode gerar inconsistência na adoção: algumas iniciativas avançam enquanto outras aguardam validação. |
| Cont. Delivery | Pipeline de entrega contínua não consolidado aumenta o lead time de mudanças e reduz a frequência de ciclos de feedback. | CD parcialmente implementado: pipelines existem mas sem automação completa de qualidade ou deploy zero-downtime. |
| Qualidade | Ausência de práticas sistemáticas de qualidade (testes automatizados, análise estática) amplia o risco de regressões durante a adoção de IA. | Cobertura de testes parcial: módulos críticos cobertos, mas gaps na automação reduzem a confiança nas mudanças geradas com assistência de IA. |
| Vel. Feedback | Ciclo de feedback lento (revisões de PR prolongadas, deploys manuais) compromete a velocidade de aprendizado com ferramentas de IA. | Feedback moderado: revisões realizadas, mas sem SLAs definidos, causando variabilidade no ritmo de entrega. |
| Ownership | Baixo senso de propriedade sobre componentes reduz a motivação para adotar IA de forma autônoma e responsável. | Ownership concentrado em alguns membros sênior; riscos de gargalo em revisões e decisões de arquitetura. |
| DX & Código | Experiência de desenvolvimento degradada (setup complexo, ambientes instáveis) reduz o ganho percebido das ferramentas de IA. | DX razoável, mas ainda com fricção em setup e onboarding que pode desacelerar a adoção por novos membros do time. |
| Senioridade | Time predominantemente júnior exige maior investimento em contexto e revisão para validar sugestões de IA de forma segura. | Seniority mista: membros experientes podem acelerar, mas a capacidade de revisão crítica das saídas de IA é limitada pela concentração sênior. |
| Flex. Org. | Rigidez organizacional (aprovações lentas, processos formais obrigatórios) limita a capacidade de experimentação e iteração rápida. | Flexibilidade parcial: processos ajustáveis em nível de time, mas dependências externas adicionam latência nas decisões. |
| Uso de IA | Uso atual de IA é inexistente ou individual, sem padronização. A adoção do time piloto parte do zero em termos de cultura e tooling. | IA já utilizada individualmente por alguns membros, mas sem padronização de ferramentas, prompts ou critérios de qualidade. |
Objetivo da fase
Gera um playbook de adoção progressiva para os 6 estágios do SDLC. Para cada estágio, define o nível de adoção recomendado (none → experimental → team → org), o workflow com responsabilidades (ia/human/shared), anti-padrões e critérios de avanço.
Templates de adoção (seleção determinística)
| Template | Quando é selecionado | Característica |
|---|---|---|
| Conservador | currentAiUsage == "none" OU overallLevel == "low" | Começa pelos estágios de menor risco (testes e observabilidade). Prioriza qualidade sobre velocidade de adoção. |
| Balanceado | Caso padrão (não se encaixa em conservador nem agressivo) | Começa pela codificação. Avança em paralelo nos estágios de menor risco enquanto consolida os de maior impacto. |
| Agressivo | currentAiUsage == "organization" OU overallLevel == "high" | Adoção simultânea em múltiplos estágios (código, review e deploy primeiro). Para times com alta maturidade. |
Os 4 níveis de adoção por estágio
| Nível | Definição | Característica |
|---|---|---|
| none | IA não é usada neste estágio | Ponto de partida. Não significa que nunca será — apenas que ainda não é o momento para este estágio específico. |
| experimental | IA em uso por 1–2 pessoas, sem padrão definido | Fase exploratória. O objetivo é aprender, não escalar. Sem gate de qualidade obrigatório ainda. |
| team | IA adotada por todo o time com padrão mínimo definido | Adoção padronizada dentro do squad. Gates de qualidade ativos. Aprendizados documentados. |
| org | IA padronizada em toda a organização para este estágio | Replicação do padrão do time para todos os squads. Métricas de impacto medidas centralmente. |
Os 6 estágios do SDLC
1
Planejamento
O que IA faz neste estágio
- Síntese de requisitos a partir de discussões e documentos
- Geração de critérios de aceite e casos de borda
- Estimativas de complexidade baseadas em histórico do repositório
- Sugestões de decomposição de tarefas
Anti-padrões
- Usar IA para substituir conversas de alinhamento com produto
- Aceitar estimativas de IA sem validação com o time técnico
- Delegar decisões de priorização para a IA
Critérios de avanço
- Pelo menos 80% das tasks têm critérios de aceite gerados com IA revisados
- Time reporta redução subjetiva de esforço no planejamento
- Qualidade dos critérios de aceite melhorou (menos retrabalho por ambiguidade)
2
Codificação
O que IA faz neste estágio
- Autocompletar e geração de código inline (copilot mode)
- Geração de boilerplate, tipos e interfaces
- Refatoração de código com contexto completo do arquivo
- Explicação de código legado e sugestões de documentação
Calibrações automáticas
- Se dx_code == "low": limitar nível a experimental (código gerado requer revisão obrigatória)
Anti-padrões
- Aceitar código gerado sem revisão crítica do contexto de negócio
- Usar IA para escrever código em áreas sem cobertura de testes
- Ignorar sugestões de segurança em favor de velocidade
Critérios de avanço
- Aumento mensurável de velocity (≥ 10%) sem degradação de qualidade
- Time tem convenções documentadas para uso de IA no stack específico
- Taxa de bugs em código com IA igual ou inferior ao código manual
3
Code Review
O que IA faz neste estágio
- Revisão automática de PRs com comentários contextualizados
- Identificação de bugs, vulnerabilidades e code smells
- Sugestões de melhoria alinhadas às convenções do repositório
- Geração de changelog e resumo do PR
Calibrações automáticas
- Se seniority == "low": limitar nível a experimental (revisão humana sênior obrigatória como gate)
Anti-padrões
- Substituir a revisão humana por revisão exclusiva de IA
- Ignorar comentários de IA sem lê-los por considerar "ruído"
- Usar IA para aprovar PRs sem entender o contexto de negócio
Critérios de avanço
- Redução de ≥ 20% no tempo médio de revisão de PRs
- Comentários de IA identificando pelo menos 1 bug por semana que seria perdido
- Revisores humanos relatam que IA melhora a qualidade da revisão
4
Testes & Shift Left
O que IA faz neste estágio
- Geração automática de testes unitários para código existente
- Identificação de casos de borda não cobertos
- Geração de testes E2E a partir de critérios de aceite
- Análise de cobertura e priorização de quais testes criar
Como IA habilita Shift Left
Shift Left = detectar problemas o mais cedo possível — antes do commit, não depois do deploy. IA torna Shift Left economicamente viável ao reduzir o custo de escrever testes e de fazer review:
- No editor (pre-commit): Copilot/Cursor sugerem testes junto com o código que está sendo escrito — o teste existe antes do PR existir
- No PR (pre-merge): CodeRabbit e similares fazem code review automático e identificam ausência de testes antes do merge — nenhum PR sem cobertura adequada passa
- Casos de borda em tempo real: IA identifica edge cases que o dev não considerou enquanto escreve — não depois que o bug chegou em produção
- Análise estática acelerada: IA prioriza o que reforçar no CI — não é mais viável ignorar coverage por falta de tempo
Calibrações automáticas
- Se quality == "low": limitar nível a experimental — testes gerados por IA passam por revisão obrigatória antes de entrar no CI. Shift Left não se implementa sem base de testes prévia.
Anti-padrões
- Aceitar testes gerados por IA sem revisar se testam o comportamento correto
- Usar testes de IA para inflar cobertura sem valor real
- Ignorar casos de borda identificados pela IA por serem "edge cases raros"
- Continuar com o modelo de QA ao final do sprint enquanto IA gera testes — IA não substitui o processo Shift Left, ela o acelera
- Tratar Shift Left como iniciativa de ferramental, não de cultura — se o dev não se sente dono da qualidade, nenhuma ferramenta resolve
Critérios de avanço
- Cobertura de testes aumentou ≥ 15% nos módulos onde IA foi usada
- ≥ 50% dos PRs chegam ao review já com testes gerados por IA (Shift Left ativo)
- Quality gate no pre-commit ou CI bloqueando merge com cobertura abaixo do mínimo definido no DoD
- Testes gerados por IA têm taxa de falso-positivo inferior a 10%
5
Deploy
O que IA faz neste estágio
- Análise de risco de deploy baseada no diff e histórico de incidentes
- Sugestão de estratégia de deploy (canary, blue-green, feature flags)
- Geração automática de runbook de rollback
- Validação de configurações de infraestrutura antes do deploy
Calibrações automáticas
- Se continuous_delivery == "low": manter nível em none (pré-condição: CD automatizado primeiro)
Anti-padrões
- Usar IA para automatizar deploy sem revisão humana em deploys de alto risco
- Ignorar avisos de risco de IA por pressão de prazo
- Confiar em runbooks gerados por IA sem testar o rollback
Critérios de avanço
- Redução de ≥ 30% nos deploys que requerem rollback
- Análise de risco de IA usada em 100% dos deploys para produção
- Runbooks de rollback gerados e testados para os 5 principais serviços
6
Observabilidade
O que IA faz neste estágio
- Detecção automática de anomalias em métricas e logs
- Análise de causa raiz assistida em incidentes
- Geração de dashboards e alertas baseados em padrões históricos
- Correlação automática de eventos entre serviços
Anti-padrões
- Usar IA para reduzir o número de alertas sem entender o porquê
- Confiar em causa raiz sugerida por IA sem validação humana
- Ignorar anomalias detectadas por IA por considerar "falso positivo" sem investigar
Critérios de avanço
- MTTR (mean time to recover) reduzido em ≥ 25% com IA
- Pelo menos 3 incidentes detectados por IA antes de impacto ao usuário
- Time usa análise de causa raiz de IA como ponto de partida em 100% dos incidentes P1/P2
Objetivo da fase
Estabelece políticas, padrões e mecanismos de controle que asseguram uso responsável, rastreável e consistente de IA em toda a engenharia, reduzindo risco e variabilidade. O pacote gerado é calibrado pelo tamanho da organização, exposição regulatória e tolerância ao risco.
8 Políticas de uso de IA
1. Uso de Dados em Prompts
Nenhum dado sensível, PII, credencial ou propriedade intelectual confidencial pode ser incluído em prompts enviados a modelos de IA externos. Dados de teste devem ser sintéticos ou anonimizados.
2. Escolha e Aprovação de Ferramentas
Toda ferramenta de IA que acesse código, dados ou infraestrutura da empresa requer avaliação de segurança e aprovação formal antes do uso em produção ou em repositórios que contêm código proprietário.
3. Revisão Humana Obrigatória
Todo código gerado com assistência de IA que for para produção requer revisão humana por um engenheiro com senioridade adequada ao contexto. IA não aprova PRs de forma autônoma.
4. Propriedade Intelectual
Código gerado com assistência de IA é propriedade da empresa. Engenheiros não devem usar ferramentas de IA que reivindiquem propriedade sobre outputs. Licenças de ferramentas devem incluir cláusula de IP explícita.
5. Segurança e Vulnerabilidades
Código gerado por IA para funções de segurança (autenticação, autorização, criptografia) requer revisão especializada adicional. Não usar IA para gerar ou modificar lógica de segurança sem supervisão de security engineer.
6. Controle de Custos
Todas as contas de ferramentas de IA devem ter limites de gasto configurados. Uso individual acima do threshold mensal definido requer aprovação prévia. Relatório de custos consolidado mensal para liderança técnica.
7. Exceções e Desvios
Qualquer desvio de política deve ser documentado, justificado e aprovado pelo responsável da política com prazo de validade definido. Exceções são revisadas no ciclo semestral de governança.
8. Revisão Periódica das Políticas
Todas as políticas são revisadas semestralmente ou quando ocorre mudança significativa nas ferramentas, no contexto regulatório ou nos incidentes relacionados a IA. A revisão inclui todos os responsáveis de política.
9. AI Literacy Requirement
Nenhum engenheiro pode usar ferramentas de IA em contexto produtivo sem ter atingido o nível L1 · Aplicador da matriz de proficiência. Revisão de código gerado com IA exige revisor em L2 · Crítico ou acima. O Time AI Enablers mantém o registro de níveis atualizado.
7 Padrões Técnicos
Commits com Assistência de IA
Mensagens de commit devem indicar quando código relevante foi gerado com assistência de IA. Formato sugerido: prefixo
[ai-assisted] ou convenção definida pelo time. Facilita auditoria e rastreabilidade.Prompts Versionados
Prompts utilizados em contextos críticos (geração de código de produção, análise de segurança, geração de testes) devem ser versionados no repositório junto ao código que os utiliza.
Observabilidade do Uso de IA
Sistemas que expõem funcionalidades baseadas em IA para usuários finais devem ter métricas de uso, latência, taxa de erro e feedback do usuário instrumentadas no dashboard de observabilidade padrão.
Rastreamento de Custos por Serviço
Chamadas a APIs de IA externas devem ter tags de custo por serviço/squad para permitir atribuição de custos. Budget alerts configurados por squad e por ambiente (dev/staging/prod separados).
Revisão de Código Gerado por IA
PRs com mais de 30% do código gerado com IA devem ter checklist explícito de revisão incluindo: lógica de negócio correta, ausência de PII hard-coded, tratamento de erros adequado e cobertura de testes.
Dados Sintéticos para Desenvolvimento
Ambientes de desenvolvimento e staging devem usar dados sintéticos gerados por IA em vez de cópias de dados de produção. Processo documentado e automatizado para geração e refresh de dados sintéticos.
Shift Left Quality Gates
A sequência de gates de qualidade é obrigatória e progressiva — nenhuma etapa pode ser pulada:
- Pre-commit — lint, formatação e testes unitários locais rodam antes do commit. Falha bloqueia localmente.
- CI gate — suite completa de testes + análise estática + cobertura mínima (definida no DoD do squad). Falha bloqueia merge.
- PR quality check — code review assistido por IA (CodeRabbit ou similar) + checklist de qualidade preenchido pelo autor. Nenhum PR é aprovado sem cobertura adequada do código novo.
- Staging — somente código que passou nas 3 etapas anteriores chega aqui. Staging não é onde qualidade é verificada pela primeira vez.
6 Guardrails (por criticidade)
Nenhum PII em Prompts Crítica
Bloqueio técnico + alerta automático quando padrões de PII (CPF, e-mail, telefone, nome completo) são detectados em prompts enviados a APIs externas. Auditoria mensal de logs de prompts para verificar conformidade.
Nenhum Output de IA Raw em Produção Crítica
Outputs de modelos de IA que chegam a usuários finais ou sistemas de produção devem passar por validação e revisão humana ou automatizada antes. Nenhum pipeline de produção aceita output de IA sem gate de qualidade.
Privacy Mode Ativado em Ferramentas Alta
Todas as ferramentas de IA aprovadas devem ter modo de privacidade ativado (que impede o uso do código como dados de treinamento). Verificação incluída no processo de aprovação de novas ferramentas.
Revisão de Licença de Dependências Alta
Dependências sugeridas por IA devem ter licença verificada antes da adoção. Checklist de licença incluído no processo de revisão de PRs que adicionam novas dependências geradas com assistência de IA.
Isolamento de Ambiente para IA Média
Experimentações com modelos de IA em ambiente de desenvolvimento devem ser isoladas do ambiente de produção. Credenciais de produção nunca acessíveis em ambientes de dev/staging onde IA é usada.
Alertas de Anomalia de Uso Média
Alertas automáticos quando o uso de APIs de IA exceder 2× o baseline semanal por squad. Objetivo: detectar loops de automação incorretos ou vazamento de credenciais antes de impacto financeiro ou de segurança.
Processo de revisão em 5 etapas
| # | Etapa | Responsável | SLA |
|---|---|---|---|
| 1 | Proposta inicial: Engenheiro documenta ferramenta/prática com casos de uso e riscos identificados | Engenheiro proponente | – |
| 2 | Revisão de segurança: Security Engineering avalia riscos de dados, acesso e licença | Security Engineering | 3 dias úteis |
| 3 | Piloto controlado: Time AI Enablers coordena uso restrito em ambiente isolado por 2 semanas | Time AI Enablers | 2 semanas |
| 4 | Avaliação de impacto: Resultados do piloto documentados com métricas de ganho e riscos observados | Time AI Enablers | 5 dias úteis |
| 5 | Decisão e comunicação: Aprovação, rejeição ou aprovação condicional com comunicação para toda a engenharia | CTO / VP Engineering | 2 dias úteis |
AI Security Posture Sugerido
Segurança de IA não é só "não vaze PII". É uma disciplina própria que cobre como modelos são manipulados, como agentes agem além do autorizado, como infraestrutura de IA é comprometida e como a organização detecta e responde a esses riscos. Os blocos abaixo refletem o que equipes de engenharia líderes estão implementando em 2025–2026.
Framework de defesa em 3 camadas (Input · Output · Runtime)
Camada 1 — Input Guardrails
Antes de o prompt chegar ao modelo
Prompt injection detection
Identificar padrões de instrução disfarçados de dados no input do usuário. Separar conteúdo de dados de conteúdo de instrução (spotlighting/metaprompting).
PII sanitization automática
Detectar e mascarar CPF, e-mail, telefone, nome completo e credenciais antes de enviar ao modelo. Ferramenta: presidio (Microsoft), Google DLP, AWS Comprehend.
Policy classification
Classificar intenção do prompt antes de processar: detectar data exfiltration, jailbreak attempt, ou uso fora do escopo aprovado.
Context shaping
System prompts estruturados que tratam conteúdo externo (docs, e-mails, web) como dados, nunca como instrução — reduz superfície de indirect injection.
Pequenas: implementar ao menos PII sanitization + prompt injection detection. Médias+: policy classification automatizada no pipeline.
Camada 2 — Output Guardrails
Antes de o output chegar ao usuário ou sistema downstream
Nenhum output raw em produção
Output de modelos que chega a usuários finais ou sistemas críticos deve passar por validação antes. Gate obrigatório — previne LLM05 (improper output handling).
Schema validation
Para outputs estruturados (JSON, código, SQL), validar schema antes de usar. Rejeitar e retentar se fora do schema esperado.
Sensitive data scan no output
Detectar e bloquear outputs que contenham credenciais, tokens, dados de outros usuários ou informação não pública antes de exibir — previne LLM02.
System prompt leakage detection
Detectar quando o modelo está reproduzindo seu próprio system prompt no output (previne LLM07). Regra simples de overlap de string ou classifier dedicado.
Pequenas: ao menos nenhum output raw + schema validation para outputs estruturados. Grandes: sensitive data scan automático em 100% dos outputs de produção.
Camada 3 — Runtime Guardrails Sugerido
Quando agentes acessam ferramentas, APIs e sistemas externos — relevante assim que houver uso agentic
Least privilege por tool call
Cada chamada de agente a uma ferramenta usa credenciais com escopo mínimo necessário. Short-lived tokens por sessão, não credenciais globais — previne LLM06 (excessive agency).
Audit log por ação do agente
Toda tool call de agente em produção deve gerar log com: quem pediu, qual ferramenta, com quais parâmetros, qual foi o resultado. Rastreabilidade completa de ações autônomas.
Plan drift detection
Monitorar se o agente está executando uma sequência de ações compatível com a task original. Desvios de plano disparam alerta ou interrompem execução.
Human-in-the-loop para ações irreversíveis
Ações destrutivas (delete, deploy em produção, envio de comunicações externas) devem ter aprovação humana explícita antes de execução, independente de quem iniciou.
Pequenas: human-in-the-loop para qualquer ação agentic em produção. Médias+: audit log automatizado + plan drift detection. Grandes: runtime guardrails via AI Gateway centralizado.
OWASP LLM Top 10 · 2025 — riscos e controles práticos
| ID | Risco | Controle prático | Tamanho |
|---|---|---|---|
| LLM01 | Prompt Injection — input manipula o modelo a agir fora do escopo | Spotlighting, policy classification, separação instrução/dados no system prompt | Todos |
| LLM02 | Sensitive Information Disclosure — modelo expõe IP, dados de outros usuários, credenciais | PII sanitization no input + output, sensitive data scan no output, privacy mode obrigatório | Todos |
| LLM03 | Supply Chain Vulnerabilities — modelos, MCPs e dependências comprometidos | Registry verificado para MCPs (GitHub MCP Registry), scan de provenance, allowlist de modelos aprovados | Médias+ |
| LLM05 | Improper Output Handling — output não validado vai direto para produção ou sistemas críticos | Schema validation, nunca output raw em produção, output scan antes de injetar em pipelines | Todos |
| LLM06 | Excessive Agency — agente executa ações além do autorizado ou do necessário | Least privilege por tool call, human-in-the-loop em ações irreversíveis, plan drift detection | Quando houver uso agentic |
| LLM07 | System Prompt Leakage — modelo reproduz instruções internas no output | Leak detection no output, não incluir dados sensíveis em system prompts, teste regular de extração | Médias+ |
| LLM08 | Vector & Embedding Weaknesses — vazamento cross-context em RAG, dados sensíveis em vector DBs | RBAC no vector store por tenant/usuário, isolamento de namespaces, auditoria de query de embedding | Grandes Sugerido |
| LLM10 | Unbounded Consumption — agente ou usuário consome tokens/compute sem limite, gerando custo ou DoS | Budget alerts por squad, rate limiting por usuário/agente, max_tokens hardcoded, anomaly detection de uso | Todos |
MCP Security — 6 controles mínimos obrigatórios Sugerido
92% dos MCP servers em uso empresarial têm alto risco de segurança — 24% sem nenhuma autenticação. O EU AI Act (em vigor ago/2026) pode responsabilizar organizações por integrações MCP não governadas. Antes de qualquer MCP server ir para produção, os 6 controles abaixo são pré-requisito:
OAuth 2.0
Autenticação obrigatória. Nenhum agente conecta a MCP server sem identity verificada.
RBAC por operação
Autorização por tool call individual, não só por servidor. Escopo mínimo por papel.
Audit log com atribuição
Quem pediu, qual tool, quais parâmetros, qual resultado — log imutável por operação.
Path & scope controls
Limitar quais recursos e operações cada MCP server pode expor. Allowlist explícita de paths.
Rate limiting
Por agente, por usuário e por servidor. Previne consumo descontrolado e ataques de amplificação.
Sensitivity label evaluation
Classificar dados expostos por cada MCP tool. Bloquear acesso a dados de sensibilidade acima do autorizado.
Gateway centralizado de MCP/LLM/A2A Sugerido · Médias e Grandes
Um único plano de controle para tráfego LLM + MCP + A2A (agent-to-agent) em vez de cada servidor implementar seus próprios controles. Referências de mercado: Kong AI Gateway, MuleSoft AI Gateway, Solo.io Agentgateway.
Oferece: PII sanitization automática, semantic caching, fallback entre modelos, OpenTelemetry nativo, RBAC unificado e audit trail consolidado.
Marketplace de Skills — critérios de publicação e governança Sugerido · Médias e Grandes
Catálogo centralizado de prompts, agentes, templates e skills de IA validados e reutilizáveis pelos squads. Sem um marketplace governado, a organização acaba com dezenas de versões paralelas do mesmo prompt — inconsistentes, sem revisão e sem rastreabilidade. Plataformas de referência: SkillReg, Agent Skills Catalog (SOC 2), PromptFluent Enterprise.
| Critério de publicação | O que implica | Responsável |
|---|---|---|
| Versionamento semântico | Cada skill/prompt tem versão (major.minor.patch). Breaking changes exigem major bump. Squads fixam versão em uso. | Autor + Time AI Enablers |
| RBAC por catálogo | Skills sensíveis (acesso a dados de produção, ações destrutivas) visíveis apenas para roles autorizados. Catálogos por domínio ou squad. | Time AI Enablers |
| Security scan automático | Antes de publicar, scan automatizado para: prompt injection patterns, data leakage, referência a credenciais hardcoded, PII em exemplos. | Security Engineering |
| Aprovação do Time AI Enablers | Nenhum skill vai para o catálogo público sem revisão e aprovação. Skills experimentais vão para namespace de rascunho primeiro. | Time AI Enablers |
| Métricas de uso e deprecação | Skills sem uso por 90 dias são marcados como deprecated. Skills com feedback negativo recorrente são removidos ou revisados. | Time AI Enablers |
Objetivo da fase
Expande a adoção de IA para todas as equipes de engenharia, operacionalizando a estrutura de governança e os aprendizados das fases anteriores para gerar impacto organizacional amplo e sustentável. A conclusão desta fase marca o ciclo completo do framework.
Plano de rollout em ondas (determinístico por tamanho)
| Tamanho da engenharia | Nº de ondas | Duração sugerida por onda | Estratégia |
|---|---|---|---|
| 1–9 engenheiros | 1 onda | 4–6 semanas | Adoção simultânea de todo o time. Piloto e escala são a mesma fase. |
| 10–29 engenheiros | 2 ondas | 6–8 semanas cada | Onda 1: 50% do time (squads mais maduros). Onda 2: restante com playbook documentado da onda 1. |
| 30–99 engenheiros | 3 ondas | 8 semanas cada | Onda 1: time piloto + 1 squad adjacente. Ondas 2–3: rollout por afinidade técnica e disponibilidade de campeões. |
| 100–299 engenheiros | 4 ondas | 6–10 semanas cada | Onda 1: squads com campeões de IA formados. Ondas subsequentes: rollout por vertical de produto. |
| 300+ engenheiros | 5 ondas | 8–12 semanas cada | Ondas por business unit ou domínio. Requer estrutura de campeões por squad e plataforma interna de IA. |
9 métricas em 3 camadas
Camada 1 — Adoção
MET-A01
% de engenheiros usando IA semanalmente
Proporção de engenheiros que usaram pelo menos uma ferramenta de IA em tarefas de desenvolvimento na semana. Meta progressiva: 25% → 50% → 80%.
MET-A02
Número de ferramentas de IA ativas
Quantidade de ferramentas de IA aprovadas e em uso ativo na organização. Indica profundidade da adoção além de um único ponto de entrada.
MET-A03
Taxa de adoção por squad
Proporção de squads com pelo menos 1 ferramenta de IA padronizada e em uso por toda a equipe. Meta: 100% dos squads ao final da última onda.
MET-A04
Distribuição de proficiência (Capability Heatmap)
Proporção da engenharia em cada nível da matriz: L0 / L1 / L2 / L3. Meta ao completar escala: <10% em L0 · ≥60% em L1+ · ≥20% em L2+ · ≥5% em L3 (1 multiplicador por squad). Publicado por squad trimestralmente.
MET-A05
Tempo para atingir L1 em novos engenheiros
Tempo médio para um engenheiro novo na organização atingir o nível L1 · Aplicador a partir do onboarding. Meta: <4 semanas. Indica eficácia do programa de capacitação e velocidade de integração de novos membros.
Camada 2 — Engajamento
MET-E01
% do SDLC coberto por IA
Proporção dos 6 estágios do SDLC com nível de adoção ≥ "team" na organização. Indica profundidade de integração no fluxo de desenvolvimento.
MET-E02
Sessões de IA por engenheiro por semana
Número médio de sessões de interação com ferramentas de IA por engenheiro por semana. Indica qualidade e profundidade do uso, não apenas adoção superficial.
MET-E03
% de PRs com revisão assistida por IA
Proporção de pull requests que passam por revisão automática de IA antes de revisão humana. Indicador de integração no fluxo de qualidade.
Camada 3 — Impacto (DORA + negócio)
MET-I01
Variação no cycle time
Delta percentual no tempo médio de commit a deploy após adoção de IA em relação ao baseline. Métrica DORA de deployment frequency indireta.
MET-I02
Variação na taxa de bugs
Delta percentual na taxa de bugs reportados em produção após adoção de IA. Métrica DORA de change failure rate indireta.
MET-I03
Variação nas métricas DORA
Variação consolidada nas 4 métricas DORA (deployment frequency, lead time, change failure rate, MTTR) antes e depois da adoção completa de IA.
3 Cerimônias recorrentes
| Cerimônia | Frequência | Participantes | Objetivo |
|---|---|---|---|
| Weekly Sync | Semanal · 30 min | Time central de adoção de IA | Revisar métricas da semana, desbloquear impedimentos, alinhar prioridades da próxima onda |
| Campeões Champions | Quinzenal · 45 min | Time central + campeões de IA por squad | Compartilhar aprendizados entre squads, alinhar boas práticas, identificar casos de uso replicáveis |
| Retro de Adoção | Mensal · 60 min | Time central + liderança técnica | Avaliar progresso das métricas, ajustar estratégia de rollout, comunicar resultados para a organização |
8 Riscos de escala e mitigações
RISK-S01
Big-bang rollout
Mitigação: Implementar rollout em ondas com critérios de entrada explícitos para cada onda. Nunca avançar para a próxima onda sem métricas de sucesso da onda anterior.
RISK-S02
Potemkin AI (adoção superficial)
Mitigação: Medir engajamento qualitativo (sessões/semana, profundidade de uso) além de adoção binária. Revisitar squads com métricas de adoção altas mas impacto baixo.
RISK-S03
Sobrecarga do Time AI Enablers
Mitigação: Limitar o número de squads em onboarding simultâneo ao capacity do Time AI Enablers. Usar modelo de campeões para distribuir carga de suporte.
RISK-S04
Perda de conhecimento entre ondas
Mitigação: Documentar playbook de cada onda antes de iniciar a próxima. Campeões da onda anterior tornam-se mentores da próxima onda.
RISK-S05
Resistência sênior
Mitigação: Envolver engenheiros sêniores no design do processo desde o início. Demonstrar como IA amplifica (não substitui) capacidade técnica avançada.
RISK-S06
Proliferação de ferramentas (tool sprawl)
Mitigação: Processo de aprovação centralizado para novas ferramentas. Revisão trimestral do portfólio de ferramentas aprovadas com descontinuação de ferramentas de baixo uso.
RISK-S07
Governança insuficiente para escala
Mitigação: Verificar que a Fase 6 está completa antes de iniciar a Fase 7. Escalar o processo de revisão de segurança e compliance antes de aumentar o número de ferramentas aprovadas.
RISK-S08
Regressão pós-conclusão
Mitigação: Manter as cerimônias recorrentes mesmo após o framework "concluído". Tratar adoção de IA como prática contínua, não projeto com fim definido.
5 Critérios de conclusão do framework
- ≥ 80% dos engenheiros da organização usando pelo menos uma ferramenta de IA semanalmente
- Todos os squads com pelo menos 2 estágios do SDLC com IA no nível "team" ou superior
- Framework de governança v1 publicado, comunicado e com processo de revisão ativo
- Métricas DORA com melhora mensurável em relação ao baseline pré-framework
- Pelo menos 1 ciclo completo de retro de adoção realizado com liderança técnica e resultados documentados