Políticas de IA para código em projetos open source

O que fazer antes de enviar código assistido por IA para um projeto

Os projetos de código aberto publicam atualmente políticas sobre código assistido por IA, e essas políticas não são uniformes. Portanto, adote uma prática simples: procure a política antes de escrever o patch e divulgue as informações com exatidão ao enviá-lo. Há uma regra comum a todas elas: nunca envie uma linha que não consiga explicar durante a revisão.

Mesmo um patch correto pode ser encerrado se o projeto proibir código gerado ou se tiver ocultado a origem do código. O impacto fica associado ao seu nome, porque um maintainer que descubra a omissão mais tarde não terá motivos para confiar no restante do seu histórico. Primeiro, algumas definições, porque as políticas usam estes termos. Um LLM (large language model) é o modelo por trás do seu coding agent. Um PR (pull request) no GitHub corresponde a um MR (merge request) no GitLab, e tudo o que segue aplica-se aos dois. O DCO (developer certificate of origin) é a linha de sign-off no fim da mensagem de um commit e acaba por ser o centro de toda a discussão.

Onde as políticas de código aberto sobre código gerado por IA chegaram

Os projetos estabeleceram quatro categorias. Todos os exemplos abaixo têm data, porque estes textos mudam.

Proibido. O conselho do Gentoo votou em 14 April 2024 que é "expressamente proibido contribuir para o Gentoo com qualquer conteúdo criado com a assistência de ferramentas de inteligência artificial de processamento de linguagem natural". As diretrizes de commits do NetBSD classificam a saída de um LLM como "código contaminado" que "não pode ser submetido sem aprovação prévia por escrito do core". O documento de proveniência de código do QEMU, em August 2026, ainda afirma que o projeto vai "RECUSAR quaisquer contribuições que se considere que incluem ou derivam de conteúdo gerado por IA".

Apenas para análise. A maioria das proibições é mais restrita do que o título sugere. O documento do QEMU afirma que a política "não se aplica a outros usos de IA, como pesquisar APIs ou algoritmos, análise estática ou depuração, desde que a respetiva saída não seja incluída nas contribuições". Pode usar o agente para ler o código. Não pode distribuir o que ele escreveu. Essa distinção é a regra prática na maioria dos projetos restritivos e é o ponto que as pessoas não percebem.

Divulgação obrigatória. O conselho do Fedora aprovou uma política sobre contribuições assistidas por IA em October 2025. A política permite as ferramentas e atribui a responsabilidade à pessoa: o contribuinte é o autor, responde integralmente por toda a contribuição e deve divulgar quando uma parte significativa dela tiver vindo de uma ferramenta sem alterações. O kernel Linux ganhou uma página sobre assistentes de programação na documentação de processos em December 2025, com um trailer para registar a ferramenta e uma regra rígida sobre quem pode aprovar a contribuição.

Nada escrito. Este ainda é o caso comum. Um preprint de May 2026 analisou 1,000 repositórios populares do GitHub e encontrou 118 com alguma política de IA escrita. O silêncio não é autorização. Faça uma pergunta numa frase no issue tracker antes de escrever o patch, e a resposta passa a ser um registo público que pode consultar mais tarde.

Por que os maintainers escreveram estas regras

O primeiro motivo é a carga de revisão, e a aritmética funciona apenas num sentido. Um agente produz uma merge request plausível com 400 linhas num minuto. Rever essa request corretamente custa uma tarde ao maintainer, e a maioria dos maintainers trabalha como voluntário. O custo de submeter caiu para quase zero. O custo de rever não mudou.

O curl mostra o extremo dessa curva. Em meados de 2025, Daniel Stenberg informou que aproximadamente um quinto dos relatórios de segurança recebidos através do bug bounty do projeto era o que ele chama de AI slop: relatórios que citam funções e caminhos de código reais, descrevem um ataque plausível e não contêm nada. O projeto encerrou o bounty no início de 2026 em vez de continuar a financiar essa enxurrada. Eram relatórios, não patches, mas o mecanismo é o mesmo que faz um maintainer abrir a sua PR já cansado.

O GNOME Calendar registou o problema como um rótulo. Em junho de 2026, o projeto introduziu "Probabilistically Automated" para merge requests que demonstrassem "dependência grande ou total de 'inteligência' artificial para gerar código" e identificou exatamente o sintoma: "normalmente acompanhada pela ausência de testes adequados e pela finalização de patches com base no comportamento teórico pretendido, e não na correção do código". Leia essa última frase duas vezes. O código parece funcionar. Ninguém verificou se funciona.

O segundo motivo é a proveniência, ou seja, de onde veio o código e ao abrigo de que licença. O QEMU declara o conflito claramente: assinar o sign-off confirma que você "compreende totalmente o estado dos direitos de autor e da licença do conteúdo" que contribui, e o estado dos direitos de autor do output dos modelos continua indefinido. O conselho do Gentoo apresentou o mesmo motivo, além de questões de qualidade e ética. Você não precisa concordar com a interpretação jurídica. Mas precisa perceber que essa decisão cabe ao maintainer, não a você.

Como encontro a política de IA de um projeto?

Procure nestes locais, pela ordem indicada.

• CONTRIBUTING.md na raiz do repositório, depois .github/CONTRIBUTING.md e, em seguida, qualquer ficheiro DCO junto desses ficheiros.
• A documentação para programadores. O QEMU mantém a sua regra em docs/devel/code-provenance.rst. O kernel mantém a sua em Documentation/process/coding-assistants.rst.
• O site ou wiki do projeto. A política do Gentoo está na página do wiki do council, e a do NetBSD está nas diretrizes para commits.
• O sistema de acompanhamento de issues e o arquivo da lista de discussão. Normalmente, uma política existe nesses locais durante meses antes de alguém a escrever no repositório.

A partir de um checkout, um grep cobre a maior parte dos casos:

grep -rniE '(llm|copilot|chatgpt|generative|ai-generated|ai-assisted)' CONTRIBUTING.md docs/ .github/ 2>/dev/null | head -20

Depois, consulte o próprio histórico do projeto, porque a convenção registada no repositório prevalece sobre qualquer resumo dessa convenção:

git log --format='%(trailers:key=Assisted-by,valueonly)' | grep . | sort | uniq -c
git log --format='%(trailers:key=AI-used-for,valueonly)' | grep . | sort | uniq -c

Uma contagem junto de um valor de trailer mostra o formato que o projeto realmente utiliza. Um resultado vazio significa que ninguém declarou nada nesse formato neste local, o que também é informação. Se o projeto estiver no GitHub e o fluxo de trabalho for novo para si, como funcionam os pull requests e os forks no GitHub explica os mecanismos assumidos nesta secção.

Divulgue no trailer do commit, não num comentário

Um trailer é uma linha Key: value no último parágrafo da mensagem de um commit. O Git já usa este formato para Signed-off-by: e Co-authored-by:, e as ferramentas analisam-no. Por isso, é a única divulgação que acompanha o código até à árvore.

net: release the buffer on the error path

The error path returned before releasing the buffer, so every failed
setup leaked one page.

Assisted-by: Claude:claude-3-opus coccinelle sparse
Signed-off-by: Your Real Name <you@example.com>

O kernel documenta esse formato como Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2] e define explicitamente o limite da linha: "AI agents MUST NOT add Signed-off-by tags. Only humans can legally certify the Developer Certificate of Origin (DCO)." O nome do agente fica em Assisted-by. O seu nome fica em Signed-off-by. Nunca permita que uma ferramenta escreva o segundo. Nunca permita que invente um endereço Co-authored-by que não pertença a ninguém.

Os nomes variam. Por isso, copie o nome local em vez de inventar um. Um patch publicado na lista do QEMU em May 2026 propôs flexibilizar a proibição desse projeto para alterações mecânicas, testes, documentação e correções de erros com vinte linhas ou menos, registadas com um trailer como AI-used-for: tests, docs. Em August 2026, isso continua a ser uma proposta numa lista de correio, e o documento aprovado ainda rejeita conteúdo gerado. Um projeto alterou a sua posição duas vezes entre 2023 e 2026. A próxima alteração não esperará por si. É por isso que o método é mais importante do que a lista.

git commit -s --trailer "Assisted-by: Claude:claude-3-opus" -m "net: release the buffer on the error path"
git log -1 --format='%(trailers:key=Assisted-by,valueonly)'

--trailer requer Git 2.32 ou mais recente. O segundo comando deve devolver-lhe diretamente o valor. Uma linha vazia significa que o git não analisou o trailer. Quase sempre isso acontece porque existe uma linha vazia ou uma frase normal dentro do bloco de trailers no final da mensagem. Para uma série que já tenha escrito, git rebase --signoff origin/main adiciona a assinatura a todos os commits, e git interpret-trailers --in-place --trailer "Assisted-by: Claude:claude-3-opus" msg.txt edita um ficheiro de mensagem.

Vale a pena planear para dois modos de falha. Um squash merge reescreve a mensagem do commit. Por isso, num projeto que faz squash, repita a divulgação na descrição do PR, onde o maintainer a lerá. Um comentário de revisão não é um registo, porque os comentários podem ser editados e nunca ficam no histórico do git.

A precisão funciona nos dois sentidos. Assisted-by num commit que escreveu manualmente é ruído e reduz o valor das suas divulgações reais. Omiti-lo num commit escrito pelo agente é o que termina a relação.

O que o Signed-off-by atesta?

O DCO é um texto curto, na versão 1.1, publicado em developercertificate.org e utilizado pelo kernel, pelo QEMU e por muitos outros projetos. Adicionar Signed-off-by: Your Name <you@example.com> significa que você declara estar de acordo com ele. Leia o que está a declarar, porque muitas pessoas adicionam essa linha sem nunca ler o texto.

A cláusula (a) afirma que a contribuição "foi criada total ou parcialmente por mim e que tenho o direito de a submeter sob a licença open source indicada no ficheiro". A cláusula (b) abrange trabalho baseado em código open source anterior que você tem o direito de transmitir com modificações. A cláusula (c) abrange código que lhe foi entregue por alguém que certificou a mesma coisa. A cláusula (d) afirma que você compreende que a contribuição e as informações pessoais incluídas no seu sign-off são públicas e são conservadas indefinidamente.

Observe o que não está incluído. O DCO nunca afirma que você escreveu todos os caracteres. Afirma que você tem o direito de submeter o código sob esta licença. É por isso que o código gerado se enquadra aqui de forma pouco clara: a questão não é a autoria, mas sim se você consegue indicar a origem. A maioria dos projetos que exigem sign-off também exige um nome real, portanto um pseudónimo falha nessa verificação. Adicione a linha com git commit -s, que lê user.name e user.email da sua configuração do git. Quando um bot de DCO rejeitar o seu PR e indicar o commit que não contém a linha, git rebase --signoff origin/main e um force push para a sua branch resolvem o problema.

Assinar um commit não é o mesmo que dar sign-off

git commit -s adiciona uma linha de texto. git commit -S cria uma assinatura criptográfica sobre o objeto do commit usando a sua chave GPG ou SSH. Cada um responde a uma pergunta diferente. A assinatura atesta que este commit veio do titular dessa chave e não foi alterado desde então. Não informa a origem do código contido no commit. Por isso, um commit assinado que contenha muito código gerado não declarado continua a ser uma violação da política. O sign-off é a declaração sobre a origem. A assinatura é a declaração sobre a identidade. Os projetos que exigem ambos pedirão ambos.

Nunca envie código que não consiga explicar numa revisão

Este é o teste, e não é realmente sobre honestidade. Para cada linha, responda: para que serve e o que deixa de funcionar sem ela? Se faltar uma das respostas, o patch não está pronto, porque o comentário da revisão vai chegar e a sua resposta resultará noutra ronda de geração. Os revisores percebem. É nesse momento que um contribuinte passa a ser um custo. Faça a mesma pergunta sobre os casos-limite, a entrada vazia, o caminho de falha e o segundo chamador.

Execute o código. Compile-o, execute a suíte de testes do projeto e escreva um reproduzidor para o bug que afirma corrigir. A documentação do kernel apresenta a alternativa correta em termos claros: "Se a correção não pôde ser compilada ou testada, ou se não foi possível produzir um reproduzidor, diga isso explicitamente: atualmente, os mantenedores perdem demasiado tempo a analisar relatórios não verificados e correções não testadas." Escrever "Não consegui testar isto em hardware real" não lhe custa nada. Dar a entender que testou custa o projeto.

Responda aos comentários da revisão pessoalmente, com as suas próprias palavras e no seu próprio ritmo. Uma resposta publicada trinta segundos depois do comentário e que o repete em cinco parágrafos diz exatamente ao mantenedor o que aconteceu. Mantenha também o diff pequeno. Quarenta linhas que compreende completamente valem mais para um projeto do que uma refatoração de quatrocentas linhas que apenas supervisionou. Se o seu agente continuar a devolver mais do que pediu, uma competência que o obriga a fazer apenas a menor alteração funcional é uma forma de manter o patch suficientemente pequeno para que ainda consiga defendê-lo linha a linha.

Mantenha as instruções do agente no repositório

As instruções fornecidas ao agente fazem parte da sua cadeia de ferramentas, portanto trate-as como código. Um ficheiro na raiz do repositório, normalmente AGENTS.md, contém o comando de compilação, o comando de teste, o formato da mensagem de commit, o requisito de assinatura e as regras de estilo já documentadas pelo projeto. Esse ficheiro é versionado e pode ser revisto, mantendo-se igual amanhã e hoje. As instruções reescritas de memória a cada sessão produzem um patch diferente em cada sessão, e não saberá qual sessão produziu o patch rejeitado. Como escrever um AGENTS.md que um agente e uma pessoa conseguem ler aborda o próprio ficheiro.

Tenha cuidado com os repositórios de outras pessoas. Não faça da sua primeira contribuição um PR que adiciona um ficheiro de instruções do agente a um projeto que não mantém. Isso parece uma tentativa de definir de fora a política de ferramentas do projeto e é uma forma rápida de associar a sua conta àquilo de que os responsáveis pela manutenção já estão fartos. Mantenha o ficheiro no seu fork até alguém o solicitar.

O local onde executa o agente é importante pelo mesmo motivo. Um agente que consegue compilar o projeto e executar os testes dentro de uma sandbox que controla fornece um patch que verificou efetivamente. Essa é a diferença entre declarar a assistência e declarar um palpite. Executar um agente de programação no seu próprio VPS aborda essa configuração, e Diferenças práticas entre Claude Code, Cursor, Codex e Copilot explica como as ferramentas diferem no dia a dia.

O método, depois de alterar a política

1. Localize a política indicada antes de escrever qualquer coisa: repositório, documentação do projeto, site ou sistema de acompanhamento.
2. Se não existir uma política, faça a pergunta no issue numa única frase e guarde a resposta.
3. Faça a divulgação no formato usado pelo projeto, no trailer do commit, e repita-a no corpo do PR se o projeto fizer squash dos commits.
4. Assine com o seu nome verdadeiro, sabendo que essa linha declara que tem o direito de submeter o código.
5. Reveja o seu próprio patch como se tivesse sido escrito por outra pessoa, porque foi.

Todos os projetos mencionados nesta página terão mudado quando a ler. Os cinco passos não mudam.

FAQ

Tenho de declarar que usei um agente de programação com IA?

Consulte o projeto, porque a resposta é definida localmente. O Fedora exige uma declaração quando uma parte significativa da contribuição veio de uma ferramenta sem alterações. O kernel Linux exige um trailer Assisted-by. O Gentoo e o QEMU, em agosto de 2026, não aceitam de todo a contribuição. Quando não houver nada escrito, faça a declaração mesmo assim num trailer do commit. Um maintainer que descubra o uso mais tarde reage à omissão, não à ferramenta, e essa reação fica associada a tudo o que enviou.

Que projetos open source proíbem código gerado por IA?

Segundo o estado em agosto de 2026: o Gentoo desde abril de 2024, o NetBSD, que trata o resultado de LLM como código contaminado que requer aprovação do core, o QEMU, que recusa contribuições derivadas de conteúdo gerado, e várias aplicações do GNOME, incluindo Loupe e Calendar. Leia o texto do próprio projeto em vez de confiar nesta lista, porque ela ficará desatualizada. Tenha em atenção a exceção partilhada pela maioria: usar um modelo para pesquisar uma API, executar análise estática ou ajudar na depuração costuma ser aceitável, desde que o resultado não esteja no patch.

Qual é a diferença entre Signed-off-by e um commit assinado?

Signed-off-by é uma linha de texto simples adicionada por git commit -s. Ela certifica a declaração de origem do developer, o que significa que tem o direito de submeter este código sob a licença do projeto. Um commit assinado, criado com git commit -S, é uma assinatura criptográfica sobre o objeto do commit, usando a sua chave GPG ou SSH. Isso prova que o commit veio da sua chave e não foi alterado. A origem e a identidade são afirmações separadas, por isso um commit assinado ainda pode violar uma política sobre IA.

Posso colocar a declaração na descrição do pull request em vez da mensagem do commit?

Coloque-a na mensagem do commit, porque esse é o registo que entra no histórico do git e acompanha o código para qualquer pessoa que clone o repositório mais tarde. A descrição de um pull request pode ser editada posteriormente e fica na plataforma de alojamento. Adicione-a também ao corpo do PR quando o projeto fizer squash merge, porque um squash reescreve a mensagem do commit e pode remover o trailer.

O meu pull request foi fechado porque foi gerado por IA. E agora?

Não discuta a política na thread, porque a pessoa que o fechou não criou a regra sozinha e a thread não é o local onde ela muda. Leia o texto da política e decida se consegue cumpri-la. Quando o projeto proíbe patches gerados, um relatório de bug claro, com um reproducer e sem patch, continua a ser bem-vindo e muitas vezes é a contribuição mais útil. Se voltar com código, apresente uma alteração pequena que consiga defender linha a linha.