Você fecha um sistema de gestão para um cliente, entrega em três semanas em vez de três meses porque usou Codex, Cursor ou Copilot no processo, recebe e segue a vida. Seis meses depois chega um e-mail: o cliente quer registrar o software no nome da empresa dele e o advogado pediu uma declaração de autoria. Ou pior — alguém rodou uma auditoria de licenças e encontrou uma biblioteca copyleft no meio do projeto. Agora existe uma pergunta na mesa que ninguém fez no começo: afinal, de quem é esse código?
Este texto responde essa pergunta sob três ângulos que se confundem o tempo todo: o que a lei brasileira diz sobre autoria de obra gerada por máquina, o que os termos de uso das ferramentas de IA realmente garantem, e o risco silencioso das bibliotecas de terceiros que a IA instala sem te avisar. No fim, o que colocar no contrato para não descobrir isso do jeito caro. Não é aconselhamento jurídico — é o mapa do que discutir com um advogado antes da próxima entrega.
O que a lei brasileira diz sobre código gerado por IA
No Brasil, software é protegido pela Lei 9.609/98 (Lei do Software), que aplica ao código o mesmo regime da Lei 9.610/98 (Direitos Autorais). E os dois textos partem do mesmo pressuposto: autor é pessoa física. Direito autoral nasce da criação intelectual humana.
Isso gera uma consequência prática desconfortável: um trecho de código gerado inteiramente por uma IA, sem interferência criativa humana relevante, provavelmente não tem autor no sentido legal. Não é que a OpenAI seja dona, nem que você seja dono automático. É que aquele pedaço pode simplesmente não ter proteção autoral — o que significa que, em tese, qualquer pessoa poderia copiar sem violar nada.
Não existe, até agora, decisão consolidada do judiciário brasileiro definindo isso com clareza para software. Nos Estados Unidos, o escritório de direitos autorais já negou registro a obras puramente geradas por IA, e sinalizou que material com contribuição humana significativa pode ser registrado na parte humana. A tendência internacional aponta na mesma direção, mas quem te disser que "a lei já resolveu isso" está vendendo certeza que não existe.
O que isso muda na prática para você
Menos do que parece, e por um motivo simples: a maior parte das brigas de propriedade de código não é resolvida pela lei autoral, e sim pelo contrato. Se seu contrato diz que o cliente recebe todos os direitos patrimoniais sobre o sistema entregue, você e ele estão alinhados independentemente de o código ter nascido do seu dedo ou do Cursor. O problema aparece quando o contrato é omisso — aí sobra interpretação, e interpretação em conflito custa advogado.
Antes de olhar a lei, olhe o contrato que você já assinou ao clicar em "aceito" na ferramenta. É ali que está a resposta comercial imediata.
A boa notícia: as principais ferramentas de vibe coding — programar descrevendo o que você quer em linguagem natural, deixando a IA escrever o código — adotaram uma postura parecida nos termos. OpenAI (Codex, ChatGPT), Anthropic, GitHub (Copilot), Cursor e concorrentes majoritariamente afirmam que a saída gerada é do usuário, sem reivindicar propriedade sobre o resultado.
Mas há detalhes que mudam o jogo:
- Plano gratuito costuma treinar com seus dados. Em várias ferramentas, o plano grátis ou pessoal permite usar suas conversas e seu código para melhorar o modelo. Planos pagos de time e empresa normalmente desligam isso. Se você está mexendo em código proprietário de cliente, isso não é detalhe.
- "Você é dono da saída" não é "a saída é original". Os termos passam a você o que a empresa tem para passar. Eles não garantem que o modelo não reproduziu trecho de código de terceiro protegido.
- Indenização existe, mas com condições. Algumas ferramentas empresariais oferecem proteção contra reclamação de direito autoral por código gerado — geralmente só nos planos corporativos, e só se você mantiver filtros ativos (o Copilot, por exemplo, tem um filtro de código público que precisa estar ligado).
Regra prática: leia a seção de propriedade intelectual e a de dados do plano que você realmente contratou, não a página de marketing. E salve um PDF da versão vigente na data do projeto — termos mudam.
O risco que quase ninguém olha: as bibliotecas que a IA puxou sozinha
Este é o ponto mais subestimado, e é onde mora o prejuízo real.
Quando você pede "faça um sistema de agendamento com relatórios em PDF", a IA não escreve tudo do zero. Ela instala bibliotecas — pacotes de código prontos feitos por terceiros. Podem ser dezenas, e cada uma tem uma licença de software: o documento que diz o que você pode e não pode fazer com aquele código.
A maioria é inofensiva. Algumas não são.
| Licença | Traduzindo | Risco para entrega comercial |
|---|
| MIT, Apache 2.0, BSD | Use como quiser, inclusive comercialmente. Só mantenha o aviso de crédito. | Baixo |
| GPL, AGPL | "Copyleft": se você distribui software que usa isso, precisa liberar o seu código-fonte sob a mesma licença. A AGPL estende isso até para sistema acessado pela web. | Alto — pode obrigar você a abrir o código do cliente |
| LGPL | Meio-termo. Uso como biblioteca separada costuma ser aceitável; embutir no código, não. | Médio, depende de como foi usado |
| Sem licença declarada | Sem permissão expressa, o padrão é "todos os direitos reservados". | Alto e frequentemente ignorado |
O cenário que dá dor de cabeça: você entrega um sistema de gestão para uma empresa, ela cresce, alguém faz auditoria de licenças e descobre uma dependência AGPL no meio. A leitura literal da licença pode obrigar a abrir o código-fonte do sistema todo. O cliente vira para você — e o contrato que vocês assinaram é quem decide quem paga a conta.
Some a isso o risco de a própria IA reproduzir trechos memorizados de projetos públicos. É pouco provável em código comum, mas cresce em código incomum e específico. Existem filtros para isso nas ferramentas, e vale mantê-los ligados.
Como verificar sem ser programador
Você não precisa ler licença por licença. Peça para a própria IA levantar o inventário: "liste todas as dependências deste projeto com a respectiva licença e sinalize qualquer licença copyleft (GPL, AGPL, LGPL) ou sem licença declarada". Depois confirme com uma ferramenta de verificação automática de licenças, porque a IA erra nesse levantamento com alguma frequência. Faça isso antes da entrega, não depois da reclamação.
As sete cláusulas que precisam estar no seu contrato
Se você entrega para cliente, o contrato é o seu escudo. Estas são as cláusulas que fazem diferença quando o assunto é código gerado por IA. Um advogado precisa redigir a versão final — o que vem abaixo é o que você deve pedir a ele.
- Cessão de direitos patrimoniais. Diga exatamente o que o cliente recebe: cessão total e definitiva, ou licença de uso. E diga quando: normalmente na quitação integral, não na entrega. Isso te protege de calote.
- Transparência sobre uso de IA. Uma linha declarando que ferramentas de IA foram usadas no desenvolvimento, com ciência do cliente. Esconder isso é o pior cenário possível — se aparecer depois, vira alegação de vício de consentimento.
- Ressalva sobre componentes de terceiros. Deixe claro que o sistema incorpora bibliotecas open source de terceiros, que essas partes seguem suas próprias licenças e não são objeto da cessão. Anexe a lista.
- Limite da garantia de originalidade. Você garante que não copiou conscientemente código de terceiros. Você não garante que cada linha gerada por IA é inédita — ninguém consegue garantir isso hoje.
- Limitação de responsabilidade. Teto para indenização, normalmente vinculado ao valor do contrato. Sem isso, um projeto pequeno pode gerar exposição ilimitada.
- Confidencialidade em duas vias. Se você vai colar código ou dados do cliente numa ferramenta de IA, precisa de autorização expressa. E precisa dizer qual plano usa e se ele treina com os dados.
- Reuso de componentes genéricos. Se você reaproveita seu próprio boilerplate entre clientes, registre isso. Sem essa cláusula, uma cessão ampla pode te impedir de usar seu próprio padrão de trabalho no próximo projeto.
LGPD: a parte que a discussão de autoria costuma esconder
Propriedade do código é um problema. Dado pessoal é outro, e no Brasil ele tem multa própria.
Se durante o desenvolvimento você cola no chat da IA uma base de clientes, um export de banco com CPF, ou um log com dados de usuários reais, você fez transferência de dados pessoais para um operador — normalmente fora do país. Isso exige base legal, exige que o cliente saiba e, dependendo do caso, exige previsão contratual específica.
Prática segura e barata: use dados fictícios em desenvolvimento, sempre. Não é só conformidade — é higiene básica que também evita vazar credencial de produção num prompt.
Um checklist honesto antes de entregar
Nada disso significa que você deve parar de usar IA para programar. Significa que a entrega tem um passo a mais que a maioria pula.
- Contrato com cláusula de cessão, ressalva de terceiros e limitação de responsabilidade assinado antes do início.
- Plano da ferramenta de IA verificado quanto a treinamento com seus dados; filtro de código público ligado.
- Inventário de dependências com licenças gerado e revisado; nada de GPL/AGPL sem decisão consciente.
- Arquivo de licenças de terceiros entregue junto com o código.
- Nenhum dado pessoal real usado em prompt durante o desenvolvimento.
- Revisão humana do código antes da entrega — inclusive porque IA gera falha de segurança com naturalidade.
O custo disso é algumas horas por projeto e, uma vez, um advogado para montar o modelo de contrato. Comparado ao custo de uma disputa sobre quem é dono de um sistema em produção, é barato.
Entregar sistema feito com IA sem contrato bem amarrado é onde o freelancer perde dinheiro. Na mentoria da WEEBs a gente revisa seu processo de entrega, o inventário de licenças e o que falta no seu contrato antes de virar problema com cliente. Se quiser, dá para conversar sobre seu projeto com a gente e entender onde está o risco.