IP, dados e código: checklist decisório para preparar produtos AR/VR e IA para due diligence

Dados são um dos pontos mais sensíveis da due diligence de inteligência artificial. A pergunta não é apenas se a equipe consegue acessar a base, mas se a empresa tem autorização para coletá-la, armazená-la, transformá-la, usá-la em treinamento, gerar derivados e transferi-la em uma operação societária.

Monte um catálogo de dados com origem, finalidade, responsável, formato, período de retenção, localização, classificação de sensibilidade, base legal aplicável e dependências contratuais. Registre também as transformações: anonimização, limpeza, rotulagem, enriquecimento, criação de dados sintéticos e geração de atributos.

Em produtos de AR/VR, imagens, vídeos, voz, movimentos corporais e mapas espaciais podem conter dados pessoais ou informações proprietárias do cliente. O catálogo deve indicar se a captura ocorreu em ambiente controlado, se houve consentimento, se os usuários foram informados e se o material pode ser usado para melhorar o produto.

Em produtos de IA generativa, documente se os dados foram usados para treinar um modelo próprio, ajustar um modelo de terceiros ou apenas alimentar uma consulta. Diferencie código, pesos, configurações, instruções, avaliações e registros de conversa. Eles têm riscos contratuais e operacionais diferentes.

Fornecedores externos devem declarar, por contrato, quem é o titular dos dados enviados, quem controla os resultados, se o fornecedor pode reutilizar entradas e saídas, por quanto tempo conserva os registros e como elimina as cópias. Também é recomendável prever aviso de incidente, auditoria, localização do processamento, subcontratação e cooperação em uma venda ou transferência de controle.

A ANPD apresenta orientações oficiais sobre a LGPD e proteção de dados pessoais, incluindo materiais que ajudam a estruturar responsabilidades e medidas de segurança. A análise jurídica deve considerar o contexto concreto, principalmente em saúde, fintech, educação e governo.

Para modelos, crie um registro por versão contendo conjunto de treinamento, método de preparação, hiperparâmetros relevantes, data de treinamento, métricas, limitações conhecidas, avaliação por grupo de usuário, custo de inferência e procedimento de reversão. Sem esse histórico, o comprador não consegue estimar a reprodutibilidade nem o risco de degradação do modelo.

Um caso prático ajuda a separar os problemas. Se uma empresa usa imagens licenciadas por um hospital para treinar um classificador, o contrato precisa deixar claro se a autorização alcança treinamento, dados derivados, validação, uso comercial e mudança de controlador. Caso contrário, o modelo pode continuar tecnicamente funcional, mas perder parte do valor econômico na negociação.

Compliance não deve ser tratado como uma pasta jurídica separada da engenharia. Em um produto de IA, AR ou VR, a forma como o dado é coletado influencia a arquitetura; a arquitetura influencia o contrato; e o contrato pode limitar o que será transferido ao comprador.

Faça uma matriz por fluxo de dados. Para cada fluxo, registre origem, finalidade, usuários envolvidos, país de processamento, fornecedor, controle de acesso, retenção, mecanismo de eliminação e evidência de autorização. Essa visão é particularmente relevante para empresas que pretendem atender clientes nos Estados Unidos ou na Europa.

Os contratos com fornecedores precisam prever continuidade e saída. Inclua entrega de código e documentação, exportação de dados em formato utilizável, transferência de modelos e pesos quando aplicável, assistência por período de transição, acesso a registros, cooperação em auditorias e proibição de retenção indevida após o encerramento.

O mecanismo de escrow pode ser adequado para determinados componentes críticos, mas não substitui a propriedade ou o acesso operacional. Defina gatilhos objetivos, como insolvência, abandono do serviço, violação grave ou incapacidade de suporte, além do conteúdo depositado e da periodicidade de atualização.

Para equipes terceirizadas, uma cessão genérica de direitos pode ser insuficiente. O contrato deve cobrir entregáveis produzidos durante a execução, materiais derivados, documentação, testes, scripts de implantação, infraestrutura como código e direitos de terceiros incorporados ao produto.

Projetos financiados por FAPESC, FINEP ou BNDES exigem uma reconciliação entre o contrato de fomento e o plano de negócio. Separe despesas elegíveis, entregáveis públicos, propriedade de resultados, obrigações de prestação de contas e restrições de transferência. Um roteiro jurídico para startups deeptech com fomento público ajuda a estruturar essa análise, mas não substitui revisão jurídica do instrumento específico.

Na prática, três falhas aparecem com frequência: fornecedor que pode reutilizar dados do cliente, universidade que mantém direitos sobre um resultado essencial e parceiro de hardware que limita a distribuição internacional. Todas devem ser identificadas antes do contato com investidores, porque a correção durante a exclusividade costuma reduzir poder de negociação.

Nem toda pendência precisa ser eliminada antes de abrir uma rodada. A decisão correta depende da criticidade do ativo, da probabilidade de questionamento, do custo de correção e da possibilidade de proteger o risco por contrato. O erro é tratar todas as tarefas como igualmente urgentes.

Priorize quatro grupos. O primeiro reúne riscos que podem impedir a transferência, como ausência de cessão sobre o código principal ou direito de uso insuficiente sobre o conjunto de dados. O segundo envolve riscos que podem interromper a operação, como dependência de uma conta pessoal, modelo sem substituição ou fornecedor sem obrigação de continuidade.

O terceiro grupo contém riscos que reduzem a escalabilidade ou aumentam o custo futuro, como ambiente impossível de replicar, pipeline manual e falta de monitoramento. O quarto inclui melhorias de apresentação, como reorganizar diagramas ou padronizar nomes, que são úteis, mas não devem competir com uma falha de titularidade.

Uma regra prática é transformar cada risco em impacto de negócio. Em vez de escrever “arquitetura pouco documentada”, registre “uma nova equipe levaria semanas para operar o serviço e não há procedimento testado de recuperação”. Em vez de “dados sem catálogo”, indique “não é possível demonstrar quais registros podem ser usados para treinar o modelo após a mudança de controle”.

Também compare três caminhos: corrigir internamente, contratar uma auditoria independente ou usar um parceiro técnico para corrigir e documentar. A equipe interna conhece o produto, mas pode não ter tempo ou distância para identificar riscos. Uma auditoria aponta lacunas, porém não necessariamente implementa as correções. Um parceiro ponta a ponta pode executar, mas precisa trabalhar com escopo, acesso e critérios de aceite bem definidos.

A OrbeSoft recomenda um diagnóstico técnico antes de propor uma squad de execução. Essa ordem evita vender capacidade sem entender o problema e permite separar dívida técnica, risco de IP, falta de documentação e gargalo de produto. Em projetos de AR/VR e IA, essa distinção costuma ser decisiva para usar o orçamento onde ele reduz mais risco.

A experiência com mais de 300 projetos na América Latina, nos Estados Unidos e na Europa mostra que previsibilidade não vem de produzir mais código a qualquer custo. Ela vem de tornar decisões, dependências, responsabilidades e evidências visíveis para quem vai operar, investir ou comprar o produto.