La seguridad de LLM ya no consiste solo en bloquear prompts inseguros. Cuando un LLM se convierte en parte de un flujo de trabajo agéntico, puede recuperar documentos, llamar a APIs, actualizar registros o activar procesos de negocio. Eso cambia el modelo de seguridad de “proteger el chat” a “proteger el sistema de acciones alrededor del modelo”.
Si su equipo está planificando una IA agéntica en producción más amplia, la seguridad de LLM debe tratarse como una puerta de lanzamiento, no como una lista de verificación final. Para equipos de la UE/EE. UU., eso significa pensar en la inyección de prompts, el acceso seguro a herramientas, la residencia de datos, la auditabilidad, la supervisión humana, las pruebas y el monitoreo de producción antes del lanzamiento.
El riesgo ya no es teórico. El AI Index 2025 de Stanford HAI reportó 233 incidentes relacionados con IA en 2024, un máximo histórico y un aumento del 56,4% respecto a 2023. El Informe del costo de una brecha de datos 2025 de IBM también encontró que el 13% de las organizaciones reportaron brechas que involucraban modelos o aplicaciones de IA; entre las comprometidas, el 97% carecía de controles adecuados de acceso a IA.
Esta guía desglosa los controles prácticos que los equipos necesitan para lanzar agentes impulsados por LLM de forma segura.
Puntos clave
- La seguridad de LLM cubre prompts, herramientas, datos, registros, personas, proveedores y monitoreo.
- La IA agéntica aumenta el riesgo de seguridad porque puede tomar acciones, no solo generar texto.
- La inyección de prompts necesita defensas por capas, no solo un prompt de sistema más fuerte.
- Las llamadas seguras a herramientas dependen del mínimo privilegio, la validación, el sandboxing y los registros de auditoría.
- La residencia de datos debe diseñarse dentro de la arquitectura para despliegues en la UE/EE. UU.
- Los controles HITL deben basarse en el riesgo, ser auditables y realistas desde el punto de vista operativo.
- Las pruebas y el monitoreo deben continuar después del lanzamiento en producción.
Qué significa la seguridad de LLM para la IA agéntica
La seguridad de LLM es más amplia que la seguridad de los prompts
La seguridad de LLM es la práctica de proteger los sistemas impulsados por LLM contra la fuga de datos, la inyección de prompts, el uso no autorizado de herramientas, las salidas inseguras y los fallos de cumplimiento.
Para un chatbot sencillo, la seguridad puede centrarse principalmente en prompts, salidas y datos de usuario. Para un sistema de IA agéntica, el alcance es más amplio. El sistema puede incluir:
- Un modelo o varios modelos
- Prompts de sistema y políticas
- Pipelines RAG y bases de datos vectoriales
- APIs y herramientas de negocio
- Memoria o contexto de sesión
- Registros y sistemas de monitoreo
- Flujos de trabajo de aprobación humana
- Proveedores externos de modelos o infraestructura
Una aplicación LLM segura no es solo un prompt seguro. Es una arquitectura segura alrededor del modelo.
Por qué los sistemas agénticos elevan el nivel de riesgo
La IA agéntica cambia el perfil de riesgo porque el modelo puede influir en acciones. En lugar de solo responder una pregunta, un agente puede:
- Buscar documentos internos
- Llamar a una API de CRM
- Actualizar un ticket
- Activar un correo electrónico
- Generar código
- Analizar registros de clientes
- Pasar datos entre herramientas
- Recomendar o ejecutar pasos de un flujo de trabajo
Eso significa que una mala instrucción, un resultado de recuperación inseguro, un permiso excesivo o una capa de validación débil pueden crear un impacto operativo real. El modo de fallo ya no es solo “la respuesta fue incorrecta”. Puede convertirse en “se tomó la acción equivocada”.
Objetivos de seguridad para agentes LLM en producción
Para agentes LLM en producción, los objetivos de seguridad deben ser explícitos. Como mínimo, los equipos deben apuntar a:
- Prevenir el acceso no autorizado a datos
- Prevenir la fuga de datos sensibles
- Prevenir el uso inseguro o no autorizado de herramientas
- Mantener registros de auditoría para acciones importantes
- Aplicar aprobación humana a flujos de trabajo de alto riesgo
- Detectar comportamientos anómalos de forma temprana
- Respaldar la respuesta a incidentes y la reversión
- Mantener trazables los cambios de modelos, prompts y herramientas
Estos objetivos ayudan a los equipos de seguridad, producto e ingeniería a evaluar si un agente está listo para producción.
Modelo de amenazas: dónde fallan los agentes LLM en producción
El modelado de amenazas brinda a los equipos una forma práctica de entender cómo puede fallar un agente LLM antes de que esas fallas afecten a clientes, empleados o datos regulados.
El informe 2025 de IBM encontró que el 60% de los incidentes de seguridad relacionados con IA condujeron a datos comprometidos y el 31% causó interrupción operativa. Para la IA agéntica, esos números importan porque un agente comprometido puede afectar tanto la exposición de información como la continuidad de procesos de negocio.
Riesgos de confidencialidad
Los riesgos de confidencialidad ocurren cuando información sensible queda expuesta al usuario, herramienta, proveedor, registro o sistema posterior equivocado.
Los ejemplos comunes incluyen:
- PII incluida innecesariamente en prompts
- Secretos o credenciales que aparecen en registros
- Recuperación RAG que expone documentos a los que un usuario no debería acceder
- Salidas del modelo que revelan instrucciones ocultas del sistema
- Configuraciones de proveedores que retienen prompts sensibles durante más tiempo del esperado
- Datos internos enviados a servicios externos sin aprobación clara
El control práctico comienza con la clasificación de datos. Los equipos necesitan saber a qué datos puede acceder el agente, dónde se procesan esos datos y quién puede ver la salida.
Riesgos de integridad
Los riesgos de integridad ocurren cuando el comportamiento, el razonamiento o las acciones del agente son manipulados.
En los sistemas LLM, el riesgo de integridad suele aparecer como inyección de prompts. En los sistemas agénticos, puede ir más allá:
- Un documento malicioso le dice al agente que ignore instrucciones previas.
- Una respuesta de herramienta contiene texto que el modelo trata como un nuevo comando.
- Un usuario engaña al agente para que llame a una función no autorizada.
- El agente modifica un registro basándose en información no verificada.
- Un resultado RAG cambia la ruta de decisión del agente.
Los controles de integridad deben centrarse en separar las instrucciones confiables del contenido no confiable, validar las llamadas a herramientas y aplicar comprobaciones de políticas antes de acciones sensibles.
Riesgos de disponibilidad y costos
Los agentes LLM también pueden crear problemas de disponibilidad y costos. Por ejemplo:
- Un agente entra en un bucle repetido.
- Las llamadas a herramientas aumentan inesperadamente.
- El uso de tokens crece más allá del presupuesto.
- Una interrupción del modelo o proveedor rompe un flujo de trabajo.
- Una entrada malformada causa reintentos repetidos.
- Un paso de alta latencia bloquea un proceso de negocio.
A esto a veces se le llama “denegación de cartera” cuando el uso excesivo del modelo crea costos inesperados. Los agentes de producción necesitan límites de tasa, tiempos de espera, límites de reintentos, controles presupuestarios y alertas.
Riesgos de cumplimiento
Para despliegues en la UE/EE. UU., el riesgo de cumplimiento suele provenir de un manejo de datos poco claro y una gobernanza débil.
Los ejemplos incluyen:
- Sin flujo de datos documentado
- Región de procesamiento poco clara
- Configuraciones de retención débiles para prompts y registros
- Sin rastro de auditoría para acciones de alto riesgo
- Sin supervisión humana para flujos de trabajo sensibles
- Sin revisión de proveedores/subprocesadores
- Sin plan de respuesta a incidentes para fallos relacionados con IA
Los equipos de seguridad y cumplimiento deben revisar estos riesgos antes del lanzamiento, no después de que el agente ya esté integrado en flujos de trabajo de negocio.
Controles de inyección de prompts e inyección indirecta
Inyección directa de prompts
La inyección directa de prompts ocurre cuando un usuario intenta manipular intencionalmente las instrucciones del modelo. El usuario puede pedir al modelo que ignore reglas del sistema, revele contexto oculto, eluda políticas o realice acciones fuera de su alcance permitido.
Para un chatbot básico, la inyección directa puede dar como resultado una respuesta insegura o incorrecta. Para un agente de IA, puede llevar al uso indebido de herramientas, exposición de datos o ejecución no autorizada de flujos de trabajo.
OWASP enumera Prompt Injection como un riesgo principal de aplicaciones LLM en su OWASP Top 10 for LLM Applications. Por eso las pruebas de inyección deben formar parte del proceso de lanzamiento para cualquier flujo de trabajo LLM que maneje datos sensibles o acciones de negocio.
Inyección indirecta de prompts
La inyección indirecta de prompts ocurre cuando instrucciones maliciosas están ocultas dentro del contenido que lee el agente. Este contenido puede provenir de:
- Páginas web
- Correos electrónicos
- Archivos cargados
- PDFs
- Tickets
- Transcripciones de chat
- Resultados RAG
- Respuestas de herramientas
- Documentos compartidos
Esto es especialmente importante para la IA agéntica porque los agentes suelen consumir contenido externo o semiconfiable antes de decidir qué hacer a continuación.
Por qué la inyección indirecta es peligrosa para los agentes
La inyección indirecta es peligrosa porque la instrucción maliciosa no proviene directamente del usuario. Aparece dentro de datos que se pidió al agente procesar.
Por ejemplo, un agente puede leer un ticket de soporte que incluye instrucciones ocultas que le indican divulgar una política interna, cambiar un campo de prioridad o llamar a otra herramienta. Si el sistema trata el contenido recuperado como una instrucción confiable, el agente puede seguirla.
El principio central es simple: el contenido externo debe tratarse como datos, no como autoridad.
Controles defensivos
La mitigación de la inyección de prompts debe usar controles por capas:
- Separar las instrucciones del sistema del contenido de usuarios y herramientas.
- Tratar los documentos recuperados como datos no confiables.
- Usar listas de herramientas permitidas en lugar de acceso abierto a herramientas.
- Validar los argumentos de herramientas del lado del servidor.
- Exigir salidas estructuradas para llamadas a herramientas.
- Añadir comprobaciones de políticas antes de acciones sensibles.
- Limitar los permisos del agente por rol y flujo de trabajo.
- Sanitizar o aislar el contenido externo antes de usarlo.
- Añadir puertas de aprobación para acciones de alto impacto.
- Monitorear patrones de prompts sospechosos e intentos bloqueados.
Ningún control único es suficiente. Un prompt de sistema fuerte ayuda, pero no debe ser el único límite de seguridad.
En qué no se debe confiar por sí solo
Los equipos deben evitar depender solo de:
- Un prompt de sistema genérico de “no rompas las reglas”
- Filtros de palabras clave
- Revisión manual sin registros
- Una única configuración de seguridad del modelo
- Confiar en todo el contenido RAG
- Dar al agente permisos amplios de API
- Asumir que los usuarios no intentarán entradas adversariales
La seguridad de LLM debe asumir que los prompts, el contenido recuperado y las salidas de herramientas pueden ser manipulados.
Llamadas seguras a herramientas y acceso de mínimo privilegio
Por qué las llamadas a herramientas cambian el modelo de seguridad
Las llamadas a herramientas son una de las mayores diferencias entre un chatbot LLM normal y un sistema de IA agéntica.
Un chatbot produce texto. Un agente con herramientas puede crear efectos secundarios. Puede buscar en una base de datos, enviar un correo electrónico, actualizar un campo de CRM, crear un ticket de soporte, ejecutar un script o activar un flujo de trabajo interno.
Eso significa que la salida del modelo se convierte en una posible acción del sistema. Los controles de seguridad deben proteger la capa de acción, no solo la capa de texto.
Riesgos comunes de llamadas a herramientas en producción
Los riesgos comunes incluyen:
- El agente llama a una herramienta a la que no debería acceder.
- El agente envía datos sensibles a la herramienta equivocada.
- El agente usa herramientas correctas con argumentos inseguros.
- El agente repite llamadas a herramientas y crea problemas de costos o disponibilidad.
- Una respuesta de herramienta contiene instrucciones maliciosas.
- Una herramienta tiene permisos más amplios de los que requiere el flujo de trabajo.
- Los secretos se exponen al modelo a través de prompts o salidas de herramientas.
- Una acción de herramienta no puede rastrearse hasta un usuario, agente o aprobación.
OWASP también destaca Excessive Agency como un riesgo importante de aplicaciones LLM, especialmente para sistemas que pueden llamar a herramientas o interactuar con sistemas externos. El problema suele estar arraigado en funcionalidad excesiva, permisos excesivos o autonomía excesiva. Eso se corresponde directamente con agentes de producción con amplio acceso a herramientas.
Acceso de mínimo privilegio para agentes LLM
El mínimo privilegio significa que el agente solo debe tener los permisos que necesita para una tarea específica.
Por ejemplo, un agente que redacta respuestas de soporte al cliente puede necesitar acceso de lectura al historial de tickets, pero tal vez no necesite permiso para emitir reembolsos, eliminar cuentas o cambiar registros de facturación. Si una acción es de alto riesgo, el agente debe redactarla o recomendarla, mientras una persona la aprueba.
Un modelo práctico de mínimo privilegio debe definir:
- Qué herramientas puede usar el agente
- Qué operaciones están permitidas
- Qué alcances de datos están permitidos
- Qué usuarios o roles pueden activar el flujo de trabajo
- Qué acciones requieren aprobación
- Qué acciones están bloqueadas por completo
Cada agente debe tener su propia identidad de servicio cuando sea posible. Evite dar a un agente acceso amplio mediante una credencial de administrador compartida.
Listas de herramientas permitidas, alcances y comprobaciones de políticas
Los agentes de producción no deben elegir entre herramientas ilimitadas. El acceso a herramientas debe estar permitido por lista y limitado por alcance.
Los controles útiles incluyen:
- Listas de herramientas permitidas por tipo de agente
- Alcances de API por flujo de trabajo
- Límites de tasa por herramienta
- Comprobaciones de políticas antes de la ejecución
- Separación de entornos entre desarrollo, staging y producción
- Comprobaciones de aprobación para operaciones sensibles
- Comportamiento de denegación por defecto cuando el contexto no está claro
Una capa de políticas puede decidir si una llamada a herramienta está permitida antes de que ocurra la acción. Esto es especialmente útil para acciones que involucran datos de clientes, impacto financiero, impacto legal, impacto de seguridad o comunicación externa.
Validación de argumentos y validación de salidas
Las llamadas a herramientas deben usar esquemas estructurados. El agente no debe pasar argumentos arbitrarios de formato libre a APIs sensibles.
Por ejemplo:
- Los IDs deben coincidir con formatos esperados.
- Los importes deben estar dentro de límites aprobados.
- Los destinatarios de correo electrónico deben coincidir con dominios permitidos o contactos verificados.
- Las rutas de archivo deben permanecer dentro de ubicaciones permitidas.
- Las llamadas a herramientas deben fallar de forma cerrada cuando faltan campos requeridos.
Las salidas de herramientas también deben tratarse con cuidado. Una respuesta de herramienta puede contener texto no confiable, datos malformados o instrucciones inyectadas. El modelo debe usar la salida de la herramienta como datos, no como una nueva fuente de autoridad.
Sandboxing de herramientas de alto riesgo
Algunas herramientas necesitan aislamiento. Los ejemplos incluyen:
- Ejecución de código
- Navegación web
- Procesamiento de archivos
- Ingesta de documentos
- Transformación de datos
- Automatización de flujos de trabajo con efectos secundarios externos
El sandboxing ayuda a limitar el daño si el agente se comporta de manera inesperada. Según el caso de uso, el sandboxing puede incluir restricciones de red, límites del sistema de archivos, tiempos de espera de ejecución, límites de memoria, credenciales separadas y entornos restringidos.
Gestión de secretos para flujos de trabajo de agentes
Los secretos no deben colocarse en prompts, contexto del modelo ni registros de texto plano. Los agentes deben acceder a secretos solo a través de servicios backend seguros.
Las buenas prácticas incluyen:
- Almacenar secretos en un gestor de secretos.
- Mantener credenciales fuera de las plantillas de prompts.
- Censurar secretos en los registros.
- Rotar credenciales con regularidad.
- Usar tokens de corta duración cuando sea posible.
- Separar credenciales por entorno.
- Evitar exponer claves API sin procesar a salidas del modelo o respuestas de herramientas.
El modelo debe solicitar una acción, pero el backend debe hacer cumplir la autorización y realizar la operación segura.
Registro de auditoría para llamadas a herramientas
Cada llamada importante a herramientas debe registrarse. Los registros deben ayudar a responder:
- ¿Qué usuario activó el flujo de trabajo?
- ¿Qué agente tomó la decisión?
- ¿Qué herramienta fue llamada?
- ¿Qué acción se solicitó?
- ¿La acción fue aprobada?
- ¿Cuál fue el resultado?
- ¿Hubo datos sensibles involucrados?
- ¿La acción fue bloqueada, reintentada o revertida?
Para entornos empresariales de la UE/EE. UU., la auditabilidad suele ser tan importante como la prevención. Si algo sale mal, la organización necesita reconstruir lo ocurrido.
Residencia de datos y privacidad para despliegues en la UE/EE. UU.
Comience con un mapa de datos
La residencia de datos comienza con comprender el flujo de datos. Antes de elegir un proveedor de modelos o una arquitectura, los equipos deben mapear:
- Qué datos entran en el prompt
- Qué datos se recuperan de sistemas internos
- Qué datos se envían a proveedores de modelos
- Qué datos se incorporan en una base de datos vectorial
- Qué datos se registran
- Cuánto tiempo se retienen los datos
- Qué región procesa o almacena cada componente
- Qué proveedores o subprocesadores participan
Sin un mapa de datos, las revisiones de seguridad y cumplimiento se convierten en conjeturas.
IBM también reportó que el 63% de las organizaciones que sufrieron brechas carecían de una política de gobernanza de IA o aún la estaban desarrollando. Para despliegues en la UE/EE. UU., esa brecha de gobernanza suele aparecer como flujos de datos poco claros, decisiones de retención débiles, revisión incompleta de proveedores o controles faltantes alrededor de la IA en la sombra.
Consideraciones para la UE
Para despliegues en la UE, los equipos comúnmente necesitan considerar principios de privacidad como minimización de datos, limitación de propósito, control de acceso, retención y revisión de transferencias transfronterizas. Las obligaciones específicas dependen de la organización, el caso de uso, el tipo de datos y la base legal.
Las preguntas prácticas de arquitectura incluyen:
- ¿Se pueden minimizar los datos sensibles antes de construir el prompt?
- ¿Se puede fijar la inferencia a una región?
- ¿Los registros se almacenan en la región correcta?
- ¿Los embeddings se consideran sensibles en este caso de uso?
- ¿Se pueden excluir los datos de clientes del entrenamiento del proveedor?
- ¿Las configuraciones de eliminación y retención son configurables?
La interpretación legal debe ser revisada por asesores calificados antes de decisiones de publicación o implementación.
Consideraciones para EE. UU.
Los despliegues en EE. UU. pueden involucrar expectativas específicas del sector según la industria. Los entornos de salud, finanzas, educación, sector público y SaaS empresarial suelen tener expectativas más estrictas en torno a controles de acceso, registros de auditoría, retención y gestión de riesgos de proveedores.
Incluso cuando una regulación no menciona explícitamente los LLM, los compradores pueden esperar controles de seguridad alineados con marcos empresariales como SOC 2 o ISO/IEC 27001.
Patrones de arquitectura para sistemas LLM sensibles a la residencia
Los patrones comunes incluyen:
- Endpoints de modelo específicos por región
- Almacenes vectoriales específicos por región
- Redes privadas donde estén disponibles
- Claves de cifrado gestionadas por el cliente
- Enmascaramiento de datos antes de llamadas al modelo
- Detección de PII antes de construir prompts
- Entornos separados para la UE y EE. UU.
- Ventanas de retención cortas para prompts y salidas
- Niveles de registro que separan metadatos operativos de contenido sensible
- Controles de acceso sobre embeddings y documentos recuperados
El objetivo es reducir el movimiento innecesario de datos y hacer que el movimiento inevitable de datos sea visible, controlado y documentado.
Lista de verificación de debida diligencia de proveedores
Antes de usar un proveedor de LLM o un proveedor de infraestructura de IA, los equipos deben preguntar:
- ¿Dónde se procesan los datos?
- ¿Dónde se almacenan los datos?
- ¿Los datos de clientes se usan para entrenamiento?
- ¿Qué controles de retención están disponibles?
- ¿Qué subprocesadores participan?
- ¿Se admiten controles de seguridad empresariales?
- ¿Hay registros de auditoría disponibles?
- ¿Se pueden eliminar datos bajo solicitud?
- ¿Hay opciones de red privada o fijadas a región disponibles?
- ¿Qué ocurre durante la respuesta a incidentes?
Las configuraciones de proveedores pueden cambiar materialmente la postura de seguridad de un sistema LLM. Deben revisarse antes del uso en producción.
Controles HITL: supervisión humana sin matar la velocidad
HITL debe basarse en el riesgo
Human-in-the-loop no significa que cada acción del agente necesite aprobación manual. Eso haría que la mayoría de los flujos de trabajo fueran demasiado lentos. Tampoco significa que cada acción deba automatizarse.
El enfoque correcto se basa en el riesgo. Las acciones de bajo riesgo pueden registrarse y monitorearse. Las acciones de riesgo medio pueden necesitar muestreo, comprobaciones basadas en reglas o aprobación bajo ciertas condiciones. Las acciones de alto riesgo deben requerir revisión humana explícita.
Niveles de riesgo sugeridos
| Nivel de riesgo | Ejemplo de acción del agente | Control sugerido |
|---|---|---|
| Bajo | Redactar un resumen interno | Solo registro |
| Medio | Actualizar un campo de CRM no crítico | Validación basada en reglas o revisión muestreada |
| Alto | Enviar un mensaje de cara al cliente | Aprobación humana requerida |
| Crítico | Pagos, eliminación de cuentas, acciones con impacto legal/de seguridad | Aprobación humana más control secundario |
Esta estructura permite a los equipos preservar la velocidad mientras siguen controlando las decisiones de alto impacto.
Controles que hacen que HITL esté listo para auditoría
Un flujo de trabajo HITL útil debe capturar:
- Identidad del revisor
- Decisión de aprobación o rechazo
- Motivo de la decisión
- Recomendación original del agente
- Acción final tomada
- Estado antes/después cuando sea relevante
- Marca de tiempo
- Ruta de escalamiento
- Opción de reversión
Sin estos registros, HITL puede ayudar operativamente, pero no respaldar una auditoría o revisión de incidentes.
Cuándo añadir un interruptor de emergencia
Un interruptor de emergencia permite a los equipos detener un agente o deshabilitar rápidamente acciones específicas de herramientas.
Los equipos deben considerar interruptores de emergencia para casos como:
- Volumen inesperado de llamadas a herramientas
- Fallos de validación repetidos
- Intentos de inyección sospechosos
- Exposición de datos sensibles
- Picos de costos
- Interrupción de modelo/proveedor
- Decisiones repetidas de baja confianza
- Quejas de usuarios anómalas o escalaciones de soporte
Un interruptor de emergencia debe probarse antes del lanzamiento. No debe existir solo como un control teórico.
Pruebas y monitoreo de agentes LLM antes de producción
El QA tradicional no es suficiente
El QA tradicional asume un comportamiento mayormente determinista. Los agentes LLM son diferentes. Sus salidas pueden variar, sus rutas de razonamiento pueden cambiar y sus acciones pueden depender de datos recuperados, respuestas de herramientas, contexto de usuario y configuraciones del modelo.
Eso significa que las pruebas de agentes deben incluir evaluación funcional y de seguridad. Un flujo de trabajo puede pasar una prueba de caso feliz y aun así fallar con entradas adversariales, documentos inusuales, respuestas de herramientas malformadas o casos de límites de permisos.
Tipos de pruebas principales
Un plan de pruebas listo para producción debe incluir:
- Pruebas de éxito de tareas
- Pruebas de inyección de prompts
- Pruebas de inyección indirecta
- Pruebas de permisos de herramientas
- Pruebas de validación de argumentos de herramientas
- Pruebas de fuga de datos
- Pruebas de acceso a recuperación RAG
- Pruebas de flujos de trabajo HITL
- Pruebas de regresión
- Pruebas de costos y latencia
- Pruebas de modos de fallo
- Pruebas de reversión e interruptor de emergencia
Las pruebas de seguridad deben incluir flujos de trabajo de negocio realistas, no solo prompts artificiales.
Construya un arnés de evaluación
Un arnés de evaluación ayuda a los equipos a probar agentes de manera consistente antes del lanzamiento. Debe incluir:
- Un conjunto versionado de casos de prueba
- Resultados esperados o criterios de puntuación
- Ejemplos adversariales
- Tareas de usuario realistas
- Escenarios de uso de herramientas
- Comprobaciones de violaciones de políticas
- Seguimiento de regresión en cambios de modelos o prompts
- Informes que puedan ser revisados por equipos de ingeniería, seguridad y producto
El arnés debe ejecutarse antes de lanzamientos importantes y siempre que cambien prompts, herramientas, modelos, lógica de recuperación o reglas de políticas.
Señales de monitoreo que se deben definir antes del lanzamiento
El monitoreo debe diseñarse antes de que el agente entre en funcionamiento. Las señales útiles incluyen:
- Frecuencia de llamadas a herramientas
- Validaciones fallidas
- Acciones bloqueadas
- Tasas de aprobación y rechazo HITL
- Reintentos repetidos
- Anomalías de tokens y costos
- Picos de latencia
- Detecciones de datos sensibles
- Patrones de prompts sospechosos
- Acceso inesperado a datos
- Quejas de usuarios
- Intentos de violación de políticas
Estas señales deben alimentar alertas, paneles y flujos de trabajo de respuesta a incidentes.
Monitoreo de producción después del lanzamiento
Las pruebas no terminan en el lanzamiento. Los agentes LLM pueden desviarse a medida que cambian los datos, las herramientas, los prompts, los modelos y el comportamiento de los usuarios.
Esta visión del ciclo de vida se alinea con el NIST AI Risk Management Framework, que organiza el trabajo de riesgo de IA en torno a gobernar, mapear, medir y gestionar. Para agentes LLM, eso significa que los equipos deben mapear riesgos antes del despliegue, medir el comportamiento mediante evaluaciones y monitoreo, y gestionar fallos mediante alertas, rutas de reversión y respuesta a incidentes.
Después del lanzamiento, los equipos deben revisar:
- Si el agente sigue cumpliendo los objetivos de éxito de tareas
- Si los bloqueos de seguridad están aumentando
- Si los revisores HITL están anulando al agente con frecuencia
- Si los patrones de costos son estables
- Si los usuarios están descubriendo nuevos modos de fallo
- Si algún cambio de modelo o proveedor afecta el comportamiento
El monitoreo de producción convierte la seguridad de LLM de una lista de verificación única en una práctica operativa continua.
Lista de verificación de seguridad de LLM para lanzar con seguridad
Controles de arquitectura
Antes del lanzamiento, confirme:
- Los flujos de datos están mapeados.
- Las clases de datos sensibles están identificadas.
- Los permisos de herramientas están documentados.
- Los controles de acceso RAG están probados.
- Las configuraciones de modelos y proveedores están revisadas.
- Las configuraciones de región y retención están confirmadas.
- Los secretos se mantienen fuera de prompts y registros.
- Los entornos están separados.
Controles de seguridad
Confirme:
- Las defensas contra inyección de prompts están probadas.
- Los casos de inyección indirecta están incluidos en la evaluación.
- Las listas de herramientas permitidas se hacen cumplir.
- Los argumentos de herramientas se validan del lado del servidor.
- Las salidas de herramientas se tratan como datos no confiables.
- Se aplica acceso de mínimo privilegio.
- Las acciones de alto riesgo tienen puertas de control.
- Los registros de auditoría están habilitados.
- Los límites de tasa y tiempos de espera están configurados.
Controles de cumplimiento
Confirme:
- La retención de datos está documentada.
- La revisión de proveedores/subprocesadores está completada.
- La política de supervisión humana está definida.
- Los flujos de trabajo de alto riesgo son auditables.
- Los controles de acceso se basan en roles.
- Los pasos de respuesta a incidentes están documentados.
- Se comprenden los procesos de eliminación y acceso a datos.
- Los equipos legales y de cumplimiento han revisado los requisitos relevantes.
Controles de lanzamiento
Confirme:
- La suite de evaluación ha pasado.
- Las pruebas de regresión están completas.
- Los casos de prueba de seguridad están revisados.
- Las alertas de monitoreo están configuradas.
- La ruta de reversión está probada.
- El interruptor de emergencia está probado.
- Se asignó un propietario posterior al lanzamiento.
- La cadencia de revisión está programada.
Un lanzamiento seguro no es solo un hito técnico. Es un compromiso operativo.
Cómo HDWEBSOFT ayuda a los equipos a asegurar sistemas LLM y de IA agéntica
Lanzar agentes impulsados por LLM de forma segura requiere tanto ingeniería de IA como pensamiento de seguridad. Los equipos necesitan diseñar flujos de trabajo, integrar herramientas, proteger datos, probar comportamientos y monitorear sistemas de producción sin ralentizar innecesariamente la entrega.
HDWEBSOFT ayuda a los equipos a planificar, construir y asegurar sistemas de IA con soporte práctico de ingeniería. Si su organización se está preparando para un despliegue de LLM o IA agéntica, nuestro equipo puede apoyar el diseño de arquitectura, la implementación de flujos de trabajo de IA, la integración de herramientas, la revisión de seguridad y la preparación para producción.
Explore nuestros servicios de desarrollo de IA para implementación segura de IA y nuestros servicios de ciberseguridad para evaluación de seguridad, revisión de riesgos y controles de producción más sólidos.
Conclusión
La seguridad de LLM no es un prompt, una política ni una lista de verificación. Para la IA agéntica, debe cubrir todo el sistema: prompts, datos recuperados, herramientas, permisos, registros, aprobaciones humanas, pruebas y monitoreo de producción.
Los equipos que lancen con seguridad serán aquellos que traten la seguridad como parte de la arquitectura desde el inicio. Los controles de inyección de prompts, el acceso a herramientas de mínimo privilegio, la planificación de residencia de datos, los flujos de trabajo HITL y la evaluación continua trabajan juntos para reducir el riesgo.
Para entornos de producción en la UE/EE. UU., el objetivo no es solo hacer que el agente sea útil. El objetivo es hacerlo controlado, auditable, resiliente y suficientemente seguro para operar en flujos de trabajo de negocio reales.
FAQ
¿Qué es la seguridad de LLM?
La seguridad de LLM es la práctica de proteger los sistemas impulsados por LLM contra la inyección de prompts, la fuga de datos, el uso no autorizado de herramientas, las salidas inseguras y los fallos de cumplimiento. Para la IA agéntica, también incluye permisos de herramientas, registros de auditoría, flujos de trabajo HITL, pruebas y monitoreo.
¿Por qué la seguridad de LLM es más difícil para los agentes de IA?
La seguridad de LLM es más difícil para los agentes de IA porque los agentes pueden tomar acciones. Pueden recuperar documentos, llamar a APIs, actualizar sistemas o activar flujos de trabajo. Eso significa que la seguridad debe proteger no solo las salidas del modelo, sino también las herramientas y los datos conectados al agente.
¿Cómo se previene la inyección de prompts en agentes LLM?
La prevención de la inyección de prompts requiere controles por capas. Los equipos deben separar las instrucciones confiables del contenido no confiable, validar las llamadas a herramientas, aplicar acceso de mínimo privilegio, tratar el contenido recuperado como datos, añadir comprobaciones de políticas, monitorear patrones sospechosos y probar con casos adversariales.
¿Qué es la inyección indirecta de prompts?
La inyección indirecta de prompts ocurre cuando instrucciones maliciosas están ocultas dentro del contenido que lee el agente, como páginas web, correos electrónicos, documentos, tickets de soporte, PDFs o resultados RAG. El agente puede tratar ese contenido como una instrucción a menos que el sistema esté diseñado para aislarlo y validarlo.
¿Cómo se aseguran las llamadas a herramientas para agentes LLM?
Las llamadas seguras a herramientas requieren acceso de mínimo privilegio, APIs con alcance limitado, listas de herramientas permitidas, esquemas estructurados, validación de argumentos del lado del servidor, validación de salidas, límites de tasa, sandboxing para herramientas de alto riesgo, gestión de secretos y registros de auditoría para las acciones de herramientas.
¿Cómo afecta la residencia de datos a las aplicaciones LLM?
La residencia de datos afecta dónde se procesan y almacenan los prompts, los documentos recuperados, los embeddings, las salidas y los registros. Los despliegues en la UE/EE. UU. deben mapear los flujos de datos, revisar la configuración de proveedores, configurar la retención y elegir patrones de arquitectura que coincidan con los requisitos de privacidad y cumplimiento.
¿Qué deben probar los equipos antes de desplegar agentes LLM?
Los equipos deben probar el éxito de las tareas, la resistencia a la inyección de prompts, los escenarios de inyección indirecta, los permisos de herramientas, la fuga de datos, los controles de acceso RAG, los flujos de aprobación HITL, el comportamiento de regresión, las alertas de monitoreo, la latencia, el comportamiento de costos, las rutas de reversión y el comportamiento del interruptor de emergencia.
