Recebeu o email do tipo 'vamos auditar e certificar a sua IA'? Um mapa prático do que o EU AI Act exige de facto, dividido entre os produtos que constrói e o website em que os divulga.
Se gere algo com "IA" no meio, é provável que já tenha recebido o email. Um consultor, um "professor afiliado" ou um organismo de certificação a oferecer-se para auditar a sua IA e certificá-la face ao Regulamento de IA da UE (AI Act). O argumento de venda assenta na urgência e na dimensão das coimas. A maior parte é meia-verdade, e a metade que é verdadeira raramente é a parte que estão a vender.
Isto é um mapa prático. Separa o que o AI Act exige de facto do ruído, e divide a questão nos dois sítios onde ela realmente recai: os produtos que constrói e o website em que os divulga. Escrevemo-lo depois de auditar o nosso próprio site e de receber os mesmos emails que está a receber.
A coisa mais vendida é um certificado. Para a maior parte da IA, esse certificado não existe.
O AI Act regula sistemas de IA, ordenados por risco. Apenas os sistemas de alto risco passam por uma avaliação de conformidade e ostentam a marcação CE. Para a maioria das categorias de alto risco, essa avaliação é interna: faz-se a si próprio, documenta-se e assina-se uma declaração de conformidade. Um terceiro, um "organismo notificado" designado por um Estado-Membro, só é exigido para um conjunto restrito, como certos sistemas biométricos. Há muito poucos organismos notificados, e uma consultora genérica não é um deles.
Por isso, quando alguém se oferece para "certificar a sua empresa ou a sua IA como conforme com o AI Act", faça uma pergunta: são um organismo notificado, e que categoria vos exige? Para quase tudo, a resposta honesta é que o que vendem é um relatório de garantia privado, não uma certificação reconhecida. Isso ainda pode ser útil. Apenas não é o que a palavra "certificado" dá a entender.
Cada sistema de IA cai num de quatro grupos:
| Nível | O que significa | Exemplos |
|---|---|---|
| Proibido | Banido em absoluto. Em vigor desde fev. 2025. | Pontuação social, técnicas manipuladoras, reconhecimento de emoções no trabalho ou na escola, recolha indiscriminada de rostos. |
| Alto risco | Obrigações pesadas. Aplicáveis a partir de ago. 2026. | IA de recrutamento e contratação, decisões de gestão de trabalhadores, avaliação de crédito, biometria, componentes de segurança. |
| Limitado (transparência) | Informar as pessoas. A partir de ago. 2026. | Chatbots e agentes de voz (revelar que é IA), conteúdo gerado ou manipulado por IA (rotulá-lo). |
| Mínimo | Sem deveres específicos do AI Act. | A maioria das ferramentas internas, analytics, processamento de documentos, assistência a código. |
A conclusão útil: a maior parte do trabalho com IA é de risco mínimo ou limitado. As obrigações concentram-se em poucas categorias. Se constrói IA de contratação ou de alocação de trabalhadores, está no nível pesado. Se constrói um chatbot, deve uma linha de divulgação. Se constrói uma ferramenta de reconciliação ou um revisor de código, o AI Act deixa-o praticamente em paz. Os seus outros deveres, como o GDPR, não.
Isto baralha constantemente agências e empresas de desenvolvimento. O AI Act atribui deveres por função. O fornecedor constrói ou modifica substancialmente o sistema. O responsável pela implementação põe-no em uso.
Se constrói um sistema de alto risco para um cliente, normalmente é o fornecedor, e os deveres de documentação e conformidade são seus, não dele. Isso tem de ficar escrito no contrato: quem é fornecedor, quem é responsável pela implementação, quem mantém o ficheiro técnico, quem regista o sistema. Herdar por acidente as obrigações de alto risco de um cliente é uma forma real de se prejudicar.
Aqui está a parte que os emails de auditoria saltam. Um website de marketing aciona muito pouco do AI Act. Se o seu site não tiver chatbot, a regra de "revelar que é IA" nem sequer é ativada. Texto e imagens gerados por IA num blog são de baixo risco.
O que se aplica de facto a um website são as regras do GDPR e do ePrivacy, e é aí que quase toda a gente está, na verdade, em incumprimento. A falha clássica: o banner de cookies é decorativo. As tags de analytics e de publicidade (Google Analytics, Google Ads, LinkedIn, o seu CRM) carregam na primeira visualização de página, antes de o visitante escolher seja o que for, e continuam a correr depois de ele clicar em "Rejeitar". Ao abrigo do ePrivacy, os cookies não essenciais precisam de consentimento prévio, e "Rejeitar" tem de rejeitar mesmo.
Verificámos o nosso próprio site e encontrámos exatamente isto. A solução não é jurídica, é técnica: definir o Google Consent Mode como negado por defeito, e não carregar as tags de todo até o visitante optar por aderir. Depois da correção, uma visita nova não define qualquer cookie não essencial até haver consentimento, e recusar limpa-os. Esse é o patamar, e são umas horas de engenharia, não uma certificação.
O outro item do website que vale a pena rever é a acessibilidade (a European Accessibility Act, em vigor desde junho de 2025). Uma verificação WCAG 2.1 AA é um seguro barato. Num tema escuro, o culpado habitual é texto cinzento esbatido que falha o rácio de contraste de 4,5:1.
É aqui que o AI Act importa, e onde ajuda externa pode valer o investimento, se for a ajuda certa.
Para um sistema de alto risco (a IA de contratação é o caso comum), as obrigações são reais mas, na sua maioria, documentação que se faz a si próprio: um processo de gestão de risco, governação de dados e testes de enviesamento, um ficheiro técnico, registo automático, supervisão humana por desenho, exatidão e segurança, depois uma avaliação de conformidade interna, uma declaração e o registo na base de dados da UE. Repare no tema: a maior parte é disciplina de engenharia que já devia estar a fazer, posta por escrito. Humano no circuito e trilhos de auditoria completos, que uma boa construção já tem, não são burocracia. São metade do requisito.
Para sistemas de risco limitado, o custo é uma frase. Um agente de voz diz "está a falar com um assistente de IA". O conteúdo gerado é marcado como gerado. Faça-o já; é obrigatório a partir de agosto de 2026.
E se constrói sobre Claude, GPT ou qualquer modelo de fundação, é um responsável pela implementação a jusante de IA de uso geral, não o fornecedor de GPAI. O fornecedor do modelo suporta as obrigações de GPAI. O seu trabalho é usar a documentação que ele lhe dá, não recriá-la.
Portanto, isto é oportuno, não está em atraso. Se o seu roteiro inclui IA de contratação ou algo na lista de alto risco, agosto de 2026 é a data com que planear. Para tudo o resto, tem linhas de transparência a acrescentar e bons hábitos de documentação a manter.
O AI Act não é motivo para pânico, e não é um produto do qual se compre uma saída. Recompensa as mesmas coisas que a boa engenharia já recompensa: saber o que o seu sistema faz, manter uma pessoa no circuito onde importa, pô-lo por escrito, e ser honesto a respeito disso.
Já construiu algumas ferramentas de IA e agora luta com duplicação e desvio? O argumento para um marketplace interno de IA: o que entra, como organizar e curar.
Miguel Vicente Jr
The six prerequisites that decide whether an AI use case is worth building, with a scoring rubric, two worked examples, and the red flags that say walk away.
Miguel Vicente Jr
Um guia prático para otimizar operações com IA: encontrar o único passo lento, automatizá-lo, manter uma pessoa no circuito e medir o antes e o depois.
Miguel Vicente JrQuer aplicar estas ideias no seu negócio? Fale com os nossos consultores de IA.
Marcar uma chamada
