Líderes de opinión

El Mapa y los Rieles: Construyendo una Arquitectura Segura para la Inteligencia Artificial Empresarial

mm
Añade Unite.AI a tus fuentes preferidas en Google

La primera parte terminó con una afirmación: la inteligencia artificial empresarial tendrá éxito cuando las instituciones aprendan a construir el bucle en sí. Este ensayo se trata de lo que sostiene el bucle. Un agente que trabaja dentro de una empresa real necesita dos cosas que la empresa probablemente no tenga hoy: un mapa del trabajo y rieles para las consecuencias.

El Mapa

Aquí está el hecho incómodo que subyace a la mayoría de los programas de inteligencia artificial estancados: la empresa no puede entregar al agente una descripción de su propio trabajo, porque no existe tal descripción. La mayoría de las empresas han mapeado sus sustantivos — bases de datos llenas de clientes, facturas, reclamos, contratos. Casi ninguna ha mapeado el trabajo: qué se puede hacer con esas cosas, por quién, bajo qué condiciones y qué sucede después. Ese conocimiento vive en la cabeza de personas experimentadas y en un gráfico de proceso que describe cómo se diseñó el trabajo hace cinco años, no cómo funciona hoy.

Un nuevo empleado humano cierra esa brecha mediante un aprendizaje — observando, intentando, preguntando. Un agente no aprende de esa manera. Necesita el trabajo escrito: las cosas que la empresa maneja y dónde se encuentra cada una, el trabajo realizado en ellas, las decisiones que eligen el camino, quién está autorizado a mover las cosas hacia adelante y qué sucede cuando lo hacen — el registro que cambia, la aprobación que necesita, la forma en que se deshace. Esa descripción escrita es el mapa.

Tres reglas mantienen un mapa vivo. Debe ser escrito por las personas que poseen el trabajo y ser seguro para los ingenieros — un mapa que solo los ingenieros pueden actualizar se vuelve obsoleto, y un mapa que solo los operadores pueden editar se vuelve inseguro. Debe ser versionado, porque un agente nunca debe actuar en contra de un significado que cambió silenciosamente. Y debe ser publicado — legible para el agente, el revisor y el auditor por igual. Si un agente tiene que descubrir su negocio uniendo llamadas a API, ha expuesto sistemas, no ha descrito el trabajo. Las API son cómo se ejecutan las cosas. El mapa es cómo se entiende el trabajo.

El mapa es importante por una razón que sobrevive a cualquier ciclo de producto: el agente no es el activo duradero. El mapa lo es. Los modelos mejorarán y se intercambiarán, los marcos de agente vendrán y se irán — y la descripción de su propio trabajo, con sus reglas y excepciones y correcciones acumuladas, es lo que cada agente futuro hereda el primer día.

Los Rieles

El mapa dice qué puede suceder. Los rieles son lo que hacen que suceda exactamente.

Algunas partes del trabajo que un agente toca son de juicio: leer el correo electrónico desordenado, sopesar la excepción, recomendar el camino. Pero gran parte de ello es repetición — la misma verificación, la misma actualización, la misma publicación, miles de veces. La repetición no necesita inteligencia. Necesita ser exacta. Un modelo es probabilístico por diseño, y para la ejecución, probablemente correcto es incorrecto: una publicación de pago no tiene variación aceptable, no importa cuán bueno sea el modelo. El trabajo estable pertenece a los rieles — automatización determinista que se ejecuta de la misma manera cada vez, cuesta nada por ejecución y deja un registro de auditoría limpio.

Aquí es donde dos curvas se están divergiendo. Construir rieles es más fácil, porque describir el trabajo, generar código, escribir pruebas y reparar rutas rotas es exactamente el tipo de trabajo que la inteligencia artificial acelera. Desplegar agentes que deambulan libremente dentro de procesos con consecuencias no se está volviendo más fácil al mismo ritmo, porque cuanto más cerca está un agente de la acción, más necesita límites, evidencia, aprobaciones, auditoría y propietarios. La consecuencia es difícil, y sigue siendo difícil. Así que deje que los agentes exploren y que ayuden a sus equipos a aprender el trabajo — luego mueva cada camino a los rieles tan pronto como deje de cambiar. No deje trabajo de alto volumen y estable dentro de un bucle probabilístico porque los agentes están de moda.

Gobernar por Consecuencia

Con el mapa y los rieles en su lugar, una pregunta queda antes de que un agente toque el trabajo real: ¿qué se le debe permitir hacer? El hábito de la industria es responder en términos de fontanería — el agente “usa herramientas” — como si buscar una política, calcular una variación, redactar una carta, aprobar una factura y pagarla fueran una sola cosa. No lo son. Un modelo que busca una política no es lo mismo que un modelo que deniega una reclamación. Un modelo que calcula una cantidad no es lo mismo que un modelo que la paga. Leer información, tomar una posición, preparar una acción, cambiar un registro y mover dinero son diferentes tipos de trabajo, y la diferencia es la consecuencia: qué cuesta a la empresa cuando el paso es incorrecto.

La gobernanza debe seguir ese gradiente, no la fontanería. El trabajo que solo lee necesita control de acceso. El trabajo que recomienda necesita un ser humano que realmente decide. El trabajo que cambia un registro necesita permiso, un registro de auditoría, una forma de deshacerlo y un propietario con nombre. El trabajo que mueve dinero necesita todo eso, más la garantía de que un cambio a medio terminar no puede dejar a la empresa en un estado que simplemente esté mal. Gobernar por consecuencia y los usos seguros de la inteligencia artificial se abren rápidamente; gobernar todo de la misma manera y obtendrá parálisis o un incidente.

La Confianza se Gana con el Flujo de Trabajo

Ese gradiente también es cómo crece la confianza. Con un mapa y rieles, la confianza deja de ser un sentimiento sobre el modelo y se convierte en una propiedad del trabajo. Un flujo de trabajo — una pieza de negocio descrita, con su puerta de la parte uno — gana permiso paso a paso, subiendo el mismo gradiente: primero solo redacta, luego puede recomendar, luego puede preparar la acción que un ser humano aprueba, luego puede ejecutar los casos rutinarios y escalar las excepciones, y finalmente puede ejecutar bajo auditoría, con personas que observan los resultados en lugar de hacer clic en cada caso.

Cada paso hacia arriba se gana con evidencia de la puerta — las decisiones inspeccionadas, las correcciones, las razones — y cada paso hacia abajo es automático cuando el rendimiento disminuye. Un modelo mejor no gana derechos de acción.

No promueva el modelo. Promueva el flujo de trabajo.

Comience con un Flujo de Trabajo

Nada de esto requiere un programa a nivel empresarial, y no debe comenzar como uno. Elija un flujo de trabajo con consecuencias reales, volumen real, costo de error real y un propietario que quiera arreglarlo. Mapee esa pieza de trabajo. Coloque sus pasos estables en rieles. Establezca su puerta. Luego verifique la descripción contra nueve preguntas sencillas:

  • ¿Qué objetos de negocio se están moviendo?
  • ¿Dónde se encuentra cada uno en este momento?
  • ¿Qué trabajo se está realizando?
  • ¿Qué decisión elige el próximo camino?
  • ¿Qué sucede si esto se aprueba?
  • ¿Qué puede usar el agente?
  • ¿Qué se ejecuta automáticamente?
  • ¿Quién propone, quién aprueba, quién ejecuta, quién es responsable?
  • ¿Qué cambia antes de la próxima ejecución si algo sale mal?

Si las personas que poseen el trabajo pueden responder esas nueve preguntas para un flujo de trabajo, un agente puede trabajar dentro de él de manera segura — proponer, ser validado y dejar que los rieles ejecuten. Si no pueden, ninguna cantidad de calidad del modelo salvará la implementación.

Los fracasos son tan reconocibles como el patrón. Un chatbot con acceso a sistemas sensibles pero sin mapa del trabajo. Una capa de recuperación que responde preguntas de política pero no puede mostrar la fuente de la política. Un agente que puede aprobar el trabajo pero no puede decir quién es el propietario de la aprobación. Un revisor que ve la recomendación pero no la consecuencia de aprobarla. Un flujo de trabajo promovido a autonomía porque el modelo mejoró, no porque el flujo de trabajo ganó confianza.

El mapa, los rieles y la puerta: esa es la arquitectura. La pregunta restante es cómo construirlo en un flujo de trabajo — y esa es la tercera parte.

Daniel Dines es Fundador y Presidente Ejecutivo de UiPath (NYSE: PATH), un líder global en orquestación y automatización empresarial. Dines también ha sido Director de Innovación de la empresa. Dines fundó UiPath en 2005 con el objetivo de construir una empresa que ayudara a los humanos a reducir el tiempo y el estrés que resultan de tareas meniales y repetitivas. UiPath está construyendo sobre su fundación como la plataforma de automatización líder en el mundo para convertirse en el líder en automatización agente al desarrollar tecnología de inteligencia artificial que refleja la inteligencia humana con una sofisticación cada vez mayor, transformando la forma en que las empresas operan, innovan y compiten. Con un enfoque en seguridad, precisión y resiliencia, UiPath se compromete a dar forma a un mundo donde la inteligencia artificial mejora el potencial humano y revoluciona las industrias.