Não tente resolver um projeto de IA com a frase “todo IP será do cliente”. Separe cada ativo e defina quatro coisas: quem é titular quando a lei reconhece um direito, qual licença cada parte recebe, quais usos são proibidos e qual acesso precisa sobreviver ao término. Em geral, o cliente deve preservar controle sobre seus dados, requisitos e ativos estratégicos; receber direitos amplos sobre entregáveis específicos; e obter licenças suficientes, portabilidade e documentação para componentes preexistentes ou de terceiros.
A resposta depende do país, do tipo de ativo, da contribuição humana, dos contratos com modelos e dados e da cadeia de fornecedores. A WIPO ressalta que questões de IA e propriedade intelectual variam por jurisdição; o U.S. Copyright Office analisa especificamente a copyrightabilidade de outputs. Portanto, use este framework para due diligence e leve o registro final ao jurídico local.
AI Rights & Reuse Proof-8: scorecard de 32 pontos
Pontue cada classe de zero a quatro: zero é não identificada; um, promessa genérica; dois, lista parcial; três, direitos e evidências documentados; quatro, direitos testados com acesso, exportação e cenário de saída. Exija pelo menos 24 de 32, nenhum zero e aprovação dos cinco filtros eliminatórios.
- Ativos preexistentes — métodos, bibliotecas, templates e know-how que cada parte já possuía.
- Entregáveis criados — código, interfaces, schemas, automações, documentação e infraestrutura desenvolvidos para o projeto.
- Dados e materiais de origem — dados do cliente, dados licenciados, conteúdo, rótulos, embeddings e conjuntos derivados.
- Modelos e componentes de terceiros — modelos-base, APIs, open source, conectores, plugins e suas licenças.
- Prompts e configuração — prompts de sistema, políticas, ferramentas, workflows, memória, parâmetros e guardrails.
- Outputs e contribuição humana — resultados gerados, seleções, edições, aprovações e rastreabilidade da autoria humana.
- Avaliações e sinais operacionais — test sets, rubricas, feedback, logs, traces, incidentes e aprendizado de operação.
- Acesso e saída — repositórios, contas, chaves, formatos, documentação, suporte de transição e direitos após o término.
Crie um registro de direitos antes do SOW
Para cada ativo, registre origem, criador, titular declarado, licença, território, prazo, sublicença, restrições, dados usados, local de armazenamento, responsável, evidência e tratamento de saída. Inclua uma coluna de “direito necessário”: possuir, modificar, operar, treinar, avaliar, auditar, sublicenciar, publicar ou apenas usar internamente. Nem todo ativo precisa ser transferido, mas todo ativo crítico precisa de um direito operacional suficiente.
A referência britânica de IPR é útil porque trata direitos como opções contratuais, não como uma única transferência. Na prática, uma consultoria pode manter seu framework geral sem levar dados, configuração ou solução específica do cliente. O comprador pode não possuir um modelo-base, mas precisa conhecer seus termos, receber a configuração e preservar uma rota de substituição.
Cinco filtros eliminatórios
- O fornecedor não apresenta inventário de componentes e licenças relevantes.
- Dados, prompts, feedback ou outputs podem treinar produtos do fornecedor sem autorização explícita e separada.
- O cliente não recebe acesso aos repositórios, configurações, avaliações e documentação necessários para operar ou migrar.
- Uma licença de terceiro impede o uso comercial, a modificação, a escala ou a região pretendida.
- O fornecedor promete exclusividade ou copyright sobre outputs sem qualificar dependência de lei, contribuição humana e termos do modelo.
Dados do cliente não são o mesmo que dados derivados
Defina separadamente dados brutos, dados corrigidos, rótulos, embeddings, índices, features, feedback e logs. Determine quem pode gerar cada derivado, para qual finalidade, por quanto tempo e se ele pode ser agregado com outros clientes. Proíba reidentificação e usos incompatíveis. Especifique exclusão, devolução e comprovação ao término, além das obrigações de privacidade aplicáveis.
Prompts e avaliações podem ser mais estratégicos que o código
Em sistemas com modelos gerenciados, o diferencial pode estar em instruções, ferramentas, políticas, conjuntos de teste, critérios de aceitação e dados de feedback. Se esses ativos ficarem apenas na conta do fornecedor, a empresa pode “possuir o código” e ainda assim não conseguir operar. Exija versionamento, exportação, documentação e licença para modificar e reutilizar no contexto contratado.
Trate componentes de terceiros como cadeia de fornecimento
O NIST SSDF recomenda práticas de desenvolvimento seguro e gestão da cadeia de fornecimento. Peça um inventário que conecte componente, versão, origem, licença, dados enviados, região, subcontratado, atualização e plano de substituição. Defina quem monitora mudanças de termos e quem arca com retrabalho quando uma dependência deixa de ser utilizável.
Outputs exigem uma política de uso, não uma promessa absoluta
Defina usos permitidos, revisão humana, marcas e conteúdos proibidos, retenção de evidências, reclamações de terceiros e responsabilidade por materiais fornecidos por cada parte. Nos Estados Unidos, o Copyright Office distingue contribuição humana de material puramente gerado. Em outros mercados, a análise pode ser diferente. O contrato deve evitar prometer proteção que a lei talvez não conceda.
Converta o registro em critérios de aceitação
- Antes do primeiro pagamento: inventário de ativos preexistentes e terceiros.
- Antes da validação: termos de dados, modelos, prompts, avaliações e feedback.
- Antes da produção: repositórios, contas, documentação, licenças e processo de incidentes.
- Antes do aceite final: exportação testada, lista de dependências, materiais de operação e certificado de exclusão quando aplicável.
- Na saída: continuidade, transferência, assistência, revogação de acessos e direitos que permanecem vigentes.
As cláusulas-modelo europeias de IA são úteis para obrigações específicas do sistema, mas a própria referência alerta que IP, aceitação, pagamento e responsabilidade precisam ser tratados no acordo principal. Não confunda conformidade de IA com direitos suficientes para operar o produto.
Conecte direitos, contrato, avaliação e saída
Use https://makinai.co/insights/pt/o-que-incluir-contrato-sow-servicos-ia para o acordo principal, https://makinai.co/insights/pt/como-escolher-empresa-avaliacao-testes-ia para proteger avaliações e https://makinai.co/insights/pt/como-evitar-lock-in-contratar-parceiro-ia para testar portabilidade. Conheça https://makinai.co/services/pt/consultoria-estrategia-ia-transformacao.
Quando envolver a MAKINAI
A MAKINAI pode mapear ativos, dependências e necessidades operacionais antes da negociação, transformar o registro em requisitos de proposta e testar se os direitos comprados permitem operar, avaliar e migrar. A redação jurídica final deve ser validada por advogados nas jurisdições aplicáveis.