Ilustración editorial para Evaluación de impacto en derechos fundamentales para IA: cómo decidir si corresponde y qué documentar
Imagen generada con gpt-image-2.5-sunburst para InferamaFonte ↗
01

Âmbito e cautela: uma avaliação para decidir antes da utilização

A avaliação de impacto sobre os direitos fundamentais prevista no artigo 27.º do Regulamento da Inteligência Artificial, conhecido como AI Act, é uma análise prévia que determinados responsáveis pela implantação devem realizar antes de utilizarem certos sistemas de IA de risco elevado. Na prática, o seu objetivo é examinar de que forma a utilização prevista pode afetar pessoas ou grupos no contexto concreto e determinar que medidas, responsáveis e mecanismos de resposta são necessários antes de a autorizar.

Não é uma certificação do sistema, uma garantia de que não haverá danos, nem uma avaliação geral de toda a atividade de uma organização. Também não substitui automaticamente uma avaliação de impacto sobre a proteção de dados (AIPD; DPIA, na sigla inglesa). O objetivo deste guia é mais limitado: ajudar a determinar se a obrigação se aplica ao caso e organizar o trabalho necessário para que a decisão de implantação seja rastreável.

A legislação aplicável pode mudar, e as fontes oficiais fornecidas incluem uma alteração de 2026 que afeta, entre outros aspetos, o tratamento de elementos da AIPD e o questionário a elaborar pelo Serviço para a IA. Por isso, antes de aplicar este guia, é necessário consultar o texto consolidado em vigor, os formulários oficiais e o calendário aplicável. Este guia organiza a análise; não constitui aconselhamento jurídico.

02

Árvore de aplicabilidade: quem deve avaliar e que utilização verificar

A obrigação prevista no artigo 27.º não se aplica indistintamente a qualquer organização que utilize IA. Em termos gerais, é necessário verificar se o sistema está abrangido pela categoria de risco elevado relevante e se quem o implanta pertence a uma das categorias identificadas na norma. O artigo contempla, entre outros, organismos de direito público, entidades privadas que prestam serviços públicos e responsáveis pela implantação de determinados sistemas de risco elevado no domínio do crédito e dos seguros de vida ou de saúde.

A avaliação está associada à utilização efetivamente prevista, e não apenas ao nome comercial do produto ou a uma classificação genérica do fornecedor. É necessário identificar a finalidade, as funções ativadas, o processo organizacional em que se integram e as pessoas afetadas. Se uma ferramenta tiver várias utilizações, convém analisar cada caso de utilização separadamente: a obrigação e os riscos podem variar entre eles.

O artigo 27.º exclui desta obrigação específica os sistemas de risco elevado indicados no ponto 2 do anexo III. A exclusão não deve ser alargada a qualquer sistema que pareça ter risco limitado, nem resolve, por si só, outras obrigações decorrentes do AI Act, da proteção de dados ou de normas setoriais. Se a classificação depender de uma exceção, de uma alteração da utilização ou da interpretação da finalidade, documenta a fundamentação dessa conclusão e solicita uma análise jurídica.

A decisão pode resumir-se nas seguintes perguntas: a entidade é um responsável pela implantação abrangido? O sistema e o caso de utilização estão dentro do âmbito relevante? Aplica-se alguma exceção? A avaliação já realizada continua válida para esta utilização? Se faltarem informações para responder, a conclusão responsável não é presumir que a obrigação não se aplica: é identificar o dado em falta, o responsável por obtê-lo e a condição que impede a aprovação definitiva.

Percurso inicial de aplicabilidade

  1. 01Identifica a entidade que decide colocar o sistema em utilização e o seu papel: responsável pela implantação, fornecedor ou ambos em atividades distintas.
  2. 02Descreve o sistema e a utilização concreta e confirma a sua classificação como sistema de risco elevado com base na documentação pertinente e no texto consolidado.
  3. 03Verifica se a entidade pertence a uma categoria prevista no artigo 27.º, incluindo organismos públicos, determinados prestadores privados de serviços públicos e os casos de crédito ou seguros abrangidos pela norma.
  4. 04Confirma se se aplica a exceção relativa ao ponto 2 do anexo III ou outra condição legal pertinente; regista a justificação.
  5. 05Se a obrigação se aplicar, planeia a avaliação antes da primeira utilização e antes de aprovar a implantação. Se concluíres que não se aplica, documenta os motivos e que alteração obrigaria a rever essa conclusão.
03

Momento, responsabilidades e comunicação à autoridade

A avaliação deve estar concluída antes da implantação em causa, e não depois de já se terem materializado danos ou de ter começado uma operação habitual. Na prática, o ponto de controlo deve situar-se antes de autorizar o acesso dos utilizadores, integrar o sistema num processo decisório ou permitir que os seus resultados influenciem decisões relativas a pessoas.

As responsabilidades organizacionais devem ser atribuídas de forma explícita. A equipa que promove o caso de utilização fornece a descrição do processo e das decisões apoiadas pelo sistema; as funções de conformidade, privacidade, direitos fundamentais, segurança e operações analisam as respetivas áreas; e uma instância com autoridade suficiente decide se a utilização pode ser aprovada, se deve ser alterada ou se deve ser suspensa. A colaboração não deve diluir a responsabilidade por concluir e manter a avaliação.

A norma prevê que a avaliação seja comunicada à autoridade de fiscalização do mercado competente depois de realizada. Determinar qual é a autoridade competente e quais são o canal e o formato aplicáveis exige verificar a jurisdição, a organização institucional nacional e as instruções oficiais em vigor. Não se deve inventar um destinatário ou um procedimento com base num modelo interno.

Também é necessário definir quando a avaliação será atualizada. Uma alteração da finalidade, da população afetada, dos dados de entrada, da frequência de utilização, do nível de automatização, das medidas de supervisão ou das condições operacionais pode modificar a análise. Regista que alterações obrigam a reabrir a decisão, quem as deteta e quem pode suspender a utilização enquanto a análise é revista.

Responsabilidades internas a atribuir

FunçãoContributo esperadoEvidência a conservar
Responsável pelo processoFinalidade, etapas do processo e decisões influenciadas pelo sistemaMapa do processo, responsáveis operacionais e limites de utilização
Equipa técnica ou fornecedor, conforme aplicávelCapacidades, limitações, instruções e condições de utilização conhecidasDocumentação do sistema, versão e pressupostos comunicados
Privacidade e conformidadeAnálise das obrigações aplicáveis e coordenação com outras avaliaçõesConclusões, referências cruzadas e questões pendentes
Responsável pelos direitos fundamentaisIdentificação dos grupos afetados, dos possíveis danos e das medidas de respostaRiscos contextualizados, medidas e riscos residuais
Órgão de autorizaçãoDecisão de aprovar, impor condições, alterar ou suspenderRegisto da decisão, condições e data de revisão
04

O que documentar: da finalidade às pessoas afetadas

O artigo 27.º estabelece um conjunto essencial de informações que permite relacionar o sistema com o contexto da sua utilização. A avaliação deve descrever os processos em que o sistema será utilizado, de acordo com a finalidade prevista; o período e a frequência de utilização; as categorias de pessoas e grupos suscetíveis de serem afetados; os riscos específicos de danos nesse contexto, tendo em conta as informações pertinentes do fornecedor; a aplicação de medidas de supervisão humana; e as medidas a adotar se os riscos se concretizarem, incluindo disposições de governação interna e mecanismos de reclamação.

Para que estes elementos apoiem uma decisão, evita expressões vagas como «pode haver enviesamento» ou «será mantida supervisão humana». Explica quem pode ser prejudicado, em que etapa do processo, que consequência é plausível e que evidência permitiria detetá-la. Se o impacto depender de circunstâncias desconhecidas — por exemplo, a dimensão de um grupo afetado ou a qualidade de determinados dados — regista a incerteza em vez de a transformar numa afirmação.

As informações fornecidas pelo fornecedor podem ajudar a compreender as capacidades, limitações e riscos conhecidos do sistema, mas não substituem a análise do responsável pela implantação. O mesmo sistema pode ter consequências diferentes consoante os critérios de elegibilidade, os colaboradores que interpretam os resultados, a possibilidade de corrigir dados e os meios de que uma pessoa dispõe para contestar uma decisão. A avaliação deve refletir essas condições concretas.

A consulta de pessoas afetadas, representantes ou especialistas pode fornecer informações que não constam da documentação técnica. É importante distinguir a obrigação legal das boas práticas editoriais ou organizacionais: quando a norma não determina um método específico de consulta, regista a consulta como uma medida escolhida para melhorar a análise, e não como um requisito textual atribuído ao artigo.

Modelo de trabalho para cada risco

ElementoPergunta de trabalhoExemplo de evidência
ContextoEm que decisão ou etapa influencia o sistema?Diagrama do processo e descrição da utilização prevista
Pessoas afetadasQuem sofre o efeito direto ou indireto?Categorias de requerentes, utilizadores ou grupos expostos
Possível danoQue consequência concreta pode ocorrer?Atraso, exclusão, tratamento desigual ou dificuldade em contestar
Causa e condiçõesQue dados, regras ou práticas podem contribuir para o dano?Campos utilizados, limiares, instruções e práticas operacionais
Medida e responsávelQue ação reduz o risco e quem a executa?Teste, controlo, revisão humana ou canal de reclamação atribuído
Risco residualO que pode continuar a acontecer depois de aplicadas as medidas?Limitações pendentes e critérios para reconsiderar a utilização
05

Dos riscos às decisões: medidas, evidência e limites

Uma lista de riscos não é suficiente. Cada risco relevante deve estar associado a uma medida verificável, a um responsável, a um prazo e a evidência que permita confirmar se a medida funciona. Se uma medida depender de outra unidade, de uma funcionalidade ainda não implementada ou de uma validação pendente, não a descrevas como se já estivesse operacional. Trata-a como uma condição prévia à implantação.

As medidas podem incluir limitar a finalidade ou as pessoas elegíveis, reduzir a frequência de utilização, melhorar a qualidade dos dados, estabelecer limiares de revisão, testar os resultados para detetar diferenças relevantes, exigir revisão humana antes de uma decisão desfavorável, permitir correções e reclamações ou suspender o sistema perante sinais de dano. São opções que devem ser justificadas no contexto; não constituem uma lista exaustiva nem garantem, por si só, a conformidade.

A supervisão humana deve ser concreta e viável. Especifica quem faz a revisão, que informações recebe, que formação necessita, que margem tem para se afastar do resultado e como regista a decisão. Uma pessoa que apenas confirma automaticamente os resultados, sem tempo, informação ou autoridade para intervir, não constitui uma medida eficaz só por estar prevista num procedimento.

A autorização pode ser condicional. Por exemplo, pode permitir-se um projeto-piloto limitado apenas depois de concluídos os testes, validado o canal de reclamações e atribuídos recursos para a revisão. A decisão deve indicar critérios de suspensão ou alteração, como erros acima de um limiar previamente definido, reclamações que revelem um padrão, alterações não aprovadas do sistema ou incapacidade de realizar a supervisão prevista. Os limiares concretos devem resultar da avaliação e não ser inventados como valores universais.

Concluir o ciclo de decisão

  1. 01Formula o risco como uma relação entre o contexto, as pessoas e o possível dano; identifica o que é um facto conhecido e o que é uma hipótese.
  2. 02Escolhe uma medida proporcionada e define o responsável, o prazo, os recursos e o teste da sua eficácia.
  3. 03Regista o risco residual e determina se é aceitável para a entidade e compatível com as suas obrigações; não o ocultes sob a designação «mitigado».
  4. 04Estabelece condições explícitas: aprovar, aprovar com restrições, adiar até resolver as questões pendentes ou não implantar.
  5. 05Define o acompanhamento, as reclamações, os incidentes e os eventos de alteração que obrigam a rever ou suspender a utilização.
06

Relação com a AIPD: coordenar sem confundir

Uma AIPD, ou avaliação de impacto sobre a proteção de dados (DPIA, na sigla inglesa), é realizada ao abrigo do regime de proteção de dados quando o tratamento previsto pode implicar um elevado risco para os direitos e liberdades das pessoas. O seu foco é o tratamento de dados pessoais e as obrigações de proteção de dados; a avaliação prevista no artigo 27.º centra-se nos impactos sobre os direitos fundamentais decorrentes da utilização do sistema de IA, no âmbito previsto pelo AI Act. Pode haver interseção, mas os objetivos e âmbitos não são idênticos.

O artigo 27.º contempla a relação com as avaliações de proteção de dados. Além disso, as fontes oficiais fornecidas indicam que uma alteração de 2026 afeta a reutilização de elementos da AIPD e o questionário a elaborar pelo Serviço para a IA. Por conseguinte, não se deve aplicar automaticamente uma formulação anterior sobre se a avaliação deve complementar, reutilizar ou remeter para uma AIPD: é necessário ler a versão consolidada em vigor e as instruções oficiais para conhecer as condições atuais.

Como método de trabalho, mantém um mapa de correspondências. Assinala que análises da AIPD também informam sobre pessoas, dados ou riscos relevantes para a avaliação dos direitos fundamentais; que elementos exigem uma análise adicional; e que questões não são abrangidas por uma avaliação com a outra finalidade. As referências cruzadas reduzem duplicações, mas devem permitir que quem revê encontre a evidência e compreenda por que motivo é relevante para o ponto correspondente.

Se uma AIPD não for exigida no caso concreto, isso não demonstra que a avaliação do artigo 27.º também não se aplica. E, se existir uma AIPD, a sua mera existência não comprova que tenham sido abrangidos os riscos que não se limitam ao tratamento de dados. A entidade deve documentar a conclusão aplicável ao caso, a norma em vigor utilizada e as lacunas que ainda têm de ser resolvidas.

07

Caso prático: avaliação de pedidos de crédito

Suponhamos que uma entidade utiliza um sistema de risco elevado para apoiar a avaliação de pedidos de crédito. Este exemplo é hipotético: não afirma que exista um sistema específico, que determinada entidade tenha uma obrigação ou que tenham ocorrido danos. Antes de o aplicar, a organização teria de confirmar a classificação, o seu papel, a utilização prevista e as condições legais do caso.

Em primeiro lugar, representa-se o processo: que informações o sistema recebe, que resultado gera, quem o consulta e se esse resultado recomenda, ordena ou determina uma decisão. Descrevem-se também a frequência e o período de utilização. Uma análise que se limite a dizer «o modelo avalia o crédito» não esclarece se os colaboradores podem afastar-se da recomendação, se o resultado causa uma recusa automática ou se existe uma segunda revisão.

Em seguida, identificam-se as pessoas afetadas — por exemplo, requerentes e pessoas cujos dados influenciam indiretamente a avaliação — e formulam-se hipóteses de danos que a entidade tem de validar. Poderiam analisar-se a possibilidade de decisões desfavoráveis associadas a dados incompletos, efeitos desproporcionados em determinados grupos, erros difíceis de corrigir ou obstáculos à compreensão e contestação de uma decisão. Não são conclusões sobre um modelo real: exigem dados, testes e contexto.

As medidas devem responder às hipóteses. A entidade poderia verificar a origem e a qualidade dos dados, testar os resultados e as diferenças relevantes, impedir que uma pontuação seja o único fundamento de decisões desfavoráveis quando a análise indicar que é necessária uma revisão, formar os colaboradores, registar os motivos para se afastarem de uma recomendação e oferecer um mecanismo acessível para corrigir informações ou apresentar uma reclamação. É necessário especificar quem executa cada controlo e que resultado permitiria considerá-lo insuficiente.

Antes da aprovação, a instância responsável deveria confirmar que as medidas existem e que a supervisão dispõe de autoridade efetiva. Se faltarem resultados dos testes, não existir um canal de reclamações operacional ou não for possível explicar que informações fundamentam uma decisão, a resposta prudente poderá ser adiar, restringir ou não autorizar a implantação até resolver a questão. Essa conclusão cabe à entidade, com base nas suas próprias evidências; o exemplo não substitui a sua análise.

08

Lista de verificação antes de aprovar a utilização

Uma lista de verificação é útil se conduzir a uma decisão e não se transformar num exercício de assinalar caixas. Cada resposta deve ter uma fonte, um responsável e, quando aplicável, uma ação pendente. Mantém separados os requisitos legais identificados no texto em vigor e as práticas internas que a organização acrescenta para tornar a análise mais sólida.

Antes de concluir, verifica se o documento identifica com precisão o sistema, a sua versão, a finalidade, os processos afetados, o calendário e a frequência de utilização. Confirma se as pessoas e os grupos afetados estão descritos com suficiente precisão, se cada risco está associado a um possível dano naquele contexto e se foram consideradas as limitações e as informações pertinentes do fornecedor.

Confirma também que a supervisão humana existe na prática, que as medidas têm responsáveis e evidências e que os riscos residuais são conhecidos. Revê os mecanismos para detetar problemas, receber reclamações e responder a incidentes. Se foram consultadas pessoas afetadas ou especialistas, regista o contributo dessa consulta e as decisões que influenciou. Se não houve consulta, indica se essa ausência limita a análise.

Por último, verifica a comunicação à autoridade competente, as referências cruzadas com a AIPD quando aplicável, a data de revisão e as condições que obrigam a reabrir a avaliação. A aprovação deve indicar que versão da documentação foi analisada, que condições acompanham a utilização e quem tem autoridade para a suspender.

Verificação final

VerificaçãoEstado que permite avançarSe faltar
AplicabilidadeEntidade, sistema, utilização e exceção analisados e documentadosSubmeter a classificação a análise e não presumir que a obrigação não se aplica
Contexto de utilizaçãoProcesso, finalidade, duração e frequência descritosCompletar o mapa do processo com a área operacional
Pessoas e riscosGrupos afetados e possíveis danos identificados com evidências ou incertezasObter dados, consultar e validar hipóteses
MedidasResponsáveis, prazos, supervisão e reclamações definidosAtribuir recursos e tratar a medida como pendente
DecisãoRisco residual e condições de aprovação explícitosAdiar, restringir ou recusar até resolver o necessário
ManutençãoAlterações, acompanhamento, autoridade e revisão previstosDefinir controlos e confirmar o procedimento oficial
09

O que verificar antes de utilizar este guia

A avaliação deve basear-se na versão consolidada do AI Act em vigor na data relevante, e não apenas em resumos, projetos ou textos anteriores. As fontes fornecidas identificam uma alteração legislativa de 2026 e uma consolidação datada de julho de 2026; indicam também que a Comissão Europeia atualizou as suas perguntas frequentes em agosto de 2026. Como as regras e as datas podem mudar, confirma se essas versões correspondem ao momento e ao caso de utilização que estás a avaliar.

Verifica no texto oficial o âmbito exato dos responsáveis pela implantação abrangidos, as categorias de sistemas incluídas, a exceção, os elementos exigidos, a comunicação à autoridade e o efeito das alterações sobre a AIPD. Confirma também se já foram publicados formulários oficiais definitivos e como deve ser feita a notificação no Estado-Membro pertinente. Uma FAQ pode ajudar a orientar, mas não prevalece sobre o ato legislativo.

O calendário de aplicação merece uma verificação específica: a data relevante depende das disposições em vigor e da categoria concreta do sistema. Não deduzas uma data geral com base numa notícia ou numa versão anterior do Regulamento. Se houver dúvidas sobre o âmbito, a autoridade competente ou a interação com outras normas, solicita aconselhamento jurídico antes de autorizar a utilização.

Para alargar a análise, articula esta avaliação com os procedimentos internos da entidade em matéria de segurança e gestão de riscos, com o seu processo de comparação de sistemas e com a avaliação de alternativas antes da seleção de uma solução. Estas análises complementam a decisão, mas não substituem a avaliação legal quando esta for exigida.

Questões em aberto

  • As fontes fornecidas indicam uma alteração de 2026 e um texto consolidado de julho de 2026, mas este guia não reproduz nem interpreta exaustivamente todas as suas disposições. É necessário verificar no texto oficial em vigor o efeito exato sobre a reutilização de elementos da AIPD, o questionário do Serviço para a IA e os requisitos do artigo 27.º.
  • Não se determina qual é a autoridade nacional competente nem o procedimento de notificação para um caso concreto: isso depende da jurisdição e das instruções oficiais em vigor.
  • Não se define uma data geral de aplicação. O calendário deve ser verificado para a categoria e o caso concretos, tendo em conta as alterações legislativas em vigor.
  • O caso relativo ao crédito não contém dados de um sistema real. A existência, a dimensão e a distribuição dos riscos mencionados devem ser validadas pela entidade responsável pela implantação.
10

Continue a explorar

10

Fontes consultadas

03

Correções e transparência

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

Propor uma correção