Por La unidad de control es la tarea
Un panel con robots animados puede ayudar a entender un sistema, pero la animación no demuestra ejecución. Mi criterio de diseño es que cada cambio visual represente un estado respaldado por un evento: tarea recibida, ejecución iniciada, resultado generado o revisión solicitada.
El registro de una tarea debería identificar el encargo, su responsable, los datos autorizados, el resultado esperado y el criterio de aceptación. La fecha de actualización y el motivo de un bloqueo permiten distinguir trabajo activo de una operación que dejó de avanzar.
En Oficina Viva exploro esta relación entre organización del trabajo y seguimiento de agentes. El vídeo y la descripción del proyecto delimitan lo demostrado; las recomendaciones de este artículo amplían el criterio de diseño y no implican que todas estén implementadas en ese sistema.
Estados que expliquen qué sucede
Propongo una máquina de estados explícita. Cada transición debe tener una causa y conservar una referencia a la ejecución. Por ejemplo:
- Pendiente
- En ejecución
- Requiere revisión
- Aprobada
- Completada
También hacen falta estados de bloqueo, fallo y cancelación. Una tarea bloqueada debería explicar si falta un dato, un permiso o una dependencia. «En ejecución» no debe mantenerse indefinidamente después de perder el contacto con el proceso que la ejecuta.
Cuando se reintenta una operación, conviene conservar los intentos por separado y vincularlos al mismo encargo. Así se puede investigar un fallo sin confundir el nuevo intento con una tarea adicional.
Permisos proporcionales a la acción
Preparar un borrador, enviar un correo y modificar un registro contable tienen consecuencias diferentes. La autorización debe evaluarse sobre la acción concreta y los datos que afectará, antes de ejecutarla.
OWASP describe la autonomía excesiva como un riesgo asociado a demasiadas funciones, permisos o capacidad de actuar. Entre sus mitigaciones incluye reducir herramientas y privilegios y exigir aprobación humana para acciones de alto impacto. Referencia: OWASP, Excessive Agency.
Mi propuesta práctica es una revisión que muestre destinatario, contenido, cambios y alcance. Si esos elementos cambian después de aprobar, la autorización debe volver a evaluarse. La aprobación de un borrador no equivale por sí sola a permiso para publicarlo.
Probar fallos antes de ampliar la autonomía
Una evaluación útil necesita entradas, resultados esperados y criterios de rechazo definidos antes de ajustar instrucciones. Esta matriz ilustra una base de pruebas; no presenta resultados medidos de una implementación.
| Escenario | Comportamiento esperado |
|---|---|
| Falta un dato obligatorio | Solicitarlo o bloquear la tarea; no inventarlo para completar la respuesta. |
| La herramienta agota el tiempo | Registrar el fallo y aplicar una política limitada de reintentos, con espera. |
| La misma tarea llega dos veces | Reconocer la identidad del encargo y evitar duplicar el efecto externo. |
| Un documento ordena ignorar las reglas | Tratar esa instrucción como contenido no confiable, sin ampliar permisos. |
| Se modifica un resultado aprobado | Solicitar una nueva revisión antes de ejecutar el cambio. |
Además de la calidad de la respuesta, mediría tareas aceptadas, correcciones humanas, latencia, fallos de herramientas y coste por tarea. Los umbrales deberían acordarse según el impacto del proceso; una sola tasa de acierto no describe todos esos riesgos.
IA local y trazabilidad con límites claros
La inferencia local permite decidir dónde se ejecuta el modelo. La confidencialidad también depende de permisos, herramientas, registros, copias de seguridad y conexiones externas. Por eso describiría la arquitectura y los flujos de datos, en lugar de presentar «local» como una garantía absoluta.
Para investigar una tarea, propondría conservar identificadores, versiones de instrucciones, herramientas utilizadas, estados, tiempos y decisiones de aprobación. Los registros deben minimizar datos sensibles y tener controles de acceso y retención. No necesitan capturar razonamientos internos del modelo para mostrar qué acciones ocurrieron.
Aplicarlo a la distribución del trabajo
Una cola visible permite comparar pendientes, bloqueos y capacidad disponible. El número de tareas por sí solo no mide la carga: importa la complejidad, la prioridad, las dependencias y el tiempo esperado. Para un equipo humano añadiría esos factores y un mecanismo para que la persona explique impedimentos.
El objetivo de mi propuesta es que quien coordina tenga contexto para decidir, y quien ejecuta tenga un encargo claro. Una interfaz de seguimiento aporta valor cuando sus estados corresponden a hechos observables y sus permisos corresponden a decisiones explícitas.