EU AI Act em 2026: o que a implantação on-prem altera em matéria de conformidade

O EU AI Act entrou em vigor em agosto de 2024, com disposições aplicadas de forma faseada ao longo de uma janela de dois a três anos ^[1][2]. Até agora, a maioria das conversas de conformidade empresarial concentrou-se em saber se um fluxo de trabalho cai sequer na categoria de "alto risco". A meio de 2026, a conversa está a mudar para uma questão mais prática: dado que o fluxo de trabalho está abrangido, que arquiteturas de implantação permitem efetivamente cumprir as obrigações do deployer, e quais é que, em silêncio, não permitem?

Essa segunda pergunta é onde a implantação on-premises deixa de ser uma preferência estilística e passa a ser um encaixe estrutural.

O que o Act pede aos deployers de IA de alto risco

O Act distingue entre o provider de um sistema de IA e o deployer do mesmo ^[1]. Um banco que utiliza uma API de LLM de terceiros para classificar pedidos de crédito é o deployer, não o provider. Os deployers de sistemas de alto risco têm obrigações que incluem: garantir supervisão humana, monitorizar o funcionamento do sistema, conservar registos por um período adequado, suspender a utilização se o sistema representar um risco para direitos fundamentais e demonstrar estas capacidades quando solicitado.

Várias dessas obrigações são diretas quando o deployer controla o runtime. A obrigação de "conservar registos por um período adequado" é mecanicamente simples se a inferência ocorrer num servidor que pertence ao deployer e os registos forem para o SIEM do deployer. A obrigação de "suspender a utilização" é igualmente trivial se o deployer puder desligar o modelo na sua própria infraestrutura.

As mesmas obrigações tornam-se mais difíceis quando a inferência corre numa API de LLM em nuvem que o deployer não opera. Os registos que o deployer pode produzir limitam-se ao que o provider expõe. Suspender a utilização exige a cooperação do provider. Demonstrar, em contemporâneo, que dados circularam pelo sistema exige confiar no pipeline do provider.

Onde se situam as APIs de LLM em nuvem na regulamentação

Nada disto torna as APIs de LLM em nuvem não conformes. Artigo a artigo, providers e deployers de IA alojada em nuvem podem cumprir as obrigações do Act. O atrito é operacional, não jurídico: o deployer tem de reunir, auditar e demonstrar conformidade por cima de uma fronteira de fornecedor, muitas vezes para fluxos de trabalho que correm milhares de inferências por dia.

O AI Index longitudinal do Stanford HAI tem acompanhado a deslocação correspondente na despesa empresarial ^[3]: o crescimento mais acentuado entre 2023 e 2025 não foi em IA generativa de uso geral, mas no ferramental de suporte — observabilidade, governação, registo de prompts, classificação de conteúdo, deteção de jailbreaks. A maior parte dessa despesa existe para colmatar o desfasamento entre o que as APIs de LLM em nuvem expõem nativamente e aquilo que um deployer precisa de evidenciar num contexto regulatório.

Esse desfasamento é a vantagem estrutural de correr a inferência em hardware que pertence ao deployer. Cada pergunta do tipo "isto aconteceu?" reduz-se a uma pergunta a que o deployer pode responder a partir dos seus próprios registos.

O que a implantação on-prem não dá de graça

Três obrigações do deployer previstas no AI Act não são automaticamente satisfeitas por uma implantação on-prem, e vale a pena nomeá-las explicitamente:

• Supervisão humana. O Act exige supervisão significativa da IA de alto risco, com humanos capazes de interpretar resultados e intervir. Correr o modelo localmente não coloca um humano no ciclo; é a conceção do fluxo de trabalho que o faz.
• Monitorização de deriva e comportamento inseguro. O deployer tem de monitorizar continuamente o sistema. A implantação on-prem torna a canalização trivial (os dados são locais), mas a política ("como se parece a deriva neste fluxo de trabalho?") ainda tem de ser definida.
• Obrigações do provider repercutidas. Quando a implantação on-prem é construída sobre um modelo de terceiros (por exemplo, um modelo de pesos abertos sob licença não comercial, ou um modelo de fornecedor entregue como binário), o deployer continua a ter de expor as divulgações exigidas pelo provider.

A vantagem estrutural do on-prem está nos eixos do tratamento de dados e da demonstrabilidade, não no da política. A política tem de ser escrita e aplicada independentemente do local onde a GPU se encontra.

Como isto se conjuga com os EUA, o Reino Unido e outras jurisdições

O EU AI Act é o mais prescritivo dos principais quadros. O US NIST AI RMF ^[4] adota uma abordagem voluntária, baseada num enquadramento, e o OECD AI Policy Observatory ^[5] acompanha o modo como os governos nacionais fora da UE convergem em princípios genericamente semelhantes (supervisão assente em risco, obrigações de transparência, regras de tratamento de dados).

Para um deployer multinacional, o efeito prático é que a jurisdição mais estrita determina a arquitetura. Se um fluxo de trabalho tiver de cumprir o EU AI Act para utilizadores europeus, o mesmo fluxo de trabalho não falhará as obrigações dos EUA, do Reino Unido, japonesas ou singapurenses se for desenhado contra a fasquia europeia. Conceber a implantação contra a fasquia mais estrita — incluindo a capacidade de o deployer evidenciar o tratamento de dados pedido a pedido — é o que torna o on-prem o padrão estruturalmente mais simples na IA empresarial em 2026.

Como se parece uma implantação de IA on-prem pronta para a conformidade em 2026

O formato em que entregamos — e o formato que os revisores de conformidade com quem trabalhamos pedem — é:

• Inferência local ao cliente. Quer no dispositivo do utilizador, quer num servidor operado pelo cliente. Nenhum prompt sai do perímetro.
• Registos de auditoria sem conteúdo. Cada ação administrativa é registada com timestamp + ator; nenhum prompt e nenhuma resposta aparece na linha de auditoria. A linha de auditoria é a evidência; o conteúdo é do deployer, a conservar de acordo com a sua própria política de retenção.
• Identidade através do IdP do cliente. OIDC contra Microsoft Entra ID ou Google Workspace, com os controlos de acesso existentes do deployer a aplicarem-se inalterados.
• Sem tenant do lado do fornecedor. O fornecedor (nós) não opera o runtime, não vê os dados e não é ponto de falha para a postura de conformidade do deployer.

Essa última propriedade é a que as APIs de LLM em nuvem, estruturalmente, não conseguem replicar — e é por isso que a implantação on-prem é o padrão dominante no segmento de empresas reguladas do mercado em 2026.

O contexto sobre como construímos em torno disto desde o início está em Porque entregamos a IA como binários instaláveis e não como SaaS em nuvem. As capacidades que concretizam a auditoria, a identidade e a superfície de política vivem no AI Admin Console.

Referências

1. Comissão Europeia. "AI Act — Regulatory framework on AI." digital-strategy.ec.europa.eu. Acedido a 2026-06-15.
2. Comissão Europeia. "AI Act enters into force." digital-strategy.ec.europa.eu. Acedido a 2026-06-15.
3. Stanford HAI. "AI Index Report." aiindex.stanford.edu. Acedido a 2026-06-15.
4. NIST. "AI Risk Management Framework (AI RMF 1.0)." nist.gov/itl/ai-risk-management-framework. Acedido a 2026-06-15.
5. OECD AI Policy Observatory. "National AI policies." oecd.ai. Acedido a 2026-06-15.

Artigos relacionados

• A mudança da compra empresarial de IA de cloud-first para residência-de-dados-first
• OECD AI Policy Observatory: o que mudou nos últimos 12 meses
• AI Admin Console: o que cada uma das seis capacidades faz, na realidade
• Registos de auditoria sem conteúdo: como provamos o que o modelo fez sem guardar prompts
• Porque é que as implantações de IA on-prem ficam paradas em compras (e o enquadramento que resolve a situação)
• Porque entregamos a IA como binários instaláveis e não como SaaS em nuvem
• Todos os artigos →