De quem é o código que a IA escreveu

No Brasil, o código que um agente de IA escreveu para você é seu, porque a Lei 9.609/98 protege o programa como obra e atribui o direito a quem encomendou ou empregou. A ferramenta não é autora e os termos das principais plataformas dizem de forma explícita que a saída pertence ao cliente. O que realmente derruba projeto em auditoria não é a autoria do código, é a licença das bibliotecas que o agente trouxe junto sem avisar.

Este texto separa três coisas que quase sempre viram uma só na conversa e que têm respostas jurídicas diferentes. Propriedade do código encomendado é assunto de contrato e de lei de software. Licença de dependência é assunto de compatibilidade entre licenças de terceiros. Responsabilidade por defeito é assunto de garantia contratual, e nenhuma das três se resolve com uma cláusula genérica proibindo uso de IA.

Quem é o dono do código gerado por um agente?

A ferramenta não reivindica o resultado e não figura como autora em lugar nenhum da cadeia. O que você escreve como entrada continua seu, e o que sai da ferramenta é tratado contratualmente como seu também. No Brasil, quando o software é feito sob encomenda ou por empregado, o direito patrimonial fica com quem encomendou ou empregou, salvo acordo em contrário. A discussão prática quase nunca é sobre quem é o dono, é sobre o contrato dizer isso com clareza.

A última linha da tabela é a única de verdade incerta no direito brasileiro, e ela quase nunca é o problema real de quem contrata software. Reprodução literal de bloco longo e reconhecível é rara em código de aplicação comum. O risco cresce em código muito idiomático, como algoritmo conhecido publicado em projeto famoso. Para trabalho de negócio, a preocupação prática está uma linha acima, na licença das dependências.

Por que a licença da dependência é o risco maior?

Um agente resolve o problema que você pediu usando o que já existe no ecossistema, e o que existe vem com licença própria. Ninguém lê essa licença no meio de uma sessão de trabalho, e é assim que uma biblioteca com exigência de abertura entra num produto que você pretende vender fechado. O problema só aparece na auditoria de um cliente grande ou numa rodada de investimento. Nesse ponto, remover a dependência costuma exigir reescrever a parte do sistema que dependia dela.

Licença permissiva: MIT, Apache e BSD permitem uso em produto comercial fechado, exigindo apenas manter o aviso de direito autoral e a cópia da licença. São a maioria do ecossistema moderno e não criam obrigação de abrir seu código. Apache ainda concede licença de patente explícita, o que agrada departamento jurídico de empresa grande.

Licença copyleft forte: GPL e AGPL podem obrigar a distribuir o código do produto inteiro sob a mesma licença quando há distribuição. A AGPL vai além e alcança software servido pela internet, o que atinge SaaS mesmo sem entregar binário. Uma única dependência AGPL no lugar errado transforma produto proprietário em obrigação de abertura.

Licença ausente: repositório sem arquivo de licença é o pior caso e não o mais permissivo, ao contrário do que a intuição sugere. Sem concessão expressa, o padrão legal é que você não recebeu direito de uso nenhum. Código copiado de resposta de fórum entra na mesma categoria e costuma passar despercebido.

Licença dupla: alguns projetos oferecem uma versão livre com restrição e uma versão comercial paga para uso fechado. Usar a versão livre dentro de produto pago viola o acordo mesmo quando o código é tecnicamente idêntico. Verificar isso é rápido e evita a conversa cara depois.

Como auditar as licenças sem ler cada uma?

A auditoria de licença é uma das poucas tarefas de conformidade que dá para automatizar por completo. Os gerenciadores de pacote modernos conseguem listar toda a árvore de dependências com a licença declarada de cada item. Rodar essa listagem num gate automático, junto com teste e verificação de segurança, custa minutos de configuração. O relatório vira anexo de entrega e resolve a pergunta antes de o cliente fazer.

O que a ferramenta não pega é dependência copiada na mão para dentro do projeto, sem passar pelo gerenciador. Esse é justamente o caso mais comum quando um agente resolve um problema pequeno colando um trecho. A defesa é revisar adições grandes de código que não vieram acompanhadas de uma nova dependência declarada. Bloco extenso e estilisticamente diferente do resto do projeto merece uma busca rápida pela origem.

O que colocar no contrato quando a IA participa da entrega?

A cláusula que resolve a maior parte da discussão é curta e trata de cessão de direitos, não de tecnologia empregada. Contrato que tenta proibir uso de IA costuma ser inaplicável, impossível de fiscalizar e não protege ninguém de nada. O que protege é dizer com clareza para quem vai o direito e o que acontece se aparecer problema de licença. Quatro pontos cobrem quase todos os casos de projeto de software sob medida.

Cessão total e definitiva: declare que todo direito patrimonial sobre o entregável passa ao contratante na quitação, independentemente da ferramenta usada para produzi-lo. Essa redação neutra sobrevive à próxima mudança de tecnologia sem precisar de aditivo. Amarrar a cláusula a uma ferramenta específica cria buraco quando a ferramenta muda.

Declaração de licenças: exija a lista de dependências com a licença de cada uma, entregue junto com o código-fonte. O item é gerável automaticamente e custa quase nada para o fornecedor honesto. Fornecedor que resiste a entregar essa lista está sinalizando algo que vale investigar antes de assinar.

Garantia de originalidade razoável: peça declaração de que o fornecedor não incorporou código de terceiro sem licença compatível, com prazo definido de correção se aparecer. Garantia absoluta ninguém consegue dar de forma honesta, e prometer isso é sinal de quem não entendeu o problema. O que se contrata é diligência e conserto, não infalibilidade.

Responsabilidade por defeito: separe defeito de mudança de escopo, com janela de garantia clara e critério objetivo de classificação. Essa é a briga que realmente acontece nos projetos, muito mais que discussão de autoria. Definir isso antes evita transformar cada pedido novo em negociação sobre quem paga.

Isso muda se você usou o plano gratuito da ferramenta?

Muda, e vale ler os termos antes de construir produto comercial em cima de um plano pessoal. Alguns planos gratuitos permitem uso do conteúdo para melhoria do serviço, o que é aceitável para estudo e ruim para código de cliente. Em projeto pago, código sob acordo de confidencialidade não deveria transitar por plano com essa permissão. A diferença de preço entre plano pessoal e comercial é pequena perto do risco contratual.

Em trabalho pago eu opero sempre em plano comercial e trato isso como custo de operação, não como luxo. A página de termos comerciais da Anthropic deixa explícito que a saída pertence ao cliente e que o conteúdo não é usado para treino. Verificar esse ponto nos termos de cada fornecedor leva minutos e evita a conversa difícil com o jurídico do cliente depois.

Como provar depois que o processo foi limpo?

Prova aqui é registro, e registro é barato quando ele nasce junto com o trabalho em vez de ser reconstruído no fim. Histórico de commits, lista de dependências com licença e resultado de teste contam a história inteira sem ninguém precisar acreditar em palavra. Esse conjunto responde de uma vez às perguntas de auditoria, de due diligence e de cliente desconfiado. Montar isso depois custa dias, e manter isso durante custa nada.

Eu uso o mesmo padrão de evidência que aplico para revisar código de agente, descrito em o que revisar antes de aceitar código gerado. Auditoria de licença entra ali como mais um gate automático, ao lado de teste e verificação de segurança. Quando o gate falha, a construção para e alguém decide, em vez de o problema seguir silencioso até a auditoria.