Propriedade intelectual em projetos de IA: de quem são os agentes?

Quando uma empresa contrata a construção de agentes de IA, surge uma pergunta que muitos contratos não respondem: de quem é o que foi construído? A dúvida sobre propriedade intelectual em IA no contrato parece jurídica, mas é estratégica. Ela define se a empresa terá autonomia ou dependência daqui a dois anos.

Este artigo organiza o tema para quem decide. Ele não substitui a análise do jurídico, mas ajuda a fazer as perguntas certas antes de assinar.

O que compõe um agente de IA, do ponto de vista da propriedade?

Um agente de IA não é uma peça única. É a combinação de cinco elementos, cada um com uma lógica de propriedade diferente.

O modelo de linguagem em si, fornecido pelas provedoras de IA, normalmente não é de ninguém do projeto. A empresa e o fornecedor apenas usam o modelo, sob os termos do provedor.

Código: o que é sob medida e o que é componente

Todo fornecedor sério reaproveita componentes: conectores, bibliotecas, estruturas de monitoramento. Isso é bom para o cliente, porque acelera e reduz custo. Mas precisa estar claro no contrato.

Uma divisão comum e justa:

• Código desenvolvido exclusivamente para a empresa: fica com a empresa ou é licenciado de forma ampla e permanente.
• Componentes reutilizáveis do fornecedor: continuam do fornecedor, com licença de uso para a empresa enquanto o serviço existir, ou permanente.

O ponto crítico é o que acontece no fim do contrato. Se a empresa não pode usar os componentes depois, o código sob medida pode deixar de funcionar.

Instruções e regras: o conhecimento do negócio em forma de instruções

Instruções e regras parecem detalhe técnico, mas guardam algo valioso: como a empresa quer que o trabalho seja feito. Critérios de aprovação, tom de atendimento, limites de desconto, ordem de verificação.

Esse conteúdo nasce do conhecimento da empresa. Por isso, o razoável é que a empresa tenha direito de usá-lo e levá-lo consigo. O contrato deve prever a entrega documentada dessas instruções.

Base de conhecimento e dados: sempre da empresa

Documentos, políticas, cadastros e históricos são da empresa antes, durante e depois do projeto. Isso é ponto pacífico. O que precisa estar escrito é o uso que o fornecedor pode fazer deles.

Três cláusulas fazem diferença:

1. Os dados só podem ser usados para prestar o serviço contratado.
2. Os dados não podem ser usados para treinar modelos ou produtos que atendam outros clientes, salvo autorização expressa.
3. No fim do contrato, os dados são devolvidos em formato utilizável e apagados dos ambientes do fornecedor, com confirmação.

Esses pontos se conectam às obrigações de proteção de dados, tratadas em LGPD e segurança em projetos de IA.

Saídas: de quem é o que o agente produz?

Em geral, as saídas geradas para a empresa, como respostas, relatórios e documentos, ficam com a empresa. Mas vale conferir os termos do provedor do modelo usado, que podem trazer condições próprias.

Outra questão é a responsabilidade. Se uma saída tiver erro, quem responde? O mais comum é que a empresa continue responsável pelo que publica ou envia, e por isso mantém a revisão humana nos pontos críticos. O contrato deve deixar claros os limites de responsabilidade do fornecedor.

O que colocar sobre propriedade intelectual no contrato de IA?

Uma lista prática para levar à conversa com o jurídico e com o fornecedor:

1. Definição de cada elemento: código sob medida, componentes, instruções, base de conhecimento, dados e saídas.
2. Titularidade ou licença de cada elemento, durante e depois do contrato.
3. Restrições de uso dos dados pelo fornecedor, incluindo treinamento de modelos.
4. Plano de saída: o que é entregue, em que formato e em que prazo.
5. Documentação mínima: arquitetura, integrações, instruções e regras, testes.
6. Modelos e provedores usados, e como mudanças serão comunicadas.
7. Responsabilidades em caso de erro, incidente ou vazamento.

Nem todos esses itens precisam ser longos. O que importa é que estejam escritos. Contratos de software tradicionais costumam cobrir código e dados, mas esquecem instruções, base de conhecimento e plano de saída, que são justamente o que diferencia um projeto de IA.

Como evitar dependência do fornecedor?

Dependência não vem só de cláusula. Vem da falta de conhecimento interno. Uma empresa que não sabe como seus agentes funcionam depende do fornecedor mesmo que seja dona do código.

Algumas práticas reduzem esse risco:

• Ter um responsável interno que acompanha cada agente e entende sua lógica.
• Exigir documentação atualizada a cada mudança relevante.
• Manter a base de conhecimento em ambiente controlado pela empresa.
• Testar, uma vez, o plano de saída: pedir a exportação e conferir se está utilizável.

Dependência total é ruim. Independência total também tem custo. O objetivo é escolher conscientemente o nível de dependência que faz sentido para cada agente.

A decisão é estratégica, não só jurídica

Agentes de IA vão carregar cada vez mais conhecimento operacional da empresa. Decidir de quem eles são é decidir quem controla esse conhecimento.

Leve o tema para a mesa antes de escolher o fornecedor, não depois. Na Horia, a regra é deixar claro desde a proposta o que é da empresa, o que é componente reutilizável e como funciona a saída.