Depois de meses de discussão, brigas públicas e pelo menos um episódio que virou escândalo na comunidade open source, o kernel Linux finalmente aprovou uma política oficial sobre o uso de inteligência artificial no desenvolvimento de código. E o que ela diz é mais simples do que parece: pode usar IA, mas você precisa declarar isso. E o erro, se vier, é seu.
Para quem acompanha o debate sobre IA no setor jurídico, a decisão do Linux tem muito a ensinar.
O que mudou de fato
A política proíbe o uso da etiqueta “Signed-off-by” para código gerado com auxílio de IA. Esse campo, no jargão do desenvolvimento de software, tem peso legal: é a assinatura do desenvolvedor garantindo que o código que ele está entregando é de sua autoria e responsabilidade.
No lugar disso, criaram a etiqueta “Assisted-by”. Traduzindo: o desenvolvedor continua responsável por tudo, mas agora tem a obrigação de informar que usou um assistente de IA no processo. Transparência obrigatória, responsabilidade total.
Linus Torvalds, o criador do Linux, deixou claro sua posição durante o debate: banir a IA seria inútil. Ele argumentou que a IA é uma ferramenta como qualquer outra e que atacantes mal-intencionados não vão parar de usar IA só porque existe uma regra interna. O foco certo, na visão dele, é controlar os resultados pela responsabilidade individual, não tentar regular o que acontece no computador de cada desenvolvedor.
A política na íntegra
O documento oficial está disponível publicamente na documentação do kernel Linux, em docs.kernel.org/process/coding-assistants.html. Vale a pena ler na íntegra porque é curto, direto e serve de referência para qualquer debate sobre governança de IA em projetos profissionais:
AI Coding Assistants (Documento oficial: Documentation/process/coding-assistants.rst — Linux Kernel 7.0)
Este documento fornece orientações para ferramentas de IA e para desenvolvedores que usam assistência de IA ao contribuir com o kernel Linux.
Ferramentas de IA que auxiliam no desenvolvimento do kernel Linux devem seguir o processo padrão de desenvolvimento do kernel.
Licenciamento e requisitos legais
Todas as contribuições devem estar em conformidade com os requisitos de licenciamento do kernel:
- Todo o código deve ser compatível com GPL-2.0-only
- Usar os identificadores de licença SPDX apropriados
Signed-off-by e Developer Certificate of Origin
Agentes de IA NÃO DEVEM adicionar tags Signed-off-by. Somente humanos podem certificar legalmente o Developer Certificate of Origin (DCO). O responsável pela submissão humana é responsável por:
- Revisar todo o código gerado por IA
- Garantir a conformidade com os requisitos de licenciamento
- Adicionar sua própria tag Signed-off-by para certificar o DCO
- Assumir total responsabilidade pela contribuição
Atribuição
Quando ferramentas de IA contribuem para o desenvolvimento do kernel, a atribuição adequada ajuda a rastrear o papel em evolução da IA no processo de desenvolvimento. As contribuições devem incluir uma tag Assisted-by no seguinte formato:
Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]Onde:
AGENT_NAMEé o nome da ferramenta ou framework de IAMODEL_VERSIONé a versão específica do modelo utilizado[TOOL1] [TOOL2]são ferramentas de análise especializadas opcionais usadas (ex.: coccinelle, sparse, smatch, clang-tidy)Ferramentas de desenvolvimento básicas (git, gcc, make, editores) não devem ser listadas.
Exemplo:
Assisted-by: Claude:claude-3-opus coccinelle sparse
Três seções. Menos de uma página. A maior organização de software open source do mundo não precisou de mais do que isso para regulamentar o tema.
Por que isso levou tanto tempo
O debate não foi tranquilo. Em janeiro deste ano, representantes da Intel e da Oracle entraram em conflito aberto sobre como regulamentar o uso de redes neurais no projeto. De um lado, quem queria restrições mais duras. Do outro, quem enxergava qualquer proibição como impraticável.
E é importante lembrar que outros projetos open source tomaram decisões bem diferentes antes disso. Gentoo e NetBSD chegaram a bloquear completamente a aceitação de código gerado por IA. O argumento deles era técnico e jurídico ao mesmo tempo: os dados usados para treinar modelos de linguagem frequentemente incluem código com licenças restritivas. Se o modelo “aprendeu” com código licenciado sob GPL, o que ele produz pode estar contaminado juridicamente, e ninguém consegue garantir a origem de cada linha.
A Red Hat foi na mesma direção: alertou que o uso de IA poderia violar inadvertidamente a licença GNU GPL e comprometer todo o sistema de certificação de origem do desenvolvedor, o DCO. O problema é que o desenvolvedor assina dizendo que garante a pureza do código que entrega, e com IA no meio, essa garantia fica difícil de sustentar.
O episódio que acelerou a discussão
A situação se tornou urgente depois de um caso concreto que chamou atenção de todos.
Um engenheiro da Nvidia chamado Sasha Levin implementou um patch para o kernel 6.15 escrito inteiramente por um modelo de IA, sem avisar ninguém. O código era funcional. Passou nos testes. Mas apresentou uma regressão de desempenho que só foi identificada depois. O problema maior, porém, não foi o bug técnico: foi a falta de transparência. A comunidade não sabia que estava avaliando código de IA como se fosse código escrito por um humano.
Outro caso que mostra bem a dimensão do problema aconteceu no projeto GZDoom, um mod do clássico jogo Doom. O líder do projeto, Christoph Oelckers, usou patches gerados por IA sem revelar isso e depois se recusou a ceder às críticas da comunidade. O resultado foi um êxodo: a maioria dos colaboradores deixou o projeto e criou um fork chamado UZDoom. Uma ruptura real, por falta de honestidade sobre como o trabalho estava sendo feito.
Fora isso, projetos populares como cURL e tldraw foram forçados a encerrar programas de recompensas por bugs ou a rejeitar automaticamente contribuições externas. Motivo: uma enxurrada de código gerado por IA, cheio de alucinações, sobrecarregou os mantenedores com trabalho inútil.
O que isso tem a ver com escritórios de advocacia
Bastante, na verdade.
Quando um advogado usa IA para redigir uma petição, um parecer ou uma minuta de contrato, ele está na mesma situação do desenvolvedor que entrega código ao kernel Linux: a responsabilidade pelo resultado é inteiramente dele. O fato de ter usado uma ferramenta de IA não muda nada nisso, nem juridicamente, nem do ponto de vista ético.
Mas o que o caso do Linux deixa claro é que o problema maior quase nunca é o uso da ferramenta em si. É a falta de transparência sobre esse uso.
Quando um cliente recebe uma peça jurídica produzida com auxílio de IA, sem saber disso, existe uma assimetria de informação que pode ser problemática. Não porque a IA necessariamente entregou algo de má qualidade, mas porque o cliente não teve a chance de avaliar o processo com consciência. Assim como a comunidade Linux não sabia que estava revisando código de IA como se fosse humano.
Nos escritórios que acompanho, a pergunta que mais ouço é “a IA pode errar?”. Pode, claro. Mas a pergunta mais relevante é outra: quem revisa e quem assina? Porque é essa pessoa que responde.
Responsabilidade frente à IA: o ponto que não dá para ignorar
Aqui está o que me parece mais importante em toda essa história do Linux, e que se aplica diretamente ao setor jurídico.
A política do kernel não criou uma nova categoria de culpa. Ela apenas deixou explícito o que já era verdade: quem assina, responde. O que mudou é que agora está escrito. E quando está escrito, ninguém pode fingir que não sabia.
No direito, isso já existe há muito tempo. O advogado que assina uma peça é responsável pelo conteúdo dela, independentemente de quem ou do que a redigiu. Isso não mudou com a IA. O que mudou é o volume de conteúdo que pode ser produzido, a velocidade com que isso acontece e, principalmente, o nível de confiança que o texto gerado inspira à primeira leitura.
Um texto de IA bem escrito parece razoável. Às vezes parece muito bom. Mas “parece bom” e “está correto” são duas coisas completamente diferentes, especialmente quando o assunto é jurisprudência, prazos, valores ou interpretação de cláusulas contratuais.
O risco real não é o advogado que usa IA com cuidado, revisa tudo e assume o resultado. Esse está trabalhando bem, possivelmente melhor do que antes. O risco é o advogado que usa IA como atalho, que entrega o que saiu sem revisar a fundo, e que vai descobrir o problema na hora errada: dentro de um processo, diante de um cliente, ou num prazo que já passou.
No Linux, quando isso acontece, a pessoa vai ter que responder ao Linus Torvalds. No direito, vai ter que responder ao cliente, ao tribunal e, eventualmente, à OAB.
A lição prática não é complicada: use IA, use com inteligência, revise tudo o que sair dela, e assuma o que você entrega. O documento do kernel Linux pode ter sido escrito para desenvolvedores de software, mas poderia ter sido escrito para qualquer profissional que usa IA em trabalho que tem consequências reais para outras pessoas.
A diferença é que no Linux agora existe uma política escrita. Na advocacia, a responsabilidade sempre existiu. Só que muita gente ainda está fingindo que a ferramenta nova muda isso.
Não muda.
A política oficial do kernel Linux sobre IA está disponível em: https://docs.kernel.org/process/coding-assistants.html
Gustavo Rocha
Consultor em gestão, tecnologia e marketing jurídico
Especialista em Inteligência Artificial aplicada ao Direito e em Privacidade
Professor de Pós-Graduação e coordenador de grupos de estudos na ESA/RS
Membro de comissões da OAB/RS e OAB/SP
Site: http://www.gustavorocha.com | E-mail: gustavo@gustavorocha.com
WhatsApp/Telegram: (51) 98163.3333
GustavoRocha.com 