Reconstruir un modelo As-Built eléctrico a partir de información incompleta obliga a responder una pregunta que rara vez se formula a tiempo: ¿en qué momento dejó de saberse, con certeza, qué fue realmente lo que se construyó? Esta pregunta no surge al cierre de la obra. Surge, casi siempre, mucho antes: en el punto donde un cambio ejecutado en campo dejó de tener una relación clara con la decisión que lo originó, con la evidencia que lo sustenta o con el modelo que debía representarlo.
Este artículo se apoya en la experiencia de trabajar sobre modelos eléctricos BIM As-Built de instalaciones asociadas a un proyecto de infraestructura de gran escala. No describe la totalidad de ese proyecto, ni evalúa su gobernanza general: describe lo observado dentro del alcance específico de esa reconstrucción, y el aprendizaje técnico que de ahí puede sostenerse.
El As-Built que comienza demasiado tarde
Es habitual que un modelo As-Built se aborde como el último paso de un proyecto: una tarea de cierre, ejecutada una vez que la obra ya terminó, con el propósito de dejar constancia de lo construido. Esta manera de entenderlo tiene un costo que no siempre se anticipa. Cuando la reconstrucción comienza después de que la ejecución concluyó, quien la realiza depende por completo de lo que otros documentaron —o dejaron de documentar— mientras la obra avanzaba. Ninguna disciplina de reconstrucción posterior recupera, con la misma fidelidad, una condición que nunca quedó registrada en el momento en que ocurrió.
La experiencia observada en este caso confirma esa tensión. El trabajo sobre los modelos eléctricos As-Built partió de fuentes que debían, en conjunto, describir la condición construida: el modelo del proyecto ejecutivo, redlines, fotografías, boletines de cambios e información técnica asociada. Estas fuentes existían. El reto no fue su ausencia, sino su relación entre sí: reconstruir, a partir de fragmentos producidos en momentos y por actores distintos, una condición única y consistente.
Un modelo coordinado no necesariamente es lo construido
Una experiencia profesional más amplia, desarrollada con mayor detalle en el artículo sobre integración eléctrica, ayuda a explicar por qué esta brecha aparece. Cuando la coordinación se reduce a detectar y cerrar interferencias sin relacionar cada ajuste con responsable, criterio técnico, restricciones y constructibilidad, una solución puede quedar geométricamente libre y seguir siendo técnicamente deficiente.
Un ejemplo eléctrico es la multiplicación de bayonetas para liberar una ruta sin considerar adecuadamente la instalación real del cableado. Si la solución debe modificarse en campo y el cambio no regresa al sistema de información, se produce una ruptura entre el modelo coordinado y la condición ejecutada. La detección de interferencias sigue siendo útil; lo que no puede asumirse es que clash-free equivalga por sí solo a construible.
Cuando existen documentos, pero falta información
La lectura más precisa de esta experiencia no es que faltaran documentos. Existían modelo de proyecto ejecutivo, fotografías, redlines, boletines de cambios e información técnica. El problema real fue que su sola existencia no bastaba para reconstruir, sin ambigüedad, la condición ejecutada: disponibilidad documental no equivale a continuidad de información. Una fotografía puede existir y, aun así, resultar insuficiente si no puede determinarse con precisión qué muestra, qué elemento del modelo afecta, qué decisión documenta, por qué ocurrió el cambio que registra, quién lo aprobó, qué otro documento lo respalda o en qué revisión del modelo terminó representado.
Dentro del alcance observado, esa falta de relación se manifestó de maneras concretas. Existían fotografías sueltas sin identificación suficiente de qué elemento o condición documentaban. Existían redlines con anotaciones manuales cuya lectura no siempre resultaba clara, y en ocasiones una fotografía y un redline describían, aparentemente, la misma zona, sin coincidir entre sí. El proyecto original, en determinados puntos, carecía de información completa, y algunos parámetros cambiaban de estructura o de terminología entre un modelo y otro; ciertas tuberías carecían de información completa de circuito. Reconstruir una condición exigía, en más de un caso, cotejar varias fuentes distintas para llegar a una interpretación razonable.
Estas observaciones corresponden al alcance específico sobre el que se trabajó, no al proyecto completo, y no deben leerse como una caracterización general de la información disponible en el resto de la infraestructura.
Reconstruir la realidad desde fragmentos
Reconstruir el As-Built, en este contexto, exige cotejar de manera sistemática el modelo de proyecto, las redlines, las fotografías, los boletines, la información técnica disponible y el criterio de ingeniería. Estas fuentes no siempre coinciden entre sí. Cuando existe contradicción, la evidencia fotográfica de la condición ejecutada puede tener un peso importante, en particular cuando coincide con otra fuente independiente. Sin embargo, una fotografía aislada tampoco demuestra, por sí sola, todo el recorrido, el sistema completo o la totalidad de las características de una instalación: documenta un encuadre, en un momento, desde un ángulo determinado. Por esa razón, la reconstrucción no puede apoyarse en una sola fuente, sino en la relación entre múltiples evidencias que, contrastadas entre sí, permiten sostener una interpretación razonable de la condición construida.
El límite del criterio técnico
Esta distinción entre evidencia e inferencia es, quizá, el concepto más importante de todo el ejercicio de reconstrucción. Puede existir, por ejemplo, una ruta documentada que llega hasta un tablero, sin que exista detalle suficiente sobre cómo se ejecutó materialmente el remate final. El conocimiento de ingeniería eléctrica permite interpretar qué elementos deberían existir en esa llegada, cómo debería resolverse técnicamente, qué componentes son probablemente necesarios y cómo leer determinadas notas o indicaciones incompletas. Pero una inferencia técnicamente razonable no es, automáticamente, evidencia de la condición construida. Ocultar esta diferencia —tratar una interpretación experta como si fuera un hecho verificado— debilita, más que fortalece, la confiabilidad del As-Built resultante.
Como marco conceptual para este artículo, resulta útil distinguir tres estados posibles de una condición dentro de un modelo As-Built. Verificado: existe evidencia suficiente de la condición ejecutada. Inferido técnicamente: existe evidencia parcial y puede sostenerse una interpretación técnicamente razonable, aunque la condición no esté completamente demostrada. No determinado: la información disponible no permite establecer, de manera responsable, cuál fue la condición real. Estos tres estados se presentan aquí como un marco editorial y conceptual derivado de esta experiencia, no como una metodología oficial de SORA, un conjunto de parámetros obligatorios, un estándar ISO ni una funcionalidad de ningún sistema o plataforma.
La pérdida silenciosa de información
El problema que este artículo describe no es únicamente geométrico. Durante la transición entre diseño, coordinación, construcción y As-Built puede perderse información asociada a los elementos, incluso cuando su geometría permanece intacta. En sistemas eléctricos esto puede afectar circuitos, tablero de alimentación, cargas, información de cableado, contenido de canalizaciones, rutas, el equipo realmente instalado, su fabricante y modelo, sus fichas técnicas y otros parámetros asociados.
En determinados flujos BIM eléctricos —como ocurrió en parte de este caso, apoyado en Revit— la geometría de una canalización no representa por sí sola los conductores que contiene: parte de su significado técnico depende, por tanto, de los datos asociados al elemento, y no únicamente de su forma visible. Un elemento puede sobrevivir geométricamente en el modelo mientras pierde la información necesaria para interpretar correctamente su función. Esta observación no debe generalizarse como una condición que ocurra siempre ni en todo sistema: se presenta como un riesgo observado dentro de esta experiencia, relevante para cualquier proceso de reconstrucción As-Built que dependa de información paramétrica.
El As-Built debería comenzar con la construcción
La experiencia descrita permite sostener una tesis central: un As-Built confiable no se reconstruye al final de la obra. Se construye durante la ejecución, mediante un proceso continuo que documenta, valida, relaciona e incorpora los cambios de campo al sistema de información del proyecto. Una segunda idea precisa el alcance de la primera: no consiste únicamente en actualizar el modelo, sino en preservar la relación entre el cambio ejecutado, su causa, su autorización, su evidencia y la información que representa ese cambio. Un modelo puede actualizarse geométricamente y, aun así, perder esa relación; cuando eso ocurre, el modelo cambia, pero lo que este artículo entiende por continuidad no se preserva.
Esta distinción conduce a otra que conviene hacer explícita: un modelo de obra y un modelo As-Built no cumplen necesariamente la misma función, y por tanto no son, de manera automática, el mismo entregable. El modelo de obra sostiene la ejecución en curso; el As-Built debería documentar, de manera confiable, lo que finalmente quedó construido. Una forma de entender esta relación, derivada de la experiencia descrita, es que el modelo de obra llega a un cierre o estado controlado que se preserva como base para el As-Built, el cual se actualiza de manera continua durante la ejecución, se valida y finalmente se entrega. El As-Built debería, en consecuencia, comenzar a construirse desde el inicio de la construcción, no únicamente después de terminarla, incorporando de manera progresiva los cambios ejecutados, la evidencia fotográfica, las redlines, la documentación de aprobación, las fichas técnicas y demás evidencia relevante, según corresponda a cada caso. Esto no implica que toda esa información deba almacenarse físicamente dentro del modelo.
Preservar la relación entre campo y modelo
Lo anterior no equivale a guardar archivos. Una organización puede conservar una gran cantidad de documentos y, aun así, perder de vista la condición real ejecutada, si esos documentos dejan de relacionarse entre sí y con los elementos que describen. La ruptura puede producirse de maneras distintas: un cambio de contratista que se lleva consigo conocimiento y contexto no documentado; un cambio de responsables; un cambio de formato; información que se extravía durante una transición entre plataformas; un cambio ejecutado en campo que nunca regresa al modelo; una fotografía que sobrevive sin el contexto que le daría sentido; un documento que existe sin relación explícita con el elemento que debería describir; una modificación aprobada cuya representación digital nunca se actualiza. Preservar esa relación implica que la información siga siendo interpretable, trazable, localizable y utilizable, a través del tiempo, de los actores, de las herramientas, de las etapas y de los entregables del proyecto.
Esto no exige que el modelo contenga físicamente toda la documentación asociada a cada elemento. Exige que conserve relaciones o identificadores suficientes para llegar hasta la información asociada dentro del entorno común de datos del proyecto: una fotografía que documenta una condición, la incidencia que esa condición originó, la decisión tomada frente a ella, su aprobación, el elemento del modelo afectado, y la revisión correspondiente del modelo. No exige que toda la información viva dentro del modelo; exige que el modelo no pierda la relación con la información que le da significado.
Qué debería preservarse cuando cambia una condición de campo
A partir de esta experiencia puede sostenerse un principio de trabajo, no un procedimiento cerrado: cuando una condición de campo obliga a modificar una solución ya coordinada, debería preservarse la relación entre la condición identificada, la evidencia que la documenta, el motivo del cambio, la decisión tomada, su aprobación, el elemento del modelo afectado, la coordinación con las disciplinas involucradas, la ejecución en campo y, finalmente, la actualización del activo de información del proyecto. Cuando resulta viable, el cambio puede evaluarse primero en el modelo, antes de ejecutarse, para identificar posibles afectaciones interdisciplinarias. Ninguno de estos elementos sustituye el juicio profesional de quien coordina el cambio, ni esta secuencia debe entenderse como aplicable de manera universal a cualquier proyecto: es una forma de nombrar, a partir de este caso, qué relación debería preservarse para que un cambio ejecutado no quede desconectado del sistema de información que debía representarlo.
Una función explícita responsable de la continuidad
En proyectos de esta complejidad, difícilmente una sola persona puede observar campo, documentar condiciones, coordinar con otras disciplinas, modelar, actualizar parámetros, producir documentación y validar la información de todas las especialidades al mismo tiempo. La experiencia descrita no señala la ausencia de una persona en particular, sino la ausencia de una función explícitamente responsable de sostener esa relación entre la ejecución y el sistema de información del proyecto. Dependiendo de la escala del proyecto, de su estructura contractual, de su organización y de los recursos disponibles, esa responsabilidad podría recaer en uno o en varios perfiles distintos; este artículo no propone todavía un nombre institucional para ella.
Lo que sí puede describirse es su contenido. En proyectos complejos puede resultar necesaria una presencia dedicada en campo, capaz de documentar condiciones, estructurar la evidencia correspondiente, relacionarla con los elementos y las decisiones que la originan, canalizar incidencias, mantener comunicación con ejecución y coordinación, transferir los cambios identificados a los equipos BIM correspondientes y verificar que la información actualizada cierre el ciclo. El equipo que actualiza los modelos no necesita, por su parte, estar físicamente en campo: puede operar de manera distribuida o remota. La función en campo actúa, en ese esquema, como vínculo entre la realidad ejecutada y el sistema de información. Esta es una necesidad funcional que la experiencia descrita permite identificar, no la descripción de un sistema que SORA haya institucionalizado hasta la fecha.
Un As-Built debería declarar también lo que no sabe
Un As-Built reconstruido a partir de información incompleta debería reconocer los límites de certeza de su propio contenido. Un modelo que declara qué fue verificado, qué fue inferido y qué no pudo determinarse puede resultar más confiable que uno que presenta la totalidad de su información con el mismo grado aparente de certeza, ocultando así la diferencia real entre lo que se sabe y lo que se ha interpretado razonablemente. Un As-Built confiable no debería ocultar aquello que no sabe.
Esta idea no es una consigna: tiene una consecuencia técnica concreta. Un elemento marcado como inferido técnicamente, en lugar de presentarse como si estuviera verificado, permite a quien opera o interviene posteriormente esa instalación decidir si requiere una validación adicional antes de actuar sobre ella. Un elemento marcado como no determinado evita que una decisión de mantenimiento, operación o modificación futura se apoye, sin saberlo, en una suposición no verificada. La utilidad de declarar la incertidumbre no es documental: es operativa.
Continuidad como condición del activo de información
La pérdida de esta continuidad entre ejecución y sistema de información puede afectar, entre otros aspectos, el mantenimiento y la operación de la instalación, la planeación de futuras modificaciones o intervenciones, la identificación correcta de lo instalado, la comprensión general de la condición construida y, de manera menos directa pero real, la exposición a retrabajos, costos posteriores o discusiones documentales o contractuales. Este artículo no cuantifica esos impactos: la experiencia que lo sustenta no permite hacerlo de manera responsable, y las observaciones aquí reunidas corresponden al alcance eléctrico As-Built descrito, no a una evaluación de la gobernanza general del proyecto.
Lo que sí puede sostenerse, con el respaldo de esa experiencia, es que la información disponible para el alcance observado presentaba vacíos, ambigüedades y discontinuidades; que esa condición dificulta reconstruir un As-Built confiable; que el conocimiento técnico permite interpretar información parcial, sin que esa interpretación equivalga a evidencia de lo construido; y que preservar la relación entre campo y sistema de información durante la ejecución reduciría, de manera razonable, la necesidad de reconstrucción posterior.
El objetivo de un As-Built no debería ser producir un modelo que parezca terminado. Debería ser preservar una representación confiable de aquello que realmente fue construido. Esa distinción —entre parecer completo y ser confiable— es, en última instancia, la que determina el valor real de la información que un proyecto deja detrás de sí.
Etiquetas
