Integrar IA generativa en herramientas de Diseño Generativo: qué funciona de verdad

¿Te imaginas ejecutar inteligencia artificial generativa directamente dentro de Grasshopper o Dynamo, interactuando con tu modelo BIM mediante lenguaje natural?

No hablo de exportar datos, procesarlos en ChatGPT y volver a pegarlos a mano. Hablo de que el modelo de lenguaje viva dentro de la definición paramétrica: que lea el modelo, razone sobre él y escriba de vuelta. Eso hoy es posible con dos ingredientes que ya tienes a mano: un componente de Python dentro de tu herramienta de diseño generativo y una API de IA.

Lo que sigue es un mapa de los tres niveles de integración que existen, qué resuelve cada uno y dónde se rompen.

Por qué el visual programming es el sitio adecuado

Grasshopper y Dynamo ocupan una posición rara y privilegiada: son suficientemente abiertos como para ejecutar código arbitrario (Python, C#), y suficientemente cerrados como para tener acceso directo y estructurado al modelo. Puedes leer cada elemento, cada parámetro, cada relación geométrica, y puedes escribir de vuelta.

Un LLM, por sí solo, no sabe nada de tu proyecto. Lo que hace que la combinación funcione es que el entorno paramétrico aporta exactamente lo que al modelo le falta: contexto real y capacidad de actuar. Y el modelo aporta lo que al entorno paramétrico le falta: interpretación de lenguaje natural y criterio sobre datos poco estructurados.

Esa división del trabajo es la idea central de todo lo que viene a continuación.

Nivel 1: El modelo como generador de contenido

El planteamiento más simple, y el más rentable a corto plazo: un componente de script recoge datos del modelo, los envía al LLM con un prompt, y la respuesta se mapea de vuelta a parámetros.

Casos típicos:

• Documentación automática. Generar descripciones de elementos, memorias de calidades o textos de pliego a partir de los parámetros reales del modelo, en vez de copiar y pegar de proyectos anteriores.
• Normalización de datos. Un modelo heredado con nomenclatura inconsistente ("MURO EXT", "M.Exterior", "muro_ext_01") se puede homogeneizar pidiendo al LLM que clasifique cada cadena contra una lista cerrada de categorías.
• Traducción y multi-idioma. Trivial de implementar, y sorprendentemente útil en proyectos internacionales.
• Extracción desde documentos. Leer un PDF de requisitos del cliente y sacar de ahí valores que alimentan parámetros del modelo.

Es el nivel más básico y el que más horas ahorra. La clave está en pedir la salida en JSON con un esquema definido y validarla antes de tocar nada del modelo. Si el LLM devuelve prosa libre, has trasladado el problema en vez de resolverlo.

Nivel 2: El modelo como copiloto de la definición

Aquí el LLM ya no procesa datos del proyecto: escribe el código que después procesará esos datos.

En la práctica, esto significa pedirle que genere el contenido de un componente de Python o C#, que resuelva una transformación geométrica que no te sale, o que te explique qué hace una definición ajena que has heredado y nadie documentó. Es el uso que más gente hace ya de forma natural, aunque sea copiando y pegando desde una ventana de chat en el otro monitor.

La diferencia entre hacerlo bien y hacerlo mal está en el contexto que le das. Un LLM al que le pides "un script que agrupe elementos por nivel" te devolverá algo genérico y probablemente desactualizado respecto a la versión de la API que usas. El mismo LLM, si le pasas la firma de los objetos con los que trabajas y un ejemplo de tu propio código, acierta mucho más.

Nivel 3: El modelo como agente con herramientas

Aquí está el salto interesante, y el que casi nadie está explotando todavía en nuestro sector.

En lugar de que el LLM devuelva texto que tú interpretas, le expones un conjunto de funciones que puede invocar: listar_elementos_por_categoria, leer_parametro, modificar_parametro, crear_vista, comprobar_colision. El modelo recibe una instrucción en lenguaje natural, decide qué funciones llamar y en qué orden, lee los resultados y continúa hasta terminar.

La diferencia práctica: en el nivel 1 tú diseñas el flujo completo y el LLM rellena un hueco. En el nivel 3 el LLM diseña el flujo dentro de los límites de las herramientas que le has dado.

Esto habilita cosas que antes requerían una definición a medida por cada caso: auditorías de modelo formuladas en lenguaje natural, ediciones masivas condicionales ("cambia el acabado de todos los muros de la fachada norte que den a una estancia húmeda"), o generación de variantes conceptuales donde el criterio de variación no es puramente numérico.

También es donde más fácil es hacerse daño, lo que nos lleva directamente a la siguiente sección.

Dónde se rompe todo esto

Si solo te llevas una sección del artículo, que sea esta.

El modelo no entiende geometría. Razona sobre la descripción textual de la geometría, no sobre la geometría. No sabe si dos elementos colisionan, si una pendiente evacúa o si un forjado es viable. Toda comprobación geométrica tiene que hacerla código determinista y devolvérsela como dato.

Alucina nombres de parámetros. Con una fluidez notable. Si le pides que modifique un parámetro y no validas contra la lista real de parámetros del elemento, escribirá en un sitio equivocado o fallará silenciosamente. La lista de parámetros válidos debe ir en el contexto, y la escritura debe validarse contra ella.

El no determinismo choca con el modelo BIM. Un modelo BIM es un registro de proyecto: la misma entrada debería producir la misma salida, y cada cambio debe ser trazable. Un LLM no garantiza ninguna de las dos cosas. Esto no lo invalida, pero obliga a diseñar el sistema asumiéndolo.

La latencia mata la iteración masiva. Una llamada por elemento sobre un modelo de diez mil elementos no es un flujo de trabajo, es una noche entera. Hay que agrupar, cachear y usar el LLM una vez para generar una regla, y aplicar la regla con código.

El coste es real. Modesto por llamada, considerable dentro de un bucle sobre un modelo grande. Conviene estimarlo antes, no después.

Cinco reglas de diseño

1. El LLM decide qué, el código hace cómo. Toda operación que toque el modelo pasa por una función determinista y validada.
2. Salida estructurada siempre. JSON con esquema, validación antes de escribir. Nada de parsear prosa.
3. Dry-run por defecto. El flujo propone los cambios, los muestra, y solo escribe tras confirmación. Especialmente en ediciones masivas.
4. Trazabilidad. Registra qué se cambió, qué instrucción lo originó y qué modelo lo generó. Sin esto no hay auditoría posible del proyecto.
5. Humano en el bucle donde importa. No en todo, sino en los puntos que se requiere validación y feedback..

Qué perfil hace falta

No un data scientist. Alguien que domine el modelo BIM y su lógica, y que tenga la soltura suficiente en Python para escribir la capa de validación y las funciones que el modelo va a invocar. El cuello de botella nunca ha sido saber de IA: es saber qué tiene sentido automatizar en un flujo de proyecto real y qué no.

Esa combinación —criterio de proyecto más capacidad de escribir la capa que conecta— es hoy uno de los perfiles más difíciles de encontrar en el sector. Y es exactamente donde se está abriendo el hueco.