¿Agentes de IA dentro de Revit?

Hay una pregunta que me hacen cada vez más desde que cuento lo que construimos en Vault: ¿y esto se puede hacer en Revit? La respuesta honesta es que todavía no lo he construido. Y justo por eso quiero escribir sobre ello ahora, antes de tener algo que mostrar, porque la diferencia entre una visión y un producto es algo que en el mundo de la IA se difumina con demasiada facilidad.

El camino ya lo recorrí una vez. Junto a Avant Leap construimos VaultPilot, un agente que opera Autodesk Vault desde lenguaje natural. Lo que aprendimos no fue cómo conectar un LLM a una API, que es la parte fácil. Fue cómo evitar que un sistema probabilístico escriba cosas equivocadas en datos de producción: dry-run antes de cada escritura, validación contra el esquema real del Vault, relectura después de escribir para confirmar que lo que la API dice que pasó realmente pasó, límites duros para operaciones irreversibles y una auditoría completa de cada acción.

La misma anatomía, otro producto

Cuando estudio la API de Revit veo una anatomía familiar: elementos, parámetros, transacciones. Un modelo con esquema propio, operaciones que modifican datos compartidos y un costo alto cuando algo se escribe mal. Es exactamente el tipo de entorno donde un agente puede leer muy bien y escribir muy mal.

Por eso creo que la receta viaja casi entera. Primero, el agente propone y el humano autoriza: en BIM, donde un modelo lo tocan muchas manos y alimenta planos, tablas y coordinación, una escritura automática sin supervisión es un riesgo que nadie debería aceptar. Segundo, validar contra el modelo real: un LLM es perfectamente capaz de inventarse un parámetro que no existe o una familia que suena plausible, y la única defensa es contrastar cada intención contra lo que el modelo de verdad contiene. Tercero, releer después de escribir: toda escritura es una afirmación que hay que probar, y la relectura es la prueba. Cuarto, límites duros: hay operaciones que un agente no debería poder ejecutar jamás, por diseño, sin importar cuánto insista el usuario.

Lo que cambia en BIM

Hay diferencias que me tomo en serio. Un modelo de Revit es un entorno de trabajo compartido en tiempo real, con worksets y sincronizaciones, y eso plantea preguntas de concurrencia que en un PDM con check-in y check-out están más contenidas. La transaccionalidad de Revit ayuda: las operaciones se agrupan y se pueden deshacer como unidad. Pero el radio de impacto de un cambio es distinto, porque un parámetro mal escrito puede propagarse a decenas de planos sin que nadie lo note hasta la impresión.

Todo eso es diseño por resolver, no un impedimento. Y se resuelve igual que en Vault: construyendo la compuerta antes de construir el agente.

Visión primero, caso real después

Lo que no voy a hacer es venderlo como si ya existiera. Estoy empezando a construir en Revit y decidí documentar el proceso en público: qué funciona, qué no, y qué aprendizajes del mundo de la manufactura se trasladan al mundo BIM. Cuando haya un caso real, lo contaré con datos. Mientras tanto, lo que hay es esto: una receta probada en otro producto y la convicción de que las compuertas importan más que las capacidades.

Si trabajas en BIM y hay un flujo de Revit que le darías a un agente mañana mismo, me interesa conocerlo. Los primeros casos reales siempre nacen de una conversación.