Por Qué la IA en Construcción se Atasca en la Capa de Datos

El ochenta y siete por ciento de los contratistas estadounidenses cree que la IA va a transformar significativamente su negocio. El veintiséis por ciento califica como alta la calidad de sus datos actuales. Esa distancia no es una distancia de entusiasmo ni de tecnología: es la razón por la que la mayoría de los proyectos de IA en construcción se atasca entre un piloto prometedor y cualquier cosa en producción.

Resumen rápido

• En una encuesta de finales de 2025 a 235 contratistas generales y de oficio en EE. UU., el 87% esperaba que la IA transformara su negocio y solo el 26% calificó su calidad de datos como alta.
• De 23 funciones de IA evaluadas en esa encuesta, 20 eran usadas por menos del 15% de los encuestados: la expectativa es casi universal, la adopción no.
• Otra encuesta de 2026 a 2.500 líderes del sector encontró que la integración con sistemas heredados es la barrera número uno para la IA, citada por el 50%.
• El cuello de botella no es el modelo. Es que los datos que el modelo necesitaría están repartidos en sistemas que no coinciden, registrados de forma inconsistente, o simplemente no registrados.
• Es decir: la mayor parte del trabajo de IA en construcción es trabajo de integración e ingeniería de datos, y dimensionarlo como otra cosa es como estos proyectos se alargan.

Ese encuadre —que el problema interesante está debajo de la funcionalidad, en la capa que nadie demuestra— recorre todo este vertical. Más al respecto en qué construyen las empresas de construcción cuando su plataforma se queda corta.

¿Qué dicen realmente las cifras?

El dato reciente más específico viene de una encuesta de Dodge Construction Network y CMiC a 235 contratistas generales y de oficio en EE. UU., realizada a finales de 2025. Tres hallazgos importan más que el titular.

La expectativa es casi universal. El 87% cree que la IA transformará significativamente su negocio; el 85% espera reducir el tiempo en tareas repetitivas. Entre los contratistas grandes, el 86% cree que la IA da ventaja competitiva.

La adopción no lo es. De 23 funciones de IA evaluadas, 20 eran usadas por menos del 15% de los encuestados. Solo el 19% estaba adaptando flujos de trabajo heredados para IA, que es el paso que convierte una herramienta en una capacidad.

Y la restricción se ve en los datos. Solo el 26% calificó como alta la calidad de sus datos actuales. Al mismo tiempo, el 57% citó preocupaciones sobre la precisión y confiabilidad del resultado como barrera. Esos dos hallazgos son el mismo hallazgo: un modelo entrenado o fundamentado en datos inconsistentes produce salidas poco confiables, y la gente que lo usa deja de confiar en él, con razón.

Una encuesta de 2026 a 2.500 líderes del sector apunta al mismo lugar desde otro ángulo: la integración con sistemas heredados fue la barrera más citada para la adopción de IA, nombrada por el 50% de los encuestados, por encima del talento, el costo, la regulación y la medición de retorno.

¿Por qué los datos de construcción son más difíciles de lo que parecen?

Porque la información existe; simplemente no está en una forma que algo pueda consumir.

Un contratista sabe cuánto cuesta un metro lineal de conduit. Ese conocimiento vive en el criterio de un presupuestador, en una hoja de cálculo del último proyecto parecido, en el sistema contable bajo un código de costo que significa algo ligeramente distinto a lo que significaba hace dos años, y en un correo de un proveedor. Los cuatro son correctos. Ninguno es consultable, y no coinciden entre sí.

Esta es la versión estructural de un hallazgo que lleva años vigente: en la última medición sistemática de tecnología en construcción, el 62% de las empresas seguía presupuestando en hojas de cálculo y el 49% movía datos entre aplicaciones a mano. Una hoja de cálculo no es un problema de calidad de datos en sí misma —mucho buen trabajo ocurre en hojas de cálculo—. Se convierte en uno en el momento en que quiere que un sistema aprenda de cuatrocientas de ellas.

Los tres modos de falla, en orden creciente de dificultad:

Los datos no están en un sistema. Están en hojas de cálculo, correos o personas. Se arregla con un proyecto, medido en meses.

Los datos están en un sistema pero registrados de forma inconsistente. La misma actividad se codifica distinto entre proyectos, entre equipos, o antes y después de que alguien reorganizó la estructura de códigos de costo. Se arregla, pero exige cambiar cómo trabaja la gente, lo que se mide en trimestres.

Los datos están en un sistema, son consistentes, y son inalcanzables. Están en una plataforma cuya exportación es un CSV que un humano tiene que descargar. Este es el que parece más fácil y muchas veces es el que decide si el proyecto es viable, porque determina si algo se puede automatizar o si alguien va a estar exportando cada semana para siempre.

¿Qué trabajo de IA no depende de tener datos limpios?

Esta es la distinción que hace que un proyecto se entregue en semanas en vez de trimestres, y se colapsa constantemente.

El trabajo de lenguaje tolera el desorden. Leer un submittal, resumir un hilo de RFI, extraer cláusulas de un contrato, clasificar un documento entrante: todo esto opera sobre insumos no estructurados porque los insumos no estructurados son para lo que fue construido. Un contratista con datos genuinamente caóticos igual puede obtener valor aquí, de inmediato.

La predicción y la estimación no. Proyectar un cronograma, estimar un costo a partir de la historia, optimizar una secuencia, detectar una anomalía: todo esto aprende de su pasado, así que hereda la inconsistencia que ese pasado contenga. Corra esto sobre datos no preparados y el resultado es confiadamente incorrecto, que es peor que no tener resultado.

La fila del modo de falla es la que vale la pena sopesar. Un resumen malo se ve obviamente malo, así que una persona lo detecta. Un pronóstico de costo 18% bajo se ve exactamente igual a uno correcto, y nadie lo detecta hasta que la obra ya arrancó. CodeBranch toma esa asimetría como la razón para secuenciar estas dos cosas de forma distinta, no como un detalle.

¿Qué busca una evaluación de preparación?

Tres preguntas, respondidas contra datos reales y no contra una descripción del sistema.

¿Existen los datos en un sistema que se pueda consultar sin una persona en el medio? ¿Se registra lo mismo del mundo real de la misma manera entre proyectos, equipos y a lo largo del tiempo? ¿Y se pueden extraer de forma programada sin una exportación manual?

Las respuestas determinan la forma del proyecto. Si las tres son sí, el trabajo de IA es el trabajo de IA. Si la tercera es no, la primera fase es integración. Si la segunda es no, la primera fase es una conversación sobre cómo la organización registra las cosas, que no es un proyecto de software y no debería cotizarse como tal.

CodeBranch corre esto como un trabajo discreto —una evaluación de preparación para IA— precisamente porque la respuesta cambia el alcance en un orden de magnitud, y descubrirlo después de firmar una propuesta es como estos proyectos salen mal para ambas partes.

¿Cómo se ve esto cuando funciona?

El patrón que vale la pena copiar es que el modelo es la parte pequeña.

En una plataforma de cotización que CodeBranch construyó para un contratista eléctrico, un motor de recomendaciones con IA sugiere componentes mientras el usuario diseña un proyecto de domótica sobre un plano, y funciona: las recomendaciones son completas e instalables. La razón por la que funciona no es el modelo. Es que las dependencias entre componentes se modelaron explícitamente primero: qué dispositivos requieren qué controladores, qué implica una configuración dada en cableado y mano de obra. La IA opera sobre una estructura que describe el dominio correctamente.

Quite esa estructura y el mismo modelo produciría sugerencias plausibles que no suman una instalación funcional. La inteligencia de la funcionalidad viene en su mayor parte de la capa de datos que tiene debajo, y esa capa fue trabajo de ingeniería, no de prompting.

Esa es la forma general. La funcionalidad de IA es el décimo visible de un proyecto cuyos otros nueve décimos consisten en hacer que los datos signifiquen algo consistente.

¿Por dónde debería empezar un contratista?

Empiece por lo que es cierto sin importar la decisión sobre IA: meta los datos de sus proyectos en un sistema que se pueda consultar.

Eso vale la pena por mérito propio. Un contratista que puede preguntarle a su propia historia cuánto ha costado realmente el metro cuadrado de un ensamble determinado en los últimos veinte proyectos ganó algo real, con o sin un modelo encima. Y resulta ser el prerrequisito de toda capacidad de predicción y estimación que valga la pena tener.

Después corra el trabajo de lenguaje y documentos en paralelo, porque no depende de esa base y puede entregar valor mientras la base se construye.

Lo que CodeBranch evitaría es la secuencia que siguieron la mayoría de los proyectos atascados: elegir un caso de uso de IA impresionante, construir un piloto sobre datos curados a mano, demostrarlo con éxito, y después descubrir que los datos de producción no lo sostienen. El piloto no estaba equivocado. Simplemente midió la cosa equivocada.

Ese orden —capa de datos primero, modelo después— es como CodeBranch aborda el software para empresas de construcción en general, porque el trabajo de integración de abajo es lo que hace posible cualquier cosa que vaya encima.