Un documento de alcance escrito solo para ingenieros será firmado por un comprador que no lo entendió. Esa firma se convierte en el origen de cada orden de cambio disputada después.
La solución no es un documento más largo. Es un documento con una estructura deliberada — uno que le da a los ingenieros la precisión que necesitan y a los compradores la claridad que necesitan para aprobar y mantener la línea.
Dos audiencias, un documento
Todo documento de alcance de un proyecto de IA tiene dos lectores con condiciones de éxito distintas.
El equipo de ingeniería necesita saber exactamente qué está construyendo, qué no está construyendo, y cómo se ve "terminado" en términos medibles. La ambigüedad aquí produce retrabajo.
El comprador necesita saber qué está pagando, qué está fuera del alcance, y qué sucede cuando aparece algo inesperado. La ambigüedad aquí produce disputas.
La mayoría de los documentos de alcance sirven bien a una audiencia e ignoran a la otra. Los ingenieros escriben en términos de sistema — endpoints, presupuestos de latencia, versiones de modelos. Los compradores leen en términos de resultados — leads generados, horas ahorradas, costo por acción. Ninguna traducción está mal. Ambas necesitan vivir en el mismo documento.
La estructura a continuación fuerza esa traducción.
Cuatro secciones que todo documento de alcance necesita
1. Límite
Establece exactamente qué hace el sistema. Un párrafo. Lenguaje claro.
Ejemplo: Este sistema ingiere una lista de hasta 5,000 registros de empresas por semana, enriquece cada registro con datos firmográficos de dos fuentes, puntúa cada registro contra un ICP definido, y entrega un archivo de salida ordenado a un bucket S3 especificado antes de las 6 AM del lunes.
Esa oración funciona para un ingeniero y para un comprador. El ingeniero ve el volumen de datos, las fuentes, el formato de salida y la ventana de entrega. El comprador ve qué está recibiendo y cuándo.
Si no puedes escribir el límite en un párrafo, el alcance todavía no está definido.
2. Exclusiones
Esta sección es la más omitida y la más costosa de dejar fuera.
Las exclusiones establecen qué no hace el sistema. No qué podría hacer después. No qué está fuera del presupuesto. Qué está explícitamente fuera de este compromiso.
Ejemplo de exclusiones para el sistema anterior:
- La escritura de vuelta al CRM no está incluida. La salida se entrega solo como archivo.
- El sistema no valida ni limpia los registros de entrada. Los registros malformados se omiten y se registran en el log.
- El enriquecimiento en tiempo real no está en el alcance. El procesamiento corre en un schedule de batch semanal.
- La revisión humana de los registros puntuados no está incluida.
Sin esta sección, los compradores asumen que todo lo adyacente al límite está incluido. Los ingenieros asumen que el comprador sabe que no lo está. Esa brecha cuesta dinero real — típicamente en forma de una conversación a mitad del proyecto donde ambas partes tienen razón y ambas partes están frustradas.
Escribe la lista de exclusiones antes de que empiece el primer sprint. Revísala con el comprador explícitamente. Obtén reconocimiento por escrito.
3. Criterios de éxito en unidades medibles
Los criterios de éxito deben ser números, no adjetivos.
Mal: El sistema debe funcionar bien y entregar resultados precisos.
Bien:
- Tasa de coincidencia de enriquecimiento ≥ 85% en registros de entrada válidos
- El batch semanal completa y entrega el archivo de salida dentro de la ventana de las 6 AM en ≥ 95% de las ejecuciones programadas
- Latencia de puntuación por registro ≤ 200ms en el percentil 99
- Tasa de falsos positivos en la puntuación ICP ≤ 12% medida contra un conjunto de validación de 200 registros
Estos números hacen dos cosas. Le dan a los ingenieros un objetivo hacia el cual construir. Le dan a los compradores una definición de "terminado" que pueden verificar sin leer código.
Si un comprador no puede evaluar los criterios de éxito sin ayuda de ingeniería, los criterios todavía no son legibles para el comprador.
4. Ruta de escalación
Los documentos de alcance casi siempre omiten esto. Es la sección que previene las conversaciones más costosas.
La ruta de escalación responde: ¿Qué sucede cuando algo fuera del límite aparece durante el proyecto?
Debe especificar:
- Quién identifica el ítem fuera del alcance (ingeniero, PM o comprador)
- Cómo se documenta (una solicitud de cambio por escrito, no un mensaje de Slack)
- Quién aprueba los cambios de alcance y en qué plazo
- Si el cambio afecta el cronograma, el costo, o ambos, y cómo se comunica eso
Una ruta de escalación de un párrafo previene la situación donde un ingeniero construye algo adyacente al alcance porque parecía útil, el comprador lo ve y espera que se mantenga, y el siguiente compromiso empieza con un desacuerdo sobre qué fue prometido.
Qué cuesta realmente omitir las exclusiones
Un ejemplo realista: un equipo define el alcance de un pipeline de enriquecimiento de leads. La sección de exclusiones está en blanco. El comprador asume que la sincronización con el CRM está incluida — estaba en el entorno de demo. El ingeniero asume que nunca se discutió. Tres semanas después, el comprador pregunta cuándo entra en producción la sincronización con el CRM. El ingeniero dice que nunca estuvo en el alcance. El comprador revisa el contrato. El contrato no dice nada.
Opciones de resolución: construirlo gratis, cobrarlo y dañar la relación, o negociar un parcial. Las tres opciones cuestan más que haber escrito la sección de exclusiones en la semana uno.
El costo del retrabajo no son solo horas de ingeniería. Es el costo de confianza, el costo de retraso, y el costo de distracción para cada otro proyecto que corre en paralelo.
Aplicando esto a sistemas de IA específicamente
Los sistemas de IA tienen un modo de falla de alcance específico: los compradores asumen que el sistema manejará casos borde para los que nunca fue entrenado ni diseñado. Un documento que define el límite y las exclusiones con precisión reduce esa brecha de suposiciones antes de que se convierta en un ticket de soporte.
En DK1.AI, la claridad de alcance está integrada en cómo estructuramos cada compromiso. AI Brand Presence es un ejemplo — el límite, las exclusiones y los criterios de éxito se definen antes de que empiece cualquier trabajo en producción, para que ambas partes sepan exactamente qué se está construyendo y qué no.
Esa disciplina aplica en cada sistema que operamos.