Gestão de risco de fornecedores de IA é o processo formal de classificar, avaliar e monitorar todo fornecedor e modelo de terceiros que sua empresa contrata — proporcional à criticidade de cada um, com evidência documentada, não confiança na palavra do vendedor. É diferente de compliance de IA (o programa interno que garante que a própria empresa segue as regras) e de governança de IA (a arquitetura geral de papéis e processos): aqui o risco nasce fora dos seus domínios, num modelo, num dataset ou numa API que você não controla, mas pelo qual responde solidariamente perante cliente, regulador e titular de dado. Este guia mostra como classificar fornecedores por criticidade, calibrar due diligence pelo risco e estruturar o contrato e o monitoramento contínuo que sustentam essa gestão na prática.
O que é gestão de risco de fornecedores de IA (e o que ela não é)
Toda empresa que usa IA generativa, contrata uma plataforma com IA embutida ou integra um modelo de terceiros via API está, na prática, terceirizando parte do processamento de dado e da decisão automatizada para um fornecedor. A gestão de risco de fornecedores de IA é a disciplina que garante que essa terceirização não vira ponto cego: cada fornecedor é classificado, avaliado e acompanhado de forma proporcional ao risco que representa — não com o mesmo questionário genérico para o provedor de um chatbot interno e para o modelo que decide crédito de cliente.
Vale separar três conceitos que se confundem:
- Governança de IA — a arquitetura completa de regras, papéis e processos da empresa, coberta no pilar governança de IA na prática.
- Compliance de IA — o programa interno que produz evidência de que a própria empresa segue essas regras: inventário de sistemas, avaliação de risco por caso de uso, trilha de auditoria. Detalhado em compliance e IA: o guia para C-level e jurídico, que já aponta a due diligence de fornecedor como o "ponto cego" mais comum dos programas de compliance — este artigo é o aprofundamento dessa lacuna específica.
- Gestão de risco de fornecedores de IA — o recorte deste guia: due diligence, classificação por criticidade, avaliação de segurança e cláusula contratual aplicadas especificamente a quem fornece IA (ou usa IA para processar seus dados) de fora da empresa.
- Gestão de risco de modelo de IA — a validação técnica independente e o monitoramento contínuo de cada modelo em produção, seja ele construído internamente ou comprado de terceiro. A classificação de fornecedor por criticidade que este guia detalha é o gatilho para exigir do fornecedor a mesma evidência de validação que a gestão de risco de modelo de IA exige de modelo construído internamente.
Um programa de compliance maduro sem gestão de risco de fornecedor é uma casa com a porta da frente trancada e a dos fundos aberta: a empresa controla o que acontece internamente e não sabe o que o fornecedor faz com o dado que recebe.
Por que isso virou prioridade em 2026
A urgência não é hipotética. A Deloitte Brasil descreve como padrão de mercado a segmentação de fornecedores por criticidade e tipo de acesso, com due diligence de segurança e privacidade proporcional ao risco e exigência de evidências — políticas, logs, testes, plano de resposta a incidente — antes e depois da contratação, dentro da metodologia D-Tracker de gestão de riscos de terceiros. É exatamente a lógica que estrutura este guia: nem todo fornecedor merece o mesmo nível de escrutínio, mas todo fornecedor crítico precisa de prova, não de promessa.
Ao mesmo tempo, a maturidade ainda é baixa. A pesquisa "Avaliando o impacto da IA na gestão de riscos de terceiros", publicada pela Deloitte em dezembro de 2025 com 336 respondentes globais (47 no Brasil), mostra que apenas 11% das organizações brasileiras alcançaram nível gerenciado de maturidade em uso de IA para gestão de riscos de terceiros — quase o dobro da média global, mas ainda minoria — e que 42% das empresas brasileiras seguem usando planilhas para coletar e consolidar esses dados. Ou seja: a maioria das empresas brasileiras ainda não tem processo formal, mesmo com o tema priorizado pela diretoria de risco.
O NIST reconhece o mesmo problema em escala global. O AI Risk Management Framework dedica categorias inteiras a risco de terceiros — não é um apêndice, é parte do núcleo do framework, segundo o AI Resource Center do NIST:
| Categoria | O que exige |
|---|---|
| Govern 6 | Políticas e processos para tratar riscos de IA vindos de software, dado e demais elementos da cadeia de fornecimento de terceiros — incluindo processo de contingência para falha ou incidente em sistema de terceiro classificado como alto risco |
| Map 4 | Mapeamento de risco e benefício de todo componente do sistema de IA, incluindo software e dado de terceiros, com identificação dos controles internos aplicáveis a cada componente |
| Manage 3 | Monitoramento regular dos riscos e benefícios vindos de fornecedores, incluindo modelos pré-treinados usados no desenvolvimento, como parte da manutenção contínua do sistema |
Se sua empresa já adotou o NIST AI RMF como referência de framework — o passo a passo completo está em framework de governança de IA —, a gestão de risco de fornecedor não é um processo à parte: é a aplicação dessas três categorias ao seu portfólio de fornecedores.
Classificação de fornecedores de IA por criticidade
O primeiro passo é parar de tratar todo fornecedor de IA como igual. Classifique por três critérios, não só pelo tamanho do contrato:
- Tipo de dado que o fornecedor acessa — nenhum dado da empresa, dado interno não sensível, dado pessoal, dado pessoal sensível.
- Nível de autonomia da decisão — o fornecedor entrega uma sugestão revisada por humano, ou o sistema decide sozinho algo que afeta cliente, colaborador ou terceiro.
- Dependência operacional — se o fornecedor falhar ou descontinuar o serviço, qual processo de negócio para.
Cruzando os três critérios, a maioria das empresas chega a três níveis de criticidade:
| Nível | Perfil típico | Exemplo |
|---|---|---|
| Baixo | Sem dado pessoal, sugestão revisada por humano, sem dependência operacional crítica | Ferramenta de IA generativa para rascunho de e-mail interno |
| Médio | Dado pessoal envolvido ou output usado externamente, mas com revisão humana antes da ação | Copiloto de atendimento que sugere resposta ao cliente |
| Alto | Decisão automatizada sem revisão que afeta pessoa (crédito, contratação, triagem, preço), ou dependência operacional crítica | Modelo de terceiros que aprova ou nega uma transação sozinho |
Essa é a mesma lógica de risco por caso de uso que estrutura o inventário de sistemas em compliance e IA e a matriz de risco detalhada em riscos da IA generativa nas empresas — aqui aplicada especificamente a quem fornece a IA, não a quem usa. Fornecedor de IA embutida em software que a empresa já usa também entra nessa classificação: "não somos fornecedor de IA" não é resposta aceitável de um vendor que lançou um recurso de IA generativa na última atualização do produto.
Due diligence proporcional ao risco: o que exigir em cada nível
Devolver o mesmo questionário de vinte páginas para todo fornecedor trava o processo de compra e não separa quem é crítico de quem não é. O princípio — confirmado pela metodologia da Deloitte citada acima — é calibrar profundidade pela criticidade:
| Nível | O que avaliar | Evidência exigida |
|---|---|---|
| Baixo | Termos de uso, política de privacidade padrão | Registro no inventário; sem questionário formal |
| Médio | Certificações de segurança (ISO 27001, SOC 2), política de retenção e uso de dado, se treina modelo com o dado do cliente | Questionário estruturado; cópia de certificações; cláusula contratual de tratamento de dado |
| Alto | Tudo do nível médio, mais: arquitetura de subprocessadores, plano de resposta a incidente, direito de auditoria, histórico de incidentes de segurança, explicabilidade do modelo, viés testado | Auditoria documental completa; direito contratual de auditoria; reavaliação periódica, não só na assinatura |
Três perguntas que todo questionário de due diligence de IA precisa responder, independentemente do nível:
- Onde o dado é processado e armazenado — país, subprocessadores envolvidos, se há transferência internacional.
- Se o fornecedor treina ou ajusta modelo com o dado da sua empresa — e, se sim, com que base legal e possibilidade de opt-out.
- Como o fornecedor responde a incidente — prazo de notificação, canal de comunicação, o que a empresa recebe em caso de vazamento ou uso indevido.
O detalhamento das cláusulas exigíveis sob a LGPD — base legal do tratamento, papéis de controlador e operador, vedação a treinar modelo sem autorização, prazo de notificação de incidente — está em LGPD e IA generativa; não repetimos aqui. Para fornecedor de alto risco, use também o checklist de ISO/IEC 42001 como referência: perguntar se o fornecedor já é certificado (ou está em processo) é um proxy rápido de maturidade de governança do próprio fornecedor.
Cláusulas contratuais: o que muda quando o fornecedor entrega IA
Contrato de fornecedor de IA precisa de cláusulas que um contrato de software tradicional não tinha. As cinco que não podem faltar, calibradas pelo nível de criticidade definido acima:
- Vedação (ou autorização explícita e revogável) ao uso do dado da empresa para treinar o modelo do fornecedor — sem isso, o fornecedor pode legalmente usar seus prompts e documentos para melhorar o produto que vende a concorrentes.
- Titularidade e indenização sobre o output gerado — quem responde se o conteúdo gerado infringir direito de terceiro. O detalhamento completo de titularidade, direitos autorais e risco de contaminação por dado de treinamento está em propriedade intelectual e IA generativa nas empresas.
- Notificação de incidente em prazo definido — não "assim que possível": um número de horas ou dias, com o que precisa constar na notificação.
- Direito de auditoria — para fornecedores de alto risco, a empresa precisa poder pedir evidência (logs, testes, relatório de incidente) a qualquer momento, não só na renovação.
- Cláusula de descontinuação e portabilidade — o que acontece com o dado e com a continuidade operacional se o fornecedor encerrar o serviço ou for adquirido.
Nenhuma dessas cláusulas substitui revisão jurídica caso a caso — são o piso mínimo que qualquer contrato de fornecedor de IA de criticidade média ou alta deveria ter, e que a maioria dos contratos assinados antes de 2024 simplesmente não previa.
Monitoramento contínuo: due diligence não termina na assinatura
O erro mais comum é tratar due diligence de fornecedor como etapa única, concluída na contratação. Fornecedor de software adiciona recurso de IA generativa numa atualização sem avisar; modelo de terceiros muda de versão e altera comportamento; subprocessador novo entra na cadeia sem renegociação de contrato. A categoria Manage 3 do NIST AI RMF, citada acima, é explícita sobre isso: modelos pré-treinados de terceiros precisam de monitoramento contínuo como parte da manutenção regular do sistema — não checagem única no início.
Na prática, isso significa:
- Reavaliação periódica proporcional à criticidade — anual para risco médio, semestral ou a cada mudança relevante de produto para risco alto.
- Gatilho de reavaliação fora do ciclo sempre que o fornecedor lança novo recurso de IA, reporta incidente ou muda de subprocessador.
- Registro do que mudou — a mesma trilha de auditoria que sustenta compliance de IA, aplicada ao fornecedor: quando foi avaliado, o que mudou desde a última avaliação, quem aprovou a continuidade. A execução técnica desse monitoramento contínuo — o que auditar, com que frequência, quem conduz — está detalhada em auditoria de IA: guia técnico para C-level e compliance.
Quem lidera a gestão de risco de fornecedores de IA
Sem dono claro, cada área negocia fornecedor de IA sozinha e a classificação de risco vira formalidade que ninguém revisa. A divisão que funciona:
| Papel | Responsabilidade |
|---|---|
| Procurement / compras | Aplica a classificação de criticidade antes de qualquer contratação avançar; garante que o questionário de due diligence seja respondido antes da assinatura |
| Compliance | Mantém o registro de fornecedores classificados e a trilha de reavaliação periódica — a mesma disciplina descrita em compliance e IA |
| Jurídico | Revisa e negocia as cláusulas contratuais específicas de IA; responde por exposição em caso de falha do fornecedor |
| Segurança da informação | Avalia certificações, arquitetura de dados e plano de resposta a incidente do fornecedor, principalmente em criticidade alta |
| Área de negócio solicitante | Declara o caso de uso real e o tipo de dado envolvido — sem essa informação correta, a classificação de criticidade erra |
Esse comitê não precisa ser formal e permanente para todo fornecedor de baixo risco — mas para fornecedor de criticidade alta, a decisão de contratar não deveria sair de uma única área. O comitê de ética de IA já descrito no hub de governança é o fórum natural para decidir esses casos-limite.
Due diligence de fornecedor reduz a probabilidade de incidente, mas não elimina o risco residual — por isso vale avaliar também a transferência desse risco via apólice, tema de seguro cibernético para riscos de IA. E se a sua empresa está do outro lado dessa relação — fornecendo IA em vez de contratando —, o mesmo rigor se aplica a quem vende para o setor público, com exigências próprias de compliance e transparência algorítmica: veja IA no setor público brasileiro: o que muda para fornecedores.
Como a Jetpacks apoia a gestão de risco de fornecedores de IA
Dentro do método Flight Plan, a gestão de risco de fornecedores entra no desenho da governança, não como anexo jurídico depois da contratação. O Launchpad mapeia os fornecedores de IA já em uso — inclusive os que chegaram sem due diligence formal — e classifica por criticidade; o Flight Plan desenha, por área, o processo de aprovação e o nível de due diligence proporcional ao risco; o Booster capacita procurement, jurídico e líderes de área a aplicar essa classificação no dia a dia, não só ler o processo num documento; e o Mission Control entrega a trilha de evidência — quantos fornecedores classificados, quantos reavaliados no prazo — que compliance leva ao board. Como parceira oficial da Replit no Brasil, a Jetpacks já aplicou essa abordagem em empresas como Hypera Pharma, Volvo, BMR Medical e C12 Brasil.
FAQ
O que é gestão de risco de fornecedores de IA?
É o processo de classificar cada fornecedor de IA (ou de software com IA embutida) por criticidade, aplicar due diligence de segurança e privacidade proporcional a esse risco, exigir evidência documentada — não promessa verbal — e monitorar continuamente após a contratação, não só no momento da assinatura do contrato.
Qual a diferença entre gestão de risco de fornecedores de IA e compliance de IA?
Compliance de IA é o programa interno que garante que a própria empresa segue as regras de uso de IA, com inventário e trilha de auditoria dos próprios sistemas. Gestão de risco de fornecedores foca especificamente no risco que entra de fora — modelos, dados e infraestrutura controlados por terceiros, mas pelos quais a empresa responde solidariamente perante cliente e regulador.
Como classificar um fornecedor de IA por criticidade?
Por três critérios: o tipo de dado que ele acessa (nenhum, interno, pessoal, pessoal sensível), o nível de autonomia da decisão que ele toma ou apoia (sugestão revisada versus decisão automática sobre pessoa) e a dependência operacional do processo de negócio em relação a esse fornecedor.
O que perguntar num questionário de due diligence de fornecedor de IA?
No mínimo: onde o dado é processado e armazenado (incluindo subprocessadores e transferência internacional), se o fornecedor treina ou ajusta modelo com o dado da empresa e sob qual base legal, e como funciona o processo de notificação de incidente, com prazo definido.
Que cláusulas contratuais um fornecedor de IA de alto risco deveria ter?
Vedação (ou autorização revogável) ao uso do dado para treinar o modelo do fornecedor, titularidade e indenização sobre o output gerado, prazo definido de notificação de incidente, direito de auditoria e cláusula de descontinuação com portabilidade de dado.
Due diligence de fornecedor de IA é feita só uma vez, na contratação?
Não. O NIST AI RMF trata monitoramento de fornecedor como parte da manutenção contínua do sistema, não como etapa única. Reavaliação periódica (anual ou semestral, conforme criticidade) e reavaliação fora do ciclo sempre que o fornecedor muda de produto, subprocessador ou reporta incidente são parte do processo, não exceção.
Quem deve liderar a gestão de risco de fornecedores de IA na empresa?
Procurement aplica a classificação antes da contratação avançar; compliance mantém o registro e a trilha de reavaliação; jurídico negocia as cláusulas; segurança da informação avalia certificações e arquitetura técnica; e a área de negócio solicitante declara o caso de uso real. Fornecedor de criticidade alta não deveria ser decisão de uma única área.
Conclusão: fornecedor de IA é extensão do seu perímetro de risco, não do seu controle
A empresa que contrata um fornecedor de IA herda o risco desse fornecedor sem herdar o controle sobre como ele opera — o que só funciona se a due diligence, a classificação por criticidade e o monitoramento contínuo estiverem no lugar antes da primeira integração, não depois do primeiro incidente. Classificar, exigir evidência proporcional ao risco e amarrar tudo isso a cláusula contratual clara é o que transforma "confiamos no fornecedor" em "temos prova de que o fornecedor é confiável".
Se sua empresa está formalizando a gestão de risco de fornecedores de IA — ou percebeu, ao ler este guia, que boa parte dos fornecedores em uso nunca passou por esse processo —, o diagnóstico gratuito da Jetpacks mapeia, em uma conversa de 30 a 45 minutos, os fornecedores de IA já em uso e o nível de maturidade atual da due diligence, e o método Flight Plan desenha o processo de classificação e aprovação do tamanho certo para o porte da sua empresa.
Descubra onde a IA gera mais resultado na sua empresa.
Comece com um diagnóstico gratuito: mapa de impacto por área e o desenho de um primeiro piloto medível, sem compromisso.