1. La madrugada del 15 de agosto
A la 01:04:40 el sistema disparó un aviso.
No hubo nadie despierto tomando la decisión. En la torre del Hospital Real de Granada, fundado por los Reyes Católicos en 1504 y terminado por su nieto Carlos V a partir de 1522, tenemos instalados seis acelerómetros registrando información de forma continua desde principios de 2025 y alimentando el Gemelo Digital Cognitivo del edificio. Estos dispositivos han colaborado en el marco del proyecto BUILDCHAIN (Horizon Europe, GA 101092052), en el que el equipo de QUANTIA ha tomado parte, y de cuyos resultados también QUANTIA es titular a través de nuestra colaboración con la UGR.
La campaña preliminar había señalado a la torre como el elemento que gobierna la respuesta dinámica de todo el conjunto. Cuando llegó la sacudida, el sistema capturó la ventana de información, la procesó, extrajo cómo estaba vibrando la torre en ese momento y lo comparó con lo que llevaba año y medio registrando y aprendiendo sobre esa estructura en concreto. Y toda esa información —la señal, el cálculo y la interpretación— quedaría integrada en ese registro, un auténtico libro digital.
La primera lectura de uno de sus modos fundamentales de vibración estaba casi un 10 % por debajo de la que se tomó una hora antes, lo cual implica que el edificio había sufrido daño estructural.
Esa cifra no la calculó nadie al día siguiente con una hoja de cálculo. Estaba disponible a la 01:19, quince minutos después del terremoto, mientras media Granada, con inquietud y angustia, salía a la calle.
Y aquí quiero parar, porque tener ese dato es la parte fácil. Lo difícil, y lo que de verdad importa, es todo lo que vino después.
Lo que el edificio sintió. Seis canales de aceleración durante uno de los eventos —cuatro en la dirección de la fachada principal de la torre, dos en la perpendicular—: la sacudida llega, la estructura responde y la respuesta se apaga en unos segundos. Esos segundos son la ventana en la que un edificio cuenta más sobre sí mismo.
2. Un gemelo digital cognitivo no es una maqueta: es un modelo de comportamiento
Durante mucho tiempo, cuando decíamos “tenemos el gemelo digital cognitivo del edificio”, queríamos decir que teníamos un modelo BIM o GIS muy bueno. Geometría precisa, elementos clasificados y alguna visualización gráfica de las lecturas de sensores. Es un trabajo valioso y difícil, y seguimos haciéndolo.
Pero nos dimos cuenta de que no es ahí donde estaba el valor. Porque eso no es un gemelo, no aprovecha todo el potencial de la información. Es, más bien, un retrato.
“Un gemelo digital cognitivo representa dos aspectos de la realidad física del activo. Y el que más importa no es la geometría.”
Del escaneo al gemelo. A la izquierda, el HBIM multiescala del Hospital Real y el despiece de la torre — cubierta y pináculos, ventanas ojivales, estructura de soporte— levantado sobre nube de puntos. En el centro, la generación del modelo de elementos finitos a partir de ese HBIM. A la derecha, el grafo de conocimiento sobre el que se monitoriza y se actualiza. Es la cadena completa: geometría, comportamiento y semántica.
Para comprender en qué consiste un gemelo digital cognitivo, hay que considerar dos aspectos:
- El primero es la geometría. Aquí el valor no está en la representación realista, en que el modelo se parezca mucho al edificio. Está en la localización: dónde está cada elemento, qué relación guarda con los que le rodean, qué función cumple dentro del conjunto. La geometría es el sistema de coordenadas del conocimiento: lo que permite situar todo lo demás.
- El segundo es el modelado del comportamiento del activo, y es el que de verdad convierte un modelo en un gemelo. Es lo que explica cómo el contexto —lo que aportan la sensórica y todos los datos que rodean al modelo geométrico— influye en el devenir del activo. Y, sobre todo, cómo ese activo aporta valor en uno o varios casos de uso concretos.
- En el ejemplo de Granada ese caso de uso es el comportamiento estructural y su mantenimiento.
-
- En una red de agua tendrían más sentido otros casos de uso, con otra física pero con el mismo esquema de procesamiento.
-
- Y en el caso de una estructura, ese modelado significa algo muy concreto: hay un modelo numérico de comportamiento —masas, rigideces, condiciones de contorno, propiedades del material— cuyos parámetros significan algo físico y verificable. La torre del Hospital Real es un modelo parametrizado de elementos finitos levantado sobre el escaneo láser de todo el conjunto. Pocos parámetros gobiernan el comportamiento de todo el edificio, y cada uno con nombre: el módulo de la fábrica y la rigidez de cada vínculo.
Esta distinción es la que decide si tus sensores sirven para algo, pero vamos a profundizar más en el concepto a través de una metáfora que utilizo mucho en mis clases:
2.1. El cuerpo humano como analogía al Gemelo Digital Cognitivo
- El modelo BIM es la anatomía. Dónde está cada cosa y de qué está hecha.
- Los sensores son el sistema nervioso. Terminaciones que perciben, pero que por sí solas no saben qué significa lo que perciben.
- El cerebro son dos cosas inseparables, y aquí está lo importante:
- El modelo de comportamiento, que aporta la teoría de cómo funciona este cuerpo.
- El grafo semántico, que aporta todo lo que se sabe sobre él. Ninguna de las dos interpreta nada por su cuenta.
- El modelo de IA (LLM) es la interfaz, que coordina y gestiona ese conocimiento para presentárselo al usuario. Es lo que da pie a la interacción con el humano.
Las tres primeras capas son donde vive el conocimiento. La cuarta es la que lo pone a disposición de un usuario: recorre el grafo, reúne lo que hace falta, decide qué es relevante para lo que le acabas de preguntar y te lo devuelve en tu idioma. Sin ella, todo lo anterior es un servidor que tiene mucha información y con el que no se puede hablar.
Inicialmente, solo teníamos la anatomía. A veces, con terminaciones nerviosas. Y en QUANTIA decidimos dar el paso que faltaba: construir el cerebro. No por elegancia técnica, sino por todas las posibilidades que se abren cuando el gemelo pasa de mostrar a interpretar — y es de eso de lo que quiero hablar.
2.2. ¿Por qué un dato de sensor, aislado, no vale nada?
Volvamos a la madrugada del 15 de agosto. El sistema mide una frecuencia natural: 3,7 Hz.
¿Y qué? 3,7 Hz no es un diagnóstico. No es ni siquiera una preocupación. Es un número.
Ahora vamos a ponernos algo técnicos: Ese número se convierte en conocimiento únicamente cuando se vincula a un modelo de comportamiento cuyos parámetros tienen significado físico.
Entonces la medición deja de ser un valor y pasa a ser evidencia: actualiza el módulo efectivo de la fábrica de la torre y la rigidez efectiva de los vínculos que la unen al resto del edificio. La inferencia bayesiana es precisamente el mecanismo de esa conversión: la medida produce una estimación probabilística actualizada sobre los parámetros físicos del modelo. Y de ahí sale todo lo demás. El sistema pudo concluir esa semana que lo observado encajaba mejor con un cambio en las condiciones de contorno de la torre —en cómo está vinculada a lo que la rodea y la sostiene— que con una fisuración de su fábrica. Eso solo se puede afirmar si la rigidez de la fábrica y la rigidez de los vínculos son parámetros distintos dentro del modelo, y si se sabe hasta dónde los datos permiten separarlos, porque se compensan en parte: una fábrica algo más rígida con vínculos algo más blandos produce casi las mismas frecuencias. Sin modelo de comportamiento, una caída de frecuencia es una anomalía y ahí se acaba la conversación. Con modelo de comportamiento, es un cambio atribuible, cuantificado con su incertidumbre y físicamente interpretable, sobre el que se puede decidir dónde mandar a un equipo.
Y hay un detalle de aquella madrugada que me parece el más elocuente de todos: el gemelo no necesitó que nadie le explicara qué había pasado. Lo que cambió en la forma de vibrar de la torre era, por sí solo, la firma de un seísmo, y contenía además algo que ningún titular ni ningún aviso del IGN contiene: cómo había respondido esta estructura en concreto. Un diagnóstico emitido desde dentro del edificio, que coincidía con exactitud con lo que estaba pasando fuera.
“La sensórica no es el gemelo. La sensórica es lo que alimenta al gemelo. El gemelo digital cognitivo es el modelo que sabe qué hacer con esa comida.”
2.3. La semántica es fundamental en el “cerebro” del Gemelo Digital Cognitivo
Durante años presentábamos la capa semántica como una cuestión de integración: el cableado que mantiene unidas las piezas. Es verdad, pero es lo menos interesante que hace. La semántica es parte del órgano que interpreta: es lo que permite estructurar los datos y los modelos, y convertirlos en conocimiento accionable.
Piénsalo desde el propio caso de agosto. Para interpretar una caída de frecuencia hace falta saber que la torre es de fábrica de calcarenita, que el edificio se reconstruyó en parte tras el incendio de 1549 y que aquello cambió los flujos de carga de varios sectores, que el enjambre de seísmos de 2020–2021 generó daños y obligó a una rehabilitación terminada en 2024, que la última inspección visual fue en marzo y no encontró nada, que la estancia contigua tuvo un problema de humedades hace dos años, y que el edificio está protegido y por tanto hay intervenciones que, sencillamente, no pueden estar sobre la mesa.
Nada de eso lo mide un sensor. Todo eso es conocimiento intrínseco del activo, acumulado durante décadas por gente distinta, y es lo que convierte un número en un diagnóstico.
Un modelo físico sin contexto es un estudiante brillante que acaba de llegar al edificio esta mañana. Con ese contexto es alguien que lo conoce de toda la vida.
Por eso el verdadero reto está en sostener este conocimiento.
Ese vínculo entre dato y comportamiento no es un vínculo, son miles. El canal 4 del acelerómetro corresponde a un grado de libertad del modelo numérico, que corresponde a un elemento del IFC, que está en una estancia, que pertenece a un sistema constructivo, que tiene un histórico de intervenciones, un informe de inspección, un estado de conservación y unos requisitos normativos aplicables.
Cada una de esas cosas vive en un software distinto, de un fabricante distinto, creada por una persona distinta en un momento distinto. Si esas relaciones están cableadas a mano en un script de integración, el gemelo se muere la primera vez que cambia cualquier cosa: una reforma, un sensor que se sustituye, un cambio de contratista, una versión nueva de la herramienta de cálculo.
La respuesta a eso es semántica: entidades y relaciones tipadas, mediante ontologías, con significado explícito y legible por máquina. Un grafo de conocimiento o knowledge graph en el que la geometría, el modelo de comportamiento, las observaciones de los sensores, los registros de mantenimiento y los estados de daño no son ficheros que alguien tiene que correlacionar, sino nodos conectados por relaciones que declaran qué son.
2.4. Cómo se modela esto de verdad
En BUILDCHAIN esto no se ha resuelto inventando una ontología propia, que es la tentación habitual y el camino más corto para quedarse solo. Se compusieron las que ya existen y funcionan: IFC como base, con ifcOWL para llevarla al mundo semántico; Brick Schema para la topología del edificio y sus equipos; SOSA/SSN, del W3C, para las observaciones de sensores; QUDT para magnitudes y unidades; schema.org para los metadatos; todo bajo ISO 19650 como marco de gobernanza del ciclo de vida. Con eso, el edificio se modela por dónde están las cosas y no por cómo se llaman los ficheros: un sensor no es “el canal 4”, es un punto que cuelga de una estancia, que cuelga de una planta, que cuelga de un edificio. Y el objetivo declarado del piloto fue exactamente ese: poder consultar un sensor por su localización dentro del edificio, y desde ahí llegar a su tipo, a sus datos crudos y al resultado de los cálculos. Toda la tesis de este artículo cabe en esa frase.
Y eso compra cuatro cosas:
I. Contexto: cada medición nueva se interpreta contra todo lo que ya se sabía de ese elemento concreto, no contra un modelo genérico.
II. Permanencia: el Hospital Real va a sobrevivir a todos los programas informáticos implicados en su monitorización, y lo único que puede sobrevivir con él es el significado explícito de los datos — un fichero propietario es un préstamo, una ontología es patrimonio.
III. Componibilidad: añadir un sensor, un modelo o una intervención deja de ser un proyecto de integración y pasa a ser declarar qué es la cosa nueva y dónde se engancha, que es literalmente la diferencia entre un piloto que funciona en un edificio y una plataforma que funciona en cuatrocientos.
IV. Y razonamiento: relaciones tipadas que se pueden recorrer y sobre las que fundamentar cada afirmación. Porque ahí no se guarda todo: la serie temporal vive fuera, en una base de datos convencional a la que el grafo apunta; lo que se ancla de forma verificable esla afirmación — qué sensor, en qué estancia, en qué instante, dijo qué.
3. El modelo de IA (LLM) como eje central del razonamiento y la interacción con el usuario.
El conocimiento vive en el modelo de comportamiento y en el grafo. El modelo de IA es quien lo coordina y lo gestiona para presentarlo: recorre el grafo, reúne lo que hace falta, lo ordena y lo convierte en una respuesta que una persona pueda usar. Las dos piezas se necesitan: sin grafo, el LLM es un interlocutor elocuente que no ha visitado nunca el edificio; sin LLM, el grafo es una biblioteca perfecta que nadie consulta.
3.1. Por qué esto, y no los sensores, es el diferencial
Voy a decirlo sin rodeos, porque es la conclusión que me ha costado más años entender. Poner sensores es relativamente fácil. Cualquiera puede instrumentar un edificio; el material está en catálogo y la instalación la hace un buen equipo en una semana. Montar un cuadro de mando también es fácil. Lo que casi nadie hace es modelar qué es cada cosa de forma que siga significando lo mismo cuando ya no estés tú.
Y esa capa es la única que acumula. Un sensor instalado es un coste hundido: si mañana lo cambias de sitio, empiezas de nuevo. Un modelo semántico bien hecho es lo contrario: cada activo modelado abarata el siguiente, porque las clases, las relaciones y las consultas se reutilizan. El conocimiento no se evapora cuando acaba el contrato, cuando cambia el software o cuando se jubila la persona que lo sabía todo.
En BUILDCHAIN esto se formaliza con una figura que me parece la idea más potente del proyecto: el Knowledge Asset —la unidad con la que se construye el Knowledge Graph—, definido como “un contenedor de conocimiento del que se puede ser propietario”, en múltiples formatos —tripletas de grafo, embeddings, registros, imágenes—, con tres propiedades núcleo: propiedad, descubribilidad y verificabilidad. El conocimiento sobre un activo pasa a ser, él mismo, un activo. Con dueño, con trazabilidad y con capacidad de ser encontrado por terceros —incluidos, y esto es deliberado en el diseño, agentes automáticos.
La arquitectura que lo sostiene son tres capas: aplicaciones arriba; en medio los servicios, las APIs y los smart oracles; y abajo el Digital Building Logbook, con el grafo de conocimiento organizado en bancos de conocimiento por caso de uso y una capa blockchain multicadena que garantiza la integridad. Y una frase del entregable que resume bien el espíritu: “la ontología es un componente vivo”. No es un anexo que se entrega y se archiva. Se mantiene.
Nuestro piloto —el Hospital Real— es el caso de uso 5, “SHM tools for cultural heritage buildings”, y fue uno de los dos únicos proof of concept con los que se validó toda la arquitectura del sistema, desarrollado en cooperación con la Universidad de Granada. Y entre los doce casos de uso del proyecto hay tres que este agosto han dejado de ser hipótesis de trabajo: “edificios a prueba de terremotos y clima mediante gemelos digitales”, “intervenciones post-catastróficas” y “seguimiento de procesos de diseño mediante actualización bayesiana”.
QUANTIA, como spin-off de la UGR, ha industrializado esa tecnología, entre otras, en QORUM, nuestra plataforma propia de gestión de datos de activos bajo la óptica de Gemelo Digital Cognitivo.
3.2. Las tres propiedades que lo hacen “cognitivo”
Con la geometría, el modelo de comportamiento y la semántica en su sitio, aparece lo que da nombre a todo esto:
- Se actualiza a sí mismo con la evidencia. El modelo no es un entregable que se congela al terminar el proyecto: cada mes de medidas reajusta sus parámetros físicos, y lo que sale no es un número, es una secuencia de distribuciones. El modelo de este mes no es el del mes pasado, porque ha aprendido de lo que ha vivido. Y en ese aprendizaje hay cosas que nadie le programó: tras un año de inferencias, el modelo ha descubierto que su rigidez efectiva sube con la temperatura —la correlación del módulo de la fábrica y de la rigidez del vínculo superior con la temperatura media mensual ronda 0,7— y que el vínculo con la fachada principal es más rígido de lo que la geometría del muro haría pensar. Un edificio que ha pasado un verano tórrido, un invierno húmedo y un enjambre sísmico no es el mismo edificio, y su gemelo tampoco debería serlo.
- Lleva la cuenta de su propia incertidumbre. No responde “el edificio ha perdido rigidez”, sino “ha perdido rigidez en torno a esto, con esta dispersión, sobre esta cantidad de evidencia”. La distancia entre esas dos frases es la distancia entre una decisión y una corazonada.
- Distingue lo que sabe de lo que cree. sabe hasta dónde puede separar una causa de otra: cuando dos parámetros se compensan, la distribución conjunta lo muestra, y ese es el límite honesto de lo que se puede afirmar.
Volviendo a la metáfora del cuerpo: un termómetro registra la fiebre pero no es inteligente. La inteligencia reside en el médico que interpreta esa fiebre en el contexto de un paciente concreto, revisa su diagnóstico cuando llega la analítica, y te dice cuánta confianza tiene en lo que acaba de decirte. Un gemelo cognitivo aspira a lo segundo. Y el rasgo que mejor lo define no es la potencia de cálculo: es saber dónde termina lo que puede afirmar.
En agosto nos tocó comprobar si servía.
4. Lo que esta tecnología fue capaz de hacer esa semana
4.1. Estar donde no había nadie
El primer terremoto fue a la una de la madrugada de un sábado de agosto, en plena operación mínima. El segundo, tres días después. Entre uno y otro hubo decenas de réplicas, muchas de madrugada. El sistema capturó, procesó e interpretó cada una de ellas sin que nadie levantara el teléfono.
Esto parece obvio y no lo es.
“La ventana en la que un edificio te cuenta más sobre sí mismo son los segundos en los que está siendo excitado. Si en ese momento no hay nada escuchando, esa información se ha perdido para siempre.”
No es recuperable después con una inspección visual, porque una grieta te dice que algo pasó, pero no cuándo, ni con qué intensidad, ni cómo respondió el conjunto.
En esta torre, además, hay una razón muy concreta: todos los edificios se mueven y esta torre, en condiciones normales, se mueve poco en la dirección perpendicular a su fachada principal. Por eso, solo dos de los seis sensores miran hacia allí: su primer modo de flexión, el que gobierna la respuesta en esa dirección, solo se identifica en una de cada seis horas de vibración ambiental. Un seísmo lo excita de lleno. Durante unos segundos, el edificio enseña precisamente el modo que peor se deja ver el resto del año. Esta información es oro para entender qué ha pasado; porque como podemos intuir, no es obvia.
18 de agosto, 10:37. El sistema captura, procesa e interpreta sin que nadie levante el teléfono.
4.2. Interpretar, no solo medir
Un acelerómetro produce una señal. Lo que un gestor necesita no es la señal: es “¿ha cambiado algo estructuralmente relevante?”. Entre esas dos cosas hay identificación modal —cada hora, sobre quince minutos de registro—, seguimiento de modos, separación de efectos ambientales y comparación contra un modelo que se actualiza. Ese trayecto es el producto.
Y hay un detalle que decide si la alarma de las dos de la mañana es una alarma de verdad. Dos de los modos de la torre vibran a frecuencias tan parecidas que, si el sistema los distinguiera solo por ahí, los confundiría varias veces al año: cada uno se desplaza con las estaciones más de lo que los separa entre sí. Por eso el sistema los identifica por su forma de vibrar, comparada con una referencia que el sistema aprendió durante su primer mes de vida. Es el tipo de detalle que no aparece en ninguna demo.
Y el resultado tiene una propiedad valiosísima: es una comparación contra el propio edificio, no contra una norma ni contra un edificio parecido. No hace falta saber si 3,7 Hz es mucho o poco para una torre del XVI. Basta con saber dónde lleva año y medio este edificio, cuánto se mueve con las estaciones —los tres modos “suben” en verano, y su correlación con la temperatura exterior supera 0,6 en todos los casos— y que ahora está en otro sitio.
4.3. Cambiar el diagnóstico, no solo la alarma
Y aquí llega lo que de verdad importa. El sistema no se quedó en “ha cambiado algo”: permitió razonar sobre qué.
Conviene decir antes qué puede separar el modelo y qué no. El modelo de la torre tiene pocos parámetros, todos con significado físico: el módulo efectivo de su fábrica y la rigidez efectiva de los vínculos con los muros que la arriostran, en dos niveles. Los datos solo informan de verdad sobre el módulo y sobre los vínculos del nivel superior; los del inferior apenas influyen en las frecuencias medidas, y la inferencia lo reconoce dejando su distribución donde estaba. Y módulo y vínculos se compensan en parte: una fábrica algo más rígida con vínculos algo más blandos produce casi las mismas frecuencias. Conviene también decir para qué se calibró: para entender el edificio, no para diagnosticar daño. Agosto ha sido la primera vez que se le pidió lo segundo.
Con ese mapa delante, lo que la serie mostró fue un descenso que se quedó. Uno de los modos superiores de la torre pasó de cerca de 12 Hz a 10 Hz, y no volvió — fue bajando escalón a escalón, con cada nueva sacudida del enjambre. Y ese modo, en concreto, es una doble flexión: la torre se curva en forma de S. Para que ese modo exista y pueda medirse, la torre tiene que estar trabajando como un conjunto íntegro con el cuerpo del edificio. Si su frecuencia baja de forma sostenida, lo que se ha perdido es rigidez en ese acoplamiento — en cómo la torre está unida a lo que la rodea, no en la fábrica de la torre en sí. Y de las dos causas posibles, una desconexión entre elementos o una fisuración de la fábrica, la lectura apunta a la primera. Habrá que contrastarlo con las inspecciones que se hagan al edificio.
Es una hipótesis, no un veredicto, y así hay que trasladarla. Pero es una hipótesis distinta, y ahí está todo el valor económico de esto: un diagnóstico de fisuración manda a un equipo a buscar grietas en la fábrica; uno de acoplamiento manda a mirar los encuentros de la torre con el edificio. Distinta inspección, distinto coste, distinta decisión. Eso es lo que hace un sistema que razona, frente a uno que avisa. Y es exactamente donde aportamos
“En QUANTIA señalamos dónde hay que mirar cuando algo ha cambiado. Un sistema que acierta con la necesidad real mejora la eficiencia de toda la operación, porque cada euro de inspección y cada hora de un técnico van al sitio correcto en lugar de repartirse por precaución.”
Y aquí este artículo se queda, a propósito, con una pregunta abierta. La hipótesis no está confirmada: hará falta contrastarla con las inspecciones que se hagan al edificio. Y cuando eso ocurra sabremos dos cosas, no una. Sabremos qué le ha pasado a la torre — y sabremos hasta qué punto acertó el gemelo. Porque un diagnóstico que se puede contrastar es también un examen para quien lo emite, y ese examen es la única forma seria de medir si esta tecnología sirve para lo que decimos que sirve. Mientras llega la respuesta nos quedamos con lo que ya tenemos, que no es poco: sabemos dónde ir a mirar. Otra vez. Y cuando haya respuesta, la contaré.
4.4. Y que se le pueda preguntar en tu idioma
Hay una quinta capacidad que se me quedaría fuera si no la contara, y es la que más ha cambiado nuestra forma de trabajar este año en QUANTIA.
Todo lo anterior —frecuencias modales, formas modales, amortiguamientos, correlaciones— es vocabulario de especialista. Es exactamente el tipo de información que se queda muerta en un servidor porque hay tres personas en la organización capaces de leerla, y esas tres personas están ocupadas.
Sobre el cerebro —modelo de comportamiento y grafo semántico— hemos puesto un modelo de IA que coordina y gestiona ese conocimiento y lo presenta. Se le pregunta al edificio, literalmente en castellano, qué le ha pasado esta noche. Y contesta razonando sobre lo que sabe de sí mismo: qué ha cambiado, cuánto, desde cuándo, con qué confianza, qué explicaciones alternativas hay, y qué haría falta medir para distinguir entre ellas.
Lo hemos empaquetado en una solución dentro de nuestra plataforma QORUM.
Insisto en el orden de los factores, porque es donde realmente está el valor de esta tecnología: esto no es un chatbot al que le hemos enchufado unos datos. Es un gemelo que ya sabía interpretar, y al que le hemos dado la capacidad de explicarse.
Una consulta real, sin retocar. Fíjate en lo que hace el sistema por su cuenta: cuantifica, contextualiza contra el histórico de meses anteriores, y avisa de que sin el canal de temperatura en vivo no puede compensar el efecto ambiental. Nadie le pidió esa cautela. Es la primera pasada, la más cruda —dos ventanas horarias, polo contra polo—; lo que viene después, emparejar cada modo por su forma y situarlo en su banda estacional, es lo que convierte esa comparación en una medida.
Eso convierte un sistema de monitorización en algo consultable por un gestor de patrimonio, un jefe de mantenimiento o un responsable de emergencias a las dos de la mañana, sin un doctorado en dinámica estructural de por medio. Y es, para mí, la diferencia entre una capacidad que existe y una capacidad que se usa.
5. Lo que hace falta para que esto funcione de verdad
Todo lo anterior descansa sobre una capa que no sale en los papers y de la que nadie presume: integridad del dato. Escrituras que no se dupliquen. Ventanas de análisis correctamente etiquetadas. Sensores que avisan cuando son ellos los que están fallando, y no la estructura. Canales ambientales vivos, porque sin temperatura no se puede separar lo que hace el clima de lo que hace el daño: la temperatura exterior la tenemos a posteriori, de una fuente externa, y con ella sabemos que los tres modos suben en verano; lo que hace falta es tenerla en el mismo instante en que el sistema decide.
Esa semana encontramos y corregimos defectos en todas esas capas. Ninguno era un problema de inteligencia artificial. Todos eran de ingeniería. Y no era la primera vez: un año antes, un corte de adquisición nos dejó casi todo agosto de 2025 sin datos —tres días de registros en un mes— y la inferencia de ese mes es la peor de toda la serie. No falló el modelo: faltó el dato.
Y esa es, en mi experiencia, la razón real por la que tantos pilotos brillantes no llegan a producto: la inferencia es el 10 % del problema. El 90 % es que la inferencia siga siendo fiable durante años, sin nadie mirando, sobre datos que llegan sucios del mundo real.
Ese 90 % es en lo que consiste QORUM.
6. El potencial: de un edificio a un sistema
6.1. Patrimonio no es el caso fácil: es el más difícil dentro de los edificios
Antes de seguir, una precisión que me importa, porque se suele leer al revés.
Que la demostración sea un edificio del siglo XVI, de esos que salen en las ilustraciones de los libros de Historia, no significa que esto sea una tecnología de nicho para monumentos. Significa lo contrario. Un edificio histórico es el peor escenario imaginable para un gemelo digital cognitivo de un edificio:
- No hay planos fiables. Hay quinientos años de intervenciones no documentadas. La geometría del modelo de la torre salió de un escaneo láser de todo el conjunto, no de un plano.
- No se pueden ensayar los materiales, porque no se puede tocar. Los parámetros del modelo arrancan con una incertidumbre enorme: el módulo de la fábrica, con un ±20 % tomado de la literatura sobre la calcarenita de Granada; la rigidez de los vínculos, con un ±50 %.
- La fábrica de mampostería tiene un comportamiento no lineal, dependiente de la amplitud, y no responde a ningún catálogo normativo.
- Y no hay margen de error, porque el activo es irreemplazable.
Si un modelo de comportamiento se puede calibrar y mantener vivo ahí, con esa incertidumbre de partida y esa exigencia, el resto de casos son problemas más acotados. En una infraestructura moderna tienes planos as-built, materiales certificados, propiedades conocidas y, a menudo, la posibilidad de instrumentar sin pedir permiso a Cultura.
Patrimonio es el examen difícil. Aprobarlo es lo que da derecho a hablar de lo demás.
6.2. Se puede usar en otros tipos de activos
Cambia la física del modelo y cambia el vocabulario del dominio. No cambia la arquitectura de la decisión. Y ahí está lo que convierte esto en producto y no en proyecto: el sistema es transversal y agnóstico al sector en el que se use, lo llamamos QORUM y está desarrollado por QUANTIA.
Redes de abastecimiento y saneamiento, energía y utilities, infraestructura civil, parque edificado en operación, manufactura, planta de proceso. En cada uno el activo es otro, la física del modelo es otra y el vocabulario es otro. La arquitectura de la solución es la misma. Adaptar el sistema a un caso de uso nuevo consiste, en esencia, en cambiar las ontologías que se registran en el grafo de conocimiento — no en reescribir la plataforma.
6.3. Ahora imagina esto
Voy a pedirte un ejercicio, y prefiero plantearlo desde donde estamos ahora mismo.
Estos días, en Granada, la evaluación del parque edificado tras los seísmos se hace como se ha hecho siempre: equipos técnicos yendo edificio por edificio, con un formulario, decidiendo con
criterio experto y sin línea base. Es trabajo excelente hecho por buenos profesionales, y es la única forma que hay. Pero tiene un límite físico: no hay técnicos suficientes, y las decisiones de las primeras setenta y dos horas —qué se cierra, qué se apuntala, qué espera— son justo las que se toman con menos información.
Imagina ahora que una fracción significativa de los activos críticos de una ciudad —los colegios, los hospitales, los depósitos de agua, los edificios administrativos, las centrales de transformación, las estaciones de autobús, metro, tren, los puentes de acceso— tuvieran un gemelo con modelo de comportamiento, semánticamente interoperable con los demás.
A las dos horas del terremoto no tendrías una lista de edificios que hay que ir a ver e ingenieros voluntarios para un lado y otro. Tendrías un orden: estos cuatro han cambiado de forma significativa y hay que ir ya; estos treinta están dentro de su variación normal y pueden esperar a la semana que viene; y en este de aquí lo que ha cambiado apunta a cimentación, así que manda al geotécnico y no al de estructuras.
Eso no sustituye al técnico. Le dice por dónde empezar. Y en las primeras setenta y dos horas de una emergencia, saber por dónde empezar es la diferencia entre gestionar y apagar fuegos. Lo mismo, con otro reloj, aplica a una sequía, a una ola de calor sobre una red eléctrica, o a una riada. Lo excepcional no avisa.
Lo que se puede tener preparado es la capacidad de interpretarlo rápido.
Veintiséis horas después, otra réplica. Doce veces menor que la del día anterior. El enjambre continúa, la intensidad decae — y eso también es información que hay que interpretar, no solo registrar.
6.4. Escalar sin reescribir nada
Este es el punto donde la semántica deja de ser una elegancia arquitectónica y se convierte en la única vía posible.
Escalar de un edificio a cuatrocientos no es un problema de capacidad de cálculo: es un problema de que cada activo tiene otra geometría, otra instrumentación, otro modelo de comportamiento y otro histórico. Si las relaciones entre esas cosas están cableadas caso por caso, el coste marginal de cada activo nuevo es el de un proyecto entero, y el negocio no cierra.
Con un grafo de conocimiento, el activo nuevo declara qué es y se engancha. El coste marginal se derrumba. Toda la diferencia entre consultoría y producto está en esa frase.
6.5. La pieza que más se malinterpreta: la cadena de custodia
De la herencia de BUILDCHAIN, la parte que este agosto ha quedado más clara es el registro trazable e inmutable del estado del activo.
Porque después de un terremoto la pregunta cara no es “¿está dañado?”. La pregunta cara es ”¿puedes demostrar cómo estaba antes?” —ante la aseguradora, ante la propiedad, ante la administración, ante un juzgado si la cosa se pone fea. Un estado estructural registrado de forma no repudiable, con trazabilidad de quién midió qué, cuándo y con qué credenciales, es la diferencia entre una negociación de dos semanas y un pleito de tres años.
Ese es el problema real que resuelve un logbook descentralizado. No es una moda tecnológica: es prueba.
7. Conclusión
El enjambre de seísmos sigue activo. Hay gente en Granada que estos días duerme mal, y edificios con daños reales que no tienen un solo sensor puesto.
Un edificio del siglo XVI que sabe contar lo que le ha pasado no arregla nada de eso, pero convierte una decisión a ciegas en una decisión informada. Y en gestión de infraestructuras y sistemas complejos, eso es casi todo.
Y termino con la pregunta que de verdad me interesa, porque los proyectos más buenos que hemos hecho no salieron de un pliego, salieron de una conversación en la que alguien nos describió un problema que no sabíamos que existía.
7.1. ¿Se te ocurre algún caso de uso donde esto encajaría en lo tuyo? ¿Te gustaría probarlo?
Si trabajas con activos críticos —patrimonio, agua, energía, transporte, industria— y hay algo que llevas años decidiendo con menos información de la que te gustaría, cuéntanoslo. Aunque solo sea para decirte si esto sirve o no para tu caso, que a veces la respuesta honesta es que no.
