- Início
- The Thinking Wire
- O Que 220 Controles Ensinam Sobre Construir Frameworks de Governança de IA
O Que 220 Controles Ensinam Sobre Construir Frameworks de Governança de IA
Em novembro de 2022, Davoud Tu entrou no time de Security Compliance do GitLab e encontrou um problema familiar: o NIST SP 800-53, com seus mais de 1.000 controles, não servia. Não por ser errado, mas por ser genérico demais para a realidade da empresa.
O controle AC-2, “Account Management”, ilustra bem. No NIST, é um item único. Na prática, abrange seis atividades operacionais distintas: criação, modificação, desativação, remoção, contas compartilhadas e monitoramento. Cada uma exige processos diferentes, evidências diferentes, responsáveis diferentes. Tratar tudo como um único controle é fingir que a complexidade não existe.
A decisão do GitLab foi construir do zero.
O Framework Que Surgiu
O resultado: 220 controles ativos distribuídos em 18 domínios customizados. Cada domínio organizado por função (gestão de identidade, proteção de dados, resposta a incidentes). Cada controle com metadados específicos: responsável, ambiente, ativos afetados, frequência de testes, natureza da automação, classificação e requisitos de evidência.
Não é um documento de política. É infraestrutura operacional.
Esses 220 controles mapeiam 1.300 requisitos de certificação. SOC 2 Type II, ISO 27001, ISO 27017, ISO 27018, ISO 42001, PCI DSS, TISAX, Cyber Essentials, FedRAMP. Oito certificações cobertas por um único framework. Quatro listas separadas de solicitações de auditoria consolidadas em uma.
Os números contam a história: controles SOC para o GitLab.com caíram de 200 para 84. Redução de 58%. Para o GitLab Dedicated, de 181 para 82. Redução de 55%. Solicitações totais de auditoria caíram 44%, de 415 para 231. Na última auditoria PCI, 95% das evidências foram aceitas antes do trabalho de campo começar.
A Lição que Importa
O instinto de quem implementa governança é adicionar controles. Mais requisitos, mais checklists, mais documentação. O GitLab demonstrou o oposto: governança melhor frequentemente significa menos controles, não mais.
Implementar controles desnecessários não melhora a segurança. Consome tempo de engenharia, gera fadiga de compliance e, paradoxalmente, enfraquece a postura de segurança. Quando tudo é prioritário, nada é.
A hierarquia do framework em dois níveis reforça isso. O Nível 1 define requisitos organizacionais. O Nível 2 captura implementações específicas por produto: GitLab.com (multi-tenant SaaS), GitLab Dedicated (single-tenant), GitLab Dedicated for Government. Cada produto tem escopo de compliance diferente. Tentar aplicar os mesmos controles a todos é o mesmo erro do NIST SP 800-53 em escala menor.
Essa é a conexão com o que exploramos em Especificações de Agentes São Artefatos de Governança: controles de governança funcionam quando são específicos o suficiente para serem testáveis e auditáveis. Controles genéricos são teatro.
O Outro Lado: Quando Governança Simplesmente Não Existe
Enquanto o GitLab refinava seus controles, algo interessante acontecia no ecossistema open source. Um desenvolvedor reimplementou a biblioteca chardet, que tem 170 milhões de downloads e licença GPL, em cinco dias usando Claude. A verificação automatizada de plágio encontrou 1,3% de similaridade de código. O resultado: algoritmos diferentes, código diferente, performance melhor.
Tecnicamente, é uma implementação clean room. Legalmente, é um território que ninguém testou de verdade.
A GPL existe há décadas como mecanismo de governança do software livre. Seu princípio central é simples: se você usa código GPL, seu código derivado herda a mesma licença. Richard Stallman construiu um ecossistema inteiro sobre essa premissa. GCC, GNU utilities, o kernel Linux.
Só que a IA inverteu a economia da reimplementação. Antes, reescrever uma biblioteca madura exigia meses ou anos de trabalho. O custo tornava a conformidade com a GPL mais barata que a alternativa. Cinco dias mudam essa equação.
O GCC já perdeu relevância para o LLVM/Clang. Utilitários GNU estão sendo reescritos em Rust com licenças MIT. A pergunta que o artigo do LowEndBox levanta (quanto tempo até o kernel Linux ser reescrito?) pode parecer provocativa, mas reflete uma tendência concreta: a barreira econômica que sustentava a GPL como mecanismo de governança está sendo corroída.
Dois Modelos de Governança, Uma Conclusão
O caso do GitLab e o caso do copyleft parecem não ter relação. Um é sobre compliance corporativo, o outro sobre licenças de software. Mas ambos revelam o mesmo princípio.
Governança funciona quando o custo de não cumprir é maior que o custo de cumprir.
O GitLab construiu um framework onde cumprir é barato. Controles específicos, evidências claras, automação onde possível. Reduziu o atrito. A consequência foi compliance mais forte com menos esforço.
A GPL dependia de um mundo onde reimplementar era caro. O custo de compliance (abrir seu código) era menor que o custo de reescrever do zero. Com IA, essa relação se inverteu. O mecanismo de governança não mudou, mas o contexto econômico ao redor dele sim.
Para quem está construindo frameworks de governança de IA, a implicação é direta. Não basta ter controles corretos. Os controles precisam ser econômicos de implementar. Se o custo de compliance excede o custo de contornar, as pessoas vão contornar.
O GitLab reduziu 58% dos controles SOC e obteve resultados melhores. Não apesar da redução. Por causa dela.
Como discutimos em A Constituição do Claude, frameworks eficazes explicam o raciocínio por trás das regras, não apenas listam proibições. A mesma lógica se aplica aqui: controles que fazem sentido operacional geram adesão. Controles que existem para satisfazer um checklist geram workarounds.
O Que Fazer com Isso
Três princípios para quem está desenhando governança de IA:
Comece pelo contexto, não pelo framework. O NIST SP 800-53 tem mais de 1.000 controles. O GitLab usa 220. A diferença não é negligência. É precisão. Identifique quais controles se aplicam à sua realidade antes de adotar qualquer framework padrão.
Trate controles como código. Metadados por controle (responsável, frequência, automação, evidências) não são burocracia. São a diferença entre governança operacional e governança documental. A primeira protege. A segunda ocupa espaço.
Projete para economia, não para completude. Se seus controles custam mais para implementar do que o risco que mitigam, eles serão ignorados. A GPL está aprendendo essa lição em tempo real. Não repita o erro.
Fontes
- GitLab Security. “How GitLab Built a Security Control Framework from Scratch.” Março 2026.
- GitLab. “GitLab Achieves ISO/IEC 42001 Certification for AI Governance.” Setembro 2025.
- LowEndBox. “The Linux Kernel Will Soon Be MIT-Licensed and Copyleft Will Be Dead Within 5 Years.” Março 2026.
A Victorino Group ajuda empresas a construir frameworks de governança de IA que funcionam na prática, não apenas no papel: contato@victorino.com.br | www.victorino.com.br
Se isso faz sentido, vamos conversar
Ajudamos empresas a implementar IA sem perder o controle.
Agendar uma Conversa