Presentado por Vijil
En entornos dinámicos donde los usuarios, los datos, los flujos de trabajo y las técnicas de ataque cambian continuamente después de la implementación, confiar en los agentes de IA se ha convertido en un problema de ejecución. La mayoría de las organizaciones todavía ven la confianza como un ejercicio previo a la implementación, declarando lista la producción de un agente y liberándolo después de pasar las evaluaciones de la zona de pruebas y las pruebas de seguridad. Desafortunadamente, esta confiabilidad colapsa tan pronto como un agente comienza a interactuar con el mundo real.
«El meollo del problema es que los CIO y los propietarios de empresas piensan en los sistemas de inteligencia artificial de la misma manera que piensan en SaaS o las aplicaciones móviles, que no responden dinámicamente al mundo que los rodea», dice Vin Sharma, fundador y director ejecutivo de Vijil. «Se supone que los agentes, según la definición clásica, perciben su entorno, razonan, actúan, observan las consecuencias y aprenden de la brecha entre las expectativas y la realidad. El problema es que los modelos subyacentes se construyen a partir de datos de entrenamiento estáticos, y esta imagen del mundo ya está obsoleta cuando llegan a la producción».
Por qué las puntuaciones de referencia no garantizan la confiabilidad del sistema del agente
Las evaluaciones de IA tradicionales ofrecen una evaluación única de las capacidades de los agentes, en lugar de su confiabilidad. Hay tres razones por las que esta evaluación no logra predecir el comportamiento empresarial real:
En primer lugar, los puntos de referencia son estáticos, construidos en torno a una noción particular de lo que significaba un buen desempeño en el momento en que fueron desarrollados, mientras el mundo continúa avanzando.
En segundo lugar, modelan de manera imperfecta la realidad, por lo que la brecha entre el punto de referencia y el mundo real es exactamente el punto donde ocurren muchas fallas.
Y en tercer lugar, los puntos de referencia son públicos, por lo que se filtran en los datos de entrenamiento de modelos futuros, lo que permite a los modelos memorizar eficazmente la prueba en lugar de demostrar sus capacidades reales.
«El agente o la aplicación puede funcionar excepcionalmente bien en una prueba comparativa, pero existe una brecha entre esa prueba comparativa y el mundo real», afirma Sharma. «Un buen rendimiento sólo demuestra que puede pasar la prueba, no que funcionará de manera confiable en producción».
Pero, en general, los puntos de referencia no son suficientes, precisamente porque miden la capacidad, no la confiabilidad.
«Tendemos a pensar en los agentes como factótums, generalmente agentes de utilidad a quienes se les puede delegar ciertos tipos de tareas», dice Sharma. «Pero lo que tenemos que hacer es darles un objetivo que les exija cumplir siempre con su deber de competencia, su deber de diligencia y su deber de lealtad hacia la empresa».
Por supuesto, los agentes no son conscientes y no se puede esperar que sientan una verdadera lealtad humana, pero según la ley el deber fiduciario en realidad no requiere conciencia. Esto simplemente significa que se debe exigir al agente que anteponga los intereses del principal a los suyos propios o a los de cualquier otra persona, como un requisito funcional y comprobable independientemente de su intención.
Suscríbete y recibe las historias más importantes del día.
Al suscribirte aceptas nuestros términos y condiciones y política de privacidad.
La capacidad y la confiabilidad son cuestiones diferentes
Dar prioridad a la confiabilidad sobre la capacidad requiere repensar lo que las empresas esperan de los agentes de IA. Sharma llama a este modelo fiduciario, un término tomado de profesiones sujetas a un deber formal de cuidado, como las instituciones financieras o los proveedores de atención médica que deben a sus clientes deberes de habilidad, cuidado y lealtad. Aborda un problema crucial en la industria actual: el énfasis casi total en la competencia, con poca atención a si un agente está en deuda con los intereses del principal que le delega el trabajo.
Las pruebas parten de una definición práctica: un agente es digno de confianza si la ventaja de delegarle una tarea supera el riesgo de fracaso de esa tarea. Se trata de una ecuación formulada en términos económicos sobre la que los gestores pueden actuar directamente, y el riesgo se descompone en tres elementos:
-
confiabilidad, o si el agente se desempeña como se espera en diferentes condiciones
-
seguridad o su resistencia a ataques de actores maliciosos
-
y seguridad, o cómo quedan contenidos los daños en caso de avería.
«La puntuación resultante se puede comparar con una puntuación de crédito al consumo, pero elaborada a partir de datos de comportamiento», explica Sharma. «Mientras tanto, la metodología de prueba debe centrarse en tres P: propósito, personas y políticas».
En Vijil, las pruebas enfocadas se adaptan al flujo de trabajo específico administrado por un agente y se vuelven cada vez más difíciles o más fáciles según el desempeño, de manera muy similar a un examen administrado por computadora. Las pruebas basadas en la personalidad se basan en más de mil perfiles de usuarios demográficamente diversos, así como en perfiles de adversarios, desde hackers éticos hasta atacantes patrocinados por el estado, para simular la variedad de personas y amenazas que un agente podría encontrar. Las pruebas basadas en políticas crean un conjunto personalizado a partir de las reglas propias de una organización, ya sea de una regulación, una política de privacidad interna o pautas de marca, y miden hasta qué punto un agente se desvía al violarlas.
Fallos de confianza que sólo aparecen en producción
Es posible que muchas fallas no aparezcan durante las pruebas de preproducción porque son el resultado de un cambio en el entorno mismo. El aprendizaje automático ya ha descrito esto como fluencia de datos y de conceptos, y para un CIO o CSO, esto significa que las personas que interactúan con un agente difieren de aquellas para quienes estaba destinado el agente, y que esos usuarios se comportan de maneras que solo se vuelven visibles en producción. Al mismo tiempo, están surgiendo nuevos ataques con una frecuencia cada vez mayor a medida que las organizaciones colocan agentes de propósito general en roles empresariales especializados para los cuales no fueron diseñados y no pueden coaccionarlos fácilmente una vez desplegados.
Los sistemas multiagente también introducen una categoría completamente nueva de fallas que no pueden detectarse a nivel de agente individual, cuando los sistemas de agentes actúan en contra de los intereses del principal. Por ejemplo, la colusión puede ocurrir cuando los agentes trabajan juntos: un agente codificador genera código mientras un segundo lo prueba y, entre bastidores, ambos acuerdan dejar intacta una puerta trasera o una vulnerabilidad en lugar de informarla. O bien, los agentes distribuyen tareas o responsabilidades entre ellos en lugar de centrarse en las tareas que se les asignan.
«Lo que ya no está en duda es si esto es posible. Está demostrado», afirmó Sharma. «¿Deberíamos preocuparnos por la colusión entre agentes de IA en seis, 12, 18 meses? Creo que es antes. Hemos dejado la era de la prevención de cortes. Ahora debemos pensar en términos de resiliencia: ¿qué tan rápido nos recuperamos de los cortes de producción?»
Cómo se ve en la práctica la gestión continua de la confianza
Operacionalmente, la gestión continua de la confianza se remonta a estos antiguos principios de observabilidad y control, aplicados durante todo el ciclo de vida de una población de agentes:
El primer paso es el descubrimiento, incorporando la IA en la sombra y los agentes no gobernados al redil de la gobernanza.
El segundo es asignar a cada agente una identidad de carga de trabajo basada en estándares separada de la de su director humano, lo que permite a las organizaciones otorgar a los agentes permisos estrictamente restringidos para sus tareas delegadas.
El tercero es el control basado en políticas que se aplica a través de un punto de cumplimiento obligatorio en el agente, en lugar de dejarlo a discreción del desarrollador.
De ahí surgen dos nuevos KPI: tiempo de confianza y tiempo de recuperación. El tiempo de confianza es el tiempo que le toma a una organización pasar de la intención a una implementación de producción que pueda sostener. El tiempo de recuperación es el intervalo entre el momento en que se detecta una vulnerabilidad y el momento en que se parchea.
La nueva responsabilidad organizacional de este trabajo podría recaer en un jefe de IA o compartirse entre las funciones de GRC, CIO y CSO, dice Sharma. Al mismo tiempo, los sistemas multiagente remodelarán la forma en que las organizaciones perciben la confianza, en lugar de adaptarse a las estrechas definiciones actuales.
«La confianza no es una vibra. La confianza no es una virtud», dijo Sharma. «Es algo que se integra en la infraestructura de sus sistemas, de modo que sea continuo. Es rastreable, mensurable. Permite que sus sistemas y su organización mejoren continuamente».
Los artículos patrocinados son contenidos producidos por una empresa que paga por la publicación o tiene una relación comercial con VentureBeat y siempre están claramente marcados. Para más información, póngase en contacto ventas@venturebeat.com.
