Un encargo de pipeline IA sin alcance definido no es flexible: es una fuente de conflictos, sobrecostes y entregas que no resuelven nada. Aquí se explica cómo acotar bien y por qué conviene a ambas partes.
El problema no es técnico: es de definición
Cuando una PYME encarga un pipeline IA a medida, el riesgo más habitual no está en la tecnología. Está en el momento en que alguien dice "y también podría hacer X, ¿verdad?" sin que nadie haya acordado qué estaba dentro y qué no.
Un alcance abierto parece cómodo al principio. En la práctica, genera entregas que no coinciden con lo que se esperaba, presupuestos que se estiran, y una relación proveedor-cliente que se deteriora aunque nadie haya actuado de mala fe.
El problema es estructural: cuando el alcance no está cerrado, cada parte trabaja con un mapa diferente del mismo territorio.
Qué significa "alcance cerrado" en un pipeline IA
Cerrar el alcance no es escribir un PDF de cien páginas. Es acordar, antes de empezar, tres cosas concretas:
- Qué entra: qué fuentes de datos, qué integraciones, qué salidas produce el sistema.
- Qué no entra: explícito, no implícito. Si no está escrito, no está incluido.
- Cómo se verifica que está hecho: el criterio de aceptación. Sin esto, "terminado" no significa lo mismo para las dos partes.
En un sprint de automatización, estos tres puntos determinan si el proyecto se entrega en tres días o en tres semanas. Y si el cliente recibe lo que necesitaba o lo que el proveedor interpretó que necesitaba.
Por qué el alcance abierto perjudica al cliente
Imagina una empresa de servicios profesionales que encarga un pipeline para clasificar y enrutar correos entrantes. El encargo inicial es claro. A mitad del sprint, alguien del equipo pregunta si el sistema podría también generar borradores de respuesta. Parece una extensión lógica.
El problema: cada funcionalidad añadida sin redefinir el alcance consume tiempo que estaba asignado a otra cosa. El resultado es que la funcionalidad principal llega incompleta, la nueva llega a medias, y el cliente tiene un sistema que no hace bien ninguna de las dos cosas.
El alcance abierto también dificulta la estimación de coste. Si el precio se acordó sobre un alcance vago, cualquier precisión posterior puede parecer un sobrecoste, aunque técnicamente no lo sea. Esa percepción destruye la confianza aunque el trabajo sea honesto.
Por qué el alcance abierto perjudica al proveedor
Un proveedor que acepta encargos sin alcance definido no está siendo flexible: está asumiendo riesgo sin precio. Cada petición añadida sin renegociar el alcance es trabajo no presupuestado. Y si el proveedor absorbe ese trabajo para "no crear conflicto", el proyecto se vuelve inviable económicamente.
La alternativa, cobrar por cada cambio sin haberlo acordado antes, genera fricción constante. El cliente siente que le cobran por cualquier cosa. El proveedor siente que trabaja sin límites claros. Ninguno de los dos tiene razón del todo, y eso es exactamente el problema del alcance abierto.
Cómo se acota un encargo en la práctica
El proceso de acotación tiene fases reconocibles en proyectos de automatización bien gestionados:
- Diagnóstico del problema real. No del sistema que el cliente quiere construir, sino del problema que ese sistema debe resolver. Es habitual que el encargo inicial describa una solución, no un problema. Ir al problema permite descartar complejidad innecesaria.
- Inventario de entradas y salidas. Qué datos entran al pipeline, en qué formato, con qué frecuencia. Qué produce el sistema, dónde va esa salida, quién la consume. Cada dato ambiguo aquí se convierte en un conflicto más adelante.
- Definición de criterios de aceptación. Cómo se demuestra que el sistema funciona. No "funciona bien", sino "clasifica correctamente el tipo X de documento" o "entrega la respuesta en menos de N segundos bajo carga Y". Sin criterios medibles, la aceptación es subjetiva.
- Lista explícita de exclusiones. Lo que no está incluido, escrito. Esto no es desconfianza: es precisión. Evita que el cliente asuma que algo está incluido porque "parecía obvio".
- Protocolo de cambios. Qué ocurre si durante el sprint aparece una necesidad nueva. No bloquearlo, pero sí gestionarlo: se evalúa, se decide si entra en este sprint o en uno posterior, y se ajusta el alcance por escrito.
El sprint como unidad de trabajo acotada
Estructurar el trabajo en sprints de alcance cerrado no es una metodología de moda. Es una forma de gestionar la incertidumbre sin que esa incertidumbre se convierta en coste oculto.
Un sprint corto —tres a cinco días— sirve para validar una hipótesis técnica o entregar una pieza funcional concreta. Un sprint medio —una a dos semanas— permite integrar componentes y probar el flujo completo. Un sprint complejo —tres a cuatro semanas— abarca sistemas con múltiples integraciones o lógica de negocio no trivial.
La duración no es arbitraria: refleja el alcance acordado. Si el alcance crece, la duración crece. Si crece sin renegociarse, el proyecto se retrasa sin que nadie lo haya decidido conscientemente.
"Tengo un encargo de automatización IA con el siguiente objetivo: [descripción]. Actúa como arquitecto de sistemas y hazme las preguntas que necesitarías responder antes de comprometerte a un alcance. No me des la solución: dame la lista de ambigüedades que deberían resolverse antes de empezar."
Precio cerrado y alcance cerrado van juntos
Un precio cerrado sin alcance cerrado es una promesa vacía. Si el alcance puede crecer sin límite, el precio cerrado no protege a nadie: o el proveedor absorbe el sobrecoste, o el cliente recibe menos de lo que esperaba.
La lógica inversa también aplica: un alcance bien definido hace posible un precio cerrado real. El proveedor sabe exactamente qué está comprometiendo. El cliente sabe exactamente qué está comprando. No hay "esto cuesta más" a mitad del proyecto porque no hay ambigüedad sobre qué estaba incluido.
Eso es lo que hace que un encargo a medida sea tratable como un producto: alcance definido, criterios claros, precio acordado antes de empezar.
Cuándo tiene sentido la consultoría por hora
Hay situaciones donde el alcance no puede cerrarse de antemano porque el problema no está suficientemente definido. En esos casos, intentar forzar un sprint cerrado produce un alcance ficticio que nadie cumplirá.
La consultoría por hora es la herramienta adecuada cuando el objetivo es explorar, diagnosticar o diseñar antes de construir. No es una alternativa peor al sprint: es el formato correcto para una fase diferente del trabajo.
Supongamos que una empresa sabe que tiene un problema con su gestión documental pero no sabe si la solución es un pipeline de clasificación, un sistema de búsqueda semántica o algo más simple. Intentar presupuestar un sprint sin responder esa pregunta primero es construir sobre arena. Unas horas de consultoría para acotar el problema valen más que semanas de desarrollo en la dirección equivocada.