Caso práctico: cuando la IA produce mediocridad industrial

Este artículo prolonga Licitaciones e IA: hacia una mutación silenciosa del mercado, donde planteábamos la constatación: la mayoría de los enfoques actuales automatizan lo incorrecto. Aquí entramos en lo concreto. Un caso real. Un fracaso real. Y lo que nos enseña.

El proyecto

Una empresa de servicios de tamaño significativo — varios miles de consultores, cientos de respuestas a licitaciones por año. La constatación inicial es sensata: dedicamos demasiado tiempo a redactar, tenemos un historial rico de respuestas ganadoras, ¿por qué no entrenar un modelo para capitalizar sobre él?

El proyecto es ambicioso. Presupuesto de varios millones de euros. Desarrollo offshore. Un equipo dedicado durante más de un año. El objetivo: una herramienta interna capaz de generar respuestas técnicas a partir del historial de ofertas pasadas.

Varios millones de euros y más de un año de desarrollo para construir un copiar-pegar estadísticamente optimizado.

Sobre el papel, es sentido común. En la práctica, es una catástrofe anunciada.

El error fundamental: ninguna ontología

El modelo fue entrenado con cientos de respuestas pasadas. Secciones técnicas, párrafos metodológicos, referencias de proyectos, compromisos de servicio. A granel.

El problema: no se construyó ninguna estructura semántica previamente.

El modelo no distingue:

• Agile vs. Ciclo en V — dos filosofías de delivery radicalmente diferentes, mezcladas en el mismo corpus de entrenamiento
• Kubernetes vs. arquitectura monolítica — paradigmas de infraestructura opuestos, tratados como bloques de texto intercambiables
• Un pliego para un ministerio vs. un pliego para una startup — contextos de negocio, niveles de exigencia, culturas de decisión que no tienen nada en común
• Una oferta ganadora vs. una oferta perdedora — ninguna ponderación. El modelo aprende tanto de los fracasos como de los éxitos, sin saberlo

Resultado: el modelo aprendió el estilo de la empresa, no su inteligencia. Sabe producir frases que se parecen a respuestas de licitaciones. No sabe por qué esas frases existen.

El resultado: la máquina de mediocridad

Después de más de un año de desarrollo y varios millones invertidos, la herramienta se entrega. Las primeras pruebas son reveladoras.

Tomemos un caso concreto. Un pliego de prescripciones técnicas para la renovación de un SI de gestión de recursos humanos de una administración local. El pliego insiste especialmente en:

• La recuperación de datos desde un sistema legacy envejecido
• La accesibilidad (RGAA)
• Un calendario ajustado con una puesta en producción antes de las elecciones

He aquí lo que produce el modelo (reconstrucción anonimizada):

Respuesta generada por el modelo:

"Nuestro enfoque metodológico se apoya en un procedimiento probado que combina las mejores prácticas Agile y los principios del ciclo en V para garantizar un delivery de calidad. Nuestro equipo pluridisciplinario movilizará expertos técnicos y funcionales para asegurar el éxito del proyecto. Proponemos una arquitectura moderna, escalable y segura, basada en los estándares del mercado."

Todo es verdad. Nada es útil.

• "Combinando Agile y ciclo en V" — porque el corpus contenía ambos, y el modelo aprendió a no molestar a nadie
• "Equipo pluridisciplinario" — frase presente en el 90 % de las ofertas de entrenamiento
• "Arquitectura moderna, escalable y segura" — la trinidad vacía, aplicable a cualquier proyecto
• Ninguna mención de la recuperación de datos (el verdadero tema)
• Ninguna mención de la accesibilidad RGAA (un requisito regulatorio)
• Ninguna mención del calendario ajustado (el riesgo principal)

El modelo produjo la media estadística de todas las respuestas pasadas. Una respuesta mediana. Técnicamente correcta. Estratégicamente vacía.

Ahora, comparemos con lo que un bid manager competente habría escrito:

Respuesta contextualizada:

"El riesgo principal de este proyecto no es técnico — es la recuperación de datos desde [sistema legacy], cuya documentación es parcial y los formatos no estandarizados. Proponemos un sprint 0 de 4 semanas dedicado exclusivamente a la auditoría y al mapeo de los datos existentes, antes de cualquier desarrollo. Este enfoque asegura el calendario de puesta en producción que ustedes han fijado en [fecha], identificando los bloqueos reales antes de que se conviertan en retrasos.

En cuanto a la accesibilidad RGAA, integramos una auditoría de conformidad en cada sprint, no en la recepción final. [Referencia de proyecto similar con resultado medible]."

La diferencia no está en la calidad redaccional. Está en la comprensión del problema.

La primera respuesta dice "somos buenos". La segunda dice "hemos entendido su dolor, he aquí cómo lo tratamos". Una tranquiliza vagamente. La otra convence.

---

El diagnóstico

¿Por qué no funciona? Porque el enfoque se basa en una hipótesis falsa: el pasado contiene las respuestas al futuro.

Entrenar un modelo con sus ofertas pasadas es enseñarle a reproducir lo que usted ya hizo. No a entender lo que el cliente pide. Es copiar-pegar estadísticamente optimizado.

Los problemas estructurales:

• Sin segmentación semántica. El modelo no sabe que "Agile" en un contexto bancario y "Agile" en un contexto industrial son dos realidades diferentes. Aprendió la palabra, no el concepto.
• Sin vínculo entre contexto y respuesta. El modelo genera bloques de texto, pero no sabe por qué tal bloque era pertinente para tal contrato. No lee el pliego — lo sobrevuela para encontrar palabras clave activadoras.
• Sin noción de calidad. Oferta ganadora, oferta perdedora, oferta mediana — todo tiene el mismo peso en el corpus. El modelo no tiene ninguna señal de lo que funciona.
• Sin adaptación al cliente. El modelo produce jerga corporativa genérica. No sabe quién está enfrente, qué le importa, qué lo diferencia de los otros compradores.

En resumen: entrenar con el pasado sin estructura semántica es aprender a copiar-pegar inteligentemente. Sin comprensión. Sin diferenciación.

Por qué es una trampa frecuente

Esta empresa de servicios no es un caso aislado. El razonamiento es tentador:

1. Tenemos 10 años de ofertas en nuestros servidores
2. La IA es buena con datos textuales
3. Luego: entrenamos un modelo con nuestras ofertas = ventaja competitiva

Es lógico. Es falso. He aquí por qué:

• El volumen no es el valor. 500 respuestas pasadas de las cuales 200 perdieron, 150 eran mediocres y 150 eran buenas — pero usted no sabe cuáles son cuáles. El modelo aprende una mezcla.
• El contexto es rey. Una respuesta brillante para un contrato de 2022 es potencialmente obsoleta para un contrato de 2026. Las tecnologías cambian. Las regulaciones evolucionan. Las expectativas de los clientes mutan.
• La ventaja competitiva no está en las palabras. Está en la capacidad de entender lo que el cliente realmente quiere, más allá de lo que escribe. Ningún modelo entrenado con sus antiguas ofertas sabe hacer eso.

La alternativa: razonar con el futuro, no con el pasado

El buen paradigma no es "¿qué hemos escrito ya de similar?". Es: "¿qué quiere este cliente específico, para él, y cómo aportarle aún más de lo que pide?"

Eso implica una arquitectura radicalmente diferente:

1. Cuestionar cada información atómica del pliego de condiciones. No sobrevolar. No resumir. Interrogar. Cada requisito, cada restricción, cada formulación es una señal. "El cliente escribió 'imperativamente' aquí y 'si es posible' allá — ¿por qué?" "Hay 15 páginas sobre infraestructura y 2 sobre aplicativo — ¿qué dice eso de sus prioridades?" "Menciona tres veces la recuperación de datos — ahí es donde le duele."

2. No razonar con el pasado. El historial puede informar (referencia de cliente, retorno de experiencia). No debe dictar. Cada contrato es un nuevo problema. El cliente no quiere saber lo que usted hizo para los demás — quiere saber lo que va a hacer para él.

3. Razonar con el futuro. ¿Qué quiere este cliente en 3 años? ¿Cuál es el problema detrás del problema? ¿Qué no se atrevió a escribir en el pliego porque no sabe que es posible? Ahí es donde se ganan los contratos. No en la capacidad de reciclar párrafos, sino en la capacidad de anticipar.

4. Construir una ontología, no un corpus. La diferencia entre una base de datos de texto y una inteligencia es la estructura semántica. Saber que "Agile" en este contexto significa "Scrum con sprints de 2 semanas y un equipo de 5" — no "somos flexibles". Saber que "arquitectura cloud-native" para este cliente significa "migramos desde on-premise y tenemos miedo" — no "Kubernetes everywhere".

Lo que hay que recordar

La diferencia entre "automatizar las licitaciones" y "comprender las licitaciones" no reside en el volumen de datos de entrenamiento. Reside en dos cosas:

• La ontología: la capacidad de dar sentido a la información, no solo de almacenarla
• El razonamiento orientado al cliente: la capacidad de partir de la necesidad real del cliente, no de lo que ya tiene en stock

La empresa de este caso de estudio invirtió millones para construir una herramienta que hace exactamente lo que un bid manager agotado hace un viernes por la noche: copiar-pegar a partir del último expediente que se parece vagamente al nuevo. Más rápido, cierto. Pero no mejor.

La IA en las licitaciones no es un problema de datos. Es un problema de cognición.

Para recordar: Entrenar un modelo con sus ofertas pasadas sin ontología es aprender a copiar-pegar inteligentemente. La diferencia entre automatizar y comprender no reside en el volumen de datos — reside en la capacidad de dar sentido.

---

En TenderGraph, no reciclamos sus antiguas ofertas. Construimos agentes capaces de leer un pliego de condiciones como lo haría un bid manager senior — buscando lo no dicho, cuestionando cada requisito, razonando para el cliente que está enfrente. No para el promedio de sus clientes pasados.

---

Lea también:

• Licitaciones e IA: hacia una mutación silenciosa del mercado — La constatación macro: por qué el mercado está cambiando, y lo que implica.
• El peor enemigo del bid manager: él mismo — La otra cara del problema: incluso sin una mala herramienta, el cerebro humano sabotea el proceso de respuesta.
• El mito del resumen ejecutivo — El resumen ejecutivo genérico es el síntoma más visible de la ausencia de ontología.
• La trampa del throughput — Producir más rápido sin ontología = mediocridad industrial a gran escala.
• Por qué sus referencias de clientes no convencen a nadie — El modelo escupía referencias sin pertinencia. He aquí por qué es un problema estructural, no tecnológico.
• Lo que el pliego de prescripciones técnicas no dice — El modelo de la empresa no detectaba las ambigüedades. Un sistema cognitivo las señala y las transforma en preguntas.
• La revolución informacional — La empresa construyó una máquina de ruido industrial. El marco señal/ruido explica por qué.
• La aceleración de los ciclos de preventa — La buena herramienta acelera. La mala acelera la mediocridad. Y después, ¿qué se hace con el tiempo ganado?
• Las competencias de la preventa en la era de la IA — La empresa subcontrató la comprensión a la IA. La competencia que faltaba: la lectura de la señal humana.
• Analizar una licitación como se debería analizar la actualidad — El modelo de la empresa producía el equivalente de publicaciones virales: ruido industrial con la gramática de la señal.
• La preventa es un ejercicio de mando — Operar sin mapa: cuando la IA produce sin conocer el terreno.