Un CISO entra a una reunión de la junta con solo la mitad de la respuesta
Imagina un escenario que se repetirá en cientos de empresas en los próximos meses. Un CISO entra a una reunión del consejo y dice: «Nuestra estrategia OpenClaw es NemoClaw. OpenShell de NVIDIA es nuestro motor de políticas. Cisco, CrowdStrike y Microsoft ya lo están utilizando. Estamos cubiertos».
El consejo asiente. La presentación es impresionante. El CISO ha hecho un trabajo real: evaluó el runtime, seleccionó los socios de infraestructura adecuados, implementó agentes en un entorno aislado con límites de red. Por cualquier medida razonable de seguridad en tiempo de ejecución, la arquitectura es sólida.
Seis meses después, llega la persona encargada de la evaluación CMMC. La primera pregunta no es sobre el aislamiento en tiempo de ejecución. No es sobre los límites de red. No es sobre qué modelo utilizan los agentes.
La pregunta es: «Muéstrame a qué CUI accedió este agente, bajo qué autorización, con qué cifrado, y presenta la pista de auditoría que vincula este acceso con una persona autorizadora».
Es entonces cuando el CISO descubre que la política de runtime y la política de cumplimiento son cosas distintas. Y para ese momento, la brecha de cumplimiento se ha ido acumulando durante seis meses de interacciones de agentes sin gobernanza que no pueden ser auditadas de forma retroactiva. La evidencia que necesita la persona evaluadora no existe. No porque el CISO haya sido negligente, sino porque la arquitectura abordó la capa equivocada.
Este escenario no es hipotético. Es el resultado predecible de confundir la afirmación de Jensen Huang sobre el «motor de políticas» con los requisitos de cumplimiento normativo. Entender la diferencia es la decisión de gobernanza más importante que tomará un CISO o responsable de cumplimiento en 2026.
Lo que Huang Realmente Dijo—y lo que Realmente Significa
La precisión importa aquí. En el discurso de apertura de GTC 2026, Huang presentó NVIDIA OpenShell como parte de la tecnología NemoClaw y dijo que estas tecnologías pueden trabajar como «el motor de políticas de todas las empresas SaaS del mundo».
La vicepresidenta de NVIDIA, Kari Briski, amplió en una rueda de prensa previa al evento: «OpenShell proporciona la capa de infraestructura que faltaba bajo las claws para darles el acceso que necesitan para ser productivas, mientras aplica límites de seguridad, red y privacidad basados en políticas».
Estas afirmaciones describen con precisión lo que hace OpenShell. Es un runtime de código abierto que aísla la ejecución de los agentes, aplica controles de red, gestiona la separación de datos a nivel de runtime y proporciona la infraestructura para que los agentes operen dentro de límites definidos. Es una capacidad significativa y necesaria.
Pero «motor de políticas» tiene un significado específico en el contexto de cumplimiento que difiere fundamentalmente del uso de NVIDIA. Cuando una persona responsable de cumplimiento HIPAA escucha «motor de políticas», piensa en: controles de acceso sobre información de salud protegida, aplicación del mínimo necesario, validación de cifrado y registros de auditoría. Cuando lo escucha una persona evaluadora de CMMC, entiende: acceso autorizado a CUI con controles documentados y paquetes de evidencia. Cuando Huang lo dice, se refiere a: límites en tiempo de ejecución para cómo los agentes interactúan con aplicaciones SaaS.
Ambos usos son legítimos. El peligro está en confundirlos.
¿Qué estándares de cumplimiento de datos importan?
Read Now
La Arquitectura Técnica de la Brecha: Política de Runtime vs. Política de Gobernanza de Datos
La diferencia entre política de runtime y política de gobernanza de datos no es semántica. Es arquitectónica. Entender dónde opera cada una en la infraestructura empresarial es esencial para construir una estrategia OpenClaw completa.
La política de runtime (dominio de OpenShell) opera en la capa de ejecución del agente. Responde preguntas como: ¿Puede este agente invocar esta herramienta? ¿Puede este agente acceder a esta ruta de red? ¿Este agente está ejecutándose dentro de un entorno aislado adecuado? ¿El entorno de ejecución está separado del sistema general? Estos son controles a nivel de infraestructura que limitan lo que el agente puede hacer como proceso informático.
La política de gobernanza de datos (dominio de cumplimiento) opera en la capa de acceso a los datos. Responde preguntas como: ¿Puede este agente acceder a este archivo específico? ¿Bajo qué autorización—y quién es la persona autorizadora? ¿Los datos están cifrados con criptografía validada? ¿Cada acceso se registra en un registro auditable? ¿Este registro de auditoría puede vincularse a un requisito de control normativo específico? Estos son controles a nivel de datos que limitan la información que el agente puede manipular y generan la evidencia que exige el cumplimiento. Sin esta capa, las empresas no tienen base para la gestión de la postura de seguridad de datos a medida que proliferan los agentes de IA.
El Pronóstico Kiteworks 2026 documenta cuán lejos están las empresas de cumplir los requisitos de gobernanza de datos para IA. Solo el 43% tiene una puerta de enlace de datos IA centralizada. El diecinueve por ciento ha improvisado soluciones puntuales sin una política coherente. El siete por ciento no tiene controles de IA dedicados.
OpenShell no resuelve ninguna de estas brechas en la capa de datos. No fue diseñado para eso. Su propósito es hacer que los runtimes de los agentes sean seguros—un problema completamente distinto.
Lo que Realmente Exige Cada Marco Normativo Importante—y Dónde OpenShell se Queda Corto
Las regulaciones no regulan agentes. Regulan datos. Esa diferencia es la base de la brecha de cumplimiento.
HIPAA exige que las entidades cubiertas implementen controles de acceso sobre información de salud protegida (§164.312(a)(1)), apliquen el mínimo necesario (§164.502(b)), mantengan registros de auditoría de acceso a información de salud protegida (§164.312(b)), y apliquen cifrado a la información electrónica de salud protegida (§164.312(a)(2)(iv)). Imagina una organización de salud donde un agente de IA extrae historiales de pacientes para generar resúmenes de alta. Ese agente está sujeto a cada uno de estos requisitos. El aislamiento de OpenShell no aplica el mínimo necesario a nivel de archivo—no puede evitar que el agente acceda a historiales de pacientes fuera del flujo de trabajo actual. No genera registros de auditoría específicos de información de salud protegida que muestren qué registros fueron accedidos para cada paciente. No aplica cifrado validado FIPS 140-3 a los datos en reposo. Cuando la persona investigadora de la OCR solicita evidencia de controles de acceso sobre las interacciones del agente con información de salud protegida, los límites en tiempo de ejecución no son una respuesta suficiente.
CMMC exige acceso autorizado a información no clasificada controlada con controles de acceso documentados (AC.1.001, AC.2.006), registro de auditoría de acceso a CUI (AU.2.042) y cifrado validado (SC.3.177). Un contratista de defensa que use agentes de IA para procesar paquetes de datos técnicos debe demostrar que cada interacción del agente con CUI fue autorizada por una persona específica, registrada a nivel de operación y cifrada con criptografía validada. Los límites de red de OpenShell no se corresponden con estos requisitos específicos. Una persona evaluadora de cumplimiento CMMC necesita ver cadenas de delegación que vinculen las acciones del agente con personas autorizadoras—algo que solo puede proporcionar una capa de gobernanza de datos.
PCI DSS 4.0 exige acceso restringido a datos de titulares de tarjetas según la necesidad de saber (Requisito 7), cifrado de datos de titulares de tarjetas (Requisito 4) y registro de todos los accesos (Requisito 10). Un agente OpenClaw que procese datos de pago en un runtime NemoClaw sigue estando sujeto a cada uno de estos requisitos, sin importar cuán bien esté aislado el runtime. La persona auditora QSA no evaluará el runtime. Evaluará si el acceso a los datos de titulares de tarjetas fue restringido, cifrado y registrado según los requisitos de PCI DSS.
SOX Sección 404 exige controles generales de TI sobre datos financieros, incluyendo gestión de identidades y accesos, gestión de cambios y registros de auditoría. Un agente que accede a datos de informes financieros—extrae cifras trimestrales, concilia cuentas, genera reportes—debe operar bajo los mismos controles ITGC que una persona empleada. Esos controles deben ser demostrables ante auditoras, con evidencia que pueda presentarse bajo demanda.
En todos los casos, el requisito normativo apunta a la capa de datos, no a la capa de runtime. OpenShell hace que el runtime sea más seguro. No hace que el acceso a los datos cumpla con las regulaciones.
La Prueba de Microsoft: Incluso los Socios de NVIDIA Ven la Diferencia
La validación más fuerte de la diferencia entre runtime y datos viene de los propios socios de NVIDIA. Microsoft Security anunció que colabora con NVIDIA en aprendizaje adversarial a través de Nemotron y OpenShell, con Alexander Stojanovic, vicepresidente del equipo NEXT AI de Microsoft Security, reportando «una mejora de 160x en la detección y reducción de ataques basados en IA». Es un avance significativo en la detección de amenazas en tiempo de ejecución—identificando cuándo los agentes están siendo manipulados, comprometidos o utilizados con fines maliciosos.
Al mismo tiempo, el blog de seguridad de Microsoft publicó una guía detallada sobre cómo ejecutar OpenClaw de forma segura recomendando tratarlo como «ejecución de código no confiable con credenciales persistentes» y desplegarlo solo en entornos completamente aislados con credenciales dedicadas y no privilegiadas. La guía advierte explícitamente que los agentes ejecutados localmente heredan el conjunto completo de privilegios de la máquina anfitriona, que la memoria persistente implica que cualquier dato comprometido permanece accesible entre sesiones, y que las herramientas de seguridad tradicionales tienen dificultades para detectar el comportamiento de los agentes.
Estas dos posturas no son contradictorias. Son complementarias—y demuestran precisamente la arquitectura por capas que describe este análisis. Microsoft invierte en protección adversarial en tiempo de ejecución a través de OpenShell (Capa 2) mientras reconoce que la protección en tiempo de ejecución por sí sola no resuelve el riesgo de acceso a los datos (Capa 3). La mejora de 160x de Microsoft en la detección de ataques de IA significa que identifican agentes comprometidos más rápido. No significa que los datos a los que accedieron esos agentes estén gobernados, cifrados o auditables con una cadena de custodia que satisfaga a una persona auditora de cumplimiento.
Si Microsoft—el propio socio de seguridad de NVIDIA—mantiene esta distinción en su guía oficial, los CISOs empresariales deberían mantenerla en sus decisiones de arquitectura.
El Ecosistema de Cisco y CrowdStrike: Excelentes en las Capas 1 y 2, Silencio en la Capa 3
El ecosistema que se está formando alrededor de NemoClaw refuerza este posicionamiento complementario. AI Defense de Cisco protege la ejecución de agentes y fue una de las primeras soluciones de seguridad empresarial integradas en la tecnología NemoClaw. El Blueprint de IA Secure-by-Design de CrowdStrike incorpora protecciones de detección de amenazas directamente en los flujos de trabajo de implementación de agentes. La integración con LangChain permite el desarrollo local de agentes con ganchos de gobernanza a nivel de runtime.
Todas estas son capacidades de seguridad valiosas. Y todas operan en las capas de runtime e infraestructura. Ninguna aplica políticas ABAC sobre operaciones individuales de archivos—no pueden distinguir entre un agente que lee una carpeta y uno que descarga su contenido. Ninguna produce paquetes de evidencia de cumplimiento específicos para regulaciones que se correspondan con HIPAA, CMMC, cumplimiento PCI o requisitos de control SOX. Ninguna conserva la cadena de delegación desde la acción del agente hasta la persona autorizadora, que es el vínculo probatorio que exigen las personas evaluadoras de cumplimiento. Ninguna aplica cifrado validado FIPS 140-3 a los datos accedidos por agentes en reposo.
CrowdStrike publicó un análisis detallado de los riesgos de seguridad de OpenClaw y lanzó un paquete de búsqueda y eliminación de contenido a nivel empresarial a través de Falcon for IT. Su enfoque fue la detección y respuesta—identificar dónde está implementado OpenClaw en los endpoints gestionados, entender la exposición y reducir el riesgo. Ese es trabajo de la Capa 2, y es importante. Pero la Capa 3—gobernar qué datos acceden esos agentes, bajo qué controles de cumplimiento, con qué evidencia de auditoría—sigue sin abordarse por ningún socio en el ecosistema de NVIDIA. El ecosistema protege al agente. Nadie en el ecosistema protege los datos que el agente manipula.
Cómo Kiteworks Compliant AI Cubre la Capa de Cumplimiento que OpenShell Deja Abierta
Kiteworks Compliant AI opera en la Capa 3 de la arquitectura empresarial OpenClaw—la capa de gobernanza de datos de IA y cumplimiento normativo. Intercepta cada interacción de agentes de IA con datos sensibles empresariales, verifica la identidad, aplica políticas ABAC, utiliza cifrado validado FIPS 140-3 y captura registros de auditoría inalterables antes de que se acceda a cualquier dato. Se sitúa entre los agentes de IA y los datos regulados que necesitan, gobernando el acceso de forma independiente del modelo, el runtime y el framework del agente.
La arquitectura implementa cuatro requisitos innegociables para el acceso a datos de IA conforme a regulaciones. La identidad autenticada del agente verifica cada agente antes del acceso a los datos y vincula el agente con la persona autorizadora que delegó el flujo de trabajo. La aplicación de políticas ABAC evalúa cada solicitud de datos según una política multidimensional: perfil del agente, clasificación de los datos, contexto de la solicitud y operación específica. El cifrado validado FIPS 140-3 protege todos los datos accedidos por agentes con módulos criptográficos que cumplen los requisitos de auditoría federales y empresariales. Y los registros de auditoría inalterables capturan cada interacción—quién, qué, cuándo y por qué—alimentando directamente los sistemas SIEM empresariales.
El servidor Secure MCP de Kiteworks gobierna asistentes de IA interactivos (Claude, Copilot) mediante el Model Context Protocol con autenticación OAuth 2.0. La puerta de enlace de datos IA gobierna pipelines RAG programáticos y flujos de trabajo automatizados. Tres Governed Assists diseñados específicamente extienden el cumplimiento a las operaciones de datos regulados más comunes—gestión de archivos, operaciones de carpetas y creación de formularios—cada una verificada por identidad, evaluada por ABAC, cifrada con FIPS 140-3 y registrada de forma inalterable. Ambos patrones de integración aplican la misma gobernanza: las políticas de Kiteworks Compliant AI se aplican de manera consistente sin importar el método de integración.
Esto no compite con OpenShell. Es la capa que OpenShell necesita debajo para completar el panorama de cumplimiento. NemoClaw hace que los agentes sean más seguros de ejecutar. Kiteworks Compliant AI hace que los datos a los que acceden estén gobernados y sean auditables, permitiendo a las empresas demostrar cumplimiento de datos en todos los marcos normativos.
Qué Deberían Hacer los CISOs y Responsables de Cumplimiento Antes de su Próxima Revisión de Gobernanza de IA
Primero, audita tu arquitectura actual de gobernanza de IA según el modelo de tres capas. Mapea cada control que tienes a su capa (cómputo, runtime o datos). Identifica en cuál capa tienes más brechas. Para el 57% de las organizaciones según el Pronóstico Kiteworks 2026, la respuesta será la Capa 3.
Segundo, educa a tu consejo sobre la diferencia entre política de runtime y política de cumplimiento antes de que escuchen «motor de políticas» y asuman que el problema está resuelto. Usa la analogía de Kubernetes: las políticas de red no satisfacen a tu auditor, y el aislamiento en tiempo de ejecución tampoco lo hará. Esto es especialmente importante para organizaciones sujetas a DORA y NIS 2, donde las obligaciones de gestión de riesgos TIC ahora se extienden explícitamente a los sistemas de IA.
Tercero, mapea tus obligaciones normativas específicas (HIPAA, CMMC, PCI DSS, SOX) a las interacciones de agentes de IA. Documenta qué requisitos aplican al acceso a datos por parte de agentes y verifica que tus controles actuales los cubran. La mayoría de las organizaciones descubrirán brechas significativas. Una evaluación formal de riesgos sobre el acceso a datos por agentes de IA es cada vez más una expectativa regulatoria, no solo una buena práctica.
Cuarto, implementa gobernanza centralizada de datos de IA antes de ampliar el uso de agentes. Las organizaciones que instalan infraestructura de gobernanza antes de escalar evitan costosos retrabajos. Cada semana sin gobernanza en la capa de datos es una semana de interacciones no gobernadas que no pueden ser auditadas retroactivamente.
Quinto, posiciona la gobernanza de cumplimiento como el acelerador de IA en las discusiones internas. Las organizaciones que implementan IA más rápido son las que pueden pasar la revisión de protección de datos de IA más rápido. La gobernanza automatizada y embebida reemplaza la barrera manual de cumplimiento que bloquea proyectos de IA en todas las empresas reguladas.
El reloj de cumplimiento avanza. Las disposiciones de alto riesgo de la Ley de IA de la UE serán totalmente exigibles en agosto de 2026. Gartner proyecta que más del 50% de las grandes empresas enfrentarán auditorías obligatorias de cumplimiento de IA para fin de año. El momento de construir la Capa 3 es antes de que llegue la persona auditora, no después.
Para saber más sobre cómo Kiteworks puede ayudarte, agenda una demo personalizada hoy mismo.
Preguntas frecuentes
Sí. NVIDIA OpenShell aplica políticas de runtime—aislamiento de agentes, límites de red y controles de acceso a herramientas. El cumplimiento HIPAA requiere controles en la capa de datos: acceso mínimo necesario a información de salud protegida, validación de cifrado (§164.312(a)(2)(iv)) y registros de auditoría de acceso (§164.312(b)). La política de runtime y la política de cumplimiento operan en capas arquitectónicas diferentes. Tu cumplimiento HIPAA requiere una solución de gobernanza de datos como Kiteworks.
AI Defense de Cisco y CrowdStrike operan en las capas de runtime y detección de amenazas—asegurando la ejecución de agentes e identificando agentes comprometidos. Ninguno aplica políticas ABAC sobre operaciones individuales de archivos, genera paquetes de evidencia específicos para regulaciones o conserva cadenas de delegación que vinculen las acciones del agente con personas autorizadoras. El Pronóstico Kiteworks 2026 encontró que el 63% de las organizaciones carecen de estos controles en la capa de datos. Se requiere una solución complementaria de Capa 3.
No. Las personas evaluadoras CMMC revisan los controles en la capa de acceso a los datos—acceso autorizado a CUI (AC.1.001), registro de auditoría de acceso a CUI (AU.2.042) y cifrado validado (SC.3.177). El aislamiento en tiempo de ejecución no satisface estos requisitos. Necesitas una solución de gobernanza de datos que autentique la identidad del agente, aplique políticas de acceso por operación y genere registros de auditoría inalterables trazables a personas autorizadoras.
Estas posturas son complementarias, no contradictorias. Microsoft invierte en protección de runtime (Capa 2) a través de OpenShell, reconociendo que la gobernanza de datos (Capa 3) es un requisito aparte. Su recomendación de tratar OpenClaw como «ejecución de código no confiable con credenciales persistentes» confirma que la seguridad en tiempo de ejecución por sí sola no es suficiente. Construye ambas capas.
Sí. Ejecutar el modelo localmente mantiene los prompts en las instalaciones pero no gobierna el acceso a los datos. Microsoft Security advierte que los agentes ejecutados localmente heredan todos los privilegios de la máquina anfitriona, ampliando el radio de impacto local. Necesitas gobernanza centralizada de la puerta de enlace de datos IA sin importar la ubicación del modelo—Kiteworks aplica los mismos controles tanto si los agentes ejecutan modelos locales como en la nube.
Recursos adicionales
- Artículo del Blog
Estrategias Zero-Trust para una protección de privacidad de IA asequible - Artículo del Blog
Cómo el 77% de las organizaciones falla en la seguridad de datos de IA - eBook
Brecha de gobernanza de IA: Por qué el 91% de las pequeñas empresas juegan a la ruleta rusa con la seguridad de datos en 2025 - Artículo del Blog
No existe «–dangerously-skip-permissions» para tus datos - Artículo del Blog
Las autoridades ya no preguntan si tienes una política de IA. Quieren pruebas de que funciona.