NIST 800-171, CUI y IA: Lo que le falta a tu plan de seguridad del sistema

Miles de organizaciones gestionan información no clasificada controlada bajo contratos gubernamentales sin estar en el proceso de certificación CMMC. Contratistas federales, universidades de investigación, agencias estatales, proveedores de tecnología y firmas de servicios profesionales que reciben CUI bajo DFARS 252.204-7012 deben implementar las 110 prácticas de seguridad de NIST SP 800-171 y documentar esa implementación en un Plan de Seguridad del Sistema. La mayoría ya lo ha hecho para el acceso de usuarios humanos a CUI. Casi ninguna lo ha hecho para el acceso de agentes de IA.

La brecha no es teórica. Se están implementando agentes de IA en organizaciones cubiertas por DFARS para el desarrollo de propuestas, documentación técnica, administración de contratos y flujos de trabajo de la cadena de suministro, todos los cuales involucran rutinariamente CUI. Estas implementaciones no están cubiertas por los SSP existentes. No se reflejan en las evaluaciones de riesgos. No se consideran en las políticas de control de acceso. Y no están generando los registros de auditoría que exigen las prácticas de auditoría y responsabilidad de NIST 800-171 para los eventos de acceso a CUI.

Esta publicación es distinta de la publicación sobre CMMC de esta serie, que se centra en el proceso de evaluación C3PAO para contratistas de la base industrial de defensa que buscan la certificación. Aquí se trata la población más amplia de organizaciones que gestionan CUI bajo contratos DFARS pero que pueden no estar en el camino de certificación CMMC, y cuyas obligaciones de cumplimiento de NIST 800-171 aplican al acceso de agentes de IA a CUI sin importar el estado de certificación.

Resumen Ejecutivo

Idea principal: Las 110 prácticas de seguridad de NIST 800-171 aplican a todo sistema que procese, almacene o transmita CUI, incluidos los agentes de IA. Las organizaciones que han implementado controles 800-171 para el acceso humano a CUI pero no han extendido esos controles a los flujos de trabajo de agentes de IA tienen una brecha de cumplimiento material en su Plan de Seguridad del Sistema. Esa brecha representa un incumplimiento contractual de DFARS, posible exposición bajo la Ley de Reclamos Falsos y una vulnerabilidad en su postura de ciberseguridad que los adversarios que atacan cadenas de suministro gubernamentales saben explotar.

Por qué te debe importar: DFARS 252.204-7012 exige a los contratistas trasladar el cumplimiento de NIST 800-171 a los subcontratistas y proveedores de servicios que gestionan CUI en su nombre. Los proveedores de IA cuya infraestructura procesa CUI, incluso de forma transitoria durante la inferencia del modelo, forman parte de esta cadena de cumplimiento. Una organización que no puede demostrar controles de acceso y registros de auditoría conformes con NIST 800-171 para el acceso de agentes de IA a CUI no cumple con los términos de su contrato DFARS, independientemente de si hay una evaluación CMMC pendiente.

Puntos Clave

1. Las obligaciones de cumplimiento de NIST 800-171 surgen de los contratos DFARS, no de la certificación CMMC. Toda organización que opere bajo DFARS 252.204-7012 debe implementar las 110 prácticas de NIST 800-171 para los sistemas que gestionan CUI. Esta obligación existe independientemente de CMMC. Las organizaciones que gestionan CUI pero aún no están en el proceso de certificación CMMC no están exentas de 800-171; simplemente se auto-certifican en cumplimiento en lugar de someterse a una evaluación de terceros.
2. Cada agente de IA que accede a CUI es un componente del sistema que debe reflejarse en el SSP. El Plan de Seguridad del Sistema debe describir todos los sistemas y componentes que procesan, almacenan o transmiten CUI, junto con los controles de seguridad que protegen cada uno. Un SSP que describe controles para estaciones de trabajo, servidores y sistemas de correo electrónico pero no menciona agentes de IA que acceden a repositorios de CUI es un SSP incompleto, y un SSP incompleto es en sí mismo una observación de incumplimiento 800-171.
3. NIST 800-171 Rev. 3 fortaleció los requisitos de control de acceso y auditoría que deben cumplir las implementaciones de IA. La revisión de 2024 de NIST 800-171 introdujo requisitos mejorados para la granularidad del control de acceso, el detalle de los registros de auditoría y la gestión de riesgos de la cadena de suministro. Estas revisiones hacen que las arquitecturas de implementación de IA existentes, que típicamente ofrecen credenciales a nivel de sesión y registros a nivel de infraestructura, sean aún menos adecuadas para el cumplimiento de 800-171 que bajo la Rev. 2.
4. El requisito de flujo descendente de DFARS extiende las obligaciones de NIST 800-171 a los proveedores de IA. Bajo DFARS 252.204-7012, los contratistas deben trasladar los requisitos de cumplimiento 800-171 a los subcontratistas y proveedores de servicios que gestionan CUI en su nombre. Un proveedor de IA cuya infraestructura procesa CUI durante la inferencia del modelo es un subcontratista o proveedor de servicios cubierto. El contratista no puede confiar en las certificaciones generales de seguridad del proveedor; el proveedor debe cumplir específicamente con los requisitos 800-171 para el manejo de CUI, y el contratista debe documentar esto en su programa de gestión de riesgos de proveedores.
5. La exposición bajo la Ley de Reclamos Falsos es un riesgo material para organizaciones con autoevaluaciones NIST 800-171 inexactas. El Departamento de Justicia ha iniciado casos bajo la Ley de Reclamos Falsos contra contratistas gubernamentales por presentar autoevaluaciones NIST 800-171 inexactas. Una organización que se auto-certifica en cumplimiento de 800-171 mientras opera agentes de IA sobre CUI sin los controles de acceso y registros de auditoría requeridos está presentando una certificación potencialmente falsa, con exposición bajo la FCA que puede extenderse a ejecutivos individuales.

NIST 800-171 y el SSP: Qué Deben Cubrir las Implementaciones de IA

NIST 800-171 organiza sus 110 prácticas de seguridad en 14 familias de controles. Tres son las más directamente implicadas cuando agentes de IA acceden a CUI: Control de Acceso (3.1), Auditoría y Responsabilidad (3.3), e Identificación y Autenticación (3.5). Una cuarta, Gestión de Configuración (3.4), cobra relevancia cuando los componentes de agentes de IA forman parte del límite del sistema. Cada una de estas familias contiene prácticas específicas que el SSP debe abordar y que las implementaciones de agentes de IA deben cumplir para que la organización esté en conformidad con sus obligaciones DFARS.

Control de Acceso (3.1): Acceso Autorizado y Mínimo Necesario

La práctica 3.1.1 exige que el acceso a CUI se limite a usuarios autorizados, procesos que actúan en nombre de usuarios autorizados y dispositivos. La práctica 3.1.2 requiere limitar el acceso a los tipos de transacciones y funciones que los usuarios autorizados pueden ejecutar. Para agentes de IA, estas dos prácticas establecen los mismos requisitos que imponen CMMC AC.1.001 y AC.2.006: el acceso debe estar autenticado, atribuido a una persona autorizada y limitado al mínimo necesario para la tarea específica. Un agente de IA que opera mediante una cuenta de servicio compartida con acceso amplio a repositorios de CUI no cumple ninguna de las dos prácticas.

La práctica 3.1.3 exige controlar el flujo de CUI de acuerdo con autorizaciones aprobadas. Para agentes de IA, esto significa que la capa de gobernanza debe impedir que los datos controlados fluyan hacia destinos no autorizados, como APIs externas, sistemas no cubiertos por DFARS o infraestructura fuera del límite autorizado de CUI. Los prompts del sistema no pueden imponer este control de flujo; solo una política ABAC a nivel de datos puede impedir técnicamente el flujo no autorizado de CUI, sin importar lo que se indique al modelo.

Auditoría y Responsabilidad (3.3): Qué Debe Contener el Registro

La práctica 3.3.1 exige crear y conservar registros de auditoría del sistema para permitir el monitoreo, análisis, investigación e informes de actividad ilícita o no autorizada en el sistema. La práctica 3.3.2 requiere asegurar las identidades de los usuarios responsables de las acciones de sus procesos, incluidos los procesos que actúan en su nombre. Para agentes de IA, la 3.3.2 es la práctica que más directamente requiere una cadena de delegación: el registro de auditoría debe capturar no solo que un agente realizó una acción, sino la identidad de la persona que autorizó y es responsable de esa acción.

Los registros estándar de infraestructura y los registros de inferencia de IA normalmente capturan qué acción del sistema ocurrió, no quién es responsable en el sentido de la 3.3.2. Una organización cuyo registro de auditoría de agentes de IA solo documenta llamadas API hechas por una cuenta de servicio, sin vincular esas llamadas al operador humano específico que delegó el flujo de trabajo, no puede cumplir la práctica 3.3.2 para esos eventos de acceso a CUI.

Identificación y Autenticación (3.5): Se Requiere Identificación Única

La práctica 3.5.1 exige que usuarios y dispositivos, y de manera crítica, procesos incluidos los agentes de IA, sean identificados y autenticados antes de acceder a los sistemas organizacionales y a CUI. La práctica 3.5.2 requiere autenticar las identidades antes de permitir el acceso. Para agentes de IA, identificación única significa que cada agente debe tener una credencial de identidad distinta y verificable, no una cuenta de servicio compartida cuya identidad sea indistinguible entre varios agentes, flujos de trabajo o eventos de acceso.

Gestión de Riesgos de la Cadena de Suministro (3.16): La Dimensión del Proveedor de IA

NIST 800-171 Rev. 3 introdujo requisitos explícitos de gestión de riesgos de la cadena de suministro bajo la familia de prácticas 3.16. La práctica 3.16.1 exige establecer y mantener un plan de gestión de riesgos de la cadena de suministro. Para organizaciones que implementan agentes de IA sobre CUI, la relación con el proveedor de IA es un riesgo de la cadena de suministro que debe evaluarse y documentarse: cómo protege el proveedor la CUI durante la inferencia del modelo, cuáles son sus obligaciones de notificación de incidentes y si cumple los requisitos 800-171 para la CUI que gestiona en nombre del contratista.

La Brecha en el SSP: Lo que la Mayoría de las Organizaciones Pasa por Alto

Un SSP conforme a NIST 800-171 debe describir el límite del sistema, todos los componentes dentro de él y los controles de seguridad que protegen la CUI en todos los componentes. Para la mayoría de las organizaciones que han implementado agentes de IA, el SSP refleja una arquitectura previa a la IA, y los componentes de agentes de IA están ausentes de la descripción del límite del sistema.

Agentes de IA Fuera del Límite del Sistema Definido

Si la infraestructura de agentes de IA no está en la descripción del límite del sistema, ninguna de las prácticas 800-171 se aplica a ella en la postura de cumplimiento documentada. Un auditor que revise el SSP frente a las operaciones reales identificará agentes de IA accediendo a CUI como componentes fuera de alcance, lo que significa que la puntuación de autoevaluación no considera esos componentes y la certificación DFARS de la organización es inexacta. Todo sistema que gestione CUI debe estar en el límite; todo sistema de IA que acceda a CUI es un sistema que gestiona CUI.

Evaluaciones de Riesgos Previas a las Implementaciones de IA

La práctica 3.11.1 exige una evaluación periódica de riesgos de las operaciones organizacionales y del funcionamiento del sistema de CUI. La mayoría de las evaluaciones actuales de las organizaciones son anteriores a sus implementaciones de IA. Una evaluación que no refleje los agentes de IA que ahora acceden a CUI (sus vulnerabilidades, dependencias de proveedores, alcance de acceso y controles de gobernanza) no es una evaluación de riesgos actual para fines de 800-171.

Brechas en el Plan de Acción e Hitos

Una vez que una organización identifica brechas de cumplimiento 800-171 creadas por implementaciones de IA, esas brechas deben registrarse en un POA&M con plazos de remediación. Identificar la brecha sin documentarla es en sí mismo un problema de cumplimiento: 800-171 exige el seguimiento sistemático de deficiencias de controles de seguridad, no solo su identificación.

Mejores Prácticas para el Acceso de Agentes de IA a CUI Conforme a NIST 800-171

1. Incluye Componentes de Agentes de IA en el Plan de Seguridad del Sistema

Actualiza el SSP para incluir todos los agentes de IA y sus componentes de infraestructura en la descripción del límite del sistema. Para cada componente de IA (capa de orquestación, alojamiento de modelos, base de datos vectorial, puerta de enlace API), documenta los controles de seguridad implementados, la CUI que gestiona y el estado de implementación de la práctica. Esto no es opcional: un SSP que no refleje las implementaciones actuales de IA es inexacto, y un SSP inexacto es una observación 800-171. La actualización del SSP debe preceder cualquier expansión adicional de implementación de IA sobre CUI.

2. Implementa Identidad Autenticada de Agente con Preservación de la Cadena de Delegación

Cada agente de IA que acceda a CUI debe operar con una credencial de identidad única a nivel de flujo de trabajo, vinculada al operador humano específico responsable de ese flujo bajo la práctica 3.3.2. Esta credencial debe ser distinta por agente y por flujo de trabajo; las cuentas de servicio compartidas no cumplen las prácticas 3.5.1 ni 3.3.2. La cadena de delegación (operador humano a identidad de agente a evento de acceso a CUI) debe capturarse en cada entrada del registro de auditoría, proporcionando la atribución de responsabilidad que exige 800-171.

3. Aplica Alcance de Acceso a CUI a Nivel de Operación Mediante ABAC

Implementa ABAC que evalúe cada solicitud de CUI de agente de IA en función del perfil autenticado del agente, la clasificación de CUI de los datos solicitados, el contexto del flujo de trabajo y la operación específica. Esto cumple las prácticas 3.1.1 (acceso autorizado) y 3.1.2 (alcance mínimo necesario de la transacción) a nivel de operación. Un agente autorizado para leer una carpeta de contratos no puede descargar todos los archivos, ni acceder a repositorios de CUI adyacentes, ni realizar operaciones fuera de su alcance autorizado, con aplicación en la capa de datos, no en la de modelo.

4. Genera Registros de Auditoría a Nivel de Operación con Atribución de Responsabilidad Humana

Cada interacción de agente de IA con CUI debe registrarse en un log a prueba de manipulaciones que cumpla las prácticas 3.3.1 y 3.3.2: identidad del agente, operador humano responsable de la acción, CUI específica accedida, operación realizada y marca de tiempo. Estos registros deben permitir el monitoreo e investigación de accesos no autorizados y conservarse durante el periodo que exija la política de gestión de registros de la organización. Los registros estándar de infraestructura y de inferencia no cumplen los requisitos de auditoría de 800-171 sin detalle completo de atribución a nivel de operación.

5. Evalúa y Documenta el Manejo de CUI por Proveedores de IA Bajo el Programa de Gestión de Riesgos de la Cadena de Suministro

Para cada proveedor de IA cuya infraestructura gestione CUI en nombre de la organización, realiza una evaluación de gestión de riesgos de proveedores específica para DFARS: evalúa si el proveedor cumple los requisitos 800-171 para el manejo de CUI, documenta la evaluación y traslada contractualmente los requisitos de cumplimiento 800-171. Actualiza el plan de gestión de riesgos de la cadena de suministro bajo la práctica 3.16.1 para reflejar las relaciones con proveedores de IA. Actualiza el POA&M con cualquier brecha identificada. Un proveedor de IA que procese CUI sin cumplimiento documentado de 800-171 es una deficiencia de flujo descendente DFARS que afecta la postura de cumplimiento del contratista principal.

Cómo Kiteworks Permite la Gobernanza de Agentes de IA Conforme a NIST 800-171

Llevar el acceso de agentes de IA a CUI al cumplimiento de NIST 800-171 requiere actualizar tres aspectos simultáneamente: el SSP para incluir los componentes de IA en el límite, los controles técnicos para gobernar el acceso de agentes de IA a CUI en la capa de datos y la evaluación de proveedores para confirmar que la propia plataforma de gobernanza de IA cumple los requisitos 800-171 para el manejo de CUI. La Red de Datos Privados de Kiteworks aborda los tres: proporciona la infraestructura técnica de gobernanza para el acceso de agentes de IA a CUI, trabaja como un componente del sistema documentable en el SSP con capacidades de cumplimiento NIST 800-171 y respalda la evaluación de proveedores que exige el flujo descendente DFARS.

Identidad Autenticada y Cadena de Delegación para las Prácticas 3.5.1 y 3.3.2

Kiteworks autentica cada agente de IA antes de que ocurra el acceso a CUI, usando una credencial única por flujo de trabajo vinculada al operador humano responsable del flujo. La cadena de delegación completa se captura en cada entrada del registro de auditoría. Esto cumple el requisito de identificación única de la práctica 3.5.1 y el requisito de atribución de responsabilidad humana de la práctica 3.3.2, proporcionando la documentación que requieren tanto las declaraciones de implementación de prácticas del SSP como las auditorías de cumplimiento DFARS.

ABAC a Nivel de Operación para las Prácticas 3.1.1, 3.1.2 y 3.1.3

El motor de políticas de datos de Kiteworks evalúa cada solicitud de CUI de agente de IA contra una política multidimensional: perfil autenticado del agente, clasificación de CUI, contexto del flujo de trabajo y operación específica. El acceso mínimo necesario se aplica a nivel de operación y el flujo de CUI se controla solo hacia destinos autorizados. Estos mecanismos de aplicación cumplen las prácticas 3.1.1, 3.1.2 y 3.1.3 en la capa de datos, independientemente del comportamiento del modelo, lo que los convierte en implementaciones de práctica defendibles en auditoría y documentables en el SSP.

Registro de Auditoría a Prueba de Manipulación para las Prácticas 3.3.1 y 3.3.2

Cada interacción de agente de IA con CUI se registra en un log a prueba de manipulaciones, a nivel de operación, que se integra directamente en el SIEM de la organización. El registro documenta la identidad del agente, el operador humano, los datos de CUI accedidos, el tipo de operación, el resultado de la evaluación de políticas y la marca de tiempo, cumpliendo las prácticas 3.3.1 y 3.3.2 con el detalle a nivel de operación y la atribución de responsabilidad humana que exige 800-171. Cuando una revisión de cumplimiento DFARS solicita evidencia de controles de acceso a CUI, la respuesta es un paquete de evidencia exportable, no una investigación en registros dispersos de infraestructura.

Cifrado FIPS 140-3 y Operaciones de Archivos CUI Gobernadas

Todo CUI accedido a través de Kiteworks está protegido por cifrado validado FIPS 140-3 Nivel 1 en tránsito y en reposo, cumpliendo los requisitos de cifrado de NIST 800-171. Las capacidades de Operaciones de Carpetas Gobernadas y Gestión de Archivos Gobernados de Kiteworks Compliant AI permiten a los agentes de IA organizar y gestionar repositorios de CUI con cada operación aplicada por el motor de políticas de datos, cumpliendo los requisitos de RBAC y segregación de CUI sin aprovisionamiento manual y proporcionando implementaciones de práctica documentables en el SSP para las prácticas de gestión de configuración bajo la familia 3.4.

Para las organizaciones que gestionan CUI bajo contratos DFARS y necesitan llevar las implementaciones de agentes de IA al cumplimiento de NIST 800-171, Kiteworks proporciona la infraestructura técnica de gobernanza y las implementaciones de práctica documentables en el SSP que cierran la brecha entre la postura de cumplimiento previa a la IA y la realidad operativa del acceso agente a CUI. Descubre más sobre las capacidades de cumplimiento NIST 800-171 de Kiteworks o solicita una demo.

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 Juega a la Ruleta Rusa con la Seguridad de Datos en 2025
• Artículo del Blog
  No Existe un «–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.