Autodesk University · 16 de septiembre de 2026 · Jose Luis Baquero Rivera

Los números que llevo al escenario de AU 2026

Los números que llevo al escenario de AU 2026

Mañana a las 4:30 PM presento MFG3731, Vault on Autopilot, en Autodesk University. Y en lugar de guardar el material para la sala, quiero dejar por escrito los números que sostienen la sesión, porque son la parte que más trabajo costó y la que menos se parece a una charla de IA típica.

Vienen de nuestro log de desarrollo: dos meses de trabajo, del 14 de mayo al 14 de julio de 2026, contra una instancia de Vault Professional 2026. No son una tasa de éxito en producción y no pretenden serlo. Son lo que pasa de verdad cuando construyes un agente que escribe en un PDM.

Los cuatro números

249 llamadas llegaron a Vault. Durante ese periodo el agente invocó 45 operaciones distintas desde lenguaje natural: buscar, cambiar estados, asignar propiedades, exportar BOM, generar reportes. Cada llamada es una intención del usuario convertida en una operación concreta contra el servidor.

150 quedaron verificadas contra el servidor: el 60%. Verificada significa que después de ejecutar, el agente releyó el dato en Vault y confirmó que el resultado coincidía con lo prometido. Ese es el estándar que le exigimos: no reportar lo que hizo, sino demostrar lo que quedó.

80 escrituras fueron detenidas por una compuerta antes de tocar datos. 45 por el anclaje de identidad y 35 por el interruptor de solo lectura. Cada una de esas 80 era una escritura que un agente sin controles habría ejecutado.

23 veces la API devolvió éxito y la relectura lo desmintió. Este es el número que más me importa. Si tu integración confía en el código de retorno, esas 23 operaciones vivirían hoy en tu Vault como datos correctos que no lo son.

Lo que significan juntos

El 60% no es un número para presumir; es un número para confiar. Un proveedor que solo enseña demos perfectas no te está enseñando el sistema: te está enseñando el ensayo. Los sistemas de verdad fallan, y la pregunta correcta no es si fallan, sino si el fallo llega a tus datos o muere en una compuerta.

El contexto que les da sentido

Estos números no viven solos. En campo hemos observado equipos donde cada ingeniero gasta entre 3 y 8 horas semanales en operaciones repetitivas de PDM, y auditar a mano un ensamble de 25 piezas antes de liberarlo toma entre 18 y 25 minutos. Vault, además, no tiene deshacer masivo: una operación en lote mal hecha no se revierte con un botón. Ese es el terreno donde un agente aporta valor real, y también la razón por la que no puede operar sin compuertas.

Por eso la sesión no gira alrededor de la demo, sino del contrato: toda escritura es una afirmación, y la relectura es la prueba. Eso es lo que defiendo mañana en Las Vegas.

Y por eso también publico los números antes de presentarlos, y no después. Si mi argumento es que un agente debe demostrar lo que hace en lugar de pedir confianza, lo mínimo es aplicarme el mismo estándar: aquí está el log, con sus fallos incluidos, para que cada quien juzgue con evidencia y no con una demo bien ensayada.

¿Un agente debería tocar tu Vault?

Cuéntame cómo trabaja tu equipo y te digo con honestidad qué automatizaría primero y qué compuertas exigiría antes de escribir un solo dato.

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