flowchart TD
A[Usuario define objetivo] --> B[Modelo propone plan]
B --> C{Usuario revisa}
C -->|corrige| B
C -->|autoriza| D[Modelo extrae evidencia]
D --> E[Modelo revisa cobertura]
E --> F{Usuario valida}
F -->|corrige| D
F -->|autoriza| G[Modelo evalúa]
G --> H{Usuario valida evaluación}
H -->|autoriza| I[Modelo prepara síntesis]
Trabajar por etapas
Cómo descomponer una tarea, planificar, ejecutar, revisar y autorizar el siguiente paso sin confundir una conversación controlada con un agente autónomo.
Una instrucción puede ser clara, tener buenos criterios e incluir ejemplos y, aun así, intentar hacer demasiado de una sola vez.
Imaginemos este encargo:
Lee el contrato completo, identifica todas las cláusulas relevantes, verifica si faltan anexos, clasifica los riesgos, compáralos con nuestra política interna, determina qué puntos deben negociarse, propón redacciones alternativas y prepara el informe final para aprobación.La tarea parece completa. El problema es que contiene muchas operaciones dependientes.
Si la aplicación omite una cláusula al comienzo, toda la evaluación posterior puede construirse sobre una base incompleta. Si confunde una política interna con una obligación contractual, la clasificación puede parecer coherente y seguir siendo errónea. Si redacta una recomendación convincente, puede resultar difícil detectar que el error nació tres etapas antes.
Una estrategia para aumentar control consiste en separar el trabajo en productos intermedios observables.
Idea central
Trabajar por etapas significa dividir una tarea compleja en operaciones más pequeñas y revisables.
En este punto del recorrido, la persona sigue controlando el avance: puede aprobar, corregir, detener o pedir información antes de pasar a la siguiente etapa.
Descomponer el problema antes de resolverlo
La primera pregunta no es “¿cuántas etapas debería tener?”, sino:
¿Qué operaciones diferentes contiene realmente la tarea?
En una revisión contractual podemos distinguir, por ejemplo:
1. INVENTARIAR
¿Qué documentos y anexos existen?
2. EXTRAER
¿Qué cláusulas son relevantes?
3. VERIFICAR
¿La evidencia está bien localizada y completa?
4. CLASIFICAR
¿A qué materia corresponde cada hallazgo?
5. EVALUAR
¿Qué impacto o riesgo produce?
6. RECOMENDAR
¿Qué pregunta, negociación o acción corresponde?
7. SINTETIZAR
¿Cómo se comunica el resultado para la decisión?No toda tarea necesita siete etapas. La utilidad de la descomposición está en separar operaciones que requieren criterios distintos o donde un error temprano puede propagarse.
Descomponer no significa revelar razonamiento privado
Existe una distinción importante.
Trabajar por etapas no requiere pedir al modelo que exponga un razonamiento interno exhaustivo o una cadena privada de pensamiento. Para controlar una tarea profesional necesitamos algo más útil: productos intermedios verificables.
Por ejemplo, en vez de pedir:
Muéstrame todo tu razonamiento paso a paso.podemos pedir:
Primero entrega únicamente una tabla con las cláusulas relevantes y su ubicación. No evalúes todavía.Después:
Revisa esa tabla y señala omisiones o errores de ubicación.Y recién entonces:
Evalúa los hallazgos confirmados.Lo importante para el control no es observar cada transición interna del modelo, sino separar entradas, salidas y decisiones entre fases.
1. Planificar
En tareas complejas puede ser útil pedir primero un plan de trabajo.
Antes de analizar el contrato, propón un plan de revisión.
Objetivo final:
obtener una matriz de riesgos y preguntas de negociación.
Condiciones:
- divide el trabajo en etapas pequeñas y revisables;
- indica qué información necesitas en cada etapa;
- indica qué output producirás al final de cada etapa;
- no analices todavía el contrato;
- espera confirmación antes de comenzar.El plan cumple una función: externaliza la arquitectura de la tarea antes de ejecutarla.
La persona puede revisar si:
- falta una materia;
- sobra una etapa;
- se está utilizando un documento incorrecto;
- la secuencia es razonable;
- se ha introducido un criterio que nadie autorizó.
Un plan es una propuesta, no una autoridad
El hecho de que el sistema pueda producir un plan no significa que debamos aceptarlo.
Puede proponer:
Etapa 1: determinar si el contrato es legalmente válido.cuando el objetivo real era una revisión comercial preliminar.
O puede decidir comparar con una “práctica de mercado” que nunca fue entregada como estándar.
Por eso conviene mantener una distinción:
PLANIFICAR
proponer una secuencia
≠
AUTORIZAR
aceptar que esa secuencia gobierne el trabajoEsta separación es una primera forma de gobernanza del proceso.
2. Ejecutar una sola operación por vez
Una vez aprobado el plan, podemos limitar la primera etapa.
Ejecuta únicamente la etapa de extracción.
Localiza cláusulas sobre:
- datos;
- confidencialidad;
- subcontratación;
- propiedad intelectual;
- niveles de servicio;
- responsabilidad;
- terminación.
Para cada una indica:
- documento;
- cláusula o sección;
- fragmento relevante.
No evalúes todavía el riesgo.Esta última frase es crucial.
Si la etapa se denomina extracción, debe producir evidencia, no una evaluación disfrazada.
Separar las tareas permite aplicar criterios propios a cada una.
Criterio de extracción
¿Encontró y localizó correctamente el texto?
Criterio de evaluación
¿La conclusión está razonablemente sustentada?
Son preguntas diferentes.
3. Revisar el producto intermedio
Después de extraer, podemos pedir una segunda lectura dirigida.
Revisa críticamente la extracción anterior.
Comprueba:
1. si cada fragmento está realmente localizado;
2. si se omitieron remisiones a anexos;
3. si una misma materia aparece en otras cláusulas;
4. si existen contradicciones entre documentos;
5. si algún fragmento fue presentado como literal cuando era una paráfrasis.
Devuelve únicamente:
- nuevos hallazgos;
- correcciones;
- omisiones;
- o confirmación razonada de que no detectaste problemas relevantes.Una revisión genérica como:
Revísalo otra vez.puede ayudar, pero sigue dejando abierto qué significa “revisar”.
Como en cualquier prompt, el control mejora cuando el criterio de revisión es explícito.
Revisar por cobertura y revisar por calidad
Podemos distinguir dos funciones.
Revisión de cobertura:
¿Falta algo que debería estar?
Revisión de calidad:
¿Lo que está incluido está correctamente respaldado y clasificado?
En revisión contractual, una segunda pasada de cobertura puede buscar específicamente:
- cláusulas dispersas;
- definiciones relevantes;
- remisiones;
- anexos;
- obligaciones postcontractuales.
Mientras una revisión de calidad puede comprobar:
- evidencia;
- coherencia de clasificación;
- separación entre texto e inferencia;
- justificación del riesgo.
Separar ambas revisiones puede ser más efectivo que pedir simplemente “una segunda revisión”.
4. Autorizar el siguiente paso
Después de revisar la evidencia, la persona puede decir:
Apruebo la extracción corregida.
Continúa con la evaluación de riesgo utilizando exclusivamente los hallazgos confirmados.La palabra apruebo tiene una función arquitectónica: marca una transición.
Hasta ese momento el sistema tenía capacidad para generar análisis, pero no permiso para avanzar dentro del procedimiento que hemos definido.
CAPACIDAD
puede producir la siguiente etapa
≠
PERMISO
está autorizado a hacerlo ahoraEsta diferencia será mucho más importante cuando lleguemos a tools y agentes, pero puede aprenderse ya dentro de una conversación.
5. Ejecutar la evaluación sobre evidencia validada
Ahora podemos cambiar el tipo de trabajo:
Utiliza únicamente los hallazgos confirmados en la etapa anterior.
Para cada uno:
- explica la consecuencia práctica para el cliente;
- clasifica el riesgo como alto, medio o bajo;
- aplica los criterios de impacto, dependencia y dificultad de mitigación;
- identifica información adicional necesaria.
No propongas todavía redacción alternativa.La evaluación ya no tiene que buscar evidencia desde cero. Trabaja sobre un conjunto previamente revisado.
Esto no garantiza corrección, pero reduce el número de operaciones simultáneas.
6. Revisar antes de recomendar
Antes de pasar a propuestas, puede existir otro punto de control:
Audita la evaluación anterior.
Para cada hallazgo comprueba:
- si la clasificación coincide con los criterios;
- si la explicación agrega afirmaciones no respaldadas;
- si falta información capaz de cambiar la categoría;
- si la recomendación posterior requerirá escalamiento humano.Sólo después:
Con las evaluaciones confirmadas, formula preguntas de negociación.Y eventualmente:
Para los puntos expresamente autorizados, propón alternativas de redacción.El trabajo se vuelve una cadena de transformaciones controladas.
La conversación completa
Podemos visualizar una secuencia manual:
Todo sigue ocurriendo dentro de una conversación. El usuario conserva el control de los hitos.
“Autoriza el siguiente paso” como regla de diseño
Los materiales del curso proponen una forma explícita de control:
Trabaja de manera iterativa y controlada.
Reglas de avance:
1. divide el trabajo en etapas;
2. al final de cada etapa, resume lo encontrado;
3. pregunta si debe continuar;
4. no redactes recomendaciones finales antes de validar la evidencia;
5. si falta un documento, detente;
6. si existe una contradicción relevante, no la resuelvas silenciosamente.La lógica es más importante que la fórmula concreta.
Estamos definiendo condiciones de avance.
Cuándo conviene detenerse
Un sistema bien instruido no sólo necesita saber qué hacer. A veces necesita saber cuándo no seguir.
Ejemplos:
Si falta el anexo de tratamiento de datos, detente antes de evaluar privacidad.Si no puedes identificar qué versión del contrato es la vigente, no compares hasta que el usuario lo aclare.Si dos documentos se contradicen respecto del límite de responsabilidad, presenta la contradicción y solicita una decisión humana antes de clasificar el riesgo.Estas reglas son importantes porque la ausencia de información puede ser una condición material del proceso.
Trabajar por etapas reduce propagación de errores
Supongamos que en un proceso de una sola salida ocurre lo siguiente:
error de extracción
↓
clasificación correcta del texto equivocado
↓
evaluación coherente
↓
recomendación convincenteEl resultado final puede parecer sofisticado porque cada etapa posterior fue internamente consistente con una premisa incorrecta.
Separar etapas permite introducir controles entre transformaciones:
extracción
↓
verificación
↓
evaluaciónEsto no elimina errores, pero aumenta la probabilidad de detectarlos antes de que se acumulen.
Trabajar por etapas también aumenta costos
No toda tarea debe dividirse.
La descomposición puede:
- requerir más interacciones;
- consumir más tiempo;
- aumentar contexto;
- generar inconsistencias entre etapas;
- exigir que el usuario mantenga disciplina sobre qué versión está validada.
Para una tarea simple:
Extrae todas las fechas del documento.planificar, ejecutar, revisar y autorizar cuatro fases puede ser absurdo.
La regla vuelve a ser funcional:
divide cuando la separación permita controlar una dependencia o un riesgo que de otro modo quedaría oculto.
Estado: una palabra que comenzará a aparecer
Al trabajar por etapas aparece intuitivamente una idea de estado.
Por ejemplo:
Plan: aprobado.
Extracción: validada.
Evaluación: pendiente.Todavía no necesitamos estudiar formalmente sistemas que mantienen estado. Basta comprender que una tarea de varias etapas depende de saber dónde estamos y qué resultados han sido aceptados.
En una conversación simple, esa información puede mantenerse de manera manual en el historial.
Más adelante veremos arquitecturas donde el estado se vuelve un componente explícito.
Trabajo por etapas ≠ workflow
En lenguaje cotidiano podríamos llamar “flujo” a cualquier secuencia de pasos. Sin embargo, el handbook reserva workflow para una abstracción posterior: una secuencia más formal de estados, condiciones y transiciones.
Aquí estamos aprendiendo la lógica anterior:
una tarea compleja puede descomponerse y el avance puede controlarse.
Todavía no necesitamos construir un workflow como componente del sistema.
Trabajo por etapas ≠ agente
Esta frontera es aún más importante.
En el esquema actual:
modelo propone
↓
persona revisa
↓
persona autoriza
↓
modelo continúaLa persona sigue coordinando la progresión.
Además, según el material del curso, en esta etapa:
- no conectamos APIs;
- no automatizamos herramientas;
- no dejamos al sistema ejecutar acciones externas por sí mismo.
La lógica comienza a parecerse a arquitecturas posteriores, pero el control sigue estando en el usuario.
Un agente, en el marco pedagógico que veremos más adelante, podrá seleccionar dinámicamente ciertas acciones o próximos pasos dentro de límites. Eso es una capacidad distinta.
Caso jurídico completo: revisión de un proveedor de IA
Podemos organizar el caso conductor así.
Etapa A — Inventario
Lista los documentos recibidos y detecta referencias a anexos que no estén disponibles.
No evalúes todavía contenido contractual.Etapa B — Extracción
Extrae cláusulas sobre datos, confidencialidad, SLA, cambios del servicio, subcontratación, responsabilidad y terminación.Etapa C — Control de cobertura
Realiza una segunda lectura buscando cláusulas dispersas, definiciones o remisiones que cambien los hallazgos.Hito humano
No avances hasta que la extracción haya sido validada.Etapa D — Evaluación
Clasifica cada hallazgo según criterios previamente definidos.Hito humano
Marca los puntos que requieren escalamiento o información adicional.Etapa E — Preparación de negociación
Formula preguntas concretas para la contraparte sobre los hallazgos aprobados.Etapa F — Síntesis
Prepara una matriz final para decisión humana. No adoptes la decisión de aprobación.La potencia del método proviene menos del número de etapas que de su separación funcional.
Qué debes recordar
Trabajar por etapas permite convertir una tarea grande en operaciones más fáciles de inspeccionar.
La secuencia pedagógica central es:
DESCOMPONER
↓
PLANIFICAR
↓
EJECUTAR
↓
REVISAR
↓
AUTORIZARNo se trata de obligar al modelo a narrar todo su razonamiento interno. Se trata de producir artefactos intermedios verificables y controlar las transiciones entre ellos.
La persona sigue teniendo un papel decisivo: corrige contexto, valida evidencia, decide cuándo continuar y conserva autoridad sobre la decisión profesional final.
El problema que todavía queda abierto
Las etapas producen información intermedia. Si queremos comparar veinte hallazgos, reutilizarlos, pasarlos a una planilla o entregarlos a otro componente, el texto libre comienza a ser incómodo.
Necesitamos controlar no sólo qué debe decir la respuesta, sino también cómo deben quedar representados sus datos.
El siguiente nodo estudia tablas, Markdown, JSON, XML y schemas, junto con una advertencia fundamental: una estructura formalmente correcta puede contener información falsa.