CMMC 2.0 y agentes de IA: Qué significa el «acceso autorizado» para los flujos de trabajo que manejan CUI

Los contratistas de defensa están implementando agentes de IA en el desarrollo de propuestas, documentación de programas, gestión de la cadena de suministro y flujos de trabajo de datos técnicos. Muchos de estos flujos de trabajo involucran información no clasificada controlada. Esto los coloca directamente dentro del alcance de CMMC 2.0, no como una consideración futura, sino como una obligación de cumplimiento actual que los evaluadores de terceros ya están revisando.

Los requisitos de control de acceso, auditoría y cifrado de CMMC no contemplan ninguna excepción para sistemas operados por máquinas. Ya sea que un empleado autorizado o un agente de IA autónomo acceda a un documento CUI, la obligación de cumplimiento es idéntica: el acceso debe estar autorizado, gobernado por rol y contexto, cifrado con criptografía validada y registrado en una auditoría a nivel de operación vinculada a un autorizador humano. La mayoría de las implementaciones de IA en la base industrial de defensa no han sido diseñadas para cumplir ninguno de estos requisitos.

Esta publicación explica lo que CMMC 2.0 exige específicamente para flujos de trabajo de IA que manejan CUI, identifica las brechas de cumplimiento que los evaluadores detectarán y describe las mejores prácticas para gobernar el acceso de agentes de IA a CUI de forma que se genere evidencia defendible —no explicaciones— cuando llegue la C3PAO.

Resumen ejecutivo

Idea principal: Las prácticas de control de acceso, registro de auditoría y cifrado de CMMC 2.0 aplican a todo sistema que maneje CUI, incluidos los agentes de IA. Los contratistas de defensa que implementan IA en flujos de trabajo con CUI sin identidad autenticada del agente, aplicación de políticas ABAC y registro de auditoría a nivel de operación están acumulando exposición de cumplimiento que no puede remediarse retroactivamente una vez que inicia una evaluación.

Por qué te debe importar: La certificación CMMC es un requisito para ser elegible a contratos: las organizaciones que no aprueban la evaluación pierden acceso a contratos del DoD. Los evaluadores revisan los controles en la capa de acceso a datos, no en la capa del modelo. Un contratista de defensa que no pueda demostrar una cadena de delegación que vincule cada interacción de agente de IA con CUI a un autorizador humano, demostrar la aplicación de acceso mínimo necesario a nivel de operación y mostrar cifrado validado FIPS 140-3 en cada ruta de datos CUI tendrá hallazgos materiales. El momento de cerrar esas brechas es antes de que llegue la C3PAO, no durante la evaluación.

Puntos clave

  1. CMMC 2.0 aplica a agentes de IA que manejan CUI sin excepción. AC.1.001 exige acceso autorizado a CUI sin importar si quien accede es humano o automatizado. CMMC no distingue entre un empleado autorizado y un agente de IA procesando un paquete de datos técnicos. Los controles que gobiernan el acceso humano a CUI aplican directa y completamente al acceso de agentes.
  2. Los evaluadores revisan controles en la capa de datos, no en la capa del modelo. Una C3PAO no preguntará qué modelo de IA usan tus agentes ni cómo están configurados los prompts del sistema. Preguntarán: ¿a qué CUI accedió el agente, bajo qué autorización, con qué cifrado y puedes presentar una auditoría que vincule el acceso a un autorizador humano? Si la respuesta a cualquiera de esas preguntas no es un paquete de evidencia documentada, la evaluación generará hallazgos.
  3. Los requisitos de segregación de CUI se extienden a las estructuras de carpetas gestionadas por IA. Las prácticas de control de acceso de CMMC exigen que el CUI esté segregado y accesible solo para personal autorizado. Cuando agentes de IA crean, mueven o reestructuran jerarquías de carpetas que contienen CUI, esas estructuras deben heredar los mismos controles RBAC/ABAC que las provisionadas manualmente. Las carpetas generadas por IA que no heredan automáticamente controles de política crean brechas de segregación.
  4. La cadena de delegación es lo que conecta las acciones del agente de IA con la responsabilidad humana. Las prácticas AC y AU de CMMC exigen que el acceso a CUI sea rastreable hasta un individuo autorizado. Para agentes de IA, esto significa que el registro de autenticación debe vincular la identidad del agente con el humano específico que delegó el flujo de trabajo, no solo con una cuenta de servicio. Sin esta cadena de delegación, la auditoría está incompleta por definición.
  5. Los guardarraíles en tiempo de ejecución y los prompts del sistema no son controles de acceso CMMC. El sandboxing de red, los motores de políticas en tiempo de ejecución y los filtros de seguridad de IA operan en la capa del modelo o de ejecución. Son capacidades de seguridad relevantes, pero no cumplen los requisitos de CMMC en la capa de datos para acceso autorizado, registro de auditoría o validación de cifrado. Una C3PAO no los aceptará como evidencia de cumplimiento de AC.1.001 o AU.2.042.

Lo que exige CMMC 2.0 para sistemas de IA que manejan CUI

CMMC 2.0 nivel 2 se alinea con las 110 prácticas de seguridad de NIST SP 800-171 en 14 dominios. Cuatro son los más directamente implicados cuando agentes de IA acceden, procesan o gestionan CUI: Control de Acceso (AC), Auditoría y Responsabilidad (AU), Identificación y Autenticación (IA) y Protección de Sistemas y Comunicaciones (SC).

Control de acceso: AC.1.001 y AC.2.006

AC.1.001 exige que el acceso a CUI esté limitado a usuarios autorizados, procesos que actúan en nombre de usuarios autorizados y dispositivos. «Procesos que actúan en nombre de usuarios autorizados» cubre explícitamente a los agentes de IA: no es un área gris. AC.2.006 exige que el acceso esté limitado a los tipos de transacciones y funciones que los usuarios autorizados pueden ejecutar. Para agentes de IA, el acceso mínimo necesario debe aplicarse a nivel de operación: un agente autorizado para leer una carpeta de contratos no está automáticamente autorizado para descargar todos los archivos, mover registros o eliminar contenido. Cada operación requiere una evaluación de política independiente.

Auditoría y responsabilidad: AU.2.042

AU.2.042 exige que las actividades de los usuarios individuales —incluidos los procesos que actúan en su nombre— sean rastreadas, registradas y revisadas periódicamente. El registro de auditoría debe capturar la identidad autenticada del agente, el humano que autorizó el flujo de trabajo, el CUI específico accedido, la operación realizada y la marca de tiempo. Un registro que solo muestre que se llamó a un endpoint de API no cumple esta práctica. Un registro que indique qué documento CUI fue accedido, por qué identidad de agente, bajo qué política y autorizado por qué humano, sí lo cumple.

Identificación y autenticación: Prácticas IA

Las prácticas IA de CMMC exigen que usuarios y procesos sean identificados y autenticados de forma única antes de acceder a CUI. Los agentes de IA que operan mediante cuentas de servicio compartidas o claves API no cumplen este requisito. Cada agente debe tener una credencial de identidad única vinculada al flujo de trabajo específico y al humano que lo autorizó. Si varios agentes comparten una identidad, o si el registro de autenticación no puede rastrear el acceso hasta un decisor humano específico, no se pueden cumplir las prácticas IA.

Protección de sistemas y comunicaciones: SC.3.177

SC.3.177 exige que el CUI sea cifrado usando criptografía validada FIPS cuando se transmite por redes abiertas y en almacenamiento. Para agentes de IA, esto significa que cada ruta de datos que toque el agente —llamadas API a repositorios CUI, pipelines de inferencia de modelos, cachés temporales de archivos, canales de entrega de salida— debe usar módulos criptográficos validados FIPS 140-3. Implementaciones estándar de TLS y AES-256 sin validación confirmada FIPS 140-3 no cumplen SC.3.177. Un evaluador que revise una implementación de IA pedirá certificados de validación de módulos criptográficos, no documentación de configuración del proveedor.

Cumplimiento CMMC 2.0 Hoja de ruta para contratistas del DoD

Leer ahora

Dónde las implementaciones de IA no cumplen los requisitos de CMMC

La arquitectura estándar para implementaciones de agentes de IA en la DIB —un agente conectado a un repositorio de documentos vía API, gobernado por una cuenta de servicio y un prompt de sistema— falla la evaluación CMMC en múltiples dimensiones a la vez. Estas son discrepancias estructurales entre cómo se construyen la mayoría de implementaciones de IA y lo que los evaluadores deben verificar.

Sin cadena de delegación no hay autorizador responsable

Cuando un evaluador CMMC revisa un evento de acceso a CUI y pregunta quién lo autorizó, la respuesta debe ser un individuo específico con autoridad documentada. Una cuenta de servicio responde con un nombre de sistema. Una clave API responde con un token. Sin una cadena de delegación que vincule la acción del agente con el humano que autorizó el flujo de trabajo, el evento de acceso no tiene autorizador responsable: un hallazgo directo contra AC.1.001 y AU.2.042. Es fundamental que esto no puede corregirse retroactivamente. La cadena de delegación debe registrarse en el momento del acceso o no existirá en la auditoría.

El alcance de acceso a nivel de operación está ausente en la arquitectura

La mayoría de implementaciones de IA otorgan a los agentes credenciales amplias de repositorio y confían en los prompts del sistema para limitar lo que realmente hace el agente. Los evaluadores CMMC revisan lo que el agente podía hacer técnicamente, no solo lo que se le indicó hacer. Si una cuenta de servicio otorga acceso a 10,000 documentos CUI y la tarea del agente requería tres, el agente tuvo acceso no autorizado a 9,997 desde la perspectiva de acceso mínimo necesario de AC.2.006, independientemente de si los recuperó.

Las estructuras de carpetas creadas por IA no heredan controles

Los agentes de IA cada vez más crean estructuras de carpetas para documentos de propuestas, entregables de programas y paquetes de datos técnicos. CMMC exige que esas carpetas hereden automáticamente los controles de acceso a CUI. En la mayoría de implementaciones, las jerarquías de carpetas creadas por IA no tienen políticas RBAC o ABAC aplicadas a menos que un humano las provea después. Cada documento colocado en una carpeta creada por IA sin gobierno es un hallazgo de segregación CUI.

Mejores prácticas para acceso de agentes de IA a CUI conforme a CMMC

1. Establece credenciales de identidad a nivel de agente vinculadas a autorizadores humanos

Cada agente de IA que acceda a CUI debe contar con una credencial de identidad única a nivel de flujo de trabajo, no una cuenta de servicio compartida. Esa credencial debe estar vinculada en el registro de autenticación al individuo específico que autorizó el flujo de trabajo. La cadena de delegación —autorizador humano, identidad del agente, evento de acceso a CUI— debe capturarse en cada entrada del registro de auditoría. Las credenciales compartidas no cumplen los requisitos IA de CMMC sin importar el alcance en la capa de aplicación.

2. Aplica ABAC a nivel de operación para cada solicitud de datos CUI

Implementa control de acceso basado en atributos que evalúe cada solicitud de CUI según el perfil autenticado del agente, la clasificación CUI de los datos, el contexto del flujo de trabajo y la operación específica. Un agente autorizado para leer una carpeta de propuestas no está autorizado para descargar todos los archivos, mover contenido o acceder a categorías CUI adyacentes. Esta evaluación por operación es el mecanismo que cumple el requisito de mínimo necesario de AC.2.006.

3. Asegura que las estructuras de carpetas gestionadas por IA hereden controles CUI automáticamente

Cada jerarquía de carpetas creada o modificada por un agente de IA que contenga CUI debe heredar controles RBAC y ABAC en el momento de la creación, no mediante provisión manual posterior. La capa de gobierno que aplica la segregación CUI debe estar integrada en la operación de creación de carpetas. Las carpetas sin controles heredados son hallazgos de segregación sin importar quién o qué las creó.

4. Registra auditorías a nivel de operación, evidentes ante manipulación, para todo acceso de agente a CUI

Cada interacción de agente de IA con CUI debe registrarse a nivel de operación: identidad del agente, autorizador humano, documento o carpeta específica accedida, tipo de operación, resultado de la evaluación de política y marca de tiempo. El registro debe ser evidente ante manipulación y exportable para revisión de evidencia de C3PAO e integración con SIEM. Los registros API a nivel de sesión no cumplen AU.2.042, y esta es una de las primeras solicitudes de evidencia que hacen los evaluadores.

5. Valida cifrado FIPS 140-3 en cada ruta de datos CUI

Audita cada punto en que CUI se transmite o almacena en los flujos de trabajo de agentes de IA —llamadas API, alojamiento de modelos, bases de datos vectoriales, memoria temporal de agentes, archivos de salida— y confirma la certificación de módulo criptográfico validado FIPS 140-3 para cada uno. SC.3.177 exige criptografía validada, no solo algoritmos robustos. Una organización que use AES-256 pero no pueda presentar el certificado de validación del módulo FIPS 140-3 tiene una brecha de hallazgo sin importar la fortaleza del cifrado.

Cómo Kiteworks habilita la gobernanza de agentes de IA conforme a CMMC

Gobernar el acceso de agentes de IA a CUI al nivel que exigen los evaluadores CMMC requiere una arquitectura diferente a la que la mayoría de contratistas de defensa han implementado. Las cuentas de servicio, claves API y prompts de sistema resuelven la capa de aplicación. CMMC evalúa la capa de datos. La Red de Datos Privados de Kiteworks —autorizada FedRAMP Moderate y compatible con casi el 90% de los requisitos de CMMC 2.0 nivel 2— brinda a los contratistas de defensa una capa de gobernanza que intercepta cada interacción de agente de IA con CUI antes de que ocurra, aplicando la verificación de identidad, política de acceso, cifrado y registro de auditoría que los evaluadores CMMC revisarán.

Identidad de agente y cadena de delegación para AC.1.001 y AU.2.042

Kiteworks autentica cada agente de IA antes de cualquier acceso a CUI y vincula esa autenticación con el humano que delegó el flujo de trabajo. La cadena de delegación completa —identidad del autorizador, identidad del agente, contexto de la operación y resultado de la política— se preserva en cada entrada del registro de auditoría. Cuando una C3PAO pregunta quién autorizó ese acceso a CUI y qué se le permitió hacer al agente, la respuesta es un registro completo, con marca de tiempo y evidente ante manipulación, no una reconstrucción desde registros de aplicación.

ABAC a nivel de operación para cumplimiento de mínimo necesario AC.2.006

El motor de políticas de datos de Kiteworks evalúa cada solicitud de CUI de agente de IA frente a una política multidimensional: el perfil autenticado del agente, la clasificación CUI de los datos solicitados, el contexto del flujo de trabajo y la operación específica. Un agente autorizado para leer documentos de propuestas en una carpeta específica no puede descargar todos los archivos, acceder a categorías CUI adyacentes ni realizar operaciones fuera de su alcance autorizado. El acceso mínimo necesario se aplica a nivel de operación, tal como exige AC.2.006 y como la mayoría de implementaciones de IA actualmente no pueden demostrar.

Operaciones de carpetas gobernadas para segregación de CUI

La función Governed Folder Operations Assist de Kiteworks Compliant AI permite a los agentes de IA crear, renombrar, mover y organizar jerarquías de carpetas CUI usando instrucciones en lenguaje natural, con cada operación gobernada por el motor de políticas de datos. Las estructuras de carpetas creadas por agentes de IA heredan automáticamente controles RBAC y ABAC, cumpliendo los requisitos de segregación de CUI de CMMC desde el momento de la creación. No se requiere provisión manual y ninguna carpeta creada por IA existe fuera del límite de gobernanza.

Cifrado FIPS 140-3 y auditoría evidente ante manipulación para SC.3.177 y AU.2.042

Todo CUI accedido mediante Kiteworks está protegido por cifrado validado FIPS 140-3 nivel 1 en tránsito y en reposo, cumpliendo SC.3.177 con certificación de módulo validado que puede presentarse directamente a los evaluadores. Cada interacción de agente con CUI se captura en un registro a nivel de operación, evidente ante manipulación, que se integra con el SIEM de la organización. Cuando la C3PAO solicita un paquete de evidencia para AU.2.042, la respuesta es un informe exportable, no una reconstrucción forense de registros de infraestructura que nunca fueron diseñados para capturar lo que exige CMMC.

Para los contratistas de defensa que quieren implementar IA a velocidad operativa sin acumular hallazgos CMMC, Kiteworks proporciona la infraestructura de gobernanza que hace que cada interacción de agente de IA con CUI esté lista para ser evaluada desde el diseño. Descubre más sobre las capacidades de cumplimiento CMMC de Kiteworks o solicita una demo para ver cómo Kiteworks gobierna el acceso de agentes de IA a CUI en tu entorno.

Preguntas frecuentes

Sí. CMMC AC.1.001 cubre explícitamente los «procesos que actúan en nombre de usuarios autorizados», lo que incluye a los agentes de IA. Las prácticas de control de acceso, registro de auditoría, identificación y autenticación, y cifrado que gobiernan el acceso humano a CUI aplican directamente al acceso de agentes de IA. Un evaluador que revise la implementación de IA de un contratista de defensa evaluará el cumplimiento según las mismas prácticas CMMC que para el acceso de usuarios humanos, sin exenciones específicas para IA ni requisitos reducidos.

Una evaluadora C3PAO que revise el acceso de agentes de IA a CUI pedirá: una cadena de delegación que vincule cada acceso de agente a CUI con un autorizador humano identificado (AC.1.001, AU.2.042); evidencia de que el acceso mínimo necesario se aplica a nivel de operación, no solo de sesión (AC.2.006); registros de auditoría a nivel de operación que muestren qué CUI fue accedido, por qué agente, bajo qué política y cuándo (AU.2.042); y certificados de validación de módulo criptográfico FIPS 140-3 para cada ruta de datos CUI que toque el agente (SC.3.177). Los prompts de sistema y los guardarraíles en tiempo de ejecución no cumplen ninguno de estos requisitos.

Sí. Las prácticas de control de acceso de CMMC exigen que el CUI esté segregado y solo accesible para personal autorizado, sin importar cómo se creó la estructura de carpetas. Las jerarquías de carpetas creadas por agentes de IA deben heredar controles RBAC y ABAC en el momento de la creación. Las carpetas que no heredan automáticamente controles de política —incluso si las crea un agente de IA en un flujo de trabajo legítimo— representan hallazgos de segregación de CUI. La provisión manual posterior de controles no elimina el periodo en que la carpeta existió sin gobernanza.

CMMC SC.3.177 exige criptografía validada FIPS para CUI, lo que significa certificación de módulo validado, no solo el uso de algoritmos de cifrado robustos. Un agente de IA que use AES-256 mediante una implementación que no tenga validación FIPS 140-3 no cumple SC.3.177. Los contratistas de defensa deben auditar cada componente en la ruta de datos CUI del agente de IA —llamadas API, alojamiento de modelos, bases de datos vectoriales, almacenamiento temporal, archivos de salida— y obtener certificados de validación de módulo FIPS 140-3 para cada uno.

No. Los guardarraíles en tiempo de ejecución, el sandboxing de red y los filtros de seguridad a nivel de modelo operan en la capa de ejecución, no en la capa de acceso a datos. Los evaluadores CMMC revisan los controles de acceso en la capa de datos: identidad autenticada del agente vinculada a un autorizador humano, alcance de acceso a nivel de operación, registro de auditoría a nivel de operación y cifrado validado. Los controles en tiempo de ejecución son capacidades de seguridad relevantes, pero no generan los paquetes de evidencia que cumplen AC.1.001, AC.2.006, AU.2.042 ni SC.3.177.

El riesgo más inmediato es que cada interacción de agente de IA con CUI sin gobernanza está generando eventos de acceso que no pueden auditarse retroactivamente según los estándares CMMC. Los registros de auditoría a nivel de operación que capturan cadenas de delegación, evaluaciones de políticas y CUI específico accedido deben crearse en el momento del acceso: no pueden reconstruirse después. Cada semana de acceso de agente de IA a CUI sin gobernanza es una semana de evidencia de auditoría que nunca existirá. Cuando comience la auditoría de cumplimiento CMMC, esa brecha será permanente: no un ítem de remediación, sino un hallazgo contra AU.2.042 por todo el periodo de acceso no registrado.

Recursos adicionales

  • Artículo del Blog
    Estrategias Zero‑Trust para protección asequible de privacidad en IA
  • 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
    Los reguladores ya no preguntan si tienes una política de IA. Quieren pruebas de que funciona.

Comienza ahora.

Es fácil comenzar a asegurar el cumplimiento normativo y gestionar eficazmente los riesgos con Kiteworks. Únete a las miles de organizaciones que confían en cómo intercambian datos confidenciales entre personas, máquinas y sistemas. Empieza hoy mismo.

Table of Content
Compartir
Twittear
Compartir
Explore Kiteworks