Checklist sistemas de AI de alto risco para fundadores e compliance leads

Sistemas de AI de alto risco precisam de checklist porque o problema raramente e entender o termo. O problema e provar que a equipe revisou o caso de uso correto, atribuiu owners, acionou controles e manteve evidencia suficiente para clientes, board, auditores ou reguladores.

Pelo EU AI Act, a classificacao high-risk pode vir de produtos regulados ou de casos de uso listados no Annex III. As draft guidelines da Comissao de maio de 2026 ajudam a aplicar Article 6, mas o regulamento continua sendo a fonte juridica.

1. Confirme o caso de uso AI

Confirme se o workflow realmente usa um sistema AI. Labels como automation, intelligence, insight, scoring, recommendation, assistant ou optimization nao bastam.

Registre nome do sistema, area de produto, finalidade, modelo ou vendor, output, quem usa o output e se a funcao e customer-facing, employee-facing, interna ou embedded. Se nao houver sistema AI, documente e feche a checklist.

2. Identifique o papel no AI Act

O papel importa porque obrigacoes variam entre provider, deployer, importer, distributor, product manufacturer e outros atores. Uma empresa SaaS pode ter papeis diferentes por workflow.

Documente quem desenvolve, quem controla finalidade e configuracao, quem coloca o sistema no mercado da UE e quais instrucoes ou role statements o vendor fornece.

3. Revise a rota de produto regulado

Pergunte se o sistema pode ser componente de seguranca de um produto regulado ou o proprio produto regulado. Isso pode importar para dispositivos medicos, maquinas, transporte, aviacao, radio equipment, brinquedos, elevadores ou ambientes industriais.

Verifique se a AI apoia comportamento de seguranca, diagnostico, monitoring, controle, alerta ou deteccao de falhas, e se pode haver conformity assessment por terceiro.

4. Revise o Annex III

Annex III costuma ser mais relevante para SaaS. Verifique biometria, infraestrutura critica, educacao, recruiting, emprego, worker management, acesso a servicos essenciais, credito, seguros, justica, migracao e processos democraticos.

A classificacao segue finalidade e uso concreto. O mesmo modelo pode ser baixo risco como assistente interno e alto risco em recruiting.

5. Avalie configuracao do cliente

SaaS costuma ser configuravel. Uma funcao comum pode se tornar sensivel se clientes a usam para ranquear candidatos, avaliar trabalhadores, medir estudantes ou influenciar acesso a servicos importantes.

Veja se clientes escolhem campos, criterios, thresholds ou labels, se workflows sensiveis sao possiveis e se ha review gate antes da ativacao.

6. Atribua owners e gates

Atribua product owner, engineering owner, legal ou compliance owner, security ou risk owner e customer-facing owner para declaracoes aprovadas.

Classificacao ausente deve bloquear lancamentos em dominios sensiveis. Classificacao provavelmente high-risk deve acionar review profunda e condicoes de launch.

7. Defina evidencia minima

Guarde intake, descricao do sistema, analise de papel, screen de produto regulado, screen Annex III, finalidade, analise de pessoas afetadas, data flow, documentos de vendor, decisao de classificacao, reviewer, data, racional, fontes, decisao de launch, controles e proximo trigger.

Para sistemas provavelmente high-risk, adicione risk records, decisoes de data governance, owner de documentacao tecnica, testes, human oversight, logging, monitoring, incident path e rota de conformidade.

8. Transforme controles em trabalho de produto

Risk management vira registro de risco da feature. Data governance vira regras para dados de training, test, input, cliente e feedback. Documentacao tecnica vira pasta de evidencia. Transparencia vira instrucoes ao cliente. Human oversight vira processo real de review. Monitoring vira metricas com owner e cadencia.

9. Reabra a decisao

Reabra a checklist quando mudarem finalidade, modelo, vendor, versao, review humana, configuracao de cliente, mercado, categorias de dados, monitoring, guidance, standards ou apetite de risco.

FAQ

O que as equipes devem entender?

Quando sistemas de AI de alto risco podem se aplicar, quais mudancas operacionais acionam e qual evidencia mostra que o trabalho acontece.

Por que importa na pratica?

Porque a classificacao pode afetar design de produto, launch gates, documentacao de cliente, vendor review, monitoring, incident response e evidencia de audit.

Qual e o maior erro?

Tratar high-risk AI como interpretacao juridica unica em vez de workflow repetivel com owners, triggers, evidencia e escalacao.

Fontes

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence.
• European Commission draft guidelines on the classification of high-risk AI systems.
• European Commission AI Act FAQ on high-risk AI systems.
• European Commission guidance on AI Act standardisation.