Due diligence de fornecedor de IA: o que perguntar antes de contratar

Due diligence de fornecedor de IA é a pergunta que você faz antes de assinar o contrato, não depois que o modelo já decide alguma coisa pela sua empresa: de onde vem o dado de treinamento, quem responde se o sistema errar, e o que o contrato garante quando esse mesmo fornecedor precisar ser auditado. Uma demonstração bem feita não responde nenhuma dessas três perguntas. Elas pedem contrato, não slide.

Eu via essa mesma lacuna em auditoria de sistema crítico muito antes de IA virar pauta de diretoria: fornecedor promete suporte e evidência de boca, sem nada escrito que obrigue a entregar isso quando o problema aparece de verdade. Antes de cobrar qualquer prova de um fornecedor novo, vale medir onde a própria empresa está, porque o Gap Analysis gratuito mostra em menos de uma hora se o buraco é no contrato do fornecedor ou no inventário interno que ainda nem existe, e isso decide quem você aborda primeiro.

Por que due diligence de fornecedor de IA não é só questionário de segurança da informação

Todo contrato de software já passa por um questionário de segurança da informação: certificação, política de senha, criptografia em trânsito e em repouso. Nenhum desses campos pergunta de onde veio o dado que treinou o modelo, se o fornecedor usa a sua base para melhorar o produto de outro cliente, ou se existe uma pessoa 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.

O NIST organiza esse ponto dentro da função de governança do seu framework de risco, num bloco dedicado a política para risco de terceiro e de cadeia de suprimento em sistemas de IA: contrato, monitoramento contínuo do fornecedor e verificação de proveniência do modelo entram no mesmo pacote de obrigação³. A ISO 42001 segue a mesma lógica dentro do Anexo A, no grupo de controles sobre relação com fornecedor e terceiro: o padrão cobra regra clara de responsabilidade entre quem fornece e quem contrata, não apenas um atestado de conformidade genérico¹.

O mapa de controles do Anexo A da ISO 42001 ajuda a separar as duas listas sem reinventar categoria: um bloco de controle cuida de segurança da informação propriamente dita, outro cuida especificamente de recurso e relação com fornecedor de IA. Juntar os dois numa única planilha de compra é o jeito mais comum de a segunda lista nunca ser preenchida, porque ela se parece com a primeira o suficiente para passar despercebida.

O que perguntar a um fornecedor de IA antes de contratar?

A pergunta certa cobre seis frentes: dado de treinamento, explicabilidade, direito de auditoria, notificação de incidente, portabilidade e subcontratação. Faltando uma delas, o contrato protege a empresa de metade do risco que ela realmente corre.

Eu prefiro revisar um contrato com fornecedor de IA a partir de um checklist de fornecedor de IA fechado antes da primeira reunião, porque negociar cláusula depois que o fornecedor já apresentou proposta comercial custa mais caro do que pedir a resposta junto com o orçamento:

Cada linha dessa lista vira cláusula, não só item de planilha de compra. É aí que a due diligence de fornecedor de IA para de ser teoria e começa a proteger a empresa de verdade.

Esse ponto cego tem nome e já aparece no inventário de sistemas de IA de qualquer empresa que levanta a lista direito: o recurso embutido some do radar de compras porque ninguém assinou contrato novo para ele. A due diligence de fornecedor de IA, nesse caso, não começa com uma ligação para o fornecedor, começa com a pergunta interna de quem autorizou ligar aquele recurso e com que dado ele foi testado antes de entrar em produção.

Cláusula de auditoria em contrato de IA: o que incluir

Montar essa cláusula do zero, para cada fornecedor novo, consome tempo que a maioria das áreas de compliance não tem sobrando numa semana comum. Os modelos de política e inventário de sistemas de IA trazem a estrutura de cláusula de auditoria e due diligence já redigida; falta ajustar o nome do fornecedor e o escopo do sistema contratado.

Uma cláusula de auditoria em contrato de IA 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 já 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 ambos.

Quem já usa um modelo de cláusulas do Anexo A da ISO 42001 para redigir outras partes do contrato tende a subestimar o item de fornecedor, porque ele parece menos técnico que criptografia ou retenção de log. Na prática é o contrário: é a cláusula que decide se a empresa vai ter alguma coisa para mostrar quando um cliente, um auditor ou a própria Justiça perguntar como aquele modelo foi escolhido e avaliado antes de entrar em produção.

Qual é a responsabilidade do fornecedor de IA segundo a LGPD?

A combinação fornecedor de IA e LGPD aparece toda vez que dado pessoal passa pela mão de um terceiro, e isso cobre praticamente todo fornecedor de IA que toca currículo, histórico de crédito ou prontuário. A lei trata esse fornecedor como operador: ele trata o dado segundo as instruções do controlador, que verifica se essas instruções e as normas da matéria estão sendo seguidas². Controlador e operador respondem de forma solidária por dano patrimonial, moral, individual ou coletivo causado em violação à legislação de proteção de dados².

Na prática, isso significa que terceirizar o tratamento para um fornecedor de IA não terceiriza a responsabilidade. 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.

Fornecedor de IA e ISO 42001: o que muda quando ele também é auditado

Essa mesma exigência de prova documentada é o que sustenta uma auditoria aprovada sem ressalva. 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.

Quando a própria empresa busca a certificação ISO 42001, o auditor pede evidência do processo de due diligence, não só do contrato assinado: como o fornecedor foi avaliado antes da escolha, quem aprovou, e com que frequência essa avaliação é repetida¹. Um contrato bom guardado numa gaveta sem processo por trás não convence um auditor de certificação, porque ele pergunta pelo processo que gerou o contrato, não só pelo papel final.

Erros comuns na due diligence de fornecedor de IA

O primeiro erro é tratar a due diligence como etapa única, feita antes da assinatura e arquivada depois. 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.

O segundo erro é delegar a avaliação inteira para a área jurídica, que lê cláusula com rigor mas não tem como avaliar se a explicação técnica do fornecedor sobre o modelo faz sentido. A due diligence de fornecedor de IA funciona melhor com jurídico e alguém que entenda o sistema lendo o mesmo documento, cada um perguntando o que o outro não perguntaria sozinho.

O terceiro erro é aplicar o checklist só ao fornecedor novo e pular o que já está contratado há anos. Boa parte do risco que eu encontro em auditoria está em sistema antigo que ganhou um recurso de IA sem que ninguém revisasse o contrato original para ver se ele ainda cobre o que o sistema passou a fazer.

O quarto erro, mais caro de todos, é confundir due diligence com o ato único de assinar o contrato. Uma auditoria interna de IA recorrente é o que confirma, depois da assinatura, se o fornecedor ainda cumpre o que prometeu no questionário: se o dado continua vindo de onde disse, se a explicabilidade prometida existe na prática quando alguém pede, se o subcontratado mudou sem aviso. 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.

O custo de pular qualquer um desses quatro pontos 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. Se a resposta demorar para aparecer, o contrato está pronto para ser assinado, mas não para proteger a empresa quando o problema chegar.

Veja também