Monitorização Pós-Colocação no Mercado ao Abrigo do Regulamento IA da UE (Art.º 72): Obrigações para Fornecedores de IA de Alto Risco

A conformidade não termina na entrada no mercado. O Art.º 72 exige que os fornecedores de sistemas de IA de alto risco mantenham um sistema ativo de monitorização pós-colocação no mercado, recolham dados de desempenho e comuniquem incidentes graves. Aqui está o que deve fazer — e quando.

O que é a Monitorização Pós-Colocação no Mercado?

A avaliação de conformidade e a marcação CE são o bilhete de entrada no mercado da UE para um sistema de IA de alto risco — não a linha de chegada. O Art.º 72 do Regulamento IA da UE impõe uma obrigação contínua: os fornecedores devem estabelecer e operar um sistema de monitorização pós-colocação no mercado (MPM) que recolha, analise e actue ativamente sobre dados de desempenho no mundo real ao longo de toda a vida operacional do sistema.

A fundamentação é simples. Um sistema de IA validado num conjunto de dados fixo pode derivar à medida que as entradas do mundo real mudam, à medida que a população de utilizadores se altera, ou à medida que o ambiente em que opera evolui. Os instantâneos estáticos de conformidade não conseguem capturar isto. A MPM é o mecanismo que transforma a conformidade num processo contínuo, em vez de um evento único.

O sistema MPM deve ser proporcional à natureza e aos riscos do sistema de IA de alto risco em causa. Um modelo de pontuação de crédito implantado em escala em milhões de consumidores requerá uma monitorização mais intensiva do que uma ferramenta estreita de classificação de documentos utilizada internamente por uma empresa regulamentada.

Quem Deve Estabelecer um Sistema MPM?

Obrigatório para:

• Fornecedores de sistemas de IA autónomos de alto risco do Anexo III — sistemas listados no Anexo III que não são componentes de segurança de um produto (por exemplo, IA utilizada em decisões de emprego, acesso à educação, aplicação da lei, avaliação da solvabilidade, gestão de infraestruturas críticas)
• Fornecedores de sistemas de IA incorporados em produtos do Anexo I — componentes de segurança de IA integrados em produtos abrangidos pela legislação europeia existente de harmonização (dispositivos médicos, máquinas, veículos)

Não exigido para:

• Fornecedores de sistemas de IA de risco mínimo (sem obrigação formal de MPM, embora se apliquem boas práticas)
• Fornecedores de sistemas de IA apenas de transparência (as obrigações do Art.º 50 não se estendem à MPM)
• Fornecedores de modelos GPAI — estes estão sujeitos a um regime separado ao abrigo dos Art.º 61–62, que inclui a comunicação de incidentes para modelos com risco sistémico, mas está estruturado de forma diferente da MPM do Art.º 72

O papel do utilizador final é de apoio mas não opcional. Os utilizadores finais devem operar o sistema de IA em conformidade com as instruções do fornecedor, ativar e reter a funcionalidade de registo incorporada no sistema e — de forma crítica — comunicar quaisquer incidentes graves de que tenham conhecimento ao fornecedor sem atraso injustificado. Um utilizador final que observa um incidente grave e não notifica o fornecedor não está em conformidade.

O Plano de Monitorização Pós-Colocação no Mercado (Anexo IV, Ponto 12)

O plano MPM é um componente obrigatório da documentação técnica (Anexo IV). Não pode ser um documento genérico: deve ser específico ao sistema, ao seu contexto de implantação e aos seus riscos identificados. No mínimo, deve definir:

1. Recolha de dados — que métricas de desempenho são capturadas (exatidão, taxas de erro, resultados de decisão), como os dados são recolhidos (telemetria automatizada, relatórios de utilizadores finais, feedback de utilizadores) e com que frequência
2. Ciclos de feedback — o mecanismo pelo qual os utilizadores finais podem comunicar problemas de desempenho, anomalias ou incidentes ao fornecedor de forma estruturada e atempada
3. Monitorização de exatidão — como o desempenho do sistema é acompanhado em relação ao benchmark validado utilizado durante a avaliação de conformidade, incluindo qualquer metodologia de deteção de desvio
4. Monitorização de preconceito — para sistemas onde os resultados demográficos são relevantes (contratação, crédito, aplicação da lei), monitorização contínua das disparidades estatísticas entre grupos protegidos, com metodologia e limiares definidos
5. Gatilhos de atualização — os limiares quantitativos ou qualitativos específicos que impulsionam medidas corretivas, incluindo requalificação do modelo, ajuste de parâmetros ou suspensão da implantação
6. Calendário de revisão — com que frequência o próprio plano MPM é revisto e atualizado, assegurando que permanece adequado ao seu propósito à medida que o contexto de implantação evolui

O plano MPM deve ser mantido atualizado. Um plano desatualizado que já não reflete a metodologia de monitorização real não satisfaz o Art.º 72.

Comunicação de Incidentes Graves (Art.º 73)

O que constitui um incidente grave?

O Art.º 73 define um incidente grave como qualquer incidente ou mau funcionamento de um sistema de IA de alto risco que leve direta ou indiretamente a:

• Morte ou dano grave à saúde (físico ou psicológico)
• Uma perturbação grave e irreversível na gestão ou operação de infraestruturas críticas
• Uma violação grave dos direitos fundamentais (privacidade, não discriminação, devido processo)
• Uma situação em que uma pessoa evitou por pouco qualquer um dos anteriores

É importante que o Regulamento IA não exija que seja estabelecida uma relação de causalidade com o sistema de IA antes de comunicar. Uma suspeita razoável de que o sistema de IA contribuiu para ou não conseguiu prevenir o dano é suficiente para desencadear a obrigação. Os fornecedores que aguardam certeza antes de comunicar arriscam-se ao incumprimento.

Prazos de comunicação

O prazo de 15 dias começa quando o fornecedor toma conhecimento do incidente — o que, na prática, significa quando o utilizador final os notifica. Os fornecedores devem conceber os seus procedimentos de notificação de utilizadores finais de forma que a informação lhes chegue rapidamente o suficiente para cumprir o prazo de comunicação a jusante.

O que um relatório de incidente deve conter

Um relatório de incidente conforme à autoridade nacional de vigilância do mercado deve incluir:

• Identificação do sistema: nome, versão, número de registo na base de dados da UE
• Descrição do incidente: o que aconteceu, que dano ocorreu ou foi por pouco evitado, data e local
• Pessoas afetadas: número e categorias de utilizadores ou terceiros afetados (anonimizados quando exigido pelo RGPD)
• Análise causal preliminar: a compreensão atual do fornecedor de como o incidente surgiu, claramente rotulada como preliminar
• Medidas corretivas ou de segurança imediatas tomadas: quaisquer passos já tomados para limitar danos ou riscos adicionais (por exemplo, suspensão da funcionalidade afetada, notificações de utilizadores finais)
• Ponto de contacto: a pessoa ou equipa responsável pela correspondência de acompanhamento com a autoridade

O relatório deve ser factual e proporcionado. Os relatórios preliminares podem ser complementados por relatórios de acompanhamento à medida que a investigação progride.

Registo Obrigatório (Art.º 12)

O Art.º 12 exige que os sistemas de IA de alto risco sejam concebidos e construídos com a capacidade de gerar automaticamente registos a um nível de granularidade suficiente para permitir:

• Monitorização pós-colocação no mercado em conformidade com o Art.º 72
• Rastreamento de eventos que levaram a um incidente grave
• Investigação pelas autoridades nacionais

Este é um requisito de design imposto ao fornecedor. O fornecedor deve incorporar a capacidade de registo no sistema antes de ser colocado no mercado.

A obrigação de ativar e reter esses registos recai sobre o utilizador final. Os utilizadores finais não devem desativar a funcionalidade de registo e devem reter os registos pelo período especificado nas instruções e documentação técnica do fornecedor. Quando não é definido nenhum período de retenção específico, os registos devem ser retidos por um período proporcional ao ciclo de vida operacional do sistema e a quaisquer requisitos específicos do sector (por exemplo, regras de manutenção de registos de serviços financeiros ao abrigo do DORA ou do MiFID II).

Modificações Substanciais e Reavaliação

Nem toda a alteração a um sistema de IA implantado desencadeia uma nova avaliação de conformidade. O Regulamento distingue entre atualizações menores e modificações substanciais.

Uma modificação é substancial — e requer uma nova avaliação de conformidade e documentação técnica atualizada — quando:

• Altera a finalidade prevista do sistema (mesmo parcialmente)
• Envolve uma alteração significativa da arquitetura ou da metodologia de treino
• Utiliza novos dados de treino que afetam materialmente o desempenho do sistema de formas que possam afetar o comportamento relevante para a conformidade
• Degrada o desempenho para além dos limiares definidos na documentação de gestão de riscos de formas que afetam a segurança ou os direitos fundamentais

As atualizações menores — patches de segurança, correções de bugs que corrigem defeitos claramente identificados sem alterar o comportamento relevante para a conformidade, alterações cosméticas à interface — não requerem uma reavaliação completa. No entanto, devem ser documentadas, e o fornecedor deve reter uma avaliação escrita confirmando que a modificação não constitui uma modificação substancial. Esse registo está sujeito a inspeção pelas autoridades de vigilância do mercado.

Lista de Verificação Prática de Implementação

A lista de verificação seguinte reflete os requisitos operacionais mínimos ao abrigo dos Art.º 72, 73 e 12. Não substitui o aconselhamento jurídico, mas fornece um ponto de partida para a análise de lacunas.

• [ ] Plano MPM documentado no ficheiro técnico (Anexo IV, ponto 12), específico ao sistema e ao seu contexto de implantação
• [ ] Capacidade de registo automatizado concebida e incorporada no sistema antes da colocação no mercado
• [ ] As instruções para o utilizador final incluem um procedimento de comunicação de incidentes claro e por escrito com contacto de escalada
• [ ] Ponto de contacto para comunicação de incidentes estabelecido internamente e notificado à autoridade nacional de vigilância do mercado relevante
• [ ] Processos ou painéis de monitorização de preconceito e exatidão definidos, com metodologia e limiares documentados
• [ ] Limiares de escalada para ação corretiva documentados e ligados ao sistema de gestão de riscos
• [ ] Procedimento de avaliação de modificação substancial em vigor, com um modelo de registo de decisão para cada atualização
• [ ] Política de retenção de registos definida, comunicada aos utilizadores finais e alinhada com as regras de retenção específicas do sector

Referências cruzadas: Documentação Técnica — Sistemas de IA de Alto Risco do Anexo III — Fornecedores vs. Utilizadores Finais