Qué es un prompt injection y cómo protegerse

El día que un agente hizo caso a quien no debía

Cada vez más empresas conectan un agente de IA a sus canales reales: la bandeja de entrada, el CRM, el sistema de tickets, el chat de soporte. La promesa es simple, que el agente lea, responda y hasta actúe sin que un humano revise cada paso. El problema aparece en el momento en que ese agente empieza a leer contenido que la empresa no controla: un correo de un tercero, una página web, un documento adjunto, un comentario en un formulario público. Todo ese contenido entra por el mismo canal de texto por el que el agente recibe sus órdenes.

El resultado se ve en casos reales, aunque casi nunca se hacen públicos. Una distribuidora mediana en México dio de baja su asistente de cobranza por correo después de que, en un mensaje de un cliente, apareciera un párrafo que el asistente interpretó como una instrucción y terminó enviando el estado de cuenta de otra empresa. Una aseguradora en Colombia tuvo que pausar un piloto de atención porque el sistema, al resumir un documento adjunto, ejecutó una acción que nadie había autorizado. En ningún caso hubo una brecha de seguridad clásica, contraseña filtrada o servidor vulnerado. El agente simplemente hizo lo que el texto le pidió.

Ahí está el dolor real para cualquier empresa que está automatizando con IA: cuanta más autonomía y más acceso le da al agente, más crece una superficie de riesgo que no existía cuando el mismo proceso lo hacía una persona. Y la mayoría de los equipos que despliegan estos agentes están mirando el ahorro de horas que van a ganar, no esta exposición nueva que están abriendo al mismo tiempo.

Qué es un prompt injection, en criterio de negocio

En criterio de negocio, un prompt injection no es un error de software tradicional, es una confusión que alguien aprovecha a propósito. Los sistemas de IA generativa que hoy se usan como agentes reciben dos cosas por el mismo canal de texto: las instrucciones de quien los configuró (la empresa) y el contenido que van a procesar (correos, documentos, páginas, comentarios). El modelo no tiene una forma nativa y confiable de separar ambas cosas. Si el contenido que procesa trae algo redactado como una orden, existe una probabilidad real de que el modelo la siga.

Esto no depende de que el modelo sea de mala calidad. Es una consecuencia de cómo funciona hoy la arquitectura de los modelos de lenguaje: todo lo que entra a su contexto se procesa como texto, y el texto no trae una etiqueta confiable que diga esto es una orden o esto es solo información para leer. Por eso el riesgo no se resuelve comprando un modelo distinto, se gestiona con el diseño del sistema que rodea al modelo, empezando por qué permisos le da la empresa.

Por qué el modelo no distingue instrucciones de datos

Para entender por qué esto pasa hay que soltar una idea que suena obvia pero no lo es: el modelo no lee un correo, un documento o una página web como lo hace una persona, separando mentalmente esto es el mensaje de esto es una orden que alguien me está dando. El modelo recibe una sola secuencia de texto y genera la respuesta más probable dado todo ese texto junto. Si en algún punto de esa secuencia aparece algo redactado como instrucción, el modelo tiene una tendencia real a tratarla como tal, venga de donde venga.

Esto convierte cualquier fuente de texto externo en un vector potencial: un correo entrante, un comentario de un formulario público, el contenido de una página que el agente visita para resumir, un archivo que un cliente sube a un portal. La empresa no controla ninguno de esos textos, y sin embargo todos terminan, en algún momento, dentro del mismo espacio que procesa el modelo. Esto tiene relación directa con lo que en el mundo de la IA se conoce como ingeniería de contexto, es decir, cómo se arma y se ordena todo lo que el modelo recibe antes de responder: si esa disciplina es débil, el riesgo de confundir dato con orden sube.

Vale la pena distinguir esto de un jailbreak de IA, donde quien manipula al modelo suele ser el propio usuario que interactúa con él, tratando de saltarse sus reglas a la vista de todos. Acá el ataque viene de un tercero externo, escondido dentro de un contenido que el agente ni siquiera identifica como un interlocutor. No hace falta que ese tercero sea sofisticado. Lo único que necesita es saber que el agente va a leer ese texto en algún momento y que el sistema no separa con claridad qué es dato y qué es orden.

El riesgo real no es leer, es lo que el agente puede hacer después

El error más común al hablar de este riesgo es tratarlo como un problema binario, si el agente puede ser engañado o no. La pregunta que de verdad importa en una empresa es otra: qué puede hacer el agente después de ser engañado. Un agente que solo lee y resuelve dudas tiene un techo de daño bajo. Un agente que puede enviar correos, escribir en el CRM, generar órdenes de compra o mover dinero tiene un techo de daño que crece en la misma proporción que sus permisos. Cuanto más se acerca un sistema a la definición de un agente autónomo, capaz de decidir y ejecutar varios pasos sin pedir permiso en cada uno, más relevante se vuelve este mapa de permisos.

• Solo lectura y respuesta: el agente resume, responde preguntas o redacta borradores, sin ejecutar nada por su cuenta.
• Escritura en sistemas internos de bajo impacto: crear una tarea, agendar una reunión, actualizar un campo no crítico en el CRM.
• Comunicación externa en nombre de la empresa: enviar correos, responder a clientes o publicar contenido sin revisión previa.
• Acciones sobre datos sensibles: acceder, modificar o compartir información de clientes, contratos o cifras financieras.
• Transacciones o cambios irreversibles: mover dinero, aprobar pagos, cancelar pedidos, eliminar registros.

Cada nivel de esta lista pide un nivel distinto de control. Tratar todos los agentes con la misma vara, sea la de confío en la IA o la de no uso IA por si acaso, es no entender dónde está realmente el riesgo. El mapa de permisos debería revisarse antes de sumar cada nueva capacidad, no después del primer incidente.

Las defensas que sí funcionan

Las defensas que de verdad mueven la aguja no dependen de que el modelo se porte bien, dependen de cómo la empresa diseña el sistema alrededor del modelo. Esa es la diferencia entre una empresa que sufre un incidente serio y una que lo contiene antes de que cause daño. En la práctica, esto se traduce en un puñado de decisiones de diseño, no en una funcionalidad que se compra una sola vez.

• Privilegio mínimo: el agente solo tiene acceso a los sistemas y datos que su tarea exige, nunca por si acaso sirve para algo más.
• Aprobación humana en acciones irreversibles: enviar dinero, borrar registros, publicar contenido externo o cerrar un contrato pasan siempre por una persona antes de ejecutarse.
• Separación entre datos e instrucciones: el sistema distingue, a nivel de diseño, qué texto viene de quien configura al agente y qué texto es contenido externo que se debe procesar con cautela.
• Entornos acotados para tareas de riesgo alto: cuando el agente procesa contenido no confiable, corre con permisos reducidos, no con las mismas credenciales que un administrador.
• Registro y trazabilidad de cada acción: toda acción que el agente ejecuta queda registrada con su origen, para poder auditar qué pasó y por qué.

Esta aprobación humana en las acciones irreversibles es, en el fondo, el principio de human in the loop aplicado a la seguridad, no solo a la calidad de la respuesta. Ninguna de estas medidas elimina el riesgo por completo. Lo que hacen es asegurar que, si un agente es engañado, el daño posible tenga un techo bajo y quede visible casi de inmediato, en lugar de un techo alto y silencioso.

Lo que no alcanza y qué preguntarle a un proveedor

Hay una defensa que se repite mucho y que no sirve como control único: pedirle al modelo, dentro de sus propias instrucciones, que ignore cualquier orden que reciba dentro del contenido que procesa. Suena razonable, pero es la misma superficie de texto la que decide si esa regla se respeta o no, y ya vimos que el modelo no separa con certeza una cosa de la otra. Es una capa más, no una solución. Confiar solo en eso es como pedirle a alguien nuevo en el equipo que use el sentido común y no darle ningún proceso ni límite formal.

Filtrar palabras o frases sospechosas tampoco resuelve el problema de fondo, porque cualquier instrucción se puede redactar de mil formas distintas y un filtro fijo siempre queda un paso atrás. Estas medidas ayudan como capa adicional, nunca como la única barrera. Antes de confiar en un agente con permisos amplios, probarlo a propósito con contenido diseñado para manipularlo, lo que se conoce como red teaming en IA, dice mucho más sobre su seguridad real que cualquier demo comercial.

• Qué permisos tiene el agente por defecto y quién decide subirlos.
• Qué acciones requieren aprobación humana antes de ejecutarse, y si eso se puede configurar o viene fijo.
• Cómo separa el sistema el contenido externo que el agente procesa de las instrucciones internas.
• Qué queda registrado cuando el agente ejecuta una acción, y quién puede revisarlo después.
• Qué pasó la última vez que alguien intentó manipular al agente con contenido externo, y cómo lo detectaron.

Si el proveedor no tiene una respuesta clara a estas preguntas, la conversación de compra debería pausarse ahí, no seguir avanzando con la demo bien armada.

Mi criterio

Cuándo tu empresa está expuesta y cuándo no

No toda empresa que usa IA generativa está igual de expuesta a un prompt injection, y no toda empresa que lo está corriendo ya sufrió un incidente. La diferencia rara vez es el modelo que usan, es qué tan bien mapearon permisos y controles antes de dejar que el agente actuara solo.

Señales de que tu empresa tiene una exposición real

• El agente lee contenido que no genera la empresa (correos de terceros, páginas web, documentos que suben clientes) y además puede ejecutar acciones sin revisión.
• Nadie en el equipo puede explicar con precisión qué permisos tiene el agente hoy, solo que hace varias cosas.
• Las acciones irreversibles, como enviar dinero, borrar registros o responder a clientes, no pasan por ninguna aprobación humana.
• No existe un registro consultable de qué acciones ejecutó el agente y por qué.
• El criterio de seguridad del proyecto se resume en confiamos en que el modelo no va a hacer nada raro.

Señales de que el riesgo está razonablemente controlado

• Cada agente tiene un permiso definido y documentado, y subir ese permiso exige una decisión explícita, no un ajuste silencioso.
• Las acciones irreversibles o de impacto alto siempre pasan por una persona antes de ejecutarse.
• El sistema distingue, en su diseño, entre instrucciones de quien configura al agente y contenido externo que solo se debe procesar con cautela.
• Existe un registro auditable de las acciones del agente, con claridad de quién lo puede revisar y con qué frecuencia se hace.
• El equipo ya probó, a propósito, qué pasa si el agente recibe contenido manipulado, en lugar de asumir que nunca va a pasar.

El orden que evita el problema

El error de fondo casi nunca es la herramienta, es el orden en el que la empresa la instaló. Primero está el dolor real: procesos que dependían de que una persona leyera correo, documentos o mensajes de clientes y decidiera qué hacer con eso. Luego está el proceso: qué se automatiza, con qué permisos y bajo qué aprobación. Después el dato: qué información va a tocar el agente y qué tan sensible es. Recién al final entra la herramienta, el modelo o la plataforma que ejecuta todo eso. Cuando una empresa arranca por el final, comprando el agente más vistoso y dándole permisos amplios desde el primer día, está construyendo su exposición al mismo ritmo que su automatización.

Un prompt injection no es una falla exótica reservada a laboratorios de investigación, es la consecuencia directa de dejar que un sistema lea texto que no controla y actúe con más autoridad de la que ese diseño puede sostener. La empresa que entiende esto no deja de usar agentes de IA, simplemente deja de tratarlos como si fueran empleados de confianza total desde el primer día.