Por qué el cifrado FIPS 140-3 es clave para el acceso a datos de agentes de IA
La mayoría de las organizaciones que implementan agentes de IA para trabajar con datos regulados creen que tienen el cifrado resuelto. Las llamadas API usan TLS. Los datos en reposo están protegidos con cifrado AES-256. El proveedor que aloja el modelo tiene una página de seguridad donde menciona el cifrado. La casilla está marcada.
No es así. No para fines de cumplimiento. CMMC SC.3.177 exige criptografía validada por FIPS, no solo criptografía robusta, sino validada. Las enmiendas de la Regla de Seguridad de HIPAA para 2025 hicieron obligatorio el cifrado de ePHI y requieren módulos criptográficos validados. FedRAMP Moderate exige cifrado validado por FIPS 140 en todo momento. El requisito no es «usar AES-256«, sino «usar un módulo criptográfico que haya sido validado por NIST para implementar correctamente AES-256». Son cosas distintas, y la diferencia entre ambas es donde las implementaciones de agentes de IA actualmente no cumplen.
En este artículo se explica qué significa realmente la validación FIPS 140-3, dónde los flujos de datos de agentes de IA introducen brechas de cifrado en entornos que de otro modo serían conformes, y por qué el cifrado validado en cada punto de la cadena del agente es el tercer pilar fundamental de gobernanza —después de la identidad autenticada y la política ABAC— que requieren las implementaciones de IA regulada.
Resumen Ejecutivo
Idea principal: La validación FIPS 140-3 no es una calificación de la fortaleza del cifrado. Es una certificación de que un módulo criptográfico específico —una biblioteca de software, un dispositivo de hardware o un componente de firmware— ha sido probado por un laboratorio acreditado y validado por NIST para implementar correctamente algoritmos criptográficos aprobados bajo condiciones operativas definidas. Un flujo de datos de agente de IA que usa AES-256 no validado no cumple con FIPS. Un flujo de datos de agente de IA que utiliza módulos validados FIPS 140-3 en cada punto de tránsito y almacenamiento sí lo cumple.
Por qué te debe importar: Las cadenas de inferencia de agentes de IA introducen múltiples puntos de tránsito y almacenamiento de datos que la mayoría de las organizaciones no han evaluado respecto al estado de validación FIPS: puertas de enlace API, entornos de alojamiento de modelos, bases de datos vectoriales, cachés temporales de inferencia, canales de entrega de resultados. Cada uno es una posible brecha de cifrado. Para contratistas de defensa, la brecha es una observación SC.3.177 de CMMC. Para organizaciones de salud, es una deficiencia de la Regla de Seguridad de HIPAA. Para contratistas federales en general, es un incumplimiento de FISMA y FedRAMP. La evaluación requerida es directa, pero la mayoría no la ha realizado para su infraestructura de IA.
Puntos Clave
- La validación FIPS 140-3 es una certificación de módulo, no una especificación de algoritmo. La pregunta no es «¿este sistema usa AES-256?», sino «¿el módulo criptográfico que implementa AES-256 en este sistema aparece en la lista de módulos validados por el Programa de Validación de Módulos Criptográficos de NIST?» Implementaciones no validadas de algoritmos aprobados no cumplen con los requisitos FIPS.
- Las cadenas de inferencia de IA tienen múltiples puntos de tránsito y almacenamiento, cada uno de los cuales requiere evaluación independiente. La conexión TLS de la aplicación a la puerta de enlace API. La conexión de la puerta de enlace al host del modelo. La memoria temporal de trabajo del modelo. La base de datos vectorial. La caché de salida. Confirmar la validación FIPS en la capa de aplicación no confirma la validación en cada componente posterior.
- La infraestructura de IA en la nube multiusuario rara vez proporciona documentación de validación FIPS por defecto. Las plataformas comerciales de IA de propósito general no están diseñadas para cumplir los requisitos federales de validación criptográfica. Las organizaciones que implementan estas plataformas para flujos de trabajo de datos regulados deben solicitar específicamente los certificados de validación de módulos FIPS, y muchas descubrirán que no pueden proporcionarlos.
- FIPS 140-3 reemplaza a FIPS 140-2 para nuevas validaciones. NIST migró el programa a FIPS 140-3 en septiembre de 2021. Las organizaciones y proveedores que aún hacen referencia solo a FIPS 140-2 deben verificar si sus módulos han sido revalidados bajo el estándar actual. Las nuevas adquisiciones deben exigir específicamente validación FIPS 140-3.
- El cifrado validado es la capa que hace duradera el resto de la arquitectura de gobernanza. La identidad autenticada y la aplicación de políticas ABAC previenen el acceso no autorizado. El cifrado validado asegura que, incluso si los datos transitan por una ruta no prevista, no puedan ser leídos. Los tres controles se complementan: cada uno cubre un modo de falla distinto. El cifrado sin control de acceso deja los datos legibles para cualquiera que acceda. El control de acceso sin cifrado validado deja los datos expuestos en tránsito para quien los intercepte.
Qué significa realmente la validación FIPS 140-3
El Estándar Federal de Procesamiento de Información 140-3 es una norma del gobierno estadounidense que especifica los requisitos de seguridad para módulos criptográficos utilizados para proteger información sensible. Es administrado por NIST a través del Programa de Validación de Módulos Criptográficos (CMVP). Un módulo logra la validación al ser probado por un laboratorio acreditado de terceros conforme a los requisitos del estándar, y NIST emite el certificado de validación final.
La validación cubre cuatro niveles de seguridad, desde el Nivel 1 (requisitos básicos, se aceptan implementaciones solo en software) hasta el Nivel 4 (máxima seguridad física, con evidencia y respuesta ante manipulaciones). Para la mayoría de las aplicaciones empresariales reguladas —incluyendo salud, servicios financieros y contratistas de defensa— la validación FIPS 140-3 Nivel 1 es el requisito aplicable. El punto clave es que cualquier nivel de validación FIPS exige que el módulo haya sido realmente probado y certificado, no solo que use algoritmos aprobados.
Lo que certifica la validación: que el módulo implementa correctamente el algoritmo aprobado. Que las funciones de gestión de claves están correctamente implementadas. Que las auto-pruebas del módulo funcionan como se especifica. Que la documentación de seguridad del módulo es precisa y completa. Lo que no certifica la validación: que el sistema que usa el módulo sea seguro en otros aspectos. Un módulo criptográfico validado por FIPS en un sistema mal protegido sigue siendo un sistema mal protegido, pero cumple el requisito criptográfico que exigen CMMC, HIPAA, FedRAMP y NIST 800-171.
FIPS 140-2 vs. FIPS 140-3
NIST migró formalmente el CMVP a FIPS 140-3 en septiembre de 2021, y las validaciones FIPS 140-2 ya no serán aceptadas para nuevas presentaciones después de septiembre de 2026. Las organizaciones deben saber que muchas certificaciones de proveedores existentes aún hacen referencia a FIPS 140-2. Para adquisiciones y evaluaciones de cumplimiento actuales, FIPS 140-3 es el estándar aplicable, y la distinción es relevante al evaluar proveedores de infraestructura de IA cuya documentación de seguridad puede referirse al estándar anterior.
Confías en que tu organización es segura. Pero ¿puedes verificarlo?
Leer ahora
Dónde las cadenas de agentes de IA introducen brechas de cifrado
Un flujo de datos típico de agente de IA en un entorno regulado implica más puntos de tránsito y almacenamiento de los que la mayoría de las evaluaciones de cumplimiento han considerado. Cada uno representa una posible brecha de validación FIPS, no necesariamente porque falte cifrado, sino porque el módulo criptográfico específico en uso puede no estar validado.
| Componente de la cadena | Datos en riesgo | Brecha de validación común |
|---|---|---|
| Aplicación a puerta de enlace API | Datos regulados en la carga útil de la solicitud del agente | La implementación de TLS puede usar una versión estándar de OpenSSL, no un módulo validado por FIPS |
| Puerta de enlace API a host del modelo | Contexto del prompt incluyendo datos regulados recuperados para inferencia | El tránsito interno del proveedor de nube suele estar fuera del límite de cifrado validado |
| Entorno de inferencia del modelo | Datos regulados en la ventana de contexto de trabajo durante la inferencia | La memoria GPU y el entorno de ejecución de inferencia normalmente no tienen estado de validación FIPS |
| Base de datos vectorial (RAG) | Representaciones embebidas de datos regulados usadas para recuperación | El cifrado de la base de datos vectorial suele usar bibliotecas no validadas |
| Caché temporal de salida | Salida del agente que contiene o deriva de datos regulados | El almacenamiento de caché frecuentemente no está cifrado o usa cifrado no validado |
| Canal de entrega de salida | Salida final del agente hacia el sistema o usuario receptor | La entrega puede usar TLS estándar sin validación confirmada de módulo FIPS |
La implicación práctica: una organización que tiene cifrado validado FIPS 140-3 en su capa de aplicación —usando un módulo validado para su almacén de datos principal y comunicaciones— puede tener una postura de cifrado completamente no validada en la cadena de inferencia de IA que ha implementado sobre esa aplicación. El estado de validación FIPS del almacén de datos principal no dice nada sobre el estado de validación de la puerta de enlace API, el host del modelo, la base de datos vectorial y la caché de salida que usa el agente de IA.
El problema de la nube multiusuario
Las plataformas comerciales de IA de propósito general —principales APIs de LLM, servicios de orquestación de IA, proveedores de bases de datos vectoriales— están diseñadas para una adopción empresarial amplia, no para el cumplimiento de validación criptográfica federal. Su documentación de seguridad puede mencionar cifrado, referenciar algoritmos estándar de la industria e incluir diversas certificaciones de seguridad. Lo que normalmente no incluyen son certificados de validación NIST CMVP para los módulos criptográficos específicos usados en los componentes que manejan datos regulados durante la inferencia de IA.
Esta es una brecha estructural: el mercado comercial de IA no fue construido para cumplir los requisitos de FIPS 140-3, y la mayoría de los proveedores no mantienen módulos validados por CMVP como característica estándar de sus plataformas. Contratistas de defensa y agencias federales han resuelto esto para sistemas principales exigiendo servicios en la nube autorizados por FedRAMP y variantes de productos específicas para el gobierno. Pocos han extendido esa evaluación a la capa de inferencia de IA que ahora implementan sobre esos mismos sistemas.
Cómo evaluar y cerrar brechas de cifrado en implementaciones de agentes de IA
1. Mapea cada límite de cifrado en la cadena de datos del agente
Comienza con un mapa completo de cada punto en el que los datos regulados están en tránsito o en reposo dentro de la cadena del agente de IA: desde la fuente de datos, pasando por la capa de orquestación del agente, la puerta de enlace API, el entorno de alojamiento del modelo, cualquier base de datos de recuperación, procesamiento de salida y entrega final. Para cada punto, identifica el módulo criptográfico que proporciona el cifrado. Esto no es lo mismo que identificar el algoritmo de cifrado; requiere identificar la biblioteca de software o el módulo de hardware específico que implementa ese algoritmo.
2. Verifica el estado de validación CMVP de cada módulo
Cruza cada módulo criptográfico identificado con la lista de módulos validados por NIST CMVP, disponible en csrc.nist.gov. Un módulo que no aparece en la lista —o cuyo certificado ha expirado— no cumple con FIPS, sin importar el algoritmo que implemente. Para infraestructura proporcionada por proveedores, solicita directamente el número de certificado CMVP. Un proveedor que no pueda proporcionar un número de certificado CMVP para el módulo criptográfico que maneja tus datos regulados no tiene cifrado validado por FIPS para ese componente.
3. Documenta las brechas y los planes de remediación
Para cada componente de la cadena donde el cifrado validado esté ausente o no confirmado, documenta la brecha, los datos regulados en riesgo y el requisito de cumplimiento aplicable. Esta documentación cumple dos propósitos: define la hoja de ruta de remediación y demuestra a los evaluadores que la organización ha realizado la evaluación de riesgos requerida y tiene un plan para cerrar las brechas identificadas. Las organizaciones en proceso de evaluación CMMC deben tener esta documentación lista, ya que es una solicitud de evidencia previsible.
4. Exige validación FIPS 140-3 en los contratos con proveedores de IA
Agrega requisitos de validación de módulos FIPS 140-3 en los contratos con proveedores de IA para cualquier proveedor cuya infraestructura maneje datos regulados. Esto debe especificar la validación en cada componente que procese esos datos, no solo en la capa de almacenamiento principal. También debe requerir que los proveedores notifiquen a la organización cuando los módulos validados sean actualizados, reemplazados o cuando el estado de validación cambie, ya que los certificados CMVP son específicos de versión y una actualización de software puede invalidar una certificación previa.
Cómo Kiteworks ofrece cifrado validado FIPS 140-3 para el acceso de agentes de IA a datos
La Red de Datos Privados de Kiteworks está construida sobre cifrado validado FIPS 140-3 Nivel 1 para todos los datos en tránsito y en reposo. Esta validación cubre toda la cadena de datos a través de la cual se procesan las interacciones de datos regulados de agentes de IA, no solo la capa de almacenamiento principal, sino cada componente de la arquitectura de gobernanza que maneja datos regulados.
Cuando un agente de IA accede a datos regulados a través de Kiteworks, cada operación de tránsito y almacenamiento utiliza módulos criptográficos validados. El mismo cifrado validado que protege el acceso de usuarios humanos a datos regulados protege automáticamente el acceso de agentes de IA, porque la capa de gobernanza se sitúa entre el agente y los datos, y cada interacción de datos pasa por esa capa. No se requiere una evaluación de cifrado específica para IA; la validación FIPS se extiende al acceso de agentes de IA por arquitectura.
Para contratistas de defensa, esto significa que SC.3.177 se cumple para interacciones de CUI de agentes de IA, con documentación de certificados CMVP presentable directamente a evaluadoras C3PAO. Para organizaciones de salud, se cumplen los requisitos obligatorios de cifrado de las enmiendas de la Regla de Seguridad de HIPAA 2025 para el acceso de agentes de IA a PHI. Para contratistas federales en general, la autorización FedRAMP Moderate que cubre la plataforma Kiteworks se extiende a los flujos de trabajo de agentes de IA que operan a través de ella.
El cifrado validado no es el control de gobernanza de IA más visible; opera bajo la superficie de cada interacción de datos. Pero es la capa que garantiza que la identidad autenticada y la aplicación de políticas ABAC no se vean comprometidas por datos que puedan ser leídos en tránsito. Los tres controles juntos —identidad, política y cifrado validado— constituyen la arquitectura de gobernanza que hace defendible cada interacción de datos regulados de agentes de IA. Descubre más sobre Kiteworks Compliant AI o solicita una demo.
Preguntas frecuentes
CMMC SC.3.177 exige criptografía validada por FIPS, específicamente módulos criptográficos que aparecen en la lista de módulos validados por NIST CMVP. Usar AES-256 a través de una implementación no validada no cumple este requisito. Una evaluadora C3PAO pedirá números de certificado CMVP, no descripciones de algoritmos. Si tu proveedor de infraestructura de IA no puede proporcionar esos certificados para los componentes que manejan CUI, tendrás una observación SC.3.177 sin importar la fortaleza del cifrado.
Las enmiendas de 2025 requieren que el ePHI esté cifrado en tránsito y en reposo usando módulos criptográficos validados, no solo algoritmos robustos. Para implementaciones de agentes de IA, esto significa que cada componente en la cadena de inferencia que maneje PHI —puertas de enlace API, hosts de modelos, bases de datos vectoriales, cachés de salida— debe usar cifrado validado por FIPS. El requisito de la Regla de Seguridad de HIPAA aplica a toda la cadena de datos, no solo al sistema de almacenamiento principal.
Solicita el número de certificado NIST CMVP para cada módulo criptográfico que el proveedor use en los componentes que manejan tus datos regulados. Luego verifica ese número de certificado en la lista de módulos validados por NIST CMVP en csrc.nist.gov. Un proveedor que describa su cifrado como «cumple FIPS» o «AES-256» sin proporcionar un número de certificado CMVP no ha demostrado validación FIPS 140-3. El número de certificado es la única evidencia verificable del estado de validación.
No automáticamente. La autorización FedRAMP cubre el límite del servicio autorizado. Los componentes de inferencia de IA —la capa de orquestación, puertas de enlace API, alojamiento de modelos, bases de datos vectoriales— que has añadido sobre una plataforma autorizada por FedRAMP no están dentro del límite de autorización de esa plataforma a menos que se incluyan específicamente. Cada componente añadido requiere su propia evaluación de validación FIPS. La autorización FedRAMP de la plataforma subyacente brinda una base sólida, pero no sustituye la validación de los componentes de IA implementados encima.
Los tres controles cubren diferentes modos de falla. La identidad autenticada y la cadena de delegación previenen el acceso no autorizado asegurando que solo agentes debidamente autorizados puedan acceder a datos regulados. La aplicación de políticas ABAC garantiza que incluso los agentes autorizados solo accedan a los datos específicos que su flujo de trabajo requiere. El cifrado validado asegura que los datos interceptados en tránsito —ya sea por un atacante en la red o por un componente no autorizado en la cadena de inferencia— no puedan ser leídos. Cada capa cubre una brecha que las otras no. Juntas constituyen una arquitectura de gobernanza donde una falla en cualquier capa no compromete el todo.
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 «–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.