VaultPilot · 7 de septiembre de 2026 · Jose Luis Baquero Rivera

Mi agente se niega a hacer ciertas cosas (y eso es una feature)

Mi agente se niega a hacer ciertas cosas (y eso es una feature)

Mi agente le dijo que no a mi propio cliente. La solicitud estaba bien escrita, la intención era buena, y la respuesta fue una negativa con su explicación. Es una de las funciones de las que más orgulloso estoy.

Agentes que obedecen demasiado

La conversación sobre agentes de IA suele girar alrededor de lo que pueden hacer: cuántas herramientas tienen, cuántos pasos encadenan, qué tan bien entienden una instrucción ambigua. Casi nadie hace la pregunta contraria: qué se niegan a hacer. Y en un PDM esa es la pregunta importante, porque una escritura equivocada no se queda quieta. Viaja a la BOM, al ERP y a producción. Y Vault no tiene deshacer masivo: cero operaciones de ese tipo existen.

VaultPilot, el agente que construimos junto a Avant Leap para Autodesk Vault, nació con esa pregunta en el centro. Tiene límites duros: operaciones que no ejecuta aunque el usuario insista con las palabras correctas. Borrados masivos, escrituras fuera del alcance acordado, cambios sin un dry-run previo que muestre exactamente qué va a pasar.

Dos meses de negativas, en números

Durante el desarrollo llevamos un log de todo lo que el agente hizo y de todo lo que se negó a hacer. Los números que siguen salen de ese log (del 14 de mayo al 14 de julio de 2026, una sola instancia contra Vault Professional 2026): no son una tasa de éxito en producción, son la radiografía de un sistema en construcción.

La primera compuerta rechazó 45 solicitudes en dos meses. Además, 80 escrituras se detuvieron en una compuerta antes de tocar datos: 45 por el anclaje de identidad y 35 por el interruptor de solo lectura. Y 23 veces la API devolvió éxito y la relectura posterior lo desmintió: sin verificación de escritura, habrían sido 23 mentiras silenciosas en el historial.

Cada una de esas negativas es un incidente que no ocurrió.

Qué hace cada "no"

Puedo contar qué hace cada compuerta, no cómo está implementada. El dry-run muestra el efecto de una operación antes de ejecutarla y exige confirmación explícita. La validación contra el esquema real del Vault impide operar sobre propiedades que el modelo cree recordar pero no existen. La verificación de escritura relee después de escribir, porque toda escritura es una afirmación y la relectura es la prueba. Los límites duros dejan ciertas operaciones fuera del alcance del agente, sin importar el prompt. Y la auditoría deja rastro de todo, incluidas las negativas.

Hay una capa más: cada chat corre con las credenciales del propio usuario. Si tú no puedes borrar un archivo en Vault, el agente tampoco puede hacerlo por ti. No hay backdoor de administrador.

La pregunta para tu próximo proveedor

Si estás evaluando agentes que escriben en tus datos, no preguntes solo qué pueden hacer. Pide la lista de lo que se niegan a hacer, y cómo lo registran. Un agente que ejecuta todo lo que le pides no es potente: es un riesgo con buena interfaz.

Mi regla desde el día uno no ha cambiado: construye la compuerta antes de construir el agente.

¿Tienes un proceso que te roba horas dentro de tus productos Autodesk?

Cuéntamelo y te digo con honestidad si necesita IA, una automatización clásica o algo más simple. Sin humo.

← Volver al blogEste artículo también circula en LinkedIn.