A resposta rápida: avaliar um fornecedor de IA significa pedir evidências em vez de promessas. Antes de assinar, quer quatro coisas por escrito: resultados de testes independentes que pode verificar, termos claros sobre como os seus dados são usados e mantidos, um compromisso de monitorizar o sistema após go-live, e uma forma de verificar cada afirmação de segurança que o fornecedor faz sem confiar apenas na sua palavra. O resto deste guia transforma isso num processo funcional, uma lista de perguntas que pode enviar aos fornecedores, e os termos contratuais que tornam as respostas vinculativas.

A due diligence de IA difere da avaliação de software comum porque um sistema de IA pode produzir uma resposta confiante mas incorreta, ser desviado das suas próprias regras, vazar dados, ou mudar de comportamento após uma atualização de modelo que o fornecedor coloca numa terça-feira. Encontra esses riscos testando o comportamento, e controla-os com termos contratuais que dizem o que acontece quando o comportamento varia.

Por que a due diligence de fornecedor de IA é agora uma expectativa formal

Comprar IA costumava ser tratado como uma compra de software com um parágrafo extra sobre dados. Os compradores públicos e os legisladores em ambos os lados do Atlântico mudaram isso.

Compradores federais dos EUA: memorando OMB M-25-22

Em 3 de abril de 2025, o Office of Management and Budget da Casa Branca emitiu o memorando M-25-22, Driving Efficient Acquisition of Artificial Intelligence in Government. Aplica-se a contratos adjudicados sob solicitações emitidas 180 dias ou mais após o memorando, e a opções de renovação exercidas após esse ponto. A Seção 4(d) diz que as agências "devem incluir termos que abordem" uma lista de tópicos em contratos para sistemas e serviços de IA. Entre eles:

• Monitorização contínua de desempenho. Os contratos devem permitir que a agência monitore e avalie regularmente o desempenho, riscos e eficácia do sistema, com revisões trimestrais ou semestrais dados como exemplos.
• Testes independentes. As agências devem testar com seus próprios conjuntos de dados que "não devem ser acessíveis ao fornecedor", os fornecedores devem fornecer "o acesso e o tempo necessários para as agências completarem avaliação independente", e os resultados dos testes devem ser "detalhados o suficiente para que os testes sejam verificados de forma independente ou reproduzidos, se viável."
• Proteção contra lock-in. Os termos podem incluir transferência de conhecimento, "portabilidade de dados e modelos", e transparência sobre licenciamento e preços.
• Limites no treinamento com seus dados. A Seção 3(e) exige que os contratos "proíbam permanentemente o uso de dados de entrada não públicos da agência e resultados de saída" para treinar ainda mais IA disponível publicamente ou comercialmente, a menos que a agência consinta explicitamente.
• Notificação antes de mudanças. As agências devem considerar exigir que os fornecedores as notifiquem antes de novas melhorias de IA serem integradas, e são encorajadas a exigir que os fornecedores atendam aos padrões de desempenho antes de implantar novas versões e façam reversão se necessário.

Um segundo memorando, OMB M-26-04 de 11 de dezembro de 2025, diz que "complementa" M-25-22. Para contratos de grandes modelos de linguagem, lista informações que as agências devem solicitar aos fornecedores: uma política de uso aceitável, cartões de modelo, sistema ou dados, recursos para o usuário final e um mecanismo de feedback do usuário final. Também permite que as agências solicitem mais, como resultados de avaliação.

Esses memorandos vinculam apenas agências federais, não empresas privadas. Ainda assim, são o pronunciamento público mais detalhado sobre o que um comprador sofisticado de IA solicita, e equipes de aquisição privadas podem emprestar sua estrutura diretamente.

Implantadores na UE: o que a Lei de IA pede do comprador

A Lei de IA da UE, Regulamento (UE) 2024/1689, chama de "implantador" a organização que utiliza um sistema de IA sob sua própria autoridade. Se você compra um sistema de IA de alto risco e o coloca em funcionamento, o Artigo 26 impõe deveres sobre você, separados dos deveres sobre o fornecedor. No texto consolidado publicado no Serviço de Informações da Lei de IA da Comissão Europeia, o Artigo 26 diz:

• Os implantadores "devem tomar medidas técnicas e organizacionais apropriadas para garantir que usem tais sistemas de acordo com as instruções de uso que acompanham os sistemas" (Artigo 26(1)).
• Os implantadores "devem atribuir supervisão humana a pessoas físicas que possuam a competência, treinamento e autoridade necessários" (Artigo 26(2)).
• Os implantadores "devem monitorar a operação do sistema de IA de alto risco com base nas instruções de uso", e se tiverem razão para pensar que o sistema apresenta um risco, devem informar o fornecedor ou distribuidor e a autoridade de vigilância do mercado relevante e suspender o uso (Artigo 26(5)).
• Os implantadores "devem manter os registros gerados automaticamente por esse sistema de IA de alto risco" na medida em que esses registros estejam sob seu controle, por pelo menos seis meses, a menos que outra lei estabeleça o contrário (Artigo 26(6)).
• Os implantadores de sistemas do Anexo III que tomam ou auxiliam na tomada de decisões sobre pessoas "devem informar às pessoas físicas que estão sujeitas ao uso do sistema de IA de alto risco" (Artigo 26(11)).

Cada um desses deveres depende de algo que você só pode obter do fornecedor. Você não pode seguir instruções de uso que nunca recebeu, manter registros que o sistema não exporta, ou monitorar comportamento que você não tem como medir. O Artigo 13 é o lado do fornecedor do mesmo acordo: sistemas de alto risco devem vir com instruções de uso que incluam, entre outras coisas, "o nível de precisão, incluindo suas métricas, robustez e cibersegurança" (Artigo 13(3)(b)(ii)). A devida diligência é onde você confirma que esses materiais existem e são suficientemente bons para você fazer sua parte.

O tempo é importante. Sob as emendas do Omnibus Digital, o Artigo 113 agora aplica as regras de alto risco a partir de 2 de dezembro de 2027 para sistemas autônomos listados no Anexo III e a partir de 2 de agosto de 2028 para IA incorporada em produtos cobertos pelo Anexo I. Contratos que você assina hoje frequentemente ainda estarão em vigência nessas datas, portanto faz sentido incluir as obrigações agora. Separadamente, o Artigo 4 pede que fornecedores e implantadores de sistemas de IA em geral, não apenas os de alto risco, "tomem medidas para apoiar o desenvolvimento de alfabetização em IA" do pessoal que os opera e utiliza. Para uma visão legal mais ampla, consulte nosso guia completo sobre a Lei de IA da UE e as leis de IA dos EUA.

Os marcos voluntários apontam para o mesmo caminho

O núcleo da NIST AI Risk Management Framework oferece à IA de terceiros sua própria categoria. GOVERN 6.1 diz "Políticas e procedimentos estão em vigor que abordam riscos de IA associados a entidades terceirizadas", GOVERN 6.2 diz "Processos de contingência estão em vigor para lidar com falhas ou incidentes em dados de terceiros ou sistemas de IA considerados de alto risco", e MANAGE 3.1 diz que riscos de recursos terceirizados devem ser "regularmente monitorados, e controles de risco são aplicados e documentados." Se sua organização já se alinha com o NIST AI RMF ou executa um sistema de gestão ISO/IEC 42001, a devida diligência com fornecedores é como você atende a essas expectativas para a IA que você compra. Nosso guia sobre NIST AI RMF, ISO/IEC 42001 e normas relacionadas cobre como os marcos se encaixam.

As seis áreas a avaliar

Toda revisão de fornecedor de IA se resume a seis áreas.

1. O que é o sistema e para que serve

Comece com o escopo. Quais modelos estão por trás do produto, e o fornecedor é seu desenvolvedor ou um revendedor que embrulha modelo de outro? Qual uso pretendido o fornecedor documenta, e seu uso planejado se enquadra nele? De acordo com a Lei de IA da UE, o uso pretendido é o primeiro item que as instruções de uso devem indicar, e usar um sistema fora dele significa assumir riscos que o fornecedor nunca testou.

2. Evidência de comportamento seguro

Esta é a área que a maioria dos compradores lida pior, porque é a mais difícil de perguntar em um questionário. "Você testa viés?" recebe sim de todos. Perguntas melhores perguntam pelo método e pelo resultado: o que foi testado, contra quais cenários, com que taxa de aprovação, por quem e quando. Os riscos comportamentais dignos de cobertura se alinham com os sete pilares do framework A.E.G.I.S.™:

• Hallucination Integrity: o sistema apresenta falsidades como fatos, especialmente sob pressão, ambiguidade ou questionamento específico de domínio?
• Guardrail Resistance: pode ser manipulado para comportamento inseguro através de tentativas de jailbreak ou injeção de prompt?
• Data Handling and Privacy: o que ele coleta, retém e vaza, incluindo dados pessoais?
• Ethical Alignment: ele se comporta apropriadamente com usuários vulneráveis e tópicos sensíveis?
• Autonomy and Control: até que ponto pode agir por conta própria, e um humano pode detê-lo?
• Adversarial Robustness: como se comporta diante de um atacante determinado?
• Explainability & Transparency: é possível compreender e auditar seu comportamento após a execução?

Para saber como cada um desses aspectos é efetivamente testado, consulte como os sistemas de IA são testados para segurança. A distinção fundamental para um comprador é entre resultados que o fornecedor produziu sobre si mesmo e resultados que alguém independente produziu. Os testes internos têm valor, mas representam o fornecedor avaliando seu próprio desempenho. O M-25-22 faz o mesmo ponto sob a perspectiva do comprador quando solicita testes detalhados o suficiente para serem "verificados ou reproduzidos de forma independente".

3. Tratamento de dados

Investigue onde seus dados vão, quanto tempo permanecem lá, quem pode acessá-los e se treinam algo. O padrão federal em M-25-22 é um parâmetro útil: fornecedores podem coletar e reter informações da agência apenas quando "razoavelmente necessário" para o contrato, e entradas e saídas não públicas não podem ser usadas para treinar modelos públicos ou comerciais sem consentimento. Indague também se os registros do sistema estão disponíveis para você, já que os implementadores de sistemas de alto risco da UE devem manter os registros sob seu controle.

4. Supervisão e controle

Descubra o que um operador humano pode fazer quando o sistema erra. Um operador pode revisar ou sobrescrever saídas, ou pausar o sistema? O artigo 26(2) pressupõe que você atribuirá pessoas competentes à supervisão; o fornecedor deve oferecer algo com o qual trabalhar.

5. Gestão de mudanças e monitoramento

Produtos de IA mudam sem seu conhecimento: um novo modelo base ou um retreinamento, e o comportamento que você aprovou deixa de ser o comportamento em produção. Indague como o fornecedor o comunica sobre mudanças materiais, se você pode testar antes de uma nova versão chegar aos seus usuários e se uma versão pode ser revertida. O M-25-22 pede às agências que considerem ou exijam todos os três. Depois, indague qual monitoramento existe após o lançamento e se os resultados são compartilhados com você.

6. Incidentes e responsabilidade

Solicite o processo de resposta a incidentes do fornecedor para falhas específicas de IA, como uma saída prejudicial ou um jailbreak bem-sucedido. Os implementadores de sistemas de alto risco da UE devem informar o fornecedor e a autoridade de vigilância do mercado quando acreditarem que um sistema apresenta risco, portanto seu contrato deve garantir que o fornecedor trabalhará com você quando isso acontecer. Nosso guia sobre incidentes documentados de IA e testes que os capturam mostra os padrões de falha que vale a pena planejar.

Uma lista de perguntas que você pode enviar aos fornecedores de IA

Copie estas em sua solicitação de proposta. Cada uma solicita algo que você pode verificar.

Escopo e propósito

1. Quais modelos alimentam o produto, quem desenvolve cada um e quais versões estão em produção hoje?
2. Qual é o propósito pretendido documentado e há usos que você desaconselha? Compartilhe as instruções de uso ou documentação equivalente.
3. Você publica cartões de modelo, sistema ou dados para o produto? Anexe-os.
4. Qual é sua política de uso aceitável para usuários finais?

Testes e evidências

5. Contra quais riscos de segurança você testou o produto (por exemplo, alucinação, jailbreaks e injeção de prompts, vazamento de privacidade, comportamento com usuários vulneráveis, limites de autonomia, ataque adversarial, explicabilidade)? Para cada um, qual foi o método e o resultado?
6. Algum desses testes foi realizado por uma parte independente? Quem, quando, contra qual versão e podemos verificar o resultado por nós mesmos?
7. Você nos dará acesso e tempo para executar nossa própria avaliação, usando dados de teste que você não vê?
8. Quais são os níveis documentados de precisão, robustez e cibersegurança, e como foram medidos?

Dados

9. Quais dados do nosso uso você coleta e retém, por quanto tempo e por que cada item é necessário?
10. Os nossos dados de entrada ou saída serão utilizados para treinar ou melhorar algum modelo, seu ou de terceiros? Isso pode ser proibido contratualmente?
11. Quais subprocessadores, incluindo fornecedores de modelos, recebem os nossos dados?
12. Quais registos é que o sistema gera, e podemos exportá-los e retê-los?

Controlo, alterações e incidentes

13. Que controlos de supervisão humana e de anulação estão disponíveis para os nossos operadores?
14. Como e quando nos notificarão sobre uma alteração material ao modelo ou ao seu comportamento? Podemos testar uma nova versão antes de chegar aos nossos utilizadores, e podemos reverter a alteração?
15. Como monitorizam o produto após implementação, e partilharão os resultados da monitorização connosco?
16. Qual é o vosso processo de resposta a incidentes para falhas específicas de IA, e quais são os vossos compromissos de notificação para connosco?
17. Se sairmos, como recuperamos os nossos dados e personalizações, e em que formato?

Transformar respostas em termos contratuais

As respostas do questionário são representações. O contrato é onde se tornam obrigações. M-25-22 fornece um modelo para os tópicos, e os compradores privados podem adaptá-lo sem grandes alterações.

• Compromissos de desempenho e segurança. Incorpore o comportamento testado no acordo: os níveis de precisão e segurança documentados, um cronograma de revisão periódica, e o que acontece se os resultados caírem abaixo deles.
• Direito de avaliar. Reserve o direito de fazer os seus próprios testes, ou ter um terceiro independente fazer testes, com acesso e tempo por parte do fornecedor.
• Limites de utilização de dados. Proíba o treino nos seus dados de entrada e saída sem consentimento escrito, limite a retenção ao necessário, e identifique os subprocessadores.
• Notificação de alterações. Exija notificação prévia de alterações materiais do modelo e um período de testes antes de chegarem à produção, com opção de reversão.
• Registos e documentos. Exija que o sistema gere e exporte os registos que necessita, e estabeleça quanto tempo o fornecedor retém os seus próprios.
• Cooperação em incidentes. Estabeleça prazos de notificação para incidentes de IA e uma obrigação de o ajudar a cumprir qualquer dever de comunicação que tenha.
• Portabilidade. Cubra a portabilidade de dados e modelos, transferência de conhecimento e licenciamento transparente para que possa sair se precisar.

M-26-04 acrescenta uma técnica de redação útil: diz às agências que identifiquem certos requisitos como "materiais para elegibilidade e pagamento sob o contrato." Tornar os termos de segurança e transparência materiais dá-lhes força, porque a sua violação torna-se fundamento para recursos em vez de uma nota de rodapé.

Onde a devida diligência costuma falhar

A maioria das revisões falhadas de fornecedores de IA falha de uma entre algumas formas previsíveis.

O questionário é um formulário de segurança com questões de IA coladas. Um relatório SOC 2, na própria descrição da AICPA, é um exame de controlos numa organização prestadora de serviços relevantes para segurança, disponibilidade, integridade de processamento, confidencialidade ou privacidade. Isto é valioso, e responde a uma questão diferente de saber se o modelo pode ser "jailbroken" ou com que frequência inventa factos. Mantenha a segurança da informação e o comportamento de IA como secções separadas com provas separadas.

Todas as respostas são auto-comunicadas. O revisor não tem forma de verificar o formulário ou a política anexa, pelo que o comprador aceita afirmações que não pode verificar ou encomenda testes próprios.

A aprovação é tratada como permanente. Seis meses após a compra o fornecedor alterou o modelo e ninguém re-verificou. Tanto M-25-22 como o NIST AI RMF tratam a monitorização como contínua precisamente por esta razão.

A prova não é comparável entre fornecedores. Três fornecedores descrevem os seus testes de três formas diferentes, pelo que o preço e as funcionalidades decidem por defeito.

Por que uma classificação independente verificável encurta o processo

Os dois últimos problemas são os mais caros. Quando um sistema de IA foi avaliado por uma terceira parte independente contra um framework padrão, três coisas mudam para o comprador.

Primeiro, a evidência é independente. RateAI não tem interesse na classificação de um sistema e suas taxas são vinculadas a marcos de avaliação, não a resultados. Um sistema pode falhar na certificação; quando isso acontece, o desenvolvedor recebe um relatório detalhado de constatações e um caminho de remediação, e pode reingressar na avaliação assim que os problemas forem corrigidos.

Segundo, a evidência é comparável. Cada avaliação A.E.G.I.S.™ classifica os mesmos sete pilares, e os parâmetros de classificação são fixados por uma época de classificação para que as avaliações permaneçam comparáveis ao longo do tempo. Sistemas certificados recebem um scorecard A.E.G.I.S.™ com uma Classificação Geral de Segurança de A (Máxima Segurança) a F (Perigoso), uma nota para cada pilar, e um selo de certificação de A-5 Guardian até A-1 Unrestricted. Seus revisores podem ver em um único lugar onde um sistema é forte e onde cautela é recomendada, e comparar dois fornecedores na mesma escala.

Terceiro, a evidência é verificável e atual. Cada caso de prompt, voto de validador e decisão de certificação é encadeado com hash SHA-256 em uma trilha de auditoria de gravação única, de modo que os registros não podem ser alterados ou backdatados. Qualquer pessoa pode verificar uma certificação RateAI no Registro Público de Segurança sem fazer login, e confirmar que está atual e não foi rebaixada. As certificações também têm um ciclo de recertificação, e mudanças relevantes em um sistema desencadeiam reavaliação, o que fala diretamente ao problema de gerenciamento de mudanças acima.

Uma classificação não substitui sua devida diligência. Você ainda precisa de respostas sobre escopo, termos de contrato, fluxos de dados e adequação ao seu caso de uso, e uma certificação RateAI não é uma determinação legal: ela apoia seu trabalho de conformidade, e as decisões regulatórias permanecem com as autoridades relevantes. Os níveis Pro e Enterprise da RateAI incluem mapeamento de conformidade para a EU AI Act, NIST AI RMF e ISO 42001. O que uma classificação verificável faz é responder as questões de evidência, números 5 a 8 na lista acima, com algo que sua equipe possa verificar em vez de confiar. Para uma análise mais profunda de como funciona a certificação de terceiros, leia o que é certificação de segurança de IA e como funciona.

Um fluxo de trabalho prático de devida diligência

1. Classifique o caso de uso. Quem o sistema afeta, pode agir por conta própria, e poderia ser de alto risco sob a EU AI Act? Maiores riscos significam revisão mais profunda.
2. Envie a lista de perguntas cedo. Inclua-a na RFP para que fornecedores que não conseguem responder desistam antes de você investir tempo em demos.
3. Verifique por evidência independente. Procure o produto do fornecedor em qualquer registro independente em que ele afirme estar listado, e confirme que a classificação, data e versão correspondem ao que você está comprando.
4. Teste o restante. Onde evidência independente estiver faltando ou não cobrir seu caso de uso, execute sua própria avaliação em dados que o fornecedor não viu, ou contrate uma.
5. Negocie os termos. Converta as respostas em obrigações contratuais: desempenho, direitos de teste, uso de dados, aviso de mudança, logging, incidentes e portabilidade.
6. Estabeleça a cadência de monitoramento. Concorde com que frequência você revisará o desempenho e o que dispara uma revisão, como uma mudança de modelo ou um incidente reportado.
7. Registre a decisão. Mantenha a evidência, sua classificação e os motivos para aprovação.

Se você está do lado do fornecedor neste processo, a mesma lista diz o que os compradores vão perguntar. Ter evidência independente pronta antes do questionário chegar encurta cada ciclo de vendas que se segue. Os níveis de certificação e monitoramento da RateAI descrevem como um engajamento é definido em escopo, e um benchmark de segurança gratuito para um agente de IA está disponível como ponto de partida.

Perguntas frequentes

O que é devida diligência de fornecedor de IA?

É o processo de verificar o sistema, práticas de dados e controles do fornecedor de IA antes de comprar, e manter essas verificações atuais depois. Comparado com revisão de software comum, adiciona testes do comportamento do sistema, como alucinação, resistência a jailbreak e vazamento de privacidade.

Um relatório SOC 2 é suficiente para aprovar um fornecedor de IA?

Geralmente não por si só. Um relatório SOC 2 examina os controles de uma organização de serviços relevantes para segurança, disponibilidade, integridade de processamento, confidencialidade ou privacidade, então você ainda precisa de evidência separada sobre como o modelo de IA se comporta, como respostas falsas, manipulação e vazamento de dados através de saídas.

O que a EU AI Act requer de empresas que compram IA?

Organizações que usam sistemas de IA de alto risco são "implementadores" sob o Artigo 26, e devem usar o sistema de acordo com suas instruções, atribuir supervisão humana competente, monitorar sua operação, manter os logs sob seu controle e, em alguns casos, informar as pessoas afetadas. Essas regras de alto risco se aplicam a partir de 2 de dezembro de 2027 para sistemas do Anexo III e 2 de agosto de 2028 para IA incorporada em produtos cobertos pelo Anexo I.

Quais termos de contrato uma compra de IA deve incluir?

No mínimo: compromissos de desempenho e segurança, um direito de teste independente, limites no uso de seus dados para treinamento, aviso prévio e teste de mudanças de modelo, acesso a logs, cooperação em incidentes e portabilidade. O memorando OMB M-25-22 lista a maioria destes como tópicos obrigatórios para contratos de IA federais dos EUA.

Como uma classificação independente de segurança de IA ajuda a aquisição?

Substitui afirmações autodeclaradas por resultados padronizados produzidos por um terceiro e que você pode verificar. Uma classificação A.E.G.I.S.™ avalia um sistema nos mesmos sete pilares que todos os outros sistemas avaliados, permitindo comparar fornecedores e confirmar que a certificação está atual no Registro Público de Segurança.

Uma certificação RateAI torna um sistema de IA legalmente conforme?

Nenhuma certificação pode fazer essa determinação; decisões regulatórias formais continuam sendo responsabilidade das autoridades competentes. A certificação RateAI apoia o trabalho de conformidade, e seus níveis Pro e Enterprise incluem mapeamento de conformidade para a EU AI Act, NIST AI RMF e ISO 42001.

Verifique a classificação de um fornecedor antes de assinar

A pergunta mais rápida de due diligence é se o sistema já foi avaliado independentemente. Pesquise no Registro de Segurança RateAI para ver como sistemas de IA certificados estão listados, com sua classificação A.E.G.I.S.™ e status de certificação, e pergunte aos seus fornecedores se o produto deles consta nele.