Seu histórico do Git é prova: controle a atribuição de IA antes que ela controle você

Você provavelmente viu a polêmica: relatos de que o VS Code estava inserindo “Co‑Authored‑by: Copilot” em commits, mesmo quando desenvolvedores não haviam optado explicitamente por isso. Muitos times deram de ombros. Não faça isso. Seu histórico do Git não é só controle de versão; é prova. É o que seu potencial adquirente, seu auditor e mantenedores upstream leem quando perguntam: “Quem escreveu isso, sob quais termos, e você consegue provar?”

Isso não é um manifesto anti‑IA. É sobre controle. A atribuição de IA vazando para a metadata do commit sem intenção ou consistência pode quebrar checagens de DCO, confundir a titularidade de PI, acionar rejeições por políticas upstream e complicar trilhas de evidência de SOC 2/ISO 27001. Se você lidera engenharia em um startup ou scale‑up, precisa de uma postura de governança que mantenha a entrega rápida enquanto transforma seu histórico do Git em um ativo, não um passivo.

O que realmente está em jogo quando a IA aparece na metadata do commit

• Quebras de DCO e políticas de contribuição: Muitas organizações e projetos open source condicionam merges ao Developer Certificate of Origin (DCO). Trailers ambíguos como “Co‑Authored‑by” vindos de uma ferramenta de IA podem fazer checagens automáticas ou mantenedores travarem. Veja a linguagem do DCO em developercertificate.org.
• Ambiguidade de titularidade de PI e direitos autorais: Algumas jurisdições tratam material gerado por IA de forma diferente para fins de direitos autorais. Se sua metadata de commit sugere um coautor não humano, você está convidando perguntas indesejadas durante diligência.
• A proveniência da cadeia de suprimentos fica turva: Práticas de SLSA, Sigstore e SBOM assumem autoria e etapas de build rastreáveis. Trailers sem controle reduzem o sinal de que você precisa para proveniência e atestações. Veja slsa.dev e sigstore.dev.
• Deriva de políticas de upstream e clientes: Alguns repositórios upstream agora exigem divulgação explícita de assistência de IA; outros proíbem explicitamente patches gerados por IA. Sua metadata pode, sem querer, colocá‑lo do lado errado de ambos.

Tradução: uma única linha de trailer “útil” adicionada por uma ferramenta pode transformar um merge rotineiro em um incêndio de 1–2 dias entre jurídico, segurança e engenharia — multiplicado por times.

Onde esse risco se infiltra

• Padrões do IDE e extensões: IDEs, extensões e agentes às vezes adicionam trailers automaticamente. Desenvolvedores raramente percebem até que um branch protegido rejeite um push.
• Templates de commit compartilhados ad hoc: Um engenheiro bem‑intencionado define um template global de commit que inclui linhas “Co‑Authored‑by:” para pair programming, e isso vaza para todo repositório.
• Contas de bot e automação: Renovate, Dependabot, bots de release e scripts internos podem adicionar trailers extras que interagem mal com suas checagens.
• Máquinas de nearshore/contratados: Ambientes mistos amplificam a deriva: IDEs, templates e language servers diferentes entre macOS, Windows e Linux.

Framework de decisão para CTOs: quatro camadas de controle

Você não resolve isso com um único hook esperto. Resolve com camadas — disciplina local, aplicação no servidor, clareza de política e proveniência da cadeia de suprimentos. Eis o modelo que implementamos para clientes.

Camada 1: Controles no desenvolvimento local (faça do “jeito certo” o padrão)

• Padronize templates de commit por repositório: Forneça um template mínimo que inclua apenas o que você exige: uma linha de assunto, um corpo opcional e “Signed‑off‑by:” se você requer DCO. Sem trailers para IA, pares ou bots por padrão.
• Hooks prepare‑commit‑msg e commit‑msg: Distribua hooks com escopo de repositório que removem trailers não permitidos e falham commits que violem a política. Exemplos de padrões não permitidos: linhas Co‑Authored‑by referenciando ferramentas (por exemplo, “Copilot”), aliases ambíguos de bots ou commits não assinados em branches protegidos.
• Trave configurações do editor em devcontainers: Se você usa devcontainers ou devboxes gerenciados, desative a inserção automática de trailers por extensões. Fixe extensões e configurações aprovadas para que a deriva não recomece.
• Lista de permissão de humanos para coautores: Se você permitir coautoria explícita, mantenha uma lista de permissão (allowlist) de e‑mails humanos. Qualquer outra coisa é removida localmente com uma mensagem de erro acionável.

Controles locais previnem a maioria dos problemas antes de chegarem ao origin. Eles não são suficientes sozinhos, porque desenvolvedores podem contorná‑los ou trabalhar fora dos seus containers. É por isso que você precisa das próximas camadas.

Camada 2: Aplicação no servidor (os trilhos de segurança que sempre rodam)

• Proteção de branch com commits assinados: Exija assinatura com GPG ou Sigstore keyless em branches protegidos. É uma barra objetiva: se um commit não estiver assinado por uma identidade permitida, ele não entra. GitHub e GitLab suportam isso.
• Hooks no servidor ou checagens obrigatórias: Adicione uma verificação de status obrigatória que analise os trailers de commits em todo PR. Rejeite commits que contenham trailers não permitidos, faltem “Signed‑off‑by” do DCO ou que tenham mudanças feitas por bots em caminhos sensíveis.
• CODEOWNERS em todo lugar: Torne a posse explícita no nível de diretório para que revisões caiam em humanos responsáveis. Se um PR contiver trailers suspeitos, os owners decidem se aceitam com disclosure ou devolvem.
• Contas de serviço para bots com identidades verificadas: Quando você permitir bots (Renovate, automação de release), dê a eles identidades e escopos únicos e documente seus trailers. Ambiguidade é o que dispara atritos de compliance.

Camada 3: Política e treinamento (remova a ambiguidade)

• Publique uma política curta de IA no código: Duas páginas, no máximo. Defina ferramentas permitidas, requisitos de divulgação, o que “coautoria” significa na sua organização e quem aprova exceções. Incorpore as expectativas de DCO.
• Regra de divulgação no PR: Exija que desenvolvedores divulguem assistência substancial de IA na descrição do PR, e não em trailers do commit. Assim a proveniência fica acessível sem poluir a metadata do Git.
• Integração com Procurement/Compras: Vincule aquisição de IDEs/agentes ao cumprimento da política. Extensões que inserem trailers automaticamente são desabilitadas ou configuradas durante o rollout, não após o primeiro incidente.
• Estratégia para upstream: Acompanhe as políticas sobre IA de contribuição dos 20 principais repositórios que você mira. Se mantenedores banirem código de IA, você evita desperdício; se exigirem divulgação, direcione isso para o texto do PR, não para a metadata do commit.

Camada 4: Proveniência, SBOM e releases (prove o que você construiu)

• Builds alinhados ao SLSA: Gere proveniência de build usando assinaturas respaldadas por OIDC (por exemplo, Sigstore Fulcio) e anexe isso aos releases. Isso prova o quem/o que/quando do seu pipeline de build, independentemente dos trailers.
• SBOMs com atestação de revisão humana: Produza SBOMs no momento do build e adicione uma atestação assinada por um responsável humano pelo release. Você não está debatendo se uma ferramenta “coautorizou” código; você está declarando e assinando quem embarcou.
• Transparência de bots de release: Se um bot promove artefatos, inclua sua identidade nas notas de release e na proveniência. Demarcação clara reduz disputas futuras.

Guia de implementação: faça isso em semanas, não em trimestres

Semana 1: Pare o sangramento

• Escolha três repositórios críticos (core service, frontend, infra). Adicione um template mínimo de commit. Adicione hooks com escopo de repositório que removem quaisquer linhas “Co‑Authored‑by:” que não correspondam a uma lista de permissão de e‑mails humanos.
• Ative commits assinados para branches protegidos. Gire chaves ou adote keyless com Sigstore se puder. Torne isso uma checagem obrigatória.
• Fixe devcontainers ou imagens golden para seus engenheiros e parceiros nearshore. Desative qualquer configuração de extensão que insira trailers automaticamente. Documente a configuração e a justificativa.

Semana 2: Faça cumprir e eduque

• Adicione uma checagem de trailers ao CI como verificação obrigatória. Ela inspeciona todos os commits em um PR e falha se aparecerem trailers não permitidos, se o DCO estiver ausente em repositórios que o exigem ou se os trailers estiverem malformados.
• Publique a política de IA em duas páginas com exemplos. Mostre como é “divulgar no corpo do PR” e quando a coautoria explícita é adequada (por exemplo, pair programming com outro engenheiro).
• Atualize CODEOWNERS em todos os serviços para garantir que a responsabilidade humana se alinhe com os revisores reais.

Semanas 3–4: Prove de ponta a ponta

• Adicione proveniência aos releases usando ferramentas alinhadas ao SLSA. Armazene atestações onde auditores e adquirentes possam acessá‑las.
• Gere SBOMs automaticamente e peça que um responsável humano pelo release dê o sign‑off, registrando em notas de release quaisquer áreas de código assistidas por IA quando relevante.
• Instrumente métricas: acompanhe a porcentagem de PRs que falham na checagem de trailers, o tempo mediano para remediar e a cobertura de SBOM/proveniência entre serviços. Espere um pico inicial e depois estabilização.

Configurações concretas de Git/GitHub/GitLab que funcionam

• Commit trailers 101: O Git trata trailers como linhas estruturadas no fim de mensagens de commit. Leia o comportamento canônico em git-interpret-trailers. Use isso para parsing determinístico nas suas checagens.
• Lista de trailers permitidos: Assunto, corpo, Signed‑off‑by, Reviewed‑by para revisores humanos e um Change‑id interno se você usa IDs ao estilo Gerrit. Só isso. Todo o resto vai para a descrição do PR.
• Padrões de trailers não permitidos: Qualquer Co‑Authored‑by que faça referência a ferramentas ou agentes; qualquer trailer sem e‑mail humano verificável; linhas duplicadas de Signed‑off‑by da mesma identidade; trailers exóticos adicionados por IDEs ou bots que não estão no seu registro.
• Proteção de branch no GitHub: Exija commits assinados; exija checagens de status (a checagem de trailers e DCO, se usado); faça valer admins; e bloqueie force pushes. Espelhe isso no GitLab com push rules e branches protegidos.
• Sigstore keyless: Adote assinatura respaldada por OIDC no CI para que suas identidades de serviço assinem artefatos sem chaves de longa duração. Isso reduz a proliferação de segredos e se alinha ao mindset de “eliminar o token de longa duração”.

Como lidar com coautoria real e transparência sobre IA sem caos

Você vai receber resistência se a política parecer teatro. Mantenha‑a prática:

• Programação em par: Permita Co‑Authored‑by para pares humanos em trabalhos de feature, limitado a e‑mails corporativos na lista de permissão. Remova em hotfixes e branches de release para manter trilhas de auditoria limpas.
• Divulgação de assistência de IA: Exija que desenvolvedores anotem “Assistência substancial de IA” nas descrições de PR com dois bullets: o nome da ferramenta e o escopo (por exemplo, scaffolding de uma suíte de testes). Nada de trailers no nível do commit.
• Contribuições upstream: Siga as regras dos mantenedores upstream. Se exigirem divulgação de IA no próprio commit, faça isso só naquele fork, com a exceção documentada no PR e no seu tracker interno.
• Caminho de exceção: Disponibilize um processo de exceção no mesmo dia, sob responsabilidade de DevEx ou Staff Eng. Nada azeda mais uma política do que um release bloqueado sem um adulto na sala.

Realidade nearshore: padronize o ambiente, não a pessoa

Times distribuídos amplificam a deriva de configuração. A solução não é mais reuniões; é menos snowflakes.

• Devboxes gerenciados para contratados: Forneça devcontainers predefinidos ou workstations em nuvem com seus hooks, templates e políticas de extensões pré‑carregados. Para times US–Brazil, você ainda tem 6–8 horas de sobreposição para resolver casos de borda no mesmo dia.
• Fonte única da verdade: Mantenha templates, hooks e scripts de aplicação em um repositório interno centralizado e incremente uma versão em cada serviço. Upgrades são PRs, não um ping no Slack.
• Onboarding em 90 minutos: Durante o onboarding nearshore, inclua um walkthrough hands‑on: acione a checagem de trailers, corrija um commit que falhou e assine um release fictício. Isso é mais barato do que descobrir durante um lançamento crítico.

Risco, trade‑offs e ROI

Alguns desenvolvedores vão chamar isso de “nannyware”? Sim. O antídoto é velocidade e clareza. Hooks devem falhar rápido com uma mensagem útil; exceções devem ser possíveis e ágeis; e a política deve preferir divulgação no nível do PR a uma metadata de commit barulhenta.

O ROI não é especulativo. Histórico limpo e releases assinados encurtam diligências, suavizam auditorias e reduzem as escaladas do tipo “o que exatamente é essa linha de Copilot?” vindas do jurídico. Para a maioria dos times, isso significa dias economizados em cada ciclo de auditoria e menos caos de fim de semana antes de grandes releases. Mais importante, você preserva opcionalidade: pode consumir ou contribuir com projetos open source com políticas de IA incompatíveis porque controla como a atribuição aparece.

E a próxima surpresa do seu IDE?

Pressuponha que mais padrões mudarão sem aviso — fornecedores de IDE lançam rápido, e a UX de coding assistido por IA evolui semanalmente. Tudo bem se você construiu camadas. Hooks e templates locais capturam a deriva, checagens do lado do servidor impõem o piso, a política define a intenção e a proveniência prova o que você embarcou. Você pode adotar as ferramentas sem adotar a metadata delas.

Principais pontos

• O histórico do Git é prova legal e de cadeia de suprimentos. Trate a metadata de commits como uma API que você controla.
• Não dependa da vigilância do desenvolvedor. Use camadas: hooks locais, aplicação no servidor, política clara e proveniência alinhada ao SLSA.
• Mantenha a atribuição fora dos trailers de commit. Coloque a divulgação de IA nas descrições de PR; reserve trailers para DCO e revisão humana.
• Exija commits assinados em branches protegidos e verifique identidades de bots e humanos.
• Padronize ambientes de desenvolvimento para times nearshore para que configurações não derivem. Entregue a política dentro do “box”.
• Crie um caminho de exceção. Velocidade e clareza vencem proibições genéricas sempre.