En los últimos dos años, la empresa ha adquirido numerosas herramientas de IA: asistentes de chat, complementos de escritura, robots de atención al cliente y sistemas de preguntas y respuestas internos. Sin embargo, las capacidades realmente consolidadas son escasas. Los prompts siguen almacenados en los ordenadores personales, los flujos de trabajo están dispersos por los rincones de los documentos, tras la puesta en marcha de los agentes inteligentes falta retroalimentación y revisión, y los miembros clave del equipo siguen viendo sus horas ocupadas por el mismo tipo de consultas. El problema a menudo no es que el modelo no sea lo suficientemente inteligente, sino que el sistema de no ha diseñado el «trabajo» como una competencia laboral gestionable .
Primero desglosamos: ¿por qué la ventana de chat no puede considerarse un puesto de trabajo?
El robot de chat responde a una pregunta y luego termina. Un puesto de trabajo debe asumir tareas de forma continua: recopilar información, aplicar reglas, acceder a los sistemas, actualizar el estado y, ante excepciones, elevar el caso. El reembolso de viajes es un ejemplo típico: el usuario puede comenzar diciendo «Ayúdame a tramitar el reembolso de viaje», interrumpirse para preguntar «¿Cuánto queda de mi límite este mes?» y luego añadir una factura más tarde. Si el sistema trata cada conversación como una nueva sesión, el flujo se rompe, se pierde el contexto y, posteriormente, resulta imposible analizar si el error proviene de la regla o de la interfaz.
En el sector ya existe la práctica de construir agentes como «empleados digitales»: se les asigna un puesto, un número de empleado, límites de capacidad y registros de trabajo, junto con SOPs modificables, bases de conocimiento, herramientas y rutas de ejecución. Desde la perspectiva del código abierto, plataformas como StaffDeck, publicadas por organizaciones como OpenBMB, presentan a los agentes como conjuntos de recursos operativos, en lugar de simples fragmentos de prompts. Para las empresas que desarrollan o personalizan soluciones propias, lo valioso no es el nombre del producto, sino este modelo de objetos.
Lógica empresarial: en el sistema deben existir al menos siete tipos de objetos
Al crear un sistema de empleados digitales, primero hay que definir los objetos del negocio en las especificaciones y luego abordar la selección del modelo.
- Archivo del puesto : nombre o rol, número de empleado, responsabilidades, estado en línea, destinatarios del servicio. Sin este archivo, no hay dónde vincular permisos ni evaluaciones.
- Límites de capacidad : qué documentos pueden leer, qué campos pueden escribir y qué promesas no pueden hacer. Estos límites deben poder ser modificados por el administrador, no quedar fijos en los prompts.
- SOP / Habilidades basadas en procesos : descomponer los procesos complejos en nodos, admitiendo ramificaciones condicionales, llamadas a herramientas, búsqueda de conocimientos y transferencia a humanos.
- Ontología del conocimiento : temas, reglas, fuentes y manuales de operación se almacenan por separado; las respuestas deben poder remitir a su fuente y las búsquedas deben permitir ajustes.
- Integración de herramientas : interfaces HTTP o MCP para consultar límites, crear documentos y actualizar estados, en lugar de limitarse a generar un simple texto.
- Tareas programadas : resúmenes diarios, recordatorios por retrasos, inspecciones de inventario y otras actividades periódicas no pueden esperar a que el usuario hable primero.
- Rastreo y retroalimentación : registrar rutas, pasos, herramientas, conocimientos y respuestas; los me gusta, los comentarios negativos y la intervención humana dan paso a la siguiente ronda de revisión.
Una solicitud real suele incluir múltiples tareas. El empleado digital debe poder entrar primero en el SOP de reembolso, reunir todos los campos y aplicar las reglas correspondientes, para luego cambiar al SOP de consulta de límites y llamar a la interfaz. Si el usuario interrumpe con una pregunta sobre políticas, debe guardarse el nodo actual y volver al flujo original una vez respondida. Ante preguntas fuera de las reglas, el contexto debe entregarse al creador o al encargado de turno, prohibiéndose responder sin fundamento.
Lógica de diseño: roles, máquinas de estados y jerarquía del conocimiento
Cómo cambiar de rol
Hay que distinguir al menos cuatro tipos de personas: creadores (que formalizan la experiencia en los empleados), administradores (que gestionan permisos, lanzamientos y cuotas), usuarios (que asignan tareas a los empleados digitales) y encargados de turno (que atienden excepciones). Los creadores no deben tener por defecto autorización para modificar inventarios o precios; los usuarios tampoco deben ver los prompts completos ni las claves secretas. Las interfaces abiertas también deben estar jerarquizadas: las claves a nivel de cuenta controlan la asignación de recursos, mientras que las claves a nivel de empleado solo permiten crear sesiones y consultar su propio historial.
Los SOPs deben usar máquinas de estados, no limitarse a la memoria de conversación
El lenguaje natural puede generar un borrador inicial, pero la ejecución debe seguir una máquina de estados: nodo actual, slots recopilados, herramientas disponibles, intentos fallidos, nodos humanos. Cuando una tarea se interrumpe, debe ser posible serializar el contexto y retomar desde el punto original. Varios SOPs permiten cambiar en tiempo real, pero al hacerlo debe conservarse la información de «de dónde venimos y qué información confirmada traemos», evitando que el usuario vuelva a llenar formularios. Las versiones y ramas deben ser reversibles; si se modifica un solo prompt en el sitio, la implementación se activa inmediatamente, pero luego será imposible rastrear responsabilidades.
No conviene convertir el conocimiento en una gran mezcla para la búsqueda
Construir índices navegables según documentos, capítulos, páginas y resúmenes; primero determinar en qué categoría podría encontrarse la información y luego localizar el texto original. Clasificar el conocimiento en compartimentos: normativas, descripciones de productos, discursos postventa y casos excepcionales separados; la búsqueda dirigida es más estable que las palabras clave generales. Cada respuesta debe estar vinculada a su fuente, reglas y tema comercial; en el entorno de pruebas debe ser posible ver «por qué se ha seleccionado este fragmento». Ajustar la búsqueda suele resolver problemas mejor que cambiar a un modelo aún más grande.
Desarrollo e implementación: interfaces, aislamiento, observación y aceptación
Durante la operación, se recomienda un acceso unificado para evitar que cada habilidad siga su propio camino y cause desviaciones en el estado. La detección de capacidades, la ejecución aislada, la integridad de los artefactos y la contabilidad de cuotas deben completarse durante la operación, no mediante acuerdos previos. Antes de lanzar una habilidad al mercado interno, realizar un escaneo de permisos: no deben aparecer claves de autenticación, variables de entorno ni credenciales de conexión en las interfaces de lectura ordinaria.
- Canal de ejecución : el flujo sincrónico es adecuado para conversaciones; el flujo asíncrono Run + Event Stream conviene para la continuación tras desconexiones y las colas de tareas, ambos comparten el mismo núcleo.
- Identidad del canal : WeChat, WeChat Work, Feishu y DingTalk pueden servir como puertas de entrada, pero la identidad del empleado, las sesiones y el rastreo deben unificarse; está prohibido que cada canal mantenga su propia memoria.
- Seguridad : la configuración del modelo solo debe referirse a números de configuración existentes, sin devolver claves del proveedor; los resultados de las herramientas deben someterse a desidentificación antes de ingresar al rastreo.
- Respaldo humano : en casos de retrasos, baja confianza, violación de autoridad o cuando el usuario solicita intervención humana, las cuatro situaciones deben permitir la transferencia completa del contexto.
La aceptación no debe limitarse a probar «capacidad de conversación». Proporcionar un conjunto de scripts repetitivos: ciclo cerrado normal, preguntas intermedias, límites insuficientes, tiempos de espera en las interfaces, escritura fuera de autoridad y respuestas sin fuente. Verificar cada script: si los nodos se han recuperado, si los documentos se han redactado correctamente, si el rastreo está completo y si las excepciones han sido asignadas a personas. La tasa de aprobación en las pruebas, la tasa de manejo de retrasos y el número de respuestas sin fundamento son indicadores más adecuados que las estrellas de satisfacción para decidir la apertura oficial.
Orden de lanzamiento: primero una fase de trabajo repetitivo
No se debe empezar directamente como asistente todo-en-uno. Elegir entre notas de seguimiento de ventas, recordatorios de aprobación, preguntas sobre normativas o preauditorías de gastos —cualquier segmento que se repita más de media hora al día—, redactar la entrada, la salida, los permisos y las excepciones en cuatro frases, y luego acompañar con SOPs y dos o tres interfaces de solo lectura o escritura restringida. Cuando los datos maestros están sucios o los nudos de aprobación no están claros, primero corregir los objetos y el estado, y luego superponer la ejecución inteligente —una vez automatizados los datos sucios, se propagarán aún más rápido por toda la empresa.
Cómo saber si el diseño ha salido bien: aquella parte que antes dependía de los correos grupales y de los formularios ya no es la ruta principal; las notas, los recordatorios y los resúmenes pueden compararse con los documentos mediante inspecciones aleatorias; las situaciones poco claras tienen un objeto de escalada; las operaciones sensibles son revisadas por personas y los registros son accesibles. Para evaluar si el desarrollo es adecuado, mirar si después de interrumpir un mismo SOP se puede recuperar , si las respuestas pueden remitir a su fuente , y si los casos fronterizos pueden pasar a la siguiente ronda de revisión . Si estas tres condiciones se cumplen, entonces ampliar los puestos; esto es más estable que abrir muchas puertas de chat desde el principio.
La dificultad técnica del sistema de empleados digitales no radica en la generación de conversaciones, sino en convertir puestos, procesos, conocimientos, herramientas y rutas en objetos de software versionables. Los prompts pueden cambiarse diez veces por semana, pero una vez que el modelo de objetos se dispersa, cada habilidad posterior acabará escribiendo su propia versión.Primero hay que hacer funcionar estas siete categorías de objetos y la máquina de estados; solo así se podrá cambiar el modelo. De lo contrario, cada vez que se cambie el modelo, será un proyecto nuevo, no un cambio de configuración.