Ir al contenido principal
FromNine
Menú

IA y datos

Agentes de IA para empresas que actúan dentro de los límites que usted fija

Automatizamos trabajo de varios pasos con agentes y flujos que usan herramientas acotadas, se detienen para pedir aprobación antes de las acciones con consecuencias y dejan un rastro que sus auditores pueden reproducir.

Para centros de servicios compartidos, administraciones y equipos de operaciones en España que quieren automatizar sin perder el control de cada decisión.

Hablemos de su proyectoConozca nuestro enfoque
Agentes de IA y automatización: capas de capacidadCuatro capas superpuestas en profundidad. De arriba abajo: el flujo de trabajo que mantiene el estado, los pasos del agente dentro de él, la pasarela de herramientas con sus permisos y el control de aprobación antes de que las acciones lleguen a sus sistemas.01Flujo de trabajo y estado02Pasos del agente03Pasarela de herramientas y permisos04Aprobación y, después, acción
  1. 01El grado de autonomía adecuado para cada paso, del flujo fijo al agente supervisado
  2. 02Herramientas con el mínimo privilegio tras una pasarela, con límites por acción
  3. 03Cada paso, llamada a herramienta y aprobación queda registrado, reproducible y exportable

01 Problemas

Por qué se estancan los programas de automatización

  1. 01

    Nadie sabe decir qué puede hacer el agente

    Funciona con una cuenta de servicio de permisos amplios. Los equipos de riesgos y de seguridad no lo aprueban, y no deberían tener que adivinarlo.

  2. 02

    La tasa de automatización luce bien, pero las excepciones se acumulan

    Los casos sencillos fluyen. El resto acaba en un buzón compartido sin contexto, y el equipo que los atiende está ahora más ocupado que antes.

  3. 03

    Cuando algo falla, nadie puede reconstruir el porqué

    No queda constancia de qué datos vio el agente, qué herramienta llamó ni quién aprobó el paso. Auditoría interna pregunta y no hay respuesta.

  4. 04

    Los robots se rompen cada vez que cambia una pantalla

    Robots que leen pantallas sostienen trabajo crítico. Cada actualización de una aplicación supone un fin de semana de reparaciones.

02 Qué entregamos

Qué entregamos

  1. 01 Diseño de la autonomía paso a paso

    Para cada paso elegimos lo más sencillo que funcione: un flujo determinista, una única llamada a un modelo, un agente que usa herramientas o una orquestación de varios pasos. A veces la respuesta honesta es que un agente no es la herramienta adecuada.

    Qué hacemos

    • Recorrido del proceso con las personas que hacen el trabajo
    • Decisión de autonomía paso a paso, con el riesgo de cada uno
    • Modelo del flujo como máquina de estados o en BPMN
    • Criterios para dar a un paso más o menos autonomía

    Qué recibe

    • Mapa de autonomía del proceso
    • Modelo del flujo bajo control de versiones
    • Registro de decisión para cada paso con agente

  2. 02 Permisos de las herramientas y mínimo privilegio

    Los agentes llaman a herramientas, nunca directamente a los sistemas. Una pasarela de herramientas aplica ámbitos de permiso, listas de autorización y límites por transacción, y cada herramienta funciona con su propia identidad de servicio.

    Qué hacemos

    • Catálogo de herramientas con las de lectura y las de escritura separadas
    • Identidades de servicio con permisos acotados por herramienta
    • Límites de transacción y de frecuencia por tipo de acción
    • Ejecución en entorno aislado para el código y el tratamiento de ficheros

    Qué recibe

    • Pasarela de herramientas con la política como configuración
    • Matriz de permisos aprobada por seguridad
    • Batería de pruebas de aplicación de la política

  3. 03 Diseño con supervisión humana

    Umbrales de aprobación, derivación según el grado de confianza y doble validación para las acciones con consecuencias. Las decisiones que afectan a personas mantienen a una persona en el circuito, en línea con el artículo 22 del RGPD y el derecho a la intervención humana.

    Qué hacemos

    • Clasificación de las acciones según sus consecuencias
    • Umbrales de aprobación y reglas de escalado
    • Interfaz de revisión con el contexto necesario para decidir
    • Salvaguardas para las decisiones sobre personas

    Qué recibe

    • Política de aprobación por tipo de acción
    • Flujo de revisión en las herramientas que sus equipos ya utilizan
    • Mapa de escalado con equipos identificados

  4. 04 Trazabilidad y auditoría

    Un registro completo de entradas, contexto recuperado, resultados del modelo, llamadas a herramientas y aprobaciones, para que cualquier ejecución pueda reproducirse y exportarse para auditoría interna o para el supervisor.

    Qué hacemos

    • Diseño del registro de eventos con reglas de conservación
    • Reproducción de ejecuciones con entradas fijas
    • Formatos de exportación acordados con auditoría interna
    • Cuadros de mando de tasas de excepción y de aprobación

    Qué recibe

    • Almacén de la pista de auditoría
    • Herramientas de reproducción
    • Cuadros de mando operativos

  5. 05 Gestión de fallos

    Los agentes fallarán. Diseñamos para que el fallo sea seguro: acciones idempotentes, compensación y reversión, tiempos de espera, escalado a un equipo identificado y un interruptor de parada que alguien está autorizado a accionar.

    Qué hacemos

    • Claves de idempotencia en cada acción de escritura
    • Pasos de compensación para los cambios que afectan a varios sistemas
    • Tiempos de espera y presupuestos de reintentos
    • Interruptor de parada por agente y por herramienta

    Qué recibe

    • Análisis de modos de fallo
    • Runbook con el procedimiento de parada
    • Pruebas de caos en los recorridos críticos

  6. 06 Agentes junto a la automatización existente

    La minería de procesos muestra el flujo tal y como se ejecuta realmente. La automatización robótica de procesos se mantiene donde solo existe una pantalla heredada y pasa a API en cuanto hay una disponible. Medimos la tasa de excepciones, no solo la tasa de automatización.

    Qué hacemos

    • Minería de procesos sobre los registros de eventos
    • Inventario de los robots existentes y de su historial de fallos
    • Alternativas mediante API a la automatización frágil de pantallas
    • Análisis de las excepciones por causa

    Qué recibe

    • Análisis del flujo actual
    • Plan de migración de pantallas a API
    • Situación de partida y objetivo para el tiempo de gestión de excepciones

03 Arquitectura

Una arquitectura de referencia ilustrativa

El orquestador es el dueño del estado del trabajo. Los pasos del agente están dentro de él y solo pueden llegar a sus sistemas a través de la pasarela de herramientas, que comprueba permisos y límites en cada llamada. Las herramientas de lectura pasan; las de escritura se detienen en un control de aprobación cuando la acción tiene consecuencias.

Todo queda registrado en la pista de auditoría. El orquestador cuenta con un interruptor de parada y tiempos de espera, y las excepciones llegan a un equipo identificado con todo el contexto de la ejecución.

Capas del diagrama

Entrada
Un nuevo caso, mensaje o evento inicia una ejecución con un identificador de correlación.
Orquestación
Estado del flujo, pasos del agente, compensación e interruptor de parada.
Perímetro de permisos
Pasarela de herramientas, herramientas de lectura, control de aprobación y herramientas de escritura.
Sistemas
CRM, ERP y gestión de expedientes, accesibles solo a través de herramientas.
Trazabilidad
La pista de auditoría y el equipo que atiende los escalados.
Ejemplo ilustrativo

  1. Entrada

    • Desencadenante: caso, mensaje, evento

  2. Orquestación

    • Orquestador y estado
    • Paso del agente
    • Interruptor de parada y tiempos de espera
    • Compensación y reversión

  3. Perímetro de permisos

    • Pasarela de herramientas
    • Herramientas de lectura
    • Control de aprobación
    • Herramientas de escritura

  4. Sistemas

    • CRM, ERP, gestión de expedientes

  5. Trazabilidad

    • Pista de auditoría: cada paso, llamada y aprobación, con reproducción y exportación
    • Equipo identificado para excepciones
Un agente dentro de un perímetro de permisos

Arquitectura ilustrativa, no corresponde a ningún sistema de cliente.

Leer el diagrama como texto

El recorrido principal va desde un desencadenante, pasando por el orquestador y un paso del agente, hasta la pasarela de herramientas; después atraviesa un control de aprobación en el que decide una persona, sigue hacia una herramienta de escritura y llega por último a los sistemas de negocio.

La pasarela también da paso a herramientas de lectura que consultan directamente los sistemas de negocio. Un interruptor de parada controla el orquestador, los pasos de compensación pueden deshacer las acciones del agente y el orquestador escala a un equipo identificado.

Las aprobaciones y las acciones de escritura se guardan en una pista de auditoría que permite reproducir y exportar. La pasarela, las herramientas de lectura, el control de aprobación y las herramientas de escritura forman juntos el perímetro de permisos.

04 Consideraciones y límites

Consideraciones de ingeniería y límites

  • La autonomía se gana paso a paso

    Cómo lo abordamos

    Los pasos empiezan supervisados. Solo ampliamos la autonomía cuando los registros muestran que el paso se mantiene dentro de los límites acordados en un volumen de casos significativo.

    Límites y dependencias

    Algunos pasos no deberían ser nunca autónomos, digan lo que digan las cifras. Es una decisión de negocio y le pediremos que la tome de forma explícita.

  • Un agente es tan seguro como sus herramientas

    Cómo lo abordamos

    Las herramientas de escritura son estrechas y parametrizadas: «emitir una nota de abono hasta un importe máximo», nunca «llamar al ERP».

    Límites y dependencias

    Cuando un sistema carece de un modelo de permisos detallado, lo compensamos en la pasarela. Eso supone trabajo adicional, y algunos sistemas no pueden hacerse lo bastante seguros para permitir la escritura.

    La IA puede equivocarse. Por eso las acciones con consecuencias se detienen ante una persona y los casos dudosos se derivan, no se adivinan.

  • La inyección de prompts es un riesgo operativo

    Cómo lo abordamos

    El contenido de correos, documentos y páginas web se trata como no fiable. No puede modificar las instrucciones del agente ni ampliar sus permisos, y las pruebas de red team lo verifican.

    Límites y dependencias

    Ninguna medida elimina el riesgo por completo. El diseño da por hecho que algún día un intento tendrá éxito y limita lo que puede alcanzar.

  • Las excepciones forman parte del producto

    Cómo lo abordamos

    Cada excepción llega con el contexto de la ejecución, un motivo y una propuesta de siguiente paso, a la cola de un equipo responsable de ella.

    Límites y dependencias

    Si nadie se responsabiliza de la cola de excepciones, la automatización desplaza el trabajo en lugar de eliminarlo. No pasamos a producción sin un responsable identificado.

05 Cómo trabajamos

Cómo trabajamos

Partimos del proceso tal como se ejecuta, no tal como está dibujado, y la autonomía se gana paso a paso.

  1. 01

    Ver el flujo real

    La minería de procesos y la observación directa muestran volúmenes, variantes y dónde se pierde el tiempo.

    ResultadoAnálisis del flujo actual

  2. 02

    Decidir la autonomía de cada paso

    Flujo, llamada a un modelo o agente, con la consecuencia de una acción errónea documentada para cada paso.

    ResultadoMapa de autonomía y matriz de permisos

  3. 03

    Ejecutar en modo sombra

    El sistema propone y las personas actúan. Comparamos sus propuestas con las decisiones reales sobre casos en curso.

    ResultadoInforme de la ejecución en modo sombra

  4. 04

    Pasar a producción con aprobaciones

    Las acciones con consecuencias esperan aprobación; los umbrales se revisan con datos, no por intuición.

    ResultadoPolítica de aprobación y cuadros de mando

06 Control humano

Dónde mantienen el control las personas

Los agentes actúan dentro de los permisos que usted define, piden aprobación antes de las acciones con consecuencias y registran cada paso.

  • Aprobación antes de las consecuencias

    Los pagos, las decisiones sobre personas y los cambios en los datos maestros esperan a una persona, con el contexto necesario para decidir con rapidez.

  • Doble validación donde importa

    Por encima de los umbrales acordados aprueban dos personas. El umbral es un parámetro que controla su responsable de riesgos, no código.

  • Un interruptor de parada que alguien puede usar

    Un rol designado puede detener cada agente y cada herramienta sin necesidad de un despliegue, y el procedimiento se ensaya.

  • Revisión humana de las decisiones sobre personas

    Cuando un resultado afecta a una persona, otra persona lo revisa, y el interesado puede solicitar esa revisión.

  • Escalado a un equipo identificado

    Las ejecuciones dudosas o fallidas van a un equipo que se responsabiliza de ellas, nunca a un buzón desatendido.

07 Ejemplo

Un ejemplo ilustrativo

Ejemplo ilustrativo

Revisión de solicitudes en una convocatoria de ayudas

01Situación
Una consejería autonómica recibe las solicitudes de una convocatoria de ayudas a la digitalización y sus técnicos dedican semanas a comprobar requisitos y documentación antes de poder valorar cada expediente.
02Qué construiríamos
Un agente que comprueba los requisitos formales, consulta los datos disponibles a través de la Plataforma de Intermediación de Datos, señala lo que falta y prepara el borrador de requerimiento.
03Dónde deciden las personas
El técnico decide sobre cada expediente y firma cada requerimiento; el agente no puede resolver ni notificar.
04Qué mediríamos
Plazo hasta el primer requerimiento, porcentaje de comprobaciones confirmadas por el técnico y expedientes revisados por semana.

08 Por sectores

En su sector

  • Servicios financieros

    Siniestros, altas de clientes y excepciones de pago gestionados por agentes con límites por transacción, doble validación y exportaciones de auditoría en un formato acordado con su función de auditoría.

  • Sector público y Administración

    Preparación de expedientes en la que el agente reúne la información y redacta, y el empleado público decide, con cada paso registrado para la revisión y los recursos administrativos.

  • Industria y fabricación

    Cambios de pedidos, seguimiento de proveedores y solicitudes de servicio entre el ERP y el correo, con aprobaciones en los puntos que comprometen dinero o capacidad.

España

Automatizar con garantías en España

Cuando un agente prepara decisiones que afectan a ciudadanos, las Leyes 39/2015 y 40/2015 marcan quién debe resolver y cómo se motiva, y la actuación administrativa automatizada exige identificar al órgano responsable. En la empresa privada, el RGPD limita las decisiones basadas únicamente en un tratamiento automatizado, y la AEPD lo vigila de cerca.

Por eso nuestros agentes preparan, comprueban y proponen, mientras una persona aprueba los pasos con consecuencias. Cada acción queda registrada para poder explicarla ante un auditor o ante la AESIA.

Preguntas sobre agentes de IA y automatización

¿Cómo deciden entre un agente y un flujo de trabajo convencional?

Si los pasos son conocidos y las entradas están estructuradas, un flujo es más barato, más rápido y más fácil de auditar. Los agentes se justifican cuando las entradas varían, el camino depende de lo que se encuentra y una persona puede comprobar el resultado. La mayoría de los sistemas en producción combinan ambos.

¿Qué impide que un agente haga algo que no debe?

Solo puede actuar mediante herramientas, cada herramienta funciona con su propia identidad de permisos acotados y la pasarela aplica límites en cada llamada. Las acciones de escritura con consecuencias se detienen hasta su aprobación. El contenido no fiable no puede modificar esas reglas.

Ya utilizamos RPA. ¿Tenemos que desecharla?

No. Los robots sobre pantallas heredadas siguen funcionando donde no existe una API. Añadimos agentes para los pasos que requieren criterio, usamos la minería de procesos para localizar los robots frágiles y los sustituimos por integraciones mediante API a medida que los sistemas subyacentes lo permiten.

¿Cómo miden el éxito?

Por el tiempo de tramitación, la tasa de excepciones, el retrabajo y el tiempo que dedican las personas a las excepciones, frente a una situación de partida medida antes de la puesta en producción. La tasa de automatización por sí sola oculta demasiado.

¿Pueden su auditoría interna o un supervisor examinar lo ocurrido?

Sí. Cada ejecución puede reproducirse a partir de su registro: entradas, contexto recuperado, resultados del modelo, llamadas a herramientas y aprobaciones. Los formatos de exportación se acuerdan con su función de auditoría antes de la puesta en producción.

Traiga el proceso que más ocupa a su equipo

Analizaremos qué pasos puede preparar un agente, cuáles deben quedar en manos de una persona y cómo mediríamos el resultado en una primera fase.

Hablemos de su proyectoConozca nuestro enfoque