RFP para contratar un proyecto de IA: plantilla y criterios de evaluación

Una solicitud de propuesta —RFP, por sus siglas en inglés— no mejora por acumular requisitos técnicos. Mejora cuando obliga a todos los proveedores a responder sobre el mismo problema, con la misma evidencia y bajo las mismas condiciones de aceptación.

Esta plantilla ayuda a convertir una intención amplia en un pliego evaluable. El resultado debe ser una RFP que permita comparar alcance, método, datos, seguridad, equipo, coste total y capacidad de salida, sin elegir por la demo más vistosa.

Antes de redactar: decide qué estás contratando

Una RFP para IA puede solicitar una fase de diagnóstico, un piloto, una implantación o un servicio operado. Mezclarlos conduce a propuestas incomparables: un proveedor cotiza descubrimiento, otro una demo y un tercero una plataforma anual.

Si todavía no existe línea base, propietario operativo o acceso viable a los datos, recomendamos contratar primero el diagnóstico. La checklist para evaluar un proyecto de IA permite detectar esos bloqueos antes de pedir ofertas.

Plantilla de RFP en ocho apartados

Utiliza estos apartados como estructura editable. Elimina lo que no aplique y añade los requisitos sectoriales, legales o técnicos del caso. Una plantilla no sustituye la revisión de compras, seguridad, privacidad y asesoría jurídica.

1. Contexto, problema y línea base. Describe el proceso actual, los usuarios, el volumen, las excepciones y la métrica de partida. Incluye qué ha impedido resolverlo hasta ahora. Evita abrir con «queremos implantar IA»; los proveedores deben poder proponer automatización convencional si resulta más adecuada.
2. Resultado, alcance y exclusiones. Define la mejora que se busca, la población o flujo incluido, los sistemas afectados y lo que queda expresamente fuera. Separa lectura, recomendación y ejecución de acciones. Indica qué errores serían inaceptables y qué condiciones obligarían a detener el trabajo.
3. Datos, conocimiento e integraciones. Enumera fuentes, propietarios, sensibilidad, calidad conocida, permisos y restricciones de uso. Aclara qué datos aporta cada parte, dónde se procesan, si pueden utilizarse para entrenamiento y cómo se eliminarán o devolverán al terminar.
4. Método de trabajo y evaluación. Exige una propuesta de fases, hipótesis, conjunto de pruebas, métricas y umbrales. La evaluación debe incluir casos normales, difíciles, excepciones y situaciones que el sistema debe rechazar o escalar. Reserva una muestra para la aceptación final.
5. Seguridad, privacidad y gobierno. Pide arquitectura, identidades, permisos mínimos, registros, aislamiento, gestión de secretos, pruebas adversariales, respuesta a incidentes y reparto de obligaciones. Solicita que el proveedor clasifique supuestos regulatorios y declare qué información necesita para validarlos.
6. Equipo, transferencia y adopción. Solicita nombres o perfiles del equipo real, dedicación, responsabilidades y sustituciones previstas. Incluye participación de usuarios, formación, documentación técnica y operativa, transferencia de conocimiento y capacidad del comprador para continuar sin dependencia innecesaria.
7. Operación, cambios y niveles de servicio. Define monitorización, soporte, mantenimiento, actualización de modelos o fuentes, regresiones, gestión de costes y procedimiento para cambios sustanciales. El proveedor debe explicar qué ocurre si cambia un modelo, una API, un precio, una región o una condición de servicio de un tercero.
8. Precio, propiedad y salida. Exige un desglose comparable de construcción y operación, junto con supuestos de volumen. Aclara derechos sobre código, configuraciones, prompts, evaluaciones, datos, documentación y mejoras. Incluye exportación, borrado, transición, reversibilidad y ayuda a un proveedor sustituto.

Qué debe responder cada proveedor

No pidas una narración libre. Entrega un formato común y limita las respuestas que no aportan evidencia. Para cada requisito solicita:

La guía para seleccionar un proveedor de IA amplía las preguntas de diligencia debida. La RFP convierte esas preguntas en una obligación de respuesta comparable.

La prueba común evita comparar promesas

Cuando el riesgo y el esfuerzo lo permitan, proporciona a los finalistas una muestra representativa bajo las mismas reglas. Puede ser una prueba remunerada, un taller técnico o una evaluación sobre datos sintéticos que conserven las dificultades del proceso.

La prueba debe medir el sistema completo, no solo el modelo. Registra calidad por tipo de caso, tiempo de revisión humana, fallos de integración, comportamiento ante instrucciones maliciosas, trazabilidad y coste por unidad. No reutilices la muestra como conjunto de ajuste y aceptación a la vez.

Una prueba no debe transferir trabajo productivo gratuito al proveedor ni exponer información innecesaria. Si la muestra contiene datos personales, secretos empresariales o información regulada, aplica las mismas restricciones que tendría una fase real.

Matriz de evaluación recomendada

Adapta los pesos antes de recibir ofertas. Cambiarlos después de ver los proveedores convierte la matriz en una justificación retrospectiva.

La puntuación no compensa condiciones no negociables. Incumplir una restricción de datos, no aceptar una prueba de seguridad o impedir la salida puede excluir una oferta aunque su nota total sea alta.

Cláusulas que no deben quedarse fuera del contrato

Las cláusulas contractuales tipo de IA de la comunidad europea de compradores públicos ofrecen una versión para alto riesgo y otra ligera. Su comentario advierte que no forman un contrato completo: deben complementarse, entre otras materias, con propiedad intelectual, aceptación, pagos, plazos, responsabilidad y legislación aplicable.

• Finalidad prevista, usos permitidos y usos prohibidos.
• Responsabilidad sobre datos, modelos, componentes y terceros.
• Documentación, instrucciones, registros y derecho de auditoría.
• Cambios que requieren aviso, reevaluación o aprobación.
• Umbrales de servicio, calidad, seguridad y coste.
• Incidentes, plazos de notificación, contención y cooperación.
• Derechos de uso, exportación, borrado y transición al terminar.
• Cooperación para explicar resultados y atender reclamaciones cuando corresponda.

Para sistemas de alto riesgo, el Reglamento europeo exige requisitos específicos sobre gestión de riesgos, datos, documentación, registros, transparencia, supervisión humana, precisión, robustez y ciberseguridad. El calendario vigente tras el AI Omnibus sitúa la aplicación de las reglas de alto riesgo del anexo III el 2 de diciembre de 2027 y las asociadas a determinados productos del anexo I el 2 de agosto de 2028, según la Comisión Europea. La clasificación y el papel de cada parte deben revisarse para el caso concreto; no se resuelven copiando una cláusula genérica.

Señales para no adjudicar todavía

No recomendamos adjudicar cuando el comprador no puede describir el resultado, no dispone de acceso legítimo a los datos necesarios o pretende cerrar el precio de producción antes de validar la incertidumbre principal. Tampoco cuando ningún equipo interno puede aceptar el resultado y operar el sistema.

En esas situaciones, divide la contratación. Encarga primero diagnóstico o preparación, conserva los artefactos y abre la siguiente fase solo cuando exista evidencia suficiente. Un contrato más pequeño puede evitar una dependencia mucho mayor.

Preguntas frecuentes