Avaliação de fornecedores de IA: as doze perguntas em falta

O essencial

• A avaliação de fornecedores foi concebida para uma cadeia de fornecimento que entregava software imutável. Comprova que um fornecedor é solvente, está segurado e certificado, mas nada diz sobre os dados com que um modelo foi treinado nem sobre a forma como este mudará depois da assinatura.
• O artigo 25.º, n.º 4 do Regulamento da IA transforma essa verificação numa obrigação jurídica quando o sistema é de risco elevado. Um acordo escrito tem de precisar a informação, as capacidades e o acesso técnico necessários.
• O artigo 25.º, n.º 1 encerra a armadilha que quase nenhum comprador pondera: apor a sua marca, modificar substancialmente o sistema ou alterar a sua finalidade transforma-o em prestador.
• A norma ISO/IEC 42001 (A.10.3) e o NIST AI RMF (GOVERN 6.1) convergem num princípio: a responsabilidade não se transfere para o fornecedor.
• O evento que deve fazer recomeçar a revisão não é o aniversário do contrato, mas a mudança de versão do modelo.

O que abrange hoje a avaliação de fornecedores

Pergunte a qualquer plataforma de risco de terceiros o que deve constar de uma revisão e obterá uma resposta notávelmente uniforme. A avaliação de fornecedores designa o processo pré-contratual através do qual se verifica se a um terceiro pode ser confiada uma função de negócio. A grelha habitual organiza-se em seis ou sete rúbricas: estrutura jurídica e societária, beneficiários efetivos, solidez financeira, certificações de segurança e privacidade do tipo SOC 2 ou ISO/IEC 27001, resiliência operacional e continuidade de negócio e, por fim, rastreio regulatório quanto a sanções, litigância e imprensa desfavorável. Os programas maduros começam por escalonar os fornecedores segundo a criticidade, de modo que uma entidade que processa salários seja examinada com mais profundidade do que um fornecedor de material de escritório. Depois reúnem as evidências, confrontam-nas com um apetite pelo risco definido e fixam uma periodicidade de revisão logo no início da relação. Nada disto está errado. Trata-se de um processo sólido, apurado por vinte anos de subcontratação, e continua a ser o alicerce de qualquer programa de governação da IA. O problema é mais circunscrito: cada uma dessas rúbricas descreve a empresa a quem compra. Nenhuma descreve o modelo que compra.

Avaliação de fornecedores e due diligence comercial

A confusão entre os dois conceitos é suficientemente frequente para justificar uma separação. A due diligence comercial averigua se o mercado, a carteira de clientes e as receitas de uma sociedade justificam uma avaliação financeira, e pertence ao mundo das operações de aquisição. A avaliação de fornecedores averigua se um fornecedor consegue prestar um serviço sem introduzir na sua organização um risco inaceitável. No léxico transacional, a expressão inglesa vendor due diligence designa ainda um relatório que o vendedor encomenda sobre si próprio para acelerar uma alienação. Nestas páginas o termo tem o primeiro sentido: é o leitor que compra, e é o fornecedor que lhe entrega um sistema de IA.

Porque falha a lista de verificação habitual perante um fornecedor de IA

Um relatório SOC 2 de tipo II é a opinião de um auditor segundo a qual uma empresa aplicou, durante um período, os controlos que declarou. Diz-lhe que as instalações estão fechadas, que os acessos são revistos e que as cópias de segurança são testadas. Não lhe diz com que dados o modelo foi treinado, se esses dados estavam licenciados, sobre que populações o modelo foi avaliado, nem o que mudou no seu comportamento na última versão. São questões de outra natureza sobre outro objeto, e o questionário habitual não as coloca. Quatro propriedades dos fornecedores de IA desmontam a revisão tradicional. O produto não é determinístico. O software convencional devolve o mesmo resultado perante a mesma entrada, pelo que um teste pontual basta para caracterizar o seu comportamento. Um modelo de IA não oferece essa garantia. A prova de que um sistema se comportou adequadamente durante um piloto tem, por isso, menor valor probatório do que o mesmo resultado numa ferramenta determinística, e uma revisão construída em torno de uma aceitação pontual sobrestima em silêncio aquilo que demonstrou. O produto muda sem que o contrato mude. Os fornecedores retreinam, substituem o modelo de base e ajustam continuamente as instruções de sistema. Um sistema aprovado em março pode comportar-se de forma sensivelmente diferente em junho, sem adenda, sem pré-aviso e sem nova certificação. A compra tradicional não prevê um evento destes, porque o software clássico saía em versões anunciadas num roteiro visível. A cadeia vai mais longe do que o seu registo. O seu fornecedor é muitas vezes uma camada aplicacional fina assente no modelo de base de um terceiro, por sua vez servido por um quarto operador. A exposição a subcontratados não é nova, mas na IA é o subcontratado que determina o comportamento daquilo que comprou, e não apenas a sua disponibilidade. A maioria dos registos de fornecedores fica-se pela contraparte direta. A transparência esbarra no segredo comercial. O NIST observa que os fornecedores recusam com regularidade divulgar a composição dos dados de treino, a arquitetura ou os resultados das avaliações, invocando confidencialidade comercial, e que o GOVERN 6.1, o controlo relativo a terceiros, figura entre os que mais frequentemente não passam auditorias independentes. Essa recusa constitui em si mesma uma constatação, e uma revisão que trate «o fornecedor não respondeu» como um campo vazio em vez de uma classificação de risco não está a cumprir a sua função. Há uma quinta dificuldade que escapa por completo ao questionário. Os fornecedores acrescentam funcionalidades de IA a ferramentas que a organização já tem contratadas, pelo que a IA entra por uma renovação e não por uma aquisição. É o rosto contratual do shadow AI, e nenhum rigor pré-contratual o deteta se nada reabrir o processo.

A obrigação legal que quase nenhum comprador pondera: o artigo 25.º do Regulamento da IA

A literatura do setor apresenta o exame de fornecedores como prudente gestão do risco. Para uma parte considerável das aplicações europeias trata-se já de uma obrigação jurídica ancorada num preceito concreto, o que altera tanto a urgência como a natureza das provas a conservar.

A exigência de acordo escrito

O artigo 25.º, n.º 4 determina que o prestador de um sistema de IA de risco elevado e o terceiro que fornece um sistema, ferramentas, serviços, componentes ou processos utilizados ou integrados nesse sistema especificam, mediante acordo escrito, a informação, as capacidades, o acesso técnico e demais assistência necessários ao cumprimento do regulamento, com base no estado da arte geralmente reconhecido. Este preceito deve ser lido como uma instrução de compras. Se constrói ou coloca no mercado um sistema de risco elevado e uma parte dele provém do exterior, o fluxo de informação correspondente tem de ficar vertido no contrato. Não basta a garantia verbal de um engenheiro de pré-venda, nem um questionário preenchido que repousa numa pasta partilhada. A obrigação consiste em ter acordado por escrito, antes de precisar, o que o fornecedor lhe comunicará e que acesso lhe franqueará.

Quando o comprador passa a prestador

O artigo 25.º, n.º 1 é o preceito que converte uma decisão de compra num compromisso de conformidade. Um distribuidor, um importador, um responsável pela implementação ou qualquer outro terceiro é considerado prestador de um sistema de risco elevado, ficando sujeito às obrigações do artigo 16.º, em três situações: quando apõe o seu nome ou marca num sistema de risco elevado já colocado no mercado, quando lhe introduz uma modificação substancial, ou quando altera a finalidade prevista de um sistema não classificado como de risco elevado de modo que este passe a sê-lo. Cada uma destas hipóteses descreve uma prática corrente que ninguém percebe como ato regulatório. Comercializar em marca branca uma solução adquirida cabe na alínea a). Um ajuste fino sobre dados próprios levado ao ponto de sair do perímetro da avaliação de conformidade inicial cabe na alínea b). Reorientar uma ferramenta genérica de triagem para decisões de contratação cabe na alínea c). O artigo 3.º, ponto 23 define modificação substancial como uma alteração não prevista nem planeada na avaliação de conformidade inicial, em resultado da qual fica afetada a conformidade com os requisitos do capítulo III, secção 2, ou fica alterada a finalidade prevista. Para os modelos de fins gerais, as orientações da Comissão oferecem uma referência quantitativa indicativa: um ajuste que empregue mais de cerca de um terço da capacidade de cálculo do treino original aponta no sentido de o interveniente a jusante assumir as obrigações de prestador sobre o modelo modificado. O nosso guia operacional do Regulamento da IA detalha como estas obrigações a montante se cruzam com as suas. Na prática, disto decorre uma pergunta que deve constar do questionário: tencionamos modificar este sistema? A resposta determina que regime de obrigações está a comprar. Os trabalhos académicos sobre sistemas agênticos, entre eles AI Agents Under EU Law, assinalam que a deriva comportamental em execução se concilia mal com a fronteira traçada pelo artigo 3.º, ponto 23, uma vez que um sistema que altera o seu próprio comportamento após a colocação em serviço pode atravessar uma linha que os redatores imaginavam atravessada deliberadamente por uma pessoa.

O que lhe deve o prestador inicial

A obrigação não é unidirecional. O artigo 25.º, n.º 2 impõe ao prestador inicial cooperar estreitamente com qualquer novo prestador, disponibilizando a informação necessária e o acesso técnico e a assistência razoavelmente expectáveis para que este cumpra as suas obrigações, em especial quanto à avaliação de conformidade. Se o contrato do seu fornecedor exclui liminarmente essa cooperação, a cláusula entra em tensão com o regulamento: é legítimo suscitá-la em negociação em vez de a aceitar como fórmula de estilo.

O que exigem a ISO 42001, o NIST AI RMF e o DORA à avaliação de fornecedores

Três referenciais abordam a gestão de fornecedores por vias distintas, e uma avaliação que satisfaça os três é defensável na maioria dos ordenamentos.

ISO/IEC 42001: a responsabilidade não se transfere

O controlo A.10 do anexo A regula as relações com terceiros e com clientes. O controlo A.10.2 exige repartir com clareza papéis e responsabilidades por todas as partes externas que intervêm no ciclo de vida do sistema de IA, desde os fornecedores de dados e os criadores de modelos até aos operadores de plataforma e integradores, para que nenhuma obrigação caia no intervalo entre duas organizações convencidas, cada uma, de que a outra tratava do assunto. O controlo A.10.3 exige uma gestão ativa dos fornecedores de IA, para que modelos, conjuntos de dados e componentes adquiridos se mantenham alinhados com os seus objetivos de IA responsável, com evidência dada por avaliações de fornecedores e cláusulas contratuais sobre transparência e enviesamento. O princípio que sustenta ambos os controlos pesa mais do que a sua letra: a responsabilidade não se transfere. Continua a responder pelo resultado mesmo quando foi um fornecedor a causá-lo. A nossa apresentação da ISO 42001 situa o anexo A no sistema de gestão no seu conjunto.

NIST AI RMF: o controlo que faz falhar as auditorias

A função GOVERN 6 trata os riscos decorrentes de software, dados e cadeias de fornecimento de terceiros. O controlo GOVERN 6.1 estende a sua governação aos modelos de fornecedores, às interfaces de programação externas, aos conjuntos de dados pré-treinados e aos componentes de código aberto, e afirma sem ambiguidade que a exposição jurídica por violação de propriedade intelectual, por dados de treino protegidos por direitos de autor e por lesões da privacidade incorporadas num modelo de terceiros permanece na organização que o utiliza. O controlo GOVERN 6.2 exige processos de contingência para a falha de um terceiro, incluindo soluções alternativas e critérios de desativação. O nosso guia do NIST AI RMF apresenta a arquitetura completa.

DORA: o registo e as cláusulas obrigatórias

As entidades financeiras suportam uma camada adicional. O regulamento DORA, aplicável desde 17 de janeiro de 2025, impõe nos artigos 28.º a 30.º um registo de informação sobre todos os acordos contratuais com prestadores terceiros de serviços de TIC, distinguindo os que suportam funções críticas ou importantes dos restantes. O artigo 30.º prescreve as cláusulas que devem constar desses contratos: descrição do serviço e níveis de desempenho, localização dos dados, notificação de alterações, direitos de auditoria, comunicação de incidentes, continuidade de negócio e direitos de resolução. Os fornecedores de IA e de grandes modelos de linguagem podem ficar dentro do perímetro na qualidade de prestadores terceiros de serviços de TIC. Em novembro de 2025, as autoridades europeias de supervisão designaram os primeiros dezanove prestadores terceiros críticos, uma lista dominada pelas plataformas de nuvem sobre as quais assenta a maioria dos serviços de IA. Em Portugal, o Banco de Portugal transmite estas expectativas às instituições supervisionadas, enquanto a CNPD cobre a vertente dos dados pessoais.

As doze perguntas de IA a acrescentar ao seu questionário de avaliação de fornecedores

Estas perguntas juntam-se às suas secções atuais de segurança, solidez financeira e continuidade, sem as substituir. Em cada uma importa a evidência esperada e não a resposta em si. A articulação que se segue retoma a do guia de licença aberta AI Vendor Security and Safety Assessment Guide, de Dennis Ah-king, pensado para se enxertar num processo de risco de terceiros já existente.

Proveniência e dados

1. Com que dados foi o modelo treinado e ao abrigo de que licença? Espere uma declaração documentada que identifique fontes e base jurídica. «Dados publicamente disponíveis» não é uma resposta. 2. Os nossos dados treinam os vossos modelos, por defeito ou por opção? Espere um compromisso contratual e não a captura de um ecrã de configuração. Confirme se o valor por defeito muda na renovação. 3. Que subcontratados e que fornecedores de modelos operam por trás deste serviço? Espere uma lista nominativa acompanhada de um compromisso de notificação. Se o fornecedor revende um modelo de base, também lhe dizem respeito as condições do fornecedor a montante.

Comportamento do modelo e alterações

4. Que avaliações foram realizadas, sobre que populações e com que resultados? Espere relatórios com resultados desagregados. Uma exatidão agregada esconde precisamente os modos de falha que geram exposição jurídica. 5. Como nos notificarão de uma mudança de versão do modelo e com que antecedência? Espere um prazo e um canal definidos. É a resposta mais valiosa de toda a lista. 6. Como detetam e comunicam a degradação do desempenho após a colocação em serviço? Espere uma monitorização cujos resultados o leitor veja, de preferência um indicador que receba em vez de um painel que eles consultam. 7. Qual é a finalidade prevista do sistema segundo a vossa própria avaliação? Espere uma declaração escrita. Uma utilização prevista que dela se afaste é o caminho mais rápido para as obrigações de prestador.

Cadeia e dependências

8. Este sistema está classificado como de risco elevado ao abrigo do Regulamento da IA e com que fundamento? Espere uma classificação fundamentada. Uma divergência neste ponto deve ser resolvida antes da assinatura. 9. Se ajustarmos o modelo ou lhe apusermos a nossa marca, como muda a repartição de responsabilidades? Espere uma resposta que trate expressamente do artigo 25.º. Um fornecedor que não tenha pensado no assunto já lhe está a dizer alguma coisa. 10. Que documentação técnica irão fornecer e será mantida atualizada? Espere um compromisso alinhado com aquilo que o leitor deve à sua própria autoridade. O nosso guia sobre a documentação de sistemas de IA fixa o mínimo exigível.

Provas e saída

11. De que direitos de auditoria dispomos e alcançam o vosso fornecedor de modelos? Espere direitos que atravessem a fronteira do subcontratado, porque é aí que o comportamento é realmente determinado. 12. Na cessação, o que acontece aos nossos dados, aos pesos ajustados e às representações vetoriais? Espere um compromisso de eliminação que abranja os artefactos derivados e não apenas os registos de origem. Quando um fornecedor recusa responder, registe a recusa, classifique o risco residual e encaminhe-o para quem tem o poder de o aceitar. Uma pergunta declinada é um resultado.

As cláusulas contratuais que tornam as respostas exigíveis

As respostas de um questionário não vinculam ninguém. As cláusulas que as convertem em obrigações são justamente as que mais faltam aos contratos de IA, porque um contrato de software genérico não foi redigido para um produto não determinístico. Os guias dirigidos aos juristas que negoceiam com fornecedores de IA identificam invariavelmente o mesmo conjunto: restrições ao uso dos dados do cliente para fins de treino, titularidade e licenciamento das saídas do modelo, direitos de notificação e aprovação sobre alterações do modelo, consentimento quanto a subcontratados e fornecedores de modelos, direitos de auditoria que alcancem o fornecedor a montante, obrigações de teste e correção do enviesamento, níveis de serviço adaptados a uma saída probabilística e, por fim, disposições de saída que desfaçam pesos ajustados e representações vetoriais, e não apenas os registos armazenados. Duas merecem destaque. As cláusulas de alteração unilateral, correntes nos contratos de software, ganham outro alcance quando o objeto alterado é o próprio modelo. E os limites de responsabilidade fixados em doze mensalidades foram calibrados para interrupções de serviço, não para uma decisão de discriminação nascida de um modelo que o leitor não construiu. O nosso guia de conformidade da IA enquadra estes elementos num plano mais amplo.

Reexame: os eventos que devem reabrir o processo

A maioria dos programas reexamina os fornecedores uma vez por ano, ou na renovação do contrato. Para um fornecedor de IA essa cadência está desalinhada do risco, porque o objeto examinado muda ao ritmo das entregas do fornecedor e não ao do seu calendário de compras. Substitua ou complemente o calendário por eventos desencadeadores:

• Uma mudança de versão do modelo, ou uma mudança do modelo de base subjacente
• A entrada na cadeia de um novo subcontratado ou fornecedor de modelos
• Um alargamento de capacidades, sobretudo quando abre ao sistema novas ações ou novas ferramentas
• Uma alteração da finalidade declarada, por qualquer das partes
• Qualquer decisão sua de ajustar, marcar ou reorientar o sistema, pois aciona o artigo 25.º, n.º 1
• Um incidente comunicável, no fornecedor ou na sua própria utilização
• Uma deriva medida que ultrapasse um limiar definido no início da relação

Os dois últimos ligam este processo a controlos que talvez já mantenha e que o nosso guia de gestão de riscos de IA descreve. Ligar a revisão de fornecedores a estes sinais, e não a uma data, é o que torna o dispositivo adequado ao comportamento real dos fornecedores de IA.

Perguntas frequentes

Qual a diferença entre diligência devida do cliente e avaliação de fornecedores? A diligência devida do cliente provém do combate ao branqueamento: identidade, beneficiários efetivos e situação perante sanções de um cliente são verificados antes do início da relação, por impulso da regulação financeira. A avaliação de fornecedores percorre o caminho inverso e incide sobre um terceiro de quem passará a depender. Ambas partilham técnicas de rastreio e frequentemente as mesmas bases de dados, o que explica a confusão, mas respondem a perguntas distintas perante autoridades distintas. Qual a diferença entre avaliação de fornecedores e due diligence comercial? A due diligence comercial determina se uma empresa vale o preço que um comprador se prepara para pagar, examinando a posição de mercado, a concentração da carteira e a qualidade das receitas: pertence a uma operação de aquisição. A avaliação de fornecedores determina se um fornecedor consegue prestar o serviço sem introduzir um risco inaceitável nas suas operações, e pertence às compras e à gestão do risco de terceiros. Um relatório SOC 2 é suficiente para um fornecedor de IA? Não. Um relatório SOC 2 é uma opinião sobre se os controlos declarados funcionaram durante um período, em matérias como gestão de acessos, gestão de alterações e monitorização. É útil e nada diz sobre a proveniência dos dados de treino, os resultados das avaliações, os testes de enviesamento ou a gestão de versões do modelo. Considere-o necessário mas não suficiente, e acrescente as perguntas próprias do modelo. Quando é que comprar um sistema de IA nos torna seu prestador? Nos termos do artigo 25.º, n.º 1 do Regulamento da IA, em três situações: apõe o seu nome ou marca num sistema de risco elevado já colocado no mercado, introduz-lhe uma modificação substancial, ou altera a sua finalidade prevista ao ponto de o tornar de risco elevado. Qualquer delas lhe transfere as obrigações de prestador do artigo 16.º, entre elas o sistema de gestão da qualidade, a documentação técnica e a avaliação de conformidade. Com que frequência deve ser reexaminado um fornecedor de IA? Mantenha uma revisão anual para continuidade e solidez financeira e acrescente eventos desencadeadores para tudo o que respeite ao modelo. Uma mudança de versão, um novo subcontratado, um alargamento de capacidades, um incidente ou uma deriva medida devem reabrir o processo independentemente da data do último exame. Reexaminar um fornecedor apenas por calendário significa avaliar um sistema que talvez já não seja aquele que avaliou. O que fazer se um fornecedor recusar divulgar os dados de treino? Registe a recusa como constatação e não como pergunta sem resposta, e classifique em conformidade o risco residual. O NIST trata a não divulgação por segredo comercial como uma característica reconhecida deste mercado e não como uma anomalia. Há normalmente posições aceitáveis por outras vias: uma garantia contratual contra reclamações de propriedade intelectual e privacidade decorrentes dos dados de treino, a certificação de um terceiro, ou uma garantia mais restrita sobre a base jurídica das licenças em vez da divulgação integral.

Conclusão

A disciplina dispõe de um bom processo. Vinte anos de gestão do risco de terceiros produziram uma revisão que apura com fiabilidade se um fornecedor ainda existirá no próximo ano e se a sua rede interna aguenta. Aquilo para que nunca foi concebida é descrever um modelo: de onde vieram os seus dados de treino, como se comporta perante as pessoas que a organização serve e o que mudou nele na semana passada. O artigo 25.º, n.º 4 já transformou essa lacuna numa questão jurídica para as aplicações de risco elevado na Europa, e tanto a ISO/IEC 42001 como o NIST AI RMF chegam ao mesmo ponto pela via da governação e não da lei. O remédio não passa por erguer um programa novo. São doze perguntas a mais, um punhado de cláusulas que tornem as respostas exigíveis e um evento desencadeador que dispare numa mudança de versão em vez de numa data. Para situar a evidência sobre fornecedores num conjunto de controlos mais amplo, comece pelo nosso guia de risco IA.