AI 供應商盡職調查不能只靠安全問卷

A due diligence de fornecedor de IA que o questionário de segurança não cobre

O problema

Todo contrato de software passa por um questionário de segurança da informação: certificação, política de senha, criptografia em trânsito e em repouso. Sou auditor de sistemas críticos e vejo o mesmo questionário ser aplicado, sem nenhum ajuste, a fornecedor de IA. Nenhum campo pergunta de onde veio o dado que treinou o modelo, se o fornecedor reaproveita a base do cliente para melhorar o produto de outro, ou se existe alguém capaz de explicar por que o sistema recusou um crédito específico.
Segurança da informação protege o dado parado. Due diligence de fornecedor de IA protege a decisão que o modelo toma com esse dado. São duas auditorias diferentes, e a segunda raramente existe num processo de compra tradicional.

Seis frentes, não uma

A pergunta certa para um fornecedor de IA cobre seis frentes, e faltando uma delas o contrato protege a empresa de metade do risco que ela corre de verdade:

Dado de treinamento: de onde vem, teve consentimento do titular, pode ser reaproveitado para treinar o modelo de outro cliente.2. Explicabilidade: existe um responsável técnico capaz de explicar uma decisão específica do modelo, não só a média geral de acerto.3. Direito de auditoria: o contrato permite pedir evidência técnica quando necessário, não só um relatório anual padronizado.4. Notificação de incidente: prazo e canal definidos em contrato, não deixados para a boa vontade do fornecedor.5. Portabilidade: o dado e o modelo treinado com ele saem com a empresa se o contrato terminar.6. Subcontratação: o fornecedor usa modelo de outro provedor por trás do produto, e que responsabilidade assume por isso. Cada linha dessa lista precisa virar cláusula, não item de planilha de compra. É aí que a due diligence para de ser teoria. Vale também para o que já está contratado. Um ERP ou um CRM que ganhou um recurso de IA numa atualização recente é, para efeito de risco, um fornecedor de IA novo, mesmo que o contrato original seja antigo. Normalmente ninguém revisita esse contrato quando o recurso chega embutido, e o ponto cego some do radar de compras porque nenhum contrato novo foi assinado para ele. ## A cláusula de auditoria, em três partes Uma cláusula de auditoria que funciona tem três partes. Primeiro, o direito de solicitar evidência técnica específica, não um relatório de conformidade genérico que o fornecedor manda para qualquer cliente. Segundo, o prazo para responder a esse pedido, porque direito de auditoria sem prazo vira pedido que fica três meses sem resposta. Terceiro, o que acontece se o fornecedor se recusar: multa, direito de rescisão, ou os dois. Fornecedor que recusa assinar essa cláusula já deu uma resposta sobre o risco antes de qualquer demonstração do produto. Fornecedor pequeno às vezes recusa porque nunca formalizou o próprio processo interno, e isso já é um dado. Fornecedor grande que recusa por política comercial costuma aceitar uma versão mais restrita, limitada a evidência documental em vez de acesso a sistema. O que não vale assinar é um contrato de IA sem nenhuma cláusula de auditoria, substituída só por uma declaração de boas práticas no site do fornecedor. ## Terceirizar o processamento não terceiriza a responsabilidade A LGPD trata o fornecedor de IA como operador: ele trata o dado segundo a instrução do controlador, que fiscaliza se essa instrução e a lei estão sendo seguidas. Controlador e operador respondem de forma solidária por dano causado em violação à legislação de proteção de dados. Na prática, isso significa que a empresa que contrata continua exposta se o fornecedor errar, e o contrato é o único lugar onde essa exposição pode ser dividida de forma explícita, com ressarcimento e prazo definidos, em vez de discutida depois do incidente. ## Um cenário comum Uma empresa de porte médio contrata um fornecedor de IA para triagem de currículo e assina o contrato padrão do próprio fornecedor, sem alteração nenhuma. Seis meses depois, um candidato questiona a decisão automatizada, e o jurídico pede ao fornecedor a explicação do modelo que recusou a candidatura. A resposta demora três semanas e vem incompleta, porque o contrato nunca obrigou prazo nem formato de resposta. A due diligence existiu, mas só em e-mail trocado antes da assinatura. Nunca virou cláusula, e por isso não valeu nada no momento em que precisou valer. Numa auditoria de SOX em mineração que conduzi, a aprovação da Ernst & Young veio sem ressalva porque cada controle tinha evidência rastreável por trás, não promessa verbal de quem operava o sistema. Due diligence de fornecedor de IA pede o mesmo padrão: evidência que sobrevive a uma pergunta de auditor externo, não resposta que soa bem numa reunião. ## O erro que custa mais caro Tratar due diligence como etapa única, feita antes da assinatura e arquivada depois, é o erro mais caro dos quatro que vejo se repetir. Fornecedor de IA muda de modelo, troca de subcontratado e atualiza a política de uso de dado com frequência maior que qualquer contrato de software tradicional, e nada disso aparece automaticamente para quem contratou. Contrato bom no dia da assinatura e nunca mais revisitado vale tanto quanto contrato nenhum, porque o risco de fornecedor de IA muda de nível sem o cliente ser avisado: o modelo é atualizado do lado do fornecedor, e quem contratou só descobre a mudança quando o comportamento do sistema já é outro. ## Conclusão O custo de pular qualquer uma dessas frentes raramente aparece no mês da assinatura. Aparece meses depois, quando um incidente expõe que ninguém sabia explicar por que o modelo decidiu o que decidiu, e a primeira pergunta de quem investiga é sempre a mesma: o contrato previa isso, ou a empresa só confiou na palavra do fornecedor? Antes de assinar o próximo contrato de fornecedor de IA, pergunte quem, na sua empresa, vai cobrar essa cláusula de auditoria no dia em que o modelo errar. Este texto é uma versão condensada de uma análise mais longa que publiquei em https://iso42001.com.br/artigos/due-diligence-fornecedor-ia/