Proteger propriedade intelectual com IA: know-how fora de modelos

Para proteger propriedade intelectual com IA, defina primeiro qual conhecimento pode sair do seu controle e faça valer essa decisão com contratos, arquitetura e permissões, não apenas com comunicados de política interna. Mantenha segredos de negócio, playbooks e conhecimento de clientes em sistemas que são seus, deixe que os agentes os consultem só no momento da tarefa e confirme por escrito que nenhum fornecedor treina com eles nem os retém. O resto é rotina de operação: revisar acessos, registrar o que o agente toca e ensaiar como você revogaria esse acesso.

Principais pontos

• A maioria dos vazamentos nasce da conveniência, como documentos colados em ferramentas, conectores amplos demais e configurações padrão que ninguém leu, e não de ataques.
• Classifique seu conhecimento em níveis de proteção antes de escolher ferramentas, para que o material mais sensível nunca chegue a um modelo compartilhado.
• Consultar um repositório que você controla é mais fácil de governar e de apagar do que treinar um modelo com seus documentos.
• As condições do fornecedor sobre treinamento, retenção, subprocessadores e exclusão precisam estar por escrito e ser revisadas, não presumidas.
• Permissões restritas, registros de atividade e uma revisão recorrente mantêm o alcance do agente compatível com a função dele.

Onde o know-how da empresa realmente vaza?

Vazamentos raramente parecem roubo. Parecem conveniência. Um funcionário cola a proposta de um cliente em uma ferramenta pública de chat para melhorar o texto. Uma equipe conecta um assistente de anotações a todas as reuniões. Uma configuração padrão do fornecedor guarda o histórico de conversas por mais tempo do que alguém leu nos termos. Nada disso é malicioso, e cada caso tira conhecimento do seu controle.

Quatro caminhos merecem ser mapeados primeiro:

• Prompts e uploads: a equipe cola documentos em ferramentas que a empresa não aprovou nem configurou.
• Retenção e treinamento pelo fornecedor: um provedor armazena as entradas, ou as usa para melhorar seus modelos, sob termos que ninguém revisou.
• Conectores: um agente é ligado a um drive, CRM ou wiki com acesso muito mais amplo do que a função exige.
• Saídas: respostas, rascunhos e resumos levam material confidencial a pessoas ou canais que não deveriam vê-lo.

O OWASP Top 10 para aplicações com LLMs cita a divulgação de informações sensíveis como um dos riscos recorrentes nesse tipo de sistema, o que combina com o que times de operações observam na prática. Para a visão estratégica mais ampla, veja como proteger o que sua empresa sabe diante de agentes de IA cada vez mais capazes.

Qual conhecimento merece qual nível de proteção?

Uma regra única para toda a informação da empresa falha em duas direções. Ou bloqueia trabalho útil com material inofensivo, ou deixa o material sensível circular com a mesma liberdade de um comunicado de imprensa. Uma classificação curta dá a você uma regra por nível.

Use este guia de decisão para cada conjunto de conhecimento, como um modelo de precificação, um playbook de entrega ou a pasta de um cliente:

• Material público ou de marketing: pode ser usado com ferramentas compartilhadas aprovadas.
• Interno, de baixa sensibilidade (atas de reunião, documentos gerais de processo): somente ferramentas aprovadas, com confirmação de que não há treinamento com seus dados e de que a retenção é limitada.
• Confidencial de cliente: somente em ambientes cobertos por confidencialidade contratual, com acesso restrito à equipe do cliente e respostas obtidas por consulta (retrieval).
• Know-how essencial (lógica de preços, métodos, fórmulas, código-fonte, estratégia não lançada): permanece em sistemas que você controla, e o agente vê apenas trechos estreitos, no nível da tarefa, ou nada.

Para posicionar um item, faça três perguntas. Um concorrente ganharia vantagem com isso? Devemos dever de confidencialidade a um cliente ou parceiro? Se isso se espalhasse, seria possível recolher de volta? Duas respostas positivas normalmente indicam o nível mais alto.

A classificação também ajuda na proteção do segredo de negócio em si. A proteção jurídica de segredos de negócio geralmente depende de a empresa tomar medidas razoáveis para mantê-los em sigilo, então uma classificação documentada e aplicada serve como evidência útil. Pergunte ao seu advogado como isso se aplica na sua jurisdição.

Por que a consulta protege o know-how melhor do que o treinamento?

Há duas formas amplas de fazer um sistema de IA conhecer o seu negócio. Você pode treinar ou ajustar (fine-tuning) um modelo com seus documentos, o que incorpora padrões ao próprio modelo. Ou pode manter os documentos em um repositório seu e deixar o agente consultar os trechos relevantes a cada tarefa. A orientação prescritiva da AWS compara essas opções, e a diferença de governança é clara.

Com a consulta, o conhecimento fica em um lugar que você possui, com regras de acesso próprias. Você pode remover um documento e ele deixa de estar disponível. Pode restringir um trecho a uma única equipe. Pode ver quais trechos foram buscados para cada resposta.

Com o treinamento, o conhecimento passa a fazer parte dos pesos do modelo. Remover um documento depois é difícil, as regras de acesso não o acompanham e, se o modelo está com um fornecedor, você colocou seu material mais valioso em um sistema que talvez não consiga inspecionar nem retirar por completo.

A consulta não é segura automaticamente. Os trechos recuperados ainda são enviados ao modelo no momento da tarefa, então os termos do provedor sobre retenção e treinamento continuam importando. Por isso arquitetura e contratos trabalham juntos. Ajuda ter um mapa de uma página mostrando onde cada peça vive; o artigo sobre as camadas da infraestrutura de IA empresarial mostra como desenhá-lo.

O que o contrato com o fornecedor deve dizer sobre seus dados?

Páginas de marketing não são contratos. Antes de qualquer ferramenta tocar material de cliente ou conhecimento essencial, obtenha respostas por escrito para uma lista curta, do fornecedor ou do próprio contrato.

• O conteúdo do cliente é usado para treinar ou melhorar modelos, por padrão ou por uma configuração que alguém possa alterar?
• Por quanto tempo entradas, saídas e logs são retidos, e quem no fornecedor pode lê-los, incluindo a equipe de suporte?
• Onde os dados são processados e armazenados, e quais subprocessadores estão envolvidos?
• Você consegue exportar e apagar tudo, incluindo índices e embeddings criados a partir dos seus documentos, e receber confirmação da exclusão?
• O que acontece com seus dados e configurações quando o contrato termina?
• Quais são os deveres do fornecedor de avisar você sobre um incidente, e em que prazo?
• A equipe usa contas pessoais além da conta da empresa, e é possível impor o uso da conta corporativa?

As condições de saída importam tanto quanto as de entrada. Se seus playbooks vivem em um formato que só um fornecedor consegue ler, proteção e dependência viram o mesmo problema. Leia como migrar agentes de IA para outro fornecedor antes de assinar.

Como permissões e logs limitam o que um agente pode expor?

Mesmo um agente bem contratado pode vazar se alcançar tudo. O princípio é antigo e sólido: dê a cada agente o menor acesso que a função exige, negue por padrão e verifique a autorização em cada requisição. O OWASP Authorization Cheat Sheet descreve essas ideias, e elas se aplicam diretamente aos agentes e às ferramentas que eles chamam.

Na prática:

• Dê ao agente uma identidade própria, separada de qualquer funcionário, para que o acesso possa ser alterado ou removido sem efeitos colaterais.
• Comece com acesso somente de leitura e acrescente capacidades de escrita ou envio uma a uma, cada uma com um responsável.
• Limite os conectores a pastas específicas, registros de clientes ou espaços de wiki, não a sistemas inteiros.
• Exija aprovação humana antes de o agente enviar qualquer coisa para fora da empresa ou compartilhar material entre clientes diferentes.
• Registre quais fontes o agente consultou e quais ações executou, para que uma dúvida sobre uma resposta possa ser rastreada.

A injeção de prompt merece menção. Um documento ou página da web que o agente lê pode conter instruções que tentam fazê-lo revelar ou encaminhar outro material. Permissões estreitas limitam o dano, porque um agente que não alcança o playbook não pode ser induzido a enviá-lo. O acesso também se desvia com o tempo, então agende uma verificação recorrente. Os passos estão em donos, permissões e rotas quando a empresa muda e usa agentes de IA.

Um cenário ilustrativo: o playbook de um cliente e um prestador externo

Este é um cenário ilustrativo, não um caso real. Uma pequena consultoria tem um playbook de onboarding de clientes que levou anos para ser refinado. Ela quer que um agente rascunhe planos de onboarding e contrata um prestador externo por algumas semanas para ajudar na configuração.

A consultoria faz o seguinte:

• Move o playbook para um repositório da própria empresa, com seções separadas para método, modelos e anotações específicas de cada cliente.
• Classifica o método como know-how essencial, de modo que o agente consulta apenas a etapa relevante para a tarefa em curso e nunca o documento inteiro.
• Limita o acesso de leitura do agente à pasta do cliente ativo, para que as anotações de um cliente não apareçam no plano de outro.
• Dá ao prestador um acesso com data de término fixa, seguindo os cuidados de contratar um freelancer para criar um agente de IA, e o remove na entrega.
• Revisa o registro de consultas todo mês e confirma que nada fora das pastas previstas foi lido.

Nada disso depende de uma ferramenta engenhosa. Depende de saber o que é valioso, onde isso está e quem, ou o quê, pode lê-lo.

Como uma abordagem gerenciada trata isso?

A Be Human projeta, implanta e opera agentes cuja identidade, memória, canais, ferramentas e permissões permanecem sob o controle da empresa. Um primeiro projeto define uma função útil, a memória e as ferramentas de que ela precisa, os limites de aprovação e um critério de sucesso observável. O know-how fica em repositórios que a empresa controla e é acessado por consulta, com acesso restrito à função. A operação gerenciada pode incluir monitoramento, revisão de permissões, manutenção de integrações, resposta a incidentes e melhorias controladas, de modo que a proteção continue depois do lançamento em vez de acabar na configuração. O NIST AI Risk Management Framework é uma boa referência para o lado de governança desse trabalho.

Faça o diagnóstico de IA gratuito da Be Human para encontrar a primeira tarefa que vale entregar a um agente.

Perguntas frequentes

Usar uma ferramenta de IA coloca automaticamente nossos segredos de negócio em risco? Não. O risco depende do que você envia, do que os termos do fornecedor permitem e de quem tem acesso à ferramenta. Ferramentas aprovadas, com termos confirmados de não treinamento e retenção limitada, combinadas com uma classificação que mantém o material essencial de fora, podem ser usadas com confiança razoável.

Ajustar (fine-tuning) um modelo com nossos documentos é uma forma segura de ensinar nosso negócio a ele? Pode ser adequado para alguns materiais, mas é mais difícil de governar do que a consulta. O conhecimento nos pesos do modelo é difícil de remover e não carrega regras de acesso. Para conteúdo sensível ou específico de clientes, consultar um repositório que você controla costuma ser a escolha mais fácil de defender.

Devemos proibir de vez as ferramentas públicas de IA? Uma proibição sem alternativa aprovada tende a empurrar o uso para fora das vistas. Uma abordagem melhor é oferecer uma ferramenta aprovada, dizer quais níveis de classificação ela pode tratar e explicar por que o restante fica de fora. As pessoas seguem regras que ainda permitem fazer o trabalho.

Quem dentro da empresa deve ser o dono dessa decisão? Designe um executivo nomeado, de preferência quem responde por risco ou operações, para cuidar da classificação e dos termos com fornecedores, com o jurídico revisando os contratos. Sem um único responsável, cada área decide sozinha e as falhas aparecem entre elas. Esse papel funciona como o de patrocinador executivo de um projeto de IA.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.