Solución / 03
Delegar tareas con control
Agentes de IA que ejecutan pasos de un proceso y piden aprobación antes de actuar.
Un agente puede consultar tus sistemas, preparar una acción y ejecutarla dentro de permisos definidos. Las acciones que comprometen a la empresa esperan la aprobación de una persona, y cada paso queda registrado.
- Acción propuesta
- Aprobación
- Ejecución
- Registro
Esperando aprobación
Enviar la orden de compra al proveedor
- Herramienta
- Correo de compras (envío)
- Permiso
- Requiere aprobación humana
- Registro
- Activo
Qué cambia
Del trabajo de hoy al sistema
Reconoces esta situación si…
- Un asistente redacta respuestas, pero el trabajo entre sistemas sigue dependiendo de copiar, comparar y perseguir aprobaciones.
- La entrada varía: correos, solicitudes o documentos que hay que interpretar antes de actuar.
- Una automatización con reglas fijas se rompe con cada excepción.
HoyUna persona consulta tres sistemas para preparar una respuesta
Con el sistemaEl agente consulta con permiso de lectura y prepara la propuesta
HoyAcciones sin rastro claro
Con el sistemaCada consulta, propuesta y acción registrada con versión y responsable
HoyExcepciones que se pierden en el correo
Con el sistemaEl agente se detiene, conserva lo hecho y escala a una persona
Control del agente
Qué se define antes de construir el agente
Un agente no se describe por lo «inteligente» que es, sino por lo que puede hacer, dónde, con qué permisos y qué pasa cuando algo falla.
Tarea
Un proceso concreto, con un dueño y un resultado esperado.
Herramientas
Los sistemas que puede usar, normalmente de dos a cuatro.
Permisos
Qué puede leer y qué puede escribir en cada sistema, con el acceso mínimo necesario.
Aprobaciones
Qué acciones se detienen hasta que una persona las aprueba, y quién aprueba.
Límites
Tiempo máximo, intentos, costo por tarea y acciones que nunca ejecuta.
Registro
Cada consulta, propuesta, aprobación y acción queda trazada con su versión.
Recuperación
Ante un fallo se detiene, conserva lo hecho y escala; las acciones reversibles pueden deshacerse.
Estas definiciones se escriben con el dueño del proceso y forman parte de la entrega.
Niveles de autonomía: se amplían solo con evidencia
Normalmente empezamos en «prepara» o «actúa con aprobación». Subir de nivel requiere datos de la operación, no confianza.
- L0 Asiste Responde preguntas. No toca ningún sistema.
- L1 Observa Consulta sistemas con permisos de lectura.
- L2 Prepara Propone una acción, con sus motivos, para que alguien la ejecute. Punto de partida habitual
- L3 Actúa con aprobación Ejecuta después de que una persona aprueba. Punto de partida habitual
- L4 Autonomía acotada Ejecuta sola dentro de límites de política y presupuesto, con registro.
Lo que el agente puede hacer, escrito antes de construir
| Acción | ¿Puede? | ¿Pide aprobación? | ¿Queda registro? |
|---|---|---|---|
| Consultar el stock | Sí | No | Sí |
| Preparar una orden de compra | Sí | No | Sí |
| Enviar la orden al proveedor | Sí | Sí, del responsable de compras | Sí |
| Modificar datos de un cliente | No | — | Sí, el intento |
Cómo funciona
Cómo funciona, paso a paso
-
Elegir proceso y nivel de autonomía
Un proceso, su dueño y el nivel inicial, normalmente «prepara» o «actúa con aprobación».
-
Definir herramientas y permisos
De dos a cuatro herramientas con alcance mínimo: qué puede leer, qué puede escribir y qué requiere aprobación.
-
Construir y probar con fallos
Casos normales, difíciles y con fallo de herramienta, contra un criterio de aceptación acordado.
-
Operar y ampliar con evidencia
Registro de acciones y evaluación periódica. Los permisos se amplían solo si los datos lo justifican.
Encaje
Cuándo encaja y cuándo no
Encaja si…
- El proceso cruza varios sistemas y la entrada no llega siempre igual.
- Hay que interpretar información antes de actuar: un correo, una solicitud o un documento.
- Existe un dueño del proceso que define qué acciones necesitan aprobación.
No conviene si…
- Las reglas son fijas y la entrada siempre llega igual. Una automatización tradicional es más simple, más barata y más predecible.
Ver automatización con reglas - Se espera autonomía total desde el inicio. No empezamos con autonomía ilimitada ni con varios agentes si uno resuelve el proceso.
Alcance
Qué entrega AMDATA y qué necesitas aportar
AMDATA entrega
- Agente instalado e integrado al flujo real.
- Conectores con permisos mínimos.
- Política escrita: qué puede hacer, qué pide aprobación y qué nunca hace.
- Registro de acciones y aprobaciones.
- Evaluación con casos de prueba y criterio de aceptación.
- Guía de operación y procedimiento para detenerlo o revertir.
Tu organización aporta
- Un dueño del proceso.
- Acceso controlado a dos a cuatro herramientas o sistemas.
- Casos reales de prueba, incluidos los difíciles.
- El criterio de aceptación: cuándo el agente es suficientemente bueno.
Precio. La implementación se cotiza por alcance después de una evaluación. El diagnóstico de un proceso tiene precio publicado. Ver condiciones
Medición
Cómo se mide el resultado
Se mide la línea base antes de construir y después se compara con la misma regla.
- Tareas completadas
- Sin intervención, con intervención o no completadas, con su motivo.
- Errores de herramientas
- Consultas o acciones que fallaron en un sistema.
- Intervención humana
- Aprobaciones, rechazos y escalamientos por tipo de acción.
- Tiempo y costo por tarea
- Incluido el consumo de modelos.
Evidencia y límites
Qué podemos demostrar hoy y qué límites tiene
Hay una demo interactiva con datos ficticios: muestra la aprobación de un envío, el rechazo y una acción que el agente no pudo completar. Aún no publicamos casos de clientes con agentes.
Abrir la demo del agenteDónde se ejecuta
En la infraestructura que apruebe tu organización. Hoy lo construido por AMDATA opera en nube.
Limitaciones
- Un agente puede interpretar mal una entrada. Por eso las acciones con consecuencias requieren aprobación.
- La calidad depende del modelo, de los datos disponibles y de las herramientas que expone cada sistema.
- Hoy lo construido por AMDATA opera en nube. Ejecutar agentes en infraestructura propia requiere evaluar primero la arquitectura.
Alternativas
Si esto no es exactamente lo que necesitas
Detalle técnico y preguntas
Detalle técnico
Para equipos de TI y seguridad que necesitan verificar cómo se construye.
Arquitectura por capas
Entrada (usuario, ERP, CRM, correo o API) → orquestación (flujo, ejecución y punto de aprobación) → control (identidad, políticas, registro y evaluación) → herramientas (conectores autorizados) → modelos.
Las capas separadas permiten cambiar de modelo o de proveedor y volver a correr las mismas pruebas.
Conexión con herramientas
APIs directas y Model Context Protocol (MCP), un estándar para conectar aplicaciones de IA con herramientas, cuando el sistema lo justifica. Los conectores críticos no dependen solo de MCP.
Por cada conector se registra: dueño, autenticación, alcance de lectura y escritura, límite de uso, aprobación y registro.
Modelos
Modelos comerciales o con pesos disponibles, según datos, latencia, costo y compatibilidad. No hay un modelo oficial: la arquitectura permite reemplazarlo.
Seguridad en ejecución
Secretos fuera del código, acceso mínimo necesario y red segmentada.
Parada, tiempo máximo, reintentos acotados y vuelta a una versión anterior.
Preguntas frecuentes
Las dudas que suelen aparecer antes de decidir.
¿El agente actúa solo?
Solo dentro de lo que la política permite. Las acciones que definas como sensibles se detienen hasta que una persona las aprueba.
¿Qué pasa si se equivoca?
Si una herramienta falla o un dato no cuadra, el agente se detiene, conserva lo hecho y escala a una persona. El registro permite reconstruir qué ocurrió.
¿Es lo mismo que un chatbot?
No. Un chatbot conversa. Un agente completa pasos de una tarea con herramientas; puede tener una interfaz de conversación o no tenerla.
Soluciones relacionadas
Evalúa el proceso antes de construir.
En 5 días hábiles medimos el proceso, definimos su línea base y te decimos qué conviene construir, qué no y en qué orden.