Em 2025, a Comunidade de Compradores Públicos da Comissão Europeia publicou um conjunto de cláusulas-modelo para a compra pública de sistemas de IA — o MCC-AI, com uma versão completa para sistemas de alto risco e uma versão simplificada para os demais, ambas alinhadas às obrigações do Regulamento de IA da União Europeia. A iniciativa não nasceu de burocracia: nasceu porque nenhum comprador público queria mais assinar um contrato de IA apoiado só na palavra do fornecedor.
O motivo aparece nas pesquisas de gestão de risco de terceiros. Segundo a Ncontracts, em levantamento de 2026 com instituições financeiras dos Estados Unidos, 72% delas sabem apenas parcialmente quais de seus fornecedores usam IA, e 16% nunca avaliaram isso. Nenhuma organização respondeu se sentir "extremamente confiante" para gerir esse risco.
Isso importa para quem assina o contrato, não só para quem opera o sistema depois. Uma cláusula vaga hoje é uma obrigação que ninguém consegue cobrar amanhã — na auditoria, numa investigação de incidente ou na hora de renovar.
O que falta na maioria dos contratos de IA
Escritórios especializados em contratos de tecnologia documentam um padrão parecido em quem compra IA: a cláusula de segurança do fornecedor tende a repetir a mesma linguagem genérica — "segurança de ponta", "conformidade total" — sem nomear um controle que se possa verificar depois. Um guia de cláusulas para contratos de fornecedores de IA, do escritório Gouchev Law, lista pontos que costumam faltar: definição clara de uso de dado para treino, propriedade do resultado gerado, revisão humana obrigatória conforme o risco e indenização que cubra reivindicação sobre o dado usado no treinamento — não só sobre o software em si.
O ponto mais frequentemente ausente é a própria definição de dado do cliente. Um contrato bem redigido, segundo análise do escritório Tish Law sobre cláusulas de fornecedores de IA, precisa tratar como confidencial não só o documento enviado, mas também o comando digitado, o resultado gerado e qualquer registro de uso — restringindo o uso do fornecedor à prestação do serviço contratado, a menos que exista permissão escrita em contrário.
O Instituto Nacional de Padrões e Tecnologia dos Estados Unidos, o NIST, trata o mesmo problema pelo lado da estrutura de governança. Sua referência de gestão de risco de IA pede que a empresa mantenha política formal para risco vindo de fornecedor e de dado de terceiro, avalie esse risco na contratação e em intervalos definidos, e preserve o direito de auditar as práticas de IA do fornecedor — não apenas confiar na palavra dele.
A norma internacional de sistemas de gestão de IA, a ISO/IEC 42001, chega a uma conclusão parecida por outro caminho: exige que a empresa avalie a capacidade de cada fornecedor de cumprir requisitos de IA responsável, peça evidência — não promessa — e seja avisada quando o fornecedor mudar o modelo, o conjunto de dados ou a forma de hospedagem, porque essa mudança pode alterar o risco que a empresa já tinha aceitado.
Por que a cláusula de marketing não protege ninguém
A saída mais comum ainda é a errada: aceitar a página de segurança do fornecedor como se fosse prova. Uma declaração pública de "segurança de nível empresarial" não é uma cláusula — é um argumento de venda, e argumento de venda não é exigível depois que algo dá errado.
O mesmo vale para o certificado isolado. Pedir um selo de conformidade na proposta é um primeiro filtro, mas não substitui a obrigação contratual. A prática recomendada por quem avalia risco de fornecedor é diferente: transformar cada certificação exibida numa cláusula que a sustente — o fornecedor declara o escopo certificado, se compromete a notificar mudança de escopo e aceita fornecer evidência sob pedido, não só o selo.
Outro erro comum é tratar a cláusula de subcontratação como formalidade. Um fornecedor de IA raramente opera sozinho: usa modelo de terceiro, hospedagem de terceiro, às vezes até revisão humana terceirizada. Sem cláusula que obrigue a listar esses subfornecedores e notificar troca, a empresa contratante descobre a cadeia real só quando algo já deu errado.
E há o ponto que mais aparece nas análises jurídicas mais recentes: a indenização costuma cobrir o software, mas não o dado de treinamento nem o resultado gerado pela IA. Se o modelo foi treinado com dado que infringe direito autoral ou viola privacidade de terceiro, a responsabilidade pode recair sobre quem contratou — não só sobre quem treinou. Negociar essa cobertura antes da assinatura sai mais barato do que negociá-la depois de uma notificação de violação.
O que precisa existir na prática
Um contrato de IA auditável se apoia em mecanismos verificáveis, não em adjetivo. São eles que uma cláusula bem escrita precisa exigir do fornecedor — e que uma empresa madura já exige de si mesma antes de assinar.
Entrada pela identidade corporativa, não por conta avulsa. A cláusula deve obrigar que o acesso ao sistema de IA venha do mesmo diretório de identidade da empresa: quem sai da empresa perde o acesso ao mesmo tempo, sem depender de alguém lembrar de cancelar uma conta paralela.
Acesso conforme o papel de cada pessoa, não a ferramenta inteira. O contrato precisa permitir configurar o que cada função enxerga e faz dentro do sistema — e o fornecedor tem que provar que essa separação existe, não apenas descrevê-la numa página de vendas.
Aprovação humana em ações sensíveis, com regra clara de quando ela vale. A cláusula precisa nomear em que situações uma ação para e pede confirmação de uma pessoa antes de seguir — não deixar essa decisão a critério do fornecedor depois que o contrato já foi assinado.
Trilha de auditoria detalhada e acessível a quem contratou. O direito de auditar, defendido pelo NIST, só vale na prática se o contrato também garantir acesso aos registros — de quem fez o quê, quando e sob qual permissão — e não apenas o direito teórico de solicitar uma auditoria algum dia.
Regra de retenção e apagamento de dado, com prazo escrito. O contrato precisa dizer por quanto tempo o dado fica retido depois do fim da prestação do serviço e como o apagamento é comprovado. Sem isso, "os dados serão tratados com segurança" não é uma obrigação verificável — é só uma frase.
É assim que a Skyller foi desenhada: identidade vinda do diretório da empresa, permissão por papel e aprovação humana como padrão do sistema, não como cláusula que a empresa precisa negociar à parte.
O ganho de um contrato que se pode auditar
Quando o contrato nomeia os controles em vez de prometer segurança, a área jurídica e a área de segurança param de trabalhar em paralelo e passam a negociar a partir da mesma lista. A auditoria interna ganha uma pergunta objetiva para cada cláusula: o controle existe, e existe evidência disso?
Isso também acelera a próxima compra. Quem avalia fornecedor de IA sem uma lista prévia de controles a exigir refaz o mesmo trabalho a cada renovação. Com cláusulas específicas, a próxima negociação usa o mesmo roteiro — e o time de compras discute posição, não descobre o vocabulário do zero.
Há um ganho menos óbvio: o contrato bem escrito também protege contra a própria evolução do fornecedor. Sistema de IA muda de modelo, de fornecedor de hospedagem e de política de dado com mais frequência do que outros sistemas corporativos. Uma cláusula de notificação de mudança material — o tipo que a ISO 42001 recomenda — dá à empresa a chance de reavaliar o risco antes que a mudança já esteja em produção, não depois.
Perguntas para levar à próxima negociação de contrato
Antes de assinar — ou renovar — um contrato de fornecedor de IA, vale levar estas perguntas para a mesa:
- O fornecedor pode usar nossos dados para treinar o modelo dele, e sob qual condição isso muda? Se a resposta estiver só numa política pública e não numa cláusula, ela pode mudar sem aviso.
- Quem, do nosso lado, tem direito de auditar as práticas de IA do fornecedor, e com que prazo de resposta? Um direito de auditoria sem prazo definido é um direito que, na prática, ninguém exerce.
- A indenização cobre reivindicação sobre o dado de treinamento e sobre o resultado gerado, ou só sobre o software? É a lacuna mais citada por advogados especializados em contrato de IA.
- O fornecedor é obrigado a notificar mudança de modelo, de subfornecedor ou de hospedagem? Sem essa cláusula, a empresa descobre a mudança só depois que ela já afetou alguma operação.
- Existe prazo contratual para apagamento de dado após o fim do contrato, e como isso é comprovado? "Tratamento seguro do dado" sem prazo escrito não é uma obrigação — é uma intenção.
