Comprenda por qué un sistema instalado y funcionando puede no estar técnicamente entregado y cómo documentación, pruebas, As-Built, configuraciones y aceptación completan la entrega.
¡Descúbrelo!
Un sistema puede estar instalado, energizado y aparentemente funcionando sin que su entrega técnica esté concluida. En ingeniería, la finalización física demuestra que los componentes fueron implantados; la entrega técnica exige comprobar, mediante documentos, pruebas, registros y trazabilidad, que el objeto cumple lo contratado; y la aceptación es la decisión formal del propietario después de esa verificación.
Esta distinción es especialmente importante en sistemas tecnológicos, donde una parte significativa de la condición entregada no es visible. Configuraciones, integraciones, licencias, archivos nativos, copias de seguridad, pruebas, inventarios, planos As-Built, manuales y evidencias de desempeño pueden ser tan relevantes como los equipos instalados.
Por ello, “está funcionando” no es sinónimo de “ha sido técnicamente entregado”. La pregunta del propietario debe ser más amplia: ¿es posible demostrar qué se instaló, con qué configuración, conforme a qué requisitos, mediante qué pruebas y documentos, y con qué pendientes remanentes?
Instalación, funcionamiento, entrega técnica y aceptación son hitos diferentes
La confusión comienza cuando diferentes hitos se tratan como si fueran un único evento. Un contratista puede concluir el montaje y considerar finalizada su producción física, mientras el propietario aún necesita verificar conformidad, documentación y preparación para asumir el sistema.
| Condición | Qué demuestra | Qué puede faltar todavía |
| Instalado | Los equipos y la infraestructura fueron implantados | pruebas, documentación, integración, correcciones |
| Funcionando | Existe una respuesta funcional observable | desempeño demostrado, cobertura integral, trazabilidad |
| Probado | Se realizaron determinadas verificaciones | documentación final, pendientes, baseline |
| Documentado | Se produjeron registros y archivos | validación de calidad y correspondencia con el campo |
| Técnicamente entregado | Requisitos, evidencias y entregables fueron reconciliados | decisión formal del propietario |
| Recibido/aceptado | La autoridad competente reconoció la entrega conforme a los criterios aplicables | obligaciones remanentes, garantías y soporte |
| Handover concluido | Operaciones recibió el activo, la información, el conocimiento y las responsabilidades | seguimiento residual cuando esté previsto |
La Aceptación Técnica en Proyectos de Ingeniería trata de la validación formal de entregables. El Handover Técnico en Ingeniería trata de la transición a operaciones. La entrega técnica se sitúa entre estos hitos como la demostración estructurada de lo que efectivamente fue producido y entregado.
Qué caracteriza una entrega técnica
No existe un paquete universal para toda obra o sistema. La entrega depende del contrato, la disciplina, la criticidad y los requisitos definidos. El principio, sin embargo, es estable: el contratista debe proporcionar evidencias suficientes para demostrar la condición que afirma haber entregado.
Según el objeto, una entrega técnica puede incluir:
- conformidad del alcance físico;
- equipos y materiales compatibles con los requisitos;
- registros de inspección;
- ensayos y pruebas;
- informes de commissioning;
- certificados;
- planos y diagramas As-Built;
- inventario de activos;
- parametrizaciones y configuraciones finales;
- archivos nativos y copias de seguridad;
- licencias y credenciales transferidas mediante un proceso seguro;
- manuales de operación y mantenimiento;
- capacitación;
- documentación de proveedores;
- garantías;
- Data Book o dossier de calidad;
- punch list y evidencias de cierre;
- actas o registros previstos para recepción y aceptación.
La obligación concreta debe leerse en el conjunto del contrato. El error es suponer que el funcionamiento aparente sustituye entregables formalmente previstos o técnicamente necesarios.
Benchmark de CCTV: las cámaras funcionan, pero el sistema aún no está técnicamente entregado
El funcionamiento aparente demuestra solamente una parte de la condición entregada. Una decisión técnica debe conciliar instalación, pruebas, documentos, configuraciones, pendientes y criterios de aceptación.
Estructure la recepción técnica antes de formalizar la aceptación →
Considere un proyecto de CCTV IP en el que la empresa instaladora concluyó la implantación. Las cámaras están montadas, el VMS muestra imágenes y los usuarios pueden visualizar el sistema. La percepción inmediata es positiva: el sistema existe y funciona.
Sin embargo, durante el análisis para la recepción, el propietario identifica que la documentación final no representa íntegramente la condición implantada. Existen divergencias entre planos y campo, los registros de pruebas no permiten rastrear todos los dispositivos, el inventario no está reconciliado, parte de las configuraciones finales no está documentada y el paquete entregado no permite reconstruir con seguridad la baseline del sistema.
Esto no significa necesariamente que la instalación física haya sido mal ejecutada. Es posible que cámaras, switches, servidores y VMS estén funcionando satisfactoriamente y, al mismo tiempo, que la entrega contractual y técnica permanezca incompleta por ausencia o inadecuación de las evidencias requeridas.
Este tipo de situación es importante porque la calidad posee diferentes dimensiones:
| Dimensión | Pregunta de control |
| Calidad de la ejecución | ¿Los equipos fueron instalados correctamente? |
| Calidad funcional | ¿El sistema ejecuta las funciones previstas? |
| Calidad de desempeño | ¿Se demostraron los criterios mensurables? |
| Calidad documental | ¿Los registros representan correctamente lo ejecutado? |
| Calidad de la evidencia | ¿Es posible demostrar objetivamente el cumplimiento? |
| Completitud contractual | ¿Se cumplieron todos los entregables y obligaciones previstos? |
La Gestión de la Calidad en Proyectos de Ingeniería y el QA/QC en Obras de Ingeniería ayudan a estructurar estas dimensiones durante la ejecución, evitando que la discusión quede únicamente para el cierre.
En sistemas digitales, una parte relevante de la entrega no aparece en la inspección visual
En sistemas digitales, la baseline también reside en copias de seguridad, parámetros, licencias y archivos de configuración. Sin estos elementos, el propietario puede recibir un sistema que funciona hoy, pero cuyo mantenimiento y recuperación futuros quedan dependientes del instalador.
Integre documentación, configuraciones y As-Built en la entrega final →
Una cámara puede estar fijada en la pared, pero eso no revela la resolución configurada, codec, bitrate, retención de grabaciones, perfiles de usuario, reglas de analytics, sincronización horaria, integración, firmware o parámetros de red. Lo mismo se aplica a automatización, BMS, SCADA, control de acceso y diversos sistemas basados en software.
Por ello, la entrega puede necesitar incluir elementos como:
- copias de seguridad de configuración;
- versiones de firmware y software;
- parámetros finales;
- topología lógica;
- direccionamiento;
- matriz de usuarios y perfiles cuando corresponda;
- licencias;
- archivos de programación;
- integraciones configuradas;
- procedimientos de restauración;
- documentación de interfaces;
- inventario de activos y números de serie.
Estos elementos deben tratarse con gobernanza de seguridad. Credenciales, claves privadas y secretos no deben insertarse indiscriminadamente en documentos de amplia circulación; el propietario debe establecer una forma segura de transferencia y custodia.
Un As-Built incorrecto impide una baseline confiable
El As-Built debe representar la condición efectivamente ejecutada. Si el plano muestra una cámara en una ubicación diferente, identifica un equipo que fue sustituido o no incorpora cambios realizados durante la implantación, el documento no cumple adecuadamente su función de baseline.
Esto se vuelve todavía más relevante años después. El equipo de mantenimiento utilizará ese acervo para localizar componentes, planificar modificaciones, investigar fallos, sustituir equipos y comprender interfaces.
Un documento incorrecto puede no impedir que el sistema funcione hoy, pero aumenta el riesgo y el coste durante toda la vida útil del activo.
Un documento entregado también debe ser un documento aceptable
La cantidad de archivos no es sinónimo de calidad documental. La Documentación Técnica en Ingeniería debe analizarse respecto de contenido, revisión, coherencia, trazabilidad y finalidad.
Es necesario distinguir:
- documento previsto;
- documento producido;
- documento sometido;
- documento revisado;
- documento rechazado;
- documento corregido;
- documento aprobado o aceptado para la finalidad requerida.
La Lista Maestra de Documentos — MDR permite reconciliar el universo esperado con lo que efectivamente se recibió y el estado de cada elemento.
Al final de la obra, decir “los documentos fueron enviados” no responde a la pregunta principal: ¿cumplen los requisitos y representan la condición final?
Una prueba aislada no sustituye los criterios de aceptación
Una demostración informal puede comprobar que una determinada función respondió en ese momento. Los criterios de aceptación exigen definir previamente qué se verificará y qué resultado se considerará satisfactorio.
En CCTV, por ejemplo, diferentes proyectos pueden exigir verificaciones de:
- cobertura;
- campo de visión;
- identificación de escena;
- grabación;
- retención;
- recuperación de vídeo;
- redundancia;
- failover;
- integración con control de acceso;
- eventos y alarmas;
- analytics;
- operación PTZ;
- sincronización horaria;
- conectividad;
- permisos y perfiles;
- desempeño de servidores y almacenamiento.
El contenido Criterios de Aceptación en Ingeniería muestra cómo transformar requisitos en verificaciones objetivas.
Cuando los criterios no fueron definidos previamente, el cierre puede convertirse en una negociación subjetiva entre “funcionó en la demostración” y “no considero que esté entregado”.
El commissioning crea evidencia estructurada de preparación
El Commissioning de Ingeniería verifica si los sistemas y subsistemas fueron instalados, configurados y probados conforme a los requisitos aplicables. Su valor consiste en transformar observaciones y pruebas en evidencias trazables.
En sistemas integrados, esto es especialmente relevante porque los problemas pueden existir en las interfaces y no en los componentes aislados. Una cámara funciona; el VMS funciona; el control de acceso funciona. Aun así, una integración comprometida puede no ejecutar el flujo previsto.
El commissioning también ayuda a garantizar que la configuración probada sea la misma que aparece en los documentos, archivos nativos y copias de seguridad entregados al propietario.
La punch list separa la finalización física del cierre de pendientes
Una obra próxima a la entrega puede mantener pendientes residuales. El problema no es necesariamente que exista un pendiente, sino que no haya gobernanza sobre él.
La Punch List en Ingeniería debe identificar, según corresponda:
- elemento;
- sistema o ubicación;
- criticidad;
- requisito afectado;
- responsable;
- plazo;
- condición temporal;
- evidencia esperada para el cierre;
- responsable de la verificación;
- estado.
Los pendientes impeditivos no deben diluirse en una lista genérica únicamente para declarar concluida la obra. Los pendientes menores pueden gestionarse cuando exista fundamento técnico y un mecanismo de control definido.
La substantial completion y la entrega técnica no deben confundirse
En contratos y modelos internacionales puede existir el concepto de substantial completion, asociado a una etapa en la que la obra alcanzó una condición suficiente para determinados efectos contractuales aunque todavía existan trabajos residuales. Su definición y efectos dependen del instrumento contractual aplicable.
Este concepto no debe importarse automáticamente a cualquier contrato brasileño ni utilizarse como sinónimo de aceptación técnica. Una condición físicamente sustancial puede coexistir con pendientes documentales, pruebas, correcciones y requisitos de recepción.
El principio de gestión consiste en separar claramente cada hito y sus efectos: finalización física, preparación funcional, entrega documental, recepción, aceptación, garantía y transferencia operacional.
En la contratación pública, el contratista declara la entrega; la Administración la verifica
En la contratación pública brasileña, la Ley nº 14.133/2021 determina que la ejecución sea acompañada y fiscalizada y que, para obras y servicios, la recepción provisional se formalice mediante un acta detallada después de verificarse las exigencias de carácter técnico.
Por lo tanto, la declaración de finalización de la empresa ejecutora es una información relevante, pero no sustituye el procedimiento de verificación de la Administración. El objeto también puede rechazarse, total o parcialmente, cuando no esté de acuerdo con el contrato.
Cómo evitar que la documentación se convierta en un problema solamente al final
La documentación de cierre no debería producirse toda de una vez después de que el equipo de campo se desmovilice. El control documental debe acompañar la ejecución.
Una buena estrategia incluye:
- definir la lista de entregables en el diseño, los Términos de Referencia y el contrato;
- estructurar el MDR y las responsabilidades;
- exigir submittals en hitos definidos;
- controlar revisiones y comentarios;
- incorporar continuamente los cambios de campo;
- vincular inspecciones y pruebas con los documentos correspondientes;
- revisar progresivamente el As-Built;
- controlar los pendientes documentales como parte del avance;
- reconciliar el paquete final antes de la recepción;
- transferir a operaciones solamente información aceptada y utilizable.
El Control de Documentos en Ingeniería y el Data Book en Ingeniería son componentes de este proceso.
Cómo Owner’s Engineering cambia la perspectiva de la entrega
El contratista responde por la ejecución del objeto dentro de sus obligaciones. Owner’s Engineering observa el mismo proyecto desde la perspectiva del propietario: requisitos, interfaces, calidad, evidencias, riesgos, cambios, documentación, operación y aceptación.
El Owner’s Engineering puede acompañar el ciclo desde la definición del alcance hasta la entrega, reduciendo la asimetría de información entre quien ejecuta y quien debe asumir el activo.
En el cierre, esta actuación puede incluir revisión documental, análisis de pendientes, apoyo a pruebas, verificación de interfaces, coordinación de especialistas y emisión de dictámenes técnicos para sustentar las decisiones del propietario.
No se trata de desconfiar del ejecutor por principio. Se trata de crear una cadena independiente de verificación proporcional al riesgo y la complejidad del objeto.
Si el sistema ya está en operación, todavía es posible corregir la entrega técnica
Cuando un sistema entró en uso antes de finalizar la documentación y las evidencias, el trabajo pasa a ser de recuperación de la baseline.
Un enfoque posible incluye:
- levantamiento del alcance y las obligaciones originales;
- inventario de la condición instalada;
- reconciliación de activos;
- revisión de los documentos existentes;
- levantamiento As-Built complementario;
- verificación de configuraciones;
- análisis de las pruebas disponibles;
- ejecución de pruebas adicionales técnicamente justificables;
- matriz de pendientes;
- corrección documental;
- consolidación del Data Book;
- recomendación técnica para recepción y aceptación.
El artículo Obra con fallos de calidad: qué contratar para diagnosticar, corregir y recuperar el control técnico muestra cómo seleccionar auditoría, QA/QC, fiscalización, commissioning, recepción técnica u Owner’s Engineering según el problema encontrado.
El problema de la entrega suele comenzar en el diseño y los Términos de Referencia
Si el propietario desea recibir una determinada evidencia al final, esa obligación debe pensarse desde el inicio. El diseño, la especificación y los Términos de Referencia deben dejar claro, según la naturaleza del objeto, qué se entregará y cómo se verificará.
Esto puede incluir:
- formatos y revisiones de documentos;
- archivos nativos;
- requisitos de As-Built;
- pruebas;
- instrumentos;
- criterios de aprobación;
- responsabilidades de commissioning;
- contenido del Data Book;
- capacitación;
- garantías;
- configuraciones y copias de seguridad;
- plazos de presentación;
- proceso de revisión y nueva presentación;
- efectos de los pendientes sobre medición y recepción.
Los Términos de Referencia en Ingeniería conectan estas definiciones con la contratación pública.
Una matriz simple para decidir si el sistema está realmente preparado para la entrega
El propietario puede estructurar la decisión mediante dimensiones de preparación:
| Dimensión | Evidencias posibles |
| Física | inspección, cantidades, instalación, identificación |
| Funcional | pruebas y demostraciones controladas |
| Desempeño | mediciones y criterios cuantitativos |
| Documental | MDR, As-Built, manuales, informes, Data Book |
| Digital | copias de seguridad, versiones, parámetros, licencias, configuraciones |
| Calidad | inspecciones, NCR, punch list y correcciones |
| Operacional | capacitación, procedimientos, soporte y repuestos |
| Contractual | entregables, actas, garantías y requisitos de recepción |
No es necesario que todos los sistemas tengan el mismo paquete documental. El paquete debe ser proporcional a la complejidad, la criticidad y lo contratado.
Consideraciones finales
Un sistema instalado puede representar una ejecución física concluida. Un sistema funcionando puede demostrar parte de su condición funcional. Ninguno de estos hitos, por sí solo, demuestra que la entrega técnica esté completa.
Una entrega madura conecta el objeto físico, requisitos, pruebas, documentos, configuraciones, pendientes y evidencias. La aceptación viene después de la verificación, conforme a la autoridad y al procedimiento aplicables. El handover lleva la condición aceptada a operaciones.
Cuando estas fronteras se definen desde la contratación y se controlan durante la ejecución, el cierre deja de depender de discusiones subjetivas. Cuando no se definen, Ingeniería Consultiva, QA/QC, Document Control, commissioning, fiscalización y Owner’s Engineering pueden ayudar al propietario a reconstruir la evidencia necesaria y recuperar el control técnico de la entrega.
Owner’s Engineering crea una capa independiente entre la declaración del ejecutor y la decisión del propietario, organizando requisitos, evidencias, interfaces, calidad y recomendaciones de aceptación.
Referencias técnicas
[1] BRASIL. Ley nº 14.133, de 1 de abril de 2021. Ley de Licitaciones y Contratos Administrativos. Disponible en: https://www.planalto.gov.br/ccivil_03/_ato2019-2022/2021/lei/l14133.htm
[2] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 19650-2:2018 — Organization and digitization of information about buildings and civil engineering works, including building information modelling — Information management using building information modelling — Part 2: Delivery phase of the assets. Disponible en: https://www.iso.org/standard/68080.html
[3] CHARTERED INSTITUTION OF BUILDING SERVICES ENGINEERS. Guide M7: Handover procedures. 2023. Disponible en: https://www.cibse.org/knowledge-research/knowledge-portal/guide-m7-handover-2023/
[4] U.S. DEPARTMENT OF ENERGY. Federal Energy Management Program. Commissioning Process for Federal Facilities. Disponible en: https://www.energy.gov/cmei/femp/commissioning-process-federal-facilities
Preguntas frecuentes
No necesariamente. El funcionamiento demuestra una condición funcional, pero la entrega técnica también puede depender de documentación, pruebas, As-Built, configuraciones, inventarios, tratamiento de pendientes, capacitación y otros entregables previstos.
La instalación física materializa equipos e infraestructura. La entrega técnica demuestra, mediante evidencias trazables, que el objeto implantado cumple los requisitos, está documentado, fue probado y posee las condiciones definidas para la recepción.
Cuando esté previsto en el alcance o sea necesario para representar la condición final, sí. El As-Built debe corresponder a la condición efectivamente ejecutada y servir como baseline para operación, mantenimiento y futuras intervenciones.
Puede, dependiendo del requisito afectado y del contrato. La criticidad del pendiente debe considerar su influencia sobre conformidad, operación, mantenimiento, seguridad, garantía, trazabilidad y obligaciones contractuales.
Porque las imágenes en el VMS demuestran solamente parte de la funcionalidad. Pueden faltar evidencias de cobertura, pruebas, inventario, configuraciones, integraciones, As-Built, copias de seguridad, licencias, capacitación y documentación final requerida.
Sí. Puede ser necesario reconstruir la baseline contractual, inventariar lo instalado, revisar documentos, realizar un levantamiento As-Built, validar configuraciones, completar pruebas, tratar pendientes y consolidar el paquete técnico final.
Materiales técnicos relacionados
Soluciones relacionadas
Servicios relacionados
- Recepción Técnica de Obras y Servicios de Ingeniería
- Commissioning de Ingeniería
- As-Built de Ingeniería
- Owner’s Engineering
