Por Andrés Vargas, especialista en ciberseguridad
Hace unas semanas ocurrió en Brasil un caso que ayuda a entender uno de los problemas de seguridad que están apareciendo con la inteligencia artificial. Ante el volumen de causas judiciales que reciben, varios tribunales brasileños están utilizando aplicaciones basadas en IA para analizar los escritos que llegan y, de esa forma, adelantar borradores que después el juez debe revisar con apoyo de su equipo.
En uno de esos tribunales, un abogado presentó un recurso con una instrucción escrita en letra blanca sobre fondo blanco, “invisible” para quien leyera el documento. El texto le pedía a la IA que aceptara sus argumentos, pero la instrucción fue detectada y el abogado recibió una multa del 10% del valor de la causa.
Este tipo de ataque se conoce como inyección de prompt y se basa en que un modelo de lenguaje no tiene una forma totalmente confiable de separar las instrucciones que debe seguir del contenido que está procesando. Una instrucción escondida en un documento que la aplicación va a procesar puede terminar influyendo en lo que esta hace, como si fuera parte de las instrucciones que definen cómo debe comportarse.
Lo que muestra este caso es que el vector de ataque ya existe. En los últimos meses han aparecido intentos similares en otros tribunales de Brasil. En los casos detectados, el mecanismo fue simple (instrucciones ocultas mediante algún truco tipográfico) y las defensas funcionaron. Sin embargo, intentos más sofisticados podrían ser mucho más difíciles de detectar y poner en riesgo la integridad de los procesos.
Los tribunales brasileños son un ejemplo concreto, pero cualquier organización que use aplicaciones basadas en IA está expuesta a riesgos similares.
Cerca de un tercio de las organizaciones aún no tiene un proceso para evaluar la seguridad de sus herramientas de IA antes de desplegarlas.
Si bien en Chile no existen estudios que midan cuántas organizaciones están evaluando la seguridad de sus aplicaciones con IA, algunas cifras ayudan a entender el contexto. El estudio SONDA Tech Trends 2026 muestra que el 88% de las empresas ya tiene algún grado de interacción con la inteligencia artificial y que el 53% todavía se maneja con lineamientos generales. A nivel mundial, el Global Cybersecurity Outlook 2026 del Foro Económico Mundial señala que cerca de un tercio de las organizaciones aún no tiene un proceso para evaluar la seguridad de sus herramientas de IA antes de desplegarlas. Aquello evidencia que la seguridad de la inteligencia artificial sigue siendo un desafío para muchas organizaciones.
Pero la inyección de prompt es solo una parte del problema. Las aplicaciones basadas en IA han ido ganando capacidades con el tiempo. Al principio respondían preguntas, después empezaron a leer documentos y hoy también consultan bases de datos, se conectan a otros sistemas o ejecutan tareas. Cuantas más capacidades adquieren, más puertas de entrada existen para que algo falle o sea manipulado.
En 2025, investigadores de Aim Security descubrieron que era posible enviarle a un usuario de Microsoft 365 Copilot un correo con instrucciones ocultas. Cuando Copilot lo procesaba, esas instrucciones podían alterar su comportamiento, llevarlo a buscar información interna a la que el usuario tenía acceso y lograr que esa información saliera hacia un servidor externo.
Una aplicación con IA sigue siendo una aplicación, con sus datos, sus permisos y sus mecanismos para ejecutar acciones.
Microsoft corrigió la falla antes de que hubiera víctimas conocidas, pero el caso evidenció algo relevante: la inyección de prompt era el punto de entrada, mientras que el impacto dependía de las capacidades que la aplicación había puesto al alcance del modelo. Una aplicación con IA sigue siendo una aplicación, con sus datos, sus permisos y sus mecanismos para ejecutar acciones.
De esta manera, los problemas pueden originarse tanto en la configuración del modelo como en las herramientas y sistemas que tiene conectados. Una aplicación también puede tener más capacidades de las necesarias, ya sea porque el modelo fue configurado con demasiado margen o porque las herramientas que utiliza no tienen los límites adecuados. En algunos casos, el problema no está necesariamente en el modelo, sino en cómo se diseñó todo lo que lo rodea.
Una aplicación también puede exponer información que no debería, tanto por cómo está configurado el modelo como por las herramientas y sistemas que tiene conectados. O puede tener más capacidades de las necesarias, ya sea porque el modelo fue configurado con demasiado margen o porque las herramientas que usa no tienen los límites adecuados. En algunos casos, el problema no está necesariamente en el modelo, sino en cómo se diseñó todo lo que lo rodea.
Además, cuando la interfaz es de voz, se agregan capas de riesgo que no existen en un chat escrito. Antes de que exista un texto que el modelo pueda interpretar, hay un audio y una transcripción que también pueden ser manipulados. Una palabra mal transcrita puede cambiar la intención de lo que se dijo, una voz se puede clonar y hay investigaciones que muestran que, bajo ciertas condiciones, es posible enviar instrucciones que un micrófono capta, pero que el oído humano no percibe. Cada una de esas capas agrega nuevos puntos que conviene evaluar.
Finalmente, cuando nos preguntamos cómo seguirá el avance de la IA, la historia de la seguridad ofrece un antecedente útil. La inyección SQL empezó a conocerse públicamente en 1998, a partir de una publicación en la revista Phrack, y casi treinta años después sigue apareciendo en aplicaciones, pese a que existe una forma conocida de prevenirla: separar los datos del usuario de las instrucciones que ejecuta la base de datos.
En los modelos de lenguaje esa distinción es mucho más difícil de conseguir, y por eso el Centro Nacional de Ciberseguridad (NCSC) del Reino Unido advierte que la inyección de prompt quizás nunca llegue a tener una solución tan definitiva. Hay defensas que reducen el riesgo, pero no conviene diseñar suponiendo que ninguna instrucción indebida logrará pasar.
Antes de habilitar una capacidad nueva, vale la pena asumir que en algún momento el asistente va a seguir una instrucción que no corresponde.
Antes de habilitar una capacidad nueva, vale la pena asumir que en algún momento el asistente va a seguir una instrucción que no corresponde, y preguntarse qué información tendría a su alcance, qué podría modificar y qué control lo detendría.
