O Regulamento da IA da UE para equipas que lançam funcionalidades de ML: orientação para quem constrói

Se está a lançar uma funcionalidade de ML ou IA na UE e se pergunta se o Regulamento da IA da UE se aplica ao seu produto, a resposta curta é: quase de certeza que o toca, mas a maioria das funcionalidades cai nos níveis mais leves, e o principal que deve hoje é transparência — dizer às pessoas quando estão a interagir com IA e identificar conteúdo gerado por IA. Esta é uma orientação para quem constrói, escrita por engenheiros que lançam estas funcionalidades para clientes. É informação geral, não aconselhamento jurídico. Para uma classificação efetiva do seu produto, recorra a aconselhamento jurídico qualificado.

Somos a Amplified Creations, um estúdio digital em Leiria e Lisboa. Construímos sistemas de recomendação, plataformas web e pipelines de captura, e quase tudo o que lançamos hoje tem uma componente de ML ou IA algalgures. Por isso, a pergunta "o Regulamento da IA aplica-se ao meu produto e quão arriscada é a minha funcionalidade?" é uma que temos de responder para o nosso próprio roteiro. Eis como pensamos sobre ela, em linguagem simples.

O Regulamento da IA da UE aplica-se ao meu produto?

O Regulamento da IA da UE é a regulação horizontal da União Europeia para a inteligência artificial. "Horizontal" significa que não é específico de um setor — aplica-se transversalmente com base naquilo que um sistema de IA faz e quão arriscada é essa utilização, e não no facto de estar nas finanças, no fitness ou no mobiliário. Entrou em vigor em 2024 e as suas obrigações entram em aplicação ao longo de um calendário de vários anos, e não todas de uma vez.

Alcança-o se colocar um sistema de IA no mercado da UE ou o puser em serviço na UE, ou se o resultado do seu sistema for utilizado na UE — mesmo quando a sua empresa está noutro lugar. A conclusão prática: se tem utilizadores na UE, assuma que está no âmbito e que a única pergunta real é qual o nível. Não importa que seja uma equipa pequena ou que o seu modelo seja um ranker de 200 linhas. A dimensão não isenta; a classificação de risco é que decide.

Uma definição útil à partida. O Regulamento distingue papéis. Um fornecedor desenvolve um sistema de IA e coloca-o no mercado em seu próprio nome. Um responsável pela implementação utiliza um sistema de IA sob a sua própria autoridade num contexto profissional. As obrigações diferem. Na maioria das vezes, quando constrói uma funcionalidade para o seu próprio produto, é o fornecedor; quando integra o modelo de outrem num fluxo de trabalho, pode ser responsável pela implementação, ou ambos. Isto importa porque as obrigações mais pesadas recaem sobretudo sobre os fornecedores de sistemas de risco elevado.

Os quatro níveis de risco, em linguagem simples

O Regulamento ordena os sistemas de IA num pequeno número de níveis de risco. Colocar a sua funcionalidade no balde certo é o jogo todo, porque as obrigações escalam com o nível.

Risco inaceitável — proibido

Um conjunto restrito de práticas é proibido de forma absoluta. Pense em pontuação social por autoridades públicas, certos tipos de sistemas manipuladores ou exploradores que causam dano, recolha não direcionada de imagens faciais para construir bases de reconhecimento, e a maioria da identificação biométrica remota em tempo real em espaços públicos. Se a sua funcionalidade está aqui, a resposta não é "cumprir" — é "não lançar". Para a esmagadora maioria das equipas de produto, nada do que está a construir vive neste nível. Vale a pena ler a lista uma vez para o poder descartar com confiança.

Risco elevado — obrigações mais pesadas

Este é o nível que carrega peso real de engenharia e de documentação. Os sistemas de risco elevado são, em termos gerais, IA usada como componente de segurança de um produto regulado, ou IA usada em domínios sensíveis específicos: coisas como recrutamento e gestão de trabalhadores, acesso à educação, acesso a serviços e benefícios privados e públicos essenciais, pontuação de crédito, certos usos em aplicação da lei e migração, e alguns casos biométricos e de infraestruturas críticas.

Se a sua funcionalidade decide quem é contratado, quem recebe um empréstimo ou quem entra numa escola, assuma que está dentro ou perto deste nível e procure aconselhamento cedo. Risco elevado não significa proibido — significa obrigações: um sistema de gestão de risco, governação de dados, documentação técnica, registos, supervisão humana, exatidão e robustez, e um processo de conformidade antes de chegar ao mercado. Isso é um verdadeiro programa de trabalho, não uma caixa para assinalar. A reação honesta de engenharia é que quer saber que está aqui antes de construir, não depois.

Risco limitado — deveres de transparência

É aqui que vive muita da IA de produto normal. "Risco limitado" é abreviatura para sistemas que não são de risco elevado mas interagem com pessoas de formas que as poderiam induzir em erro se não fossem reveladas. O dever aqui é a transparência, e é concreto:

• Se os utilizadores interagem com um sistema de IA como um chatbot, devem ser informados de que estão a lidar com uma máquina, salvo se for óbvio pelo contexto.
• Conteúdo gerado ou manipulado por IA — imagens, áudio e vídeo sintéticos e texto gerado publicado para informar o público — deve ser identificado como artificialmente gerado, de forma legível por máquina sempre que viável.
• Deep fakes e media sintética semelhante implicam expetativas de divulgação.

O objetivo destes deveres não é papelada; é que as pessoas não sejam enganadas sobre se está um humano ou uma máquina do outro lado. Se construir um chatbot com LLM, este nível é a sua base mesmo quando nada mais se aplica.

Risco mínimo — quase tudo o resto

A grande maioria da IA em produção — filtros de spam, widgets de recomendação, ordenação de pesquisa, previsão de inventário — situa-se no risco mínimo, onde o Regulamento não impõe obrigações específicas obrigatórias para além das regras que já se aplicam ao seu software (RGPD, direito do consumidor, e por aí adiante). Códigos de conduta voluntários são incentivados, mas não está a carregar um programa de conformidade só pela parte de IA.

Porque é que um pequeno ranker explicável é mais leve do que um chatbot LLM

Eis a parte que realmente muda a forma como construímos. Duas funcionalidades podem ser ambas "IA" e cair em níveis muito diferentes, e é a opção de design que conduz a diferença.

Veja o nosso trabalho no Jofit, uma app de bem-estar com um sistema de recomendação que sugere sessões. É um ranker pequeno e explicável — não um modelo de linguagem grande. Pontua um conjunto delimitado de opções face a características que escolhemos e podemos inspecionar, e podemos dizer, para qualquer recomendação, porque foi ordenada como foi. Como não é usado para decidir contratação, crédito, educação ou outro domínio de risco elevado, e como não é um agente conversacional a fingir-se de humano, situa-se tipicamente em terreno de risco mínimo ou, no máximo, limitado. Não precisamos de uma etiqueta de deep fake numa sugestão de treino.

Agora contraste com um chatbot LLM. No momento em que uma funcionalidade fala com os utilizadores em linguagem natural como se fosse uma pessoa, o dever de transparência de risco limitado aplica-se — tem de revelar que é IA. Se esse chatbot também gerar conteúdo publicado para o público, as expetativas de identificação acumulam-se por cima. E os modelos de IA de finalidade geral que estão por baixo têm as suas próprias obrigações do lado do fornecedor quanto a documentação e, para os modelos mais capazes, deveres de risco sistémico. Nada disto torna os LLM impossíveis de lançar. Significa que um sistema conversacional opaco atrai mais obrigações, por desenho, do que um ranker transparente a fazer um trabalho restrito.

Isto não é uma conclusão jurídica sobre nenhum produto específico — a sua classificação depende do seu uso real, do seu domínio e de factos que não vemos daqui. É o padrão que usamos para orientar a arquitetura cedo, e depois confirmamos com aconselhamento jurídico.

O que a Amplified Creations efetivamente faz quanto a isto

Inclinamo-nos fortemente para ML pequeno, explicável e documentável em vez de LLM opacos sempre que o trabalho o permite, e o Regulamento da IA é uma de várias razões. Um ranker explicável como o do Jofit é auditável: podemos escrever as características, a lógica de pontuação e as fontes de dados, e reconstruir qualquer decisão. Essa mesma documentação que torna um modelo depurável também o torna defensável se um regulador ou cliente alguma vez perguntar como funciona.

Concretamente, a higiene de documentação que mantemos ajuda independentemente do nível em que uma funcionalidade caia. No nosso trabalho de ML mantemos uma descrição simples do que o sistema faz e do seu propósito pretendido, de onde vêm os dados de treino e de entrada, quais são as limitações conhecidas, que supervisão humana existe no circuito, e um registo de alterações das versões do modelo. Do lado web, a nossa stack — PHP 8.3, Cockpit CMS, páginas renderizadas no servidor com JSON-LD completo e analítica sem cookies, focada na privacidade — está construída para não andarmos discretamente a recolher ou inferir coisas que depois teríamos de explicar. Quando introduzimos uma funcionalidade conversacional ou generativa, acrescentamos a divulgação "está a falar com IA" e a identificação de conteúdo como parte da construção, não como remendo posterior. Não afirmamos certificar a conformidade de ninguém; somos engenheiros, e trazemos aconselhamento jurídico qualificado para as questões de classificação e conformidade.

A versão curta

• Assuma o âmbito. Se tem utilizadores na UE, o Regulamento da IA provavelmente aplica-se; a pergunta real é qual o nível.
• Quatro níveis: inaceitável (proibido), risco elevado (obrigações pesadas), risco limitado (deveres de transparência), risco mínimo (quase tudo, poucos deveres específicos).
• A transparência é a base comum: diga aos utilizadores quando estão a falar com IA e identifique conteúdo gerado por IA.
• O design conduz o nível. Um pequeno ranker explicável costuma ficar leve; um chatbot LLM atrai transparência e, muitas vezes, mais.
• A higiene de documentação compensa de qualquer forma. Escreva propósito, dados, limitações, supervisão e versões.
• Procure aconselhamento para a classificação. Isto é orientação, não aconselhamento jurídico.

Perguntas frequentes

O Regulamento da IA da UE aplica-se ao meu produto se a minha empresa estiver fora da UE?

Muito provavelmente sim. O Regulamento pode alcançar fornecedores e responsáveis pela implementação fora da UE quando um sistema de IA é colocado no mercado da UE ou o seu resultado é utilizado na UE. Ter sede noutro lugar não o isenta por si só. Confirme a sua situação específica com aconselhamento jurídico qualificado.

Um sistema de recomendação é de risco elevado ao abrigo do Regulamento da IA?

Normalmente não, por si só. Um sistema de recomendação usado para conteúdo, produtos ou sessões situa-se tipicamente em terreno de risco mínimo ou limitado. Tende para risco elevado apenas quando é usado para decidir coisas em domínios sensíveis como emprego, crédito ou acesso a serviços essenciais. O seu uso real determina o nível, por isso confirme a classificação com um advogado.

Qual é, na prática, a obrigação de transparência?

Sobretudo duas coisas: dizer aos utilizadores quando estão a interagir com um sistema de IA como um chatbot, salvo se for óbvio, e identificar conteúdo gerado ou manipulado por IA como artificialmente gerado. O objetivo é que as pessoas não sejam enganadas sobre se foi um humano ou uma máquina a produzir o que estão a ver.

Preciso de um programa de conformidade para uma funcionalidade de risco mínimo?

Não especificamente pelo Regulamento da IA. Os sistemas de risco mínimo não carregam obrigações específicas obrigatórias do Regulamento da IA para além das leis que já se aplicam ao seu software, como proteção de dados e regras do consumidor. Os códigos voluntários são incentivados, mas não exigidos.

Porque é que a Amplified Creations prefere ML explicável a LLM?

Porque modelos pequenos e explicáveis são auditáveis e documentáveis, o que mantém as obrigações mais leves e as decisões defensáveis. Conseguimos reconstruir porque é que uma recomendação aconteceu, o que ajuda na depuração, com clientes e em qualquer questão regulatória — sem a carga mais pesada de transparência e documentação que um sistema conversacional opaco tende a atrair.