Por qué los LLM inventan propiedades de Vault (y cómo se corrige)

Pídele a un modelo de lenguaje que trabaje con las propiedades de un archivo en Vault y observa lo que pasa. Responde rápido, con seguridad absoluta, y con una lista impecable de propiedades. El problema aparece cuando comparas esa lista contra tu Vault real: varias de esas propiedades no existen. Nunca existieron.

No es un bug, es la naturaleza del modelo

La reacción típica es pensar que el modelo falló. Pero un LLM no consulta tu servidor: completa patrones. Durante su entrenamiento vio miles de sistemas PDM, documentación, foros y ejemplos de código. Si en ese universo la propiedad Estado de aprobación aparece con frecuencia, el modelo te la va a ofrecer con total naturalidad, aunque tu Vault jamás la haya tenido.

Visto así, el comportamiento es coherente: el modelo hace exactamente aquello para lo que fue construido. Predecir lo probable. Lo probable y lo verdadero coinciden muchas veces. En un PDM de producción, muchas veces no es suficiente.

Dónde se vuelve peligroso

Mientras el modelo solo conversa, la propiedad inventada es una anécdota. El riesgo aparece cuando el agente tiene permiso de escritura. Escribir en una propiedad que no existe, o peor, crear un valor con el tipo de dato equivocado en una propiedad parecida, convierte una alucinación estadística en datos corruptos dentro del sistema que gobierna tu producto.

Y hay una trampa adicional: los errores de este tipo no explotan de inmediato. Se descubren semanas después, cuando un reporte sale vacío o una liberación se bloquea, y para entonces nadie recuerda qué operación los introdujo.

La corrección es estructural, no de prompt

La primera tentación es escribir un mejor prompt: dile al modelo que no invente. Ayuda poco. La memoria del modelo no distingue entre lo que vio en tu Vault y lo que vio en internet. La corrección real está fuera del modelo, en la arquitectura del agente.

En VaultPilot, que construimos junto a Avant Leap, funciona así: cada operación que menciona una propiedad se valida contra el esquema real del Vault antes de ejecutarse. Se comprueba que la propiedad exista, que el tipo de dato coincida y que el usuario tenga permiso sobre ella. Si algo no cuadra, la operación no llega ni al dry-run: se detiene con un mensaje claro de qué no existe y qué alternativas reales hay.

El modelo sigue siendo libre de proponer. El esquema decide qué propuestas son reales. Esa división del trabajo es la que convierte un LLM en una herramienta de ingeniería.

La regla general, más allá de Vault

Este patrón aplica a cualquier sistema donde un agente de IA toque datos que importan: nunca dejes que el modelo defina la realidad. La realidad la define el esquema, la API o la base de datos, y el modelo se adapta a ella. Cuando evalúes cualquier herramienta de IA para ingeniería, pregunta exactamente esto: contra qué valida sus operaciones antes de ejecutarlas. Si la respuesta es el propio modelo, no la dejes cerca de producción.

¿Te ha pasado que una IA te inventa campos, funciones o propiedades con total confianza? Me interesa el caso: escríbeme y lo conversamos.