Agentes de IA que alteram registos: quem responde ao abrigo do AI Act

O caso: um pedido, uma ferramenta e um registo alterado

Imaginemos que alguém pede a atualização da morada de um cliente. Um agente interpreta o pedido, consulta um sistema empresarial, verifica alguns dados e envia uma instrução que altera o registo. A questão jurídica não se resolve chamando-lhe «agente» nem constatando que atua sem confirmação em cada etapa. Primeiro, é necessário definir que sistema foi colocado em serviço, com que finalidade e por que entidade.

O Regulamento (UE) 2024/1689, conhecido como AI Act, não cria uma categoria regulatória separada para os agentes. A Comissão indica que um agente costuma incluir pelo menos um modelo de IA de finalidade geral e pode constituir um sistema de IA. Isso não significa que cada agente, enquanto conjunto técnico ou produto comercial, tenha necessariamente uma classificação única: podem estar envolvidos vários sistemas, componentes e organizações com funções diferentes.

Para analisar o exemplo, é preciso descrever o fluxo concreto: quem disponibiliza o sistema, quem o configura, que ferramentas liga, quem autoriza as instruções e que decisão produz a alteração. Também importa saber se o agente apenas prepara uma proposta ou se executa a alteração, e se a finalidade é uma tarefa administrativa corrente ou uma atividade abrangida por uma área regulada pelo Regulamento. A ação externa é relevante para a análise operacional, mas, por si só, não basta para concluir que o sistema é de alto risco.

O que se segue é um mapa geral do AI Act, não uma determinação jurídica sobre uma implementação específica. A distribuição de papéis depende de factos verificáveis e da relação entre os participantes, não apenas do nome dado internamente ao produto.

Sistema, modelo, agente e papéis: conceitos distintos

O Regulamento define «sistema de IA» atendendo a características como o funcionamento com diferentes níveis de autonomia, a capacidade de inferência e a produção de resultados — por exemplo, previsões, conteúdos, recomendações ou decisões — que podem influenciar ambientes físicos ou virtuais. A Comissão publicou orientações para ajudar a interpretar essa definição. A análise deve centrar-se na solução concreta e nas suas capacidades, não numa etiqueta comercial como «agente», «copiloto» ou «automação inteligente».

Um modelo de IA e um sistema de IA não são sinónimos. Um modelo pode ser um componente do sistema; o sistema abrange a forma como o modelo é integrado, disponibilizado e utilizado. Por sua vez, «agente» costuma descrever uma arquitetura ou um modo de funcionamento que pode combinar um modelo, instruções, ferramentas, memória e mecanismos de execução. Essa descrição técnica não substitui as definições do Regulamento.

Em termos gerais, «prestador» é quem desenvolve um sistema de IA ou um modelo de IA de finalidade geral, ou manda desenvolvê-lo, e o coloca no mercado ou em serviço sob o seu nome ou marca, nas condições previstas pelo Regulamento. «Responsável pela implantação» é quem utiliza o sistema sob a sua autoridade, salvo no caso de uso pessoal não profissional. O papel depende do que a entidade faz e de como disponibiliza ou utiliza o produto; pode variar entre componentes da mesma solução.

«Integrador» não é, por si só, uma categoria geral de operador equivalente a prestador ou responsável pela implantação no AI Act. Uma empresa que liga ferramentas pode limitar-se a integrar um sistema, ou as suas ações podem colocá-la noutro papel, conforme os factos. O artigo 25.º prevê situações em que um distribuidor, importador, responsável pela implantação ou outro terceiro passa a ser considerado prestador de um sistema de alto risco, por exemplo, se o comercializar sob o seu nome, o modificar substancialmente ou alterar a finalidade prevista de modo a torná-lo de alto risco. Nem toda a configuração ou integração produz automaticamente esse efeito.

No caso do registo, o prestador poderia ser quem disponibiliza o sistema agêntico sob a sua marca; a empresa cliente poderia ser responsável pela implantação se o utilizar sob a sua autoridade; e uma empresa tecnológica poderia prestar serviços de integração. Mas esses rótulos são hipóteses de trabalho, não conclusões: os contratos, a apresentação no mercado, o controlo sobre a conceção e as alterações efetuadas podem mudar o enquadramento.

A finalidade, e não a autonomia isolada, orienta a classificação

O AI Act não classifica como de alto risco todo o sistema que tenha autonomia, aceda a uma ferramenta ou produza um efeito externo. A classificação depende dos critérios e domínios definidos no Regulamento, nomeadamente de saber se o sistema é um componente de segurança de um produto abrangido pela legislação enumerada ou se corresponde a um dos casos de utilização do anexo III, tendo em conta as condições e exceções aplicáveis.

No exemplo, alterar a ficha de um cliente não permite, por si só, afirmar que o sistema é de alto risco. É necessário identificar a finalidade prevista do sistema e o setor e processo em que opera. A análise pode mudar se o sistema for utilizado, por exemplo, para uma função expressamente incluída num domínio do anexo III, ou se fizer parte de um produto regulamentado nos termos do Regulamento. O simples tratamento de dados pessoais por uma empresa, a existência de automatização ou a importância comercial de uma ação não bastam.

A finalidade prevista é determinada a partir do que o prestador pretende que o sistema faça, tal como se reflete nas instruções, na documentação técnica e nos materiais de comercialização, além do contexto de utilização que seja pertinente. Também é necessário distinguir essa finalidade de um uso efetivo que se afaste do previsto. Se o responsável pela implantação modificar o sistema ou alterar a sua finalidade, poderá ser necessário reavaliar tanto a classificação como a entidade que assume as obrigações de prestador.

A Comissão indica que os agentes costumam incluir pelo menos um modelo de finalidade geral e podem constituir um sistema de IA. Na prática, isso significa examinar separadamente as regras aplicáveis ao modelo e ao sistema integrado, sem inferir que a presença de um modelo de finalidade geral determina, por si só, a classificação do sistema completo.

A autonomia é relevante para descrever o funcionamento e avaliar os controlos adequados. Por exemplo, não é equivalente o sistema sugerir uma alteração que uma pessoa executa, aplicá-la depois de uma aprovação específica ou fazê-lo automaticamente. Essa diferença pode alterar a avaliação operacional, mas não substitui os critérios jurídicos de classificação do AI Act.

Responsabilidades: distinguir as obrigações relativas ao sistema das relativas à utilização empresarial

O Regulamento distribui obrigações de acordo com o papel desempenhado e a categoria do sistema. Por isso, não é correto atribuir todas as obrigações ao programador do modelo, nem transferi-las automaticamente para a empresa cliente. Um fluxo pode implicar obrigações para mais de uma entidade, mas só depois de determinar que sistema está em análise, que regras lhe são aplicáveis e quem corresponde a cada definição.

Para os sistemas de alto risco, o artigo 16.º estabelece obrigações do prestador, incluindo assegurar a conformidade com os requisitos aplicáveis, dispor de um sistema de gestão da qualidade, conservar documentação e cumprir as obrigações de avaliação da conformidade, registo e outros requisitos indicados nesse artigo. Esta referência não transforma qualquer agente num sistema de alto risco nem significa que a empresa que o integra seja sempre o seu prestador.

O artigo 26.º regula as obrigações dos responsáveis pela implantação de sistemas de alto risco. Entre outros aspetos, exige que utilizem o sistema de acordo com as instruções de utilização, atribuam a supervisão humana a pessoas com competência e autoridade adequadas e acompanhem o funcionamento nas condições previstas. O âmbito concreto depende de se tratar efetivamente de um sistema de alto risco e das disposições aplicáveis. Não se deve generalizar este requisito como uma obrigação do AI Act para toda a ação automatizada.

O artigo 25.º pode alterar a distribuição de papéis quando uma entidade muda a função que desempenha relativamente a um sistema de alto risco: por exemplo, se o colocar no mercado sob o seu próprio nome ou marca, proceder a uma modificação substancial ou alterar a sua finalidade prevista de modo a que passe a ser de alto risco. A avaliação exige examinar que alteração foi feita e como afeta o sistema; ligar uma API ou alterar um modelo de formulário não corresponde necessariamente a essas situações.

O artigo 4.º determina que os prestadores e os responsáveis pela implantação adotem medidas para assegurar, na medida do possível, um nível suficiente de literacia em IA do seu pessoal e de outras pessoas que operem ou utilizem sistemas em seu nome, tendo em conta os conhecimentos, a experiência, a formação, o contexto de utilização e as pessoas afetadas. Esta obrigação não substitui a análise dos papéis nem transforma as recomendações de conceção deste texto em exigências legais.

Também podem ser pertinentes outras normas europeias ou nacionais, dependendo dos dados tratados, da decisão automatizada, do setor e das consequências. Esta análise limita-se a situar as questões no âmbito do AI Act e não determina obrigações decorrentes de outros regimes.

Permissões, aprovação e registos: controlos prudenciais

Embora o AI Act não transforme automaticamente cada controlo técnico imaginável numa obrigação geral, um agente com capacidade para escrever em sistemas empresariais deve ter limites operacionais proporcionais. Restringir as ferramentas disponíveis, o âmbito dos dados e as operações permitidas reduz o impacto potencial de erros, instruções mal interpretadas ou falhas de integração. Estas são recomendações de conceção e segurança, não afirmações de que cada uma é exigida pelo AI Act em todas as implementações.

Uma prática útil consiste em atribuir apenas as permissões mínimas: permitir que o agente consulte apenas os campos necessários e separar a leitura da escrita. Se uma atualização puder causar danos significativos ou for difícil de reverter, poderá ser necessária aprovação humana antes da execução. Para alterações rotineiras, a conceção poderá permitir a execução automática dentro de limites estreitos, com validações prévias e um mecanismo de reversão. A decisão depende do impacto e do contexto, não de uma fórmula única.

Os registos operacionais podem ajudar a reconstituir que pedido originou uma ação, que dados ou ferramentas foram utilizados, que instrução foi enviada, que resultado o sistema devolveu e se uma pessoa interveio. Convém definir o acesso, a conservação e a proteção desses registos em conformidade com as normas aplicáveis. Registar uma ação não demonstra, por si só, que a implementação está conforme, nem substitui a documentação ou os registos legalmente exigidos, quando aplicáveis.

A intervenção humana é uma medida de conceção adequada quando o sistema deteta dados incompletos, uma instrução ambígua, uma operação fora do padrão autorizado ou uma falha de ferramenta. É necessário definir quem recebe o caso, que informação obtém e se pode interromper ou corrigir a operação. Nos sistemas de alto risco, o artigo 26.º contém requisitos específicos de supervisão humana para os responsáveis pela implantação; noutros casos, a recomendação prudencial não deve ser apresentada como uma obrigação equivalente do AI Act.

Estas medidas ajudam a controlar ações externas, mas não resolvem a classificação jurídica. Uma implementação tecnicamente controlada pode continuar a exigir uma análise da finalidade e dos papéis; e uma classificação de alto risco não fica satisfeita apenas por se limitarem as permissões.

Datas de aplicação e limites temporais

O calendário deve ser consultado no Regulamento oficial, distinguindo a entrada em vigor da aplicação efetiva de cada obrigação. O Regulamento (UE) 2024/1689 entrou em vigor a 1 de agosto de 2024. A regra geral determina que será aplicável a partir de 2 de agosto de 2026, mas o artigo 113.º fixa datas anteriores para partes específicas e uma data posterior para determinados sistemas de alto risco integrados em produtos regulamentados.

A partir de 2 de fevereiro de 2025, aplicam-se os capítulos I e II, nos termos do artigo 113.º. Isto inclui, entre outras disposições, as definições do capítulo I, a literacia em IA do artigo 4.º e as práticas proibidas do artigo 5.º. Esta data não significa que o regime completo dos sistemas de alto risco se aplique desde então.

A partir de 2 de agosto de 2025, aplicam-se, entre outras, as disposições do capítulo V relativas aos modelos de IA de finalidade geral, bem como as normas institucionais e as regras sancionatórias indicadas no artigo 113.º. Para os prestadores de modelos de IA de finalidade geral colocados no mercado antes de 2 de agosto de 2025, o artigo 111.º prevê uma disposição transitória: devem cumprir as obrigações aplicáveis, o mais tardar, até 2 de agosto de 2027.

A aplicação geral começa em 2 de agosto de 2026. Para os sistemas de alto risco contemplados no artigo 6.º, n.º 1, que sejam componentes de segurança de produtos ou produtos sujeitos à legislação de harmonização enumerada no anexo I, o artigo 113.º indica a data de 2 de agosto de 2027. O artigo 111.º também contém regras transitórias para sistemas de alto risco já colocados no mercado ou em serviço antes de 2 de agosto de 2026; o seu alcance depende de se verificarem alterações significativas na conceção e de outras condições previstas no texto.

Por isso, não basta citar uma data geral no planeamento empresarial. É necessário associar cada obrigação ao respetivo artigo, categoria e disposição transitória, e verificar se o sistema ou modelo já estava no mercado ou em serviço na data relevante. Este resumo reflete o texto do Regulamento (UE) 2024/1689 indicado nas fontes fornecidas; qualquer alteração legislativa posterior deve ser novamente verificada na versão oficial antes de se tomarem decisões.

Lista de verificação antes da implantação

Comece por delimitar o objeto: está a analisar um modelo, um sistema que o integra ou um fluxo com vários sistemas? Desenhe a cadeia desde o pedido até à alteração do registo e indique que componente gera cada resultado. Identifique se existe uma ação externa e que entidade controla a sua execução.

Em seguida, determine os papéis com base em provas concretas: a marca sob a qual o sistema é disponibilizado, os contratos, a documentação, quem encomenda ou realiza alterações, quem decide a finalidade e quem o utiliza sob a sua autoridade. Verifique especialmente se uma alteração pode ser substancial ou se a finalidade prevista foi alterada de modo a afetar a categoria do sistema.

Avalie a classificação sem atalhos: identifique a finalidade prevista, consulte os critérios do artigo 6.º e os domínios pertinentes dos anexos e verifique as exceções ou condições. Se a informação não permitir uma conclusão, registe a questão como pendente e solicite uma análise jurídica ou regulamentar antes de afirmar que o sistema é ou não é de alto risco.

Por último, distinga o que é legalmente exigido das medidas prudenciais: determine que disposições se aplicam ao papel de cada entidade e ao sistema concreto; registe as datas e as transições; e defina permissões, aprovações, registos e escalonamentos como controlos operacionais com responsáveis e critérios verificáveis. O resultado deve poder ser revisto se mudarem o modelo, as ferramentas, a finalidade, o setor ou a forma de utilização.

Esta lista organiza a verificação inicial, mas não substitui aconselhamento jurídico sobre um produto ou uma implantação específicos. Também não é um guia completo de gestão de riscos, conformidade dos prestadores, avaliação de impacto ou documentação de decisões. O objetivo é evitar que a autonomia do agente seja usada como substituto de uma análise baseada no texto legal e em factos demonstráveis.

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.