)
¿Cómo se añaden guardrails a LiteLLM?
El proxy de LiteLLM admite guardrails mediante una sección guardrails en el archivo config.yaml. Se integra con más de 40 proveedores de guardrails externos que cubren detección de inyección de prompts, enmascaramiento de PII, filtrado de contenido y aplicación de políticas.
Cada guardrail se ejecuta en modo pre_call, during_call o post_call, y puede activarse o desactivarse por solicitud, por clave API o por equipo. En despliegues empresariales, el ecosistema de guardrails nativos cubre lo básico pero deja brechas en la aplicación de políticas basada en intención, el enrutamiento por jurisdicción, las pistas de auditoría a nivel de inferencia y la seguridad de agentes.
NeuralTrust TrustGuard se integra como guardrail personalizado directamente en LiteLLM para cubrir esas brechas.
TL;DR - Puntos Clave
- LiteLLM es un excelente gateway de IA para enrutamiento, gestión de costes y balanceo de carga entre más de 100 proveedores LLM. No fue diseñado como producto de seguridad.
- El ecosistema de guardrails de LiteLLM admite más de 40 proveedores que cubren detección de inyección de prompts, enmascaramiento de PII, filtrado de contenido y aplicación de políticas.
- Los guardrails se ejecutan en tres modos:
pre_call(antes de la llamada al LLM),during_call(en paralelo) ypost_call(tras la respuesta). - Las brechas empresariales: sin aplicación de políticas basada en intención, sin enrutamiento por jurisdicción, sin pistas de auditoría a nivel de inferencia, sin seguridad para agentes, sin pruebas adversariales previas al despliegue.
- NeuralTrust TrustGuard se integra con LiteLLM como guardrail personalizado: todas las aplicaciones que ya apunten al proxy quedan cubiertas sin ningún cambio en el código del cliente.
- Si quieres reemplazar LiteLLM por completo en lugar de extenderlo, TrustGate es la alternativa. Los dos productos no están diseñados para funcionar en serie.
LiteLLM enruta tus solicitudes de IA de manera brillante. Se integra con un amplio ecosistema de proveedores de guardrails para inyección de prompts, enmascaramiento de PII y filtrado de contenido. Eso cubre lo básico.
Para todo lo empresarial (pistas de auditoría de cumplimiento, enrutamiento por jurisdicción, monitorización de agentes, red teaming) necesitas una capa de seguridad adicional. NeuralTrust TrustGuard se integra directamente en LiteLLM como guardrail personalizado, cubriendo entrada y salida en cada solicitud sin tocar el código de tu aplicación.
)
LiteLLM Destaca en Enrutamiento. Eso No Es lo Mismo que Seguridad.
Imagina esto. Llevas tres meses con un despliegue de IA en producción. LiteLLM funciona perfectamente. Enruta consultas de clientes a GPT-4o, hace fallback a Claude cuando OpenAI es lento, hace seguimiento del gasto por equipo y aplica límites de tasa. Tus ingenieros lo adoran.
Entonces tu responsable de seguridad hace una pregunta: "¿Qué está inspeccionando lo que va a esos modelos antes de llegar?"
Silencio.
LiteLLM fue diseñado para resolver el problema del enrutamiento multi-proveedor. Lo resolvió de forma brillante. El repositorio de GitHub tiene decenas de miles de estrellas por una razón. Pero enrutar tráfico de IA y securizar tráfico de IA son dos trabajos distintos.
Este artículo te muestra ambos: cómo funciona el sistema de guardrails de LiteLLM, dónde deja de ser suficiente y cómo integrar NeuralTrust TrustGuard para cubrir las brechas.
Qué Ofrece el Ecosistema de Guardrails de LiteLLM
El proxy de LiteLLM dispone de una sección guardrails en su config.yaml. Admite más de 40 proveedores de guardrails, cubriendo cuatro áreas de capacidad principales:
- Detección de inyección de prompts: escanea las entradas de usuario en busca de intentos de secuestrar las instrucciones del modelo.
- Enmascaramiento de PII y PHI: detecta y enmascara datos personales (tarjetas de crédito, direcciones de correo, NSS, números de teléfono) antes de que lleguen al LLM.
- Detección de secretos: detecta claves API y credenciales en las entradas.
- Aplicación de políticas de contenido: marca o bloquea entradas y salidas no conformes con las políticas definidas.
Cada guardrail puede ejecutarse en tres modos:
pre_call: se ejecuta antes de la llamada al LLM, solo sobre la entradaduring_call: se ejecuta en paralelo con la llamada al LLM, sobre la entradapost_call: se ejecuta tras la llamada al LLM, sobre la entrada y la salida
La estructura básica de configuración tiene este aspecto:
Inicia el proxy:
Puedes activar o desactivar guardrails por solicitud usando el campo metadata.guardrails:
Y aplicarlos a nivel de clave API, útil para dar a las herramientas internas un acceso diferente al de los endpoints orientados al cliente:
Esto es sólido para prototipos y la mayoría de despliegues internos. El problema aparece cuando necesitas demostrárselo a un regulador.
)
Lo Que los Guardrails Nativos de LiteLLM No Pueden Hacer
Esta es la lista de brechas. No son peticiones de funcionalidades, son los problemas que surgen en despliegues empresariales reales.
1. Sin aplicación de políticas basada en intención
Los proveedores de guardrails nativos detectan patrones: formatos de PII conocidos, firmas de inyección conocidas. No entienden lo que una conversación intenta lograr a nivel semántico. Un usuario que sondea lentamente el contenido del prompt del sistema a lo largo de diez mensajes aparentemente inocentes no será detectado solo con coincidencia de patrones.
2. Sin enrutamiento por jurisdicción
LiteLLM enruta según el rendimiento del modelo, el coste y la carga. No sabe que los datos personales de la UE no deben enrutarse a un proveedor estadounidense sin cobertura legal explícita. Enviará felizmente los datos médicos de un cliente francés a un endpoint que te expone a la jurisdicción de la Ley CLOUD.
3. Sin pista de auditoría a nivel de inferencia
LiteLLM registra mediante callbacks: puedes enviar datos a Langfuse, Helicone o S3. Eso es registro a nivel de aplicación. Una pista de auditoría empresarial registra la entrada exacta, la salida, la versión del modelo y la marca de tiempo en la capa de inferencia en un formato inmutable que un regulador puede verificar. Son cosas distintas.
4. Sin seguridad para agentes múltiples o MCP
A medida que tu despliegue de LiteLLM evoluciona de prompts simples a flujos de trabajo agénticos (cadenas de llamadas a herramientas, acceso a memoria, comunicación orquestador-subagente) los guardrails nativos solo ven la llamada API más externa. Lo que ocurre dentro de la cadena es invisible para ellos.
5. Sin pruebas adversariales previas al despliegue
Puedes configurar guardrails para los patrones que conoces. No puedes conocer lo que no conoces. OWASP LLM Top 10 lista diez categorías de ataque. Los guardrails nativos cubren parcialmente algunas de ellas. El resto requieren red teaming deliberado.
6. Sin documentación de cumplimiento
DORA, HIPAA, Reglamento UE de IA: todos requieren evidencia documentada de que tu sistema de IA tiene controles en vigor. LiteLLM genera registros. No genera los artefactos de auditoría que un equipo de cumplimiento puede presentar ante un regulador.
Añadir NeuralTrust TrustGuard como Guardrail Personalizado de LiteLLM
TrustGuard se integra con LiteLLM como clase de guardrail personalizado. Todas las aplicaciones que ya apuntan al proxy quedan cubiertas sin ningún cambio en el código del cliente: añades un fichero Python y unas pocas líneas a tu config.yaml.
El guardrail llama al endpoint /v1/evaluate de TrustGuard sobre la entrada antes de la llamada al modelo y sobre la respuesta antes de que llegue al usuario. TrustGuard devuelve un veredicto (allow, block o transform) y el guardrail lo aplica.
Paso 1: Crear la clase guardrail
Crea un fichero llamado trustguard_guardrail.py junto a tu config.yaml. Usa el cliente httpx que viene incluido en LiteLLM, por lo que la imagen del proxy no necesita ninguna dependencia adicional:
Paso 2: Declararlo en config.yaml
Establece TRUSTGUARD_API_BASE en {url-de-tu-workspace}/v1/evaluate e inyecta TRUSTGUARD_API_KEY desde tu gestor de secretos. El fichero trustguard_guardrail.py debe estar junto a config.yaml en el directorio desde el que se ejecuta el proxy.
Paso 3: Elegir fail-open o fail-closed
fail_open decide qué ocurre cuando TrustGuard no es accesible: un timeout, un fallo de DNS o un error.
fail_open: false (recomendado): el proxy devuelve un error 503 y la solicitud nunca llega al modelo. Los prompts permanecen dentro de tu perímetro.
fail_open: true : el tráfico fluye sin inspección y se registra un aviso. Úsalo solo si la disponibilidad es más importante que la inspección garantizada, y configura una alerta sobre la línea de log failing open (traffic NOT inspected).
Paso 4: Elegir el alcance de inspección
scope: current_turn inspecciona solo el mensaje de usuario más reciente más los resultados de herramientas desde entonces. Tamaño de payload constante; un ataque distribuido en varios turnos no es visible en una sola llamada.
scope: transcript inspecciona todos los mensajes en cada turno. Cobertura máxima, pero el payload crece con la conversación y una cadena marcada en el historial bloquea todas las solicitudes posteriores de esa sesión.
Paso 5: Verificar
Establece LITELLM_LOG=INFO primero y luego prueba:
Una configuración correcta registra dos líneas por solicitud: TrustGuard input -> status=allow y TrustGuard output -> status=allow. Un prompt bloqueado registra status=block en input, y ninguna línea de output, el modelo nunca es llamado.
Nota sobre streaming: Con
stream: true, el guardrail post-call se ejecuta sobre la respuesta ensamblada después de que los fragmentos ya han sido enviados. El bloqueo en el lado de la salida se convierte en detección a posteriori. La aplicación en el lado de la entrada no se ve afectada y sigue ejecutándose antes de llamar al modelo.
Consulta la guía de integración completa en docs.neuraltrust.ai/trustguard/integrations/litellm.
)
¿Y NeuralTrust TrustGate?
TrustGate es el gateway de IA de NeuralTrust, una alternativa completa a LiteLLM, no una capa que se sitúa frente a él. Ejecutar dos gateways en serie añade latencia y complejidad operativa sin ningún beneficio.
Si ya usas LiteLLM y quieres añadir seguridad empresarial: usa TrustGuard como guardrail personalizado (esta guía).
Si estás evaluando gateways de IA y quieres seguridad nativa integrada desde el inicio: evalúa TrustGate como tu gateway.
Artículo relacionado: NeuralTrust vs. LiteLLM: Comparación de Gateways de IA 2026
LiteLLM con TrustGuard vs LiteLLM Solo
| Capacidad | LiteLLM Solo | LiteLLM + TrustGuard |
|---|---|---|
| Detección de inyección de prompts | Mediante proveedores del ecosistema (dependencias de API externas) | Análisis basado en intención mediante la API de evaluación de TrustGuard |
| Enmascaramiento de PII | Mediante proveedores del ecosistema (dependencias de servidor externo) | Reglas de transformación DLP integradas, sin infraestructura adicional |
| Aplicación de políticas de contenido | Mediante proveedores del ecosistema | Motor de políticas semántico con veredictos allow, block, transform |
| Enrutamiento por jurisdicción | No admitido | Enruta por clasificación de datos y jurisdicción legal |
| Pista de auditoría a nivel de inferencia | Registros de aplicación basados en callbacks | Registros de inferencia inmutables por solicitud con trace ID |
| Seguridad para agentes múltiples y MCP | Solo llamada API más externa | Visibilidad completa de la cadena mediante TrustLens |
| Pruebas adversariales previas al despliegue | No admitido | TrustTest cubre OWASP LLM Top 10 |
| Documentación de cumplimiento | No incluida | Artefactos de auditoría DORA, Reglamento UE de IA, HIPAA |
| Control de guardrail por equipo, por clave | Sí (nativo de LiteLLM) | Sí, más controles de clasificación de datos |
| Cambios requeridos en el código de la aplicación | N/A | Ninguno, integración a nivel de proxy |
Qué Significa Esto en la Práctica
LiteLLM gestiona el problema del enrutamiento. TrustGuard gestiona el problema de la seguridad. Los dos funcionan en capas distintas y están diseñados para trabajar juntos.
TrustGuard añade aplicación en tiempo de ejecución en cada solicitud: evaluación de la entrada antes de la llamada al modelo, evaluación de la salida antes de que la respuesta llegue al usuario, registros de auditoría inmutables para cada interacción y detección de anomalías en patrones de acceso inusuales. TrustLens mapea cada punto de contacto de IA en tu entorno. TrustTest ejecuta ejercicios adversariales antes de que salgas a producción.
La combinación cubre ambas mitades de lo que requiere la infraestructura de IA empresarial: un enrutamiento que funciona y una seguridad que puedes demostrar.
Descubre cómo NeuralTrust securiza despliegues LiteLLM
FAQs acerca de añadir guardrails a LiteLLM y securizarlo para empresas
1. ¿Cómo añado guardrails a LiteLLM?
Añade una sección guardrails a tu config.yaml de LiteLLM. Cada entrada necesita un guardrail_name, un bloque litellm_params que especifique el proveedor de guardrail y un mode (pre_call, during_call o post_call). Establece default_on: true para aplicar el guardrail a todas las solicitudes. LiteLLM admite más de 40 proveedores de guardrails, incluyendo clases Python personalizadas para integraciones empresariales. La documentación completa está en docs.litellm.ai/docs/guardrail_providers.
2. ¿Qué cubre el ecosistema de guardrails de LiteLLM?
El ecosistema de guardrails de LiteLLM abarca más de 40 proveedores en cuatro áreas de capacidad principales: detección de inyección de prompts, enmascaramiento de PII y PHI, aplicación de políticas de contenido y detección de secretos. Los guardrails se ejecutan sobre la entrada antes de la llamada al modelo (pre_call), en paralelo durante la llamada (during_call) o sobre la respuesta después de que el modelo responde (post_call). Cada guardrail es una llamada API externa, por lo que la garantía de seguridad empresarial depende enteramente de la fiabilidad y cobertura del proveedor que elijas.
3. ¿Qué brechas de seguridad deja LiteLLM en despliegues empresariales?
El ecosistema de guardrails de LiteLLM no proporciona aplicación de políticas basada en intención (solo coincidencia de patrones de proveedores externos), enrutamiento por jurisdicción, pistas de auditoría a nivel de inferencia en formatos listos para el cumplimiento, seguridad de flujos de trabajo de agentes múltiples ni pruebas adversariales previas al despliegue. Para organizaciones sujetas a DORA, HIPAA, el Reglamento UE de IA o FedRAMP, estas brechas deben cerrarse mediante una capa de seguridad integrada como NeuralTrust TrustGuard.
4. ¿Cómo se integra NeuralTrust TrustGuard con LiteLLM?
TrustGuard se integra con LiteLLM como clase de guardrail personalizado. Creas un fichero trustguard_guardrail.py junto a tu config.yaml, lo declaras en la sección guardrails y estableces dos variables de entorno: TRUSTGUARD_API_BASE (apuntando a /v1/evaluate en la URL de tu workspace de TrustGuard) y TRUSTGUARD_API_KEY. El guardrail se ejecuta en pre_call y post_call en cada solicitud. No se requieren cambios en el código de tu aplicación. Las instrucciones completas están en docs.neuraltrust.ai/trustguard/integrations/litellm.
5. ¿Cuál es la diferencia entre fail-open y fail-closed en TrustGuard?
fail_open: false (fail-closed) significa que si TrustGuard no es accesible, el proxy devuelve un error 503 y la solicitud nunca llega al modelo, los prompts permanecen dentro de tu perímetro. fail_open: true significa que si TrustGuard no es accesible, el tráfico fluye sin inspección y se registra un aviso. Fail-closed es el valor predeterminado recomendado para cualquier despliegue donde la seguridad sea un requisito estricto. Si usas fail-open por razones de disponibilidad, configura una alerta sobre la línea de log failing open (traffic NOT inspected) para que una interrupción no pase desapercibida.
Sobre el Autor
Roger Howroyd es Head of Global SEO and AI en NeuralTrust, donde lidera la estrategia de búsqueda de la empresa en SEO, AEO, GEO y optimización LLM. Está especializado en búsqueda potenciada por IA, estrategia de contenido, desarrollo de backlinks y SEM. Conéctate en LinkedIn.
NeuralTrust es una plataforma de seguridad para agentes de IA, reconocida en el Gartner Hype Cycle for Application Security 2026, el Gartner Hype Cycle for Infrastructure Security 2026, la Guía de mercado de Gartner 2025 para AI Gateways y Agentes Guardianes y el Compás de liderazgo KuppingerCole 2025 para Defensa de IA Generativa. Certificada ISO 27001. Con sede en Barcelona.
)