Un modelo de lenguaje levanta una asignación de costes en dos días. Un equipo financiero defiende luego esa asignación ante operaciones, comercial y un auditor durante los seis meses siguientes. La distancia entre esos dos calendarios es todo el argumento de este texto: el modelo es ahora la parte barata, y la validación es a donde se ha mudado el trabajo.

¿Qué cambió cuando el modelo se volvió rápido?

Durante la mayor parte de nuestros 25 años, construir el modelo era el cuello de botella. Mapear actividades, entrevistar a dueños de proceso, estimar ecuaciones de tiempo, cablear los drivers. Meses de eso. La validación era casi una formalidad al final, porque para cuando habías construido la cosa a mano la conocías de forma íntima.

Ese orden se ha invertido. Un modelo puede aparecer ahora en días, ensamblado por alguien que nunca se sentó con los dueños de proceso y no sabe decir por qué se eligió un driver determinado. El artefacto parece igual. La comprensión detrás de él todavía no existe. La validación ya no es la formalidad del final. Es el sitio donde la comprensión que falta tiene que reconstruirse.

¿Por qué la construcción rápida hace la validación más difícil y no más fácil?

Un modelo construido a mano lleva su propio rastro de auditoría en la cabeza de quienes lo construyeron. Pregunta por qué el coste de setup se asigna por lote y alguien recuerda la discusión que tuvo sobre eso en marzo.

Un modelo rápido no lleva esa memoria. Te da una asignación de setup, sonará seguro, y no hay nadie en la sala que haya peleado por esa decisión. Así que la validación no puede apoyarse en recuerdos. Tiene que reconstruir de forma independiente si la decisión era correcta: este driver refleja consumo real, el total concilia, el margen sobrevive a una prueba de esfuerzo. Eso es más lento que sellar un modelo que construiste tú, y debe serlo.

Hay un segundo problema, más sutil. Un modelo que construyes a mano te enseña el negocio mientras lo construyes. Descubres que dos líneas de producto que suponías parecidas consumen tiempo de setup de forma muy distinta, y ese descubrimiento cambia en silencio cómo lees cada número posterior. Un modelo entregado ya terminado se salta esa educación. Heredas las conclusiones sin el aprendizaje, lo que significa que la primera vez que entiendes de verdad el negocio es durante la validación, con el tiempo apretando y un resultado ya sobre la mesa que todos en la sala preferirían creer.

¿A dónde deben ir ahora las horas de ingeniería?

A después de que el modelo exista. En concreto:

– Conciliación primero. Antes de discutir cualquier asignación aislada, confirma que los totales del modelo cuadran con el libro mayor. Un modelo que no concilia no merece discutirse línea por línea. – Escrutinio de los drivers a continuación. Recorre el puñado de asignaciones que cargan más coste y pregunta si el driver refleja cómo se consume de verdad el recurso. La mayor parte del riesgo está en un pequeño número de pools grandes. – Esfuerzo y deriva al final. Fuerza los supuestos y luego decide con qué frecuencia se vuelve a revisar el modelo. Un modelo es una fotografía de un negocio en un momento, y los negocios se mueven.

Esta es la lógica de correr la validación como un paso distinto e independiente, en vez de una casilla que marcar al cierre. Describimos cómo lo secuenciamos en /how-we-work/.

¿Cómo se conecta esto con la regulación?

Ligeramente, pero vale la pena decirlo. El EU AI Act empuja a las organizaciones a poder demostrar que un sistema influido por IA fue revisado, documentado y gobernado. Un modelo de costes que, en silencio, dirige decisiones de precio o de inversión es exactamente el tipo de sistema que se beneficia de un registro de validación defendible. La validación lenta no es solo buena ingeniería. Resulta ser el rastro en papel que quieres tener cuando alguien pregunta cómo se verificó el número. Las organizaciones que van a sufrir son las que tratan un modelo de costes generado por IA como una respuesta acabada en vez de un borrador que hay que defender. Un paso de validación produce, casi como subproducto, la documentación que un regulador o un auditor acabará pidiendo: qué se comprobó, qué se encontró, qué se aceptó y por qué.

¿Construir el modelo rápido es malo?

No. Usamos estas herramientas y nos alegramos de que la construcción se abaratara. Construcción barata significa poder construir tres modelos candidatos y compararlos, lo que antes era un lujo. El error es tratar la velocidad de la construcción como si fuera la velocidad de la confianza. No lo es. El modelo está listo en dos días. La confianza se gana a lo largo de los meses que pasas probándolo. Hemos visto modelos técnicamente correctos en la entrega perder utilidad en silencio en dos trimestres porque nadie asumió la nueva revisión. La construcción nunca fue el riesgo. El riesgo es tratar un primer borrador rápido como un hecho asentado.

Conclusión: presupuesta la validación como el evento principal, no como el remate. Si la construcción llevó dos días, eso es información sobre la construcción y no dice nada sobre si el modelo está bien. Empieza por la conciliación, escruta los pools más grandes y guarda registro. Más sobre el paso de validación en /ai-profitability/.