A legislação europeia sobre IA está em vigor. Consegue responder a estas cinco perguntas?
O regulamento europeu sobre IA está em vigor desde agosto de 2024. As práticas proibidas expiraram em agosto de 2025. As obrigações para a IA de alto risco entram em vigor em agosto de 2026. Se implementa sistemas de IA na Europa — ou processa dados pertencentes a europeus — o relógio já está a correr.
A maioria das organizações ainda trata o AI Act como um documento de conformidade para ler e assinar. Entregaram-no ao jurídico, marcaram-no como "em análise" e seguiram em frente. Esta é a abordagem errada.
O AI Act não é principalmente um texto jurídico. É um conjunto de obrigações operacionais. E a forma mais rápida de saber se está realmente em conformidade — não no papel, mas operacionalmente — é responder a cinco perguntas concretas sobre cada sistema de IA que gere.
Se não consegue responder às cinco, tem trabalho a fazer antes de agosto.
Porquê estas cinco perguntas
O regulamento tem mais de 180 artigos. Mas enterrada nas disposições de gestão de riscos, nas obrigações de transparência, nos requisitos de supervisão humana e no quadro de responsabilidade há uma estrutura subjacente consistente: os sistemas de IA devem ser governáveis. Não apenas seguros em abstrato — ativamente governáveis por pessoas identificáveis, com processos definidos, comportamento auditável e uma cadeia de responsabilidade clara.
Essa estrutura resume-se a cinco perguntas. Não são minhas — são as que qualquer regulador, auditor ou advogado fará em primeiro lugar quando algo correr mal. Deveria conseguir respondê-las antes de algo correr mal.
Pergunta 1: A que dados acede e que dados pode alterar?
Parece óbvio. Raramente o é.
Na prática, a maioria das equipas que implementa sistemas de IA tem uma resposta razoável para "que dados lê?" (dados de treino, dados de entrada, talvez um corpus de recuperação), mas uma resposta muito mais vaga para "que dados pode escrever, modificar ou provocar alterações?"
Os sistemas agênticos agravam isto. Um agente que envia e-mails, atualiza registos de CRM, chama APIs ou modifica configurações tem acesso de escrita a sistemas reais. As disposições de governação de dados do AI Act (artigos 10 e 13) exigem documentar a proveniência dos dados de treino, o âmbito dos dados de entrada e — crucialmente — que estado do sistema pode ser modificado pelos outputs do sistema de IA.
O que significa a conformidade: um mapa de dados mantido por cada implementação de IA. Fontes de entrada (com controlos de acesso documentados), destinos de saída (com permissões de escrita documentadas) e uma distinção clara entre caminhos de leitura e escrita.
A lacuna mais comum: documentaram-se as entradas mas não o que acontece a jusante dos outputs da IA. Se o seu sistema de IA recomenda algo e um humano clica em aprovar, o clique do humano conta como a escrita? Legalmente: às vezes sim, às vezes não. Precisa de saber qual é o seu caso.
Pergunta 2: Quem o supervisiona?
O AI Act exige supervisão humana para sistemas de IA de alto risco (artigo 14). Não "os humanos podem rever os outputs se quiserem." Supervisão humana definida — um papel nomeado com responsabilidade de monitorizar o comportamento do sistema, rever decisões sinalizadas e autoridade para anular ou parar.
Esta pergunta tem duas camadas:
Supervisão operacional: quem monitoriza o sistema dia a dia? Quem recebe o alerta quando a taxa de erros aumenta? Na maioria das organizações, esta é uma função de plantão de engenharia. Está bem, mas tem de ser explícita. "A equipa monitoriza" não é suficiente — a equipa não é uma entidade legal e não tem autoridade.
Supervisão de governação: quem tem autoridade para modificar os parâmetros do sistema, reentreinar o modelo ou desligá-lo? Para indústrias regulamentadas isto mapeia nas estruturas de governação existentes. Para startups frequentemente não mapeia em ninguém, o que é um problema.
O que significa a conformidade: para cada sistema de IA, um indivíduo nomeado ou papel com responsabilidades de supervisão documentadas e a autoridade real (acesso, ferramentas, processo) para as exercer. Não um RACI que aponta para "Engenharia" — uma pessoa, ou um papel claramente definido, com responsabilidade real.
O Gabinete de IA e as autoridades nacionais de vigilância do mercado são a camada de supervisão acima da sua governação interna. Não são abstratas. Estão a construir ativamente capacidade de aplicação.
Pergunta 3: Onde guarda a informação?
O RGPD e o AI Act sobrepõem-se significativamente aqui. As obrigações de transparência e os requisitos de governação de dados do AI Act pressupõem que consegue responder onde são persistidos os inputs do modelo, os outputs e os estados intermédios.
Isto complica-se rapidamente para sistemas que utilizam fornecedores de modelos de terceiros, geração aumentada por recuperação com bases de dados vetoriais externas, modelos ajustados alojados por fornecedores cloud, ou arquiteturas multi-agente onde um agente passa contexto a outro.
O que significa a conformidade: residência de dados documentada para cada armazenamento persistente que o sistema de IA toca. Isto inclui: dados de entrada, dados de saída, histórico de conversas ou estado de sessão se retido, embeddings numa base de dados vetorial, dados de treino de fine-tuning, registos de auditoria.
Para IA de alto risco, os dados devem ser retidos de forma a permitir auditoria post-hoc. Precisa de conseguir reconstruir o que o sistema fez com que dados, para uma decisão específica, numa data específica.
A questão do fornecedor cloud: se está a usar um fornecedor de LLM com sede nos EUA sem residência de dados na UE, a questão de para onde vão os dados em trânsito está em aberto. A maioria das equipas de engenharia nunca leu os aditamentos de tratamento de dados dos seus contratos.
Pergunta 4: Quem responde se errar?
O quadro de responsabilidade do AI Act, combinado com a pendente Diretiva de Responsabilidade de IA, está concebido para responder a isto a nível macro. Mas a pergunta prática é interna: antes de o regulador perguntar, a sua organização sabe?
Há três papéis de responsabilidade na estrutura do AI Act:
Fornecedor: a organização que desenvolve ou coloca no mercado um sistema de IA. Se ajusta um modelo, constrói um produto em cima de um modelo ou desenvolve uma ferramenta de IA para outros usarem, provavelmente é um fornecedor.
Responsável pelo deployment: a organização que coloca um sistema de IA em uso num contexto específico. Se está a usar o produto de um fornecedor de IA nas suas operações empresariais, é um responsável pelo deployment.
A maioria das organizações é simultaneamente fornecedor (das suas próprias ferramentas de IA) e responsável pelo deployment (de IA de terceiros). A divisão de obrigações entre eles importa: os fornecedores são responsáveis pela segurança de design fundamental do sistema; os responsáveis pelo deployment são responsáveis pelo contexto de deployment apropriado e supervisão.
O que significa a conformidade: alocação documentada de obrigações entre a sua organização e os seus fornecedores de IA. Os seus contratos enterprise devem especificar quem é o fornecedor de referência para cada sistema.
A lacuna real: a maioria das organizações ainda não teve a conversa sobre responsabilidade com os seus fornecedores de IA. O contrato foi assinado, a chave API está em produção e ninguém alocou formalmente quem responde ao regulador.
Pergunta 5: Como se desliga se começar a funcionar mal?
Esta é a pergunta que a maioria das equipas encontra mais difícil de responder, não porque o mecanismo não exista, mas porque nunca foi explicitamente concebido.
O artigo 9 (gestão de riscos) e o artigo 14 (supervisão humana) juntos exigem que os sistemas de IA de alto risco tenham procedimentos definidos para parar a operação quando os limiares de segurança ou precisão são ultrapassados. Isto não é "pode desligar o servidor." Significa:
- Deteção: como sabe que está a comportar-se mal? Que métrica, alerta ou processo de revisão faz emergir o problema?
- Classificação: o que constitui "funcionar mal" para este sistema específico? Deriva do modelo? Disparidade demográfica nos outputs? Taxa de erro a ultrapassar o limiar?
- Autorização: quem tem autoridade para decidir parar?
- Execução: o que significa parar? Matar a API? Reverter para uma versão anterior? Mudar para um processo manual de recurso?
- Comunicação: quem é notificado quando uma paragem ocorre? Para sistemas de alto risco em certas categorias, a notificação de incidentes ao Gabinete de IA é obrigatória.
O que significa a conformidade: um runbook — não um interruptor de desligamento teórico, mas um procedimento documentado testado pelo menos uma vez, com proprietários nomeados em cada passo.
Porque a maioria das equipas falha aqui: o sistema foi implementado de forma incremental. Nunca houve uma sessão de design sobre "qual é o plano de desligamento?". O interruptor existe em princípio (desligar o servidor) mas as camadas de deteção e autorização não existem.
O padrão por detrás das cinco perguntas
Leia-as juntas: acesso/modificação de dados, supervisão, armazenamento, responsabilidade, desligamento. Não são cinco requisitos independentes. São cinco facetas de uma única pergunta: este sistema de IA é governável?
A governação exige que alguém possa observar o sistema (perguntas 1, 3), que alguém tenha autoridade sobre ele (perguntas 2, 4) e que essa autoridade possa ser exercida na prática (pergunta 5). Se falta qualquer uma das cinco, o ciclo de governação está quebrado.
O AI Act europeu está a operacionalizar isto na lei porque a abordagem voluntária não funcionou. Princípios sem aplicação não mudam o comportamento. O Ato é aplicação.
O que faria este trimestre
Se está a implementar sistemas de IA na Europa, ou qualquer coisa que toque dados europeus, a sequência prática:
-
Faça um inventário das suas implementações de IA. Não só os produtos de IA que vende — toda a IA que usa internamente. Ferramentas de seleção de RH, bots de atendimento ao cliente, deteção de fraude, motores de recomendação.
-
Para cada sistema, responda às cinco perguntas. Escreva-as. "Ainda não decidimos" é uma resposta — significa que tem uma lacuna.
-
Para qualquer coisa nas categorias de alto risco (Anexo III do Ato) — priorize. Agosto de 2026 é o prazo limite.
-
Organize os seus contratos com fornecedores. Quem é o fornecedor de referência? Que capacidades de auditoria o fornecedor fornece?
-
Construa o runbook para a pergunta 5. Das cinco, é a mais operacional e a menos provável de existir. Construa-o antes de precisar dele.
O AI Act não é uma regulamentação perfeita. Mas as cinco perguntas são engenharia responsável independentemente da regulamentação — é o que o deployment responsável de sistemas com consequências sempre exigiu. O Ato está simplesmente a torná-lo obrigatório.
Está a implementar sistemas de IA em produção na Europa e precisa de capacidade de engenharia que já opere com estes controlos de governação incorporados? Fale connosco — as nossas equipas nearshore constroem sistemas de IA com registos de auditoria, hooks de supervisão humana e runbooks de conformidade como prática padrão.
