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 un MVP de software normal porque el sistema es probabilístico, no determinista. "El usuario puede restablecer la contraseña" es un binario que puedes escribir como prueba de aprobado o fallo. "El asistente responde correctamente" no lo es, porque la misma pregunta puede dar respuestas distintas cuando cambian la versión del modelo, la temperatura o la formulación. Así que reemplazas "funciona" por cuatro cosas que deben quedar nombradas en el statement of work antes de que cambie de manos el dinero: un set de evaluación versionado con respuestas de referencia, una métrica objetivo con su umbral sobre ese set, una puerta de lanzamiento que decide la salida a producción, y el manejo explícito del caso incierto más un rollback. Si el alcance de un proveedor dice "construir un asistente de IA" sin nada de eso, ha definido el alcance de una demo, y pagarás esa brecha durante el endurecimiento. Más abajo hay una plantilla lista para copiar.

Este es el documento que los fundadores hacen circular internamente antes de comprar. Está escrito desde el lado de quien construye, con las preguntas incómodas hechas explícitas. Las fechas regulatorias son vigentes a mediados de 2026 y van con sus reservas donde están en movimiento.

Por qué "funciona" no funciona para la IA

En el software normal, la aceptación es binaria: dada la entrada X, comprueba la salida Y, listo. Un LLM da una salida distinta para la misma entrada entre una ejecución y otra, así que "el chatbot responde con precisión" no tiene ninguna prueba detrás. No hay número, ni set definido, ni mínimo, nada que aprobar y nada que disputar cuando la calidad es mala. La solución es estadística, no binaria. Aceptas una tasa medida sobre un set definido, idealmente promediada entre varias ejecuciones, y para comprobaciones de regresión reproducibles fijas la temperatura en cero donde el caso de uso lo permita. La segunda trampa llega de inmediato: un arreglo para un caso rompe en silencio otro, así que el set de evaluación tiene que ejecutarse como puerta en cada cambio de prompt o de modelo, no una sola vez al final. Ese único giro, de "funciona" a "supera esta vara sobre este set, siempre", es todo el sentido de definir bien el alcance de una construcción de IA.

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.

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".

Bien, sobre el set de evaluación de 100 casos acordado con respuestas de referencia fijas:

• al menos 90% de respuestas fieles, ancladas en el contexto recuperado, puntuadas por un LLM-as-judge con aprobado o fallo binario y calibradas contra etiquetas humanas;
• al menos 85% de relevancia de la respuesta;
• menos del 2% de salidas dañinas o que violan políticas, como puerta dura en la que una sola salida dañina bloquea el lanzamiento;
• rechaza o escala en al menos el 95% de los casos de prueba no respondibles;
• p95 time-to-first-token por debajo de 2 segundos, p95 de la respuesta completa por debajo de 4 segundos;
• coste por debajo de EUR 0,05 por conversación con el modelo acordado;
• sin regresión por debajo de ningún mínimo en la ejecución de evaluación antes de un deploy.

Trata los umbrales exactos como puntos de partida para negociar según tu riesgo, no como dogma. Los proveedores suelen citar fidelidad igual o superior a 0,75 y alucinación por debajo del 5% (1% para casos de alto riesgo) como puntos de partida de producción; fija los tuyos según cuánto te cuesta una respuesta equivocada. El set de evaluación que defines aquí es la misma evidencia que pedirá la diligencia técnica de un inversor, lo cual cubrimos en la lista de comprobación de diligencia técnica para MVPs de IA, y 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.

"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

Si tu aplicación interactúa con usuarios, los deberes de transparencia del Artículo 50 del EU AI Act, incluido decir a los usuarios que están tratando con IA, aplican desde el 2 de agosto de 2026 y apenas se ven afectados por los cambios propuestos. La mayoría de las obligaciones de alto riesgo también vencían entonces. Un acuerdo provisional en 2026 empujaría los deberes independientes de alto riesgo a finales de 2027, pero a mediados de 2026 eso todavía no es ley y solo entra en vigor con la adopción formal. No definas tu plan de cumplimiento en torno a un retraso que no se ha promulgado.