Nota: este artículo ha sido reescrito y traducido al español con ayuda de IA. Si detectas expresiones poco claras, indícalas en los comentarios.
1. Introducción
Los ataques por inyección de prompts son un problema crítico a fecha de septiembre de 2025 y ya existen casos con impacto real. A medida que los agentes IA se generalizan, no es prudente avanzar sin una solución de base. La arquitectura multietapas que presentamos, o enfoques similares, puede acelerar la adopción segura de agentes IA por parte de la industria. Durante la redacción identificamos un método afín denominado CaMeL, que consideramos igualmente valioso como referencia.
El objetivo es impedir de forma estructural la manipulación del sistema y la destrucción de datos a través de inyección de prompts. No pretende mejorar la calidad de las respuestas, reducir alucinaciones ni optimizar la comprensión contextual; esas metas corresponden a la evolución natural de los modelos.
Por ello aceptamos como límite razonable las limitaciones de capacidad que no causan operaciones indebidas y consideramos inaceptables las acciones no intencionadas por el usuario, como envío de correos o llamadas a herramientas externas. Esta distinción permite centrarse en crear sistemas donde los ataques no deseados sean inviables, en lugar de perseguir la idea difusa de una IA segura en general. Además, al seguir un flujo de pensamiento similar al humano, la arquitectura es comprensible y permite aplicar directamente buenas prácticas empresariales para reducir errores.
2. Arquitectura de Procesamiento Multietapas
2.1 Mecanismo básico
La seguridad se logra separando el procesamiento en dos etapas.
Etapa 1 análisis de instrucciones Entrada de usuario -> Plan de ejecución específico ya confirmado. Etapa 2 ejecución Plan confirmado + datos externos -> Resultado final.
Con ello, las acciones ejecutables quedan decididas antes de ver datos externos, imposibilitando que estos alteren las instrucciones.
Ejemplo 1 caso claro
Entrada Email mi agenda de los últimos 7 días a Suzuki san
Resultado del análisis de instrucciones: externo Recuperar datos del calendario últimos 7 días. LLM Redactar el correo con los datos recuperados. externo Enviar el correo a Suzuki san. LLM Generar respuesta con el resultado. cliente Mostrar el resultado.
Aunque el calendario tenga contenido malicioso, las operaciones ya están fijadas en la Etapa 1. Las instrucciones maliciosas se tratan como datos a procesar y no afectan a las acciones del sistema. Puede haber errores en la redacción, pero la consecuencia sería solo un contenido extraño en el correo, sin alterar el flujo operativo.
Ejemplo 2 juicio más difícil
Entrada Qué opinas del contenido de esta URL
Resultado del análisis de instrucciones: externo Obtener datos de la URL. LLM Generar la respuesta. cliente Mostrar el resultado.
Aunque los datos incluyan instrucciones maliciosas, la única operación es mostrar el resultado.
2.2 Optimización con prompts dedicados
En la etapa de análisis conviene usar prompts diseñados como si generaran código, fijando el formato de salida. Al estar el formato definido, la validación se vuelve mecánica. Los LLM actuales superan con creces este nivel de complejidad.
Ventajas principales velocidad de procesamiento por diseño ligero, reducción de errores al especializar la tarea, depuración sencilla gracias a la visualización explícita del plan y mejora incremental al optimizar cada etapa de forma independiente.
2.3 Limitación del uso de prompts generales
Restringiendo el uso de LLM en modo general donde no es viable auditar la salida en busca de inyección, limitamos el impacto cuando esta ocurra. Por ejemplo, en un flujo externo obtener URL, LLM generar respuesta, cliente mostrar, una inyección solo afectaría al texto mostrado sin activar operaciones.
El efecto es análogo al escape frente a SQLi o XSS se puede mostrar contenido malicioso, pero se evita ejecutar acciones maliciosas.
2.4 Transparencia adaptativa para mejorar la experiencia
Al separar pasos, cuando existan operaciones externas o vía MCP, puede solicitarse aprobación del usuario con claridad contextual.
Ejemplo cuando se requiere confirmación Plan previsto Recuperar datos del calendario de los últimos 7 días. Redactar el contenido del correo. Enviar el correo a Suzuki san. Se pedirá confirmación del contenido antes del envío. Continuar Sí Cancelar Configuración detallada.
Si no se requiere confirmación no se muestra nada y se pasa a la Etapa 2, manteniendo una experiencia fluida.
Así se divulga la información según el riesgo, se evitan confirmaciones innecesarias y se refuerza la confianza del usuario al indicar operaciones relevantes antes de ejecutarlas.
2.5 Procesamiento seguro por defecto
Si no puede identificarse un procedimiento específico, se aplica un comportamiento por defecto seguro generar respuesta y mostrar. Ejemplo Entrada Cómo has estado últimamente. Resultado LLM Generar respuesta. cliente Mostrar. Se mantiene el comportamiento clásico hasta que existan instrucciones confirmadas.
2.6 Complejidad del análisis de instrucciones
Para resolver límites entre órdenes directas como eliminar el archivo y órdenes ambiguas como organizar datos innecesarios, se permiten respuestas de confirmación dentro del prompt dedicado.
Reglas de juicio 1 operación del sistema clara especificar en el plan. 2 operación ambigua solicitar confirmación. 3 sin operación del sistema procesamiento por defecto.
Ejemplo Usuario Organiza datos innecesarios. Respuesta de confirmación No puedo determinar el procesamiento. Indica tu intención A analizar y proponer métodos sin operar el sistema. B ejecutar movimiento o borrado de archivos operación del sistema.
Esta confirmación se limita a generar y mostrar respuesta, preservando las garantías de seguridad del enfoque multietapas.
3. Retos de implementación
3.1 Gestión de fiabilidad del historial de chat
La arquitectura parte de confiar en los datos que sustentan el análisis de instrucciones. La entrada del usuario es intencional y, si de ella se derivan acciones inesperadas, se clasifica como problema de calidad del modelo o de intención del usuario. Sin embargo, con frecuencia se necesita contexto del propio chat, por ejemplo AI propone métodos, el usuario pide ejecutar eso y es necesario referenciar mensajes anteriores.
Para garantizar fiabilidad, el historial debe separarse entre contenido mostrado en pantalla y contenido no mostrado. El historial de referencia que alimenta el análisis debe almacenar solo lo que el usuario vio, evitando contaminación por datos externos. De este modo, el análisis se basa en información ya validada por el usuario. Si hubiera inyección en lo mostrado y el usuario la consiente, se considera cuestión de rendimiento del modelo y pericia del usuario.
Además, puede clasificarse la confianza por niveles Nivel 1 últimas respuestas del chat actual. Nivel 2 todo el historial del chat. Si con Nivel 1 es suficiente, se continúa; de lo contrario se pasa a Nivel 2. Si con Nivel 2 hay dudas, se solicita confirmación o más detalles. Esto también ayuda a mitigar confusión por historiales largos.
Para evitar contaminación adicional, ante operaciones del sistema es útil una verificación cruzada 1 plan con historial completo. 2 plan con solo la respuesta previa y la entrada actual. 3 comparar. 4 si difieren, cambiar a modo de confirmación antes de actuar.
3.2 Cierre de vectores restantes mediante separación en la UI
Aunque el enfoque multietapas bloquea la inyección desde datos externos, persiste el riesgo de mezclar instrucciones y datos en el mismo campo. Un atacante podría inducir a pegar un texto que incluya órdenes maliciosas. La solución es separar físicamente el campo de instrucciones del campo de datos de referencia. Así se impide estructuralmente la mezcla, se refuerza la higiene operativa y se desactiva la ingeniería social basada en copia y pega.
3.3 Inyección durante la selección de MCP
Si el análisis usa MCP y se recurre a descripciones de herramientas, estas podrían contener inyección. La mitigación incluye no usar descripciones en crudo, sino resúmenes previos con LLM, cotejar con el nombre de la herramienta y aplicar políticas operativas de confianza similar a no instalar software no fiable.
3.4 Instrucciones con ramificación condicional compleja
Órdenes como si hay error corrige y si no despliega a producción exigen juzgar resultados externos. Para evitar que el LLM decida en base a texto manipulable, conviene definir interfaces tipo MCP con respuestas estructuradas, separando un resultado booleano o numérico del mensaje textual. Por ejemplo una herramienta de pruebas que devuelve result boolean y message string. Así el juicio se realiza con el booleano, minimizando el impacto de inyecciones en la salida textual.
6. Conclusión cambio de paradigma en seguridad
Esta arquitectura aporta una solución de raíz a la inyección de prompts, desplazando el foco desde detectar ataques perfectos hacia eliminar por diseño los caminos de ataque. Al distinguir con claridad entre limitaciones de capacidad de la IA y daños por ataque, aceptando las primeras y bloqueando las segundas de forma estructural, posibilita sistemas de IA prácticos y seguros.
En Q2BSTUDIO aplicamos esta arquitectura multietapas en soluciones de software a medida y aplicaciones a medida, con especialización en inteligencia artificial, ciberseguridad, agentes IA, automatización de procesos, servicios cloud aws y azure, y servicios inteligencia de negocio con power bi. Si tu organización quiere acelerar la adopción de ia para empresas con garantías, visita nuestra página de inteligencia artificial para empresas y refuerza tu postura defensiva con nuestros servicios de ciberseguridad y pentesting. Nuestro equipo diseña e implementa planes de despliegue seguros de agentes IA, integraciones con MCP, controles de validación automáticos y flujos de aprobación que preservan la agilidad sin sacrificar la protección.
Resumen ejecutivo beneficios clave reducción del riesgo operativo ante inyección, trazabilidad y depuración del plan de ejecución, menor acoplamiento entre tareas cognitivas y acciones del sistema, mejor experiencia de usuario gracias a transparencia adaptativa y escalabilidad mediante componentes optimizables por separado. Este enfoque ayuda a sacar el máximo partido a la inteligencia artificial en entornos profesionales manteniendo bajo control la superficie de ataque.