AI Act e ITIL: como cumprir o regulamento europeu com as práticas que já tem

O regulamento europeu da inteligência artificial, o Regulamento (UE) 2024/1689, foi aprovado em 2024 e está a entrar em vigor por fases. A data que mais importa para a maior parte das organizações é 2 de Agosto de 2026, quando se tornam exigíveis as obrigações dos fornecedores de sistemas IA classificados como high-risk. Em Portugal, a ANACOM foi designada autoridade nacional de supervisão de mercado, com competência coordenada por 14 autoridades sectoriais.

A primeira reacção típica é tratar isto como problema jurídico: contratar advogados, fazer ginástica contratual, esperar pelas guidelines da Comissão. Erro. O AI Act é, em primeiro lugar, um regulamento de governance e gestão de processos. Exige sistema de gestão de qualidade, gestão de risco contínua, documentação técnica viva, logging, supervisão humana e relação estruturada com a autoridade. Para quem tem ITIL minimamente implementado, isto é território familiar. Para quem não tem, o gap é grande e demora a fechar.

O que o AI Act exige na prática

O regulamento classifica os sistemas de IA em cinco categorias de risco, com obrigações proporcionais. Quem está sujeito a obrigações pesadas é quem cai em high-risk ou em general-purpose AI (GPAI):

1. Proibidos (artigo 5.º): oito práticas banidas, incluindo manipulação subliminar, classificação social, reconhecimento de emoções em locais de trabalho e bases biométricas indiscriminadas. Multa máxima: 35 milhões ou 7% do volume de negócios.
2. High-risk (anexos I e III): sistemas em recrutamento, crédito, infraestrutura crítica, justiça, gestão de migração, educação, dispositivos médicos, brinquedos com IA e mais. Obrigações pesadas e auditoria obrigatória.
3. Risco limitado: chatbots, deepfakes e IA generativa orientada ao consumidor. Obrigações de transparência (avisar o utilizador que está a falar com IA).
4. Risco mínimo: filtros de spam, IA em jogos. Sem obrigações específicas além de boas práticas voluntárias.
5. GPAI (modelos de uso geral): GPT, Claude, Llama, Gemini. Obrigações distintas para fornecedores de modelo, com transparência sobre dados de treino e copyright.

Para os sistemas high-risk, o regulamento define obrigações específicas distribuídas pelos artigos 9.º a 17.º. Em síntese operacional, exige documentar tudo, monitorizar tudo, ter supervisão humana real, garantir robustez técnica, manter logs auditáveis e ter um sistema de gestão da qualidade que prove que existe processo, não apenas papel. A obrigação é de resultado e de evidência, não apenas de intenção.

Que sistemas de TI caem em high-risk?

A pergunta mais frequente é "se eu uso IA, sou high-risk?". A resposta curta: depende do uso, não da tecnologia. Um mesmo modelo (GPT-4, por exemplo) pode ser risco mínimo num caso e high-risk noutro. O que define a classificação é o domínio de aplicação e o impacto nas pessoas. Seis exemplos concretos que vejo em organizações portuguesas:

1. Sistemas de recrutamento com IA: triagem automática de CVs, scoring de candidatos, entrevistas analisadas por algoritmo. Anexo III, ponto 4. High-risk.
2. Controlo de acesso e identidade com biometria: reconhecimento facial em portas, autenticação por voz com decisão automatizada de bloqueio. High-risk se aplicado a contexto crítico.
3. Avaliação de desempenho de trabalhadores: scoring automático de produtividade, monitorização contínua de comportamento, decisões disciplinares baseadas em IA. Anexo III, ponto 4. High-risk.
4. Detecção de fraude e scoring de crédito: modelos que decidem aprovação de crédito, classificam risco de cliente, bloqueiam transacções suspeitas. Anexo III, ponto 5. High-risk.
5. Gestão de infraestrutura crítica: redes de telecomunicações, energia, água, gás, transportes. Anexo III, ponto 2. High-risk obrigatório.
6. IA em produtos regulados: dispositivos médicos, máquinas industriais, brinquedos com componentes IA. Anexo I. High-risk com regime próprio (a partir de 2027).

Se a sua organização tem um destes seis casos, o trabalho de conformidade já tem prioridade máxima. Se não tem nenhum, vale a pena documentar essa avaliação numa nota interna assinada (parte do dever de literacia em IA do artigo 4.º), porque a primeira pergunta de qualquer auditor será exactamente essa.

Mapa: o que o AI Act exige e que prática ITIL responde

Esta tabela cruza os artigos chave do AI Act com as práticas ITIL 4 e v5 que cobrem cada exigência. Quem já faz ITIL bem aplicado tem cerca de 80% do trabalho de governance feito, faltando apenas adaptações específicas para IA.

Se a sua organização já tem seis ou mais destas práticas com maturidade razoável, o AI Act é principalmente um exercício de adaptação dos processos existentes. Se tem menos de seis, o caminho mais sensato é construir a base ITIL antes de tentar atingir conformidade plena.

Para uma visão integrada das práticas ITIL e como se articulam no value chain ITIL v5, vale a pena ler o nosso guia sobre as 8 actividades do lifecycle. E para quem está a tratar simultaneamente da conformidade NIS2, muitos dos controlos sobrepõem-se.

Por onde começar se já fazemos ITIL?

Quem já tem ITIL implementado pode atingir conformidade básica com o AI Act em cerca de 90 dias, dividindo o trabalho em três blocos sequenciais. O segredo é começar pelo inventário, não pelo processo. Sem saber que sistemas IA existem na organização, nenhum framework funciona.

Dias 1-30: inventário e classificação de risco

Identificar todos os sistemas de IA em uso (próprios, third-party, embedded em SaaS) e classificá-los segundo as cinco categorias do AI Act. Para cada sistema, registar: fornecedor, finalidade, dados que processa, decisões automatizadas que toma, número de pessoas afectadas. Este inventário deve ficar no CMDB ou num registo equivalente que possa ser auditado. Atribuir um owner por sistema e um responsável global pela conformidade IA.

Dias 31-60: gap analysis vs práticas ITIL existentes

Para cada sistema classificado como high-risk ou GPAI, fazer mapeamento dos requisitos AI Act contra as práticas ITIL existentes. Identificar três tipos de gap: prática inexistente, prática existente mas não aplicada a IA, prática existente e aplicada mas sem evidência auditável. O output é uma matriz de priorização: que controlos faltam e quais têm de ser adaptados.

Dias 61-90: quick wins e arquitectura

Implementar os controlos mais críticos: logging automático com retenção mínima de 6 meses, change board específico para alterações em sistemas IA, fluxo de incidente que dispara notificação à ANACOM em sistemas high-risk, e procedimento de supervisão humana com ponto de decisão obrigatório. Em paralelo, formação de literacia IA para colaboradores que tocam estes sistemas (obrigatório desde 2 Fev 2025, artigo 4.º).

Três armadilhas que vejo nos primeiros projectos

Em conversas com responsáveis de TI portugueses nos últimos meses, três padrões repetem-se sistematicamente, mesmo em organizações com ITIL bem implementado:

1. IA introduzida sem passar pelo change enablement

O caso típico: equipa de operações decide testar um agente IA para classificar tickets, conecta o agente ao service desk, e duas semanas depois descobre-se que o agente já tomou centenas de decisões sem registo, sem aprovação formal, sem avaliação de risco. Em sistema high-risk, isto seria não-conformidade grave. A correcção é adicionar critério explícito ao change board: qualquer introdução, alteração ou desactivação de componente IA passa por avaliação formal de classificação de risco AI Act antes da aprovação.

2. Logging insuficiente para o artigo 12.º

O AI Act exige logging automático que permita rastreabilidade de operações ao longo do ciclo de vida do sistema. Na prática, isto significa registar inputs do sistema, outputs, decisões, contexto da decisão, intervenções humanas e alterações ao modelo. A maior parte dos sistemas IA actuais regista apenas o pedido e a resposta, sem o resto. Sem logs adequados, é impossível demonstrar conformidade, e é impossível investigar incidentes. A solução passa por arquitectura desde o início: integrar IA com monitoring and event management existente, com retenção de 6 meses ou mais e separação clara de dados pessoais.

3. Incident management sem fluxo para ANACOM

O processo padrão de incidente termina em "resolvido + RCA". Para sistemas high-risk de IA, tem de existir um ramo adicional: "incidente grave + notificação à autoridade". A ANACOM ainda não publicou portal próprio, mas a obrigação aplicar-se-á a partir de 2 Agosto 2026 e os critérios de "incidente grave" estão no artigo 3.º (49.º): morte ou dano grave à saúde, perturbação grave de infraestrutura crítica, violação de obrigações jurídicas fundamentais, dano grave a património. A maior parte das equipas não tem este gatilho desenhado no fluxo.

Templates e ferramentas que aceleram o trabalho

Não vale a pena reinventar a roda. Os templates ITSM em português que disponibilizamos cobrem grande parte dos artefactos que o AI Act exige, com adaptação mínima. Em particular:

• Templates de gestão de risco incluem matriz de avaliação e plano de tratamento, que servem directamente para o artigo 9.º.
• Templates de segurança da informação cobrem políticas, controlos e registos de evidência necessários para o artigo 15.º.
• Templates de change enablement incluem formulário RFC, matriz de impacto e calendário CAB, adaptáveis para incluir critério de risco IA no artigo 14.º.
• Templates de gestão de incidentes com formulário, runbook e relatório post-mortem cobrem os artigos 72.º e 73.º com adaptação do gatilho de notificação.

Para visão completa do regulamento e suporte à implementação, o portal aiact-portugal.pt mantém um repositório actualizado de obrigações, prazos e ferramentas de avaliação, incluindo o checklist de literacia em IA do artigo 4.º.

Erros que vejo repetir-se

Para fechar, os erros que mais custam tempo e dinheiro nos primeiros projectos:

1. Esperar pelas guidelines da Comissão para começar. As guidelines vão sair em sequência ao longo dos próximos 18 meses. Quem começou cedo já tem inventário e processo. Quem espera vai chegar a 2 Agosto 2026 sem nada feito.
2. Confundir conformity assessment com auditoria interna. Conformity assessment é um procedimento técnico específico para sistemas high-risk (artigo 43.º) e exige notified body para certos casos. Não é a mesma coisa que auditoria interna ITSM.
3. Tratar literacia em IA como "formação anual de hora e meia". O artigo 4.º exige que os colaboradores tenham competência adequada para o uso que fazem da IA. Para quem trabalha com sistemas IA críticos, isto significa formação contínua e prática, não webinar de 60 minutos.
4. Ignorar o ciclo de vida do modelo. Um sistema IA não é estático. Re-treino, fine-tuning, drift de modelo, mudança de dados de input: tudo isto pode requalificar o nível de risco. Tem de haver processo contínuo, não one-shot.
5. Não testar a notificação à ANACOM. O primeiro exercício prático para muitas equipas será o incidente real. Faça simulacros antes, com cronómetro, com testemunhas e com follow-up documentado.

Perguntas frequentes