Saltar ao contido principal
FromNine
Menú

IA e datos

Axentes de IA e automatización que actúan dentro dos límites que vostede fixa.

Automatizamos traballo de varios pasos con axentes e fluxos que usan ferramentas acoutadas, paran para pedir aprobación antes das accións con consecuencias e deixan un rastro que a súa auditoría pode reproducir.

Para centros de servizos compartidos, equipos de operacións e unidades de tramitación que levan o mesmo proceso por varios sistemas.

Fálenos do seu proxectoVer atención ao público
Axentes de IA e automatización: capas de capacidadeCatro capas superpostas en profundidade. De arriba abaixo: o fluxo de traballo que garda o estado, os pasos do axente dentro del, a pasarela de ferramentas cos seus permisos e o punto de aprobación antes de que as accións cheguen aos seus sistemas.01Fluxo de traballo e estado02Pasos do axente03Pasarela de ferramentas e permisos04Aprobación e despois acción
  1. 01O grao de autonomía axeitado para cada paso, do fluxo fixo ao axente supervisado
  2. 02Ferramentas co mínimo privilexio tras unha pasarela, con límites por acción
  3. 03Cada paso, chamada a ferramenta e aprobación rexistrados, reproducibles e exportables

01 Problemas

Por que dubidan os programas de automatización

  1. 01

    Ninguén sabe dicir que pode facer o axente

    Funciona cunha conta de servizo con permisos amplos. Os equipos de riscos e de seguridade non o aproban, e non deberían ter que adiviñalo.

  2. 02

    A taxa de automatización parece boa, pero as excepcións amoréanse

    Os casos sinxelos pasan sen problema. O resto acaba nunha caixa de correo compartida sen contexto, e o equipo que os atende ten agora máis traballo ca antes.

  3. 03

    Cando algo sae mal, ninguén pode reconstruír por que

    Non queda constancia dos datos que viu o axente, da ferramenta que chamou nin de quen aprobou o paso. A auditoría interna pregunta e non hai resposta.

  4. 04

    Os robots rompen cada vez que cambia unha pantalla

    Robots que len pantallas sosteñen traballo crítico. Cada actualización dunha aplicación supón unha fin de semana de reparacións.

02 Que entregamos

Que entregamos

  1. 01 Deseño da autonomía paso a paso

    Para cada paso eliximos o máis sinxelo que funcione: un fluxo determinista, unha única chamada a un modelo, un axente que usa ferramentas ou unha orquestración de varios pasos. Ás veces a resposta correcta é que un axente non é a ferramenta axeitada.

    Que facemos

    • Percorrido polo proceso coas persoas que fan o traballo
    • Decisión de autonomía paso a paso, co risco de cada paso
    • Máquina de estados ou modelo BPMN do fluxo
    • Criterios para dar a un paso máis ou menos autonomía

    Que recibe

    • Mapa de autonomía do proceso
    • Modelo do fluxo con control de versións
    • Rexistro de decisión para cada paso con axente

  2. 02 Permisos das ferramentas e mínimo privilexio

    Os axentes chaman a ferramentas, nunca directamente aos sistemas. Unha pasarela de ferramentas aplica alcances, listas de permitidos e límites por operación, e cada ferramenta funciona coa súa propia identidade de servizo.

    Que facemos

    • Catálogo de ferramentas coas de lectura e as de escritura separadas
    • Identidades de servizo con alcance limitado para cada ferramenta
    • Límites de operacións e de frecuencia por tipo de acción
    • Execución illada para o código e o manexo de ficheiros

    Que recibe

    • Pasarela de ferramentas coa política como configuración
    • Matriz de permisos aprobada por seguridade
    • Batería de probas da aplicación das políticas

  3. 03 Deseño coa persoa no circuíto

    Limiares de aprobación, enrutamento segundo a confianza e dobre revisión para as accións con consecuencias. As decisións sobre persoas manteñen unha persoa no circuíto, de acordo co artigo 22 do RXPD e o dereito a obter intervención humana.

    Que facemos

    • Clasificación das accións segundo as súas consecuencias
    • Limiares de aprobación e regras de escalada
    • Interface de revisión co contexto necesario para decidir
    • Garantías para as decisións sobre persoas

    Que recibe

    • Política de aprobación por tipo de acción
    • Fluxo de revisión nas ferramentas que os seus equipos xa usan
    • Mapa de escalada con equipos designados

  4. 04 Trazabilidade e auditoría

    Un rexistro completo das entradas, do contexto recuperado, das saídas do modelo, das chamadas a ferramentas e das aprobacións, para que calquera execución se poida reproducir e exportar para a auditoría interna ou para un supervisor.

    Que facemos

    • Deseño do rexistro de eventos con regras de conservación
    • Reprodución de execucións con entradas fixas
    • Formatos de exportación acordados coa auditoría interna
    • Paneis de taxas de excepción e de aprobación

    Que recibe

    • Almacén do rexistro de auditoría
    • Ferramentas de reprodución
    • Paneis operativos

  5. 05 Xestión dos fallos

    Os axentes van fallar. Deseñamos para que o fallo sexa seguro: accións idempotentes, compensación e reversión, tempos de espera, escalada a un equipo designado e un interruptor de parada que alguén está autorizado a usar.

    Que facemos

    • Claves de idempotencia en cada acción de escritura
    • Pasos de compensación para cambios en varios sistemas
    • Tempos de espera e orzamentos de reintentos
    • Interruptor de parada por axente e por ferramenta

    Que recibe

    • Análise dos modos de fallo
    • Manual de operación co procedemento de parada
    • Probas de caos nos camiños críticos

  6. 06 Axentes xunto á automatización existente

    A minaría de procesos mostra o fluxo tal e como funciona. A automatización robótica de procesos (RPA) queda onde só existe unha pantalla herdada e pasa a API en canto hai unha. Medimos a taxa de excepcións, non só a de automatización.

    Que facemos

    • Minaría de procesos sobre rexistros de eventos
    • Inventario dos robots existentes e do seu historial de fallos
    • Alternativas con API para a automatización fráxil de pantallas
    • Análise das excepcións por causa

    Que recibe

    • Análise do fluxo actual
    • Plan de migración de pantallas a API
    • Situación de partida e obxectivo do tempo de xestión de excepcións

03 Arquitectura

Unha arquitectura de referencia ilustrativa

O orquestrador é o dono do estado do traballo. Os pasos do axente están dentro del e só poden chegar aos seus sistemas a través da pasarela de ferramentas, que comproba o alcance e os límites en cada chamada. As ferramentas de lectura pasan; as de escritura paran nun punto de aprobación cando a acción ten consecuencias.

Todo deixa constancia no rexistro de auditoría. O orquestrador ten un interruptor de parada e tempos de espera, e as excepcións van a un equipo designado co contexto completo da execución.

Capas do debuxo

Entrada
Un novo expediente, mensaxe ou evento inicia unha execución cun identificador de correlación.
Orquestración
Estado do fluxo, pasos do axente, compensación e interruptor de parada.
Límite de permisos
Pasarela de ferramentas, ferramentas de lectura, punto de aprobación e ferramentas de escritura.
Sistemas
CRM, ERP e xestión de expedientes, aos que só se chega a través de ferramentas.
Rastro
O rexistro de auditoría e o equipo que atende as escaladas.
Exemplo ilustrativo

  1. Entrada

    • Disparador: expediente, mensaxe, evento

  2. Orquestración

    • Orquestrador e estado
    • Paso do axente
    • Interruptor de parada e tempos de espera
    • Compensación e reversión

  3. Límite de permisos

    • Pasarela de ferramentas
    • Ferramentas de lectura
    • Punto de aprobación
    • Ferramentas de escritura

  4. Sistemas

    • CRM, ERP, xestión de expedientes

  5. Rastro

    • Rexistro de auditoría: cada paso, chamada e aprobación, con reprodución e exportación
    • Equipo designado para excepcións
Un axente dentro dun límite de permisos

Arquitectura ilustrativa, non é o sistema dun cliente.

Ler o diagrama como texto

A ruta principal vai dun disparador ao orquestrador e a un paso do axente, despois á pasarela de ferramentas, a un punto de aprobación onde decide unha persoa, a unha ferramenta de escritura e, finalmente, aos sistemas de negocio.

A pasarela tamén permite ferramentas de lectura que consultan directamente os sistemas de negocio. Un interruptor de parada controla o orquestrador, os pasos de compensación poden desfacer accións do axente e o orquestrador escala a un equipo designado.

As aprobacións e as accións de escritura quedan nun rexistro de auditoría que permite reproducir e exportar. A pasarela, as ferramentas de lectura, o punto de aprobación e as ferramentas de escritura forman xuntos o límite de permisos.

04 Consideracións e límites

Consideracións técnicas e límites

  • A autonomía gáñase paso a paso

    Como o abordamos

    Os pasos comezan supervisados. Só ampliamos a autonomía cando os rexistros mostran que o paso se comporta dentro dos límites acordados nun volume significativo de casos.

    Límites e dependencias

    Algúns pasos nunca deberían ser autónomos, digan o que digan os números. Esa é unha decisión de negocio, e pedirémoslle que a tome de forma explícita.

  • Un axente é tan seguro coma as súas ferramentas

    Como o abordamos

    As ferramentas de escritura son estreitas e parametrizadas: «emitir unha factura rectificativa ata un límite», nunca «chamar ao ERP».

    Límites e dependencias

    Cando un sistema non ten un modelo de permisos detallado, compensámolo na pasarela. Iso engade traballo, e algúns sistemas non se poden facer seguros dabondo para darlles acceso de escritura.

    A saída da IA pode estar mal. Por iso as accións con consecuencias paran ante unha persoa e os casos dubidosos derívanse, non se adiviñan.

  • A inxección de instrucións é un risco operativo

    Como o abordamos

    O contido de correos, documentos e páxinas web trátase como non fiable. Non pode cambiar as instrucións do axente nin ampliar os seus permisos, e as probas adversarias comproban que non o fai.

    Límites e dependencias

    Ningunha medida elimina o risco por completo. O deseño parte de que un intento terá éxito algún día e limita o que pode alcanzar.

  • As excepcións forman parte do produto

    Como o abordamos

    Cada excepción chega co contexto da execución, un motivo e un seguinte paso proposto, á cola dun equipo que é responsable dela.

    Límites e dependencias

    A automatización despraza o traballo en vez de eliminalo se ninguén é responsable da cola de excepcións. Non pasamos a produción sen unha persoa responsable designada.

05 Como traballamos

Como traballamos

Partimos do proceso tal e como funciona, non tal e como está debuxado, e gañamos autonomía paso a paso.

  1. 01

    Ver o fluxo real

    A minaría de procesos e a observación directa mostran volumes, variantes e onde se perde o tempo.

    ResultadoAnálise do fluxo actual

  2. 02

    Decidir a autonomía de cada paso

    Fluxo, chamada a un modelo ou axente, coa consecuencia dunha acción errada anotada para cada paso.

    ResultadoMapa de autonomía e matriz de permisos

  3. 03

    Funcionar en modo sombra

    O sistema propón e as persoas actúan. Comparamos as súas propostas coas decisións delas en casos reais.

    ResultadoInforme do modo sombra

  4. 04

    Pasar a produción con aprobacións

    As accións con consecuencias agardan aprobación; os limiares revísanse con evidencias, non por intuición.

    ResultadoPolítica de aprobación e paneis

06 Control humano

Onde as persoas manteñen o control

Os axentes actúan dentro dos permisos que vostede define, piden aprobación antes das accións con consecuencias e rexistran cada paso.

  • Aprobación antes da consecuencia

    Os pagamentos, as decisións sobre persoas e os cambios nos datos mestres agardan por unha persoa, co contexto necesario para decidir de présa.

  • Dobre aprobación onde importa

    Por riba dos limiares acordados aproban dúas persoas. O limiar é un axuste que controla a persoa responsable do risco, non código.

  • Un interruptor de parada que alguén pode usar

    Un rol designado pode deter cada axente e cada ferramenta sen despregar nada, e o procedemento ensáiase.

  • Revisión humana nas decisións sobre persoas

    Cando un resultado afecta a unha persoa, revísao outra persoa, e a persoa afectada pode solicitar esa revisión.

  • Escalada a un equipo designado

    As execucións dubidosas ou falladas van a un equipo que se fai cargo delas, nunca a unha caixa de correo sen atender.

07 Exemplo

Un exemplo ilustrativo

Exemplo ilustrativo

Facturas de provedores con incidencias nun distribuidor de alimentación

01Situación
Un distribuidor de alimentación recibe as facturas dos seus provedores, cada vez máis en formato electrónico. As que non casan co pedido ou co albará agardan días nunha cola mentres o persoal de administración reclama por correo a quen fixo a compra.
02Que construiriamos
Un axente reúne o pedido, o albará e as condicións pactadas, redacta unha proposta de solución e unha mensaxe para a persoa compradora, e propón o asento a través de ferramentas do ERP con alcance limitado.
03Onde deciden as persoas
Os asentos por riba dun importe fixado necesitan dúas aprobacións. Nada que toque os datos bancarios dun provedor se automatiza nunca.
04Que mediriamos
Días que unha incidencia permanece aberta, proporción de propostas aceptadas sen cambios e tempo dedicado a cada incidencia.

08 Por sector

No seu sector

  • Servizos financeiros

    Sinistros, altas de clientes e incidencias de pagamento xestionados por axentes con límites por operación, dobre aprobación e exportacións de auditoría nun formato acordado coa súa función de auditoría.

  • Sector público

    Preparación de expedientes na que o axente reúne e redacta e o persoal empregado público decide, con cada paso rexistrado para revisións e recursos.

  • Fabricación e industria

    Cambios de pedido, seguimento de provedores e solicitudes de servizo entre o ERP e o correo, con aprobacións nos puntos que comprometen diñeiro ou capacidade.

España

Automatizar sen quitarlle a decisión ás persoas

En España, as decisións automatizadas sobre persoas teñen as mesmas regras de base en calquera sector: o Regulamento de IA e o dereito do RXPD a non ser obxecto de decisións baseadas unicamente nun tratamento automatizado, que a LOPDGDD completa. Nos expedientes públicos, deseñamos para que a resolución quede sempre en mans do persoal tramitador.

Mantemos unha soa orquestración e un só rexistro de auditoría, e facemos configurables por entidade os limiares de aprobación, as linguas e as vías de escalada. A persoa responsable do risco de cada entidade ve e aproba os axustes que afectan ao seu persoal, á súa clientela ou á cidadanía.

Preguntas sobre axentes de IA e automatización

Como deciden entre un axente e un fluxo de traballo normal?

Se os pasos son coñecidos e as entradas están estruturadas, un fluxo é máis barato, máis rápido e máis fácil de auditar. Os axentes gañan o seu sitio onde as entradas varían, o camiño depende do que se atopa e unha persoa pode comprobar o resultado. A maioría dos sistemas en produción combinan os dous.

Que impide que un axente faga algo que non debe?

Só pode actuar a través de ferramentas, cada ferramenta funciona coa súa propia identidade de alcance limitado e a pasarela aplica límites en cada chamada. As accións de escritura con consecuencias paran ata que alguén as aproba. O contido non fiable non pode cambiar esas regras.

Xa usamos RPA. Temos que tiralo?

Non. Os robots sobre pantallas herdadas seguen funcionando onde non hai API. Engadimos axentes para os pasos que requiren criterio, usamos a minaría de procesos para atopar os robots fráxiles e substituímolos por integracións con API a medida que os sistemas de base o permiten.

Como miden o éxito?

Polo tempo de tramitación, a taxa de excepcións, o retraballo e o tempo que as persoas dedican ás excepcións, comparados cunha situación de partida medida antes da posta en produción. A taxa de automatización por si soa oculta demasiado.

Pode a auditoría interna ou un supervisor revisar o que pasou?

Si. Cada execución pódese reproducir a partir do seu rexistro: entradas, contexto recuperado, saídas do modelo, chamadas a ferramentas e aprobacións. Os formatos de exportación acórdanse coa súa función de auditoría antes da posta en produción.

Traia o proceso que máis ocupa o seu equipo

Antes de construír nada, sinalaremos onde axuda un axente, onde abonda cun fluxo de traballo e onde ten que decidir unha persoa.

Fálenos do seu proxectoVer atención ao público