Entienda cuándo un problema en una obra pública caracteriza una falla de proyecto, cómo determinar la responsabilidad del proyectista y del responsable técnico y qué evidencias exige la Ley 14.133 para demostrar nexo y daño.
¡Descúbrelo!
Un error de proyecto en una obra pública no debe tratarse solamente como una incompatibilidad de dibujo que “apareció en la obra”. Cuando una falla de concepción, dimensionamiento, especificación, levantamiento, compatibilización o detalle altera el costo, el plazo, la calidad, la seguridad o la funcionalidad del emprendimiento, pasa a producir efectos técnicos, contractuales y de responsabilidad profesional. La Ley nº 14.133/2021 determina expresamente que, si las modificaciones de contratos de obras o servicios de ingeniería derivan de fallas de proyecto, debe investigarse la responsabilidad del responsable técnico y adoptarse las medidas necesarias para resarcir los daños causados a la Administración.
Esto no significa, sin embargo, que toda adenda, toda RFI o toda necesidad de revisión encontrada en campo sea automáticamente un “error del proyectista”. Una atribución de responsabilidad técnicamente consistente exige separar tres situaciones diferentes: una falla existente en el proyecto contratado; un defecto derivado de la ejecución o de los materiales empleados; y una modificación legítima causada por una condición sobrevenida, una nueva necesidad de la Administración o un riesgo que no podía haberse eliminado razonablemente durante el desarrollo del proyecto. Sin esta separación, el proceso corre el riesgo de atribuir responsabilidad por presunción, cuando lo correcto es demostrar requisito, autoría, desviación, nexo causal e impacto.
La ART — Anotação de Responsabilidade Técnica, registro brasileño de responsabilidad técnica — es una parte importante de esta trazabilidad porque identifica, a efectos legales, a los responsables técnicos por las actividades de ingeniería. No sustituye el análisis del contenido efectivamente contratado y producido, ni convierte a un único profesional en responsable de todas las disciplinas de un emprendimiento multidisciplinario. Para determinar la responsabilidad por una falla, es necesario reconstruir quién tenía atribución sobre la decisión técnica en cuestión, cuál era el nivel de desarrollo exigido, qué información estaba disponible, qué versión del proyecto fue liberada y de qué manera el problema generó el daño o la necesidad de modificación.
Qué caracteriza una falla de proyecto en una obra pública
La Ley nº 14.133 define el proyecto básico como el conjunto de elementos necesarios y suficientes para definir y dimensionar la obra o servicio, con un nivel de precisión adecuado, y exige soluciones suficientemente detalladas para evitar, durante la elaboración del proyecto ejecutivo y la ejecución, reformulaciones o variantes que afecten calidad, precio y plazo. El proyecto ejecutivo, a su vez, debe contener los elementos necesarios y suficientes para la ejecución completa de la obra, detallando las soluciones previstas en el proyecto básico y especificando servicios, materiales y equipos.
Esta lógica es importante porque la expresión “falla de proyecto” debe relacionarse con el nivel de desarrollo que el documento debía poseer. Una omisión que sería aceptable en un estudio preliminar puede ser incompatible con un proyecto básico listo para licitación. De la misma forma, una decisión que todavía podría quedar abierta en el proyecto básico no debería permanecer indefinida cuando el frente correspondiente de la obra depende de un proyecto ejecutivo liberado para construcción.
En la práctica, una falla puede aparecer como:
- dimensionamiento insuficiente o técnicamente inadecuado;
- especificación incompatible con la condición real de instalación;
- cantidad derivada de un levantamiento incompleto o incorrecto;
- ausencia de una solución necesaria para ejecutar el objeto;
- incompatibilidad entre disciplinas;
- interfaz no resuelta entre estructura, arquitectura, instalaciones o equipos;
- requisito normativo o regulatorio no incorporado;
- premisa técnica inconsistente con los datos disponibles;
- detalle que no permite ejecutar la solución sin una reformulación relevante;
- documento desactualizado utilizado como referencia de construcción;
- modificación de una disciplina no propagada a documentos dependientes;
- solución que cumple el dibujo aisladamente, pero no el desempeño o la funcionalidad del sistema integrado.
La existencia de un problema en campo, sin embargo, es solamente el primer indicio. El diagnóstico debe verificar si el problema nació efectivamente de la documentación de proyecto o si resultó de una ejecución divergente, material sustituido, condición desconocida, interferencia no registrada o modificación posterior.
El artículo sobre Proyecto Básico vs. Proyecto Ejecutivo ayuda a comprender por qué el análisis de la falla debe considerar la madurez exigida en cada etapa. El contenido sobre obra sin proyecto ejecutivo trata el gate legal para la ejecución, mientras que aquí el foco es otro: determinar técnicamente el origen y la responsabilidad cuando el proyecto ya producido se muestra inadecuado.
Cómo diferenciar falla de proyecto, error de ejecución y cambio legítimo
Cuando el origen del problema todavía es incierto, la revisión técnica debe comparar requisitos, baseline documental, interfaces y condición construida antes de que la obra transforme una hipótesis en una decisión contractual.
La distinción es decisiva porque cada origen conduce a responsabilidades, registros y tratamientos contractuales diferentes.
| Situación | Origen técnico predominante | Evidencia típica | Tratamiento inicial |
| Falla de proyecto | Concepción, cálculo, especificación, levantamiento, coordinación o detalle inadecuados | Proyecto liberado, memoria de cálculo, requisito, revisión, incompatibilidad | Revisión técnica, análisis de nexo y eventual investigación de responsabilidad |
| Error de ejecución | Obra ejecutada en desacuerdo con proyecto, especificación o procedimiento | Inspección, RDO, fotos, pruebas, dibujo IFC y condición construida | No conformidad, corrección por el ejecutor y fiscalización |
| Material inadecuado | Material suministrado diferente del aprobado o sin el desempeño requerido | Submittal, certificado, ficha técnica, inspección de recepción | Rechazo, sustitución y tratamiento contractual |
| Condición imprevista | Condición física o interferencia no detectable con diligencia razonable | Levantamiento de campo, sondeo, registro, documento de descubrimiento | Evaluación de riesgo, solución técnica y eventual modificación contractual |
| Cambio de la Administración | Nuevo requisito, uso, capacidad o estándar solicitado después de la baseline | Solicitud formal, acta, decisión administrativa, change request | Gestión del cambio y análisis de impacto |
| Evolución técnica legítima | Optimización o ajuste permitido por el régimen contractual y formalmente aprobado | Estudio comparativo, aprobación, matriz de riesgos | Change control y actualización de baseline |
Un ejemplo sencillo es una tubería que colisiona con una viga. La colisión puede representar una falla de compatibilización del proyecto. Pero también puede haberse creado porque la estructura fue ejecutada fuera de posición, porque la tubería instalada no siguió la ruta prevista o porque una revisión arquitectónica posterior desplazó el ambiente sin actualizar las demás disciplinas. La imagen final de la colisión es la misma; la responsabilidad es completamente diferente.
Por ello, los procesos maduros utilizan Design Review, coordinación multidisciplinaria, revisión de interfaces y control de revisiones antes de emitir para construcción. La finalidad no es crear una capa burocrática, sino reducir la probabilidad de que una inconsistencia documental atraviese la fase de proyecto y se convierta en costo de obra.
Una ejecución divergente no convierte automáticamente al proyecto en culpable
La Ley nº 14.133 establece que el contratado debe reparar, corregir, retirar, reconstruir o sustituir, a sus expensas, el objeto en el que se verifiquen vicios, defectos o incorrecciones resultantes de la ejecución o de los materiales empleados. La fiscalización no elimina esta responsabilidad.
Así, si el proyecto especificaba correctamente el elemento y la contratista ejecutó una solución diferente sin aprobación, el origen primario no es el proyecto. Tampoco es correcto atribuir al proyectista una falla introducida por sustitución comercial de equipo, cambio de ruta en campo o método ejecutivo incompatible con la solución aprobada.
No toda revisión de proyecto es una falla
Los proyectos se desarrollan sobre una determinada baseline de requisitos, levantamientos y premisas. Una modificación posterior de necesidad, capacidad, legislación aplicable, condición de contorno o estrategia de implantación puede exigir revisión sin que el documento original estuviera técnicamente equivocado para la información disponible cuando fue emitido.
Por eso, la gestión de requisitos y la gestión de cambios son esenciales. Sin historial de requisitos y configuración, un cambio legítimo ocurrido meses después puede interpretarse retrospectivamente como un error original.
Qué determina la Ley 14.133 sobre fallas de proyecto
La disposición central es el art. 124, §1º. Establece que, cuando las modificaciones de contratos de obras y servicios de ingeniería deriven de fallas de proyecto, estas modificaciones darán lugar a la investigación de responsabilidad del responsable técnico y a la adopción de las medidas necesarias para resarcir los daños causados a la Administración.
El texto tiene tres consecuencias prácticas importantes.
Primero, la necesidad de modificar el contrato no cierra el asunto. Resolver técnicamente la obra y formalizar la adenda puede ser necesario para preservar el emprendimiento, pero la Administración todavía debe evaluar si la modificación derivó de una falla de proyecto y si hubo daño asociado.
Segundo, la atribución de responsabilidad presupone una relación demostrable entre la falla y la modificación. El simple hecho de existir una adenda no demuestra error de proyecto. Las obras pueden modificarse por una alteración legítima de la Administración, condición sobrevenida, expropiación, licenciamiento, cambio de demanda u otros eventos previstos en la propia legislación.
Tercero, el texto se refiere al responsable técnico. Esto hace fundamental la trazabilidad de autoría, atribución, ART, disciplina y alcance. En un proyecto multidisciplinario, no es técnicamente adecuado tratar a todos los profesionales como responsables indistintamente de cualquier problema surgido en el emprendimiento.
La recepción del proyecto no extingue la responsabilidad por una falla
Otra disposición relevante está en el art. 140. La Ley determina que la recepción definitiva del proyecto no exime al proyectista o consultor de la responsabilidad objetiva por daños causados por una falla de proyecto.
Esto corrige una interpretación peligrosa: la aprobación administrativa del entregable no funciona como una liberación técnica absoluta. La Administración debe revisar y aceptar el producto conforme a su proceso de contratación, pero el descubrimiento posterior de una falla capaz de causar daño no deja automáticamente de ser susceptible de análisis porque el documento había sido recibido.
Al mismo tiempo, esta regla no exime a la Administración de mantener un proceso de revisión y aceptación técnicamente robusto. Aprobar proyectos sin criterios, evidencias o capacidad técnica aumenta la exposición del emprendimiento. La gestión de requisitos, evidencias y criterios de aceptación reduce esta fragilidad al hacer explícito qué debe verificarse antes de cada liberación.
ART, autoría y responsabilidad técnica: qué debe rastrearse realmente
La Ley nº 6.496/1977 determina que los contratos para ejecución de obras o prestación de servicios profesionales de ingeniería están sujetos a la Anotação de Responsabilidade Técnica — ART — y establece que la ART define, a efectos legales, a los responsables técnicos por el emprendimiento de ingeniería.
La ART, por tanto, es una pieza esencial de trazabilidad. Pero la investigación técnica no debe detenerse en la existencia del documento. Es necesario confrontar la ART con el contrato, la disciplina, el alcance efectivamente producido, la autoría de las piezas, las revisiones y las decisiones que condujeron al elemento cuestionado.
La Ley nº 5.194/1966 refuerza esta lógica al tratar la autoría y la responsabilidad de los profesionales que colaboran en partes de un proyecto. En emprendimientos complejos, la responsabilidad técnica debe relacionarse con las partes efectivamente desarrolladas y asumidas por cada profesional.
Una matriz mínima de trazabilidad suele incluir:
- empresa o profesional contratado para el proyecto;
- objeto y alcance contractual;
- disciplina técnica;
- responsable técnico y ART correspondiente;
- autores y revisores de cada documento;
- código y revisión del documento;
- fecha de emisión;
- estado documental, como preliminar, para aprobación o liberado para construcción;
- requisito o premisa que originó la solución;
- aprobaciones y comentarios recibidos;
- modificaciones posteriores y sus respectivos responsables;
- documento efectivamente utilizado por la obra.
Esta cadena es especialmente relevante cuando hay cambio de equipo, sustitución de proyectista, contratación de disciplinas separadas o desarrollo de proyecto por un consorcio. Sin ella, la investigación puede acabar vinculando un problema a la empresa o al profesional equivocado.
Cómo demostrar técnicamente que el daño nació del proyecto
Los eventos con múltiples disciplinas, revisiones e impactos exigen una línea de evidencia auditable. Owner’s Engineering puede integrar proyecto, contrato, campo y costos sin sustituir las competencias legales de la Administración.
Owner’s Engineering para la gobernanza técnica del emprendimiento
La investigación de responsabilidad no debería comenzar con la pregunta “¿quién se equivocó?”, sino con una reconstrucción objetiva del evento. El objetivo es establecer una cadena verificable:
requisito aplicable → información disponible → solución proyectada → desviación técnica → manifestación en la obra → modificación necesaria → impacto de costo/plazo/calidad → responsable técnico por la decisión.
Esta secuencia evita conclusiones basadas solamente en percepción de campo.
1. Identificar el requisito que debía cumplirse
El primer paso es determinar qué requisito, norma, dimensión, desempeño, interfaz o condición debía observarse. Sin requisito no existe referencia técnica para caracterizar una desviación.
La fuente puede estar en el programa de necesidades, Término de Referencia, proyecto básico, norma técnica, memoria, requisito del fabricante, legislación, contrato, matriz de interfaces o decisión formal de la Administración.
2. Verificar qué datos estaban disponibles para el proyectista
Una solución puede parecer inadecuada después de que surge información nueva. El análisis debe verificar si esa información ya existía o razonablemente debía haberse obtenido durante los levantamientos y el desarrollo del proyecto.
Entre los ejemplos están:
- topografía;
- registro de redes existentes;
- sondeo;
- levantamiento arquitectónico;
- datos de carga;
- requisitos operacionales;
- informaciones de empresas de servicios públicos;
- características de equipos existentes;
- condiciones ambientales;
- restricciones de implantación.
Si el contrato contemplaba un levantamiento y el dato relevante podía haberse identificado con el método contratado, la ausencia puede integrar la falla. Si la condición estaba oculta y no era detectable mediante las diligencias razonables previstas, el análisis cambia de naturaleza.
3. Fijar la baseline documental correcta
Es necesario saber qué revisión estaba vigente cuando la obra tomó la decisión. En muchos conflictos, el análisis falla porque compara la condición construida con un PDF que no era la revisión vigente.
La gobernanza documental debe permitir identificar emisión, revisión, transmittal, aprobación y distribución. Correos electrónicos aislados o archivos con nombres como “final_v2_corregido” no son una baseline confiable para un emprendimiento relevante.
4. Caracterizar técnicamente la desviación
La desviación debe describirse de forma mensurable. “Proyecto malo” no es una conclusión técnica. Es necesario señalar, por ejemplo, que la sección calculada era insuficiente para la carga de proyecto, que faltaba espacio físico para mantenimiento, que dos disciplinas ocupaban el mismo volumen, que la especificación no atendía al ambiente o que la cantidad no correspondía al levantamiento disponible.
5. Demostrar el nexo causal
A continuación, debe demostrarse que la desviación generó la consecuencia alegada. Una falla puede existir y no haber causado el daño reclamado; otra puede haber contribuido junto con un error de ejecución, demora en la decisión o modificación posterior.
El análisis del nexo debe separar causa raíz, factores contribuyentes y consecuencias. En casos complejos, las técnicas de análisis de causa raíz ayudan a evitar que la primera desviación visible sea tratada como la única causa.
6. Cuantificar el impacto incremental
El daño derivado de la falla no es necesariamente igual al valor total de la solución correctiva. Parte del costo podría existir incluso si el proyecto hubiera sido correcto desde el principio.
El análisis debe separar:
- costo que ya sería necesario en el alcance original;
- costo de demolición o retrabajo causado por la falla;
- materiales perdidos;
- horas improductivas;
- movilización adicional;
- efecto sobre el camino crítico;
- costo indirecto de extensión del plazo cuando esté demostrado;
- nuevos proyectos, pruebas o licencias necesarios exclusivamente por la corrección;
- otros efectos directamente atribuibles al evento.
Esta separación es esencial para evitar la sobreestimación del daño.
Las fallas multidisciplinarias exigen análisis de interfaces, no la búsqueda de un único culpable
Gran parte de los problemas relevantes de proyecto no está dentro de una única disciplina. Aparecen en las fronteras: estructura vs. instalaciones, arquitectura vs. equipos, eléctrica vs. automatización, drenaje vs. movimiento de tierras, utilidades vs. proceso, obra civil vs. fabricante.
Una tubería puede estar correctamente dimensionada y aun así ser imposible de instalar porque el paso estructural no fue coordinado. Un tablero eléctrico puede ser eléctricamente correcto y, al mismo tiempo, no disponer de área de acceso y mantenimiento. Un equipo puede cumplir la especificación, pero exigir infraestructura de alimentación, extracción, fundación o red que no fue incorporada por las demás disciplinas.
Por ello, la gestión de interfaces debe definir quién suministra información, quién la recibe, qué documento registra la interfaz y quién verifica su cierre. Sin esta estructura, una investigación posterior puede encontrar múltiples documentos técnicamente correctos en aislamiento y un sistema globalmente inviable.
La responsabilidad puede ser compartida cuando diferentes profesionales tenían obligaciones complementarias sobre la interfaz. Pero esta conclusión debe nacer de los contratos, las atribuciones técnicas y los registros, no de una división arbitraria de porcentajes.
La contratación integrada y semiintegrada cambia la asignación del riesgo de proyecto
El régimen de ejecución contractual modifica el análisis. En la contratación integrada, el contratado desarrolla el proyecto básico a partir del anteproyecto y asume los riesgos asociados al proyecto en los términos de la Ley y del contrato. En la contratación semiintegrada, el proyecto básico es suministrado por la Administración, pero puede existir la posibilidad de que el contratado lo modifique, mediante autorización y demostración de la superioridad de la innovación, asumiendo los riesgos asociados a la modificación.
Esto significa que la pregunta “¿quién proyectó?” es insuficiente. Es necesario identificar qué versión de la solución pertenece a qué parte, quién tenía libertad para modificarla, qué riesgo fue asignado y qué documento fue efectivamente aprobado.
La matriz de asignación de riesgos debe dialogar con el régimen, la madurez de los proyectos y las interfaces. Las cláusulas genéricas que transfieren “todos los riesgos de proyecto” sin coherencia con los documentos suministrados tienden a crear disputas en lugar de gobernanza.
El papel de la fiscalización cuando aparece un posible error de proyecto
El fiscal no debe improvisar una nueva solución en campo sin un proceso formal. Al identificar una condición posiblemente derivada de una falla de proyecto, el registro debe preservar la evidencia y evitar que la corrección destruya el historial necesario para el análisis.
Una secuencia técnicamente prudente incluye:
- registrar la condición encontrada en el RDO o sistema equivalente;
- identificar la documentación vigente relacionada;
- interrumpir solamente el frente afectado cuando sea necesario por seguridad o riesgo de retrabajo, sin transformar automáticamente el evento en paralización total;
- emitir RFI, consulta técnica o no conformidad según el proceso contractual;
- obtener manifestación del proyectista o responsable de la solución;
- evaluar alternativas e impactos;
- formalizar la decisión por la autoridad competente;
- actualizar documentos, presupuesto y cronograma cuando corresponda;
- preservar el expediente del evento para una eventual investigación de responsabilidad.
La Ley nº 14.133 permite contratar terceros para asistir y subsidiar al fiscal con información técnica. El apoyo técnico a la fiscalización es especialmente útil cuando el objeto posee alta complejidad multidisciplinaria o cuando el equipo público no dispone internamente de todas las especialidades necesarias. Este apoyo no sustituye la competencia legal del fiscal; aumenta la calidad de la evidencia y de la decisión técnica.
Cómo tratar la corrección sin borrar la evidencia de la falla
Existe una tensión práctica: la obra necesita continuar, pero la Administración también necesita preservar elementos para determinar origen e impacto. El peor enfoque es corregir rápidamente sin registrar la baseline anterior e intentar reconstruir el evento meses después.
Antes de la intervención deben preservarse, según su relevancia:
- dibujos y modelos en la revisión vigente;
- memoria de cálculo;
- especificaciones;
- fotos y vídeos de la condición encontrada;
- levantamiento dimensional;
- RDO;
- RFI y respuestas;
- actas de decisión;
- presupuesto original del ítem;
- presupuesto de la corrección;
- programación del frente afectado;
- material ya adquirido o instalado;
- registros de inspección;
- identificación de los profesionales involucrados.
Cuando la corrección exige una modificación contractual, el análisis técnico de adendas debe separar la necesidad objetiva de modificar el contrato de la investigación sobre quién soportará el daño derivado del origen de la modificación.
Esta separación evita un falso dilema: reconocer la necesidad de la adenda no significa reconocer automáticamente que la Administración deba absorber todos sus costos.
Cómo prevenir fallas de proyecto antes de la licitación
La prevención comienza en el documento de contratación: alcance, productos, criterios de revisión y aceptación deben ser verificables antes de que el proyectista inicie el trabajo.
Revisión Técnica del Término de Referencia para Obras y Servicios de Ingeniería
La prevención comienza antes de publicar el pliego. Cuanto antes se encuentre una inconsistencia, menor será la cantidad de decisiones, adquisiciones y servicios que deban deshacerse.
Levantamientos compatibles con el riesgo del emprendimiento
Un proyecto confiable depende de datos confiables. Levantamiento de condiciones existentes, topografía, sondeo, inspecciones, datos de utilidades y requisitos operacionales deben ser proporcionales a la complejidad y al nivel de decisión de la etapa.
Ahorrar en el diagnóstico para “ganar plazo” puede simplemente transferir incertidumbre a la obra, donde cada descubrimiento cuesta más para resolverse.
Criterios objetivos de madurez
La Administración puede utilizar gates de preparación para impedir que un paquete avance solamente porque llegó la fecha prevista. Los contenidos sobre Project Readiness y PDRI muestran cómo la madurez del alcance puede tratarse de forma estructurada.
Un paquete listo para contratación debe permitir responder, entre otras cuestiones:
- ¿los requisitos están definidos y son trazables?
- ¿los levantamientos críticos fueron concluidos?
- ¿las disciplinas están coordinadas?
- ¿las interferencias relevantes fueron tratadas?
- ¿las memorias y los dibujos son coherentes?
- ¿las cantidades reflejan la documentación?
- ¿el presupuesto es trazable a los proyectos?
- ¿los requisitos de licenciamiento y empresas de servicios públicos están incorporados?
- ¿los riesgos residuales fueron explicitados?
- ¿los documentos tienen revisión y estado controlados?
Revisión independiente en los puntos de mayor consecuencia
No todo proyecto exige el mismo esfuerzo de revisión. Un enfoque basado en riesgo concentra Design Review, cálculo independiente, clash detection y Project Assurance en los elementos cuyo error produciría mayor efecto sobre seguridad, costo, plazo u operación.
El servicio de Design Review en proyectos de ingeniería actúa precisamente en esta frontera: verificar coherencia, madurez, interfaces y riesgos antes de que el documento se convierta en una instrucción costosa de obra.
El Término de Referencia debe definir qué significa proyecto aceptado
Si el TR exige solamente “entrega de proyecto ejecutivo” sin definir disciplinas, contenido mínimo, criterios de revisión, formato, compatibilización, memorias de cálculo, responsabilidades y proceso de aprobación, el contrato crea una disputa futura sobre lo que debería haberse producido.
Una revisión técnica del Término de Referencia antes de la licitación reduce este riesgo al verificar si los productos de ingeniería son verificables y suficientes para la decisión que deberán sustentar.
Cuándo tiene sentido contratar un análisis independiente de la falla
Un análisis independiente tiende a generar más valor cuando el evento posee una o más de estas características:
- impacto económico relevante;
- riesgo de paralización;
- múltiples proyectistas o contratistas involucrados;
- conflicto entre fiscalización, proyectista y ejecutor;
- necesidad de una adenda significativa;
- posible solicitud de reequilibrio o claim;
- riesgo de seguridad o desempeño;
- necesidad de investigar responsabilidad;
- ausencia de equipo público en la especialidad necesaria;
- documentación extensa o versiones conflictivas.
El alcance no debe formularse como “encontrar al culpable”. Un buen análisis independiente define el evento, reconstruye requisitos y baseline, identifica causas y factores contribuyentes, verifica responsabilidades contractuales, cuantifica impactos y presenta conclusiones sustentadas por evidencias.
La Owner’s Engineering puede asumir este papel de integración técnica a lo largo del emprendimiento, creando la gobernanza necesaria para que las divergencias sean identificadas antes de transformarse en litigios.
Ejemplo práctico: modificación de fundación durante la ejecución
Considere una obra en la que, después de la excavación, el equipo concluye que la fundación prevista no puede ejecutarse como fue proyectada. Decir inmediatamente que “hubo un error de proyecto” es prematuro.
El análisis debería preguntar:
- qué sondeos eran exigidos y cuáles fueron realizados;
- ¿la condición encontrada estaba representada en los boletines de sondeo?
- ¿el proyectista recibió esos datos?
- ¿la memoria de cálculo utilizó parámetros coherentes con los resultados?
- ¿la ejecución llegó a la cota y al lugar especificados?
- ¿hubo cambio de implantación después del sondeo?
- ¿existió una condición geotécnica localizada no capturada por una campaña razonablemente dimensionada?
- ¿qué solución habría sido necesaria incluso si la condición se hubiera conocido antes?
- ¿qué parte de la corrección representa costo incremental causado por el evento?
Si el sondeo indicaba claramente la condición y el cálculo desconsideró el dato, la evidencia apunta a una falla de proyecto. Si la campaña contratada era inadecuada por deficiencia del propio alcance de la Administración, el análisis puede involucrar una falla de planificación. Si la condición era geológicamente imprevisible con un nivel razonable de investigación, el evento puede pertenecer a otro riesgo contractual.
El valor de la ingeniería está en producir esta distinción antes de la decisión administrativa.
Ejemplo práctico: el equipo no cabe en el ambiente proyectado
Otro caso común ocurre cuando un equipo especificado no puede instalarse, transportarse o mantenerse en el espacio disponible.
Las posibles causas incluyen:
- dimensiones del equipo conocidas y no coordinadas por arquitectura;
- equipo modificado posteriormente sin actualizar el layout;
- el proveedor entregó un modelo diferente del aprobado;
- la ruta de transporte no fue considerada;
- la infraestructura construida redujo el espacio útil;
- los requisitos de mantenimiento no estaban definidos.
La solución correctiva puede ser idéntica — ampliar una abertura, modificar el layout, desmontar componentes — pero el origen y la responsabilidad cambian según la cadena documental.
Este tipo de problema demuestra por qué el proyecto no es solamente un conjunto de dibujos. Es un sistema de requisitos, interfaces, decisiones y configuraciones que necesita permanecer coherente hasta la entrega del activo.
Checklist para investigar un posible error de proyecto
Antes de concluir que existe responsabilidad del proyectista, verifique si el proceso puede responder:
- ¿Qué requisito fue incumplido?
- ¿Qué documento debía atender el requisito?
- ¿Qué revisión estaba vigente?
- ¿Quién elaboró y quién asumió la responsabilidad técnica por esa parte?
- ¿La ART correspondiente está identificada?
- ¿Qué información estaba disponible cuando se desarrolló la solución?
- ¿El proyecto atendía al nivel de madurez contratado?
- ¿La ejecución siguió íntegramente la solución proyectada?
- ¿Hubo una modificación posterior del requisito, equipo o condición de contorno?
- ¿Existen factores contribuyentes de ejecución, suministro o fiscalización?
- ¿La desviación fue demostrada técnicamente?
- ¿Existe nexo causal entre la desviación y el daño alegado?
- ¿El impacto incremental fue separado del costo que ya existiría normalmente?
- ¿La corrección está formalmente aprobada y reflejada en la documentación vigente?
- ¿Las evidencias anteriores a la corrección fueron preservadas?
Si estas preguntas no pueden responderse, la prioridad debería ser completar la instrucción técnica antes de formular una conclusión de responsabilidad.
Consideraciones finales
La Ley nº 14.133 hizo explícita una obligación que, técnicamente, ya debería formar parte de la buena gobernanza de obras: las modificaciones derivadas de fallas de proyecto no pueden tratarse solamente como un ajuste de planilla. La Administración debe investigar la responsabilidad técnica y adoptar medidas para resarcir los daños cuando estén demostrados.
La calidad de esta investigación depende menos de opiniones retrospectivas y más de la trazabilidad construida durante el proyecto y la obra. Requisitos claros, ART, control de revisiones, Design Review, registros de campo, RFIs, mediciones y gestión de cambios transforman un conflicto potencial en una cuestión técnicamente analizable.
El objetivo no es eliminar toda modificación — algo irreal en emprendimientos complejos —, sino distinguir de forma consistente qué es una falla evitable, qué es ejecución inadecuada, qué es condición sobrevenida y qué es cambio legítimo. Esta distinción protege el interés público, reduce disputas y mejora la calidad de las decisiones de ingeniería.
Cuando una falla ya produjo una modificación de alcance, retrabajo o impacto de plazo, el análisis debe separar la necesidad técnica de la corrección de la responsabilidad y del costo incremental atribuible al evento.
Análisis Técnico de Adendas, Modificaciones de Alcance y Claims
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. Disponible en: https://www.planalto.gov.br/ccivil_03/_ato2019-2022/2021/lei/l14133.htm.
[2] BRASIL. Ley nº 5.194, de 24 de diciembre de 1966. Regula el ejercicio de las profesiones de Ingeniero, Arquitecto e Ingeniero Agrónomo. Disponible en: https://www.planalto.gov.br/ccivil_03/leis/l5194.htm. Disponible en: https://www.planalto.gov.br/ccivil_03/leis/l5194.htm.
[3] BRASIL. Ley nº 6.496, de 7 de diciembre de 1977. Instituye la Anotação de Responsabilidade Técnica en la prestación de servicios de ingeniería, arquitectura y agronomía. Disponible en: https://www.planalto.gov.br/ccivil_03/leis/l6496.htm. Disponible en: https://www.planalto.gov.br/ccivil_03/leis/l6496.htm.
[4] TRIBUNAL DE CONTAS DA UNIÃO. Licitaciones y Contratos: Orientaciones y Jurisprudencia del TCU. Disponible en: https://licitacoesecontratos.tcu.gov.br/. Disponible en: https://licitacoesecontratos.tcu.gov.br/.
Preguntas frecuentes
No. La adenda puede derivar de un cambio legítimo de la Administración, condición sobrevenida, riesgo contractual, modificación de requisito o falla de ejecución. Para caracterizar una falla de proyecto es necesario demostrar requisito, desviación técnica, autoría, nexo causal e impacto.
El art. 124, §1º establece que las modificaciones contractuales derivadas de fallas de proyecto dan lugar a la investigación de responsabilidad del responsable técnico y a la adopción de las medidas necesarias para resarcir los daños causados a la Administración.
No. La Ley 14.133 establece que la recepción definitiva del proyecto no exime al proyectista o consultor de la responsabilidad objetiva por daños causados por una falla de proyecto.
La ART identifica a los responsables técnicos a efectos legales, pero la investigación debe relacionar la ART con el alcance, disciplina, autoría, revisión y decisión técnica efectivamente asociada a la falla. En proyectos multidisciplinarios puede haber responsabilidades distintas o compartidas.
Es necesario comparar la condición ejecutada con el documento vigente, los requisitos y las especificaciones. Si la solución proyectada era correcta y la obra divergió de ella, el origen tiende a ser la ejecución. Si la propia solución liberada era insuficiente o incompatible, existe un indicio de falla de proyecto.
La Administración debe instruir el proceso con su fiscalización y responsables competentes, pudiendo utilizar apoyo técnico especializado. En eventos complejos, un análisis independiente de ingeniería puede reconstruir baseline, causas, responsabilidades e impactos sin sustituir las competencias legales del gestor y del fiscal.
El cálculo debe considerar solamente los impactos atribuibles al evento, separando el costo que ya sería necesario en el alcance original del retrabajo, pérdida de materiales, extensión de plazo, movilización adicional y otros efectos incrementales directamente demostrados.
Materiales técnicos complementarios
Soluciones relacionadas
- Gestión de Requisitos, Evidencias y Criterios de Aceptación
- Gestión de Pendencias, RFIs y No Conformidades
- Gestión de Procesos, Workflows y Aprobaciones Técnicas
- Gestión de Contratos, Alcance y Entregables
Servicios relacionados
- Design Review en Proyectos de Ingeniería
- Proyecto Ejecutivo de Ingeniería
- Owner’s Engineering
- Apoyo Técnico a la Fiscalización de Obras y Contratos de Ingeniería
- Análisis Técnico de Adendas, Modificaciones de Alcance y Claims en Contratos de Ingeniería
Contenidos principales sobre el tema
- ¿Obra sin proyecto ejecutivo? Lo que exige la Ley 14.133 antes de comenzar
- Proyecto Ejecutivo de Ingeniería: qué es, etapas, detalle y entregables
- Proyecto Básico vs. Proyecto Ejecutivo: Diferencias en la Contratación de Ingeniería Consultiva
Contenidos técnicos relacionados
- Design Review en Proyectos de Ingeniería: revisión técnica, interfaces y madurez del proyecto
- Proyecto Multidisciplinario de Ingeniería: disciplinas, coordinación, interfaces y entregables
- Matriz de Asignación de Riesgos en Contratos de Ingeniería
- Adendas Contractuales en Obras y Servicios de Ingeniería
- Project Readiness en Ingeniería
- Owner’s Engineering: framework ejecutivo para contratación, gobernanza y aceptación
- Guía Completa sobre Ingeniería Consultiva
