Cómo definir el alcance de un proyecto de IA (y frenar el trabajo que no se cobró)

La reunión de la semana seis, cuando el proyecto ya no es el que se firmó

La escena se repite con variaciones menores en casi cualquier proyecto de IA que se atrasa. El consultor entra a la reunión de la semana seis de un proyecto de ocho, y lo que iba a ser una actualización de avance se convierte en una discusión sobre quién pierde plata. El cliente pregunta por qué el modelo todavía no está listo si la propuesta hablaba de ocho semanas. El consultor explica que las primeras tres semanas se fueron en limpiar datos que, según la propuesta firmada, ya estaban ordenados. El cliente responde algo que ha escuchado decir a decenas de clientes distintos, casi con las mismas palabras: “yo pensé que eso lo hacían ustedes”.

Nadie mintió en esa reunión de venta. El cliente describió el estado de sus datos tal como lo recordaba, no tal como estaba realmente en el sistema. Nadie audita su propio CRM antes de contratar una consultoría, y es razonable que no lo haga: para eso contrata a alguien. El error no está en que el cliente se haya equivocado sobre sus datos. Está en que esa descripción optimista nunca se convirtió en una condición escrita, verificable, con una consecuencia clara si resultaba falsa. Sin esa condición, cuando la realidad no coincide con lo que se dijo en la reunión de venta, no hay documento al que volver: solo hay dos versiones de lo que “se entendía”, y el que factura después pierde.

Quien vive esto todos los meses es el consultor de IA: la persona que cotiza con la información que el cliente le da, porque verificar cada dato antes de firmar sería, en la práctica, hacer gratis buena parte del proyecto. El desborde de alcance en IA no nace de clientes de mala fe ni de consultores que cotizan mal a propósito. Nace de un supuesto que todos daban por cierto y que nadie puso por escrito antes de que el reloj empezara a correr.

Qué entra y qué no en el alcance de un proyecto de IA

Antes de discutir cláusulas hay que resolver algo más básico: qué palabras usa el documento para decir “esto sí, esto no”. Un alcance de IA que solo describe el resultado final (“un sistema que clasifica tickets automáticamente”) no protege a nadie, porque el resultado final admite mil caminos distintos y mil presupuestos distintos. Lo que protege es la lista concreta de entregables y, con el mismo peso, la lista de lo que queda explícitamente fuera.

• El modelo o la lógica entrenada sobre el caso de uso acordado, con el conjunto de datos que se definió para entrenarlo y probarlo.
• La integración puntual con los sistemas que se nombraron en la propuesta, no “los sistemas de la empresa” en general.
• Las pruebas contra los criterios de aceptación pactados, no una promesa abierta de que el modelo “funcione bien”.
• La documentación y el traspaso para que el equipo del cliente pueda operar lo entregado sin depender del consultor cada semana.

Igual de importante es nombrar lo que el documento excluye a propósito: la limpieza indefinida de datos que aparezcan sucios después de firmado, la integración con sistemas que nadie mencionó en la propuesta, el reentrenamiento continuo del modelo una vez en producción y la redefinición de las reglas del negocio a mitad de camino, porque eso no es un ajuste técnico, es que el cliente todavía no decidió qué necesita. Cuando esa lista de exclusiones no existe, el default tácito es “todo entra”, y ese default lo paga siempre el margen del proyecto.

Esa definición tiene una consecuencia práctica que se olvida seguido: si el alcance fija en qué estado deben estar los datos, entonces el estado real de los datos deja de ser un problema técnico que el consultor absorbe en silencio y se convierte en una condición contractual, con su propio mecanismo cuando no se cumple. Es la misma lógica que sostiene cómo estructurar contratos y SLAs con proveedores de IA: una cláusula no vale por lo detallada que suena, vale por lo verificable que es.

La cláusula de estado de datos: lo que hay que firmar antes, no descubrir después

La cláusula de estado de datos no es un formulario técnico que se le pide al área de sistemas del cliente. Es una lista corta de supuestos verificables que el consultor escribe en su propia propuesta, a partir de lo que el cliente describió, y que el cliente firma como cierto. Si algo de esa lista resulta falso una vez dentro del proyecto, eso no es un problema que el consultor absorbe: es el gatillo explícito para revisar precio y plazo.

• Volumen esperado: cuántos registros o casos existen realmente, no la cifra aproximada que alguien recuerda de memoria.
• Formato y ubicación: en qué sistema vive el dato, en qué estructura, y si hay que exportarlo o el consultor tiene acceso directo.
• Completitud del campo objetivo: si el dato que se necesita predecir (la etiqueta, el resultado, la categoría) está registrado en la mayoría de los casos históricos, no solo en los recientes.
• Fecha de corte de la muestra que se usó para cotizar, porque un dato revisado en enero no garantiza nada sobre el dato de julio.
• Permisos de acceso ya otorgados, no “los vamos a tramitar cuando arranquemos”, porque esa gestión sola puede comerse semanas del cronograma.

En la práctica, pido una muestra pequeña y real de los datos antes de cerrar el precio final, no la descripción verbal de cómo están. No hace falta una auditoría completa, que sería cotizar gratis parte del diagnóstico. Alcanza con revisar unas pocas semanas o un puñado de registros representativos para confirmar que lo que el cliente cree tener coincide con lo que hay. Esa muestra chica es la diferencia entre cotizar sobre un supuesto y cotizar sobre un hecho verificado.

Los demás supuestos que hay que dejar por escrito (no solo los de datos)

El estado de los datos es el supuesto que más desborda un proyecto de IA, pero no es el único. Cualquier condición de la que dependa el cronograma o el precio, y que el consultor no controla, tiene que quedar escrita en la propuesta con el mismo nivel de detalle. Si no se escribe, se vuelve un reclamo después, y el reclamo casi siempre lo gana quien factura menos.

• Quién aprueba cada entrega y en cuánto tiempo: un proyecto no avanza si el responsable del cliente tarda semanas en revisar un avance, y esa demora no puede convertirse en “atraso del consultor”.
• Qué entorno y qué accesos entrega el cliente, y cuándo: ambiente de pruebas, credenciales, permisos de API. Sin fecha comprometida, el reloj del proyecto empieza a correr solo del lado del consultor.
• Quién ejecuta la integración con sistemas internos: si es el equipo de IT del cliente o el consultor, porque cambia radicalmente el esfuerzo cotizado.
• Qué fechas dependen de que el cliente entregue algo primero: un dato, una decisión de negocio, una firma. Un plazo fijo que depende de un tercero no es un plazo fijo, es una expectativa.

Cada uno de estos puntos suena obvio cuando se lee en una lista, y por eso mismo se salta al redactar una propuesta de consultoría de IA que se aprueba: la prisa por cerrar el trato empuja a dar por sentado lo que en realidad nadie confirmó. Un supuesto no escrito no desaparece, solo espera a la reunión de la semana seis para aparecer como discusión.

Cómo se cobran los cambios sin que cada uno se convierta en una pelea

El miedo a “pelear” por un cobro adicional es lo que más plata le cuesta a un consultor de IA, no la falta de un buen contrato. La solución no es endurecer el tono en la reunión, es tener el mecanismo decidido de antemano para no tener que improvisarlo bajo presión. La distinción que uso es simple: una aclaración razonable de algo ya escrito en el alcance no se cobra, porque cobrarla erosiona la confianza más de lo que vale esa hora. Una adición real al alcance sí se cobra, siempre, y se cobra antes de empezarla, no después de terminarla.

• Un caso de uso nuevo que se suma a mitad de camino y no estaba en la propuesta original.
• Una integración con un sistema que nunca se mencionó al cotizar, aunque el cliente asuma que “ya que estás metido ahí”.
• Un cambio en el criterio de aceptación ya pactado, porque mover la meta a mitad de proyecto es, en la práctica, otro proyecto.
• Un dataset adicional que el cliente decide sumar después de firmado, aunque parezca del mismo tipo que el original.
• Un requisito legal o de seguridad que aparece después de la firma y que nadie pudo anticipar en la propuesta.

El precio del cambio se dice en voz alta en la misma reunión donde se pide, no “te lo paso por correo”, que es la forma más fácil de diluir la conversación y de que el cliente entienda otra cosa. La misma disciplina que uso para poner precio a un proyecto de IA desde el inicio aplica aquí: un número dicho con seguridad en el momento se acepta casi siempre; un número que llega tarde, por correo y a la defensiva, se negocia siempre a la baja.

Criterios de aceptación medibles: sin ellos, “que funcione bien” no significa nada

“Que el modelo funcione bien” no es un criterio de aceptación, es una frase que cada parte interpreta a su favor cuando llega el momento de cerrar el proyecto y cobrar el saldo. El cliente la lee como “perfecto en todos los casos”; el consultor la lee como “mejor que lo que había antes”. Ambas lecturas son razonables y ambas son incompatibles, así que la discusión se vuelve sobre percepciones en vez de sobre hechos.

• Una línea base del proceso actual: cómo se decide hoy, sin modelo, para tener con qué comparar. Sin ese punto de partida, no hay forma de demostrar que el proyecto mejoró algo.
• Un conjunto de prueba definido de antemano, acordado con el cliente antes de entrenar, no elegido después para que el resultado luzca mejor.
• Un umbral pactado por escrito, no descubierto sobre la marcha, sobre qué nivel de desempeño se considera aceptado y cuál dispara una revisión.
• Quién evalúa y con qué método, para que el resultado no dependa de quién mire los números ese día.

El error habitual, sobre todo cuando hay presión comercial por cerrar la venta, es prometer un desempeño que suena bien en la propuesta pero que nunca se comparó con una línea base real. Prefiero un criterio modesto y verificable a una promesa optimista que nadie sabe cómo probar. Un umbral pactado, aunque sea conservador, cierra la discusión el día de la entrega; una promesa vaga la reabre.

Qué pasa con el mantenimiento después del cierre (esto también es alcance)

Un modelo entregado y aceptado no se queda quieto: el comportamiento que aprendió sobre los datos del cliente empieza a desactualizarse desde el primer día en producción, a un ritmo que depende del negocio, no de la calidad del modelo. Si el alcance no dice qué pasa después del cierre, el cliente asume que el consultor sigue disponible indefinidamente para “lo que salga”, y el consultor asume que el proyecto terminó el día de la entrega. Las dos suposiciones son razonables y las dos generan el mismo conflicto.

Por eso el alcance tiene que nombrar, con la misma precisión que el resto de las cláusulas, qué cubre la etapa posterior al cierre: una ventana corta de garantía solo para defectos del entregable original (no para funciones nuevas), quién queda a cargo de monitorear que el modelo siga rindiendo, y qué ocurre cuando ese rendimiento cae por debajo del umbral pactado en los criterios de aceptación. Lo que no cabe en esa ventana de garantía es una expectativa abierta de soporte gratuito indefinido.

La forma más honesta de resolverlo, y la que más me ha funcionado, es no fingir que el mantenimiento cabe gratis dentro del proyecto cerrado: se ofrece como línea aparte o se convierte directamente en un retainer de consultoría de IA, con su propio alcance mensual. Decirlo así, desde la propuesta inicial, evita la conversación incómoda de después, donde el cliente siente que le están cobrando dos veces por lo mismo.

Las señales de que el alcance se está desbordando, antes de que sea tarde

El desborde de alcance casi nunca llega como una sola decisión grande y visible. Llega como una sucesión de “sí, está bien” dichos para no incomodar en una reunión, hasta que en la semana ocho nadie recuerda bien qué se firmó originalmente. Estas son las señales que reviso para detectarlo mientras todavía se puede frenar, no cuando ya es una pelea por el pago final.

• El cliente empieza frases con “ya que estás”: la señal más común y la más fácil de dejar pasar, porque cada pedido suena pequeño por separado.
• Las reuniones de avance se vuelven sesiones de lluvia de ideas en vez de revisiones de entregables contra el documento firmado.
• Aparecen usuarios nuevos pidiendo funciones que nadie negoció con quien firmó el contrato.
• El ambiente de pruebas deja de ser el que se acordó, y nadie lo menciona porque “total es casi igual”.
• El equipo dice “esto no toma nada” para evitar la conversación incómoda de cobrar un cambio, y ese “nada” se acumula durante semanas.
• La fecha de entrega se mueve varias veces pero el presupuesto nunca se vuelve a conversar.

Ignorar estas señales es, según he visto, uno de los errores de un consultor de IA en su primer año: confundir flexibilidad con buen servicio. Ser flexible es ajustar la forma de entregar algo ya pactado; absorber gratis todo lo que se pide “de paso” es simplemente no cobrar por el trabajo que sí se hizo.

Mi criterio: el alcance no protege al cliente, protege la relación

La prueba de que un alcance está bien escrito no es que el proyecto salga perfecto: nunca sale exactamente como se imaginó. Es que cuando algo cambia (y algo siempre cambia) las dos partes ya saben, sin discutirlo de nuevo, qué documento consultar y qué sigue.