Cómo estructurar una licitación de IA por etapas (piloto antes del contrato grande)

El error de comprar la promesa antes que la evidencia

El patrón se repite en comité tras comité: se redacta un TDR con alcance amplio (“automatizar el área de servicio al cliente”, “implementar IA en toda la operación comercial”), se reciben propuestas con demos pulidas y capturas de pantalla de otros clientes, se elige a la que suena mejor en la sala, y se firma un contrato de doce o veinticuatro meses. En ningún punto de ese proceso alguien vio el sistema funcionar sobre los datos reales, con los procesos reales y las excepciones reales de esa empresa específica. Se compró una promesa bien presentada, no un resultado demostrado.

El costo de ese error no aparece el día de la firma, aparece seis meses después, cuando el proyecto va atrasado, el proveedor pide “un poco más de tiempo para ajustar”, y el comité descubre que ya no puede salir sin perder la mitad del presupuesto anual asignado al área. Ahí entra la lógica más peligrosa de cualquier compra grande: “ya invertimos tanto, hay que seguir”. El sesgo de costo hundido convierte un mal contrato en un proyecto zombie que nadie se atreve a cerrar, porque cerrarlo significa admitir en el directorio que la decisión estuvo mal desde el inicio.

Lo que casi nadie discute en la mesa de compras es que el problema no fue elegir al proveedor equivocado, fue diseñar un proceso de compra que no dejaba espacio para descubrir el error antes de comprometer el presupuesto completo. Un contrato grande firmado de golpe traslada todo el riesgo de la implementación hacia el comprador: si el proveedor no entendió el proceso de negocio, el comprador se entera cuando ya es caro corregirlo.

Estructurar la licitación por etapas no es burocracia adicional ni una forma de procrastinar la decisión. Es diseñar la secuencia de compra para que la evidencia aparezca antes que el compromiso grande, y para que el criterio de avanzar quede escrito antes de que exista presión política, emocional o de cronograma para justificar seguir con algo que no funciona.

Qué es una licitación de IA por etapas (y qué no es)

La idea central es simple aunque casi nadie la aplica con disciplina: separar la decisión de “probar” de la decisión de “escalar”, y ponerle a cada una su propio contrato, su propio precio y su propio criterio de éxito por escrito. No es una fase informal donde el proveedor “hace una demo antes de firmar”; es una etapa contractual, pagada, con alcance definido y con una condición explícita de paso a la siguiente etapa.

• No es alargar el proceso de compra para evitar decidir: cada etapa tiene plazo fijo y fecha de decisión, no se puede estirar indefinidamente.
• No es pedir trabajo gratis disfrazado de “prueba de interés”: el piloto se paga, a menor escala que el contrato grande, pero se paga.
• No es una licitación tradicional con una demo pegada al final como checkbox: el criterio go/no-go se pacta antes de que el piloto empiece, no se improvisa después de verlo.
• No es una forma de evitar comprometerse con un proveedor: en algún momento, si el piloto funciona, hay que firmar el contrato grande y sostener la relación.
• No es descuento sin evidencia: si no hay un número o un umbral de éxito escrito antes de empezar, no es un piloto serio, es solo una demo con otro nombre.

Etapa 0: el diagnóstico antes de sacar el TDR

El error de diseño más común empieza antes de que exista cualquier proveedor en la conversación: el comité redacta el TDR o el RFP directamente desde la solución (“necesitamos IA para servicio al cliente”) en vez de partir del proceso y del dolor concreto que ese proceso genera. Sin ese diagnóstico previo, cualquier criterio de éxito que se escriba después va a ser vago, y un criterio vago es exactamente lo que un proveedor mediocre necesita para poder decir, al final del piloto, que “sí cumplió”.

La etapa 0 no lleva proveedor todavía. Es trabajo interno, de la empresa, antes de publicar la licitación. El objetivo es llegar al mercado con un problema tan bien definido que cualquier proveedor serio pueda dimensionar el piloto con precisión, y cualquier proveedor que evite responder con precisión quede automáticamente descartado por su propia vaguedad.

• Diagnostica el proceso primero, no la herramienta: describe el flujo real, paso a paso, con sus excepciones, antes de pensar en qué tecnología lo va a tocar.
• Define el KPI concreto que se va a mover: tiempo de respuesta, tasa de error, costo por transacción o volumen atendido, no “mejorar la experiencia” en abstracto.
• Marca la línea base actual con datos propios: si hoy no sabes cuánto tarda o cuánto cuesta el proceso, no vas a poder comprobar después si mejoró.
• Decide con qué datos reales vas a trabajar: qué existe, en qué formato, quién los tiene y qué tan limpios están, porque de eso depende si el piloto es viable en el plazo que quieres.
• Fija un presupuesto techo por etapa, no un presupuesto total: cuánto estás dispuesto a pagar por el piloto es una cifra distinta, y mucho menor, a cuánto estás dispuesto a pagar por el contrato grande.

Etapa 1: el piloto acotado con criterio go/no-go

Qué debe tener el piloto para ser un piloto real

Un piloto que sirve para decidir tiene un alcance deliberadamente pequeño: un proceso, no todos; un área o una línea de servicio, no la operación completa; un volumen de casos definido de antemano, no “lo que salga”. También tiene un plazo corto, medido en semanas y no en meses, porque el objetivo no es construir el sistema completo a escala reducida, es responder una pregunta puntual: ¿este proveedor, con este enfoque, resuelve este dolor específico de nuestra empresa?

El piloto debe correr sobre datos reales de la empresa, no sobre datos de demostración curados por el proveedor, y debe involucrar al mismo equipo y al mismo proceso que se usaría si esto escala, no a un equipo especial armado solo para la prueba. Un piloto que se ve bien porque lo corrió el equipo estrella del proveedor sobre datos limpios seleccionados a mano no dice nada sobre cómo se va a comportar el contrato grande con el equipo normal y los datos normales del día a día.

El criterio go / no-go, pactado antes de empezar

Esta es la parte que casi todos los comités se saltan y que es, en realidad, la más importante de toda la etapa: el criterio de éxito se escribe y se firma antes de que arranque el piloto, no se discute después de ver los resultados. Si el criterio se negocia al final, gana el que tiene más poder de negociación en ese momento, y normalmente es el proveedor, que ya invirtió tiempo y presión para que el comité diga que sí.

• El criterio debe ser numérico o verificable, no “se ve prometedor” ni “el equipo quedó conforme”.
• Debe estar firmado por ambas partes antes del inicio del piloto, como anexo del contrato de piloto, no como acuerdo verbal.
• Debe incluir un umbral mínimo de “no-go”, es decir, qué resultado significa claramente que no se avanza, no solo qué resultado significa que sí.
• Debe evaluarse con los datos que el propio comité puede auditar, no solo con el reporte que entrega el proveedor sobre su propio desempeño.

Este piloto acotado es, en el fondo, una prueba de concepto dentro del marco de la licitación: la misma lógica de una POC corta y bien delimitada, pero atada por escrito a una condición contractual de paso a la siguiente etapa. Sin ese marco contractual, una POC exitosa puede quedar en una demostración simpática que nadie usa para decidir nada.

Etapa 2: el escalamiento condicionado al resultado del piloto

Si el piloto cumple el criterio go pactado, recién ahí se negocia el contrato grande, y esa negociación parte de una posición muy distinta a la que existía antes de ver evidencia: ahora la empresa sabe cuánto esfuerzo real toma el proceso, qué tan limpios están sus datos, qué tan bien lo entendió el proveedor y qué ajustes hicieron falta en el camino. Esa información vale dinero en la mesa de negociación, y no aprovecharla es dejar sobre la mesa una ventaja que costó pagar el piloto para obtener.

El escalamiento no debería ser una simple renovación automática del piloto a mayor escala. Es una nueva negociación, con evidencia de por medio, donde la empresa puede exigir condiciones que antes del piloto no tenía forma de justificar: SLA más estrictos, penalidades atadas a resultado, o un precio distinto al que aparecía en la propuesta original, ahora que ambas partes saben lo que realmente cuesta hacerlo funcionar.

• Repite el criterio de éxito en un segundo lote antes de comprometer el alcance total: un piloto exitoso una sola vez puede ser suerte, no patrón.
• Define por escrito las condiciones de salida del contrato grande: bajo qué circunstancias la empresa puede terminar el contrato sin penalidad si el desempeño se cae después de escalar.
• Ata parte del pago a resultado, no solo a entregables: el proveedor que confía en su propio piloto no debería tener problema con esto.
• Deja SLA, tiempos de respuesta y penalidades por escrito antes de firmar, no como “detalles a resolver en la implementación”.
• No amplíes el alcance del contrato grande sin exigir el mismo rigor de criterio de éxito que se usó en el piloto: escalar no es una excusa para bajar el estándar de evidencia.

Cómo redactar las condiciones de paso entre etapas

Todo esto tiene que quedar escrito en el TDR o el RFP desde el inicio, no negociarse etapa por etapa sobre la marcha. La cláusula de paso entre etapas es, probablemente, el párrafo más importante de todo el documento de licitación, y es también el que casi ningún comité redacta con precisión.

• Qué entrega el proveedor al cierre de cada etapa: un reporte de resultados frente al criterio pactado, no solo “el sistema funcionando”.
• Quién decide el paso a la siguiente etapa: nombra al responsable o al comité, con fecha límite de decisión, para que nadie diluya la responsabilidad.
• Qué pasa si no se cumple el criterio: el contrato de esa etapa termina sin penalidad para la empresa, y el proveedor no tiene derecho automático a una segunda oportunidad sin renegociar.
• Plazo máximo para tomar la decisión de avanzar o no: evita que el piloto se alargue indefinidamente “mientras se evalúa”, que es la forma más común de convertir un piloto en un contrato grande sin haberlo decidido nunca formalmente.
• Precio de cada etapa por separado, nunca un precio único global: si el precio del contrato grande ya está fijado desde el inicio, no hay ningún incentivo real para que el proveedor se esfuerce en el piloto.

Esta forma de redactar reduce el riesgo en los dos lados de la mesa, y por eso vale la pena defenderla incluso frente a proveedores que insisten en “simplificar” con un contrato único. Para la empresa, reduce la exposición financiera y operativa si la implementación no funciona como se prometió. Para el comité de compras, que en la mayoría de organizaciones tiene que justificar el gasto frente a dirección o directorio, tener un piloto con resultado medible es una defensa mucho más sólida que una propuesta bien escrita: “lo probamos con datos reales y cumplió el criterio pactado” pesa más en cualquier comité de riesgo que “la propuesta se veía sólida”.

Cómo se ve en la práctica

Una distribuidora mediana, cerca de ciento veinte personas, en Perú, recibió una propuesta de un proveedor de IA para automatizar la atención de pedidos y consultas de sus clientes mayoristas. La propuesta incluía un contrato de dieciocho meses, alcance amplio (“todo el canal de atención”) y un precio único cerrado. El comité, presionado por reducir el tiempo de respuesta a clientes que llevaba meses como queja recurrente en el directorio, estuvo cerca de firmarlo tal cual llegó.

Antes de firmar, alguien en el comité insistió en partir la contratación: una etapa de piloto de tres semanas, sobre un solo canal (pedidos por WhatsApp de un grupo acotado de clientes), con un criterio go/no-go escrito: el sistema debía resolver correctamente al menos un umbral pactado de consultas sin intervención humana, medido sobre casos reales, no sobre casos de demostración.

El piloto reveló algo que la propuesta nunca mostró: el proveedor había diseñado su solución asumiendo un catálogo de productos fijo y ordenado, y la realidad del negocio era un catálogo que cambiaba semanalmente por temporada, con excepciones de precio por cliente que el proveedor no había preguntado en ninguna reunión previa. El sistema fallaba justo en el tipo de caso más frecuente de la operación real: las excepciones. El criterio de éxito pactado no se cumplió.

El comité no firmó el contrato grande. Volvió al mercado con un TDR mucho más preciso, que ahora incluía explícitamente el manejo de catálogo dinámico y excepciones de precio como requisito evaluable, y con la etapa de piloto ya incorporada como parte estándar de cualquier licitación futura de IA. El costo del piloto fue una fracción mínima de lo que habría costado descubrir el mismo problema seis meses después, con un contrato de dieciocho meses ya en marcha y sin forma barata de salir.

Mi criterio

Cómo saber si estructuraste bien la licitación por etapas

No hace falta un proceso complicado para saber si el diseño de la licitación quedó bien armado. Basta con revisar, antes de publicar el TDR, si estas condiciones están explícitas y por escrito, no asumidas ni dejadas “para conversarlas con el proveedor ganador”.

• El TDR describe el proceso y el dolor real, no solo la tecnología deseada, con línea base medible antes de recibir propuestas.
• Existe una etapa de piloto acotado, pagada, con alcance y plazo definidos, separada contractualmente del contrato grande.
• El criterio go/no-go está redactado y firmado antes de que el piloto empiece, con umbral numérico o verificable en ambos sentidos.
• La cláusula de paso entre etapas nombra quién decide, con qué plazo y qué pasa si no se cumple el criterio, sin ambigüedad ni prórroga automática.
• El precio de cada etapa está separado, de modo que el proveedor tiene incentivo real para que el piloto funcione, no solo para llegar al contrato grande.

Si al revisar el TDR alguna de estas condiciones falta o quedó como “se definirá durante la implementación”, todavía no está lista para salir a licitación. Cerrar esos huecos antes de publicarla cuesta una tarde de trabajo interno; descubrirlos después de firmar el contrato grande cuesta, casi siempre, mucho más que eso.