Elegir el patrón y el grado de autonomía

Saber que un paso necesita interpretación no decide todavía cuánto debe delegarse. La misma capacidad puede aparecer como ayuda puntual para una persona, como paso dentro de un workflow o como herramienta de un agente que decide qué hacer después.

Elegirás el patrón menos autónomo que pueda cumplir el objetivo. La autonomía no es una recompensa por utilizar una tecnología más avanzada: debe justificarse por la variabilidad del trabajo, la posibilidad de comprobar resultados y las consecuencias de actuar.

Una escala de autonomía

Utiliza cinco niveles conceptuales. No representan productos concretos y pueden combinarse dentro del mismo proceso.

1. Asistencia

El sistema prepara información, una clasificación, un resumen o un borrador. Una persona decide qué hacer y ejecuta o aprueba la acción.

Encaja cuando:

• el volumen permite revisión;
• la decisión necesita contexto profesional;
• el coste de un error es relevante;
• el objetivo inicial es aprender;
• la salida puede acelerar el trabajo sin ocultar responsabilidad.

Ejemplo hipotético: generar un borrador de comentario para un informe mensual. El responsable contrasta datos, corrige interpretación y aprueba el texto.

2. Workflow

Un workflow coordina pasos con rutas y controles definidos. Puede incluir reglas, integraciones, personas y llamadas a modelos.

En la taxonomía técnica publicada por Anthropic, un workflow sigue rutas de código predefinidas. Es adecuado cuando puedes anticipar:

• estados;
• orden de actividades;
• condiciones de paso;
• responsables;
• excepciones principales;
• criterio de finalización.

Ejemplo hipotético: recibir una factura, clasificarla, extraer campos, validarlos, enviarla a revisión si falta información y registrar el resultado en el ERP.

3. RAG

Un flujo RAG estándar recupera información de una fuente, prepara los resultados como contexto y los envía junto con la consulta al modelo para generar la respuesta.

Su función es responder o asistir utilizando documentación concreta. No ejecuta necesariamente acciones y no convierte una base documental desordenada en conocimiento fiable por sí sola.

Encaja cuando:

• las respuestas dependen de fuentes internas identificables;
• el usuario necesita localizar evidencia;
• la documentación puede prepararse, actualizarse y gobernarse;
• existe un conjunto de preguntas para evaluar recuperación y respuesta.

No es necesario cuando toda la información relevante cabe en el contexto directo de una tarea puntual, cuando solo se necesita búsqueda sin generación o cuando la fuente estructurada puede consultarse mediante una regla.

4. Agente

En esa misma taxonomía, un agente dirige dinámicamente su proceso y el uso de herramientas. Puede decidir qué pasos ejecutar, qué fuente consultar o si necesita repetir una acción. Es una distinción útil para esta decisión, no una nomenclatura universal de la industria.

Encaja mejor en problemas abiertos donde no puede fijarse de antemano una única secuencia y donde existen herramientas seguras, observación del resultado y condiciones claras de parada.

Un agente añade flexibilidad, pero también puede añadir latencia, coste, rutas difíciles de anticipar y una superficie mayor de error. Aumenta la complejidad solo cuando una solución más simple no alcance el resultado.

5. Automatización completa

El sistema ejecuta el proceso o una parte del proceso sin aprobación caso por caso. No significa que opere sin límites: necesita reglas, permisos, registros, monitorización y una forma de tratar excepciones.

Encaja cuando:

• las entradas y salidas están bien definidas;
• el comportamiento se ha evaluado en condiciones representativas;
• los errores son detectables y recuperables;
• existe un responsable operativo;
• la acción no supera el riesgo aceptado;
• hay una ruta de parada y escalado.

Aplica un filtro provisional de autonomía

Cruza dos dimensiones:

La tabla solo fija un punto de partida. La lección 6 desarrollará el riesgo y los controles; aquí basta con reducir autonomía cuando el error tenga consecuencias relevantes o no pueda detectarse a tiempo.

Workflow frente a agente

La distinción no depende de que el sistema utilice un modelo.

Un workflow puede incluir varios modelos y seguir siendo un flujo predefinido. Un agente puede utilizar una sola herramienta y decidir dinámicamente cuándo llamarla.

Elige workflow cuando:

• el proceso puede descomponerse en pasos estables;
• necesitas trazabilidad predecible;
• existen validaciones claras entre fases;
• el coste y la latencia deben controlarse;
• las excepciones principales pueden enrutar a una persona.

Considera un agente cuando:

• el número y orden de pasos dependen de cada caso;
• la tarea exige explorar, comprobar y adaptar el plan;
• las herramientas tienen interfaces y permisos bien definidos;
• el sistema puede observar resultados reales;
• existen límites de iteraciones, coste, tiempo y acciones.

«Parece más inteligente» no es un criterio suficiente.

RAG frente al uso directo de un modelo

El uso directo de un modelo puede bastar para transformar información aportada en la propia solicitud: resumir un documento adjunto, reescribir un texto o clasificar una entrada con criterios incluidos.

RAG añade una capa de recuperación. Tiene sentido cuando la respuesta depende de seleccionar información desde un corpus mayor o actualizado y cuando conservar la referencia a las fuentes aporta valor.

Antes de elegir RAG, pregunta:

• ¿Qué fuentes contiene el conocimiento?
• ¿Quién puede acceder a cada una?
• ¿Cómo se actualizan?
• ¿Qué debe ocurrir cuando no se recupera evidencia suficiente?
• ¿Necesitamos respuesta generada o basta mostrar documentos relevantes?

La búsqueda sin generación puede ser la solución más controlable para ciertos usos.

Trata cloud, API o local como un factor

La ubicación no decide por sí sola la privacidad ni la viabilidad. Registra qué datos se tratarían, finalidad, permisos, retención, condiciones contractuales, latencia, disponibilidad y capacidad de operación. Un despliegue local puede reducir determinadas transferencias, pero sigue necesitando controles sobre accesos, registros, copias y seguridad; una API exige evaluar sus propias condiciones y riesgos. El Privacy Framework de NIST orienta este análisis hacia los riesgos del tratamiento, no hacia una garantía automática asociada a la ubicación.

No selecciones despliegue hasta conocer los datos y sistemas reales. Esa comprobación corresponde a la siguiente lección.

Ejemplo hipotético: documentación interna

Una empresa quiere responder preguntas sobre manuales operativos.

• Asistencia: una persona adjunta un manual y pide un resumen.
• Workflow: la consulta se clasifica, se busca en una fuente concreta y la respuesta se envía a revisión si falta evidencia.
• RAG: el sistema recupera fragmentos de varios manuales autorizados y prepara una respuesta con referencias.
• Agente: el sistema decide qué repositorios consultar, formula búsquedas sucesivas y compara resultados antes de responder.
• Automatización completa: además de responder, el sistema ejecuta una acción sin aprobación.

La necesidad declarada es consultar documentación. Un RAG estándar o incluso una búsqueda pueden bastar. Añadir un agente solo se justificaría si las consultas requieren rutas variables y múltiples herramientas. Ejecutar acciones pertenece a otra decisión.

Aplicación: fija el nivel máximo permitido

Para cada paso con IA, completa:

1. Salida que prepara.
2. Acción que podría ejecutar.
3. Consecuencia si se equivoca.
4. Persona responsable.
5. Evidencia que puede comprobarse.
6. Nivel inicial: asistencia, workflow, RAG, agente o automatización completa.
7. Acción expresamente prohibida.
8. Condición que permitiría aumentar autonomía.

Después redacta una frase:

Elegimos este nivel porque resuelve la variabilidad necesaria y conserva control sobre estas consecuencias.

Si la explicación se apoya solo en comodidad o novedad, reduce autonomía.

Límite de autonomía que queda registrado

Añade:

• patrón propuesto;
• nivel de autonomía inicial;
• acciones permitidas;
• acciones prohibidas;
• punto de revisión o aprobación;
• fuentes que necesitaría un RAG;
• herramientas que necesitaría un agente;
• factores que podrían justificar API, cloud o local;
• condición para aumentar o reducir autonomía.

La propuesta sigue siendo conceptual. Ahora debes contrastarla con los datos, accesos, sistemas e integraciones que realmente existen.