Las alucinaciones de la IA preocupan en cualquier área de finanzas, pero en construcción tienen un costo particular. En casi ninguna otra industria el monto correcto de un documento depende de tantos otros documentos. Una estimación de obra solo se puede validar mirando el contrato, las órdenes de cambio aprobadas, las estimaciones anteriores y las condiciones de cada subcontrato.
Un modelo de lenguaje que lee la estimación sin consultar todo eso no se detiene a preguntar. Completa lo que falta con el valor más probable. Y en construcción, el valor más probable casi nunca es el que dice el contrato.
En construcción, cada número depende de otro documento. Una IA que adivina siempre va a encontrar algo que adivinar.
La IA alucina en construcción cuando calcula montos a partir de un solo documento. El monto a pagar de una estimación depende del valor del contrato con sus órdenes de cambio, de la retención pactada en ese subcontrato y del saldo de anticipo por amortizar. Si el modelo no consulta esas fuentes, genera cifras plausibles que no coinciden con lo acordado.
Cinco puntos donde un modelo que adivina cambia el monto
Punto 1
El valor del contrato sin las órdenes de cambio
La estimación dice 40% de avance. ¿40% de qué? Si el modelo toma el monto original del subcontrato y no suma las órdenes de cambio aprobadas, calcula el avance sobre una base equivocada. El resultado se ve correcto y está mal.
Punto 2
La retención de garantía que se asume
Cada subcontrato puede pactar un porcentaje de retención distinto. Un modelo que no tiene el contrato a la mano usa el que aparece con más frecuencia en los documentos que ha visto. Si el pactado era 5% y el modelo aplica 10%, al subcontratista se le retiene el doble.
Punto 3
La amortización del anticipo sin historial
Para descontar correctamente el anticipo hay que saber cuánto se pagó, cuánto ya se amortizó en estimaciones anteriores y cuánto queda. Sin ese historial, el modelo calcula un descuento que parece lógico, aunque el saldo real sea otro.
Punto 4
El código de costo que suena correcto
Los catálogos de costos cambian de un proyecto a otro. Un modelo puede asignar un código que existe y tiene un nombre parecido al concepto de la factura, pero que pertenece a otra partida. El costo queda en el lugar equivocado y el margen del proyecto se distorsiona.
Punto 5
La orden de cambio que todavía no se aprueba
Una orden de cambio propuesta y una aprobada se ven casi iguales en papel. Si el modelo trata la propuesta como aprobada, se paga un trabajo que todavía está en negociación.
Un ejemplo para ver la diferencia
Este caso es ilustrativo y no corresponde a un proyecto real. Un subcontrato de USD 800,000 con una orden de cambio aprobada por USD 50,000. La retención pactada es de 5% y el anticipo de 20% se amortiza en proporción a cada estimación. Llega una estimación con 40% de avance.
| Concepto |
Validado contra el contrato |
Calculado por un modelo que adivina |
| Base del contrato |
USD 850,000 |
USD 800,000 |
| Monto estimado al 40% |
USD 340,000 |
USD 320,000 |
| Retención de garantía |
USD 17,000 (5%) |
USD 32,000 (10%) |
| Amortización de anticipo |
USD 68,000 |
USD 64,000 |
| Monto a pagar |
USD 255,000 |
USD 224,000 |
Una diferencia de USD 31,000 en una sola estimación. Ninguno de los dos montos se ve raro a simple vista, y los dos se pueden registrar en el ERP sin una sola alerta. El error aparece cuando el subcontratista reclama, cuando se concilia contra el contrato o en la auditoría del proyecto.
Por qué pasa
Un modelo de lenguaje funciona prediciendo la respuesta más probable. Eso lo hace muy bueno para leer documentos con formatos distintos, como una estimación escaneada, una factura en PDF o una orden de cambio enviada por correo. Lo que no hace por sí solo es comprobar si el número que generó coincide con una fuente externa.
Cuando el dato está en el documento, lo extrae bien. Cuando el dato depende de otro documento que no tiene, lo completa. Lo desarrollamos a fondo en el artículo sobre agentes IA que alucinan en contabilidad.
Leer con una capa, validar con otra
La forma de usar IA en construcción sin este riesgo es separar dos trabajos que un modelo de lenguaje mezcla. Una capa neural lee el documento, sin importar el formato. Una capa simbólica separada valida cada dato contra las fuentes del proyecto antes de registrarlo. Esa capa no genera texto ni puede inventar un valor.
Modelo que adivina
Lee la estimación, completa lo que falta con el valor más probable y entrega un monto que se ve correcto.
Arquitectura neuro-simbólica
Lee la estimación y compara cada dato contra el contrato, las órdenes de cambio aprobadas, el historial de anticipos y el catálogo de costos. Si algo no se puede verificar, se detiene y lo escala con la explicación.
Así funciona un trabajador digital Pantera sobre ERPs de construcción como CMiC, Viewpoint o Sage, y sobre cualquier otro que la empresa ya tenga. El equipo de control de obra sigue aprobando y resolviendo las excepciones. Lo que cambia es que cada monto que llega a su revisión ya se comparó contra el contrato, y lo que no cuadra llega con el motivo exacto.
Si quieres ver qué otros errores entran al sistema sin alerta, en tu ERP no te va a avisar repasamos cinco casos que aplican a cualquier industria.
Bottom line. En construcción, el monto correcto casi nunca está completo en un solo documento. Una IA que lo completa por probabilidad va a acertar muchas veces y a equivocarse justo donde más cuesta.
.png)
.png){kind=logo}
.png)