Cómo definir el scope de un proyecto de IA antes de contratar a una agencia

Cada semana, un equipo directivo envía un RFP para "una solución de IA" y recibe cinco propuestas que parecen idénticas y se comportan de forma completamente distinta. El problema no son las agencias. El problema es el scope. Si define bien el scope, el resto es procurement. Si no, está comprando billetes de lotería.

Este artículo es la checklist que aplicamos con clientes antes de que se tomen en serio una sola propuesta.

Por qué el scope mata más proyectos de IA que la tecnología

La mayoría de los proyectos de IA fallidos no fracasan porque el modelo no funcionara. Fracasan porque el proyecto entregó algo que nadie podía usar o que en realidad no movía ninguna métrica que le importara a alguien. La tecnología estaba bien. El scope estaba mal.

Un scope equivocado se manifiesta como:

• Un prototipo sin responsable de negocio.
• Un workflow que nadie integra en la operativa diaria.
• Una métrica que "mejora" pero no cambia ninguna decisión.
• Un modelo preciso con datos de test e inútil un martes por la mañana.

La solución no es un modelo mejor. Es una pregunta mejor.

El brief de scope mínimo

Antes de entregar nada a una agencia, un freelancer, un FDE o un proveedor, debería poder responder a esto en una página.

1. ¿Quién es el dueño del resultado?

Nombre a una persona. No a un equipo. No a un comité de dirección. Una sola persona cuyo número cambia si esto funciona.

Si no puede nombrar a nadie, pare. No está definiendo el scope de un proyecto — está financiando un hobby.

2. ¿Qué métrica se mueve, y cuánto?

Elija una métrica principal. Ejemplos que funcionan:

• "Reducir el tiempo de redacción de una propuesta comercial de 4 horas a 30 minutos."
• "Aumentar el pipeline cualificado procedente de inbound un 25%."
• "Recortar el tiempo de enriquecimiento manual del CRM por comercial de 6 horas semanales a 1."

Ejemplos que no:

• "Mejorar la productividad." ¿La de quién?
• "Usar IA para marketing." ¿Haciendo qué, exactamente?
• "Ser más data-driven." ¿Comparado con qué?

Si no puede poner un número junto al verbo, no está preparado.

3. ¿Cuál es la versión más pequeña que sigue siendo útil?

La mayoría de los scopes de IA son tres veces demasiado grandes. Pregúntese: si solo pudiéramos construir un workflow, ¿cuál sería? Esa es su v1. Todo lo demás es v2.

4. ¿Qué aspecto tiene el fracaso a los 90 días?

Si en el día 90 el equipo no lo está usando, ¿por qué podría ser? Escriba tres respuestas honestas. Serán las suposiciones que tendrá que probar en el prototipo.

5. ¿Qué datos tiene realmente?

No los datos que le gustaría tener. Los datos que viven en sus sistemas hoy, con calidad razonable, y a los que alguien puede dar acceso en dos semanas.

Si la respuesta es "primero tendremos que hacer un proyecto de datos", eso es otro proyecto. Defina su scope por separado.

6. ¿Cuál es la restricción realmente determinante?

¿Tiempo? ¿Presupuesto? ¿Cumplimiento normativo? ¿Política interna? Elija una. Las propuestas que recibirá son radicalmente distintas según la respuesta. Si no puede nombrar la restricción determinante, obtendrá la propuesta que cada proveedor quería vender, no la que su situación necesita.

Las preguntas que las agencias deberían hacerle

Si una agencia presenta una propuesta sin haber preguntado esto, trátela como una conjetura:

• ¿Quién es el dueño del resultado internamente?
• ¿Qué aspecto tiene el éxito en cifras en el día 90?
• ¿Qué sistemas están dentro del scope y cuáles explícitamente fuera?
• ¿Cuál es el estado de los datos hoy?
• ¿Cuál es el proceso de compra y el calendario?
• ¿Qué se ha intentado antes, y por qué no cuajó?

Un proveedor que se salta estas preguntas y va directo a las funcionalidades de la plataforma está vendiendo, no haciendo scoping.

Cómo comparar las propuestas cuando lleguen

Cuando lleguen las propuestas, puntúelas en cinco cosas. No en capacidades — en scope.

• Claridad del scope. ¿Puede leerla y predecir exactamente qué se va a construir?
• Transparencia de las suposiciones. ¿Qué asumieron? ¿Son correctas esas suposiciones para su realidad?
• Superficie de riesgo. ¿Qué podría descarrilar esto — integraciones, datos, seguridad, gestión del cambio — y cómo lo gestionan?
• Lógica de precios. ¿El precio está ligado al resultado, al tiempo o al scope? Los desajustes son señales de alarma.
• Ruta de salida. ¿Qué cuesta salir después de la v1? El vendor lock-in es un gasto real — El coste oculto de elegir al partner de IA equivocado explica cómo se ve en la práctica.

Puntúe cada propuesta de 1 a 5 en estos criterios. La que obtiene la puntuación más alta rara vez es la del precio más bajo o la presentación más bonita.

Errores habituales

• Tratar el discovery como una fase gratuita. El discovery de verdad es trabajo remunerado. Si un proveedor lo ofrece gratis, está subvencionando la venta o saltándose la versión rigurosa.
• Añadir scope durante el procurement. Cada "y además" duplica el riesgo. Resístase.
• Dejar que el proveedor defina su propio scope. Si el mismo proveedor define el scope y puja, está pagando por un scope sesgado.

Ideas clave

• La mayoría de los proyectos de IA fracasan por el scope, no por la tecnología.
• Un brief de scope de verdad nombra al responsable, la métrica, la v1 y la restricción determinante.
• Las buenas agencias hacen las mismas preguntas antes de pujar. Las malas venden funcionalidades.
• Compare propuestas por claridad de scope, no por listas de capacidades.

Si quiere un scope más afilado antes de tomarse en serio una sola propuesta, para eso exactamente está construido el AI Scoping Workshop. Y cuando el use case todavía necesita prueba, valídelo mediante un MVA Sprint antes de escalar.

---

¿Ya ha recibido propuestas de IA? Haga revisar cada propuesta de forma independiente antes de comprometerse, o reserve una intake gratuita de AI scoping. Independiente, rápida, y le señalaremos lo que falta.