Cómo armar un RFP para contratar un proveedor de IA

Por qué la mayoría de los RFP de IA producen basura comparativa

El error empieza antes de escribir la primera línea del RFP: se redacta para “que todos puedan participar”, cuando el objetivo real es que solo los proveedores que entendieron el problema puedan proponer algo serio. Un RFP abierto, genérico, que describe la necesidad en dos párrafos vagos y pide “su mejor propuesta de solución con IA”, no filtra nada. Filtra al revés: atrae a quien vende una herramienta genérica con una capa de marketing y espanta al que necesitaría tiempo real para diagnosticar antes de proponer un precio serio.

El resultado es previsible. Llegan entre ocho y quince propuestas con formatos distintos, alcances distintos, supuestos distintos y ningún criterio común para pararlas una junto a otra. Una habla de “implementación en 4 a 6 semanas” sin decir qué incluye esa implementación. Otra cotiza una plataforma completa sin mencionar quién carga los datos ni quién los mantiene después. El comité de compras termina comparando estética de PDF, no capacidad real de resolver el problema.

Y ahí aparece el sesgo más caro de todos: cuando nadie puede comparar con criterio, la decisión se mueve hacia la relación. Se adjudica al proveedor que ya trabaja con la empresa, al que tiene un contacto interno, al que “se ve confiable” en la reunión. No porque nadie quiera hacer trampa, sino porque el RFP no dejó ninguna vara objetiva contra la cual medir. Nadie compra herramientas, la gente compra resultados, pero un RFP mal armado hace prácticamente imposible evaluar resultado esperado, así que la decisión termina anclada en otra cosa.

Un RFP de IA que funciona no busca maximizar el número de propuestas recibidas. Busca maximizar la calidad comparativa de las tres o cuatro propuestas serias que sí van a llegar. Eso empieza por entender qué es (y qué no es) un RFP, y por qué se confunde tanto con el documento que debería redactarse antes.

Qué es un RFP de IA (y qué no)

RFP son las siglas de request for proposal: solicitud de propuesta. En un proceso de contratación de IA es el documento que se envía a un grupo corto de proveedores preseleccionados para que presenten su enfoque, su forma de trabajo y su cotización sobre un problema de negocio ya delimitado. No es el primer documento del proceso: llega después de que la empresa ya hizo el trabajo de definir qué problema quiere resolver y con qué evidencia lo sostiene.

• No es un catálogo de deseos: un RFP no enumera todas las funciones de IA que “estaría bien tener”, porque eso invita a cotizar features en vez de resolver un problema.
• No es el TDR: el TDR define el requerimiento técnico y de negocio; el RFP es la invitación a proponer sobre ese requerimiento y las reglas del juego para competir por él.
• No es una cotización disfrazada: pedir “su propuesta y precio” sin pedir enfoque, método y supuestos es un pedido de cotización, no un RFP.
• No es un filtro de marca: un buen RFP no premia al proveedor más conocido; premia al que demuestra entender el problema con más precisión.
• No es un documento que se reutiliza igual para todo: un RFP genérico copiado de otro proyecto casi nunca refleja el problema real que se quiere resolver.

RFP y TDR no son el mismo documento: la diferencia que nadie explica

Es común que una empresa junte los dos documentos en uno y termine con algo que no cumple ninguna de las dos funciones bien. El TDR (términos de referencia) responde la pregunta “¿qué necesito resolver, con qué alcance, con qué restricciones?”. Es el documento que exige un diagnóstico previo: qué proceso falla, con qué evidencia, qué KPI se busca mover, qué datos existen y en qué estado. Ese trabajo se hace antes de invitar a nadie a proponer nada.

El RFP viene después y responde una pregunta distinta: “dado ese requerimiento, ¿cómo se van a comparar las propuestas que lleguen?”. El RFP toma el TDR como insumo (o lo incluye como anexo) y agrega las reglas del juego: a quién se invita, qué formato debe tener la propuesta, qué criterios se van a pesar, qué preguntas son obligatorias, y en qué fecha se decide. Un TDR bien hecho sin un RFP que ordene la competencia sigue produciendo propuestas incomparables. Y un RFP prolijo sobre un TDR flojo produce propuestas prolijas sobre un problema mal definido, que es igual de caro.

La regla práctica: si tu equipo no puede explicar en una frase la diferencia entre lo que pide el TDR y lo que pide el RFP, probablemente estás usando un solo documento para las dos funciones, y eso es exactamente lo que produce las doce propuestas incomparables del punto anterior.

La estructura de un RFP de IA que sí sirve

Un RFP de IA serio tiene seis piezas. No hace falta que sean seis documentos separados, pero sí seis secciones identificables, porque cada una filtra algo distinto.

Contexto y problema

Empieza describiendo el proceso de negocio afectado, no la tecnología deseada: qué está pasando, qué evidencia lo sostiene, qué se ha intentado antes y con qué resultado. Un proveedor que lee esta sección y entiende el dolor real propone distinto a uno que solo lee “necesitamos IA para X área”.

Qué se pide proponer

• Enfoque y método, no solo precio: cómo diagnosticarían antes de implementar, qué fases proponen, qué asumen que ya existe y qué asumen que falta.
• Alcance explícito: qué queda dentro y qué queda fuera de la propuesta, para no descubrir el límite después de firmar.
• Plan de datos: de dónde saldría la información, quién la prepara, qué calidad mínima se necesita.
• Plan de continuidad: quién opera el sistema después de la implementación y con qué nivel de dependencia del proveedor.
• Riesgos que ellos mismos identifican: un proveedor que no puede nombrar un riesgo de su propia propuesta es una señal de alerta, no de confianza.

Formato de propuesta y criterios de evaluación: cómo comparar sin adivinar

La parte que más RFP olvidan es exigir un formato común de respuesta. Sin eso, cada proveedor cuenta su historia a su manera y el comité termina comparando estilos de redacción, no contenido. Pedir una estructura fija, aunque sea simple, es lo que permite poner tres propuestas una al lado de la otra y ver la misma información en el mismo orden.

• Diagnóstico entendido: en sus propias palabras, qué problema de negocio identificaron y con qué evidencia lo justifican.
• Enfoque propuesto: fases, entregables, tiempos por fase, no solo un tiempo total.
• Equipo asignado: quién ejecuta realmente, no solo quién vende, con su experiencia relevante.
• Precio desglosado: por fase o por componente, no un número único que oculta qué se está pagando.
• Supuestos y exclusiones: qué da por sentado el proveedor y qué explícitamente no incluye.

Los criterios de evaluación deben publicarse en el mismo RFP, con su peso, antes de recibir ninguna propuesta. Esto evita el reclamo, muchas veces justificado, de que la adjudicación se ajustó después para favorecer a alguien.

• Comprensión del problema y del proceso de negocio (peso alto): ¿el proveedor demuestra que entendió el dolor, o repitió el enunciado del RFP con otras palabras?
• Método y capacidad de ejecución (peso alto): experiencia comprobable resolviendo problemas similares, con evidencia de resultado, no solo con logos de clientes.
• Propiedad y portabilidad del sistema (peso medio): qué tan atrapada queda la empresa con ese proveedor si la relación termina.
• Precio y estructura de costos (peso medio): no el número más bajo, sino el que mejor explica en qué se gasta cada parte.
• Riesgo y plan de soporte (peso medio): qué pasa si algo falla en producción y quién responde.

Las preguntas obligatorias que filtran al que solo vende herramientas

Hay un grupo de preguntas que deberían ser obligatorias en cualquier RFP de IA, porque separan al proveedor que construye una relación de trabajo real del que solo conecta una herramienta y cobra por eso. Si un proveedor evade estas preguntas o las responde en genérico, es información valiosa por sí sola.

• ¿De quién son los datos y los modelos entrenados o ajustados con ellos? La respuesta debe ser explícita, no “eso se ve en el contrato”.
• ¿Qué pasa si terminamos la relación? Exportabilidad de datos, documentación del sistema, tiempo de transición razonable.
• ¿Qué soporte existe después de la puesta en marcha, y con qué tiempo de respuesta ante una falla?
• ¿Quién del equipo propuesto seguirá disponible después del primer mes? Muchas propuestas lucen bien con el equipo senior en la venta, que después desaparece en la ejecución.
• ¿Qué evidencia tienen de un resultado de negocio movido en un caso comparable? No un caso de uso genérico, sino un número que cambió.

El RFP también debe fijar cronograma (fecha límite de preguntas, fecha límite de entrega, fecha estimada de decisión) y un único canal de contacto para preguntas, documentado por escrito. Esto evita que un proveedor obtenga información informal que otro no tuvo, lo cual vicia la comparación antes de empezar.

Cómo se ve en la práctica

Una distribuidora mediana de insumos industriales, alrededor de 90 personas, en Perú, sacó a licitación un proyecto de automatización de su proceso de cotizaciones con un RFP de una página y media: “buscamos soluciones de IA para mejorar nuestra atención al cliente”. Recibió doce propuestas en cuatro semanas. Cinco ofrecían chatbots, tres ofrecían plataformas de CRM con IA integrada, dos ofrecían consultoría sin especificar entregable, y dos ni siquiera mencionaban el proceso de cotizaciones que había originado el pedido.

El comité de compras pasó tres semanas más tratando de comparar precios que iban de 8 mil a 60 mil soles, sin poder explicar por qué la diferencia era tan grande, porque cada propuesta cotizaba cosas distintas bajo el mismo nombre. La decisión se estaba inclinando hacia el proveedor con el que el área comercial ya tenía una relación previa, no porque su propuesta fuera mejor, sino porque era la única que alguien en el comité entendía completa.

Se detuvo el proceso, se reescribió el RFP con el problema acotado (el cuello de botella específico en la generación de cotizaciones, con el tiempo promedio actual documentado), se exigió el formato común de respuesta y se publicaron los criterios con peso antes de reabrir la invitación, esta vez solo a cinco proveedores preseleccionados por experiencia comprobable en el sector.

Llegaron cuatro propuestas, las cuatro comparables línea por línea. La adjudicación tomó una reunión, no tres semanas, y quedó documentada con el criterio que la sostenía. El proveedor elegido no fue el más barato ni el de la relación previa: fue el que demostró en su propuesta que había entendido el cuello de botella real, con un enfoque que en los primeros dos meses de ejecución redujo el tiempo de respuesta de cotización de días a horas, medido contra el mismo indicador que se había documentado antes de licitar.

Mi criterio

Cómo saber si armaste bien el RFP

Antes de enviar el RFP a un solo proveedor, revisa si cumple estos cinco puntos. Si falla en dos o más, todavía no está listo para salir.

• El problema está descrito con evidencia, no con la palabra “IA” funcionando como si fuera el problema en sí.
• Existe un formato de respuesta obligatorio, no una invitación abierta a “su mejor propuesta”.
• Los criterios de evaluación y sus pesos están publicados en el mismo documento, antes de recibir propuestas.
• Las preguntas sobre datos, propiedad y soporte están explícitas, no delegadas a “se conversa en la reunión”.
• El cronograma y el canal de contacto son iguales para todos los proveedores invitados, sin excepciones informales.

Un RFP que cumple esto no garantiza la mejor decisión, pero elimina buena parte del ruido que hace que la decisión termine dependiendo de quién presentó mejor, en vez de quién resuelve mejor. Esa diferencia, en un proyecto de IA de tamaño mediano, suele valer más que cualquier descuento que un proveedor ofrezca al final de la negociación.