AI Act: conformidade sem a abstração.

Classifique o sistema antes de fazer qualquer outra coisa

Toda decisão no âmbito do AI Act começa com uma pergunta: em que nível se enquadra este sistema. Erre a classificação e ou sobredimensiona um chatbot ou subprotege uma ferramenta de triagem de CV que um regulador tratará como alto risco. Os quatro níveis não são um espectro pelo qual deslizar; são compartimentos discretos com consequências jurídicas diferentes, e um único produto pode estar em mais do que um se agrupar várias funções.

A classificação é função da finalidade prevista, não da sofisticação técnica. Uma simples regressão logística que decide quem obtém um empréstimo é de alto risco. Um grande modelo multimodal que recomenda receitas não é. O Act analisa para que serve o sistema e quem é afetado, por isso o trabalho de classificação pertence a produto e conformidade em conjunto, não apenas à equipa de ciência de dados.

A maioria das disputas na sala de auditoria não é mínimo versus alto; é alto versus limitado na fronteira. Se não conseguir defender a classificação por escrito, trate-a como o nível superior até conseguir. O curso AI Risk Manager percorre a lógica de classificação e a evidência de que precisa para sustentar uma decisão.

O que "alto risco" significa realmente na operação

O TL;DR lista as sete áreas de obrigação. A realidade operacional é que cada uma é um processo recorrente, não um documento que se escreve uma vez. A conformidade de alto risco é um sistema que se opera durante toda a vida do produto, e o Act espera que demonstre que o sistema está ativo, não que existiu no dia do lançamento.

1. A gestão de risco é contínua. Identifica utilizações indevidas e danos previsíveis, mitiga-os, testa o risco residual e repete a cada alteração substancial. Um registo de riscos congelado desde o lançamento é uma não conformidade, não um controlo.
2. A governança de dados abrange os conjuntos de treino, validação e teste: representatividade, exame de enviesamento, lacunas e a proveniência dos dados. Precisa de mostrar o que verificou e o que encontrou, não apenas afirmar que os dados eram "bons".
3. A documentação técnica é a espinha dorsal do dossiê. Descreve o sistema, a sua finalidade, as suas opções de conceção, as suas métricas de desempenho e as suas limitações com detalhe suficiente para que um terceiro possa avaliar a conformidade a partir dela.
4. A manutenção de registos significa registo de logs automático ao longo da vida do sistema, de modo a que os eventos sejam rastreáveis. Se algo correr mal, tem de conseguir reconstruir o que o sistema fez.
5. A supervisão humana tem de ser concebida desde o início, não acrescentada depois: as pessoas que supervisionam o sistema precisam da capacidade de compreender, intervir e anular, e a interface tem de tornar isso possível.
6. A exatidão, a robustez e a cibersegurança têm de ser medidas e declaradas, e depois mantidas em condições reais, incluindo adversariais. "Funciona na demonstração" não é uma afirmação de robustez.

Estas obrigações mapeiam-se de forma limpa num sistema de gestão, e é por isso que as equipas combinam o Act com a ISO/IEC 42001. O curso ISO 42001 Lead Implementer constrói o modelo operacional que transforma estas sete áreas em processos repetíveis com responsáveis, evidência e ciclos de revisão.

O fluxo de trabalho da avaliação de conformidade

A avaliação de conformidade é a barreira que um sistema de alto risco passa antes de ser colocado no mercado da UE. Para a maioria das categorias de alto risco trata-se de uma avaliação por controlo interno conduzida pelo fornecedor face aos requisitos do Act; certas categorias, nomeadamente alguma biometria, passam por um organismo notificado. De qualquer forma a sequência é a mesma, e vale a pena tratá-la como um plano de projeto em vez de uma lista de verificação.

1. Confirme a classificação e os requisitos aplicáveis ao seu caso de uso e categoria específicos.
2. Implemente os processos de gestão de risco e de governança de dados e execute-os, gerando evidência real em vez de marcadores de posição.
3. Reúna a documentação técnica de modo a que esteja completa e internamente coerente com os logs, os resultados de teste e o registo de riscos.
4. Execute a avaliação de conformidade (interna, ou através de um organismo notificado quando exigido) e resolva as lacunas que ela revelar.
5. Elabore a declaração de conformidade UE, aponha a marcação CE e registe o sistema na base de dados da UE antes de ir para o mercado.
6. Passe à monitorização pós-comercialização no primeiro dia, porque a obrigação não termina no lançamento.

Monitorização pós-comercialização e o calendário faseado

Colocar um sistema no mercado é o ponto intermédio da obrigação, não o fim. Os fornecedores têm de executar um plano de monitorização pós-comercialização que recolhe ativamente dados de desempenho e de incidentes ao longo da vida implementada do sistema, e os incidentes graves têm de ser comunicados às autoridades dentro de janelas definidas. Modificações substanciais podem voltar a desencadear a avaliação de conformidade, por isso o seu processo de gestão de alterações e o seu processo de AI Act têm de estar interligados.

O calendário é faseado, o que faz tropeçar as equipas que leem "agosto de 2027" e assumem que têm até lá para tudo. As proibições de práticas inaceitáveis já se aplicam. As obrigações GPAI e várias disposições de governança chegam mais cedo no calendário, e as obrigações de alto risco entram em fases ao longo do período até agosto de 2027, consoante a categoria. A postura correta é mapear cada um dos seus sistemas à sua própria data aplicável em vez de planear para um único precipício.

Operar o ciclo de monitorização e de incidentes é onde os papéis de auditor e de risco de IA justificam o seu valor. O curso AI auditor (AAIA) cobre como auditar um sistema de gestão de IA face a esta evidência, e o curso advanced AI auditor (AAIR) aprofunda o trabalho de teste e garantia por trás de um dossiê pós-comercialização defensável.

IA de uso geral: uma obrigação separada que pode herdar

As regras para modelos GPAI situam-se ao lado dos níveis de risco, não dentro deles. Se construir ou afinar um modelo de uso geral, carrega obrigações de fornecedor: documentação técnica do modelo, informação para os implementadores a jusante, uma política de direitos de autor, e um resumo público do conteúdo de treino. Os modelos considerados portadores de risco sistémico assumem deveres mais rigorosos, incluindo avaliação do modelo, teste adversarial e comunicação de incidentes.

A armadilha para a maioria das equipas está do outro lado dessa relação. Se integrar um modelo de fundação de terceiros no seu próprio sistema de alto risco, não escapa ao Act apontando para o fornecedor do modelo. Herda o risco de integração e continua responsável por o seu sistema atingir a conformidade. Trate a documentação do fornecedor do modelo como um insumo para o seu dossiê, não como um substituto dela, e estabeleça as transferências contratuais antes de lançar.

Erros comuns e a decisão à sua frente

• Tratar a classificação como algo único. Uma funcionalidade que começou como motor de recomendação torna-se de alto risco no momento em que condiciona uma decisão de contratação ou de crédito. Reclassifique a cada alteração material de finalidade.
• Escrever a documentação como artefacto de lançamento. O dossiê tem de manter-se sincronizado com o sistema em funcionamento; um dossiê desatualizado é pior do que um incompleto porque induz ativamente em erro.
• Confundir o sistema de gestão com a regulamentação. A ISO 42001 organiza a sua prova, mas não torna por si só um sistema conforme com o AI Act. Continua a ter de classificar, avaliar e registar face ao Act.
• Assumir que as obrigações de fornecedor GPAI cobrem a sua integração. Não cobrem. O seu sistema de alto risco precisa da sua própria história de conformidade.
• Planear para um único prazo. As datas faseadas significam que algumas obrigações já estão ativas enquanto outras estão a anos de distância; planeie por sistema, por categoria.

A decisão à frente da maioria das equipas não é se devem cumprir mas como construir a capacidade de cumprir repetidamente. Se está a começar do zero, o curso ISO 42001 Foundation dá à equipa um vocabulário partilhado, e o curso AI security management (AAISM) liga as obrigações de cibersegurança e robustez do Act ao programa de segurança que já executa. Escolha o papel mais próximo da sua lacuna e construa a partir daí.