Entienda qué es un CDE BIM, cómo funciona un Entorno Común de Datos según ISO 19650 y cómo controlar revisiones, estados, aprobaciones, accesos, entregas y trazabilidad.
¡Descúbrelo!
Un proyecto puede tener todos los archivos centralizados en una plataforma en la nube y aun así operar con información poco confiable. Basta imaginar un equipo con tres versiones del mismo proyecto eléctrico llamadas ELETRICA_FINAL.pdf, ELETRICA_FINAL_02.pdf y ELETRICA_REV3_APROVADO.pdf. Todos los documentos están en el mismo repositorio, pero nadie puede responder con seguridad qué revisión es válida para coordinación, cuál solo fue verificada internamente, cuál está autorizada para ejecución, quién aprobó el cambio o qué versión fue sustituida.
Este escenario muestra por qué CDE BIM — Common Data Environment, o Entorno Común de Datos — no debe entenderse como sinónimo de carpeta compartida, drive corporativo o software de almacenamiento. El CDE forma parte del proceso de gestión de la información: debe sostener identificación, estados, revisiones, clasificación, permisos, transiciones, registros de responsabilidad y criterios que permitan saber no solo dónde está la información, sino en qué condición puede utilizarse.
La ABNT NBR ISO 19650-2 trata el CDE como infraestructura necesaria para la producción colaborativa de información. La norma establece que el entorno debe permitir la identificación única de los contenedores de información, la codificación acordada, la asignación de estado, revisión y clasificación, la transición controlada entre estados, el registro de usuario y fecha y el control de acceso a nivel del contenedor. Después, el mismo proceso normativo conecta el CDE con la verificación de calidad, revisión, aprobación para compartir, autorización, aceptación y archivo.
La tesis de este artículo es directa: un CDE solo genera valor cuando transforma el almacenamiento en gobernanza operativa de la información. La tecnología es necesaria, pero el resultado depende de requisitos, roles, reglas de transición, metadatos, criterios de aceptación y disciplina de uso.
El CDE no es simplemente “dónde está el archivo”. Es el entorno que permite saber qué información es válida, en qué revisión, para qué finalidad, bajo responsabilidad de quién y con qué evidencia de aprobación o aceptación.
Qué es un CDE BIM y por qué no es solo una carpeta en la nube
CDE es la sigla de Common Data Environment, expresión normalmente traducida como Entorno Común de Datos. En el contexto de la gestión de la información BIM, el CDE funciona como el entorno en el que los contenedores de información se producen, comparten, revisan, autorizan, aceptan y preservan de forma controlada.
El término “contenedor de información” es importante porque el CDE no trabaja únicamente con modelos tridimensionales. Un contenedor puede ser un modelo BIM, un plano, una memoria técnica, una hoja de cálculo, un informe, una especificación, un archivo de cálculo, un registro u otro conjunto identificable de información que forme parte del proceso de entrega.
Por eso, la discusión sobre CDE es más amplia que elegir una plataforma BIM. El problema real es crear una fuente controlada de información para el proyecto.
Centralización no es lo mismo que control
Considere una obra con arquitectura, estructura, electricidad, climatización y gestión. Todos los equipos reciben acceso al mismo almacenamiento en la nube. Cada proyectista crea sus propias carpetas y publica archivos cuando considera que una revisión está lista.
En pocas semanas aparecen archivos como:
ARQ_FINAL.rvt
ARQ_FINAL_NOVO.rvt
ARQ_REV04_COORD.rvt
ESTRUTURA_OK.ifc
ELETRICA_APROVADO.dwg
ELETRICA_APROVADO_CORRIGIDO.dwg
La centralización existe. La gobernanza, no.
El equipo todavía necesita descubrir, mediante interpretación humana, qué archivo está vigente, qué significa “OK”, quién autorizó “APROBADO”, si la revisión anterior sigue siendo válida, si el documento es solo para coordinación o para ejecución y quién debe ser informado cuando una versión es sustituida.
Este tipo de proceso funciona mientras el proyecto es pequeño, las personas se conocen y la memoria del equipo resuelve las ambigüedades. En proyectos multidisciplinarios, contratos largos, múltiples empresas o cambios de profesionales, se convierte en un riesgo de ingeniería.
La pregunta central del CDE es: “¿para qué puede utilizarse esta información?”
Imagine que el proyectista eléctrico terminó una revisión del modelo. Antes de compartirla con las demás disciplinas, su propio equipo todavía necesita verificar nomenclatura, parámetros obligatorios, consistencia técnica y coordinación interna.
El archivo existe, pero todavía no debe ser utilizado por otras disciplinas.
Más tarde, el equipo concluye la revisión interna y libera el modelo para coordinación. La información ahora puede utilizarse como referencia por los demás equipos, pero eso no significa necesariamente que esté autorizada para ejecución de la obra.
En otro momento, un determinado conjunto de documentos puede ser autorizado como entrega formal.
Por lo tanto, el CDE debe permitir distinguir la condición de uso de la mera existencia del archivo.
La diferencia puede parecer administrativa, pero tiene efecto técnico. Un equipo de climatización que coordina ductos contra una revisión eléctrica todavía en desarrollo puede generar decenas de interferencias falsas. Una constructora que utiliza un plano compartido para coordinación como si estuviera liberado para ejecución puede materializar una solución aún no autorizada.
Un CDE no es un producto específico
Otro error frecuente es transformar la sigla CDE en sinónimo de una determinada plataforma comercial.
Existen softwares capaces de soportar workflows de CDE, control documental, modelos, revisiones, aprobaciones, issues, permisos e historial. Pero el concepto de CDE no pertenece a un fabricante específico.
Una solución tecnológica debe evaluarse frente a los requisitos del proceso. Debe sostener el flujo establecido para ese proyecto, con los permisos, metadatos, transiciones, registros e integraciones necesarios.
Esta distinción también es importante en la contratación. Escribir “usar plataforma X” no sustituye la definición de cómo se identificará, clasificará, verificará, compartirá, autorizará y aceptará la información.
La propia ABNT NBR ISO 19650-2 prevé que la parte requirente pueda alojar y gestionar el CDE directamente, contratar a un tercero o transferir posteriormente determinadas funciones a una parte proveedora líder. El requisito es funcional: el entorno debe atender al proceso establecido.
Un CDE puede ser distribuido
Otro punto relevante es que Entorno Común de Datos no significa obligatoriamente “un único sistema físico donde ocurre todo”. La ABNT NBR ISO 19650-2 contempla, durante la movilización, la configuración y prueba del CDE del proyecto y también de un CDE distribuido del equipo de entrega, incluida su conexión con el entorno del proyecto cuando corresponda.
Esto corresponde mejor a la realidad de muchos proyectos. Una empresa de diseño puede tener su entorno interno de producción; el coordinador puede utilizar una plataforma específica para federación e issues; el contratante puede mantener el entorno oficial de entrega. El desafío es garantizar que las fronteras y los intercambios estén controlados.
La gobernanza debe responder:
1. dónde se produce la información; 2. en qué momento sale del entorno interno; 3. qué verificaciones ocurren antes de compartir; 4. cómo entra la información en el CDE oficial; 5. quién puede utilizarla y para qué finalidad; 6. cómo se registran revisiones y sustituciones; 7. cómo se autoriza y acepta la entrega final.
Sin esta definición, múltiples plataformas solo multiplican los puntos de incertidumbre.
El valor del CDE está en la confianza, no en el volumen almacenado
Un CDE con terabytes de documentos puede ser técnicamente peor que un entorno más pequeño y bien gobernado.
La métrica de éxito no es la cantidad de archivos. Es la capacidad de responder preguntas como:
- ¿cuál es la revisión vigente?
- ¿cuál es el estado de esa información?
- ¿quién es el autor responsable?
- ¿quién verificó y aprobó?
- ¿cuándo ocurrió la transición de estado?
- ¿qué clasificación fue aplicada?
- ¿quién tiene acceso?
- ¿para qué uso está liberada la información?
- ¿qué fue sustituido?
- ¿qué evidencia demuestra la aceptación?
Cuando estas respuestas son trazables, el CDE deja de ser un repositorio y pasa a funcionar como infraestructura de decisión.
El artículo sobre Gestión de la Información en BIM e ISO 19650 presenta el proceso más amplio en el que se inserta el CDE. Aquí, el foco es entender cómo esta infraestructura se materializa en el flujo cotidiano del proyecto.
Cómo funciona el flujo de información dentro de un CDE
Un CDE maduro no trata todos los archivos como equivalentes. La información atraviesa estados y puntos de control a medida que madura.
En la práctica, distintas organizaciones pueden adoptar nomenclaturas o implementaciones específicas, pero el principio es estable: una información en elaboración no debe tener la misma condición de uso que una información revisada, compartida, autorizada o aceptada.
Trabajo en curso: la información todavía pertenece al equipo autor
Al inicio del flujo, el equipo produce su información en un entorno de trabajo.
Imagine el modelo eléctrico de un edificio. El proyectista está ajustando rutas de bandejas portacables, posición de cuadros, alimentadores y espacios técnicos. Durante esta etapa, el equipo puede guardar decenas de veces al día. Parte de los cambios está incompleta. Algunos objetos fueron desplazados provisionalmente. Otros todavía esperan un cálculo o una decisión del coordinador.
Sería inadecuado que cada guardado se transformara automáticamente en referencia para arquitectura, estructura y climatización.
La información de trabajo debe permanecer claramente identificada como en desarrollo hasta superar las verificaciones establecidas.
Esto no significa ocultar el proyecto. Significa preservar la responsabilidad del autor e impedir que información provisional sea interpretada como referencia válida.
La verificación y el aseguramiento de la calidad vienen antes de compartir
La ABNT NBR ISO 19650-2 determina que cada equipo realice verificaciones de aseguramiento de la calidad de sus contenedores antes de la revisión para compartir.
Esta distinción es importante porque “el archivo abre” no significa “el archivo cumple”.
La verificación puede comprobar, por ejemplo:
- convención de identificación;
- presencia de los metadatos obligatorios;
- estructura del contenedor;
- estándares de información;
- requisitos de nomenclatura;
- integridad del archivo;
- propiedades o clasificaciones exigidas;
- consistencia con los procedimientos de la organización.
Parte de estas verificaciones puede automatizarse. Pero la propia norma advierte, en esencia, que la verificación de conformidad no sustituye la revisión y aprobación de la adecuación técnica de la información.
Esto produce una distinción útil:
verificación de conformidad responde si el contenedor sigue las reglas establecidas;
revisión técnica responde si la información es adecuada para el uso previsto.
Un modelo puede estar perfectamente nombrado, clasificado y completado y aun así contener una solución de ingeniería incorrecta.
Aprobar para compartir no es lo mismo que autorizar como entrega
Después de la verificación, el equipo revisa la información y decide si puede compartirse.
Considere nuevamente el modelo eléctrico. El equipo concluyó el análisis interno y entiende que esa revisión puede ser utilizada por estructura y HVAC para coordinación. Entonces asigna el estado correspondiente y libera la información en el flujo.
A partir de ese momento, otros participantes pueden utilizarla de acuerdo con la finalidad definida.
Sin embargo, compartir no debe confundirse con la autorización final del modelo de información.
En el proceso de la ABNT NBR ISO 19650-2, antes de la entrega a la parte requirente, los equipos someten su información a la parte proveedora líder para autorización. La parte líder verifica el modelo frente al MIDP, los requisitos de intercambio, los criterios de aceptación y el nivel necesario de información.
Solo después de esta autorización la información pasa a revisión y aceptación por la parte requirente.
Esta secuencia crea controles diferentes:
producción del equipo → verificación → revisión → intercambio → coordinación → presentación → autorización → aceptación.
Un buen CDE debe sostener estas diferencias sin depender de nombres improvisados en el archivo.
Ejemplo completo: desde la revisión eléctrica hasta la aceptación del contratante
Considere el contenedor ELE-Z01-M3, correspondiente al modelo eléctrico de una zona determinada.
El equipo eléctrico produce la revisión R05 en su entorno de trabajo. Durante la producción, el archivo no debe ser utilizado por las demás disciplinas porque contiene cambios todavía no verificados.
Cuando el equipo concluye la revisión, ejecuta las verificaciones previstas. El modelo tiene identificación correcta, clasificación, parámetros requeridos y estructura válida. Luego, el responsable técnico revisa el contenido y aprueba R05 para compartir.
Arquitectura, estructura y HVAC comienzan a utilizar R05 en la coordinación. Surgen dos cuestiones: una bandeja portacables interfiere con una viga y un panel tiene una zona de mantenimiento insuficiente. Las issues regresan al equipo eléctrico.
El equipo corrige el modelo y produce R06. La nueva revisión vuelve a pasar por verificación y revisión antes de ser compartida.
Al alcanzar el hito de entrega, la parte proveedora líder consolida los contenedores previstos en el MIDP y verifica el modelo de información. Si la entrega cumple los requisitos, se autoriza para su presentación al contratante.
La parte requirente revisa entonces el paquete frente a sus requisitos y criterios de aceptación. Si es aceptado, ese conjunto pasa a constituir un entregable formal.
Observe que el mismo “modelo eléctrico” atravesó varias condiciones de uso. El CDE debe hacer que esta historia sea trazable.
Revisión, estado y finalidad no son sinónimos
Este punto evita muchos errores.
Revisión indica una evolución del contenedor.
Estado indica su condición dentro del flujo.
Finalidad o adecuación indica para qué uso está liberado.
Una revisión más nueva no es automáticamente la revisión válida para cualquier finalidad.
Por ejemplo, R06 puede estar en desarrollo mientras R05 continúa siendo la última revisión aprobada para coordinación. Si la plataforma simplemente ordena por fecha y muestra “R06” como el archivo más reciente, un participante puede utilizar información que todavía no ha sido liberada.
El CDE debe preservar la diferencia entre más reciente y vigente para un uso determinado.
Más reciente no significa automáticamente vigente. Una nueva revisión puede continuar en desarrollo mientras la anterior sigue siendo válida para coordinación, ejecución u otro uso definido.
La transición debe dejar trazabilidad
La ABNT NBR ISO 19650-2 requiere que el CDE registre el nombre del usuario y la fecha cuando las revisiones de los contenedores transitan entre estados.
Este registro tiene valor técnico, contractual y de gestión.
Si una obra ejecutó determinada solución, el equipo debe ser capaz de reconstruir qué información estaba autorizada en ese momento. Si una revisión fue sustituida, debe ser posible identificar la transición. Si hubo una aprobación equivocada, el historial debe mostrar quién realizó la acción y cuándo.
Sin historial, la plataforma puede presentar la situación actual, pero no explica cómo llegó el proyecto hasta ella.
Archivar no es simplemente mover archivos antiguos a otra carpeta
Al final de la fase de entrega, la ABNT NBR ISO 19650-2 determina el archivo del conjunto de contenedores aceptados en el CDE, considerando futuras necesidades para el modelo de información del activo, requisitos de acceso, reutilización y políticas de retención.
Esto significa que el cierre debe preservar el contexto.
Un archivo antiguo sin metadatos, estado, revisión, autoría o vínculo con la entrega puede tener poco valor años después. En cambio, un conjunto archivado con trazabilidad permite auditoría, mantenimiento, retrofit, ampliación, disputas contractuales y reconstrucción de la historia técnica.
Aquí es donde el CDE comienza a conectarse con el As-Built en Ingeniería y con la gobernanza del activo durante la operación.
Qué debe controlar un CDE para ser confiable
Una plataforma puede tener decenas de funcionalidades y aun así fallar en los controles básicos. Por eso, la evaluación de un CDE debe comenzar por las dimensiones de gobernanza, no por el catálogo comercial del software.
La ABNT NBR ISO 19650-2 ofrece una base particularmente objetiva al exigir identificador único, codificación, estado, revisión, clasificación, transiciones registradas y acceso controlado a nivel del contenedor.
La tabla siguiente traduce estos fundamentos en preguntas de ingeniería.
| Dimensión | Qué debe controlar el CDE | Pregunta de auditoría |
| identificación | código único del contenedor | ¿es posible distinguir inequívocamente este documento/modelo? |
| codificación | valores estandarizados de los campos | ¿todos utilizan la misma convención o cada empresa inventa su propia nomenclatura? |
| revisión | evolución del contenedor | ¿qué revisión está vigente y cuáles fueron sustituidas? |
| estado/adecuación | condición de uso | ¿esta información puede utilizarse para trabajo interno, coordinación, autorización o ejecución? |
| clasificación | contexto y organización de la información | ¿la clasificación permite localizar, filtrar e interpretar el contenido? |
| autoría | responsable de la producción | ¿quién responde por la información? |
| transición | cambio entre estados | ¿quién modificó la condición de uso y cuándo? |
| acceso | lectura, modificación y aprobación | ¿cada participante tiene únicamente la autoridad necesaria? |
| historial | registro de las transacciones | ¿es posible reconstruir la secuencia de decisiones? |
| aceptación | resultado de la revisión del entregable | ¿existe evidencia de que el requisito fue cumplido? |
La identificación única evita que el nombre del archivo cargue toda la inteligencia
En entornos informales, las personas intentan colocar en el nombre del archivo todo aquello que el sistema no controla.
Aparecen nombres como:
ELETRICA_BLOCOA_EXECUTIVO_REV4_APROVADO_FINAL_07-08-26.pdf
El nombre intenta informar disciplina, ubicación, fase, revisión, estado y fecha al mismo tiempo.
El problema es que cada persona puede interpretar o escribir de manera diferente. Pequeñas diferencias rompen filtros y automatizaciones. Un equipo usa ELE; otro EL; otro ELETRICA. Un participante escribe REV04; otro R4.
En el CDE, la identificación debe seguir una convención acordada y documentada, con campos y códigos consistentes. El nombre deja de ser una narrativa libre y pasa a formar parte de un sistema de información.
La revisión debe controlarse sin borrar la historia
Sobrescribir el archivo anterior y conservar únicamente la última copia reduce la trazabilidad.
Un proceso de ingeniería necesita saber qué cambió y en qué secuencia. Esto es especialmente importante cuando diferentes revisiones fueron utilizadas en reuniones, compras, ejecución o aprobación.
La gestión adecuada de revisiones no significa que todos tengan acceso irrestricto a todas las versiones. Significa que el sistema preserva la historia y presenta la revisión correcta según el contexto y los permisos.
El estado debe tener significado operativo
Una etiqueta solo genera valor cuando cambia el comportamiento del proceso.
Si “compartido” y “autorizado” aparecen como dos nombres distintos, pero cualquier usuario puede tratar ambos de la misma manera, la gobernanza es meramente decorativa.
Los estados deben estar asociados a reglas:
- quién puede promover la información;
- qué verificaciones son necesarias antes de la transición;
- quién puede utilizar el contenedor después de la transición;
- para qué finalidad puede utilizarse;
- qué registro queda grabado;
- cómo ocurre el rechazo o retorno para corrección.
Esta lógica transforma el workflow en un mecanismo de control.
Estado sin regla es solo una etiqueta. Para generar gobernanza, cada transición necesita tener autoridad, verificaciones, condición de uso y registro de auditoría claramente definidos.
La clasificación permite encontrar y reutilizar información de forma consistente
La ABNT NBR ISO 19650-2 relaciona la clasificación del contenedor con la estructura definida por la ABNT NBR ISO 12006-2.
En la práctica, la clasificación es una capa adicional de significado. Ayuda a organizar información por sistemas, elementos, tipos u otras estructuras necesarias para el proyecto y el activo.
La cuestión es similar a la discutida en el artículo sobre Clasificación de la Información en BIM y NBR 15965: cuando los equipos utilizan conceptos diferentes para describir la misma cosa, la búsqueda, integración y reutilización se deterioran.
El acceso no debe ser “todos editan todo”
Colaboración no significa ausencia de control.
Un proyectista necesita editar los contenedores bajo su responsabilidad. Un coordinador puede necesitar revisar y comentar. Una parte proveedora líder puede tener autoridad para autorizar. El contratante puede necesitar aceptar. Otros participantes pueden tener acceso solo de lectura.
Si cualquier usuario puede modificar un entregable aceptado, el valor de la aceptación se reduce.
Por eso, el acceso debe diseñarse al nivel necesario, considerando lectura, escritura, revisión, transición de estado, autorización y administración.
La norma también prevé que la parte requirente especifique requisitos funcionales y no funcionales cuando el alojamiento, gestión o soporte del CDE sea contratado a terceros. Esto abre espacio para criterios como disponibilidad, desempeño, seguridad, interoperabilidad, retención y continuidad, según el contexto del proyecto.
Los metadatos forman parte de la ingeniería de la información
Un archivo contiene contenido. Los metadatos explican el contexto de ese contenido.
Disciplina, zona, tipo de contenedor, revisión, estado, clasificación, autoría y finalidad son ejemplos de información que permite filtrar, controlar y automatizar el entorno.
Imagine un proyecto con 15 mil contenedores. Navegar manualmente por carpetas es insuficiente. El equipo necesita consultar, por ejemplo:
todos los documentos eléctricos de la zona 03, en una revisión determinada, autorizados para una finalidad determinada y modificados después de un hito específico.
Esto solo es confiable si los metadatos están estructurados.
El CDE debe controlar la información sin crear burocracia inútil
Una gobernanza excesivamente compleja también falla.
Si cada transición exige veinte campos, cinco aprobaciones y tareas que no alteran el riesgo ni la calidad, los usuarios comienzan a buscar atajos. Surgen hojas de cálculo paralelas, correos electrónicos de aprobación y comparticiones externas al entorno oficial.
El proceso debe ser proporcional a la complejidad, riesgo y necesidad del proyecto.
Los proyectos pequeños pueden operar con workflows más simples. Los grandes programas de capital, infraestructuras críticas, data centers, hospitales o proyectos con múltiples contratistas pueden exigir controles más sofisticados.
El principio es mantener control suficiente para que la información sea confiable, sin transformar el CDE en un obstáculo para la producción.
CDE, ISO 19650 y los demás instrumentos de gestión de la información
El CDE no funciona de manera aislada. Es la infraestructura operativa de un sistema más amplio de requisitos, responsabilidades y planes de entrega.
En la ABNT NBR ISO 19650-2, la parte requirente primero establece necesidades, requisitos de información, hitos de entrega, estándares, métodos y procedimientos, información de referencia y recursos compartidos. En este contexto, establece el CDE y el protocolo de información.
Después, los equipos responden a la contratación, desarrollan y confirman el BEP, detallan responsabilidades y estructuran TIDP y MIDP. Durante la movilización, la tecnología y el CDE se configuran y prueban. Solo entonces la producción colaborativa ocurre de manera controlada.
Esta secuencia explica por qué simplemente comprar software al inicio del proyecto rara vez resuelve el problema.
Los requisitos dicen qué debe entregarse; el CDE sostiene cómo se controla la entrega
Un contratante puede necesitar recibir un modelo federado en un hito determinado, con propiedades específicas, documentación asociada y criterios de aceptación definidos.
Ese requisito no nace del CDE. Nace de la necesidad de información de la organización, del proyecto o del activo.
El CDE actúa como infraestructura para garantizar que los contenedores producidos frente a ese requisito sean identificados, revisados, compartidos, autorizados y aceptados de forma trazable.
Por lo tanto:
un requisito sin CDE puede producir entregas difíciles de controlar;
un CDE sin requisito puede controlar perfectamente información que nadie necesitaba producir.
Las dos capas deben estar conectadas.
El BEP organiza la estrategia de gestión de la información
El BEP BIM explica cómo el equipo de entrega pretende conducir los aspectos de gestión de la información del encargo.
En el BEP pueden aparecer la estrategia de entrega, roles, responsabilidades, federación, estándares, métodos, procedimientos, software, hardware e infraestructura de TI.
El CDE es el entorno en el que una parte relevante de estas reglas se vuelve operativa.
Si el BEP indica que los modelos deben pasar por una determinada verificación antes de la federación, el workflow del CDE debe soportar esa regla. Si define una convención de identificación, el entorno debe aplicarla. Si establece responsables de aprobación, los permisos deben reflejar esos roles.
Un BEP desconectado del CDE se convierte en un documento de intención. Un CDE desconectado del BEP se convierte en una herramienta sin proceso.
BEP y CDE deben estar conectados. El BEP define reglas de gestión de la información; el CDE debe transformar esas reglas en identificación, permisos, transiciones, entregas y evidencias controlables.
TIDP y MIDP transforman las entregas en compromisos planificados
Cada equipo de tareas desarrolla su TIDP — Task Information Delivery Plan, indicando los contenedores que producirá, dependencias, nivel necesario de información, duración, autor responsable y fechas de entrega.
La parte proveedora líder combina estos planes en el MIDP — Master Information Delivery Plan.
El CDE debe estar alineado con esta planificación.
Imagine que el MIDP prevé la entrega del modelo eléctrico, memoria de cálculo y diagrama unifilar para una fecha-hito determinada. La plataforma puede contener cientos de archivos eléctricos, pero el proceso debe reconocer qué contenedores constituyen formalmente esa entrega.
Esta relación permite medir la integridad, identificar retrasos, revisar el paquete y registrar la aceptación.
CDE y modelo federado: compartir no significa mezclar autorías
En la coordinación BIM, los modelos de diferentes disciplinas pueden federarse para realizar análisis conjuntos.
El CDE proporciona los contenedores compartidos con el estado adecuado. El coordinador utiliza esta información para componer el modelo federado y realizar análisis.
Esto no significa que el coordinador pase a ser autor de los modelos disciplinares.
Si se encuentra una interferencia entre una bandeja portacables y la estructura, la issue vuelve a los equipos responsables. El proyectista corrige su información en el origen, pasa nuevamente por el workflow y publica una nueva revisión.
Esta lógica preserva la responsabilidad y se conecta directamente con los artículos sobre Open BIM, Archivo IFC y Clash Detection.
CDE y LOD/LOIN: el entorno debe saber qué debería estar allí
El artículo sobre LOD BIM y LOIN mostró que calidad no significa producir el máximo nivel de detalle posible.
De la misma manera, el CDE no debe premiar el volumen de información.
Una entrega debe evaluarse frente al nivel necesario de información. La ABNT NBR ISO 19650-2 exige que los criterios de aceptación consideren el nivel necesario para cada requisito.
Esto cambia la auditoría. No basta preguntar “¿el archivo está en el CDE?”. Es necesario preguntar:
¿el contenedor entregado contiene la información que debería contener para este hito y esta finalidad?
CDE, PIM, AIM y transición a la operación
Durante la fase de entrega, el modelo de información del proyecto — PIM — se desarrolla progresivamente. Al cierre, la información relevante puede alimentar el modelo de información del activo — AIM — para apoyar la operación y el mantenimiento.
El CDE debe preservar esta continuidad.
La ABNT NBR ISO 19650-2 orienta que, después de la aceptación del modelo de información del proyecto concluido, los contenedores se archiven considerando aquello que será necesario como parte del AIM, el acceso futuro, la reutilización y la retención.
Esto convierte el cierre en un problema de gobernanza, no únicamente de backup.
Un As-Built sin historial de aprobación, documentos de proveedores sin asociación al activo, modelos sin revisión válida o registros dispersos por correo electrónico reducen la calidad de la transición.
Este punto crea un puente directo entre el CDE, el As-Built de Ingeniería y la gestión documental a lo largo del ciclo de vida.
CDE y ENGiOS: gobernanza más allá del proyecto
El CDE es particularmente importante durante el flujo de producción y entrega de la información de un proyecto. Pero las organizaciones de ingeniería enfrentan desafíos más amplios: contratos, documentos técnicos, revisiones, evidencias, aceptación, As-Built, activos, historial de proyectos y conocimiento institucional.
Por eso, el CDE puede entenderse como una capa de una arquitectura más amplia de gobernanza técnica digital.
La solución Entorno Común de Datos y Gestión de la Información BIM estructura específicamente requisitos, procesos, responsabilidades y tecnología para el CDE. Por su parte, ENGiOS™ amplía la discusión hacia la gestión técnica, documentación y gobernanza de ingeniería.
La conexión no debe basarse en una promesa genérica de software. El criterio sigue siendo el mismo: cada capa tecnológica debe atender los requisitos y procesos que la organización realmente pretende gobernar.
Cómo implementar, auditar y evitar los errores más comunes en un CDE
Implantar un CDE no comienza creando carpetas. Comienza definiendo el proceso que esas carpetas, metadatos, permisos y workflows deberán soportar.
La secuencia más defendible es:
necesidad → requisitos → roles → estándar de información → contenedores → metadatos → estados → transiciones → permisos → tecnología → pruebas → movilización → producción → auditoría.
Este orden reduce el riesgo de adaptar la ingeniería a las limitaciones de una herramienta elegida demasiado pronto.
1. Defina el objetivo del entorno
Antes de configurar cualquier plataforma, determine qué debe resolver el CDE.
El objetivo puede incluir coordinación multidisciplinaria, entrega documental, gestión de modelos, aprobación técnica, control de revisiones, recepción de contratistas, transición a la operación o una combinación de estos usos.
Un entorno orientado únicamente a la coordinación de diseño tendrá requisitos diferentes de un CDE destinado a un programa de capital con decenas de contratos y transición a la gestión de activos.
La pregunta no es “¿qué software vamos a utilizar?”. La pregunta inicial es:
¿qué decisiones y entregas necesitan estar respaldadas por la información?
2. Defina responsables y autoridad
Todo workflow necesita roles claros.
¿Quién administra el CDE?
¿Quién define los estándares?
¿Quién crea usuarios?
¿Quién puede modificar metadatos?
¿Quién aprueba para compartir?
¿Quién autoriza las entregas?
¿Quién acepta en nombre del contratante?
¿Quién gestiona los rechazos?
¿Quién preserva el archivo al cierre?
Estas funciones pueden distribuirse entre el contratante, la gerencia, proyectistas, constructora y terceros. Lo importante es evitar autoridad implícita.
3. Estructure identificación, clasificación y metadatos antes de migrar archivos
Crear miles de documentos antes de cerrar la taxonomía genera retrabajo.
El equipo debe definir las convenciones y códigos que se utilizarán en el entorno. Esto incluye campos suficientes para distinguir los contenedores y permitir filtros relevantes.
El principio es encontrar equilibrio. Pocos metadatos generan ambigüedad; demasiados metadatos generan baja adopción y llenado inconsistente.
Una pregunta práctica ayuda:
¿qué filtros serán necesarios para localizar, revisar, entregar y auditar la información?
Si nadie utiliza un determinado campo para decisiones, automatización, búsqueda o control, tal vez no debería ser obligatorio.
4. Modele los estados y las transiciones
El workflow debe diseñarse antes de automatizarse.
Para cada transición, defina:
- estado de origen;
- estado de destino;
- responsable de la acción;
- verificaciones previas;
- campos obligatorios;
- condición de uso resultante;
- notificación necesaria;
- posibilidad de rechazo;
- registro de auditoría.
Esto transforma el flujo en un proceso verificable.
Un ejemplo:
| Transición | Responsable | Verificación mínima | Resultado |
| producción → listo para revisión | autor | campos y archivo completos | contenedor disponible para el revisor interno |
| revisión → intercambio | responsable del equipo | conformidad + adecuación técnica | referencia disponible para coordinación |
| compartido → presentación | parte proveedora | issues resueltas e hito cumplido | entrega lista para autorización |
| presentación → autorizado | parte proveedora líder | MIDP + EIR + criterios de aceptación | paquete autorizado para el contratante |
| autorizado → aceptado | parte requirente | requisitos y criterios de aceptación | entregable formalmente aceptado |
La tabla es ilustrativa. El workflow real debe reflejar el contrato y la gobernanza definida para cada proyecto.
5. Configure permisos coherentes con la responsabilidad
Una plataforma puede tener un workflow perfecto en el papel y fallar porque los usuarios poseen privilegios excesivos.
Si un autor puede aprobar su propio documento cuando debería existir segregación de funciones, el control pierde fuerza. Si cualquier participante puede eliminar evidencias o modificar información ya aceptada, la trazabilidad queda comprometida.
Los permisos deben probarse por escenario, no solo verificarse en una matriz.
Cree usuarios de prueba con roles diferentes y simule creación, edición, lectura, intercambio, rechazo, autorización, aceptación, sustitución y archivo.
6. Pruebe el CDE antes de la producción real
La movilización es un punto explícito de la ABNT NBR ISO 19650-2. La parte proveedora líder debe configurar y probar software, hardware e infraestructura de TI, el CDE del proyecto, posibles entornos distribuidos, intercambios entre equipos y la entrega a la parte requirente.
Esto significa que el primer hito crítico no debe ser la primera prueba real del proceso.
Un piloto puede utilizar un paquete pequeño de documentos y modelos para verificar convención de identificación, permisos, notificaciones, revisión, rechazo, transiciones, descarga y visualización, interoperabilidad, auditoría, informes, comportamiento de revisiones sustituidas y consulta del historial.
Los problemas encontrados en esta etapa cuestan mucho menos que los problemas descubiertos durante una entrega contractual.
7. Capacite sobre el proceso, no solo sobre la interfaz
Enseñar “dónde hacer clic” es insuficiente.
El usuario necesita comprender por qué no debe compartir información en desarrollo, qué significa determinado estado, cuándo una revisión sustituye a otra y qué consecuencias existen al autorizar un entregable.
Sin esta comprensión, el equipo utiliza la plataforma como un drive sofisticado.
La capacitación debe incluir escenarios de ingeniería. Por ejemplo:
“Usted es el proyectista eléctrico. Terminó R04, pero la verificación encontró propiedades obligatorias ausentes. ¿Qué debe ocurrir?”
“Usted es el coordinador. Existe R05 en elaboración y R04 compartida. ¿Cuál puede entrar en la federación?”
“Usted es la parte requirente. El paquete fue autorizado por la parte líder, pero falta evidencia de un requisito. ¿Lo acepta o lo rechaza?”
Este tipo de ejercicio crea comprensión operativa.
8. Audite el comportamiento real del entorno
Un CDE puede estar bien configurado y ser mal utilizado.
La auditoría debe observar no solo la configuración, sino también el comportamiento real de los usuarios.
Indicadores útiles incluyen contenedores sin identificación válida, revisiones duplicadas, estados incompatibles con la fase, entregas sin responsable, rechazos sin justificación, aprobaciones fuera del workflow, archivos enviados por correo electrónico en paralelo, permisos excesivos, elementos compartidos sin verificación, entregables vencidos en el MIDP e información aceptada sin evidencia de criterios.
La auditoría también debe verificar si el equipo creó un “CDE sombra”: carpetas externas, grupos de mensajería, enlaces públicos u hojas de cálculo paralelas que pasaron a ser la fuente real de información.
Los errores más comunes en los proyectos
La tabla siguiente resume señales de que el entorno existe técnicamente, pero la gobernanza todavía es débil.
| Síntoma | Riesgo | Corrección del proceso |
| archivos llamados “final” | condición de uso ambigua | controlar revisión y estado mediante metadatos/workflow |
| todos editan todo | pérdida de responsabilidad | permisos por rol y contenedor |
| la revisión nueva sustituye a la antigua sin historial | imposibilidad de auditoría | preservar versiones y transiciones |
| intercambio por correo electrónico | fuente paralela de verdad | exigir intercambio formal mediante el entorno definido |
| aprobación en mensajes informales | aceptación sin evidencia | registrar la decisión en el workflow |
| el modelo más reciente entra automáticamente en la federación | uso de información no liberada | filtrar por el estado adecuado |
| metadatos opcionales completados de formas diferentes | búsqueda y automatización frágiles | códigos controlados y validación |
| software elegido antes del proceso | workflow adaptado a la herramienta | definir requisitos funcionales antes de la selección |
| cientos de campos obligatorios | baja adopción y datos ficticios | aplicar proporcionalidad y LOIN |
| cierre tratado como backup | pérdida de contexto para operación | archivar con revisión, estado, acceso y retención definidos |
Cómo saber si un CDE es maduro
Un CDE maduro permite que alguien que no participó en las conversaciones diarias del proyecto comprenda el estado de la información.
Esa es una buena prueba.
Si un nuevo coordinador entra al equipo y necesita llamar a tres personas para descubrir qué plano utilizar, el entorno todavía depende de memoria tácita.
Si puede identificar la revisión vigente, la condición de uso, el autor, el historial, los criterios y los documentos relacionados directamente en el sistema, la información está más institucionalizada.
La madurez también aparece cuando una decisión puede auditarse meses o años después sin reconstruir manualmente correos electrónicos.
En la estructuración de un Entorno Común de Datos y Gestión de la Información BIM, A3A conecta requisitos, responsabilidades, metadatos, workflows, criterios de aceptación, movilización y auditoría del entorno.
CDE como instrumento de contratación y aceptación
El tema tiene una implicación comercial importante.
En contratos de ingeniería, definir “entrega mediante CDE” es insuficiente. El contrato o sus documentos asociados deben establecer, según corresponda, estructura de contenedores, convención de identificación, estados y finalidades, revisiones, responsabilidades, requisitos de información, criterios de aceptación, fechas-hito, formatos, reglas de acceso, propiedad intelectual, licenciamiento, retención y entrega final.
Esto transforma el CDE en un mecanismo de medición y aceptación.
Una entrega deja de ser “envió el archivo” y pasa a ser “entregó el conjunto previsto, en la revisión correcta, con el estado adecuado, la información requerida y evidencia de aceptación”.
Este enfoque es particularmente relevante en Owner’s Engineering, gerenciamiento, contratos EPC/EPCM, proyectos ejecutivos, obras multidisciplinarias y recepción técnica.
Cuándo contratar apoyo especializado para estructurar el CDE
El apoyo externo tiende a generar mayor valor cuando el proyecto tiene múltiples contratistas, gran volumen documental, requisitos BIM formales, transición a operación, contratos con hitos complejos o historial de fallas de revisión y aprobación.
En estos escenarios, el desafío no es solo configurar una plataforma. Es transformar requisitos de ingeniería en proceso operativo, matriz de responsabilidades, nomenclatura, metadatos, workflow, criterios de aceptación, plan de movilización, capacitación y auditoría.
A3A estructura esta capa mediante la solución de Entorno Común de Datos y Gestión de la Información BIM, conectando el CDE con la gestión de la información, coordinación, documentación técnica y gobernanza del proyecto.
Conclusión
CDE BIM no es solo un lugar común para almacenar archivos. Es una infraestructura de gestión de la información capaz de distinguir aquello que está en desarrollo de aquello que puede ser compartido, autorizado, aceptado y preservado.
La ABNT NBR ISO 19650-2 proporciona requisitos objetivos para esta infraestructura: identificación única, codificación acordada, estado, revisión, clasificación, transición entre estados, registro de usuario y fecha y acceso controlado por contenedor. El proceso normativo también conecta el entorno con la verificación de calidad, revisión, autorización, aceptación y archivo.
El resultado práctico es un cambio importante de pregunta. En lugar de “¿dónde está el archivo?”, el equipo pasa a preguntar:
¿qué información es esta, quién responde por ella, en qué revisión está, para qué finalidad puede utilizarse, quién autorizó su estado y qué evidencia demuestra que el requisito fue cumplido?
Esa es la diferencia entre almacenamiento y gobernanza.
La tecnología sigue siendo esencial, pero no es suficiente. Un CDE maduro exige requisitos claros, roles definidos, metadatos consistentes, estados con significado operativo, permisos coherentes, pruebas de movilización, capacitación y auditoría continua.
Cuando estas capas funcionan en conjunto, el entorno reduce ambigüedades, mejora la coordinación, fortalece la trazabilidad contractual y crea una base más confiable para diseño, construcción, recepción, As-Built y operación.
Por eso, la decisión más importante en una implantación de CDE no es elegir primero la plataforma. Es definir qué flujo de información necesita ser gobernado y qué evidencias permitirán confiar en él.
Referencias técnicas
[1] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 19650-1:2018 — Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM) — Information management using building information modelling — Part 1: Concepts and principles. Geneva: ISO, 2018.
[2] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 19650-2:2018 — Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM) — Information management using building information modelling — Part 2: Delivery phase of the assets. Geneva: ISO, 2018.
Preguntas frecuentes
CDE BIM es el Entorno Común de Datos utilizado para controlar la producción, intercambio, revisión, autorización, aceptación y preservación de información de un proyecto. No es solo almacenamiento: debe sostener estados, revisiones, identificación, clasificación, accesos y trazabilidad.
CDE significa Common Data Environment, expresión normalmente traducida como Entorno Común de Datos. En el contexto de la serie ISO 19650, es una parte esencial de la infraestructura de gestión de la información.
No. Las plataformas comerciales pueden implementar workflows y funcionalidades de CDE, pero CDE es un concepto y un proceso de gestión de la información. La herramienta debe seleccionarse y configurarse de acuerdo con los requisitos del proyecto.
Una carpeta compartida centraliza archivos. Un CDE también debe controlar identificación, revisión, estado, clasificación, permisos, transiciones, historial y condición de uso de la información. La centralización sin estos controles no garantiza gobernanza.
La ABNT NBR ISO 19650-2 establece, entre otros puntos, identificador único del contenedor, codificación acordada, estado, revisión, clasificación, transición entre estados, registro de usuario y fecha y acceso controlado a nivel del contenedor.
La revisión registra la evolución del contenedor. El estado representa su condición dentro del proceso e influye en la finalidad para la que puede utilizarse la información. Una revisión más nueva puede seguir en desarrollo mientras la revisión anterior continúa válida para coordinación.
La ABNT NBR ISO 19650-2 recomienda que el CDE del proyecto esté en funcionamiento antes de la invitación a presentar propuesta, permitiendo compartir información con organizaciones proponentes de forma controlada. Durante la movilización, el entorno y los intercambios deben configurarse y probarse.
El BEP organiza la estrategia de gestión de la información del equipo. TIDP y MIDP planifican qué contenedores se producirán y cuándo. El CDE sostiene operativamente la producción, intercambio, revisión, autorización, entrega y aceptación de esa información.
Sí. La ABNT NBR ISO 19650-2 contempla la posibilidad de un CDE distribuido del equipo de entrega conectado al CDE del proyecto. El punto crítico es controlar las fronteras, responsabilidades, estados e intercambios entre los entornos.
Una señal de madurez es poder identificar, sin depender de la memoria o de conversaciones paralelas, cuál es la revisión vigente, su estado, autor, finalidad, historial, aprobación y criterio de aceptación. El entorno también debe evitar fuentes paralelas de información fuera del workflow oficial.
Materiales técnicos complementarios
Soluciones
- Entorno Común de Datos y Gestión de la Información BIM
- Gestión de Requisitos, Evidencias y Criterios de Aceptación
- Gestión Electrónica de Documentos Técnicos y Control de Revisiones
- ENGiOS™
Servicios
- Compatibilización e Integración de Proyectos
- Proyecto Ejecutivo de Ingeniería
- Gerenciamiento / Owner’s Engineering
Guías técnicas
- Guía Completa de BIM y Compatibilización de Proyectos
- Guía Completa de Compatibilización de Proyectos
- Guía Completa sobre Gerenciamiento de Proyectos
Whitepapers
Artículos técnicos
- Gestión de la Información en BIM e ISO 19650
- BEP BIM
- Archivo IFC en BIM
- Open BIM
- LOD BIM
- Coordinación de Proyectos de Ingeniería
eBook
