Contrato de tratamento de dados com fornecedor de IA: o que checar

Um contrato de tratamento de dados com fornecedor de IA deve dizer quais dados pessoais o fornecedor pode tratar, para quais finalidades (e somente elas), onde, por meio de quais suboperadores e o que acontece com esses dados quando o contrato termina. As cláusulas mais importantes para IA são justamente as que os modelos genéricos costumam ignorar: uso para treinamento, retenção de prompts e respostas, logs, memória e eliminação. Leia o contrato como um documento operacional que descreve como seus dados circulam, não como uma formalidade para assinar e arquivar.

Principais pontos

• Confirme primeiro os papéis: sua empresa deve ser a controladora e o fornecedor o operador, sem finalidades próprias escondidas do fornecedor.
• Peça uma declaração por escrito sobre treinamento: seus prompts, arquivos e respostas não devem melhorar modelos de outros clientes, a menos que você aceite expressamente.
• Liste todos os lugares onde o dado pode ficar guardado: prompts, respostas, logs, embeddings, memória do agente e backups, cada um com regra de retenção e caminho de eliminação.
• Obtenha a cadeia completa de suboperadores, incluindo o provedor do modelo, com aviso prévio e direito de objeção quando ela mudar.
• Combine o contrato com evidências: documentação de segurança, deveres em caso de incidente e um plano de saída que devolva ou elimine seus dados.

Por que um fornecedor de IA exige mais do que um contrato padrão?

Em uma ferramenta de software convencional, o dado entra em um formulário e fica em um banco de dados. Em um serviço de IA, o mesmo dado pode passar por uma camada de aplicação, um provedor de modelo, um índice de busca, um repositório de logs e um repositório de memória. Cada camada pode pertencer a uma empresa diferente, e cada uma guarda alguma coisa: uma cópia, uma representação derivada ou um rastro.

Leis de proteção de dados como a LGPD e o GDPR distinguem quem decide por que o dado é tratado (o controlador) de quem o trata em nome dele (o operador, chamado de processor no GDPR). Um bom contrato mantém o fornecedor no papel de operador. O risco aparece quando o fornecedor reserva para si o direito de usar o conteúdo do cliente para melhorar o próprio produto. Nessa finalidade, o fornecedor age por conta própria, e sua empresa concordou com algo que talvez não tenha pretendido.

Se você atua no Brasil, leia este texto junto com LGPD e agentes de IA nas empresas: o que verificar antes de usar, que trata das bases legais e dos deveres que ficam com você como controlador.

Quais cláusulas procurar?

Use esta lista como primeira leitura. Cada item deve ser respondido no texto do contrato, não em uma página de marketing que pode mudar sem aviso.

• Escopo e instruções: o contrato indica as categorias de dados pessoais, as categorias de titulares, a finalidade e a duração, e afirma que o fornecedor trata os dados somente conforme suas instruções documentadas.
• Papéis: diz com clareza que o fornecedor é operador do seu conteúdo e lista qualquer finalidade para a qual ele alega agir de forma independente.
• Treinamento e melhoria: proíbe usar seu conteúdo para treinar, ajustar ou avaliar modelos de outros clientes, ou torna isso uma adesão explícita e opcional.
• Retenção e eliminação: define regras de retenção para prompts, respostas, arquivos, embeddings, logs e memória, e exige eliminação a pedido e no encerramento, com confirmação por escrito.
• Suboperadores: lista todos, incluindo o provedor do modelo e o de hospedagem, exige aviso antes de mudanças e dá a você o direito de objetar.
• Localização e transferências: informa onde os dados ficam armazenados e onde a inferência do modelo é executada, e qual mecanismo de transferência internacional se aplica quando o dado sai do país.
• Medidas de segurança: descreve controles de forma concreta, como controle de acesso, criptografia, separação entre clientes e registro de atividades, em vez de prometer segurança "padrão de mercado".
• Comunicação de incidentes: define um prazo de aviso, as informações que você receberá e o dever de cooperação do fornecedor.
• Apoio às solicitações dos titulares: compromete o fornecedor a ajudar você a responder pedidos de acesso, correção e eliminação.
• Auditoria e evidências: permite que você analise relatórios, envie questionários ou faça auditoria de forma razoável.
• Devolução e saída: descreve como você pode exportar seus dados e em que formato, antes da eliminação.

O que treinamento, retenção e memória mudam?

Esses três temas são onde a IA mais se diferencia de um software comum, por isso merecem atenção própria.

Treinamento. Faça a pergunta de forma direta: algo que enviarmos, ou que o agente produzir, será usado para treinar ou melhorar um modelo que outros clientes utilizam? A resposta deve ser um não claro, ou uma adesão opcional que você controla. Cuidado com expressões como "para melhorar nossos serviços", que podem abranger mais do que você imagina.

Retenção. Os prompts costumam conter mais dados pessoais do que alguém planejou, porque a equipe cola e-mails, contratos e anotações neles. As respostas também podem conter dados pessoais. Provedores de modelo podem guardar as entradas por um período para monitorar abusos, e alguns oferecem um modo sem retenção. Pergunte qual é o padrão, se pessoas podem ler o conteúdo retido e se você pode escolher a opção mais restrita no contrato.

Memória. Um agente que lembra de clientes, preferências e decisões passadas tem um repositório de memória, e esse repositório é dado pessoal da mesma forma que um CRM. Embeddings criados a partir dos seus documentos derivam deles e devem ser tratados como o mesmo dado. A cláusula de eliminação precisa alcançar memória, índices e logs, não apenas o histórico visível da conversa. Um jeito prático de reduzir os três problemas é enviar menos dados desde o início, como explicado em minimização de dados em agentes de IA.

Até onde vai a cadeia de suboperadores?

A maioria dos serviços de IA é montada com peças de terceiros. O fornecedor com quem você assina pode rodar a aplicação em um provedor de nuvem, chamar um modelo de outra empresa, enviar logs a um serviço de monitoramento e usar um provedor separado de e-mail ou mensagens. Seu contrato obriga apenas a primeira empresa. Ele deve garantir também que as mesmas obrigações sejam repassadas ao longo da cadeia.

Peça estes itens por escrito:

• A lista atual de suboperadores, com o serviço que cada um presta e o país em que opera.
• O compromisso de que cada suboperador esteja vinculado a termos que não sejam mais fracos que os seus.
• O prazo de aviso antes de incluir um novo suboperador e o que você pode fazer se objetar.
• Os termos do provedor do modelo sobre retenção, revisão humana e treinamento, aplicados aos seus dados.
• Se é possível escolher uma região ou uma opção sem retenção para a inferência.

Um fornecedor que não consegue descrever sua cadeia em um diagrama simples geralmente não a mapeou. Para uma análise mais ampla do próprio fornecedor, o processo de compras de agentes de IA, com Jurídico, TI e Financeiro ajuda a organizar quem verifica o quê, de forma complementar ao contrato.

O que as cláusulas de segurança, incidente e auditoria devem dizer?

A linguagem de segurança nos contratos costuma ser genérica. Procure detalhes que você possa verificar depois: como o acesso aos seus dados é limitado dentro do fornecedor, como os clientes são separados, como as credenciais são guardadas e quem pode ver seu conteúdo durante o suporte. Pergunte como o fornecedor trata riscos específicos de aplicações com modelos de linguagem, como prompt injection e permissões excessivas do agente. O OWASP Top 10 for LLM Applications é uma boa referência para essa conversa, e o NIST AI Risk Management Framework ajuda a enquadrar as respostas do fornecedor dentro do seu trabalho mais amplo de gestão de riscos.

Sobre incidentes, o contrato deve definir o que conta como um, com que rapidez você será avisado, o que o aviso contém e quem faz o quê em seguida. Um agente que envia o documento errado para a pessoa errada é um tipo de evento diferente de um vazamento em banco de dados, então verifique se respostas enviadas ao destinatário errado e ações não autorizadas do agente estão cobertas pelo dever de comunicação, e não apenas o roubo de dados.

Sobre a saída, exija uma forma de levar seus dados e sua configuração embora, e uma confirmação de eliminação depois. Essa também é a melhor proteção contra a dependência de um único fornecedor.

Como isso fica na prática? Um cenário ilustrativo

Cenário ilustrativo: um pequeno escritório de contabilidade quer um assistente de IA para redigir respostas a e-mails de clientes. O contrato padrão do fornecedor permite o uso do conteúdo do cliente "para melhoria do serviço" e cita o provedor de hospedagem, mas não o provedor do modelo.

O responsável jurídico do escritório faz três perguntas. Melhoria do serviço inclui treinamento de modelo? Qual empresa executa o modelo e por quanto tempo ela guarda as entradas? A eliminação no encerramento cobre a memória do assistente sobre os dados dos clientes? O fornecedor responde que o treinamento é excluído para contas empresariais, informa o provedor do modelo e oferece uma configuração sem retenção, e concorda em incluir memória e logs na cláusula de eliminação. O escritório acrescenta uma regra interna curta: CPF e CNPJ de clientes nunca são colados em prompts. Nada disso exigiu uma ferramenta nova. Exigiu ler o contrato à luz do fluxo real de dados.

Perguntas para levar à revisão jurídica

Entregue esta lista ao seu advogado ou encarregado de dados, junto com uma descrição de uma página do fluxo de trabalho: o que o agente faz, quais dados ele vê e quem aprova suas ações.

• Somos controladores e o fornecedor é operador em todas as finalidades? Onde o texto diz o contrário?
• Alguma cláusula permite que o fornecedor ou seus provedores usem nosso conteúdo para treinamento, avaliação ou análises de produto?
• Quais tipos de dados são retidos, por quanto tempo, e podemos reduzir ou desativar a retenção?
• A obrigação de eliminação alcança logs, embeddings, backups e memória do agente, e como ela é confirmada?
• O provedor do modelo consta como suboperador, e os termos dele são repassados?
• Onde os dados são armazenados e onde são tratados, e qual mecanismo de transferência internacional se aplica?
• Como seremos avisados de incidentes, inclusive respostas erradas e ações não autorizadas do agente?
• O que acontece com nossos dados e nossa configuração se rescindirmos, e em que formato podemos exportá-los?
• Como a cláusula de responsabilidade trata uma violação causada por um suboperador?
• A regulação do nosso setor, ou do nosso caso de uso, acrescenta deveres que o modelo de contrato não cobre? Para o ângulo europeu, veja se o AI Act europeu se aplica à sua empresa e aos agentes de IA.

Como uma operação gerenciada lida com isso?

A Be Human trata o contrato como uma das entradas do desenho da solução, não como uma etapa jurídica separada. No início do projeto, ficam registrados o papel do agente, as categorias de dados que ele vai tocar, as ferramentas às quais ele se conecta e os limites de aprovação, o que dá ao seu revisor jurídico uma descrição concreta do tratamento. Durante a operação gerenciada, as revisões de permissões e a manutenção das integrações incluem conferir se o que o agente alcança continua igual ao que foi combinado, e mudanças de suboperador ou de provedor são levadas ao seu conhecimento para análise. A avaliação jurídica em si continua com o seu advogado.

Perguntas frequentes

Precisamos de um contrato de tratamento de dados se enviamos poucos dados pessoais? Sim. Se o fornecedor trata dados pessoais em seu nome, o volume não elimina a necessidade. Volumes pequenos também geram obrigações, e o contrato é o que permite cobrar do fornecedor os limites de retenção e de treinamento. Reduzir o que você envia é um bom complemento, não um substituto.

Podemos aceitar o contrato padrão do fornecedor como está? Muitas vezes sim, se ele responder às cláusulas acima em texto claro. Leia primeiro e negocie apenas as lacunas que importam, normalmente uso para treinamento, retenção, cadeia de suboperadores e alcance da eliminação. Um fornecedor que se recusa a esclarecer qualquer um desses pontos já lhe disse algo útil.

Quem responde se o provedor de modelo do fornecedor sofrer uma violação? Seu contrato é com o fornecedor, então ele deve responder por seus suboperadores e exigir que eles avisem você. Como controlador, você ainda pode ter deveres próprios perante a autoridade e os titulares afetados. Pergunte ao seu advogado como responsabilidade e comunicação se encaixam antes de assinar.

Com que frequência devemos revisar o contrato depois de assinado? Revise quando o fluxo de trabalho mudar, quando o fornecedor anunciar um novo suboperador ou provedor, e em um ciclo regular, como uma verificação anual. Registre a revisão no seu registro de riscos de IA, para que mudanças em dados, ferramentas ou permissões levem a uma nova leitura do contrato.

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