Vin Sharma, cofundador y director ejecutivo de Vijil – Serie de entrevistas

Vin Sharma es cofundador y director ejecutivo de Vijil y cuenta con más de 30 años de experiencia en ciberseguridad, código abierto, computación en la nube e infraestructura de IA. Antes de fundar la empresa, dirigió proyectos de ingeniería de aprendizaje profundo en AWS para Amazon SageMaker y Amazon Bedrock, desarrolló infraestructura para centros de datos en Intel y ocupó puestos de producto e ingeniería en Hewlett-Packard. Su carrera comenzó con pruebas automatizadas de equipo rojo para sistemas UNIX de confianza, una experiencia que fundamenta su enfoque en lograr que los agentes de IA empresariales sean fiables, seguros y protegidos.

Vijil ofrece infraestructura de confianza para agentes de IA empresariales y ayuda a las organizaciones a evaluar su comportamiento, aplicar controles y mejorar su resiliencia a lo largo del ciclo de vida de los agentes. Su enfoque combina pruebas, seguridad y retroalimentación continua para adaptar el comportamiento de los agentes al propósito previsto y a las políticas de una organización. En esta entrevista, Sharma habla sobre cómo definir y medir la confianza, por qué las pruebas de agentes difieren de las pruebas convencionales de seguridad del software y qué supervisión necesitan las empresas a medida que los agentes adquieren autonomía.

Trabajó durante más de 30 años en empresas como AWS, Intel y Hewlett-Packard antes de fundar Vijil. ¿Qué terminó por convencerlo de que la confianza y la seguridad de la IA constituían un problema sin resolver lo bastante importante como para crear una empresa en torno a él?

Antes de incorporarme a una empresa emergente de seguridad, hace 30 años, cursaba estudios de posgrado sobre IA y aprendizaje automático. Desde entonces, he trabajado en equipos de producto que incorporaron seguridad de nivel militar a sistemas operativos basados en Unix y Linux; desarrollaron servidores web seguros para la banca en línea; crearon entornos de ejecución de confianza para la computación en la nube; integraron cifrado en plataformas de análisis de datos y, más recientemente, me llevaron de vuelta al punto de partida, a desarrollar servicios de IA y aprendizaje automático listos para empresas en AWS. Ese recorrido me dejó convencido de que incorporar confianza a un sistema de inteligencia es más difícil que construir el propio sistema inteligente. Aunque la industria de la IA parece estar ampliamente comprometida con aumentar las capacidades de los agentes, creo que debemos invertir tantos recursos en dotarlos de mecanismos escalables de supervisión y control. Sin métricas y mecanismos adaptados a las necesidades de cada organización, la ola inicial de adopción entusiasta acabará encallando en los bancos de arena del riesgo y el ROI, porque las empresas no podrán demostrar que sus agentes actúan en su mejor interés.

Vijil parte de la idea de que muchos agentes de IA nunca llegan a producción porque las empresas no pueden verificar adecuadamente su fiabilidad, seguridad y protección. ¿Dónde observa las mayores brechas de confianza a medida que las compañías pasan de los prototipos de IA a su implementación en producción?

El principal obstáculo para implementar más agentes con niveles crecientes de autonomía es que las organizaciones puedan especificar el comportamiento previsto de sus agentes y verificar que estos se comporten según lo previsto. Y no solo eso: deben poder hacerlo a la escala y la velocidad a las que operan los agentes. Es lógico que necesitemos una forma de que los agentes midan y modifiquen el comportamiento de otros agentes. Dos de las mayores brechas consisten en saber qué medir (qué significa que un agente sea bueno) y qué modificar (qué componentes del sistema del agente hay que ajustar para inducir el comportamiento que pretende la entidad que lo dirige: el modelo y sus parámetros, la instrucción del sistema, las instrucciones del usuario, la estructura de ejecución del agente o el grafo de sistemas multiagente).

¿Cómo define y mide Vijil la «confianza» en un agente de IA, y qué señales o parámetros de referencia son más importantes para determinar si un agente está listo para operar en un entorno empresarial?

Definimos la confianza como el beneficio previsto de delegar tareas en un agente autónomo, descontado el riesgo de que traicione nuestra intención. Esto significa que se puede confiar en un agente si se comporta correctamente en condiciones normales, ruidosas y hostiles y, cuando falla, minimiza el alcance de los daños. A continuación, podemos medir la confianza según tres pilares: fiabilidad, seguridad y protección. Los agentes son fiables cuando se desempeñan según lo previsto en diversas condiciones; son seguros cuando lo hacen en condiciones hostiles, y ofrecen protección cuando pueden minimizar los riesgos empresariales, legales y técnicos.

Los agentes de IA pueden comportarse de forma impredecible porque combinan modelos, herramientas, fuentes de datos, memoria y sistemas externos. ¿En qué se diferencian las pruebas de un agente de las pruebas tradicionales de seguridad de aplicaciones o de la evaluación convencional de modelos?

El software tradicional falla de maneras que hoy conocemos bien. En términos generales, esto incluye la incapacidad para gestionar entradas malformadas, debilidades en la lógica y el diseño del sistema, errores de implementación, vulnerabilidades ocultas frente a ataques y efectos secundarios imprevistos de los resultados. Es razonablemente predecible probar si se producen estos fallos. Los agentes amplían enormemente la superficie de fallo. Tanto, que la evaluación de modelos, las pruebas unitarias, las pruebas de integración, las pruebas de seguridad de aplicaciones, las pruebas de penetración y las verificaciones de cumplimiento normativo no pueden abarcarla por completo. Para probar la nueva superficie de riesgo de los agentes, necesitamos nuevas métricas y mecanismos que evalúen su comportamiento con respecto al propósito especificado por la entidad que los dirige, las características de sus usuarios y las políticas de la organización, el sector y la región en los que operan.

Tu trayectoria incluye liderar iniciativas de ingeniería de aprendizaje profundo para Amazon SageMaker y Amazon Bedrock. ¿Qué aprendizajes de la creación de infraestructura de IA en AWS han influido más en tu enfoque de la seguridad y la fiabilidad de los agentes en Vijil?

La enseñanza más decisiva fue que detectar pronto los problemas de fiabilidad, seguridad y cumplimiento de los servicios durante el ciclo de desarrollo era mucho más eficaz y eficiente que descubrirlos en vísperas del lanzamiento, como se hacía tradicionalmente, o, peor aún, después de que el servicio ya estuviera en producción, cuando uno se despertaba con llamadas para avisar de que el servicio estaba fallando.

Vijil no solo se centra en probar los agentes antes de su implementación, sino también en protegerlos y mejorarlos continuamente en producción. ¿Qué tipos de riesgos solo se hacen visibles cuando un agente empieza a interactuar con usuarios, datos y sistemas empresariales reales?

El mundo real tiene una capacidad infinita para sorprendernos. Y un agente sorprendido es un agente propenso a cometer errores. A nadie le preocupa que un agente se equivoque al generar un meme. En cambio, un agente diseñado para ayudar o sustituir a un asesor financiero, un asistente jurídico, un abogado, un enfermero, un médico, un paciente o cualquier profesional de un sector en el que haya que demostrar un comportamiento fiduciario no puede funcionar a menos que los niveles de tolerancia estén bien delimitados, se supervisen cuidadosamente y el comportamiento del agente se restablezca con rapidez.

A medida que las empresas implementan agentes cada vez más autónomos, capaces de ejecutar acciones en lugar de limitarse a generar respuestas, ¿cómo debe evolucionar el modelo de seguridad? ¿Son suficientes conceptos tradicionales como los permisos, la identidad y el control de acceso?

No. A medida que los agentes se convierten en actores dentro de una organización, necesitan identidades únicas que puedan verificarse; se les deben asignar roles que rijan tanto su comportamiento como sus componentes funcionales (herramientas con permisos de acceso a recursos), junto con políticas obligatorias de control de acceso; hay que supervisarlos continuamente para detectar desviaciones del propósito previsto y orientarlos para que mantengan su resiliencia frente a los ataques.

Vijil ha pasado de una ronda de financiación semilla de 6 millones de dólares a una Serie A de 17 millones, mientras formaba un equipo fundador de unas 20 personas y alcanzaba su primer millón de dólares en ingresos recurrentes anuales. ¿Cuáles fueron las decisiones más importantes que les permitieron pasar de un concepto técnico inicial a la adopción comercial?

Desde el principio, optamos por crear una capa de confianza que se integrara con la plataforma elegida por el cliente, pero previmos que las empresas buscarían cada vez más personalización, un control más granular y menores costos para los sistemas multiagente que usan modelos abiertos. La apuesta a largo plazo por crear una capa de plataforma en lugar de un producto puntual nos ofrece ventajas competitivas, pero también plantea retos: encontrar empresas preparadas para gobernar agentes a gran escala no es tan sencillo como vender un servicio de migración directa.

Comenzaste tu carrera desarrollando pruebas automatizadas de equipos rojos para sistemas UNIX confiables en 1995. Casi tres décadas después, ¿cómo han cambiado los principios de los equipos rojos cuando el sistema que se evalúa es un agente de IA capaz de razonar, adaptarse y usar herramientas externas?

Históricamente, las pruebas de equipos rojos consistían en poner a prueba las defensas de una organización frente a un ataque coordinado. Los principios generales siguen vigentes. Aún necesitamos coordinar ataques en condiciones controladas para detectar los puntos débiles de la organización evaluada. Sin embargo, la etapa intermedia en la que los ejercicios de equipos rojos se basaban en guiones para probar sistemas de software ya no resulta adecuada, porque los agentes de IA no son como el software determinista: están diseñados para adaptarse a su entorno, de modo que no se puede repetir el mismo ataque de forma predecible. Sostengo que los agentes deberían tratarse como empresas. Por tanto, las pruebas de equipos rojos para agentes deben adaptarse necesariamente al propósito del agente, indagar si se desvía de las intenciones de sus usuarios y evaluar su voluntad y capacidad para eludir las políticas de su entorno.

De cara al futuro, ¿crees que las pruebas independientes y los estándares cuantificables de confianza para los agentes de IA se convertirán en un requisito previo para su implementación en empresas? ¿Qué debe ocurrir en el sector para que ese nivel de garantía se convierta en una práctica habitual?

Hoy, quienes desarrollan agentes evalúan sus capacidades, los equipos rojos comprueban su resistencia a las inyecciones de instrucciones y a los ataques para eludir las salvaguardas, y los equipos de gobernanza, riesgo y cumplimiento (GRC) apenas están empezando a evaluar su conformidad con la normativa. Muy pocas organizaciones establecen un régimen de verificación del comportamiento que funcione continuamente en segundo plano durante todo el ciclo de vida del agente, a medida que cambian los modelos, las herramientas, los recursos, los flujos de trabajo y el entorno de destino. Más importante aún, Vijil ayuda a las empresas de una manera singular al rastrear el comportamiento real del agente en producción hasta su especificación, mediante un ciclo de retroalimentación que mejora continuamente al agente. Los agentes que sobreviven a los ataques son los que se adaptan para mantener su resiliencia.

Gracias por esta excelente entrevista. Los lectores que deseen obtener más información sobre cómo probar, proteger y mejorar continuamente los agentes de IA empresariales pueden visitar Vijil.