Due diligence de fornecedores de IA: guia prático para equipas SaaS

A due diligence funciona quando transforma uma utilização proposta numa decisão operacional defensável. A equipa deve compreender função, dados e pessoas afetadas, fornecedores de modelos e infraestrutura, testes, papéis jurídicos, compromissos contratuais e monitorização de alterações. O resultado não é um questionário preenchido, mas aprovação, aprovação condicionada, piloto limitado, escalamento ou rejeição fundamentada com responsáveis.

O AI Act da UE não contém uma checklist universal chamada “AI vendor due diligence”. A profundidade depende do sistema, finalidade, classificação, papel na cadeia de valor, tratamento de dados e regras setoriais. Um assistente de atas e um sistema que ordena candidatos requerem análises diferentes. Comece pelo caso de utilização e peça provas proporcionais às consequências.

Porque a análise tradicional não basta

Acesso, encriptação, disponibilidade, subcontratantes, incidentes e eliminação continuam importantes. Mas um serviço de IA pode mudar modelos, fontes de retrieval, filtros ou utilização de prompts e outputs sem uma release convencional. A qualidade varia por língua, grupo ou input; um “apoio à decisão” pode tornar-se decisivo sob pressão.

Analise fornecedor e sistema: empresa, alojamento, modelos, segurança, contrato e continuidade; depois finalidade, utilizadores, afetados, dados, comportamento, supervisão humana, integrações e ações posteriores. Separá-los recria o problema das análises manuais durante a escala.

Quando aprofundar

Faça análise reforçada se entram dados pessoais, confidenciais, regulados ou do cliente; o output influencia decisões importantes; o serviço age autonomamente ou altera produção; se liga conhecimento proprietário; o erro é difícil de detetar ou reverter; a cadeia é opaca; ou uma falha causa dano material.

Não deduza a classificação do marketing. No AI Act contam finalidade e papel. O artigo 25 pode deslocar obrigações de fornecedor por rebranding, alteração substancial ou nova finalidade de alto risco. Fornecedores de sistemas de alto risco e terceiros de componentes devem trocar informação necessária através de acordos escritos. Em 30 de agosto de 2026, grande parte do AI Act é aplicável; as datas alteradas para alto risco são 2 de dezembro de 2027 para o anexo III e 2 de agosto de 2028 para produtos regulados. São períodos de preparação.

Provas a solicitar

1. Sistema e cadeia: limite, modelos e fornecedores, regiões, integrações, fontes, subcontratantes, usos permitidos e proibidos, limitações, versões e avisos.
2. Dados e privacidade: finalidade, local, acesso, retenção, eliminação, treino e transmissão de prompts, uploads, outputs, feedback, metadados e logs. Se o fornecedor é subcontratante RGPD, o artigo 28 exige garantias suficientes e contrato adequado. O EDPB descreve uma avaliação específica e contínua de conhecimento, fiabilidade, recursos, políticas, auditorias e certificações.
3. Segurança e resiliência: relatórios e âmbito, vulnerabilidades, incidentes, encriptação, identidades, isolamento, recuperação e dependências. Para GenAI: prompt injection, fuga, ferramentas inseguras e fontes envenenadas.
4. Desempenho e impacto: grupos e línguas testados, baseline, limiares, condições, limites e falhas. Teste a configuração real com inputs difíceis, escalamento, intervenção humana e recuperação.
5. Governance: responsáveis do fornecedor por segurança, privacidade, AI governance, incidentes e avisos; responsáveis internos de negócio e risco; reclamações, outputs nocivos e provas após término.

O AI RMF voluntário do NIST propõe políticas, controlos documentados, contingências e monitorização para IA de terceiros. O perfil GenAI menciona due diligence de aquisição, SLA, relatórios de garantia e transparência da cadeia. São referências de desenho, não prova de conformidade jurídica.

Contrato e decisão

O contrato deve seguir as provas: finalidade, utilizadores e dados; treino; modelos, subcontratantes, locais e avisos; segurança, incidentes e cooperação; documentação; limites e supervisão; alterações; continuidade, portabilidade, eliminação e saída; responsabilidade proporcional. Um contrato não corrige um sistema inadequado, mas protege informação e soluções.

1. Descreva finalidade, utilizadores, afetados, inputs, outputs, integrações, automação, revisão humana e ação posterior.
2. Atribua nível preliminar e papéis AI Act/RGPD, registando transferências, regras e incertezas.
3. Peça provas proporcionais e reutilize documentos atuais que respondam realmente.
4. Teste o produto configurado com dados representativos lícitos; guarde versões e resultados.
5. Trate lacunas com correção, controlo compensatório, âmbito limitado, piloto temporário, aceitação ou rejeição.
6. Reavalie após alterações de finalidade, modelo, fornecedor, dados, integração, autonomia, incidente ou lei.

O registo de decisão contém produto e versão, utilizações permitidas e proibidas, cadeia, nível, papéis, justificação, provas, testes, lacunas, contrato, decisão, condições, prazos e monitorização. As expectativas de AI governance exigem provas atualizadas.

FAQ

Qual é a finalidade prática?

Decidir de forma defensável se e como um serviço específico pode ser usado, encontrar lacunas cedo, atribuir controlos e guardar provas para clientes, auditorias, incidentes e reavaliações.

O que documentar primeiro?

A utilização exata: utilizadores, afetados, dados, inputs, outputs, integrações, revisão humana e ação posterior. Sem esse limite, respostas e papéis jurídicos não são avaliáveis.

Qual é o maior erro?

Tratar due diligence como troca documental única. Uma análise forte liga âmbito, provas, testes, contrato, condições, monitorização e gatilhos claros de reavaliação.