Cómo escribir un documento de alcance para un agente de IA

Publicado en agosto de 2026.

TL;DR: Un documento de alcance convierte “quiero un agente de IA para mi negocio” en una cifra que puedes cotizar y que el cliente puede aprobar. Necesita seis partes: el disparador, las entradas, las salidas, las herramientas que utiliza, lo que queda explícitamente excluido y una lista escrita de pruebas de aceptación. Escríbelo antes de cotizar la tarifa de construcción, no después. Yo cobro el mío como un entregable de auditoría fijo de $500–$1,000, aparte de la construcción.

[La lectura del operador] Gestiono más de 30 agentes en producción entre una marca de consultoría y Pickleland, un centro de pickleball en Pflugerville, TX, y he definido el alcance de builds de agentes para clientes además de esa experiencia. La razón más común por la que un proyecto de agente sale mal no es el código: es que nadie escribió qué significaba “terminado” antes de enviar la factura. Un documento de alcance resuelve eso en una sola sesión. Es el entregable menos glamoroso que produzco y el que evita más discusiones.

Tabla de contenidos

Por qué un documento de alcance, no un correo de propuesta

Un correo de propuesta describe lo que harás. Un documento de alcance define cómo se ve “terminado” — con la especificidad suficiente para que tú y el cliente puedan comparar el agente terminado con él y estar de acuerdo, sin necesidad de una conversación, sobre si pasó o no.

Esa distinción importa porque el precio de los agentes de IA solo funciona si la tarifa de construcción se ancla a algo fijo. Cotiza un precio fijo contra un alcance indefinido y habrás cotizado una cifra que en realidad no puedes cumplir: el modelo mental del cliente de “un agente de IA para mi negocio” sigue expandiéndose gratis hasta que tú pones un límite, y poner ese límite después del depósito es una conversación peor que definir el límite antes.

Escribo uno para cada build, incluso los pequeños. Un agente de un solo flujo de trabajo recibe una versión de media página. Un sistema multiagente recibe el documento completo. El formato no cambia — solo cambia la extensión.

Las seis cosas que necesita un documento de alcance

1. El disparador. Qué hace que el agente empiece a funcionar: el envío de un formulario, una hora programada, un correo entrante, un webhook de otra herramienta. Nombra el disparador exacto, no una categoría de disparador. “Se ejecuta cuando se envía un formulario de leads” es alcance. “Gestiona leads entrantes” no lo es.

2. Las entradas. Qué datos recibe el agente y de dónde vienen. Enumera los campos, no solo la fuente — “nombre, correo, tamaño de la empresa y el campo de texto libre del mensaje del envío de Typeform,” no “los datos del formulario.”

3. Las salidas. Qué produce el agente y adónde va. Misma regla: nombra el destino y el formato. “Publica un borrador de respuesta en el canal de Slack #leads para aprobación humana” es alcance. “Responde a los leads” no lo es.

4. Las herramientas e integraciones que utiliza. Cada API, base de datos o plataforma que el agente llama. Aquí también anotas cualquier cosa que explícitamente no estás integrando — un cliente que asume que su CRM está incluido porque lo mencionó una vez en la llamada de descubrimiento es la fuente más común de scope creep que he visto.

5. Lo que queda excluido. Una lista corta y explícita de cosas que el agente no hará, aunque suenen relacionadas. Si estás construyendo un agente de clasificación de leads, escribe “no envía mensajes salientes” aunque parezca obvio — lo obvio para ti no es obvio para un cliente que nunca ha definido el alcance de un software antes.

6. La lista de pruebas de aceptación. La lista real de casos que el agente terminado debe superar antes de que se deba el pago final. No “funciona bien” — casos específicos y verificables: “clasifica correctamente 9 de 10 leads de muestra del conjunto de datos proporcionado,” “publica correctamente en el canal de Slack conectado sin intervención manual,” “gestiona un envío mal formado (campo de correo faltante) sin fallar.” Esta es, sin duda, la sección más importante del documento, porque es a la que ambas partes pueden recurrir después sin tener que volver a discutir qué se quiso decir.

La plantilla

Esta es la estructura real que uso. Cópiala, completa las seis secciones y tendrás un documento al que puedes ponerle un precio.

AGENT SCOPE DOCUMENT — [Client name] / [Project name]
Date: [date]

1. TRIGGER
   [What starts this agent running]

2. INPUTS
   [Exact data fields and their source]

3. OUTPUTS
   [What the agent produces, in what format, sent where]

4. TOOLS & INTEGRATIONS
   Included: [every API/platform/database touched]
   Explicitly excluded: [anything adjacent that is NOT built]

5. EXCLUSIONS
   [What this agent will not do, even if related]

6. ACCEPTANCE TESTS
   [ ] [Specific, checkable test case]
   [ ] [Specific, checkable test case]
   [ ] [Specific, checkable test case]
   ...

BUILD FEE: $[amount], due [payment terms]
MAINTENANCE RETAINER: $[amount]/month, starting [date]
CHANGE REQUESTS: priced separately, quoted before work starts

Signed: _______________  Date: _______

Las líneas de tarifa de construcción y retainer existen para que el precio quede anclado directamente al alcance definido arriba — mira cómo calculo ambas cifras si nunca has puesto precio a un build. Un cliente que firma este documento está aprobando el alcance y el precio en el mismo gesto, que es justamente el punto.

Cómo llevo la llamada que produce este documento

Cobro la sesión de definición de alcance en sí como una auditoría fija de $500–$1,000, separada de la tarifa de construcción — nunca la incluyo en ella, ni siquiera cuando el cliente sigue adelante. Dos razones: evita que la etapa de definición de alcance se convierta en trabajo de ventas no pagado, y hace que el cliente se tome la llamada en serio en lugar de tratarla como una consulta gratuita.

La llamada en sí dura entre 30 y 45 minutos, estructurada en torno a las seis secciones anteriores, en orden. No dejo que la conversación se desvíe hacia “qué podría hacer un agente de IA, en teoría, por tu negocio” — esa es una conversación distinta, más cara, y es la que produce documentos que nadie puede cotizar. Pido el disparador primero, porque un cliente que no puede nombrar qué inicia el proceso normalmente no tiene un flujo de trabajo lo bastante estable como para automatizarlo todavía — algo que vale la pena sacar a la luz antes de que ninguno de los dos se comprometa con un build.

Envía el prompt, no la página en blanco

No escribo el primer borrador del documento a mano. Tomo mis notas de la llamada — a menudo solo un párrafo desordenado de viñetas — y pego esto en Claude:

Here are my raw notes from a scoping call for an AI agent build. Turn them
into a scope document with exactly these six sections: Trigger, Inputs,
Outputs, Tools & Integrations, Exclusions, Acceptance Tests. For each
section, flag anything the notes don't specify clearly enough to build
against, rather than guessing or filling the gap yourself. The acceptance
tests need to be specific and checkable — reject vague criteria like
"works correctly" and either sharpen them into a concrete test case or
flag them for me to clarify with the client.

[paste raw notes]

Esa última instrucción — marcar los vacíos en lugar de rellenarlos — es la parte que importa. Un modelo inventará con gusto una prueba de aceptación que suene plausible para completar el documento, y una prueba que suena plausible pero no coincide con lo que el cliente realmente quiso decir es peor que un espacio en blanco sobre el que tienes que preguntar.

Errores comunes que todavía veo cometer a la gente

Escribir la sección de exclusiones al final, o saltársela. La sección de exclusiones es la que la mayoría trata como opcional. Es la que evita más disputas. Escríbela antes de las pruebas de aceptación, no después.

Pruebas de aceptación que describen comportamiento en lugar de resultados. “El agente debe entender el tono del cliente” es comportamiento. “El borrador de respuesta del agente se aprueba sin ediciones en 7 de 10 casos de muestra” es un resultado. Solo los resultados son verificables.

Definir el alcance a partir de una sola conversación sin notas escritas. Si el documento de alcance es el primer artefacto escrito del proyecto, estás reconstruyendo la llamada de memoria días después. Toma notas durante la llamada, en el orden de las seis secciones, y el documento prácticamente se escribe solo.

Dejar que el cliente escriba el alcance. Que un cliente describa lo que quiere con sus propias palabras es un insumo para el documento, no el documento en sí. Su lenguaje suele tener forma de funcionalidad (“quiero que gestione mis leads”), no forma de prueba. Traducir eso en criterios de aceptación verificables es el verdadero valor de la sesión de definición de alcance — por eso es un entregable pagado y no un formulario que el cliente llena por su cuenta.

Las herramientas que uso para esto

Claude redacta el documento a partir de las notas de la llamada usando el prompt anterior, y marca los vacíos en lugar de adivinarlos.

Notion es donde vive el documento de alcance terminado, compartido con el cliente antes de cobrar cualquier depósito — el mismo lugar donde guardo el resto del rastro documental del proyecto.

Airtable hace seguimiento de qué proyectos están en definición de alcance, cuáles firmados y cuáles en construcción, una fila por cliente, para que un documento de alcance nunca quede sin firmar durante semanas sin que nadie se dé cuenta.

Preguntas frecuentes

¿Qué tan largo debe ser un documento de alcance?

Tan largo como sea necesario para que cada prueba de aceptación sea verificable, y ni un poco más. Un agente de un solo flujo de trabajo puede ocupar media página. Un sistema multiagente con varias integraciones puede llegar a dos o tres páginas. La extensión no es el objetivo — el objetivo es que un cliente y un desarrollador, leyendo las pruebas de aceptación por separado, lleguen a la misma conclusión sobre si se superaron o no.

¿Qué pasa si el cliente quiere cambiar el alcance después de firmar?

Eso es una solicitud de cambio, cotizada por separado y presupuestada antes de empezar el trabajo — escribe esa condición en el propio documento, como en la plantilla anterior. Un documento de alcance que se puede expandir en silencio después de la firma no es en realidad un documento de alcance.

¿Necesito un documento de alcance para automatizaciones muy pequeñas?

Sí, solo que uno corto. El valor no está en la extensión — está en tener una lista escrita de pruebas de aceptación antes de empezar a construir, para que “terminado” sea una checklist en vez de una sensación. He tenido trabajos pequeños y definidos de manera informal que se alargaron más que otros grandes y bien definidos, exactamente por esta razón.

¿A quién pertenece el documento de alcance en sí — es parte del entregable?

Lo trato como algo que el cliente conserva, sin importar si avanza a un build o no, ya que pagó por la auditoría que lo produjo. Lo que yo conservo es la plantilla y el prompt subyacentes, de la misma forma en que conservo andamiaje reutilizable entre proyectos — la estructura del documento es mía, el contenido completado sobre su negocio específico es suyo.

Próximos pasos: Mi curso de Agentes de IA para Principiantes cubre cómo construir los agentes que describe un documento de alcance como este. El programa cowork es para operadores que quieren un entorno estructurado para practicar la definición de alcance y la construcción de este tipo de trabajo. Si prefieres que te escriba el documento de alcance, reserva una sesión de 30 minutos.