Para el 2 de diciembre de 2027, las obligaciones del implementador bajo la Ley de IA de la UE se aplican a sistemas de IA de alto riesgo usados en biometría, infraestructura crítica, educación, empleo, migración, asilo y control fronterizo [1]. Los equipos de cumplimiento en 2026 no esperan hasta diciembre de 2027 para posicionarse. Están redactando cuestionarios de diligencia para proveedores ahora, y la adquisición de IA empresarial se está estancando en esos cuestionarios a un ritmo que tiene muy poco que ver con la tecnología que se adquiere. La solución no es una mejor demostración. Es replantear de qué trata realmente la conversación de adquisición.
Cómo se ve realmente el “estancamiento” en 2026
La prueba técnica de concepto pasa. El modelo produce resultados útiles con la carga de trabajo del cliente. El evaluador técnico escribe una nota positiva y entrega el expediente a adquisiciones. Luego el expediente queda detenido. Tres semanas después, el equipo de cumplimiento del cliente responde con un memorando: “No podemos evidenciar nuestras obligaciones como implementador 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 mientras se formaba: ciclos de negociación que “antes tardaban más de un año en cerrarse se están acelerando a 2 o 3 meses” para productos que cumplen con los nuevos requisitos [4]. La implicación funciona también en sentido contrario. La adquisición de productos que no cumplen con los nuevos requisitos sigue tomando un año. Pilotos técnicos sólidos no cambian eso.
Lo que realmente se pide evidenciar en la adquisición
La Ley de IA de la UE distingue entre el proveedor de un sistema de IA y el implementador del mismo [1]. Un banco que usa una API de LLM de terceros para evaluar solicitudes de préstamo es el implementador. Las obligaciones del implementador incluyen supervisión humana, monitoreo, reporte de incidentes y demostrar estas capacidades a solicitud. Estas obligaciones aplican al banco, no al proveedor del LLM, y el equipo de adquisiciones del banco es el punto donde la selección del proveedor decide si las obligaciones son prácticas de cumplir.
Esta orientación no es exclusiva de la UE. NIST publicó una nota conceptual para un Perfil AI RMF sobre IA Confiable en Infraestructura Crítica el 7 de abril de 2026 [2], el primer alcance federal de las obligaciones del implementador AI RMF para operadores de infraestructura crítica en Estados Unidos. El Observatorio de Políticas de IA de la OCDE mantiene un repositorio vivo “de más de 80 jurisdicciones y organizaciones” [3]. La convergencia entre jurisdicciones sobre las obligaciones del lado del implementador es la tendencia, no una excepción.
Los equipos de adquisiciones en industrias reguladas leen estas señales y se posicionan con anticipación. No pueden esperar hasta el 2 de diciembre de 2027 para saber si una arquitectura de proveedor les permitirá cumplir sus obligaciones.
Por qué “somos SOC 2” es la respuesta equivocada
La respuesta basada en controles del proveedor que históricamente resolvía las conversaciones de adquisición empresarial — SOC 2 Tipo II, ISO 27001, DPA alineado con GDPR — aborda los controles del lado del proveedor. Son necesarios. No son suficientes para las obligaciones del implementador que ahora surgen.
Las obligaciones del implementador requieren que este demuestre, a solicitud, qué datos han pasado por el sistema de IA. Esa es una cuestión sobre los propios registros del implementador, no del proveedor. Un proveedor con certificación SOC-2 que mantiene el prompt y la respuesta en una nube gestionada no puede cerrar esta brecha, porque la brecha está en el lado del implementador: este no puede producir un registro de algo que no ve.
Esta es la descoordinación estructural que detiene la conversación de adquisición. El equipo de cumplimiento redacta un memorando sobre las obligaciones del implementador. El proveedor responde con certificaciones del lado del proveedor. Los dos barcos se cruzan sin encontrarse.
El marco que resuelve el estancamiento
Tres propiedades de la arquitectura de despliegue, nombradas desde el principio en el cuestionario para proveedores, disuelven el estancamiento:
- Inferencia local al implementador. Ya sea en el dispositivo del usuario o en un servidor que opera el implementador. Los prompts y respuestas nunca salen del perímetro del implementador.
- Registros de auditoría sin contenido que posee el implementador. Cada acción administrativa se registra con marca temporal y actor, en el SIEM del implementador. No aparecen prompts ni respuestas en la fila de auditoría. La fila es la evidencia; el contenido es del implementador para retener según su propia política de retención.
- Identidad a través del IdP del implementador. OIDC contra Microsoft Entra ID o Google Workspace. Los controles de acceso y políticas SSO existentes del implementador se aplican sin cambios.
Estas no son propiedades del proveedor para certificar. Son propiedades de la arquitectura de despliegue para especificar. Una vez que el cuestionario del proveedor se enmarca en ellas, el memorando de cumplimiento se redacta solo: cada obligación del implementador tiene una propiedad arquitectónica correspondiente a la que puede referirse.
Cómo se presenta esto en la forma que entregamos
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 implementador usa para hacer cumplir políticas, gestionar licencias y mostrar auditorías. Seis clientes Fortune Global 500 en farmacéutica, finanzas, gobierno, legal, defensa y energía han desplegado esta forma desde 2007 (clientes anteriores), y cada uno de esos compromisos pasó por una versión del marco anterior antes de firmar el contrato.
La forma más rápida de concretarlo es recorrerlo con una carga de trabajo real. Un piloto gratuito de 1 semana pone 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 — suficiente para que el equipo de cumplimiento redacte el memorando sobre las obligaciones que realmente enfrentan.
Referencias
- Comisión Europea. "Ley de IA — Marco regulatorio sobre IA." https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai. Consultado el 03-06-2026.
- NIST. "Marco de Gestión de Riesgos de IA." https://www.nist.gov/itl/ai-risk-management-framework. Consultado el 03-06-2026. La nota conceptual sobre Infraestructura Crítica fue publicada el 7 de abril de 2026.
- Observatorio de Políticas de IA de la OCDE. "Paneles de navegación de políticas." https://oecd.ai/en/dashboards. Consultado el 03-06-2026.
- Andreessen Horowitz. "Estado de la IA Generativa en la Empresa." https://a16z.com/generative-ai-enterprise-2024/. Publicado el 21 de marzo de 2024. Consultado el 03-06-2026.