A Lei Europeia de IA entrou em vigor em agosto de 2024, com disposições implementadas gradualmente ao longo de um período de dois a três anos [1][2]. Até agora, a maioria das conversas sobre conformidade empresarial focou-se em saber se um fluxo de trabalho se enquadra na categoria de "alto risco". Em meados de 2026, a conversa está mudando para uma questão mais prática: dado que o fluxo de trabalho está no escopo, quais arquiteturas de implantação realmente permitem cumprir as obrigações do implantador, e quais silenciosamente não permitem?

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

O que a Lei exige dos implantadores de IA de alto risco

A Lei distingue entre o fornecedor de um sistema de IA e o implantador dele [1]. Um banco que usa uma API de LLM de terceiros para avaliar pedidos de empréstimo é o implantador, não o fornecedor. Os implantadores de sistemas de alto risco têm obrigações que incluem: garantir supervisão humana, monitorar a operação do sistema, manter registros por um período apropriado, suspender o uso se o sistema representar risco a direitos fundamentais e demonstrar essas capacidades mediante solicitação.

Várias dessas obrigações são simples quando o implantador controla o ambiente de execução. A obrigação de "manter registros por um período apropriado" é mecanicamente simples se a inferência ocorrer em um servidor de propriedade do implantador e os registros forem armazenados no SIEM do implantador. A obrigação de "suspender o uso" é igualmente trivial se o implantador puder desligar o modelo em sua própria infraestrutura.

As mesmas obrigações tornam-se mais difíceis quando a inferência é realizada em uma API de LLM em nuvem que o implantador não opera. Os registros que o implantador pode produzir são limitados ao que o fornecedor expõe. Suspender o uso requer a cooperação do fornecedor. Demonstrar, de forma contemporânea, quais dados passaram pelo sistema requer confiar no pipeline do fornecedor.

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

Nada disso torna as APIs de LLM em nuvem não conformes. Artigo por artigo, provedores e implementadores de IA hospedada na nuvem podem satisfazer as obrigações do Regulamento. O atrito é operacional, não legal: o implementador precisa montar, auditar e demonstrar conformidade através de uma fronteira de fornecedor, frequentemente para fluxos de trabalho que executam milhares de inferências por dia.

O Índice de IA longitudinal da Stanford HAI acompanhou a correspondente mudança nos gastos empresariais [3]: o crescimento mais acentuado entre 2023–2025 não foi na IA generativa de uso geral, mas nas ferramentas de suporte — observabilidade, governança, registro de prompts, classificação de conteúdo, detecção de jailbreak. A maior parte desse gasto existe para preencher a lacuna entre o que as APIs de LLM em nuvem expõem nativamente e o que um implementador precisa evidenciar em um contexto regulatório.

Essa lacuna é a vantagem estrutural de executar inferência no hardware que o implementador possui. Toda pergunta "isso aconteceu?" se reduz a uma questão que o implementador pode responder a partir de seus próprios logs.

O que o on-prem não oferece gratuitamente

Três obrigações do implementador segundo o 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 Regulamento exige supervisão significativa da IA de alto risco, com humanos capazes de interpretar resultados e intervir. Executar o modelo localmente não coloca um humano no ciclo; o design do fluxo de trabalho é que o faz.
  • Monitoramento de deriva e comportamento inseguro. O implementador deve monitorar continuamente o sistema. A implantação on-prem torna a infraestrutura trivial (os dados são locais), mas a política ("como é a deriva para este fluxo de trabalho?") ainda precisa ser definida.
  • Obrigações do provedor repassadas. 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 implementador ainda precisa expor as divulgações exigidas pelo provedor.

A vantagem estrutural do on-prem está nos eixos de manuseio de dados e demonstrabilidade, não na política. A política precisa ser escrita e aplicada independentemente de onde a GPU esteja.

Como isso se relaciona com EUA, Reino Unido e outras jurisdições

O AI Act da UE é o mais prescritivo dos principais frameworks. O NIST AI RMF dos EUA [4] adota uma abordagem voluntária baseada em framework, e o Observatório de Políticas de IA da OCDE [5] acompanha como governos nacionais fora da UE estão convergindo para princípios amplamente similares (supervisão baseada em risco, obrigações de transparência, regras de manuseio de dados).

Para um implementador multinacional, o efeito prático é que a jurisdição mais rigorosa define a arquitetura. Se um fluxo de trabalho precisa satisfazer o AI Act da UE para usuários europeus, o mesmo fluxo não falhará nas obrigações dos EUA, Reino Unido, Japão ou Singapura se for projetado segundo o padrão da UE. Projetar a implantação segundo o padrão mais rigoroso — incluindo a capacidade do implementador de evidenciar o manuseio de dados por requisição — é o que torna o on-prem a opção estruturalmente mais simples para IA empresarial em 2026.

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

A forma que entregamos — e a forma que os revisores de conformidade com quem trabalhamos solicitam — é:

  • Inferência local no cliente. Ou no dispositivo do usuário ou em um servidor operado pelo cliente. Nenhum prompt sai do perímetro.
  • Registros de auditoria sem conteúdo. Toda ação administrativa é registrada com carimbo de data/hora + ator; nenhum prompt e nenhuma resposta aparecem na linha de auditoria. A linha de auditoria é a evidência; o conteúdo é do implantador para reter sob 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 controles de acesso existentes do implantador aplicando-se sem alterações.
  • Nenhum inquilino de inferência operado pelo fornecedor. A Software Tailor não opera o tempo de execução do modelo nem recebe prompts, respostas ou documentos do cliente por este caminho. Identidade da organização, licenciamento, política, estado do servidor, uso agregado, registros de auditoria e suporte ainda podem usar um plano de controle do fornecedor e devem ser avaliados como uma dependência separada.

Essa última propriedade de inferência é aquela que as APIs de LLM em nuvem estruturalmente não conseguem replicar. Isso não torna um produto on-premises automaticamente conforme nem elimina a necessidade de avaliar seu plano de controle, rotas de suporte, cadeia de suprimentos do modelo e responsabilidades operacionais do cliente.

O histórico de como construímos isso desde o início está em Por que entregamos AI como binários instaláveis, não SaaS em nuvem. As capacidades que implementam a auditoria, identidade e superfície de política vivem em AI Admin Console.

Referências

  1. Comissão Europeia. "AI Act — Quadro regulatório sobre IA." https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai. Acesso em 2026-06-15.
  2. Comissão Europeia. "AI Act entra em vigor." https://digital-strategy.ec.europa.eu/. Acesso em 15-06-2026.
  3. Stanford HAI. "Relatório do Índice de IA." https://aiindex.stanford.edu/. Acesso em 15-06-2026.
  4. NIST. "Estrutura de Gestão de Riscos de IA (AI RMF 1.0)." https://www.nist.gov/itl/ai-risk-management-framework. Acesso em 15-06-2026.
  5. Observatório de Políticas de IA da OCDE. "Políticas nacionais de IA." https://oecd.ai/. Acesso em 15-06-2026.