Porque é que as implantações de IA on-prem ficam paradas em compras (e o enquadramento que resolve a situação)

Até 2 de dezembro de 2027, as obrigações do deployer ao abrigo do EU AI Act aplicam-se aos sistemas de IA de alto risco utilizados em biometria, infraestruturas críticas, educação, emprego, migração, asilo e controlo de fronteiras ^[1]. As equipas de conformidade em 2026 não estão à espera de dezembro de 2027 para se posicionarem. Estão a redigir questionários de due diligence a fornecedores neste momento, e a aquisição de IA empresarial fica parada nesses questionários a um ritmo que pouco tem que ver com a tecnologia a ser adquirida. A solução não é uma melhor demonstração. É um reenquadramento daquilo que a conversa de compras é, na realidade.

Como se parece, na prática, um "impasse" em 2026

A prova de conceito técnica passa. O modelo produz resultados úteis sobre a própria carga de trabalho do cliente. O avaliador técnico escreve uma nota positiva e passa o processo às compras. Depois o processo fica parado. Três semanas mais tarde, a equipa de conformidade do cliente volta com um memorando: "Não conseguimos evidenciar as nossas obrigações de deployer sobre este fluxo de trabalho se a inferência ocorrer num endpoint que não controlamos."

O inquérito empresarial da a16z identificou a forma deste padrão à medida que se ia constituindo: ciclos de negócio que "costumavam demorar mais de um ano a fechar estão a ser concluídos em 2 ou 3 meses" para produtos que se enquadram nos novos requisitos ^[4]. A implicação corre também no sentido contrário. A aquisição de produtos que não se enquadram nos novos requisitos continua a demorar o ano. Pilotos técnicos sólidos não alteram esse facto.

Aquilo que se pede, na realidade, às compras que evidenciem

O EU AI 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. As obrigações do deployer incluem supervisão humana, monitorização, comunicação de incidentes e demonstração destas capacidades quando solicitado. Estas obrigações aplicam-se ao banco, não ao fornecedor do LLM — e a equipa de compras do banco é a superfície onde a seleção do fornecedor decide se as obrigações são praticáveis de cumprir.

Esta direção não é exclusivamente europeia. O NIST publicou uma nota conceptual para um Perfil do AI RMF sobre IA fiável em infraestruturas críticas a 7 de abril de 2026 ^[2], o primeiro enquadramento federal das obrigações do deployer no âmbito do AI RMF para operadores de infraestruturas críticas nos Estados Unidos. O OECD AI Policy Observatory mantém um repositório vivo "de mais de 80 jurisdições e organizações" ^[3]. A convergência transjurisdicional sobre obrigações do lado do deployer é a tendência, não uma exceção.

As equipas de compras em setores regulados leem estes sinais e antecipam-se. Não podem esperar até 2 de dezembro de 2027 para saber se uma arquitetura de fornecedor lhes permitirá cumprir as suas obrigações.

Porque "temos SOC 2" é a resposta errada

A resposta sobre controlos do fornecedor que, historicamente, resolvia as conversas de aquisição empresarial — SOC 2 Type II, ISO 27001, DPA alinhada com o RGPD — incide sobre controlos do lado do fornecedor. São necessários. Não são suficientes para as obrigações do deployer que estão agora a entrar em vigor.

As obrigações do deployer exigem que este demonstre, mediante pedido, quais os dados que circularam pelo sistema de IA. Trata-se de uma questão sobre os registos do próprio deployer, não os do fornecedor. Um fornecedor com SOC 2 limpo que mantém o prompt e a resposta numa nuvem gerida não consegue colmatar esta lacuna, porque a lacuna está do lado do deployer da fronteira: o deployer não pode produzir um registo de algo que não vê.

É este o desfasamento estrutural que faz parar a conversa de compras. A equipa de conformidade redige um memorando contra as obrigações do deployer. O fornecedor responde com certificações do lado do fornecedor. Os dois navios cruzam-se sem se encontrarem.

O enquadramento que resolve o impasse

Três propriedades da arquitetura de implantação, declaradas à partida no questionário ao fornecedor, eliminam o impasse:

1. Inferência local ao deployer. Quer no dispositivo do utilizador, quer num servidor operado pelo deployer. Os prompts e as respostas nunca saem do perímetro do deployer.
2. Registos de auditoria sem conteúdo, propriedade do deployer. Cada ação administrativa é registada com timestamp e ator, no SIEM do deployer. Nenhum prompt ou resposta aparece na linha de auditoria. A linha é a evidência; o conteúdo é do deployer, a conservar de acordo com a sua própria política de retenção.
3. Identidade através do IdP do deployer. OIDC contra Microsoft Entra ID ou Google Workspace. Os controlos de acesso e as políticas de SSO existentes do deployer aplicam-se inalterados.

Estas não são propriedades do fornecedor a certificar. São propriedades da arquitetura de implantação a especificar. Uma vez enquadrado o questionário ao fornecedor em função delas, o memorando de conformidade redige-se sozinho: cada obrigação do deployer tem uma propriedade arquitetural correspondente para a qual o deployer pode apontar.

Como isto se concretiza no formato em que entregamos

O AI Suite da Software Tailor é entregue como instaladores de desktop que comunicam com um processo de inferência local. O AI Admin Console é a superfície de gestão que a equipa de TI do deployer utiliza para aplicar políticas, gerir licenças e expor auditoria. Seis clientes da Fortune Global 500 nos setores farmacêutico, financeiro, governamental, jurídico, defesa e energia implantaram com este formato desde 2007 (clientes anteriores), e todos esses projetos passaram por uma versão do enquadramento acima antes da assinatura do contrato.

A forma mais rápida de concretizar isto é percorrê-lo sobre uma carga de trabalho real. Um piloto gratuito de 1 semana coloca o modelo no hardware do cliente, a linha de auditoria no SIEM do cliente e a identidade através do IdP do cliente — o suficiente para que a equipa de conformidade redija o memorando contra as obrigações que efetivamente enfrenta.

Referências

1. Comissão Europeia. "AI Act — Regulatory framework on AI." digital-strategy.ec.europa.eu. Acedido a 2026-06-03.
2. NIST. "AI Risk Management Framework." nist.gov/itl/ai-risk-management-framework. Acedido a 2026-06-03. A nota conceptual sobre infraestruturas críticas foi divulgada a 7 de abril de 2026.
3. OECD AI Policy Observatory. "Policy Navigator dashboards." oecd.ai/en/dashboards. Acedido a 2026-06-03.
4. Andreessen Horowitz. "State of Generative AI in the Enterprise." a16z.com/generative-ai-enterprise-2024. Publicado a 21 de março de 2024. Acedido a 2026-06-03.

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
• Registos de auditoria sem conteúdo: como provamos o que o modelo fez sem guardar prompts
• EU AI Act em 2026: o que a implantação on-prem altera em matéria de conformidade
• Porque entregamos a IA como binários instaláveis e não como SaaS em nuvem
• Todos os artigos →