Vigilância pós-comercialização da IA: como transformar sinais de utilização em controlos verificáveis

O que exige a vigilância pós-comercialização

A vigilância pós-comercialização é o sistema através do qual o fornecedor recolhe e analisa informações pertinentes sobre o desempenho de um sistema de IA de risco elevado depois de este ser colocado no mercado ou em serviço. O seu objetivo não é acumular registos por si só: é permitir que o fornecedor verifique se o sistema continua a cumprir os requisitos aplicáveis e se surgiram problemas que exigem investigação ou ação.

O artigo 72.º do Regulamento da IA atribui ao fornecedor a responsabilidade de estabelecer e documentar esse sistema. Este deve ser proporcional à natureza da tecnologia e aos riscos do sistema. O fornecedor deve também dispor de um plano de vigilância pós-comercialização como parte da documentação técnica. Na prática, o plano explica como serão obtidos e analisados os dados, que sinais podem revelar um desvio e como será decidido se é necessário intervir.

A obrigação diz respeito aos sistemas de IA de risco elevado. Não significa que todos os fornecedores tenham de vigiar qualquer produto com a mesma intensidade, nem que tenham de recolher todos os dados disponíveis. A proporcionalidade é importante: as fontes, os indicadores e a frequência das revisões devem ter uma relação razoável com a utilização prevista, o contexto de implantação e os riscos que o sistema pode gerar.

Convém separar dois planos. O requisito legal consiste em dispor de um sistema e de um plano adequados e documentados. Os indicadores, limiares e rotinas propostos neste guia são opções de conceção para tornar operacional essa obrigação; não constituem uma lista universal imposta pelo Regulamento.

O que observar e de onde podem vir os dados

O Regulamento contempla dados pertinentes fornecidos pelos responsáveis pela implantação e dados obtidos através de outras fontes. Isto dá margem para cada fornecedor conceber um sistema adequado ao seu produto, mas não elimina a necessidade de justificar por que razão uma fonte é pertinente nem como será interpretada. Os dados devem servir para avaliar o desempenho do sistema ao longo da sua vida útil e detetar alterações que possam afetar a conformidade ou os riscos.

Um inventário inicial pode incluir métricas de funcionamento, resultados anómalos, incidentes técnicos, reclamações, comentários estruturados dos utilizadores, pedidos de assistência e alterações nas condições de utilização. Consoante o sistema, também pode ser pertinente observar alterações na população de utilizadores, nos dados de entrada ou nos processos com os quais o sistema está integrado. Nem todos estes sinais são obrigatórios em todos os casos: a sua utilidade depende do contexto e do risco que se pretende vigiar.

A interação com outros sistemas de IA merece atenção quando for pertinente para compreender o desempenho ou os riscos. Por exemplo, uma ferramenta pode receber resultados de outro sistema ou alimentar um processo automatizado com as suas próprias saídas. Nestes casos, uma alteração no sistema ligado, no formato dos dados ou no fluxo de trabalho pode modificar o comportamento observado sem que o modelo sob vigilância tenha mudado. O plano deve indicar que dependências são pertinentes e como serão detetadas alterações nas mesmas.

A cooperação com o responsável pela implantação é importante, porque o fornecedor poderá não observar diretamente todas as condições reais de utilização. Um acordo operacional pode especificar que categorias de dados são partilhadas, quem as prepara, com que periodicidade, através de que canal e a quem são comunicados os sinais urgentes. Trata-se de uma recomendação prática: o Regulamento não transforma esta lista concreta num formulário obrigatório. A partilha deve limitar-se ao necessário para a finalidade de vigilância e respeitar as demais obrigações aplicáveis.

Conceber um plano que possa ser aplicado

Um plano operacional começa pela utilização prevista e pelos riscos que o sistema pode apresentar nesse contexto. A partir daí, identifica que dados podem revelar uma alteração pertinente e que decisões poderão resultar desses dados. Uma tabela de métricas sem responsáveis, critérios de revisão ou vias de atuação é difícil de utilizar e pouco esclarecedora quanto à forma como um sinal foi tratado.

É útil atribuir responsabilidades distintas. Uma equipa técnica pode validar a qualidade dos dados e analisar o comportamento; a equipa de produto pode avaliar alterações nas funcionalidades ou nas condições de utilização; a equipa de conformidade pode verificar as obrigações aplicáveis e a documentação; e uma pessoa ou equipa com autoridade definida pode decidir se o caso deve ser escalado. Em organizações pequenas, uma mesma pessoa pode desempenhar várias funções, mas as decisões e os respetivos fundamentos devem continuar a ser identificáveis.

Os indicadores devem ser formulados de modo a permitir uma análise consistente. Podem incluir taxas de erro, indisponibilidade, alterações na distribuição dos dados de entrada, diferenças entre grupos pertinentes para a avaliação do sistema ou um aumento de resultados que exigem revisão humana. Um indicador só é útil se estiver definido como é calculado, que período é observado e que limitações tem. Não se deve apresentar uma métrica como prova conclusiva se ela constituir apenas um sinal a investigar.

O fornecedor pode estabelecer níveis internos de alerta. Por exemplo, uma alteração acima de um limiar acordado pode desencadear uma revisão técnica; a repetição da alteração ou a sua ocorrência em várias implantações pode justificar uma avaliação mais ampla. Estes limiares são ferramentas de gestão recomendadas, não valores fixados de forma geral pelo artigo 72.º. Devem ser revistos se a utilização, a evidência disponível ou o perfil de risco se alterarem.

Investigar sinais e registar as decisões

Um sinal não equivale automaticamente a um incumprimento. Pode dever-se a dados incompletos, a uma alteração no processo do cliente, a um incidente temporário ou a uma degradação real. A investigação deve distinguir estas possibilidades e registar que informações foram analisadas. Se o sinal afetar várias implantações, convém verificar se existe uma causa comum, como uma determinada versão, uma dependência partilhada ou uma alteração nas condições dos dados de entrada.

Um registo de decisões útil inclui a data de deteção, a fonte, o sistema e as versões afetados, a descrição do sinal, a pessoa responsável pela avaliação, a evidência analisada, a conclusão e as etapas seguintes. Se não for adotada uma medida, o registo deve explicar por que motivo as informações disponíveis não justificavam uma ação e que condições levariam à reabertura do caso. Este nível de detalhe é uma boa prática documental, não um formato fechado prescrito pelo Regulamento.

As medidas possíveis dependem do resultado da análise. Podem consistir em corrigir um defeito, atualizar instruções, modificar uma integração, reforçar os controlos humanos, limitar temporariamente determinadas utilizações ou iniciar uma revisão técnica mais ampla. A medida escolhida deve ser proporcional ao problema observado e ficar documentada. Se o sinal sugerir que o sistema já não satisfaz os requisitos aplicáveis ou que surgiram riscos não considerados, o fornecedor deve relacionar essa conclusão com os seus processos de avaliação e gestão de riscos, em vez de a tratar como um incidente isolado de apoio ao cliente.

O responsável pela implantação também precisa de saber que informações são importantes para utilizar o sistema de forma adequada e comunicar problemas pertinentes. Por isso, o plano deve prever um canal de escalonamento e um mecanismo para transmitir informações ao fornecedor. Nos produtos com vários clientes, a definição de uma via consistente evita que sinais semelhantes fiquem dispersos por diferentes equipas de apoio.

Vigilância, gestão de riscos, avaliações de impacto e incidentes

A vigilância pós-comercialização não substitui a gestão de riscos. A gestão de riscos é um processo mais amplo de identificação, análise e tratamento dos riscos que deve acompanhar o sistema. A vigilância fornece informações sobre o seu funcionamento real e pode revelar que uma hipótese anterior deixou de ser válida, que surgiu um novo risco ou que uma medida de controlo não funciona como esperado. O plano deve permitir que estes sinais cheguem a quem pode rever as avaliações e as medidas existentes.

Também não é o mesmo que uma avaliação de impacto anterior à implantação. Uma avaliação prévia analisa possíveis efeitos num determinado contexto e antes de uma utilização concreta, quando aplicável. A vigilância observa informações ao longo do ciclo de vida do sistema e ajuda a detetar alterações que só se tornam visíveis durante a utilização. São atividades complementares: nenhuma delas demonstra, por si só, que o sistema continuará a comportar-se da mesma maneira depois de implantado.

A notificação de incidentes graves prevista no artigo 73.º tem outro desencadeador e outra finalidade: diz respeito aos incidentes que devem ser comunicados de acordo com as regras aplicáveis. A vigilância, por sua vez, deve funcionar de forma sistemática e não deve esperar que ocorra um incidente grave. Um sinal pode justificar uma investigação e medidas preventivas mesmo que ainda não tenha atingido o limiar de um incidente notificável. E, se for identificado um incidente que deva ser notificado, o processo de vigilância não substitui a comunicação exigida.

Para evitar confusões, as organizações podem articular os processos sem os fundir: o mesmo acontecimento pode dar início a uma investigação no âmbito da vigilância e, em separado, desencadear a avaliação da obrigação de notificar incidentes. O registo deve indicar que via foi considerada, quem tomou a decisão e que ações foram iniciadas. Esta separação ajuda a evitar que um sinal precoce seja desvalorizado ou que qualquer desvio menor seja automaticamente tratado como um incidente grave.

Casos específicos e calendário regulamentar

O artigo 72.º estabelece uma salvaguarda específica para determinados sistemas de risco elevado no domínio da aplicação da lei: o sistema de vigilância não abrange os dados operacionais sensíveis que se encontrem na posse das autoridades policiais. A exclusão é específica. Não deve ser interpretada como uma isenção geral de vigilância para qualquer sistema utilizado por uma autoridade, nem como autorização para ignorar outros sinais pertinentes que possam ser tratados ao abrigo das regras aplicáveis.

A reforma regulamentar de 2026 alterou o número relativo às orientações da Comissão. O Regulamento prevê que a Comissão publique orientações e um modelo voluntário para o plano de vigilância pós-comercialização antes de 2 de setembro de 2027. Por conseguinte, o modelo não deve ser descrito como uma ferramenta já disponível nem como um requisito obrigatório em si mesmo. Enquanto não for publicado, os fornecedores podem estruturar a sua documentação com base nas obrigações legais em vigor e nas suas necessidades operacionais.

O calendário de aplicação dos sistemas de risco elevado também foi alterado. O texto consolidado estabelece datas diferentes consoante a categoria: para os sistemas de risco elevado incluídos no anexo III, a aplicação das obrigações pertinentes começa em 2 de dezembro de 2027; para os sistemas de risco elevado abrangidos pela legislação de harmonização enumerada no anexo I, começa em 2 de agosto de 2028. A classificação e a data aplicável devem ser verificadas para cada sistema; não convém extrapolar uma data para todos os produtos de IA.

Estas datas não diminuem a importância de preparar antecipadamente o ciclo de vigilância. A conceção das fontes de dados, dos acordos de partilha e da atribuição de responsabilidades exige, muitas vezes, coordenação entre o fornecedor e o cliente. No entanto, a preparação operacional não deve ser confundida com a afirmação de que uma obrigação já é aplicável a um sistema concreto antes da respetiva data.

Lista de verificação para rever o plano

O teste prático de um plano não é a sua extensão, mas sim se permite reconstruir a forma como o sistema é vigiado e o que acontece quando surge um sinal. As perguntas seguintes servem para uma revisão interna. Não substituem a análise jurídica do sistema, da sua classificação ou das suas obrigações específicas.

Um plano sólido identifica o sistema e as utilizações pertinentes, explica que fontes de informação utiliza e porquê, atribui responsabilidades e define uma rotina de análise. Prevê também como são comunicados os sinais entre o fornecedor e o responsável pela implantação, como são conservadas as decisões e como os resultados se relacionam com uma revisão dos riscos ou uma medida corretiva.

A revisão deve ainda verificar se as métricas são interpretáveis, se os alertas conduzem a ações concretas e se a equipa consegue distinguir uma anomalia nos dados de uma degradação do sistema. Se uma alteração de versão, uma nova integração ou uma modificação do contexto puder afetar o desempenho, o plano deve indicar como isso será detetado e como a vigilância será reexaminada.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.