Automatización en arquitectura: BIM, IA y operación

Una sala está fría, otra se climatiza vacía y el panel enseña un edificio tridimensional impecable. Encima pone «inteligente», así que la calefacción debe de estar a punto de comprenderlo. Me impresiona lo bien que puede presentarse una integración que todavía no conecta una lectura con una acción útil. BIM, sensores e IA pueden aportar a la operación de un edificio, pero antes necesitamos saber qué dato corresponde a qué espacio y quién hará algo cuando indique un problema.

La automatización en arquitectura puede conectar decisiones de diseño, información BIM y datos de operación. Para hacerlo con criterio hay que separar qué sabemos del edificio, qué estamos midiendo y qué acciones estamos autorizados a ejecutar. Seguiremos un caso hipotético de climatización de unas oficinas: desde las alternativas de proyecto hasta el trabajo de mantenimiento. Nos servirá para situar las reglas, los sensores y la IA donde aportan, sin atribuirles ahorros ni capacidades que todavía habría que comprobar.

Automatizar una decisión de diseño que puedas explicar

Durante el proyecto podríamos explorar protecciones solares para las salas de la fachada sur. Una rutina permite generar alternativas mediante parámetros y preparar sus datos para compararlas. El equipo necesita decidir qué condiciones examina: geometría, iluminación, demanda estimada, uso o posibilidades constructivas, según el alcance del estudio. El resultado tiene valor cuando podemos relacionarlo con esas entradas y sus supuestos. Una forma que cambia al mover un deslizador demuestra una relación programada; todavía falta explicar por qué una alternativa conviene al edificio.

La comparación requiere conservar qué se calculó y con qué modelo. Si cambiamos horarios de uso o prestaciones de un cerramiento, los resultados dejan de describir exactamente la misma hipótesis. Por eso guardaría escenario, reglas y versión junto con cada opción. La automatización puede hacer repetible la preparación y señalar incumplimientos definidos. La decisión arquitectónica seguirá incorporando compromisos que no caben en una única cifra, además de requisitos que necesitan la comprobación técnica correspondiente.

Aquí conviene separar programación e IA. Una regla explícita puede generar una geometría o revisar que exista una propiedad sin aprender de datos anteriores. Un modelo de aprendizaje puede ayudar en una tarea de predicción o clasificación si contamos con datos y criterios para evaluarlo. No hace falta añadirlo a una operación determinista para reconocer que tiene utilidad. El ordenador tampoco solicita que cada multiplicación venga acompañada de una nueva denominación comercial.

Para un primer uso escogería una tarea repetida, con entradas controladas y un resultado verificable. Por ejemplo, preparar la comparación de alternativas sin alterar automáticamente el modelo de producción. El equipo revisaría la propuesta y registraría cuál adopta. Ese límite permite aprender y detectar errores antes de que una rutina exploratoria herede responsabilidades de entrega. La velocidad del prototipo es una ventaja siempre que sepamos en qué momento deja de ser razonable permitirle cambiar cualquier cosa.

Preparar el BIM para que la operación encuentre los activos

Cuando las oficinas pasan a operación, las preguntas cambian. Mantenimiento necesita saber qué equipo atiende una sala, dónde está y cómo localizar su documentación. El modelo de diseño puede aportar parte de ese contexto, pero debe contrastarse con lo realmente instalado. Si la unidad prevista fue sustituida durante la obra, conservar sin revisión la referencia inicial puede dirigir una intervención al equipo equivocado. La puesta en servicio necesita unir proyecto, instalación y registro operativo.

Definiría una identidad para cada activo relevante y su relación con espacios, sistemas y documentación. No es obligatorio trasladar todos los parámetros de Revit a la herramienta de operación. Hace falta seleccionar los que permitan las tareas acordadas y asignar quién los mantiene. El nombre visible puede cambiar; la relación operativa debe seguir siendo inequívoca. Si el sensor se llama «Sala 2» y el modelo utiliza «Reuniones B», alguien tendrá que resolver esa correspondencia antes de que el algoritmo empiece a sacar conclusiones con mucha seguridad.

La representación operativa combina datos relativamente estables, como la pertenencia de un equipo a un sistema, con estados y lecturas que cambian continuamente. Podríamos utilizar el 3D para localizar una unidad y una gráfica para revisar su comportamiento durante la mañana. La interfaz debería elegir el soporte que facilita cada tarea. Obligar a cargar todo el edificio para conocer la última temperatura sería una decisión de presentación con un entusiasmo bastante discutible por el tiempo del operador.

Para hablar de una conexión operativa mantenida no basta con unir una vez un sensor y un objeto. Al sustituir un equipo o reorganizar las salas, hay que actualizar las relaciones y comprobar que las lecturas sigan atribuyéndose al lugar correcto. Ese mantenimiento forma parte del sistema que algunos proyectos llaman gemelo digital. El nombre puede ayudar a describir la intención; lo que sostiene la utilidad es saber quién conserva cada relación y cómo se detecta que ha dejado de representar al edificio.

Medir con contexto antes de ordenar una actuación

La lectura de temperatura necesita su unidad, instante, procedencia y una indicación de validez. También hay que conocer qué representa el sensor: una sala concreta, una zona o una posición que quizá no describe todo el espacio. Si deja de transmitir, el sistema debería mostrar la ausencia de información. Conservar el último valor en una pantalla sin identificarlo como antiguo puede hacer que una avería de comunicaciones parezca una temperatura extraordinariamente estable.

En las oficinas del ejemplo, una desviación podría relacionarse con horarios, ocupación, una ventana abierta, una consigna o un problema del equipo. Una sola lectura no demuestra cuál es la causa. Reunir series de datos y contexto permite investigar; convertir la primera asociación en diagnóstico automático puede mandar a mantenimiento a corregir algo que funciona. La automatización puede preparar la evidencia y priorizar una revisión, manteniendo clara la diferencia entre condición observada, hipótesis y causa confirmada.

Antes de recopilar más variables, preguntaría qué decisión permiten mejorar. Si para ajustar una zona basta una señal agregada de uso, seguir a cada ocupante añade una exposición y un trabajo de gestión que el objetivo no necesita. También definiría durante cuánto tiempo hace falta conservar cada dato y quién puede consultarlo. No se trata de construir un almacén infinito a la espera de que una futura IA descubra su propósito. Acumular información sin criterio suele ser más sencillo que mantener su significado.

Empezaría observando el edificio sin añadir nuevas órdenes automáticas. Ese primer periodo permitiría comprobar correspondencias, horarios y calidad de las lecturas. El operador podría contrastar las alertas propuestas con lo que ocurre realmente. Conectar una medición a un panel es una prueba de transporte; comprobar que pertenece al activo correcto y llega a tiempo para la decisión es una prueba del recorrido. Las dos importan, pero no ofrecen la misma evidencia.

Elegir reglas e IA según la incertidumbre del problema

Si conocemos una condición y su tratamiento, una regla explícita puede ser el comienzo más comprensible: detectar una ausencia prolongada de datos o señalar que una lectura queda fuera del rango acordado durante un periodo definido. Los valores y tiempos deben proceder del diseño y la operación del sistema concreto. Este artículo no prescribe consignas de climatización. El interés está en que mantenimiento pueda ver entrada, condición y respuesta, y distinguir una alarma de la orden que eventualmente se autorice.

La analítica puede ayudar a encontrar comportamientos menos evidentes. La descripción de capacidades EMIS del Departamento de Energía estadounidense diferencia, entre otras, análisis de consumo, detección de fallos y control supervisor. Son capacidades distintas: reconocer una desviación no implica tener confirmado su diagnóstico ni permiso para corregirla. Esa separación permite evaluar cada parte por su resultado y evita llamar «optimización automática» a cualquier gráfica con una línea de previsión.

Para nuestro caso hipotético podríamos estudiar si un modelo anticipa el arranque necesario para una zona. Antes de que actúe, compararíamos sus propuestas con una estrategia de referencia y revisaríamos cómo responden ante cambios de uso. El criterio tendría que incluir el servicio que queremos ofrecer y los recursos que consume, con datos representativos del alcance. Si una regla sencilla obtiene un resultado adecuado, la predicción más compleja necesita demostrar su ventaja. Ser más difícil de explicar no es una prestación.

También hay que prever cuándo deja de ser fiable. Una reforma, un equipo nuevo o un horario distinto pueden cambiar el comportamiento que se aprendió. El sistema necesita identificar su versión, sus condiciones de uso y la respuesta prevista cuando falten datos o el caso quede fuera del alcance evaluado. Puede mantenerse como propuesta para una persona o retirarse en favor del procedimiento definido. Una capa de IA debería tener una forma clara de reconocer incertidumbre, especialmente cuando su salida podría acabar afectando a un edificio ocupado.

Separar la consulta de los permisos para controlar

Una aplicación que muestra datos y otra que puede modificar un equipo tienen efectos diferentes. La guía NIST SP 800-82 Rev. 3 trata los sistemas de automatización de edificios dentro de la tecnología operacional y subraya sus necesidades de seguridad, fiabilidad y funcionamiento físico. La conexión de un panel nuevo debe respetar esa realidad. Poder consultar el estado de una unidad no debería conceder por accidente capacidad para cambiar cualquier parámetro de su control.

En las oficinas, definiríamos qué acciones puede proponer el sistema, cuáles puede ejecutar bajo condiciones aprobadas y cuáles requieren intervención del personal autorizado. Un cambio en el modelo BIM no debería transformarse directamente en una consigna operativa sin el flujo de validación correspondiente. Los equipos de diseño y operación necesitan acordar esa frontera. El modelo describe información que puede ayudar a decidir; una orden sobre el edificio exige comprobar un contexto y una autoridad adicionales.

La pérdida de conexión externa también necesita un comportamiento previsto. La operación del edificio no puede depender de que cargue correctamente una vista 3D o responda un servicio analítico. Los responsables de control deben definir continuidad, intervención local y recuperación para la instalación concreta. La aplicación que añadimos tiene que comunicar sus fallos y respetar esos mecanismos. Estamos ampliando una capacidad de gestión, no asignando al navegador la responsabilidad de recordar que las salas siguen existiendo cuando se cierra la pestaña.

Antes de habilitar nuevas actuaciones, propondría comprobar el recorrido con el equipo responsable: origen del dato, relación con el activo, condición evaluada, decisión autorizada y confirmación del resultado. Se ensayarían también datos ausentes y peticiones rechazadas en el entorno adecuado. No se afirma aquí que esas pruebas se hayan ejecutado. Son parte de lo que habría que demostrar antes de presentar un prototipo informativo como una integración que puede controlar la instalación.

Comprobar el valor y asignar quién lo mantendrá

Un piloto debería tener un objetivo observable y un alcance limitado. Para las salas del ejemplo interesaría comprobar si las personas encuentran las desviaciones relevantes y si la información permite actuar con menos investigación previa. Si se evalúan cambios de consumo o confort, hay que tener en cuenta las condiciones de comparación: clima, ocupación, horarios y actuaciones de mantenimiento. Una semana más templada puede producir una mejora sin que el algoritmo haya participado en absoluto. La atribución del resultado necesita algo más que dos barras de colores.

Los avisos también tienen coste. Una alerta que aparece continuamente sin aportar una acción clara enseña al operador a ignorarla. Conviene revisar descartes, causas y tiempo de atención, y retirar o ajustar reglas cuando no ayuden. Mantener una predicción mediocre porque ya costó entrenarla solo añade otra obligación al sistema. El criterio de continuidad debería seguir siendo la tarea del edificio, aunque eso implique admitir que una solución convencional resuelve mejor una parte.

La entrega necesita propietarios para datos, correspondencias, reglas e integraciones. También una explicación de qué hace la aplicación y cómo recuperar o desactivar sus funciones dentro del procedimiento acordado. Si nadie mantiene la relación entre la sala y su sensor, el contexto se degrada incluso cuando todos los servicios siguen respondiendo. Los cambios físicos del edificio no consultan el estado del repositorio antes de producirse.

La conexión empieza a servir cuando una lectura cambia una decisión y puedes comprobar su efecto. El modelo ayuda a localizar, las reglas hacen repetible lo conocido y la IA necesita un papel que pueda evaluarse. No es obligatorio que las tres tecnologías aparezcan en cada pantalla. Una sala que deja de calentarse vacía aporta una explicación bastante convincente por sí sola.