Automatizar Revit con Dynamo e IA: reglas y revisión

El grafo lee habitaciones y colorea resultados con una soltura admirable. Entonces llega el modelo del proyecto: fases mezcladas, departamentos con cuatro nombres y una columna titulada «Código bueno». Aparecen nodos amarillos y alguien propone añadir IA para arreglarlos. Una respuesta ambiciosa al problema de no haber definido los datos. Yo empezaría dando las gracias a los nodos: al menos tienen la decencia de avisar de que algo no encaja.

Automatizar Revit exige decidir qué datos se aceptan, qué condiciones se comprueban y qué cambios se permiten. Dynamo, Python y una IA pueden participar, pero no forman una escalera en la que cada tecnología vuelve obsoleta a la anterior. Vamos a diseñar un caso hipotético de revisión de habitaciones para ver qué responsabilidad conviene dar a cada capa y cómo conservar el control cuando los datos se parecen más a un proyecto real que a una demostración.

Define el alcance antes de intentar arreglar los nodos

La tarea del ejemplo consiste en revisar nombres, departamentos y códigos de las habitaciones incluidas en una entrega. Para empezar necesitamos definir cuáles son esas habitaciones. Fase, documento y condiciones de inclusión forman parte del requisito; también el tratamiento de habitaciones no colocadas o no cerradas. Si una lista queda vacía porque faltan datos para seleccionar, no debería confundirse con un modelo sin incidencias. Una automatización útil debe explicar tanto lo que ha revisado como lo que no ha podido revisar.

La tabla de referencia requiere un acuerdo parecido: columnas estables, tipos y valores permitidos. Si falta una columna o se repite una clave que debería ser única, el flujo debe señalarlo antes de proponer cambios. Continuar escogiendo el primer valor que encuentre puede producir resultados con un aspecto excelente y un origen indefendible. Las hojas de cálculo son una interfaz estupenda mientras no les pidamos que mantengan un contrato que nunca hemos definido.

Conviene separar observaciones y decisiones. Un departamento con espacios sobrantes puede admitir una normalización acordada. Un texto «Administración o dirección» necesita saber qué significa esa habitación en el proyecto. No es el mismo problema. La primera versión puede limitarse a recoger datos y mostrar candidatos; conseguir que alguien llegue rápidamente a los casos dudosos ya elimina trabajo mecánico sin inventar información.

Guarda una estructura intermedia con identidad del elemento, valores leídos, fase y datos necesarios para evaluar. A partir de ahí, la regla puede trabajar con información simple y devolver un resultado. Esa separación permite probar casos sin abrir Revit y comparar lo que recibió la regla con lo que existía en el modelo. Cuando todo ocurre dentro de un nodo que devuelve «error», la primera tarea del mantenimiento consiste en descubrir qué tarea estaba haciendo.

Utiliza Dynamo para hacer visible el recorrido

La programación visual ayuda a seguir cómo se seleccionan elementos, se transforman datos y se conectan operaciones. La introducción del Dynamo Primer explica esa forma de expresar programas mediante nodos y conexiones. En nuestro flujo conviene que los grupos describan etapas comprensibles: entrada, lectura, evaluación y revisión. Si para entender el grafo hay que perseguir una conexión por tres pantallas, la representación visual está perdiendo parte de su ventaja.

Los parámetros de entrada deberían corresponder a decisiones que el usuario pueda tomar: documento, fase, tabla o conjunto de habitaciones. Rutas particulares y nombres de proyecto escondidos en varios nodos convierten el uso compartido en una búsqueda del tesoro. También conviene mostrar recuentos y estados intermedios. Saber que se han leído cien habitaciones y solo cuarenta entran en alcance orienta bastante más que recibir una tabla final sin saber qué pasó con las demás.

Cuando crecen las reglas, sus excepciones y los mensajes, Python puede ayudar a reunir esa lógica en funciones comprobables. No es obligatorio trasladar todo el grafo ni introducir código para demostrar madurez. La pregunta es qué parte resulta más fácil de entender y mantener en cada representación. Una regla pequeña puede funcionar perfectamente con nodos; una colección de decisiones repetidas quizá necesite otra organización.

Conserva las versiones de Revit, Dynamo, motor Python y paquetes que utiliza el flujo. La guía de desarrollo de Dynamo muestra la integración de Python y Revit, pero un fragmento debe contrastarse con el entorno donde se ejecuta. Que dos nodos tengan Python en el nombre no demuestra que compartan todas las dependencias y comportamientos. La compatibilidad merece algo más que esperanza visual.

Da a la IA una pregunta acotada y una salida revisable

En el catálogo del ejemplo existen departamentos aprobados. Muchas variantes, como abreviaturas conocidas, pueden resolverse con un diccionario mantenido por el equipo. No hay motivo para consultar una IA cada vez que aparece Admin. si el acuerdo ya establece su correspondencia. Los sistemas deterministas tienen una ventaja poco vistosa: repiten una decisión sin reinterpretarla en cada ejecución. Conviene aprovecharla antes de contratar creatividad para un problema de equivalencias conocidas.

La IA podría ayudar ante una descripción nueva, proponiendo candidatos del catálogo y explicando qué información utiliza. Esa propuesta debería mostrarse junto al texto original y permitir que una persona la revise. Si no hay contexto suficiente, el flujo necesita admitir que no puede recomendar una opción. Una etiqueta de confianza no convierte una elección en un hecho del proyecto; hay que observar sus errores con ejemplos revisados antes de darle utilidad operativa.

La salida debe validarse: que la opción exista en el catálogo, que corresponda al conjunto permitido y que conserve la relación con la habitación consultada. Un resultado bien formado todavía puede ser semánticamente incorrecto. Por eso la evaluación debería incluir descripciones ambiguas, valores desconocidos y casos donde la respuesta adecuada es abstenerse. Mostrar únicamente aciertos bonitos acredita capacidad para preparar una demo, una disciplina con bastante competencia.

Si se utiliza un servicio externo, comparte solo la información autorizada y necesaria para esa tarea. El control determinista debería poder seguir informando cuando ese servicio falle o no esté disponible. En este artículo no se ha ejecutado esa integración ni se atribuyen aciertos a un modelo concreto: se describe el diseño de un flujo que habría que probar. La IA ayuda a interpretar; todavía hace falta decidir quién acepta la propuesta y cómo se conserva esa decisión.

Convierte una propuesta aceptada en un cambio controlado

Antes de modificar Revit, el usuario debe poder revisar el elemento, el parámetro, el valor actual y el propuesto. También debe quedar claro qué partes se pueden excluir o cancelar. Para la habitación ambigua, aceptar un departamento es una decisión del proyecto; la operación de escritura viene después. Mezclar ambas dentro de una respuesta generada dificulta explicar por qué terminó un valor concreto en el modelo.

La capa que aplica cambios tiene que comprobar de nuevo las precondiciones: que el elemento siga existiendo, el parámetro sea editable y el valor actual coincida con el observado cuando corresponda. El modelo puede cambiar entre revisión y ejecución. Si alguien ha corregido ya una habitación, sobrescribirla con una propuesta antigua no es automatización eficiente; es una forma muy aplicada de deshacer trabajo ajeno.

Las modificaciones requieren el contexto de escritura adecuado. La documentación de transacciones de Revit establece que los cambios del documento se realizan en una transacción activa y describe restricciones relevantes. El flujo debe decidir qué ocurre si un elemento no puede cambiarse: abortar el conjunto o permitir resultados parciales, según su propósito. Esa decisión necesita reflejarse en el informe, no quedar escondida en el último mensaje de un nodo.

Después hay que volver a leer y comprobar. Distingue propuesto, solicitado, aplicado y verificado; una intención aceptada no demuestra su efecto. Conserva el resultado con la versión del catálogo y la herramienta. Si aparecen cambios parciales, el usuario debe saber cuáles se confirmaron y cuáles necesitan intervención. Cuanto más fácil resulte ejecutar sobre muchos elementos, más útil será poder explicar cada resultado sin reconstruir la conversación completa.

Prueba con modelos incómodos antes de distribuir

Prepara habitaciones correctas, datos ausentes, fases excluidas y valores que no pertenecen al catálogo. Añade un cambio de la tabla y una propuesta que ya no coincide con el valor actual del modelo. La lógica de reglas puede probarse con datos simples; la lectura y escritura requieren modelos controlados y el entorno de ejecución real. Pasar las primeras pruebas no acredita las segundas, aunque el informe se pueda generar fuera de Revit.

Al compartir el flujo aparecen tareas de distribución y soporte: reconocer qué versión se ejecutó, mantener paquetes y comunicar cambios de las reglas. No todos los usuarios necesitan editar el grafo, pero sí entender qué selecciona, qué puede modificar y qué hacer ante un fallo. Un mensaje útil señala la etapa y el siguiente paso; «Object reference not set» puede conservarse para el diagnóstico técnico sin convertirse en la explicación de negocio.

Evalúa si la solución reduce trabajo humano después de contar revisión y mantenimiento. Puede que el diccionario resuelva casi todos los casos y la IA no compense; puede que Dynamo sea suficiente o que una función necesite otra forma de distribución. No hay obligación de utilizar todos los componentes del título. La arquitectura debe permitir retirar una pieza que no aporte valor sin desmontar la revisión completa.

El flujo útil deja claro qué ha leído, qué regla ha aplicado y por qué un caso necesita revisión. La IA puede ayudar donde exista una pregunta interpretativa; no tiene por qué convertirse en el servicio de limpieza de un catálogo abandonado. Si tu automatización se rompe siempre en la misma entrada, trae ese ejemplo a los comentarios. Quizá la siguiente mejora no necesite otro nodo.