Automatizar Revit con Dynamo e IA: un flujo, tres niveles de control
El grafo funcionaba de maravilla en la demostración. Leía habitaciones, comprobaba nombres y departamentos, coloreaba los errores y exportaba una tabla. Después lo ejecutaron sobre el modelo del proyecto: encontró habitaciones sin cerrar, valores escritos de cuatro formas distintas, fases mezcladas y una columna de Excel que alguien había renombrado «para que se entendiera mejor». Dynamo respondió con una elegante colección de nodos amarillos.
Automatizar Revit exige algo más que conectar una entrada con una salida. Hay que decidir qué datos aceptar, qué condiciones comprobar, qué cambios permitir y cómo explicar un fallo. Dynamo, Python y la IA pueden participar en ese recorrido, pero no ocupan peldaños de una escalera tecnológica. Cada uno resuelve una parte distinta y hereda una responsabilidad diferente.
Tabla de contenidos
El error no estaba en el nodo amarillo
La primera versión asumía que todas las habitaciones estaban colocadas, tenían nombre y pertenecían a una fase concreta. Filtraba elementos, leía parámetros y comparaba valores con una tabla. En el modelo de prueba, esas condiciones se cumplían. En producción, los datos representaban decisiones aún abiertas, restos de fases y criterios que varias personas interpretaban de forma distinta.
El equipo dejó de reparar nodos y escribió el propósito: detectar habitaciones relevantes para la entrega cuyo nombre, departamento o código no cumpliese las reglas. «Relevantes» necesitaba definición. Se excluyeron esquemas, fases antiguas y elementos sin área cuando correspondía; las habitaciones no cerradas se trataron como una condición específica, no como una lista vacía.
También se definió qué podía corregirse. Normalizar espacios o mayúsculas era reversible y verificable. Elegir el departamento correcto requería contexto de proyecto. La primera automatización leería y propondría; solo aplicaría cambios seguros después de una confirmación.
La entrada dejó de ser una promesa
La tabla de referencia recibió un esquema: columnas obligatorias, nombres estables, tipos de dato y versión. El flujo validaba el archivo antes de consultar Revit. Si faltaba Código o aparecían duplicados, detenía la ejecución con un mensaje comprensible. Intentar continuar habría distribuido el problema con admirable eficiencia.
Dentro del modelo, cada parámetro se localizaba de forma explícita. El equipo distinguió parámetros de tipo e instancia, valores visibles e identificadores internos, y comprobó que el elemento perteneciese al documento esperado. Un nodo que devuelve texto no garantiza que el texto signifique lo mismo en todas las familias o versiones.
Los datos se transformaban a una estructura intermedia: identificador, nombre, departamento, código, fase y estado geométrico. A partir de ahí, las reglas no necesitaban conocer la interfaz de Dynamo ni modificar Revit. Esta separación parecía una complicación hasta que permitió probar cien casos sin abrir un proyecto.
Dynamo conservó la conversación con el equipo BIM
La lógica visual seguía siendo útil para seleccionar alcance, mostrar relaciones y ajustar el prototipo con quienes conocían el modelo. Un coordinador podía seguir cómo se obtenían habitaciones y cómo se clasificaban resultados. La representación hacía visibles decisiones que, en un script monolítico, habrían quedado escondidas tras nombres de funciones.
El grafo se reorganizó en etapas: entrada, validación, lectura, evaluación, previsualización y ejecución. Los grupos y nombres describían intención, no una sucesión de «List.Map» y «Code Block». Las rutas y nombres de proyecto salieron del archivo. Un grafo compartido no debería necesitar que cada usuario visite tres nodos secretos antes de pulsar ejecutar.
Dynamo no tenía que absorber toda la complejidad. Cuando las reglas y mensajes crecieron, mantener decenas de conexiones empezó a ocultar el proceso. La solución no fue declarar obsoleta la programación visual, sino dejarle la orquestación y mover la lógica que necesitaba pruebas más finas.
Python entró para separar reglas de transacciones
El módulo de Python recibía datos simples y devolvía resultados: correcto, advertencia, bloqueo y corrección propuesta. Cada regla incluía código, explicación y evidencia. Al no escribir en el modelo, podía ejecutarse sobre casos preparados y producir siempre la misma respuesta.
Otra capa traducía las correcciones aprobadas a operaciones de la API de Revit. Antes de abrir una transacción, mostraba cuántos elementos cambiarían, qué parámetros y cuáles eran los valores anterior y propuesto. El usuario podía excluir elementos o cancelar.
Las modificaciones se agruparon con una estrategia clara. Si una precondición crítica fallaba, no se escribía nada. Si un elemento concreto estaba bloqueado, el resultado indicaba el fallo sin presentar el conjunto como éxito. La transacción no era un detalle técnico: definía qué podía quedar a medias y cómo recuperarlo.
La vista previa cambió la relación con la herramienta
El informe dejó de ser una tabla final y pasó a ser el centro del flujo. Permitía filtrar reglas, localizar habitaciones y revisar propuestas. Una fila incluía modelo, elemento, parámetro, valor encontrado, condición esperada y acción posible. «32 errores» se convirtió en una lista que podía resolverse.
Los cambios automáticos se limitaron a normalizaciones acordadas. Para valores ambiguos, el usuario elegía entre opciones válidas o devolvía la incidencia al responsable. Esta decisión evitó que el sistema completase datos solo para conseguir un dashboard verde.
Después de ejecutar, se volvía a leer el modelo y verificar el resultado. El informe diferenciaba solicitado, aplicado y confirmado. Revit podía rechazar un cambio por permisos, grupos, diseño o estado del documento; asumir que una llamada sin excepción equivale a una entrega correcta era demasiado optimista.
La IA encontró un lugar bastante menos heroico
Los usuarios escribían departamentos como «Administración», «Admin.» o «Zona administrativa». Parte de esa variación podía resolverse con un diccionario. Para descripciones nuevas, el equipo probó una IA que proponía correspondencias con el catálogo y mostraba su evidencia. La propuesta nunca se escribía directamente en Revit.
La IA también ayudaba a agrupar mensajes de incidencia y resumir patrones: muchos errores podían proceder de una misma plantilla o importación. El resultado servía para priorizar una investigación. Las reglas deterministas seguían validando si el valor final pertenecía al catálogo.
Cuando la confianza era baja, aparecían varias opciones o se pedía revisión. Las entradas y salidas se registraban sin exponer información innecesaria, y el equipo podía desactivar el servicio. Si la IA no estaba disponible, el control de habitaciones continuaba funcionando. Un asistente no debía convertirse en el interruptor general de la oficina.
La IA no recibió una transacción abierta
Permitir que un modelo generativo decidiese acciones y las ejecutase sobre cientos de elementos habría mezclado interpretación probabilística con escritura de alto impacto. El equipo mantuvo una frontera: la IA proponía texto o clasificación; una regla comprobaba la propuesta; una persona confirmaba cuando existía ambigüedad; y una capa determinista escribía.
Esta cadena podía parecer conservadora, pero hacía posible explicar un cambio. Si una habitación terminaba en un departamento, se conocían valor original, propuesta, catálogo, aprobador y ejecución. La trazabilidad importaba más que ahorrar el último clic.
Para tareas reversibles y de bajo riesgo se podía reducir la intervención. Para nombres que alimentaban mediciones, entregas o sistemas externos, el control aumentaba. Automatizar Revit no exige el mismo permiso para colorear una vista temporal que para alterar parámetros contractuales.
Las pruebas empezaron con los casos desagradables
El equipo preparó habitaciones correctas, sin cerrar, redundantes, en fases excluidas, con parámetros ausentes, valores nulos y caracteres inesperados. También incluyó documentos vinculados y elementos en grupos. Los resultados esperados formaban parte de las pruebas.
La capa de reglas se verificaba sin Revit; la lectura y escritura necesitaban modelos controlados. Cada actualización de la aplicación o de Dynamo ejecutaba un conjunto mínimo antes de distribuirse. Los catálogos de valores tenían su propia versión.
La IA se evaluaba con ejemplos históricos revisados y una categoría «no sé». No bastaba con mostrar aciertos bonitos. Se observaban propuestas incorrectas, cambios al actualizar el modelo y coste de revisión. Si el asistente no reducía trabajo o introducía riesgo, volvía al banquillo.
Distribuir el flujo añadió una responsabilidad nueva
Mientras lo utilizaba una persona, bastaba con un paquete documentado. Al crecer usuarios, aparecieron versiones divergentes, dependencias y configuraciones locales. El equipo creó un canal de distribución, registró la versión ejecutada y evitó guardar archivos modificables en escritorios.
Los permisos se ajustaron. Cualquier modelador podía ejecutar el diagnóstico; aplicar cambios masivos requería un rol y un modelo editable. Los catálogos corporativos tenían propietario. Los proyectos podían ampliar configuraciones sin alterar las reglas comunes.
Los mensajes de error incluían siguiente acción y un identificador para soporte. «Object reference not set» se reservó para conversaciones internas entre máquinas, donde quizá alguien lo aprecie.
El mantenimiento decidió qué tecnología sobrevivía
Se midieron ejecuciones, tiempo humano, falsos positivos, fallos y solicitudes de soporte. Algunas reglas cambiaban con el BEP; otras permanecían estables. La arquitectura permitía actualizar el catálogo sin tocar el lector de Revit y ajustar mensajes sin reescribir la transacción.
Dynamo continuó como interfaz y espacio de prototipo en algunos equipos. Python sostuvo reglas y servicios comunes. Cuando distribución, permisos y compatibilidad necesitaron una integración más formal, ciertas funciones pasaron a una aplicación sobre la API. No fue una graduación obligatoria, sino una respuesta al alcance.
La IA permaneció acotada. Su modelo, coste y comportamiento podían cambiar, de modo que no se convirtió en dependencia de controles críticos. El mantenimiento incluía revisar si seguía aportando más que un buen diccionario.
Cuándo dejar la tarea manual
Si la clasificación dependía de interpretar una decisión de diseño aún abierta, la herramienta reunía candidatos y contexto, pero no elegía. Si una regla variaba en cada proyecto, primero se intentaba formalizar el proceso. Automatizar una ambigüedad solo la vuelve más difícil de localizar.
Las tareas poco frecuentes, de bajo volumen o con consecuencias difíciles de verificar podían mantenerse manuales. También aquellas donde preparar datos costaba más que resolver el caso. El objetivo no era usar todas las tecnologías disponibles, sino reducir trabajo sin perder control.
Una automatización parcial podía ser suficiente: detectar habitaciones dudosas y llevar al usuario hasta ellas ya eliminaba buena parte de la revisión mecánica. No hacía falta corregirlo todo para demostrar valor.
Un flujo, varias capas de control
El grafo terminó funcionando sobre modelos menos educados que el de la demostración. No porque Dynamo hubiese aprendido a adivinar, sino porque el equipo definió entradas, aisló reglas, añadió vista previa, controló transacciones y diseñó fallos comprensibles. Python y la API asumieron responsabilidades donde aportaban estructura.
La IA encontró un papel útil al interpretar y agrupar, siempre detrás de una frontera de validación. No gobernaba el modelo ni sustituía el catálogo. El flujo podía continuar sin ella y explicar cada modificación.
Para automatizar Revit, empieza por una decisión repetida y por los datos reales que intentarán estropearla. Elige la herramienta después, separa leer de escribir y diseña la revisión humana en función del riesgo. Si todo funciona únicamente con la tabla perfecta, no has terminado el desarrollo: solo has terminado la demo.
Respuestas