flowchart LR
A[Objetivo] --> B[Generar plan]
B --> C[Validar plan]
C --> D{¿Plan aceptable?}
D -- No --> B
D -- Sí --> E[Ejecutar]
E --> F[Evaluar resultado]
Agente planificador
Cómo un agente transforma un objetivo amplio en subtareas, selecciona estrategias, evalúa resultados y modifica el plan cuando cambian las condiciones.
El agente de workflow parte de una ventaja importante: la organización ya conoce la estructura general del proceso.
Pero no todos los problemas profesionales llegan con una ruta suficientemente definida.
Consideremos el encargo:
“Prepara los antecedentes necesarios para decidir si deberíamos contratar este proveedor de IA.”
¿Qué debe ocurrir primero?
¿Revisar el contrato?
¿Entender la arquitectura del producto?
¿Buscar el DPA?
¿Determinar qué datos utilizará?
¿Revisar seguridad?
¿Comparar precios?
La tarea contiene un objetivo, pero no necesariamente una secuencia completa.
Aquí aparece el agente planificador.
Idea central
Un agente planificador agrega una capacidad específica:
descomponer un objetivo amplio en subtareas y decidir cómo organizarlas.
En el marco del curso, su ciclo puede resumirse así:
descomponer → crear subtareas → elegir estrategia → evaluar resultados → replanificar.
Planificar no equivale a ejecutar libremente. Un buen diseño puede separar el plan de la ejecución y validar antes de actuar.
Del “haz esto” al “averigua cómo hacerlo”
Un workflow recibe una ruta.
Un planificador debe construir una.
Comparemos.
Workflow
1. revisar contrato
2. revisar DPA
3. revisar seguridad
4. pedir aprobaciónPlanificador
Objetivo:
preparar decisión sobre proveedor
Preguntas:
- ¿qué necesito saber?
- ¿qué información tengo?
- ¿qué dependencias existen?
- ¿qué acción desbloquea la siguiente?El plan no debería ser una lista ornamental.
Debe establecer una estrategia de resolución.
1. Descomponer objetivos
Un objetivo amplio suele contener varias operaciones.
Por ejemplo:
“Evalúa si el proveedor es aceptable.”
Una descomposición útil podría ser:
A. entender el producto
B. identificar datos y finalidades
C. revisar arquitectura y dependencias
D. analizar contrato
E. revisar seguridad
F. comparar con criterios internos
G. identificar pendientes
H. preparar recomendación preliminarUna buena descomposición reduce dependencia oculta
Supongamos que el agente intenta evaluar el contrato antes de saber qué servicio se está contratando.
Puede interpretar mal cláusulas de:
- disponibilidad;
- tratamiento de datos;
- propiedad intelectual;
- salida.
La descomposición correcta reconoce dependencias:
entender servicio
↓
identificar riesgos relevantes
↓
seleccionar documentación
↓
analizarPlanificar significa también descubrir qué debe ocurrir antes de qué.
2. Crear subtareas
Una categoría amplia como “revisar privacidad” todavía puede ser demasiado grande.
El planificador puede crear subtareas más concretas:
- localizar DPA
- identificar roles de tratamiento
- extraer finalidades
- identificar subprocesadores
- revisar transferencias
- detectar retención
- comparar contra estándar internoCada subtarea debería tener un producto observable.
Por ejemplo:
Subtarea: identificar subprocesadores.
Producto: lista de entidades + función + fuente documental + estado de confirmación.
Subtareas demasiado pequeñas
La planificación también puede fallar por exceso de granularidad.
Dividir una revisión en cientos de microacciones aumenta:
- costo;
- latencia;
- posibilidades de error;
- complejidad de coordinación.
El nivel adecuado depende de la tarea.
3. Elegir estrategias
Un objetivo puede alcanzarse por rutas distintas.
Huyen utiliza ejemplos donde dos planes son correctos, pero uno es más eficiente que otro.
En trabajo jurídico también ocurre.
Pregunta:
“¿Qué contratos contienen una cláusula que se aparta del estándar actual?”
Estrategia A:
- revisar manualmente todos los contratos;
- extraer cada cláusula;
- comparar una por una.
Estrategia B:
- identificar primero contratos de la categoría relevante;
- recuperar sólo cláusulas del tema;
- comparar con estándar.
Ambas podrían funcionar.
La segunda puede ser más eficiente.
La estrategia depende de herramientas y restricciones
Un plan no puede exigir capacidades inexistentes.
Si el agente propone:
“buscar en la base jurídica X”
pero no tiene acceso a esa base, el plan es inválido.
Por eso la planificación debe conocer:
- inventario de herramientas;
- permisos;
- límites de fuentes;
- tiempo;
- costo;
- criterios de cierre.
Separar planificación y ejecución
Ésta es una de las ideas más importantes de Huyen para sistemas agentivos.
Podemos pedir al modelo:
“piensa el plan y ejecútalo de inmediato.”
Pero si genera un plan defectuoso de cincuenta pasos, el sistema puede gastar tiempo y recursos antes de descubrir el error.
Una alternativa es:
La separación permite detener un plan inválido antes de ejecutar acciones.
Validaciones simples
Podemos comprobar:
- ¿usa sólo herramientas existentes?;
- ¿respeta permisos?;
- ¿omite una etapa obligatoria?;
- ¿tiene demasiados pasos?;
- ¿viola una restricción?;
- ¿incluye una condición de término?;
No todo requiere otro modelo.
Algunas validaciones pueden ser deterministas.
4. Evaluar resultados
Un plan no termina cuando una herramienta devuelve algo.
El agente debe determinar si la subtarea realmente avanzó el objetivo.
Supongamos:
Subtarea: localizar DPA.
Resultado:
archivo encontrado: privacy-policy.pdf¿Se completó la subtarea?
No necesariamente.
El sistema debe comprobar si el archivo es efectivamente el DPA.
Evaluación de progreso
Después de cada subtarea puede preguntar:
1. ¿Se obtuvo el producto esperado?
2. ¿La evidencia es suficiente?
3. ¿Apareció información nueva?
4. ¿El plan sigue siendo válido?
5. ¿Existe un bloqueo?La evaluación convierte planificación en un proceso adaptativo.
5. Replanificar
La realidad puede invalidar el plan inicial.
Ejemplo:
Plan original:
1. revisar producto
2. revisar privacidad
3. revisar seguridad
4. revisar contrato
5. consolidarNueva observación:
El proveedor no entrega DPA y utiliza un subprocesador no identificado.
El agente puede actualizar:
1. registrar falta de DPA
2. solicitar o buscar documento
3. suspender conclusión de privacidad
4. revisar impacto del subprocesador
5. escalar si no existe información suficienteReplanificar no significa cambiar la política
El sistema adapta la trayectoria.
No debería inventar nuevos criterios sustantivos.
Si el estándar interno exige DPA, replanificar puede significar buscarlo o escalar.
No significa concluir:
“El DPA no es necesario porque dificulta completar la tarea.”
La flexibilidad opera dentro de límites.
Un caso completo: proveedor de IA
Objetivo:
“Preparar decisión preliminar sobre un nuevo proveedor de IA.”
Plan inicial
1. entender producto y uso previsto
2. identificar documentos disponibles
3. revisar tratamiento de datos
4. revisar seguridad y continuidad
5. revisar contrato y términos
6. identificar desviaciones
7. preparar preguntas y puntos abiertos
8. entregar expediente a decisión humanaEjecución de subtarea 1
Resultado:
El producto analiza documentación de clientes y genera recomendaciones.
Consecuencia:
La criticidad de datos aumenta.
Ejecución de subtarea 2
Resultado:
Contrato: sí
DPA: no
Seguridad: parcial
Lista de subprocesadores: enlace rotoEvaluación
El planificador detecta que no puede completar privacidad ni seguridad con evidencia suficiente.
Replanificación
A. buscar DPA en portal del proveedor
B. verificar enlace alternativo de subprocesadores
C. preparar solicitud de documentación
D. continuar sólo con análisis contractual no dependiente
E. marcar privacidad y seguridad como pendientesLa planificación permitió continuar donde era razonable y detener conclusiones donde faltaba evidencia.
Fallas de planificación
Huyen identifica varios modos de falla que conviene traducir al contexto jurídico.
Herramienta inválida
El plan utiliza una fuente o función a la que no existe acceso.
Parámetros incorrectos
Busca el expediente o jurisdicción equivocada.
Falla de objetivo
El plan produce un informe detallado, pero no responde a la decisión que se necesitaba apoyar.
Violación de restricciones
Cumple la tarea, pero utiliza fuentes no autorizadas o supera un límite.
Falsa finalización
El agente concluye que terminó cuando todavía quedan asuntos abiertos.
Este último riesgo es especialmente importante.
Un informe bien escrito puede ocultar que:
- faltaron documentos;
- una subtarea nunca se ejecutó;
- se ignoró una excepción;
- no se alcanzó el criterio de cierre.
El criterio de cierre debe formar parte del plan
Un plan sin condición de término puede seguir iterando o detenerse demasiado pronto.
En nuestro caso podríamos exigir:
Cerrar sólo cuando:
- todos los documentos mínimos estén encontrados o marcados como faltantes;
- cada área tenga estado;
- cada hallazgo material tenga evidencia;
- los puntos de riesgo alto estén escalados;
- la decisión final quede reservada a la persona competente.La planificación no consiste solamente en decidir qué hacer.
También debe saber qué cuenta como suficientemente hecho.
Cuándo no conviene usar un planificador
Las clases advierten que no conviene utilizarlo cuando:
- el criterio jurídico no está definido;
- la acción no admite supervisión.
Podemos ampliar la intuición.
Tampoco aporta mucho cuando:
- la ruta ya es fija;
- el problema puede resolverse con pocas reglas;
- el costo de variabilidad supera el beneficio;
- no podemos evaluar planes intermedios.
Un planificador no debe reemplazar un workflow claro sólo porque parece más sofisticado.
Planificador y persona
La planificación puede distribuirse entre sistema y humano.
Por ejemplo:
AGENTE
propone plan
HUMANO
aprueba o modifica
AGENTE
ejecuta subtareas permitidas
HUMANO
interviene en puntos críticosEsto puede ser especialmente apropiado durante las primeras etapas de adopción, cuando todavía estamos aprendiendo qué planes funcionan.
Qué hace que un plan sea bueno
No basta con que un plan contenga muchos pasos. Para ser útil debería satisfacer varias condiciones.
Pertinencia: las subtareas deben contribuir realmente al objetivo.
Ejecutabilidad: deben existir herramientas, fuentes y permisos para realizarlas.
Orden: las dependencias deben respetarse.
Proporcionalidad: el plan no debería utilizar veinte pasos cuando cuatro son suficientes.
Control: debe incluir puntos de validación y una condición de término.
Adaptabilidad: debe permitir cambiar cuando nueva evidencia invalida una suposición inicial.
Podemos convertir esas condiciones en una revisión previa:
| Pregunta | Falla que intenta evitar |
|---|---|
| ¿Cada paso aporta al objetivo? | trabajo irrelevante |
| ¿Tengo los medios para ejecutarlo? | plan imposible |
| ¿El orden respeta dependencias? | análisis prematuro |
| ¿El costo es razonable? | sobreplanificación |
| ¿Sé cómo comprobar avance? | falsa finalización |
| ¿Sé cuándo escalar? | autonomía excesiva |
Plan local versus plan completo
Un planificador no siempre necesita diseñar todo el encargo desde el comienzo.
Puede trabajar con planificación local:
objetivo general
↓
plan para la próxima subtarea
↓
ejecución
↓
nueva observación
↓
nuevo plan localEsta aproximación puede ser preferible cuando la tarea depende intensamente de información que todavía no se conoce.
Por ejemplo, intentar planificar veinte pasos de una revisión contractual antes de abrir los anexos puede producir un plan ficticio. Puede ser mejor decidir primero cómo identificar documentación, observar el resultado y recién entonces planificar la revisión sustantiva.
La planificación puede, por tanto, ser jerárquica: objetivo general estable, planes locales que se ajustan a medida que aparece información.
El costo de planificar demasiado
Los agentes consumen recursos cada vez que llaman modelos o herramientas. Una planificación que genera múltiples alternativas, evaluaciones y replanteamientos puede mejorar calidad, pero también aumentar latencia y costo.
Huyen destaca precisamente este intercambio: generar varios planes y elegir el mejor puede ser útil, pero exige más llamadas.
En un contexto jurídico conviene preguntar:
¿el valor de una planificación más sofisticada justifica el costo y la complejidad para esta tarea?
Una revisión rutinaria puede necesitar un workflow. Una investigación estratégica y no estructurada puede justificar planificación más flexible.
La persona como validador de estrategia
No toda intervención humana tiene que ocurrir al final.
Una persona puede revisar el plan antes de que empiece una ejecución costosa o sensible.
Por ejemplo:
PLAN PROPUESTO
1. revisar contrato
2. consultar web pública
3. contactar proveedor
4. preparar recomendaciónEl revisor puede responder:
“No contactes al proveedor todavía. Limita las fuentes a documentos internos y términos oficiales. Agrega revisión de seguridad antes de preparar recomendación.”
La intervención modifica la estrategia, no simplemente el texto final.
Esto puede ser una forma de control especialmente valiosa durante la adopción inicial de agentes planificadores.
Qué debes recordar
El agente planificador aparece cuando el objetivo está claro, pero la ruta concreta no puede definirse completamente de antemano.
Sus cinco funciones centrales son:
descomponer objetivos → crear subtareas → elegir estrategias → evaluar resultados → replanificar.
Un buen diseño no confunde planificación con libertad ilimitada.
El plan debe respetar herramientas, fuentes, permisos, criterios y condiciones de término.
Y, cuando el impacto lo justifica, puede validarse antes de ejecutarse.
El problema que todavía queda abierto
Hasta ahora hemos supuesto principalmente un agente que mantiene el objetivo general y organiza su propio trabajo.
Pero una tarea grande puede beneficiarse de especialización.
En vez de pedir a un único agente que investigue, analice, redacte y critique, podríamos distribuir esas funciones.
La siguiente página introduce los sistemas multiagente: coordinación común, división de trabajo y revisión cruzada entre especialistas.