IBM lanza LLMON, su lenguaje contra el prompt injection

IBM mete un lenguaje de marcado en sus modelos pequeños

IBM publicó LLMON (LLM Object Notation, se pronuncia «lemon»), un lenguaje de marcado diseñado específicamente para que los modelos de lenguaje distingan instrucciones de datos, y lo llevó a dos modelos experimentales derivados de Granite 4.1: granite-4.1-3b-LLMON-preview y granite-4.1-8b-LLMON-preview. La cifra que resume la apuesta: en el benchmark OPI, estos modelos evitan un 47% más de ataques de prompt injection que el mejor modelo frontera que IBM evaluó, y un 95% más que el mejor modelo open source de su comparativa.

Para un founder que ya tiene un agente leyendo facturas, tickets o respuestas de una API, eso no es un detalle académico. Es la diferencia entre un asistente que obedece a tu sistema y uno que obedece a una frase escondida en un documento que alguien subió.

¿Qué es LLMON y cómo se diferencia de JSON?

LLMON es un lenguaje de marcado tipo XML cuyos delimitadores estructurales no son caracteres, sino tokens especiales reservados en el vocabulario del modelo. Cada componente semántico —instrucción, dato, requisito— se marca con una etiqueta con significado, y los límites entre bloques son explícitos.

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

El diagnóstico de IBM apunta a un problema de diseño de formatos. JSON se creó para parsers, no para modelos causales: el tokenizador no respeta la gramática, y la estructura se codifica con los mismos caracteres ({, ", :) que aparecen en el texto normal. Para el modelo, una comilla que abre un campo y una comilla dentro de un documento son el mismo token. Las reglas de escape que un parser entiende son, para el modelo, solo patrones estadísticos. Y la profundidad de anidamiento se codifica contando corchetes, algo en lo que los transformers son reconocidamente débiles sobre tramos largos.

LLMON invierte eso: la estructura y el contenido usan partes distintas del vocabulario. Las etiquetas se declaran al inicio de cada span, los límites son explícitos y el anidamiento se declara localmente, así el modelo no tiene que llevar la jerarquía en la cabeza a lo largo de miles de tokens.

¿Cómo se ve LLMON en la práctica?

El cambio más importante es que LLMON no reemplaza los chat templates: los enriquece. Donde un template convencional dice a qué rol pertenece cada parte (system, user, assistant), LLMON dice qué significa cada componente y cómo se relacionan entre sí.

En la práctica, sigues construyendo la misma lista de mensajes que pasarías a cualquier modelo de chat y llamas a apply_chat_template. La diferencia es que un turno ahora puede nombrar sus partes y marcar cada una como exec: True o exec: False. Una parte marcada como True queda ligada al bloque de ejecución, que declara qué instrucción correr, sobre qué datos y con qué requisitos. Una parte marcada como False se renderiza en el contexto pero no la referencia nadie.

IBM lo ilustra con un ejemplo mínimo: un turno de usuario con una instrucción («Write a short paragraph about»), un dato («IBM Company») y dos requisitos («Use less than 10 words», «Do not use commas»). Un template convencional habría aplanado todo en un solo string y dejado al modelo inferir qué era la tarea, qué el sujeto y qué las restricciones. Con LLMON, ese mismo turno llega al modelo como cinco bloques direccionables, unidos por un sexto bloque que dice: ejecuta esta instrucción, sobre estos datos, sujeto a estos dos requisitos, y pon la respuesta en el bloque indicado.

Los IDs de bloque son de dos caracteres y se codifican como un único token, así que direccionar un bloque cuesta siempre dos tokens.

¿Cuánto mejora la resistencia al prompt injection?

La inyección indirecta de prompts es un ataque donde una instrucción maliciosa viaja escondida en un dato: un documento recuperado, la respuesta de una herramienta, información que aporta el usuario. Es exactamente el problema que la separación instrucción/dato de LLMON busca atacar.

IBM evaluó los previews contra varios modelos open source y cerrados en el benchmark OPI, que coloca la inyección dentro de los datos de tareas clásicas de NLP. La métrica que reportan es robustez, definida como 1 menos la tasa de éxito del ataque. El resultado: los modelos no-LLMON son altamente susceptibles y ejecutan las instrucciones inyectadas con alta probabilidad, mientras que los LLMON prácticamente eliminan el problema en ese benchmark, con las cifras de 47% y 95% mencionadas arriba. La tendencia se repite en otros benchmarks, ASB y StruQ.

Un detalle importante para no sobreinterpretar: esas pruebas miden robustez ante inyecciones indirectas estáticas. La separación instrucción/dato ataca directamente ese tipo de ataque. IBM dice estar trabajando en mejorar también los ataques adaptativos, que se despliegan a lo largo de muchos turnos de conversación.

Y las ganancias de seguridad no vienen a costa de capacidad general: según IBM, los modelos LLMON rinden a la par de los Granite 4.1 Instruct en las categorías estándar de benchmarks.

Por qué esto importa justo ahora

El prompt injection no es una preocupación teórica. En la edición 2026 de su Top 10 para aplicaciones con LLM, publicada el 3 de agosto de 2026 durante la semana de Black Hat USA, OWASP mantuvo el prompt injection en el primer puesto, una posición que ocupa desde la primera edición de la lista, según reportó Help Net Security. La lista incorporó por primera vez datos de incidentes reales —6.639 casos documentados, con un peso del 25% en el ranking final— además del voto de cientos de profesionales.

Lo relevante es la razón estructural que OWASP señala: los modelos procesan las instrucciones del sistema, la entrada del usuario y el contenido recuperado como un único flujo de tokens, sin un mecanismo incorporado que separe «instrucciones a seguir» de «contenido a leer». El SQL injection se resolvió con consultas parametrizadas que separan estructuralmente datos y código; para los modelos de lenguaje no existía un equivalente. El propio Centro Nacional de Ciberseguridad del Reino Unido ya había señalado en un blog de 2023 que el prompt injection «puede ser simplemente un problema inherente a la tecnología LLM», y CISA y sus socios de Five Eyes hicieron una admisión comparable en su guía sobre IA agéntica de mayo de 2026.

El ecosistema de agentes lo está sintiendo. Ars Technica reportó en octubre de 2026 que Google y otras cuatro organizaciones reconocieron vulnerabilidades que explotan un agente dentro de una red para propagar instrucciones dañinas a otros agentes internos, aprovechando los huecos de confianza del Model Context Protocol (MCP). Es una forma especial de prompt injection que no ataca al LLM, sino a un agente específico —traducción, análisis de datos— cuyos guardrails suelen ser laxos.

Ahí es donde LLMON se vuelve interesante: no es un guardrail añadido encima del modelo, sino una propiedad que emerge del layout del contexto. Una instrucción alcanzada a través de un bloque de ejecución es autoritativa; cualquier cosa alcanzada como input —datos, documentos, esquemas de herramientas, resultados de herramientas— es material para leer, no una orden a seguir. IBM es explícito en que es un comportamiento aprendido, no una garantía impuesta.

¿Qué significa esto para tu startup?

Si tu producto usa un modelo pequeño para tareas de alto volumen —clasificar, extraer, resumir, enrutar—, la propuesta de IBM ataca un dolor real: los modelos chicos son justamente los más frágiles cuando el contexto mezcla instrucciones y datos sin estructura explícita.

Tres cosas concretas que puedes hacer esta semana:

Prueba el swap antes de rediseñar nada. Si ya experimentas con Granite 4.1 3B u 8B, IBM afirma que puedes cambiar al preview de LLMON y ver un rendimiento general comparable con mucha más resistencia a la inyección. No hace falta pipeline de conversión: basta con nombrar las partes del turno (instrucción, dato, requisito) y el chat template que viene con el modelo las convierte en bloques LLMON.
Audita dónde entra contenido no confiable en tu contexto. Haz la lista de todos los puntos donde un documento de un cliente, una respuesta de herramienta o un campo libre llegan al prompt. Esos son tus vectores de inyección indirecta, y son los que la separación instrucción/dato ataca de frente.
Si ya tienes pipelines en JSON, no los tires. IBM publicó convertidores y notebooks que traducen JSON a LLMON y de vuelta sin pérdida, y una librería (LLMON-converters) que preserva la estructura interna de un documento JSON como bloques tipados y direccionables en lugar de un string opaco.

Y si tu dominio tiene una estructura propia, LLMON no está atado a un esquema fijo: puedes elegir tus propios nombres de etiquetas y afinar un LoRA encima del modelo para que las entienda. IBM lo demuestra en ScienceWorld, un benchmark de tareas científicas elementales, donde definió un vocabulario con etiquetas como instr.task.goal, data.state.room o assistant.next_action, renderizó las soluciones de referencia con esas etiquetas y afinó un LoRA que después juega partidas nuevas escribiendo su siguiente acción en ese vocabulario.

Los límites: es un preview, no producción

Conviene leer la letra chica. IBM describe estos modelos como un preview experimental, listo para exploración y evaluación, pero no para producción. Los modelos parten de checkpoints base de Granite 4.1, no de los instruct ya publicados, así que el comportamiento LLMON se aprende durante el post-entrenamiento en lugar de superponerse a un formato de chat existente.

El entrenamiento combinó la re-serialización de un corpus convencional de instruction tuning a LLMON —cada componente del prompt como bloque direccionable, con un bloque de ejecución por turno—, datos aumentados con instrucciones y bloques señuelo deliberadamente no ligados, cinco etapas secuenciales de GRPO que cubren razonamiento multidominio, RLHF, calibración de conocimiento y matemáticas, y una etapa final de DPO sobre mil pares de preferencia on-policy construidos con las propias respuestas del modelo a intentos de inyección.

Ese es el punto que un founder debería retener: la regla de privilegio —instrucción vía bloque de ejecución manda, input se lee— es un comportamiento aprendido, no una garantía criptográfica. Un modelo entrenado para respetar esa jerarquía es más difícil de secuestrar, no imposible.

Conclusión

LLMON es una de esas ideas que parecen obvias después de leerlas: si el problema es que los modelos no distinguen órdenes de datos, dales un formato donde esa distinción sea explícita en el vocabulario. IBM la está probando en el extremo más difícil —modelos de 3B y 8B, donde la fragilidad es mayor— y con resultados que, si se sostienen fuera del laboratorio, cambian el cálculo de riesgo para cualquiera que despliegue agentes sobre contenido que no controla.

La lectura estratégica para una startup es doble. Primero, la separación estructural entre instrucciones y datos empieza a ser una decisión de arquitectura, no un parche de prompt: si tu stack depende de que el modelo «se dé cuenta» de qué parte del contexto es una orden, estás construyendo sobre un supuesto frágil. Segundo, el costo de migrar puede ser bajo —un template, un convertidor— y eso hace que valga la pena medirlo en tu propio caso de uso antes de que un cliente lo mida por ti.