AI Act em 2026: como decidir se um sistema de IA aciona obrigações, quais evidências reunir e quando uma pessoa deve intervir

Escopo deste guia: uma decisão rastreável, não um parecer jurídico

Este guia destina-se a equipas de produto, segurança, conformidade, compras e tecnologia que desenvolvem, integram, distribuem ou utilizam sistemas de IA relacionados com o mercado da União Europeia. O seu objetivo é converter um caso de uso numa ficha auditável: o que o sistema faz, quem intervém na cadeia de fornecimento, onde é utilizado, que categoria pode ser relevante, quais as obrigações em vigor e que evidência existe.

Não pretende resolver de forma conclusiva a classificação jurídica de um produto específico. A aplicação do Regulamento da IA depende dos factos, da finalidade prevista, da configuração real, dos intervenientes que tomam decisões e, em determinados setores, de normas adicionais. Privacidade, emprego, crédito, produtos de saúde, aviação, biometria e prestação de serviços públicos podem exigir avaliações ao abrigo de enquadramentos distintos.

As datas são importantes, mas não existe uma única data de aplicação para todo o Regulamento. A Comissão Europeia apresenta um calendário faseado: algumas regras, incluindo as relativas a práticas proibidas e à literacia em IA, começaram a aplicar-se antes do regime geral. Além disso, uma alteração legislativa posterior modifica o calendário de determinadas obrigações aplicáveis a sistemas de alto risco.

Utilize este artigo como um procedimento de governação. Para explorar controlos operacionais, consulte a secção Segurança; para avaliar alternativas técnicas e fornecedores, a secção Comparar; e para contextualizar capacidades e casos de uso, a secção Descobrir.

Passo 1: delimite o caso de uso antes de avaliar o risco

A unidade de análise não deve ser apenas o nome comercial de uma ferramenta. Pode ser uma funcionalidade específica, uma versão de modelo, um fluxo automatizado ou uma integração. Um mesmo produto pode ter funções com níveis de exposição diferentes: resumir documentos internos não é equivalente a priorizar pessoas para uma prestação, nem a executar alterações numa conta externa.

Documente a finalidade prevista declarada por quem oferece o sistema e a finalidade efetiva que a sua organização configura ou permite. Inclua os territórios de colocação no mercado, utilização ou disponibilidade de resultados; os grupos potencialmente afetados; o ambiente de utilização; a fase do ciclo de vida; as interfaces; e as ações posteriores habilitadas. Conserve capturas de configuração, contratos, instruções, avaliações e versões.

Identifique também se está perante um modelo de finalidade geral, um sistema construído sobre esse modelo ou ambos. As orientações da Comissão sobre modelos de IA de finalidade geral são interpretativas e ajudam a separar as obrigações do fornecedor do modelo das do interveniente que oferece ou utiliza um sistema a jusante. Não substituem a norma nem uma interpretação judicial.

Passo 2: identifique o papel pela atividade, não pela designação no contrato

Uma organização pode desempenhar mais de um papel em relação a produtos ou componentes distintos. O título de um contrato — por exemplo, «cliente», «parceiro» ou «revendedor» — não determina, por si só, o resultado. O que é relevante para a análise é qual interveniente desenvolve, manda desenvolver, comercializa, coloca em serviço, importa, distribui, altera ou utiliza o sistema sob a sua autoridade.

Como enquadramento operacional, considere como possível fornecedor o interveniente que desenvolve um sistema ou modelo, ou manda desenvolvê-lo, e o comercializa ou coloca em serviço sob o seu nome ou marca. Considere como possível utilizador o interveniente que utiliza um sistema sob a sua autoridade, exceto em utilizações pessoais não profissionais. Importador e distribuidor são papéis na cadeia comercial que exigem rever como o sistema é introduzido ou disponibilizado na União. A figura do mandatário exige uma designação e um mandato verificáveis.

Uma alteração substancial, uma mudança de finalidade ou a comercialização sob marca própria são sinais para interromper o fluxo automático e solicitar uma análise especializada. As orientações disponíveis sobre o âmbito das obrigações dos fornecedores de modelos de IA de finalidade geral abordam, entre outros aspetos, a identificação do fornecedor, a colocação no mercado e as alterações; a sua condição de guia interpretativo deve ficar registada no processo.

Passo 3: classifique a utilização e separe categorias que não são intercambiáveis

Comece por excluir se o caso pode estar relacionado com uma prática proibida. As práticas proibidas têm um regime de aplicação anterior ao calendário geral. A Comissão publicou orientações sobre essas práticas; são úteis para estruturar perguntas e exemplos, mas a interpretação autoritativa final compete aos tribunais competentes da União.

Depois, avalie, sem assumir o resultado, quatro planos distintos: se o sistema pode enquadrar-se como de alto risco por ser um componente de segurança de um produto regulamentado ou por outro pressuposto regulado; se o seu caso de uso pode integrar categorias de alto risco; se aciona deveres de transparência; e se intervém um modelo de finalidade geral. Um sistema pode exigir transparência sem ser de alto risco. Um modelo de finalidade geral não equivale automaticamente a um sistema de alto risco utilizado por um terceiro.

Não transforme uma lista de setores num diagnóstico. A finalidade concreta, o efeito sobre as pessoas, a autonomia operacional, o contexto de implementação e as exceções aplicáveis podem alterar a conclusão. Se o sistema afetar emprego, educação, acesso a serviços essenciais, crédito, saúde, biometria, administração da justiça ou serviços públicos, estabeleça uma revisão jurídica e setorial como condição de saída.

Passo 4: construa uma cronologia por obrigação e condição

O planeamento deve associar cada obrigação a uma condição de ativação, e não limitar-se a uma data global. O enquadramento da Comissão indica que as práticas proibidas e as obrigações de literacia em IA são aplicáveis desde 2 de fevereiro de 2025. As obrigações relativas a modelos de finalidade geral e determinadas disposições de governação começaram antes do regime geral, em 2 de agosto de 2025. O regime geral tem como referência 2 de agosto de 2026, sujeito às exceções previstas.

Para alto risco, não reutilize automaticamente as datas anteriores. A alteração legislativa publicada em 2026 adia a aplicação ligada aos sistemas do anexo III e aos sistemas relacionados com o anexo I segundo um calendário diferenciado: 2 de dezembro de 2027 para um grupo e 2 de agosto de 2028 para o outro. A correspondência concreta deve ser validada face ao texto consolidado e à situação do sistema.

As orientações de transparência publicadas pela Comissão em 2026 apresentam-se como orientação sobre o âmbito prático das obrigações aplicáveis desde 2 de agosto de 2026. Utilize-as para conceber controlos e evidência, não para substituir a análise do texto legal ou de atos posteriores.

Passo 5: traduza requisitos em evidências operacionais

Uma obrigação só é gerível se estiver associada a um responsável, uma fonte, uma data, uma versão e uma prova de execução. O processo não deve consistir numa declaração comercial genérica. Deve permitir reconstruir que sistema foi avaliado, para que finalidade, com que configuração, que controlos foram aplicados e que decisão foi tomada.

Para um caso que possa ser de alto risco, as áreas habitualmente relevantes incluem gestão de riscos, governação e qualidade dos dados quando aplicável, documentação técnica, registos, informação para utilizadores, supervisão humana, exatidão, robustez e cibersegurança. A aplicabilidade concreta depende da classificação e do papel. Não declare que um controlo cumpre um requisito se o seu âmbito, teste e evidência não tiverem sido verificados.

A supervisão humana também não se demonstra com a frase «existe uma pessoa no circuito». Descreva o que a pessoa consegue ver, quando intervém, que autoridade tem para ignorar ou interromper uma saída, que formação recebe, como são geridos os alertas e o que acontece perante automatização excessiva. Se não conseguir intervir materialmente antes de uma consequência relevante, documente essa limitação.

Passo 6: aplique a análise a compras e integração de terceiros

Comprar um sistema ou uma API não elimina as responsabilidades de quem o configura e utiliza. A organização compradora deve distinguir a documentação recebida do fornecedor da evidência gerada sobre a sua própria implementação. Por exemplo, o fornecedor pode disponibilizar instruções, características declaradas e documentação de conformidade, quando aplicável; o utilizador deve conseguir explicar a finalidade local, os utilizadores autorizados, os dados ligados, as permissões e as decisões tomadas após uma saída.

Inclua questões de conformidade na seleção, no contrato, na aceitação técnica e na revisão periódica. Peça informação com um nível de detalhe proporcional à utilização prevista. Se o fornecedor se recusar a identificar a versão, alterações relevantes, limitações conhecidas, condições de utilização ou mecanismo de incidentes, trate a ausência de informação como um risco de aquisição, e não como uma questão administrativa menor.

O Código de Boas Práticas para IA de finalidade geral, publicado em 2025 e considerado pela Comissão uma ferramenta voluntária adequada, pode ser um sinal documental útil em alguns casos. Não equivale, por si só, a demonstrar conformidade legal nem substitui a evidência específica do sistema integrado.

Três cenários: que factos alteram a análise

Cenário um: um assistente interno redige rascunhos a partir de documentos que a equipa carrega manualmente. Se não decide sobre pessoas, não executa ações externas e é utilizado com revisão humana substantiva, o processo pode inicialmente centrar-se em finalidade, dados, informação aos utilizadores, permissões, fornecedores e formação. Contudo, a classificação muda se os rascunhos forem utilizados para decisões de emprego, crédito, saúde ou acesso a serviços sem uma revisão efetiva.

Cenário dois: um sistema prioriza pedidos de clientes. O nome «priorização» não resolve nada. Importa saber se ordena apenas uma fila operacional ou se determina, na prática, quem recebe um serviço, em que prazo, em que condições e com que possibilidade de correção. Devem ser documentadas variáveis, regras, métricas, enviesamentos conhecidos, responsáveis pela anulação e efeitos dos falsos positivos e negativos.

Cenário três: um agente pode enviar e-mails, alterar registos ou acionar ações em ferramentas externas. O facto decisivo não é utilizar linguagem natural, mas o âmbito das suas permissões, a reversibilidade das ações, os limiares de autorização, a identidade que executa a ação e os controlos prévios e posteriores. Uma ampla capacidade de execução pode exigir uma avaliação de segurança mais intensa, mesmo quando a classificação regulamentar permaneça incerta.

Modelo textual de ficha de aplicabilidade

Mantenha uma ficha por caso de uso e atualize-a quando mudar a finalidade, o modelo, a integração, o fornecedor, os dados ou a população afetada. A ficha deve poder ser lida por produto, segurança, compras e conformidade sem os obrigar a reconstruir decisões a partir de mensagens ou reuniões isoladas.

É preferível registar incerteza explícita a encerrar uma classificação sem base suficiente. Assinale que conclusão é um facto documentado, que elemento é uma análise interna e que assunto aguarda confirmação jurídica, técnica ou contratual.

Erros frequentes e quando interromper para escalar

Um erro habitual é assumir que o fornecedor absorve toda a responsabilidade. Outro é aceitar uma declaração comercial de conformidade sem verificar que produto, versão, finalidade e interveniente abrange. Também é frequente utilizar uma data única para todo o Regulamento, ou transformar a avaliação de riscos numa caixa de verificação que não é revista após uma alteração técnica ou de contexto.

Interrompa a implementação ou a expansão e escale para aconselhamento jurídico quando existir uma possível prática proibida; incerteza razoável sobre alto risco; tratamento sensível ou decisões com efeito significativo sobre pessoas; biometria; emprego; crédito; saúde; educação; serviços públicos; atividade policial ou judicial; comercialização transfronteiriça complexa; alteração substancial; ou conflito entre a finalidade declarada e a utilização real.

Escalar não equivale a bloquear permanentemente o produto. Significa formular uma pergunta concreta, anexar factos e evidências, identificar a decisão pendente e preservar uma versão do sistema avaliado. Esta disciplina permite que a revisão jurídica, de privacidade, de segurança ou de direitos fundamentais seja mais rápida e verificável.

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.