Plantilla de alcance para un MVP de IA: criterios de aceptación, set de evaluación, puerta de lanzamiento y qué va en el SoW

Definir el alcance de un MVP de IA es distinto de definir un flujo completamente determinista porque las salidas del modelo pueden variar con la versión, los ajustes de muestreo, el contexto y la formulación. "El usuario puede restablecer la contraseña" quizá permita una prueba exacta de aprobado o fallo; "el asistente responde correctamente" necesita una distribución de tareas y una regla de puntuación definidas. Por eso nuestro statement of work recomendado nombra cuatro cosas: un set de evaluación versionado con etiquetas de referencia o rúbricas, una métrica objetivo con su umbral, una puerta de lanzamiento y el manejo explícito del caso incierto más un rollback. Más abajo hay una plantilla lista para copiar.

Este es un punto de partida para compras, no asesoramiento jurídico ni un estándar universal de calidad. Volvimos a comprobar las fechas regulatorias y la guía de evaluación el 2 de septiembre de 2026.

¿Quieres poner a prueba este alcance antes de firmar con una agencia?

Reserva una consulta gratuita

Por qué "funciona" no funciona para la IA

El software convencional también usa pruebas estadísticas, de rendimiento y basadas en propiedades, por lo que la aceptación no siempre es binaria. El problema distintivo aquí es que las respuestas generadas pueden tener varias formas aceptables y variar entre ejecuciones. Mide un set definido, repite los casos donde importe la varianza y registra el modelo y la configuración exactos. Una temperatura de cero puede reducir la varianza de muestreo, pero no garantiza una salida idéntica en un modelo alojado. Ejecuta evaluaciones de regresión ante cambios materiales de prompt, retrieval, modelo, política o herramientas, con una frecuencia proporcional al riesgo. Esto sigue la recomendación de NIST de documentar sets de prueba, métricas, condiciones similares al despliegue, incertidumbre y monitorización continua en su guía Measure del AI RMF.

Qué debe fijar el statement of work de un MVP de IA

Cada sección se gana su lugar. Las que sostienen todo son el set de evaluación, los criterios de aceptación y la puerta de lanzamiento.

Sección	Qué debe fijar
Problema + un resultado	Una frase. El único trabajo del usuario que el MVP debe hacer. Todo lo que no lo sirva queda fuera de alcance.
Dentro y fuera de alcance	Dos listas. La lista de lo que queda fuera de alcance es la que sostiene todo: nombra las cosas tentadoras que no vas a construir (multiidioma, voz, fine-tuning, móvil) para que se conviertan en change requests, no en supuestos.
Especificación funcional + de comportamiento de la IA	Requisitos normales más el comportamiento de la IA: tarea, tono, comportamiento de rechazo (cuándo debe decir "No lo sé"), requisito de citas y fallback ante baja confianza o ausencia de acierto en el retrieval. Aquí codificas el caso incierto.
Criterios de aceptación	Métrica objetivo más umbral sobre un set de evaluación nombrado. Nunca "funciona". Ejemplos más abajo.
El set de evaluación	Cómo se muestrean los casos del uso previsto y previsible, cómo se justifica el tamaño de la muestra, quién posee las etiquetas de referencia o rúbricas y cómo se puntúan los casos. Usa comprobaciones deterministas donde sea posible; calibra los evaluadores de modelo con revisión humana y documenta los desacuerdos.
Puerta de lanzamiento + rollback	La vara medible para salir a producción, acordada antes del lanzamiento por responsables de producto, ingeniería, riesgo y calidad, más monitorización, disparador de rollback y criterio de kill.
Datos	Fuentes, procedencia, derechos de uso, tratamiento de datos personales, transferencias, retención y requisitos de residencia. Determina con la guía del EDPB sobre roles si cada proveedor es responsable, encargado o subencargado y establece el contrato y las instrucciones requeridos. No entrenar y la retención son controles específicos del producto, no lenguaje universal del GDPR.
No funcionales	Latencia percibida por el usuario y de extremo a extremo, time-to-first-token donde importe el streaming, coste por tarea completada, concurrencia, disponibilidad y telemetría respetuosa con la privacidad. Comprueba los precios actuales de entrada, salida, caché, herramientas y medios del proveedor elegido, en vez de asumir una proporción fija.
Seguridad y cumplimiento	Autenticación, autorización, aislamiento por inquilino, modelo de amenazas, respuesta a incidentes, deberes aplicables del GDPR y clasificación y transparencia específicas del sistema conforme al EU AI Act.
Hitos, pago, IP, traspaso	Fases de discovery, construcción, evaluación, endurecimiento y lanzamiento, con condiciones comerciales, disposiciones sobre IP, tratamiento de licencias de terceros y artefactos de traspaso nombrados en el contrato.

Criterios de aceptación: mal frente a bien

Esta es la sección que decide si puedes exigirle algo a un proveedor.

Mal, porque no hay número, ni set, ni mínimo: "el chatbot responde correctamente a las preguntas de los clientes", "el asistente es preciso y útil", "el modelo rara vez alucina", "funciona bien en las pruebas".

Mejor estructurado, con marcadores ilustrativos que deben sustituirse por umbrales basados en evidencia para el riesgo y la carga reales:

objetivo de fidelidad [umbral], anclado en el contexto recuperado, puntuado con una rúbrica y calibrado con etiquetas humanas;
objetivo de relevancia de la respuesta [umbral];
fallos críticos de seguridad [cero o un límite de riesgo aprobado explícitamente], con categorías bloqueantes nombradas;
rechazo o escalado en casos no respondibles [umbral];
presupuestos p95 de time-to-first-token y respuesta completa [donde importe cada uno];
coste por tarea completada [presupuesto] con el modelo y flujo acordados;
sin regresión por debajo de ningún mínimo en la ejecución de evaluación antes de un deploy.

Estos campos son ejemplos, no referencias universales del sector. No existe un tamaño universal defendible para el set, ni un umbral universal de fidelidad, salidas dañinas, latencia o coste. Deriva cada valor de la frecuencia de uso, gravedad de las consecuencias, cobertura de subgrupos, intervalos de confianza y fallback disponible cuando falle el sistema. El perfil de IA generativa de NIST es una guía voluntaria, pero ofrece un marco útil basado en el riesgo. Los métodos de puntuación están en cuándo merece la pena construir evaluaciones de LLM.

La plantilla de alcance lista para copiar

Pégala, rellena los corchetes, borra lo que no aplique. Hazla circular antes de aceptar una sola propuesta.

Alcance / SoW de MVP de IA, [Nombre del proyecto]
Fecha [fecha] · Versión [v0.1] · Responsable [nombre]

1. Problema + un resultado. Problema: [una frase]. El único resultado que este MVP debe entregar: [usuario] puede [hacer X] para que [Y].

2. Alcance. Dentro de alcance: [funcionalidad 1], [funcionalidad 2]. Fuera de alcance, solo por change request: [multiidioma], [voz], [fine-tuning], [móvil].

3. Funcional + comportamiento de la IA. Funcional: [lista]. Comportamiento de la IA: tarea [exactamente qué], tono [conciso, sin especulación], citas [debe o no debe anclarse en fuentes], rechazo [cuando esté fuera de alcance o con baja confianza, decir "No lo sé" o escalar], fallback [modelo secundario, respuesta en caché o traspaso a un humano].

4. Criterios de aceptación. Sobre el set [nombre/versión]: [métrica] >= [umbral con justificación e incertidumbre]; fallos críticos de seguridad [cero o límite de riesgo definido]; rechazo o escalado correcto >= [umbral] en casos no respondibles; p95 [medida de latencia] < [presupuesto]; coste por tarea completada < [presupuesto]; sin regresión material por debajo de ningún mínimo acordado antes del deploy.

5. Set de evaluación. Tamaño [N, con justificación del muestreo] entre casos de [camino feliz], [borde], [no respondibles], [adversarios] y subgrupos relevantes. Responsable de referencias: [experto del dominio del cliente]. Puntuación: comprobaciones deterministas para [campos objetivos], evaluador de modelo con rúbrica para [calidad] y revisión humana ciega para calibración y casos disputados. Almacenado y versionado en [ubicación].

6. Puerta de lanzamiento + rollback. Salida a producción cuando se cumplan todos los mínimos de la Sección 4, con visto bueno de [producto] + [ingeniería] + [QA]. Rollback: si [métrica] cae por debajo de [mínimo] durante una [ventana], revertir automáticamente. Criterio de kill: no desplegar si [fidelidad < X% o cualquier salida dañina].

7. Datos. Fuentes [lista], procedencia y derechos [por fuente], datos personales [qué, finalidad, base legal, retención], transferencias y residencia [requisitos]. Rol del proveedor [responsable/encargado/subencargado], condiciones del artículo 28 donde correspondan, uso para entrenamiento [condiciones], retención [condiciones/ajustes].

8. No funcionales. Presupuestos de latencia, disponibilidad, concurrencia y coste como en la Sección 4. Observabilidad: registrar solo los metadatos mínimos necesarios para calidad, seguridad y coste; redactar o evitar prompts y respuestas sin procesar salvo justificación; definir acceso y retención; alertar en [umbral].

9. Seguridad + cumplimiento. Autenticación [método], permisos y aislamiento por inquilino [modelo], modelo de amenazas y respuesta a incidentes, deberes del GDPR [roles, registro cuando sea exigible, base legal, DPIA cuando sea probable un alto riesgo, condiciones de encargado] y rol, clasificación, deber del artículo 50 y plazo aplicables del EU AI Act.

10. Hitos + pago. Discovery, construcción, evaluación y endurecimiento, lanzamiento, pago por fase. Propiedad, cesión o licencia de IP, componentes de terceros y fecha efectiva: [condiciones contractuales]. Traspaso: set de evaluación y resultados, registro de prompts y modelos, diagrama de arquitectura y de flujo de datos, runbook, acceso a logs, credenciales. Visto bueno: cliente [__] proveedor [__] fecha [__].

"Si el alcance no puede decirte, en números, cómo se ve lo bastante bueno y qué pasa cuando el modelo se equivoca, no es un alcance. Es un deseo. El set de evaluación y la puerta de lanzamiento son las dos líneas que convierten una demo de IA en algo que de verdad puedes comprar."

Una nota sobre el AI Act

El artículo 50 no impone una obligación general a toda aplicación que contenga IA. Los proveedores de sistemas destinados a interactuar directamente con personas deben informar, en general, de que se interactúa con IA, salvo que sea evidente para una persona razonablemente informada, observadora y prudente, con las excepciones previstas. Otras obligaciones del artículo 50 abarcan el marcado de contenido sintético y determinadas divulgaciones de los responsables del despliegue. La mayoría de las obligaciones aplicables comenzaron el 2 de agosto de 2026; hay una transición hasta el 2 de diciembre de 2026 para proveedores del artículo 50.2 cuyos sistemas de contenido sintético ya estaban en el mercado. Tras el Reglamento (UE) 2026/1744, las reglas de alto riesgo del anexo III se aplican desde el 2 de diciembre de 2027 y las de alto riesgo integradas en productos del anexo I desde el 2 de agosto de 2028. Comprueba el texto consolidado del AI Act y tu rol, en vez de aplicar una fecha a todo sistema.

Preguntas frecuentes

¿Cómo se escriben los criterios de aceptación para una funcionalidad de IA?

No como "funciona." Define una métrica objetivo y un umbral justificado sobre un set nombrado y versionado, además de categorías de seguridad bloqueantes, comportamiento de rechazo o escalado, presupuestos de latencia y coste y una regla de regresión. Repite ejecuciones donde importe la varianza y documenta la incertidumbre, en vez de copiar cifras universales.

¿Qué es un set de evaluación?

Una muestra versionada y con responsable de casos previstos, de borde, no respondibles, adversarios y de subgrupos relevantes, con etiquetas de referencia o rúbricas. No existe un tamaño mínimo universal. Justifica cobertura e incertidumbre para la decisión y el riesgo, y amplía el set con fallos de producción.

¿Quién debería ser dueño del set de evaluación?

Un experto del dominio de tu lado, no solo el proveedor. La persona que sabe cómo se ve una respuesta correcta debe definir las respuestas de referencia, o estarás dejando que quien construye corrija sus propios deberes.

¿Cómo se puntúan los casos de evaluación?

Combina comprobaciones deterministas para campos objetivos como fechas, IDs y forma del JSON con evaluación del modelo basada en rúbricas y revisión humana donde haga falta criterio. Calibra los evaluadores con etiquetas humanas ciegas, registra desacuerdos y deriva a personas los casos disputados o de consecuencias importantes.

¿Qué es una puerta de lanzamiento para una app de LLM?

La vara medible que decide la salida a producción: los umbrales y condiciones bloqueantes que el sistema debe cumplir sobre el set acordado, con aprobación de responsables de producto, ingeniería, riesgo y calidad. También define monitorización, un disparador de rollback y un criterio de kill.

¿Qué va en un statement of work de IA?

Problema y un resultado, dentro y fuera de alcance, requisitos funcionales más una especificación de comportamiento de la IA (tono, rechazo, citas, fallback), criterios de aceptación como métrica más umbral sobre un set de evaluación, el set de evaluación en sí, la puerta de lanzamiento y el rollback, derechos de datos y PII y residencia, no funcionales (latencia, coste por acción, registro), seguridad y cumplimiento, e hitos, pago, IP y artefactos de traspaso.

¿Por qué no puedo escribir simplemente "la IA responde correctamente" en el alcance?

Porque las respuestas generadas pueden tener varias formas aceptables y variar entre ejecuciones o versiones del modelo. Necesitas un set definido, una regla de puntuación y un mínimo, o no hay nada objetivo que aprobar ni nada que disputar cuando la calidad es mala.

¿Cómo manejo el caso en que la IA se equivoca o no está segura?

Especifica una ruta de rechazo, escalado o fallback y pruébala con casos no respondibles y ambiguos. Fija el umbral según la gravedad de las consecuencias y la revisión humana disponible, en vez de copiar un porcentaje universal.

¿Qué cláusulas de datos necesita el SoW de un MVP de IA?

Documenta procedencia y derechos de uso, finalidades y base legal de los datos personales, retención, transferencias y residencia, roles del proveedor, condiciones de encargado donde correspondan, uso para entrenamiento, controles de seguridad, borrado y derechos de auditoría. Un proveedor de modelos puede ser encargado o subencargado según la cadena contractual.

¿Afecta el EU AI Act al alcance de mi MVP de IA?

Puede afectarlo, según el sistema, el rol y el caso de uso. Las obligaciones aplicables del artículo 50 comenzaron en general el 2 de agosto de 2026, las reglas de alto riesgo del anexo III se aplican desde el 2 de diciembre de 2027 y las integradas en productos del anexo I desde el 2 de agosto de 2028. Clasifica el sistema y comprueba la ley consolidada.

Reflexiones finales

El alcance de un MVP de IA depende de un set de evaluación y una puerta de lanzamiento defendibles. Juntos convierten un vago "constrúyennos un asistente" en evidencia y condiciones contractuales que un comprador puede evaluar.

Antes de aceptar una propuesta, escribe el resultado, traza la línea de lo que queda fuera de alcance, define métricas y mínimos justificados sobre un set gobernado por tus expertos, decide qué pasa cuando el modelo no está seguro y nombra la vara de lanzamiento. Rellena primero la plantilla para comparar propuestas con los mismos requisitos.

¿Quieres tener el set de evaluación y la puerta de lanzamiento integrados en el alcance de tu MVP?