Por qué los despliegues de IA on-premises se atascan en compras (y el enfoque que lo resuelve)
Las compras de IA en empresa se atascan por las obligaciones del deployer, no por la tecnología. Las propiedades de la arquitectura de despliegue que resuelven el atasco en 2026, y por qué «tenemos SOC 2» es la respuesta equivocada a la pregunta que ahora plantean los equipos de cumplimiento.
El 2 de diciembre de 2027, las obligaciones del deployer bajo la EU AI Act se aplicarán a los sistemas de IA de alto riesgo utilizados en biometría, infraestructuras críticas, educación, empleo, migración, asilo y control de fronteras [1]. Los equipos de cumplimiento en 2026 no están esperando a diciembre de 2027 para posicionarse. Están redactando cuestionarios de diligencia de proveedores ahora, y las compras de IA en la empresa se atascan en esos cuestionarios a un ritmo que tiene muy poco que ver con la tecnología que se está adquiriendo. La solución no es una mejor demo. Es replantear de qué trata realmente la conversación de compras.
Cómo se ve realmente el «atasco» en 2026
La prueba de concepto técnica se supera. El modelo produce resultados útiles sobre la carga de trabajo real del cliente. El evaluador técnico redacta una nota positiva y entrega el expediente a compras. Y entonces el expediente se queda parado. Tres semanas más tarde, el equipo de cumplimiento del cliente regresa con un memorando: «No podemos evidenciar nuestras obligaciones como deployer en este flujo de trabajo si la inferencia ocurre en un endpoint que no controlamos».
La encuesta empresarial de a16z identificó la forma de este patrón cuando empezaba a tomarla: ciclos de venta que «solían tardar más de un año en cerrarse se están cerrando en 2 o 3 meses» para los productos que encajan con los nuevos requisitos [4]. La implicación va también en sentido contrario. Las compras de productos que no encajan con los nuevos requisitos siguen tardando el año. Los pilotos técnicos sólidos no cambian eso.
Qué se le está pidiendo realmente a compras que evidencie
La EU AI Act distingue entre el provider de un sistema de IA y el deployer que lo utiliza [1]. Un banco que utiliza una API LLM de terceros para evaluar solicitudes de préstamo es el deployer. Las obligaciones del deployer incluyen supervisión humana, monitorización, notificación de incidentes y la capacidad de demostrar todo ello cuando se solicite. Estas obligaciones recaen sobre el banco, no sobre el proveedor del LLM, y el equipo de compras del banco es la superficie donde la selección de proveedor decide si las obligaciones serán prácticas de satisfacer.
Esta dirección no es exclusiva de la UE. NIST publicó una nota conceptual para un AI RMF Profile sobre IA fiable en infraestructuras críticas el 7 de abril de 2026 [2], el primer alcance federal de las obligaciones del deployer bajo el NIST AI RMF para operadores de infraestructuras críticas en Estados Unidos. El AI Policy Observatory de la OCDE mantiene un repositorio vivo «procedente de más de 80 jurisdicciones y organizaciones» [3]. La convergencia entre jurisdicciones en las obligaciones del lado del deployer es la tendencia, no la excepción.
Los equipos de compras en sectores regulados leen estas señales y se posicionan con antelación. No pueden esperar al 2 de diciembre de 2027 para descubrir si la arquitectura de un proveedor les permitirá satisfacer sus obligaciones.
Por qué «tenemos SOC 2» es la respuesta equivocada
La respuesta basada en controles de proveedor que históricamente resolvía las conversaciones de compras en la empresa —SOC 2 Type II, ISO 27001, DPA alineado con el RGPD— aborda controles del lado del proveedor. Son necesarios. No son suficientes para las obligaciones del deployer que están entrando en vigor.
Las obligaciones del deployer exigen que el deployer demuestre, cuando se le solicite, qué datos pasaron por el sistema de IA. Esa es una pregunta sobre los propios registros del deployer, no los del proveedor. Un proveedor con SOC 2 impecable que retiene el prompt y la respuesta en una nube gestionada no puede cerrar esta brecha, porque la brecha está del lado del deployer: el deployer no puede producir un registro de algo que no ve.
Este es el desajuste estructural que atasca la conversación de compras. El equipo de cumplimiento redacta un memorando sobre las obligaciones del deployer. El proveedor responde con certificaciones del lado del proveedor. Los dos barcos se cruzan sin verse.
El enfoque que resuelve el atasco
Tres propiedades de la arquitectura de despliegue, declaradas por adelantado en el cuestionario al proveedor, hacen colapsar el atasco:
- Inferencia local al deployer. Bien en el dispositivo del usuario, bien en un servidor que opera el deployer. Los prompts y las respuestas nunca salen del perímetro del deployer.
- Registros de auditoría sin contenido, propiedad del deployer. Cada acción administrativa queda registrada con marca temporal y actor, en el SIEM del deployer. Ningún prompt ni respuesta aparece en la fila de auditoría. La fila es la evidencia; el contenido queda en manos del deployer para retenerlo bajo su propia política de retención.
- Identidad a través del IdP del deployer. OIDC contra Microsoft Entra ID o Google Workspace. Los controles de acceso y políticas de SSO existentes del deployer se aplican sin cambios.
No se trata de propiedades del proveedor que haya que certificar. Son propiedades de la arquitectura de despliegue que hay que especificar. Una vez que el cuestionario al proveedor se plantea en estos términos, el memorando de cumplimiento se escribe solo: cada obligación del deployer tiene una propiedad arquitectónica correspondiente a la que el deployer puede señalar.
Cómo se concreta esto en la forma en la que distribuimos
AI Suite de Software Tailor se entrega como instaladores de escritorio que se comunican con un proceso de inferencia local. AI Admin Console es la superficie de gestión que el equipo de TI del deployer utiliza para aplicar políticas, gestionar licencias y exponer la auditoría. Seis clientes Fortune Global 500 en farma, finanzas, gobierno, jurídico, defensa y energía han desplegado bajo este modelo desde 2007 (clientes anteriores), y cada una de esas relaciones pasó por una versión del enfoque anterior antes de firmar el contrato.
La forma más rápida de concretarlo es recorrerlo sobre una carga de trabajo real. Un piloto gratuito de 1 semana coloca el modelo en el hardware del cliente, la fila de auditoría en el SIEM del cliente y la identidad a través del IdP del cliente, lo suficiente para que el equipo de cumplimiento redacte el memorando sobre las obligaciones a las que realmente se enfrenta.
Referencias
- European Commission. «AI Act — Regulatory framework on AI.» digital-strategy.ec.europa.eu. Consultado el 2026-06-03.
- NIST. «AI Risk Management Framework.» nist.gov/itl/ai-risk-management-framework. Consultado el 2026-06-03. La nota conceptual sobre infraestructuras críticas se publicó el 7 de abril de 2026.
- OECD AI Policy Observatory. «Policy Navigator dashboards.» oecd.ai/en/dashboards. Consultado el 2026-06-03.
- Andreessen Horowitz. «State of Generative AI in the Enterprise.» a16z.com/generative-ai-enterprise-2024. Publicado el 21 de marzo de 2024. Consultado el 2026-06-03.
Artículos relacionados
- El cambio de cloud-first a residencia-de-datos-first en la compra de IA empresarial
- OECD AI Policy Observatory: qué cambió en los últimos 12 meses
- Registros de auditoría sin contenido: cómo demostramos lo que hizo el modelo sin conservar los prompts
- EU AI Act en 2026: qué cambia el despliegue on-premises en el cumplimiento
- Por qué distribuimos IA como binarios instalables, no como SaaS en la nube
- Todos los artículos →
Aplique el enfoque a una carga de trabajo real.
Un piloto gratuito de 1 semana coloca el modelo, la fila de auditoría y la identidad dentro del perímetro del cliente, y permite a su equipo de cumplimiento redactar el memorando contra las obligaciones a las que realmente se enfrenta.