Pliego de condiciones de un proyecto de IA: la plantilla comentada para una pyme

Usted tiene un caso de uso en mente, un presupuesto aproximado y un proveedor que le pide «un pliego de condiciones». Tres semanas después el documento existe, ocupa doce páginas y nadie sabe decir qué se entregará ni cómo se comprobará que funciona. El proyecto arranca igualmente, sobre una interpretación. Ahí empiezan las desviaciones de alcance, los retrabajos facturados y las entregas que nadie se atreve a rechazar.

Un pliego de condiciones de un proyecto de IA no es un expediente técnico. Es un documento de decisión: fija el problema, el resultado esperado, las restricciones no negociables y la forma en que se constatará que el trabajo está hecho. Ocupa de dos a cinco páginas y se redacta antes de pedir un precio.

Key Takeaways

• Un pliego de IA describe un resultado y unos criterios de aceptación, no una solución técnica: la herramienta pertenece al proveedor, el problema pertenece a la empresa.
• Siete bloques bastan: contexto y objetivo de negocio, alcance incluido y excluido, datos, resultado esperado y aceptación, restricciones, costes y reversibilidad, gobernanza.
• El bloque que más se descuida es el de los datos. Según Gartner (2025), el 63 % de las organizaciones no dispone, o no sabe si dispone, de las prácticas adecuadas de gestión de datos para la IA.
• Los criterios de aceptación se escriben antes del presupuesto, en forma de casos de prueba con nombre. Sin ellos, la entrega se juzga por impresiones, y las impresiones se negocian.
• El documento se redacta dentro de la empresa, con el equipo que sufre el problema. Un proveedor puede cuestionarlo, no sustituirlo.

Un pliego fija un resultado, no una herramienta

La tentación más frecuente en una pyme es partir de la herramienta. «Queremos un agente de IA conectado a WhatsApp que clasifique las solicitudes». La frase describe una intención y un canal, no un resultado. Deja al proveedor la tarea de adivinar qué es una solicitud bien clasificada, a qué velocidad, con qué tasa de error aceptable y quién corrige cuando la clasificación falla.

Un proyecto de IA se juzga por tres elementos encadenados: la calidad de la salida, el tiempo ganado y el coste de funcionamiento. Si el pliego no dice nada sobre esos tres puntos, el proveedor entregará lo que sabe hacer, en el plazo que controla, y la conversación sobre el valor llegará demasiado tarde.

Esa imprecisión sale cara. En una nota publicada en julio de 2024, Gartner estimaba que al menos el 30 % de los proyectos de IA generativa se abandonarían tras la prueba de concepto antes de finales de 2025, por cuatro motivos: calidad de datos insuficiente, controles de riesgo inadecuados, costes que se disparan y valor de negocio difuso. Tres de esos cuatro motivos se resuelven en el documento que usted redacta antes de firmar.

La buena pregunta inicial no es por tanto «¿qué herramienta?» sino «¿qué decisión se vuelve más rápida, o qué trabajo desaparece?». La respuesta cabe en una frase, y esa frase se convierte en la primera línea del pliego. Si no consigue escribirla, el encuadre no ha terminado: es exactamente el trabajo que cubre una auditoría de encuadre.

Los siete bloques de la plantilla, comentados

El esqueleto siguiente sirve para un agente conversacional, una automatización de back office, una herramienta de clasificación de documentos o un modelo de previsión. Lo que cambia de un proyecto a otro es el contenido, nunca la estructura.

1. Contexto y objetivo de negocio. Describa dónde aparece el problema, con qué frecuencia y quién lo sufre. Mida la situación actual con sus propias cifras: solicitudes por semana, tiempo medio de tratamiento, tasa de error observada. Este bloque es la base de comparación para la aceptación. Sin medida de partida, ninguna ganancia será demostrable y el debate se trasladará a las impresiones.

2. Alcance: lo incluido y lo excluido. La columna «excluido» es la más importante, y siempre es la que se olvida. Un proyecto de IA se desborda por naturaleza: en cuanto el agente clasifica los correos, alguien pide que responda, luego que haga seguimiento, luego que actualice el CRM. Escriba sin ambigüedad los usos, los canales y los idiomas que quedan fuera del campo. Un alcance excluido explícito vale más que una lista generosa de inclusiones.

3. Datos y accesos. Qué datos leerá el sistema, dónde están, en qué formato, quién autoriza el acceso y durante cuánto tiempo se conservan. Precise la calidad esperada: campos obligatorios, duplicados tolerados, documentos escaneados aceptados o no. Añada la cuestión de la anonimización cuando entren datos personales en el dispositivo.

4. Resultado esperado y criterios de aceptación. Describa lo que ve el usuario al final: un borrador de respuesta en el buzón, una línea añadida a la hoja de cálculo, un resumen de reunión. Después enumere los casos de prueba, nombrando cada uno: solicitud simple, solicitud en otro idioma, solicitud fuera de tema, adjunto ilegible, cliente duplicado. Cada caso recibe un resultado esperado verificable. Es el bloque que convierte un proyecto en compromiso.

5. Restricciones. Técnicas (sistemas existentes que no deben sustituirse, alojamiento en Europa, picos de carga), normativas (RGPD, secreto profesional, conservación de los intercambios) y humanas (quién valida cada salida antes del envío, quién usa la herramienta a diario, quién forma a las nuevas incorporaciones). Las restricciones humanas son las que hacen fracasar los proyectos mejor encuadrados técnicamente.

6. Costes, propiedad y reversibilidad. Separe el coste de construcción de los costes recurrentes: licencias, consumo de modelos, alojamiento, mantenimiento, correcciones. Precise a quién pertenecen las entregas, los prompts y los conjuntos de prueba. Por último, escriba la salida: cómo se recuperan los datos y la configuración si se cambia de proveedor o se detiene el proyecto. Un proyecto de IA sin cláusula de salida se convierte en una dependencia.

7. Gobernanza y aceptación. Nombre a un único decisor del lado de la empresa, a la persona que arbitra en caso de desacuerdo y el calendario de aceptación. Prevea el procedimiento ante desviaciones: otra ronda de corrección, reducción de alcance o parada. Un proyecto sin procedimiento de parada tampoco tiene procedimiento de éxito.

Si el proyecto produce un agente de IA, añada un bloque breve sobre el tono y los límites de respuesta: lo que el agente nunca debe decir y a quién pasa la mano.

Cinco formulaciones que reescribir antes del envío

Un pliego se relee buscando las frases que un proveedor podría interpretar de dos maneras. Aquí van cinco, con su versión utilizable.

Las cifras de esa tabla son ejemplos de redacción, que deben sustituirse por sus compromisos reales. Lo que importa no es su valor exacto, sino su forma: un umbral, un caso, un plazo, un responsable.

Los datos: el bloque que decide lo que sigue

El mismo estudio de Gartner citado antes pone cifra al riesgo: siempre según Gartner (2025), las organizaciones abandonarían el 60 % de los proyectos de IA no respaldados por datos preparados para la IA de aquí a 2026. Dicho de otro modo, el modelo casi nunca es el punto de ruptura. El punto de ruptura es lo que se le da a leer.

En una pyme, eso se traduce en tres comprobaciones concretas. Primero, la disponibilidad: ¿los datos existen en forma explotable o hay que sacarlos antes de un PDF de un sistema sectorial? Después, la regularidad: ¿todos los equipos rellenan los campos de la misma manera? Por último, la propiedad: ¿quién tiene derecho a hacer circular esos datos hacia una herramienta externa y en qué condiciones?

La falta de experiencia interna complica el ejercicio. En 2025, el 18 % de las empresas francesas de 10 asalariados o más declaran utilizar al menos una tecnología de IA y, entre las que no utilizan ninguna, el 54 % cita una falta de experiencia, según el Insee (2026). No es una confesión de retraso, es una información que debe integrarse en el documento: prevea quién podrá revisar las salidas del sistema dentro de seis meses y qué hará si esa persona se marcha.

Un pliego honesto menciona también lo que la empresa todavía no sabe. Una frase del tipo «la calidad de los datos históricos no se ha auditado» vale más que una afirmación tranquilizadora que el proveedor tomará al pie de la letra. Esa transparencia aparece en el precio.

Costes, propiedad y condiciones de salida

El presupuesto de un proyecto de IA se lee a doce meses, no en la factura inicial. Tres partidas se repiten: la construcción, el uso (consumo de modelos, licencias, alojamiento) y el mantenimiento. Pida al proveedor que separe las tres y que precise lo que varía con el volumen. Un precio cerrado construido sobre 500 solicitudes al mes no aguanta si usted trata 3.000.

La propiedad merece una cláusula explícita. Los prompts, los conjuntos de prueba, la documentación y los scripts de integración deben figurar como entregables. Sin esa lista, un cambio de proveedor se traduce en una reconstrucción completa, a menudo a precio alto. La cláusula de salida es la contrapartida: formato de los datos exportados, plazo de entrega, supresión de las copias que guarda el proveedor.

Este trabajo de redacción se cruza con el del presupuesto, y a menudo ambos documentos se responden. Para comprobar que las dos versiones cuentan lo mismo, lo que debe contener un presupuesto de agente de IA ofrece una rejilla de lectura útil.

Quién lo escribe y en cuánto tiempo

El pliego se escribe del lado de la empresa, por el dirigente o el responsable de negocio afectado, con las personas que viven el problema a diario. Un consultor puede dinamizar el ejercicio, plantear las preguntas y reformular, pero no puede inventar sus restricciones. Cuando el documento llega completamente redactado por el proveedor, la empresa compra una solución sin haber definido su necesidad.

Cuente de dos a cinco días de trabajo repartidos en dos semanas, la mayor parte en entrevistas cortas: una hora con el equipo que sufre el problema, una hora con la persona que posee los datos, una hora con quien pagará la factura y por tanto debe arbitrar. El documento final ocupa de dos a cinco páginas. Por encima de ocho páginas describe la arquitectura en lugar del proveedor y se convierte en un documento de negociación.

El buen momento para escribirlo es antes de la consulta, no después. Un documento redactado tras el presupuesto sirve para justificar una decisión ya tomada. Para situar este trabajo en la secuencia completa, las seis etapas de un proyecto de IA muestra dónde se coloca el encuadre y por qué condiciona lo que viene después.

Preguntas frecuentes

¿Cuántas páginas debe tener un pliego de proyecto de IA?

De dos a cinco páginas para un proyecto de pyme, sin contar los anexos técnicos. El anexo puede contener los esquemas de datos, la lista de casos de prueba y ejemplos de documentos. El cuerpo debe seguir siendo legible por un dirigente en veinte minutos; de lo contrario no se releerá en el momento de los arbitrajes.

¿Hay que nombrar la herramienta, por ejemplo ChatGPT o n8n?

Nombre una herramienta solo si es una restricción real: un sistema ya implantado, un acuerdo marco, una obligación de alojamiento. Si no, describa la función esperada y las restricciones, y deje que el proveedor proponga. Esa libertad es lo que permite comparar dos ofertas por el resultado y no por una marca.

Mi proveedor afirma que redactar el pliego forma parte de su misión. ¿Quién tiene razón?

Los dos, siempre que se separen los papeles. El proveedor es legítimo para la especificación técnica, la arquitectura y el plan de pruebas. La empresa sigue siendo propietaria del objetivo, del alcance, de los criterios de aceptación y del presupuesto. Un proveedor que se niega a discutir esos cuatro puntos antes de presupuestar toma el control del proyecto.

¿Un pliego garantiza que el proyecto salga bien?

No. Reduce las desviaciones de interpretación, hace oponible la aceptación y obliga a formular los casos límite antes de pagar. No sustituye ni la calidad de los datos, ni la disponibilidad de los equipos, ni la decisión de parar un proyecto que no cumple sus criterios. Es un instrumento de pilotaje, no un seguro.

¿Qué hacer si ningún proveedor responde punto por punto al documento?

Considere el silencio como una información. O el alcance sigue siendo demasiado vago para presupuestarlo, o el proveedor no desea comprometerse con criterios medibles. En ambos casos, enviar el documento a un tercer proveedor cuesta menos que firmar una respuesta parcial. Si quiere automatizar tareas repetitivas sin un proyecto de IA completo, el encuadre es el mismo, con un alcance más corto.

Conclusión

Un pliego de condiciones de un proyecto de IA sirve para tres cosas: decidir lo que se quiere, hacer verificable la entrega y conservar el control de la salida. Los siete bloques de la plantilla caben en dos páginas, y la mayoría de las desviaciones observadas provienen de bloques vacíos, no de elecciones técnicas discutibles.

Si está preparando un proyecto y el documento aún no existe, empiece por la frase de objetivo y por sus propias medidas de partida. Si el documento existe pero le parece difuso, hágalo revisar antes del envío: escríbanos basta para obtener una opinión sobre lo que falta.