Delegar tareas con IA: criterios de aceptación que evitan retrabajo

Delegar una tarea a un sistema de IA no consiste en escribir una petición extensa ni en encontrar la herramienta más autónoma. Consiste en convertir una necesidad de trabajo en un encargo verificable. La diferencia importa: una respuesta aparentemente útil puede ser inutilizable si no cubre el público, el formato, las fuentes permitidas, los límites de decisión o la revisión necesaria.

El objetivo práctico no es “que la IA haga la tarea”, sino reducir una parte concreta del trabajo sin desplazar el coste hacia la corrección posterior. El ahorro esperado debe tratarse como una hipótesis, no como una promesa: se confirma comparando el tiempo de preparación, revisión y corrección con el proceso anterior.

La unidad de delegación es un resultado aceptable

Una instrucción como “prepara un resumen de clientes” describe una intención, pero deja demasiadas decisiones abiertas. Un encargo delegable define qué debe entregarse y cómo una persona comprobará que sirve. Los criterios de aceptación son precisamente esas condiciones comprobables antes de dar la tarea por terminada.

Esto es especialmente relevante cuando la tarea atraviesa varias aplicaciones. Algunas propuestas de automatización visual permiten combinar integraciones y código personalizado, como describe el repositorio de n8n. En esos flujos, un error pequeño al inicio puede propagarse a una hoja de cálculo, un CRM o una publicación. La automatización no elimina la necesidad de definición: la vuelve más necesaria.

Los siete campos de un encargo útil

1. Resultado: nombra el entregable, no la actividad. Por ejemplo: “tabla de 25 cuentas renovables priorizadas”, no “analiza renovaciones”.
2. Entrada autorizada: indica documentos, campos, fechas y fuentes que puede usar. Añade qué información debe ignorar.
3. Transformación: explica la regla de trabajo: clasificar, extraer, comparar, redactar o preparar un borrador.
4. Formato de salida: define columnas, secciones, idioma, longitud, estructura y ubicación de entrega.
5. Criterios de aceptación: expresa condiciones observables: sin duplicados, con enlace de origen por fila, fechas normalizadas, máximo tres recomendaciones.
6. Límites y escalado: señala qué no puede decidir y cuándo debe parar para pedir confirmación.
7. Revisión humana: determina quién valida, qué muestra revisará y qué ocurre si hay un fallo.

De una petición ambigua a un contrato operativo

Ejemplo: preparar un borrador de publicación

Una delegación débil sería: “Publica este contenido en nuestras redes”. No aclara si se debe publicar o dejarlo preparado, qué cuentas intervienen, qué versión se aprueba ni cómo se confirma el resultado.

Un encargo más seguro podría ser:

Resultado: preparar un borrador para LinkedIn y X a partir del documento indicado.
Entrada: usar solo el documento y los enlaces incluidos en él.
Salida: dos textos, cada uno con llamada a la acción y enlace exacto.
Aceptación: sin afirmaciones no presentes en el documento; tono profesional;
menos de 1.200 caracteres para LinkedIn y menos de 280 para X.
Límite: no publicar ni programar. Si falta el enlace final, detenerse.
Revisión: una persona aprueba ambos textos antes de cualquier envío.

La clave es que “preparar” y “publicar” son estados distintos. Una API de publicación puede devolver identificadores para operaciones asíncronas o programadas y permitir consultar su estado mediante request_id o job_id, según la documentación de Upload-Post. Ese detalle técnico tiene una traducción editorial clara: entregar una solicitud no equivale a verificar un resultado final. El criterio de aceptación debe exigir una comprobación del estado y definir qué estados requieren intervención humana.

Diseña criterios que una persona pueda comprobar rápido

Un buen criterio evita adjetivos vagos como “completo”, “bueno” o “relevante” si nadie ha definido cómo medirlos. Sustitúyelos por pruebas sencillas. No hace falta que sean métricas complejas; basta con que reduzcan la interpretación.

Separa autonomía de autoridad

Una herramienta puede recorrer pasos, conservar contexto y trabajar en un entorno con navegador, archivos y terminal. La documentación de Grok Bot describe este tipo de trabajo de varios pasos y también contempla que ciertos sitios requieran una intervención humana. Pero que un sistema pueda ejecutar una acción no significa que deba tener autoridad para tomarla.

Conviene clasificar cada acción en tres niveles:

• Preparar: recopilar, ordenar, redactar borradores, etiquetar o detectar anomalías. Suele ser el mejor punto de partida.
• Proponer: recomendar una decisión con evidencia y alternativas, sin ejecutarla.
• Ejecutar: enviar, publicar, modificar datos, comprar o eliminar. Requiere reglas más estrictas, permisos mínimos y confirmación cuando el impacto sea relevante.

Este reparto reduce errores caros. Si el resultado puede afectar a clientes, dinero, reputación o datos personales, el criterio no debería ser solo “correcto”: debe incluir evidencia de origen, límite de alcance, responsable de aprobación y trazabilidad de la acción.

Una revisión humana proporcionada al riesgo

Revisarlo todo anula parte del beneficio; no revisar nada convierte la delegación en una apuesta. Diseña una revisión proporcional. Para tareas repetitivas y de bajo impacto, revisa una muestra inicial y los casos señalados como inciertos. Para decisiones con efectos externos, revisa cada salida antes de ejecutar. Para procesos con datos sensibles, limita desde el inicio los datos disponibles y registra qué se ha entregado.

La revisión debe estar incluida en el encargo, no añadirse al final como una costumbre implícita. Especifica qué comprobar: fidelidad a la fuente, campos obligatorios, tono, duplicados, destinatarios, permisos y estado final. Si el sistema no puede demostrar una condición, la salida debe quedar marcada como pendiente y no avanzar.

Cómo mejorar el encargo después de cada ciclo

Empieza con una tarea acotada, no con un proceso entero. Guarda los fallos detectados durante la revisión y conviértelos en reglas explícitas. Si aparecen enlaces rotos, añade “validar que cada URL abre antes de entregar”. Si hay clasificaciones dudosas, crea una categoría “requiere revisión” y prohíbe forzar una decisión. Si el formato llega inconsistente, proporciona una plantilla.

Después de varios ciclos, mide de forma sencilla: tiempo de preparación, tiempo de revisión, número de correcciones y porcentaje de salidas aceptadas sin cambios relevantes. No necesitas atribuir el resultado a la IA con precisión científica para tomar una decisión operativa; necesitas saber si el flujo completo, incluida la supervisión humana, resulta más útil que el anterior.

Delegar bien no es pedir más autonomía. Es fijar un resultado, hacer visibles los límites y decidir de antemano cómo se comprobará que el trabajo está listo.