Due diligence de fornecedor de IA: checklist

Uma boa demonstração ainda deixa perguntas importantes sem resposta

O fornecedor apresenta um agente que consulta documentos, prepara respostas, atualiza o CRM ou acompanha tarefas. A demonstração funciona. A interface parece pronta. O preço cabe no orçamento inicial.

A contratação, porém, transfere parte de um processo para uma arquitetura que dependerá de dados, integrações, modelos, credenciais, suporte e decisões humanas. O que funcionou em um roteiro controlado pode exigir outra estrutura quando recebe volume real, registros incompletos, exceções e sistemas indisponíveis.

A due diligence de fornecedor de IA verifica se as afirmações comerciais e técnicas possuem evidência suficiente para a decisão de compra. Ela examina a empresa fornecedora, a solução proposta, as dependências, o modelo de operação e as condições de continuidade antes da assinatura.

Esse trabalho começa depois que a empresa delimitou o problema e recebeu uma proposta plausível. A RFP para agente de IA organiza o que pedir ao mercado. A due diligence testa se o fornecedor escolhido consegue cumprir o que respondeu.

Due diligence, homologação técnica e avaliação do agente cumprem funções diferentes

As três atividades se conectam, mas encerram decisões distintas.

Due diligence do fornecedor

Avalia capacidade empresarial, técnica e operacional antes da contratação. Procura evidência sobre experiência, segurança, equipe, dependências, suporte, situação da solução e condições de saída.

Homologação da solução

Confirma se arquitetura, integrações, controles e ambiente atendem aos requisitos definidos. Pode incluir análise documental, revisão técnica e testes controlados.

Avaliação do agente

Mede o comportamento do sistema em casos representativos. Verifica qualidade, limites, escalonamento e efeitos nos sistemas de destino.

Uma empresa pode aprovar o fornecedor e reprovar a solução proposta. Também pode homologar a arquitetura e descobrir, nos testes, que o agente ainda falha em uma classe crítica. Por isso, a decisão deve registrar o resultado de cada camada em vez de produzir um único selo genérico de aprovação.

Comece pelo risco da capacidade que será contratada

A profundidade da diligência deve acompanhar a consequência possível. Um recurso que resume material público exige menos verificação que um agente autorizado a acessar dados de clientes ou alterar registros financeiros.

Classifique o caso por cinco fatores:

dados consultados ou produzidos;
ações permitidas nos sistemas;
alcance sobre clientes, unidades e processos;
dificuldade para desfazer um erro;
tempo que a operação suporta sem o serviço.

Quanto maior a combinação entre dado sensível, ação externa, volume e baixa reversibilidade, maior precisa ser a evidência. Questionário comercial, política publicada e certificado ajudam, mas podem não bastar para uma capacidade crítica.

A página sobre matriz de autonomia para agentes de IA ajuda a ligar permissão e supervisão à consequência de cada ação.

Verifique a empresa que continuará existindo depois do projeto

A arquitetura pode ser boa e o fornecedor não ter estrutura para sustentá-la. A diligência empresarial procura sinais de continuidade e responsabilidade.

Peça informações verificáveis sobre:

razão social e partes responsáveis pelo contrato;
tempo de operação e experiência relevante;
composição da equipe que atenderá o projeto;
dependência de profissionais específicos;
parceiros e subcontratados essenciais;
capacidade de suporte e escalonamento;
cobertura durante férias, desligamentos e incidentes;
política de segurança e resposta a vulnerabilidades;
referências compatíveis com o nível de risco;
seguro, certificação ou obrigação setorial quando aplicável;
estabilidade financeira proporcional à duração do compromisso.

A análise precisa respeitar o tamanho do contrato. Exigir uma estrutura de multinacional de uma consultoria especializada pode eliminar um parceiro adequado sem reduzir o risco central. O objetivo é descobrir se a capacidade prometida depende de uma pessoa, conta ou relação que pode desaparecer sem transição.

Referências comerciais devem ser usadas com perguntas concretas. Investigue cumprimento de escopo, transparência diante de falhas, qualidade da documentação, suporte depois da entrega e facilidade para receber dados ou artefatos ao encerrar a relação.

Faça a proposta virar uma arquitetura verificável

Expressões como “agente personalizado”, “memória inteligente” e “integração completa” não descrevem uma operação. Peça um desenho que mostre:

entradas e gatilhos;
sistemas consultados;
modelos e provedores usados;
contexto enviado ao modelo;
memória e estado persistidos;
ferramentas disponíveis;
operações de leitura e escrita;
identidades e permissões;
aprovações humanas;
logs e evidências;
filas, retentativas e tratamento de erros;
caminhos de contingência;
responsáveis por cada camada.

Compare o desenho com a unidade de trabalho contratada. Se o agente prepara uma proposta, por exemplo, a arquitetura precisa explicar como identifica o cliente, encontra condições vigentes, trata informação ausente, encaminha aprovação e confirma o artefato final. Uma resposta de chat não prova que o processo foi concluído.

Também peça uma lista de hipóteses. Integração disponível, qualidade do cadastro, acesso a sandbox, volume, formato dos documentos e participação da equipe cliente costumam afetar prazo e preço. Hipótese escondida reaparece como aditivo ou atraso.

Identifique todos os fornecedores que entram pela mesma porta

Uma solução contratada com uma empresa pode depender de vários terceiros: provedor de modelo, plataforma de automação, banco vetorial, hospedagem, observabilidade, OCR, canal de mensagens e conectores.

A due diligence deve registrar:

| Dependência | Pergunta de verificação | |---|---| | modelo | Qual provedor, perfil, região e política de uso de dados? | | plataforma | Quem administra, atualiza e exporta a configuração? | | infraestrutura | Onde executa, quem monitora e como recupera? | | integração | É oficial, própria ou depende de automação de interface? | | armazenamento | Que dados persistem, por quanto tempo e sob qual acesso? | | observabilidade | O cliente consegue acessar casos e efeitos relevantes? | | subcontratado | Que trabalho realiza e qual obrigação assume? |

O guia sobre cadeia de suprimentos de agentes de IA mostra como ligar essas dependências à composição que realmente roda em produção.

Concentração também importa. Se a mesma plataforma controla execução, memória, logs e exportação, uma indisponibilidade ou disputa pode afetar todo o serviço. Dependência não torna a solução inviável por definição. Ela precisa estar visível, precificada e acompanhada de uma saída possível.

Exija evidência proporcional à afirmação

Cada promessa relevante deve apontar para um artefato, teste ou registro.

| Afirmação | Evidência útil | |---|---| | “o agente usa apenas dados autorizados” | mapa de fontes, identidade, permissões efetivas e teste negativo | | “existe isolamento entre clientes” | arquitetura de segregação, chaves de escopo e teste entre contas | | “todas as ações ficam registradas” | trace ligado ao efeito confirmado no sistema oficial | | “é possível interromper o agente” | procedimento exercitado sobre gatilhos, filas, ferramentas e credenciais | | “a solução é portátil” | exportação de amostra, formato documentado e inventário de ativos | | “o suporte cobre incidentes críticos” | severidades, canal, escala, responsável e exercício ou histórico |

Certificados e políticas demonstram que controles foram definidos ou avaliados em determinado escopo. Eles não comprovam automaticamente a configuração desta solução, deste ambiente e desta versão.

Quando a evidência não pode ser entregue antes do contrato, transforme a lacuna em condição de fase, marco de aceite ou direito de encerramento. Tratar uma promessa futura como capacidade pronta distorce a decisão econômica.

Examine dados, memória e uso pelo fornecedor

Peça uma resposta por classe de dado, não uma declaração única de privacidade.

Verifique:

que entradas chegam ao fornecedor e aos subfornecedores;
se dados são usados para treinamento ou melhoria de serviços;
onde ocorre processamento e armazenamento;
quais cópias temporárias, índices e backups são criados;
como funciona a memória entre execuções;
quem possui acesso administrativo;
que conteúdo aparece nos logs;
quais prazos de retenção podem ser configurados;
como correção, exportação e exclusão são executadas;
que evidência confirma o descarte;
o que muda durante suporte e investigação de incidentes.

A retenção de dados em agentes de IA precisa ser definida por finalidade, objeto e evento. “Dados protegidos” é uma frase curta demais para governar sessões, arquivos, memória, traces e backups.

Questões jurídicas, regulatórias e contratuais devem ser validadas pelos responsáveis da empresa. A diligência organiza fatos e lacunas para essa avaliação. Ela não substitui parecer especializado.

Avalie a sustentação, não somente a implantação

Agentes mudam quando modelos, fontes, ferramentas, políticas ou volumes mudam. A proposta precisa explicar quem cuida do serviço depois do primeiro aceite.

Pergunte:

quem monitora disponibilidade, qualidade, custo e risco;
quem recebe alertas e decide intervenção;
como novas versões são testadas;
que mudanças entram no valor contratado;
como correções urgentes são priorizadas;
quais horários e canais de suporte existem;
como incidentes são classificados e escalados;
quem mantém casos de regressão e documentação;
que dependências são responsabilidade do cliente;
como a operação funciona durante indisponibilidade;
como o serviço será transferido ou encerrado.

O SLA para agentes de IA deve acompanhar unidades concluídas, qualidade e continuidade. Disponibilidade de API isolada não representa o serviço que a empresa comprou.

Rode um teste de saída antes de assinar

Portabilidade prometida merece uma amostra prática. Escolha um conjunto pequeno e peça a exportação dos ativos que seriam necessários em uma troca:

configuração e instruções;
dados autorizados e seus identificadores;
memória ou estado que precise continuar;
casos e resultados de avaliação;
logs necessários para auditoria;
documentação de integrações;
lista de dependências;
procedimento de revogação e exclusão.

Verifique se os formatos abrem, se os vínculos permanecem compreensíveis e se outra equipe conseguiria reconstruir a responsabilidade operacional. O plano de saída para fornecedor de IA detalha transição, corte e aceite final.

Um teste pequeno revela dependências que uma cláusula abstrata não mostra. Também ajuda a estimar custo e prazo de saída antes que a empresa esteja pressionada a migrar.

Organize os achados por decisão

A diligência precisa terminar em um registro curto, com evidência e responsável.

Use quatro estados:

Aprovado

A evidência atende ao requisito e pode ser associada à versão ou condição avaliada.

Aprovado com condição

A contratação pode avançar desde que uma ação tenha dono, prazo e marco de aceite. A condição deve limitar escopo ou pagamento quando for relevante.

Pendente

Falta informação suficiente. O item não deve desaparecer dentro de uma nota geral. Registre impacto possível e quem buscará a resposta.

Impeditivo

A lacuna conflita com restrição obrigatória ou cria risco incompatível com o caso. Preço ou funcionalidade adicional não compensam esse ponto.

Para cada achado, registre requisito, afirmação do fornecedor, evidência recebida, conclusão, risco, ação, dono e data. Essa estrutura preserva a razão da decisão quando equipe, proposta ou arquitetura mudarem.

Checklist de due diligence de fornecedor de IA

Empresa e responsabilidade

A parte contratada e os responsáveis estão identificados?
A equipe principal e sua cobertura operacional estão claras?
Dependências de pessoas específicas foram expostas?
Referências foram verificadas com perguntas sobre operação real?

Solução e arquitetura

A unidade de trabalho e o efeito esperado estão definidos?
Arquitetura, integrações, identidades e aprovações são visíveis?
Hipóteses técnicas e dependências do cliente foram registradas?
Afirmações críticas possuem evidência verificável?

Dados e segurança

Fluxo, finalidade, retenção e exclusão de dados foram detalhados?
Subfornecedores e regiões relevantes estão identificados?
Permissões efetivas podem ser testadas?
Incidente, interrupção e recuperação têm responsáveis?

Operação e continuidade

Suporte, manutenção e atualização possuem escopo?
SLA acompanha o processo concluído?
Custos variáveis e premissas de volume estão visíveis?
Exportação, transição, revogação e descarte foram testados ou contratados?

Decisão

Cada lacuna tem estado, impacto, dono e prazo?
Condições aparecem nos marcos e no contrato?
Itens impeditivos ficaram separados da pontuação comercial?
A autoridade interna registrou a decisão e os riscos aceitos?

A diligência protege a capacidade que a empresa pretende comprar

Escolher um fornecedor de IA exige avaliar tecnologia, mas a compra só entrega valor quando a capacidade continua funcionando em casos reais, com suporte, evidência e limites conhecidos.

A due diligence reduz a distância entre demonstração e operação. Ela mostra quem responde, de que componentes o serviço depende, como as promessas serão verificadas e o que a empresa consegue fazer quando qualidade, custo ou relação comercial mudarem.

O resultado esperado é uma decisão rastreável: contratar, contratar com condições, pedir nova evidência ou recusar. A empresa preserva velocidade sem assinar um conjunto de dependências que só será compreendido depois do primeiro problema.