Aprovechar la puerta de enlace de IA de TrueFoundry para el cumplimiento de FIPS

Velocidad, seguridad y soberanía: la puerta de enlace de IA compatible con FIPS

En el sector público actual, estamos presenciando una colisión. Por un lado, tenemos el Fuerza imparable de IA generativa. Los líderes de las agencias saben que los modelos lingüísticos extensos (LLM) pueden reducir los tiempos de procesamiento de documentos de días a segundos. Ven el potencial de lograr enormes aumentos de eficiencia.

En el otro lado se encuentra el Objeto inamovible: Cumplimiento. Específicamente, los requisitos de las Normas Federales de Procesamiento de Información (FIPS). No se trata solo de trámites burocráticos; son leyes físicas no negociables para los datos gubernamentales.

La creencia común es que debes elegir: Velocidad o seguridad. Puede tener una pila de IA moderna y ágil que infrinja las reglas, o una pila «segura» que cumpla con las normas y que esté años atrasada.

No estamos de acuerdo. No tienes que elegir. Solo necesita la arquitectura adecuada, que ofrecemos a través del Puerta de enlace de IA de Truefoundry. Lo llamamos Estrategia de «nube local».

Por qué el cumplimiento no es opcional

Antes de hablar de la solución, seamos diplomáticos pero directos sobre el problema. ¿Por qué necesitamos el FIPS? ¿Por qué no podemos simplemente usar las claves de API estándar para OpenAI o Anthropic?

‍

Resumen ejecutivo: El mandato de la FIPS y el problema «secreto»

Antes de analizar la solución, debemos definir claramente la restricción.

FIPS (Estándares federales de procesamiento de información), específicamente FIPS 140-3 (https://csrc.nist.gov/pubs/fips/140-3/final), es el estándar oficial del gobierno de EE. UU. para los módulos criptográficos. No se limita a preguntar: «¿Están cifrados sus datos?» Plantea una pregunta mucho más rigurosa: «¿El módulo matemático específico que realiza el cifrado ha sido validado por un laboratorio acreditado por el NIST?»

Para las agencias gubernamentales, esto no es negociable. Si los datos (o los secretos que los protegen) son gestionados por un módulo no validado (como el OpenSSL estándar que se encuentra en la mayoría de los programas comerciales), un auditor los considera en la práctica «texto plano».

El conflicto con la IA moderna: la custodia de los secretos La intersección de FIPS y la IA generativa crea una vulnerabilidad crítica con respecto a las claves de API. Los LLM modernos (como el GPT-4 o el Claude 3.5) funcionan mediante el intercambio de secretos a largo plazo (claves de API) que permiten el acceso a los datos y al presupuesto de la agencia.

• El riesgo de SaaS: en una implementación de SaaS estándar, subes estas valiosas claves de API a la nube de un proveedor. Pierdes la custodia. Si ese proveedor las almacena en una base de datos estándar que se basa en un cifrado no validado, de hecho, ha expuesto sus credenciales a un entorno no autorizado.
• La ventaja de On-Prem: al implementar «On-Prem» de Truefoundry, recuperas la soberanía. Sus claves de API se almacenan en su propio AWS Secrets Manager o Azure Key Vault (que son servicios validados por la FIPS). El AI Gateway las recupera mediante programación solo durante el milisegundo necesario para firmar una solicitud. Las claves nunca superan el límite validado por la FIPS y el proveedor del software nunca las puede ver.

La consecuencia de la IA oculta: cuando las agencias no proporcionan una arquitectura que cumpla con estas claves, los equipos se ven obligados a actuar de manera clandestina.

‍

• El incidente de Samsung: En 2023, ingenieros bien intencionados de Samsung pegaron código propietario en la versión pública de ChatGPT para optimizarlo. No «hackearon» nada; solo intentaron ser eficientes. ¿El resultado? Esa IP sensible se filtró al dominio público.
• La lección de Equifax: Las infracciones importantes a menudo no se producen porque faltara el cifrado, sino porque se implementó de manera deficiente (claves débiles, certificados caducados). FIPS evita esto al ordenar validado módulos criptográficos.

La conclusión: Si no les das a tus equipos una forma segura y compatible de usar la IA, encontrarán una forma insegura de hacerlo.

La solución: Truefoundry «On-Prem» en la nube

Truefoundry es una puerta de enlace de IA, un plano de control que administra las interacciones de LLM. Ofrece capacidades de primera clase, como el enrutamiento de modelos, el almacenamiento en caché y el seguimiento de costos.

Ahora, hablemos del elefante en la habitación: El software de Truefoundry en sí no está validado por la FIPS 140-2. Cuenta con sólidas certificaciones comerciales como SOC 2 tipo II e HIPAA, lo que demuestra que está madura y es segura para el uso empresarial. Sin embargo, no lleva el distintivo FedRAMP High específico que se requiere para las cargas de trabajo de defensa.

Entonces, ¿cómo lo usamos en un entorno gubernamental?

Usamos el «Estrategia de fortaleza».

Implementamos Truefoundry's Plano de datos como carga de trabajo autohospedada («local») interno tu existente AWS GovCloud o Gobierno de Azure de Microsoft Azure o Sector público de Google de GCP (en el resto del blog, utilizamos AWS GovCloud para ilustrar el entorno, pero el mismo principio se aplica a Azure y GCP).

• El tanque (infraestructura): AWS GovCloud proporciona la armadura validada por FIPS. Se encarga de la seguridad física y del trabajo criptográfico pesado.
• El motor (Truefoundry): El AI Gateway proporciona velocidad e inteligencia.

Al anidar la aplicación dentro de la infraestructura segura, logramos el cumplimiento mediante herencia.

‍

Inmersión profunda en la arquitectura: La fortaleza

¿Cómo aislamos el software que no es FIPS dentro de un shell compatible con FIPS? Tratamos a Truefoundry Gateway como una «caja negra» protegida por los servicios de AWS.

Figura 1: Modelo conceptual general

El decodificador de acrónimos (por qué lo construimos de esta manera)

1. ALB (balanceador de carga de aplicaciones) compatible con FIPS: Este es nuestro «Bouncer». Configuramos este ALB para usar conjuntos de cifrado validados por FIPS 140-3 o previamente validados por FIPS 140-2. Aquí termina la conexión TLS. Esto significa que el «protocolo de enlace criptográfico» lo gestiona el hardware validado de AWS, no el contenedor Truefoundry. La aplicación «hereda» de manera efectiva este cumplimiento para su ingreso.
2. PVC con separación de aire: La puerta de enlace se encuentra en una subred privada sin una ruta directa a Internet. Solo puede «hablar» cuando la ALB le habla, o «susurrar» a proveedores de LLM específicos a través de un estricto firewall de NAT Gateway.
3. Almacenamiento WORM (escribe una vez, lee muchas): Redirigimos los registros de auditoría a Amazon S3 con Object Lock activado. Esto crea un registro de auditoría legalmente defendible que satisface a los responsables de cumplimiento: una vez que se escribe un registro, no se puede eliminar.

‍

El recorrido del usuario: «Velocidad segura» con Alex

Los diagramas de arquitectura son geniales para los ingenieros, pero veamos cómo esto cambia la realidad diaria de Alex, analista sénior. Este flujo de trabajo demuestra cómo la «Fortaleza» gestiona una tarea del mundo real y, al mismo tiempo, protege a la agencia de los errores.

La misión: Alex tiene una propuesta de proveedor que contiene Información no clasificada controlada (CUI) y potencial PII. Necesita un resumen en 20 minutos.

Figura 2: Flujo de trabajo del usuario con Merits de TrueFoundry

‍

Fase 1: Protección activa (la «red de seguridad»)

Alex pega el texto en la interfaz de usuario de Truefoundry. No se da cuenta de que la página 4 contiene el texto de un proveedor ID fiscal.

• La intercepción: Cuando Alex golpea enter, The Truefoundry Barandas escanea la entrada al instante.
• La acción: El sistema detecta el patrón de identificación fiscal. No solo bloquea la solicitud, sino que también lo hace quirúrgicamente redacta los números sensibles.
• El resultado: El mensaje que realmente llega al LLM es seguro. Alex recibe una notificación: «¡Se encontró un número de identificación fiscal! Redactando...» Está protegido contra una fuga accidental.

Fase 2: Agnosticismo modelo (el «pivote»)

El sistema dirige el mensaje redactado a Llama 3 en Bedrock. El resumen sale «mediocre».

• El interruptor: Alex no necesita llamar a TI. Él selecciona «Claude 3.5 (Azul)» desde el menú desplegable y pulsa «Regenerar».
• El enrutamiento: Truefoundry redirige automáticamente la solicitud a un proveedor de nube completamente diferente. Alex no ve la complejidad de autenticarse con Azure en lugar de con AWS. Simplemente obtiene una respuesta mejor.

Fase 3: Costos y auditoría (el «registro documental»)

Una vez que Alex obtiene su «Resumen perfecto», se activan dos procesos en segundo plano:

1. Almacenamiento en caché: La respuesta está guardada. Si un colega hace la misma pregunta mañana, obtiene la respuesta al instante por un precio de 0,00$.
2. Registro de auditoría: El sistema registra toda la interacción, incluidos el evento de redacción y el costo (0,42 USD), y la envía al administrador a través del almacenamiento S3 WORM para un registro permanente.

‍

Conclusión: un multiplicador de fuerza

El enfoque «local» de Truefoundry permite a las agencias gubernamentales tener lo mejor de los dos mundos.

Al anidar el plano de datos de Truefoundry en AWS GovCloud, crea un sistema que:

1. Soberano: Sus datos nunca salen de su control sin permiso.
2. Ágil: Puede cambiar de modelo (OpenAI, Anthropic, Llama) al instante a medida que la tecnología evoluciona.
3. Cumple con: Aprovecha las validaciones FIPS existentes de AWS para proteger la aplicación.

No se trata solo de marcar una casilla en un formulario de cumplimiento. Se trata de empoderar a personas como Alex para que hagan su trabajo de manera segura, eficiente y sin temor a convertirse en los próximos titulares.

‍