Avaliação de riscos de fornecedores de IA: questionário, modelo de pontuação e checklist de evidências (2026)
A avaliação de riscos de fornecedores de IA é a análise que você faz antes de um produto ou uma API de IA de terceiros acessar seus dados: você classifica o risco do caso de uso, faz perguntas específicas sobre IA (treinamento com seus dados, retenção, suboperadores e provedores de modelos, testes de segurança, riscos das respostas, regulamentação), coleta evidências para cada resposta, atribui uma pontuação ao fornecedor e define os termos contratuais e o monitoramento. A diferença em relação a uma análise convencional de fornecedores é que os fornecedores de IA acrescentam o comportamento dos modelos, a reutilização de dados e uma cadeia de provedores de modelos envolvidos no processamento. Este guia traz um questionário pronto para uso, um modelo de pontuação e um checklist de evidências, atualizados em 26 de outubro de 2026.
O conteúdo foi escrito para equipes de segurança, compras e plataforma que aprovam APIs de IA, gateways de IA e ferramentas SaaS com recursos de IA. Não constitui orientação jurídica.
Por que o risco de fornecedores de IA é diferente
Uma análise tradicional de terceiros pergunta sobre controle de acesso, criptografia, disponibilidade e certificações. Para fornecedores de IA, é preciso verificar tudo isso e também:
| Novo risco | Por que importa | Exemplo de pergunta |
|---|---|---|
| Reutilização de dados para treinamento | Seus prompts podem melhorar um modelo usado por outras pessoas | Os dados dos clientes são usados para treinamento ou avaliação por padrão? |
| Quartas partes | O fornecedor pode encaminhar dados a provedores de modelos | Quais provedores de modelos processam nossos dados e em quais regiões? |
| Comportamento do modelo | As respostas podem estar erradas, ser inseguras ou vazar dados | Como o sistema é testado contra injeção de prompt e vazamento de dados? |
| Mudanças rápidas | Modelos e versões mudam sem aviso | Como as mudanças de modelo são anunciadas e versionadas? |
| Regulamentação | A Lei de IA da UE e as regras setoriais acrescentam obrigações | Como vocês classificam este sistema segundo a Lei de IA da UE? |
| Exposição a custos | Os custos podem disparar com a cobrança por uso | Há cotas, limites de gastos e alertas? |
O NIST AI Risk Management Framework aborda explicitamente os riscos de IA de terceiros nas funções Govern e Map, e o Perfil de IA Generativa do NIST (AI 600-1) lista os riscos da cadeia de valor e da integração de componentes entre os riscos de IA generativa.
Etapa 1: Classifique o fornecedor por caso de uso
Nem toda ferramenta de IA exige o mesmo nível de análise. Primeiro, classifique o risco; depois, ajuste a abrangência do questionário.
| Nível | Critérios | Profundidade da análise |
|---|---|---|
| Nível 1 (alto) | Dados de clientes, dados pessoais, dados sujeitos a regulamentação ou IA que executa ações (envia, paga, altera registros) | Questionário completo, evidências, testes de segurança, análise jurídica |
| Nível 2 (médio) | Dados internos, com revisão humana de todas as respostas | Questionário essencial + principais evidências |
| Nível 3 (baixo) | Apenas dados públicos, sem integração | Formulário resumido + análise dos termos |
Registre o nível e a justificativa na documentação do fornecedor. Reclassifique quando o caso de uso mudar.
Etapa 2: Envie o questionário de riscos de fornecedores de IA
Use estas perguntas como complemento ao seu questionário padrão de segurança (por exemplo, o Shared Assessments SIG ou a Matriz de Controles de IA da CSA).
Tratamento de dados e privacidade
- Nossos dados (prompts, arquivos, respostas) são usados para treinar ou avaliar algum modelo? Qual é a configuração padrão? Há opção de desativação ou compromisso contratual?
- Por quanto tempo prompts, respostas e logs são retidos? Podemos configurar retenção zero ou um prazo curto?
- Onde os dados são processados e armazenados (regiões)? Podemos fixar uma região?
- Quais suboperadores e provedores de modelos recebem nossos dados? Como somos notificados sobre mudanças?
- Há um acordo de tratamento de dados (DPA) disponível? Ele abrange o processamento por IA e as transferências internacionais?
Governança de modelos e sistemas
- Quais modelos são usados no produto? São próprios ou de terceiros?
- Como as mudanças de modelo ou versão são comunicadas e testadas?
- Quais avaliações de precisão, viés e segurança vocês realizam? Podem compartilhar os resultados?
- Vocês têm documentação sobre o uso pretendido e as limitações conhecidas (fichas de modelo ou de sistema)?
Segurança
- Quais certificações ou atestações abrangem o serviço de IA (SOC 2 Type II, ISO 27001, ISO 42001)? O produto de IA está no escopo?
- Como vocês testam injeção de prompt, vazamento de dados e autonomia excessiva (por exemplo, com base no OWASP Top 10 para Aplicações com LLM)?
- Como as chaves de API são emitidas, têm seu escopo definido, são rotacionadas e revogadas?
- O que os logs contêm, quem pode acessá-los e podemos exportá-los?
- Qual é o processo de resposta a incidentes e o prazo de notificação para incidentes relacionados à IA?
Operações e custos
- Qual é o SLA? Ele abrange os recursos de IA e os provedores de modelos dos quais o serviço depende?
- O que acontece quando um provedor de modelos fica indisponível: há alternativa de contingência, operação degradada ou falha?
- Há cotas por chave, limites de gastos e alertas de uso?
- Quais são as condições de encerramento: exportação de dados, confirmação de exclusão, prazos de aviso prévio?
Regulamentação
- Como vocês classificam o sistema segundo a Lei de IA da UE e quais obrigações cumprem como fornecedor ou no apoio a quem implanta o sistema? O cronograma de implementação atualmente indica que os requisitos para sistemas de alto risco do Anexo III passam a valer em 2 de dezembro de 2027.
- As respostas incluem avisos ou marcações de conteúdo gerado por IA quando exigidos?
Etapa 3: Colete evidências, não apenas respostas
Cada "sim" em uma análise de Nível 1 deve remeter a algo que você possa arquivar.
| Resposta | Evidências a solicitar | O que verificar |
|---|---|---|
| "Não treinamos com seus dados" | Cláusula contratual, DPA, documentação da configuração do produto | Padrão ou desativação opcional; abrange também os suboperadores |
| "Os dados são retidos por 30 dias" | Política de retenção, captura de tela da configuração administrativa | Aplica-se a logs e backups |
| "SOC 2 Type II" | Relatório sob NDA, carta de atualização de cobertura | Serviço de IA no escopo; data final do período; exceções |
| "Testamos injeção de prompt" | Resumo dos testes ou relatório de teste de invasão | Data, escopo, achados, novo teste |
| "Cotas por chave" | Documentação ou captura de tela do console; seu próprio teste | Os limites realmente bloqueiam requisições |
| "Provedores de modelos listados" | Lista de suboperadores com regiões | Atende às suas necessidades de residência de dados |
Um certificado é uma evidência para triagem, não uma prova de que seu caso de uso é seguro. Para evidências específicas de gateways, consulte evidências SOC 2 para um gateway de API de IA, o checklist de DPA para gateways de IA e o checklist de retenção de dados de APIs de IA.
Etapa 4: Pontue o fornecedor
Atribua uma pontuação de 1-5 a cada área (5 = sólida, com evidências) e defina os pesos conforme o que importa para seu caso de uso:
| Área | Peso (exemplo de Nível 1) | Pontuação 1 | Pontuação 5 |
|---|---|---|---|
| Uso e retenção de dados | 25% | Treina com os dados por padrão, retenção indefinida | Sem treinamento, retenção configurável, garantia contratual |
| Segurança e testes | 25% | Sem testes específicos de IA | Evidências recentes de testes, com novo teste de verificação |
| Quartas partes e residência de dados | 15% | Provedores de modelos desconhecidos | Lista completa, regiões, aviso de mudanças |
| Governança e mudanças | 15% | Mudanças de modelo sem aviso | Versionadas, anunciadas, avaliadas |
| Operações e controles de custos | 10% | Sem SLA, sem cotas | SLA, contingência, cotas, limites |
| Preparação regulatória | 10% | Sem posicionamento | Classificação e obrigações documentadas |
Um script simples de pontuação que você pode guardar junto à documentação do fornecedor:
WEIGHTS = {"data": .25, "security": .25, "fourth_parties": .15,
"governance": .15, "operations": .10, "regulatory": .10}
def vendor_score(scores: dict, evidence: dict) -> dict:
"""scores: 1-5 per domain; evidence: True if the score is backed by filed evidence"""
capped = {d: (s if evidence.get(d) else min(s, 2)) for d, s in scores.items()} # no evidence -> max 2
total = sum(WEIGHTS[d] * capped[d] for d in WEIGHTS)
decision = "approve" if total >= 4 else "approve with conditions" if total >= 3 else "reject or escalate"
return {"score": round(total, 2), "decision": decision, "capped": capped}
print(vendor_score(
{"data": 5, "security": 4, "fourth_parties": 4, "governance": 3, "operations": 4, "regulatory": 3},
{"data": True, "security": True, "fourth_parties": True, "governance": False, "operations": True, "regulatory": False},
))
A regra de limite de pontuação importa: uma alegação sem comprovação nunca deve receber a mesma pontuação que uma alegação verificada por testes.
Etapa 5: Verifique por conta própria as alegações de maior risco
Para fornecedores de Nível 1, faça alguns testes em um ambiente isolado antes de assinar:
- Revogação de chaves: revogue uma chave de teste e confirme que as requisições falham imediatamente.
- Cotas: defina uma cota baixa e confirme que as requisições são bloqueadas quando ela é atingida.
- Lista de modelos permitidos: faça uma chamada a um modelo que não deveria ser permitido e confirme que ela é negada.
- Conteúdo dos logs: verifique o que um log de requisição armazena (apenas metadados ou o prompt completo).
# After revoking the test key in the vendor console, this should return 401
curl -s -o /dev/null -w "%{http_code}\n" https://api.vendor.example/v1/chat/completions \
-H "Authorization: Bearer $REVOKED_TEST_KEY" -H "Content-Type: application/json" \
-d '{"model":"any-model","messages":[{"role":"user","content":"ping"}]}'
Um questionário informa o que o fornecedor afirma; esses testes verificam diretamente algumas dessas alegações. Um teste de segurança completo da sua própria aplicação de IA é um trabalho separado, abordado em nosso guia de auditoria de segurança de IA.
Etapa 6: Inclua os controles no contrato
| Cláusula | Motivo |
|---|---|
| Proibição de treinamento com dados de clientes (inclusive por suboperadores) | Impede a reutilização de dados |
| Limite de retenção e exclusão no encerramento | Limita a exposição |
| Aviso de mudança de suboperadores e provedores de modelos | Permite contestar novas quartas partes |
| Prazo de notificação de violações e incidentes de IA | Agiliza a resposta |
| Direitos de auditoria e de acesso a evidências | Permite verificar novamente as alegações |
| SLA que abranja os recursos de IA | Permite exigir o cumprimento da disponibilidade |
| Residência de dados | Atende às regras de transferência |
Etapa 7: Monitore após a aprovação
- Reavalie os fornecedores de Nível 1 anualmente e quando o fornecedor mudar modelos, suboperadores ou termos.
- Acompanhe o uso e o custo por fornecedor e por chave.
- Acompanhe incidentes e avisos de segurança.
- Mantenha uma lista de modelos aprovados para que novos modelos passem por análise (fluxo de aprovação de modelos de IA).
Avaliação de um gateway de API de IA como fornecedor
Um gateway fica entre suas aplicações e vários provedores de modelos. Por isso, avalie as duas camadas: o próprio gateway (chaves, logs, cotas, faturamento, suporte) e cada provedor para o qual ele encaminha requisições. Solicite a lista de rotas e a indicação de quais provedores recebem quais dados. Com a Flatkey, por exemplo, você pode consultar modelo, tokens, custo e chave de cada requisição no painel de uso, exportar logs como CSV/JSON para servir de evidência e criar ou revogar chaves por ambiente no gerenciamento de chaves de API. Guarde essas exportações na documentação de compras, junto ao questionário. Nosso pacote de evidências para contratação de gateways de IA lista o conjunto completo, e a análise de evidências de provedores de modelos aborda os provedores dos quais o gateway depende.
Perguntas frequentes
O que é uma avaliação de riscos de fornecedores de IA?
É uma análise estruturada de um produto ou uma API de IA de terceiros que verifica uso de dados, segurança, provedores de modelos que atuam como quartas partes, governança, operações e preparação regulatória antes da aprovação, com respaldo em evidências e uma pontuação de risco.
Quais perguntas devem constar em um questionário para fornecedores de IA?
No mínimo: se seus dados são usados para treinar modelos, retenção, regiões de processamento, suboperadores e provedores de modelos, certificações que abrangem o serviço de IA, testes de segurança específicos de IA, controles de chaves e logs, SLA e contingência, controles de custos, condições de encerramento e classificação segundo a Lei de IA da UE.
Como a gestão de riscos de fornecedores de IA difere da gestão convencional de riscos de terceiros (TPRM)?
A IA acrescenta a reutilização de dados para treinamento, provedores de modelos que atuam como quartas partes, respostas imprevisíveis dos modelos, mudanças frequentes de modelos e regulamentação específica de IA. Os controles padrão de TPRM continuam se aplicando.
A IA pode ajudar na gestão de riscos de fornecedores?
Sim, ferramentas de IA podem resumir questionários e apontar evidências ausentes, mas uma pessoa deve tomar a decisão de aprovação e verificar as evidências, especialmente para fornecedores de Nível 1.
Um relatório SOC 2 é suficiente para aprovar um fornecedor de IA?
Não. Verifique se o serviço de IA está coberto pelo escopo e pelo período do relatório e, ainda assim, faça perguntas específicas sobre IA relacionadas a treinamento, retenção, provedores de modelos e testes. A visão geral de SOC 2 da AICPA explica o que um relatório SOC 2 abrange.
Quais referenciais ajudam a avaliar o risco de fornecedores de IA?
O NIST AI RMF e seu Perfil de IA Generativa, o OWASP LLM Top 10 para riscos técnicos, a Matriz de Controles de IA da CSA, a ISO/IEC 42001 para sistemas de gestão de IA e o questionário Shared Assessments SIG.
Fontes
Verificadas em 26 de outubro de 2026: NIST AI RMF, NIST AI 600-1, OWASP Top 10 para Aplicações com LLM, Matriz de Controles de IA da CSA, Shared Assessments SIG, cronograma da Lei de IA da UE, checklist de GDPR para gateways de API de IA.
