Lista de verificação de diligência devida de fornecedores de IA para fundadores e responsáveis de conformidade

Uma lista de verificação de diligência devida de fornecedores de IA deve determinar se um serviço específico, numa configuração específica, é adequado à utilização prevista. Antes da aprovação, documente utilização, fluxos de dados, cadeia de fornecedores, papéis jurídicos, controlos de segurança, testes de desempenho, condições contratuais, supervisão humana e plano de saída. Atribua a cada questão pendente um responsável e uma decisão: resolver antes do lançamento, limitar o piloto, escalar ou rejeitar.

Esta lista é um modelo prático para fundadores e responsáveis de conformidade SaaS, não um questionário legal obrigatório nem uma certificação. Ajuste as provas ao dano possível. Uma ferramenta de escrita com material público exige menos análise do que um sistema que classifica candidatos a emprego ou um agente capaz de alterar contas de clientes. A reputação do fornecedor não demonstra a segurança da sua implementação.

Quando realizar a análise

Comece antes de carregar informações reais de clientes, ligar sistemas de produção ou assumir compromissos vinculativos com clientes. Repita a análise quando um fornecedor existente acrescentar IA, a finalidade mudar, entrarem novos dados, surgir outro modelo ou subcontratante ulterior, ou diminuir a revisão humana. A renovação é um ponto de controlo útil, mas não deve ser o único desencadeador.

Use a lista para serviços de IA adquiridos, API integradas e funções de IA em produtos SaaS comuns. Se a função não usar IA, a avaliação habitual do fornecedor pode bastar. Sem dados pessoais, algumas perguntas de privacidade podem não se aplicar; segurança, confidencialidade, fiabilidade e contrato podem continuar relevantes. Justifique cada resposta «não aplicável».

Para cada ponto registe resposta, ligação às provas, revisor, data e lacunas restantes. Prefira uma cláusula contratual datada, uma exportação da configuração ou um resultado de teste a uma garantia comercial sem reservas.

1. Defina a utilização aprovada e as responsabilidades

• Que tarefa exata executará o serviço e para quem?
• Quem poderá ser afetado por resultados ou ações incorretos?
• Produz rascunhos, recomenda, classifica, decide ou executa ações?
• Quem responde pelo resultado empresarial, configuração técnica e aprovação?
• Que utilizações, categorias de dados e integrações ficam expressamente excluídas?

Escreva um limite aplicável pela engenharia: «Preparar respostas de apoio a partir de artigos aprovados; um trabalhador revê cada resposta; sem alterações de contas». Evite aprovar «IA para apoio» sem limites. Registe o plano contratado e o ambiente, pois uma conta experimental e uma implementação empresarial podem ter condições e controlos diferentes.

Provas a conservar: descrição de utilização de uma página, responsáveis identificados, esquema de arquitetura e lista de utilizações excluídas. Uma responsabilidade por atribuir deve bloquear a aprovação até alguém a assumir.

2. Identifique a cadeia de fornecedores e modelos

Pergunte que entidade jurídica presta o serviço, que modelos utiliza, onde ocorre o tratamento e que outras organizações recebem os dados. Determine se os pedidos podem ser encaminhados para diferentes modelos e se a configuração fixa ou permite essas escolhas.

Peça uma lista atualizada de fornecedores e subcontratantes ulteriores, documentação pertinente, informação disponível sobre modelos e versões e o procedimento de notificação de alterações substanciais. Distinga o que o fornecedor não pode divulgar do que ainda não entregou. Os detalhes em falta devem permanecer como incertezas visíveis, explicando o efeito na aprovação.

Verificação da decisão: consegue identificar organizações e componentes relevantes para o risco proposto? Caso contrário, limite o piloto a material não sensível ou escale. Uma longa lista de logótipos não é um mapa de fluxos de dados.

3. Mapeie o tratamento e as responsabilidades de privacidade

Siga prompts, ficheiros carregados, documentos recuperados, resultados, comentários, acesso do apoio e registos. Pergunte separadamente sobre conservação, apagamento, treino, acesso humano e região de tratamento para cada tipo de dado relevante. «Não treinamos com os seus dados» não explica a duração dos registos de monitorização de abusos nem quem os pode consultar.

Quando o RGPD se aplica, determine os papéis de responsável pelo tratamento e subcontratante para cada atividade. O artigo 28 exige garantias suficientes do subcontratante e contrato conforme; o artigo 35 exige uma AIPD quando o tratamento é suscetível de implicar elevado risco. Considere fundamento jurídico, transparência e capítulo V para transferências internacionais pertinentes. Estas verificações dependem do tratamento real, não da etiqueta «IA». RGPD, artigos 5–6, 13–14, 28, 35 e capítulo V.

Provas a conservar: mapa de fluxos, acordo de tratamento aplicável, definições de conservação, avaliação de transferências quando pertinente e análise documentada da necessidade de AIPD. Teste o apagamento com uma amostra segura em vez de presumir que remover um espaço de trabalho elimina todas as cópias conservadas.

4. Verifique o âmbito do Regulamento da IA e as datas aplicáveis

Registe o papel da organização, a finalidade prevista do sistema e as obrigações pertinentes. Comprar um produto nem sempre torna a organização apenas responsável pela implantação: marca, modificações ou alteração da finalidade podem afetar as responsabilidades. Verifique práticas proibidas e transparência aplicável separadamente da classificação de risco elevado. Regulamento da IA, artigos 3, 5, 6, 25 e 50.

Segundo a verificação de 8 de setembro de 2026, o calendário alterado aplica as principais regras de risco elevado do anexo III desde 2 de dezembro de 2027 e as correspondentes regras relativas a produtos do anexo I desde 2 de agosto de 2028. Não se trata de um adiamento de todas as obrigações do Regulamento da IA. Registe disposições e regras transitórias pertinentes para a implementação. Comissão Europeia: entrada em vigor do Omnibus IA.

Verificação da decisão: peça provas adequadas ao papel e sistema identificados. Uma declaração geral de «conformidade com o Regulamento da IA» não substitui uma avaliação fundamentada do âmbito. Escale a incerteza antes de usar o sistema para decisões com consequências importantes.

5. Verifique a segurança e os limites das integrações

Pergunte como o serviço autentica utilizadores, separa ambientes de clientes, protege segredos, regista acessos e gere vulnerabilidades. Examine âmbito e período de qualquer relatório independente de garantia. Confirme se cobre o serviço de IA e a configuração previstos e analise exceções substanciais.

Enumere individualmente as permissões das ferramentas ligadas. Um assistente que lê artigos de conhecimento não deve receber automaticamente autorização para exportar todos os pedidos de apoio ou emitir reembolsos. Teste se conteúdos recuperados podem desviar o assistente, se material não autorizado pode surgir nos resultados e se ações arriscadas exigem aprovação separada.

Provas a conservar: configuração de acesso, provas de garantia pertinentes, permissões de integração, resultados de testes e decisões corretivas. Atribua explicitamente aos responsáveis técnicos a desativação de acessos desnecessários antes do lançamento.

6. Teste utilidade, falhas e supervisão humana

Defina critérios de aceitação antes da demonstração. Prepare casos representativos com entradas incompletas, documentos enganadores, perguntas sem resposta suportada, línguas relevantes e abusos plausíveis. Use material sintético ou autorizado por outra via. Registe configuração e data do teste para delimitar o resultado.

Avalie os aspetos importantes para a tarefa: correção, rastreabilidade, divulgação inadequada, tratamento inconsistente e paragem segura quando o sistema não consegue responder. Para recomendações relevantes, confirme que os revisores têm informação, tempo, autoridade e capacidade prática para contestar um resultado.

O NIST AI RMF organiza o trabalho de risco em Govern, Map, Measure e Manage. Pode estruturar a análise, mas a sua adoção não demonstra, por si só, conformidade legal. NIST AI RMF Core.

Verificação da decisão: acorde quais as falhas que bloqueiam o lançamento e quais podem ser controladas por utilização restrita. «Há uma pessoa envolvida» é insuficiente se essa pessoa aceita rotineiramente resultados sem os verificar.

7. Concilie o contrato com a configuração

Verifique se as condições assinadas cobrem plano adquirido, utilizações permitidas, dados, confidencialidade, compromissos de segurança, cooperação em incidentes, alterações substanciais e cessação. Pergunte quem detém ou pode usar entradas e resultados, que restrições existem e o que acontece perante uma reclamação de propriedade intelectual. Não deduza titularidade ou proteção do material comercial.

Compare promessas e definições. Se o contrato permite excluir os dados do treino, determine se a opção está ativa e quem a pode alterar. Se promete apagamento, registe processo, exclusões e provas disponíveis. Pergunte como o fornecedor ajudará a investigar incidentes e a cumprir as suas próprias obrigações.

Provas a conservar: condições assinadas, anexos relevantes, exceções aprovadas e comprovativos da configuração. Separe questões de negociação comercial de condições a cumprir antes de o serviço receber dados de produção.

8. Registe a decisão, a monitorização e a saída

Use resultados explícitos: aprovado dentro do âmbito, aprovado com condições, piloto restrito, escalado ou rejeitado. Registe riscos residuais, pessoa autorizada a aceitá-los, prazos e próxima revisão. Um impedimento de lançamento por resolver não deve tornar-se uma simples tarefa posterior só porque a data se aproxima.

Atribua a alguém a monitorização de alterações substanciais, incidentes, controlos de qualidade falhados, reclamações e expansão do uso. Decida que acontecimentos exigem nova análise. Confirme que a equipa pode revogar acessos, retirar integrações, exportar registos necessários, pedir apagamento e continuar o processo caso o fornecedor fique indisponível.

Provas a conservar: decisão assinada e procedimento de desativação ou alternativa testado. A aprovação deve ser compreensível para um colega ausente das chamadas com o fornecedor. Ligue-a às provas para diligência devida de investidores, sem reconstruir a explicação em cada análise.

Um registo prático de aprovação

Use este registo compacto para um fornecedor e uma utilização. Anexe provas em vez de copiar relatórios completos.

| Campo | O que registar | | --- | --- | | Âmbito | Serviço, plano, finalidade, utilizadores, dados, integrações, exclusões | | Responsabilidade | Responsável empresarial, técnico, revisor de privacidade/jurídico, aprovador | | Constatações | Referências às provas, testes, incertezas, âmbito jurídico | | Decisão | Resultado, fundamento, riscos residuais, exceções aceites | | Condições | Ação necessária, responsável, prazo, dependência do lançamento | | Seguimento | Data de revisão, desencadeadores, contacto de incidentes, procedimento de saída |

Uma regra útil de conclusão exige prova ou lacuna explícita para cada pergunta obrigatória, tratamento para cada lacuna e responsável para cada condição de aprovação. «Questionário recebido» é um marco de progresso, não uma decisão de aprovação.

Exemplo: assistente de redação para apoio ao cliente

Imagine que uma equipa SaaS pretende preparar respostas com um assistente. A primeira proposta liga todo o arquivo de pedidos e permite envio automático. A análise identifica anexos privados, conservação incerta dos registos e passos de resolução de problemas ocasionalmente inventados.

Um piloto restrito poderia usar artigos aprovados, pedidos sintéticos, nenhum envio automático e revisão documentada por trabalhadores. Antes da produção, a equipa esclareceria a conservação, limitaria o acesso de recuperação, testaria falhas representativas e aprovaria o contrato pertinente. São controlos ilustrativos, não uma garantia de aceitabilidade de qualquer implementação de apoio.

Se a equipa ativar reembolsos mais tarde, a aprovação original deixa de descrever o uso. Reabra a análise de permissões de escrita, cenários de abuso, autorização e recuperação. Por isso um registo reutilizável é mais útil do que um selo de «aprovado» para todo o fornecedor. Também reduz a duplicação descrita no guia de análises manuais do risco de fornecedores.

Erros comuns e perguntas frequentes

Basta um certificado de segurança?

Não. Pode apoiar afirmações específicas de segurança dentro do seu âmbito. Não esclarece se dados, papel jurídico, resultados, integrações e contrato são adequados. Conserve-o juntamente com provas específicas da implementação.

Todos os fornecedores de IA precisam da mesma análise?

Não. Use controlos mais leves para utilizações reversíveis de baixo impacto e mais profundos para dados sensíveis, decisões importantes ou permissões amplas. Documente a justificação da profundidade e as condições que a alterariam.

O que deve um fundador documentar primeiro?

Comece por utilização exata, categorias de dados, responsável empresarial e permissões. Estes factos permitem aos especialistas pedir provas pertinentes. Sem eles, mesmo um questionário detalhado pode descrever o serviço errado.

E se o fornecedor recusar provas importantes?

Registe a recusa e a incerteza resultante. Considere provas alternativas, uma implementação mais limitada ou outro fornecedor. Não encerre o ponto apenas porque o fornecedor diz que a informação é confidencial.

Quando está concluída a lista?

Para a decisão atual, quando âmbito, provas, lacunas, condições e aprovador responsável estiverem registados. O processo operacional continua com monitorização e reavaliação. Comece esta semana com um fornecedor proposto e torne o registo reutilizável.

Fontes e crédito da imagem

As ligações junto das afirmações remetem para o RGPD, o texto consolidado atual do Regulamento da IA, a atualização da Comissão Europeia e o NIST AI RMF Core. A lista operacional e o exemplo são recomendações editoriais, não requisitos legais adicionais.

Imagem: reunião da equipa Wiki Loves Monuments em Viena, fotografada por Manfred Werner (Tsui), via Wikimedia Commons, CC BY-SA 4.0. Redimensionada. Ilustra uma análise colaborativa; não implica apoio.