Nota Este artículo ha sido reelaborado y traducido al español con asistencia de IA. Si detectas pasajes poco claros, indícalos y lo mejoraremos.
Introducción Los ataques de inyección de indicaciones son un problema crítico en 2025, con casos de daño confirmados. A medida que se generalizan los agentes IA, no es responsable avanzar sin una solución de base. Proponemos una arquitectura multietapas que bloquea de forma estructural la manipulación del sistema y la destrucción de datos mediante indicaciones maliciosas. No busca mejorar la calidad de las respuestas ni la comprensión contextual, aspectos que deben resolverse con mejoras de modelo. Diferenciamos claramente lo aceptable de lo inaceptable: es tolerable que haya respuestas raras que no ejecuten acciones en el sistema; es inaceptable que se lancen operaciones no deseadas como envíos de correo, llamadas a herramientas o MCP.
Arquitectura multietapas La seguridad se logra separando el proceso en dos fases. Etapa 1 análisis de instrucciones convierte la petición del usuario en un plan de ejecución específico. Etapa 2 ejecución toma el plan confirmado y lo aplica sobre datos externos para producir resultados. La clave es que las operaciones ejecutables quedan completamente determinadas antes de leer cualquier dato externo, imposibilitando de forma estructural que dichos datos alteren el plan.
Ejemplo claro Petición enviar la agenda de los últimos siete días por correo a la persona indicada. Plan en Etapa 1 recuperar calendario de los últimos siete días; redactar el contenido del correo a partir de lo recuperado; enviar el correo; generar el resumen del resultado; mostrarlo al usuario. Aunque el calendario contenga texto malicioso, solo se considera dato a procesar y no puede cambiar las operaciones ya fijadas. El peor caso sería un contenido de correo extraño, sin comprometer el sistema.
Ejemplo con juicio difícil Petición dime qué opinas del contenido de una URL. Plan recuperar la URL; elaborar la respuesta; mostrarla. Incluso si la página incluye instrucciones maliciosas, lo único que sucede es una visualización, sin impacto operativo.
Prompts dedicados para el análisis En la Etapa 1 se recomienda usar prompts tipo generación de código, con formato de salida fijo y validable mecánicamente. Esto aporta velocidad, menos errores por interferencias funcionales, planes de ejecución transparentes y mejoras incrementales por etapa.
Contener el riesgo del uso general de LLM Delimitando dónde se usa el LLM de propósito general, si surge una inyección esta solo afectará a contenido mostrado, no a operaciones. Es un efecto análogo a escapar consultas ante SQLi o XSS: el contenido malicioso puede verse, pero no ejecuta acciones.
Transparencia adaptable y aprobaciones Al separar pasos, cuando haya llamadas a APIs, herramientas o MCP se puede solicitar aprobación del usuario. Ejemplo plan previsto recuperar agenda de siete días; organizarla en formato correo; enviar a la persona destinataria; confirmar contenido antes de enviar. Para acciones rutinarias y seguras, no se molesta al usuario; para operaciones sensibles se muestra información clara que inspira confianza.
Comportamiento seguro por defecto Si no se puede determinar un procedimiento específico, se responde de forma segura por defecto generar respuesta y mostrar. Por ejemplo, ante cómo has estado últimamente, el sistema continúa conversando como un asistente convencional hasta que existan instrucciones confirmables. Repetir aclaraciones es un tema de calidad, no de seguridad.
Ambigüedad y confirmaciones Para frases como ordenar datos innecesarios, las reglas son simples. Si una operación del sistema es clara, se incluye en el plan. Si es ambigua, se solicita confirmación. Si no hay operación del sistema, se responde por defecto. Un mensaje de confirmación útil sería deseas solo analizar y proponer métodos de organización con salida en texto, o ejecutar realmente movimientos o borrados de archivos.
Gestión de la fiabilidad del historial El análisis de instrucciones debe basarse en información fiable. El chat suele mezclar contenido del usuario con resultados externos como webs, que pueden contaminar el historial. Solución separar estrictamente lo visualizado en pantalla de lo no mostrado y reutilizar solo lo confirmado visualmente por el usuario. Además, emplear niveles de confianza jerárquicos nivel 1 últimas respuestas de la conversación y nivel 2 todo el historial. Si el plan es consistente con nivel 1, se procede; si no, se valida con nivel 2; si persiste la duda, se pide detalle. Para prevenir contaminación, comparar dos planes uno con historial completo y otro solo con la respuesta anterior más la entrada actual; si difieren, cambiar a modo de confirmación.
Defensa adicional desde la interfaz Aunque la arquitectura bloquee la inyección desde datos externos, queda el vector de mezclar instrucciones y datos en el mismo campo. El patrón peligroso es pegar texto externo sin comprenderlo y pedir que se traduzca, incorporando indicaciones maliciosas. Recomendación separar físicamente campo de instrucciones y campo de datos. Esto impide mezclar elementos, refuerza la consciencia operativa y neutraliza tácticas de ingeniería social basadas en copia y pega.
Riesgos al seleccionar MCP Si el análisis usa catálogos MCP, las descripciones podrían incluir inyecciones. Mitigue usando MCP de confianza, resumiendo descripciones con un LLM en canal controlado o contrastando los resultados con el nombre y la función declarada antes de permitir su uso.
Condicionales complejos Peticiones como si hay error corrige, si no despliega a producción requieren ramas condicionales. En vez de que el LLM interprete texto libre de una herramienta, defina retornos estructurados con campos booleanos o enteros separados del mensaje de texto. Así las decisiones se toman con datos tipados y se minimizan los riesgos de inyección en los flujos condicionales.
Resumen y cambio de paradigma La arquitectura multietapas desplaza el foco de detectar todas las inyecciones a eliminar vías de ataque por diseño. Al aceptar las limitaciones normales de la IA pero impedir estructuralmente el daño operativo, ofrece una defensa robusta y práctica para agentes IA en entornos reales.
Q2BSTUDIO y la implantación de esta arquitectura En Q2BSTUDIO diseñamos e implantamos soluciones de software a medida y aplicaciones a medida con énfasis en inteligencia artificial, ciberseguridad, agentes IA, automatización de procesos, servicios cloud aws y azure, y servicios inteligencia de negocio con power bi. Podemos convertir esta arquitectura en una plataforma lista para producción, integrada con tus sistemas, con auditoría de seguridad extremo a extremo y observabilidad. Conoce cómo aplicamos estas técnicas en proyectos de ia para empresas en nuestra página de inteligencia artificial y revisa nuestras capacidades de pruebas de seguridad y respuesta ante amenazas en ciberseguridad. Si tu organización busca agentes IA seguros que respeten flujos aprobados, conectados a servicios cloud y cuadros de mando con power bi, nuestro equipo puede ayudarte a reducir riesgos y acelerar el valor de negocio.