Por qué Sophos se ha convertido en su propio laboratorio de pruebas de IA

Todos los proveedores de seguridad hablan de la IA que tienen en sus productos. Pero muy pocos te dirán cómo usa su propio personal la IA: qué agentes se ejecutan en sus procesos de ingeniería, a qué datos tienen acceso esos agentes y quién decidió que eso era aceptable. Esa segunda conversación, en nuestra opinión, es igual de importante. Cuando contratas a un proveedor, no solo heredas su software; heredas su criterio. Así que aquí te contamos cómo adopta Sophos la IA internamente: cómo valoramos los riesgos, cómo los gestionamos y en qué aspectos seguimos aprendiendo.

Por qué estamos a la vanguardia

Para una empresa de seguridad sería fácil ser la cautelosa: dejar que otros cometan los errores y extraer las lecciones después. Nosotros hemos adoptado deliberadamente la postura contraria: para Sophos, el mayor riesgo es quedarse quieto. Nuestros clientes ya están implementando agentes de IA en producción. Si queremos seguir protegiéndolos, tenemos que entender los riesgos de primera mano; a ser posible, antes de que se enfrenten a ellos.

Ejecutamos IA en producción porque no puedes defenderte de lo que nunca has puesto en marcha. Las rutas de inyección de comandos, las llamadas a herramientas con privilegios excesivos, las identidades no humanas que acumulan acceso de forma silenciosa… Todo esto solo se vuelve intuitivo una vez que has puesto en marcha agentes en entornos reales, has visto cómo fallan y has analizado esos fallos. Por eso aplicamos las herramientas de los agentes a nuestro propio entorno antes que al de nadie más: hemos soltado un marco de agentes autónomos en una red interna para ver hasta dónde podía llegar, hemos usado modelos de vanguardia para buscar vulnerabilidades en nuestros propios productos antes de que los adversarios se beneficien de lo mismo, y hemos replanteado cómo son los programas de recompensas por errores cuando es la IA la que los encuentra. Todo lo que aprendemos mejora las detecciones que lanzamos y da forma al rumbo que tomará la hoja de ruta del producto, con el fin de apoyar a nuestros clientes.

Esto se aplica a toda la empresa, pero doblemente al equipo de seguridad. Si un equipo de seguridad no es capaz de averiguar cómo adoptar la IA de forma segura y rápida, es difícil ver quién lo hará. Una organización con un CISO que prohíbe lo que no entiende corre el riesgo de entender muy poco en un par de años. Y con una avalancha de vulnerabilidades acelerada por la IA que ya está llegando, los defensores que hayan desarrollado esa comprensión serán los que salgan adelante.

Cómo vemos el riesgo: una brújula, no una lista de comprobación

Ir a la vanguardia sin usar el juicio es pura imprudencia. Internamente, nuestra filosofía de riesgo cabe en una página y se resume en seis palabras: asume riesgos más inteligentes, entrega más rápido, gánate la confianza. La esencia es distinguir entre los riesgos buenos y los malos. Los riesgos buenos tienen un beneficio significativo, un alcance limitado, una vía de retorno, un responsable claro y una hipótesis de la que realmente aprenderemos. Los riesgos malos tienen un daño ilimitado, carecen de plan de recuperación, tienen una responsabilidad poco clara… o prescinden del juicio humano: los cambios automatizados o impulsados por agentes que afectan directamente a los clientes sin la supervisión suficiente son un mal riesgo, independientemente del beneficio que ofrezcan.

La mayoría de las decisiones no se anuncian como tal. Por eso situamos cada apuesta en una brújula sencilla, con dos ejes: potencial de beneficio (alto o bajo) y riesgo de pérdida (controlado o ilimitado).

Figura 1: la brújula de riesgo de Sophos

La realidad es que la mayoría de las apuestas actuales en IA autónoma empiezan en el cuadrante superior derecho: alto potencial de beneficio, riesgo de pérdida ilimitado. La clave está en reducir el alcance del impacto hasta que se desplacen hacia la izquierda: «solo lectura» antes que «escritura», «interno» antes que «orientado al cliente», un flujo de trabajo antes que todo un conjunto. El trabajo consiste en reducir el riesgo, no en poner trabas. Alrededor de la brújula hay cinco aspectos innegociables —la confianza del cliente, la seguridad, la protección, la privacidad y la estabilidad operativa— con los aspectos legales y de cumplimiento entretejidos en cada uno de ellos. Ser inflexibles con estos puntos es precisamente lo que nos permite ser agresivos en todo lo demás. Cuando evalúes la postura de cualquier proveedor respecto a la IA, esta es la estructura que vale la pena buscar: un marco claro para decir «sí», anclado en límites explícitos para decir «no».

El Consejo de Seguridad de la IA: gobernanza a la velocidad de la adopción

Un marco solo sirve de algo si realmente se toman decisiones basándose en él. Los casos de uso de la IA iban surgiendo más rápido de lo que cualquier ciclo de gobernanza tradicional podía procesar, y casi nunca encajaban en el molde de una evaluación clásica de proveedores o una revisión de seguridad. Nuestra respuesta es el Comité de Seguridad de la IA: un pequeño grupo multifuncional de profesionales —de seguridad, ingeniería, producto, TI, asuntos legales, RR. HH. y equipos de atención al cliente— presidido por mí, como CISO. Está diseñado para tomar decisiones: una reunión mensual de treinta minutos, el trabajo real se hace de forma asíncrona, y su cometido es tomar decisiones rápidas y prácticas sobre usos novedosos o de alto riesgo de la IA (nuevas herramientas, flujos de trabajo autónomos, patrones de riesgo emergentes).

Lo más importante es que el comité se sitúa por encima de nuestros procesos de evaluación de riesgos de proveedores y de revisión de seguridad, en lugar de sustituirlos. Esos procesos siguen gestionando en masa los casos bien conocidos. Cuando surge algo nuevo o realmente ambiguo —un agente con un perfil de privilegios inusual, un caso de uso sin precedentes—, se remite al comité, y la respuesta de este vuelve a los equipos como directriz permanente, actualizada casi en tiempo real. El enfoque que usamos internamente es el siguiente: si no estás seguro de cómo hacer algo con la IA, usa los canales existentes; si no estás seguro de si deberías hacerlo, pregúntale al comité. Las herramientas y los patrones se clasifican de forma deliberadamente sencilla —permitir, investigar, tolerar, denegar—; se mantiene un enfoque ágil y se revisa a medida que aprendemos.

Cuando el comité detecta patrones de solicitudes similares, redacta una política que define un límite en lugar de enumerar herramientas. Nuestra primera política permanente abarcaba los modelos de IA locales: cualquier cosa que cumpla con el límite de que «los datos no salgan del dispositivo» ya no necesita una revisión de seguridad por herramienta. Cuando esa política entró en vigor, cerramos la cola de tickets de revisión individuales a los que sustituía. Una gobernanza que reduce el atraso en las revisiones se gana una reputación muy diferente a la que lo aumenta.

Y como debemos predicar con el ejemplo, la propia junta funciona de forma nativa con IA. Un agente de IA compartido actúa como su brazo administrativo: resume los debates, hace un seguimiento de las acciones y da un recordatorio a los responsables, redacta órdenes del día, documentos de políticas y comunicaciones para toda la empresa, y saca a la luz de forma proactiva propuestas interesantes relacionadas con la IA que vienen de la cola de revisión, junto con incidentes externos relevantes. Todo lo que se publica externamente pasa por un proceso de aprobación: el agente redacta el borrador y un miembro humano de la junta lo aprueba antes de que se publique nada. Los altos cargos dedican su tiempo a tomar decisiones; el agente se encarga de la logística. Se trata, deliberadamente, de una demostración en directo del modelo operativo que pedimos al resto de la empresa que siga. Si eres un cliente y te preguntas cómo se aprueba un nuevo caso de uso de IA en Sophos, este es el mecanismo y la velocidad a la que funciona.

La parte difícil: los patrones de seguridad aún se están definiendo

Esta es la parte que los proveedores no suelen decir en voz alta: nadie ha definido del todo los patrones de seguridad, ni siquiera nosotros. Los equipos de ingeniería van más adelantados. Están surgiendo patrones de desarrollo claros para la creación con IA. Los equipos de seguridad aún no tienen un manual equivalente. ¿Cómo se revisa la seguridad de un flujo de trabajo basado en agentes que se reescribe a sí mismo cada semana? ¿Cómo es la respuesta ante incidentes en el caso de un agente comprometido? ¿Cómo se supervisa un conjunto de identidades no humanas que actúan en lugar de limitarse a sugerir? Ahora mismo, esas preguntas se responden principalmente con criterio, no con patrones, y fingir lo contrario no ayuda a nadie.

Escribí sobre una parte de esta brecha en Cómo trabajar con la «tríada letal»: las implementaciones de agentes más útiles combinan datos privados, contenido no fiable y comunicación externa —exactamente la combinación que hace que la inyección inmediata sea peligrosa—, por lo que la disciplina práctica consiste en reducir el radio de impacto en lugar de buscar la pureza de los patrones. A nivel interno, eso significa tratar los entornos de agentes como una superficie de seguridad de primer orden —gobernanza centralizada de las plataformas de IA, telemetría de toda la actividad de los agentes, detección de comportamientos anómalos en los agentes— integrada desde el principio, no añadida a posteriori. Seguiremos publicando lo que funciona y, lo que es igual de importante, lo que no.

Por desgracia, nuestro intento de ofrecer algunas medidas técnicas de mitigación de riesgos también ha puesto de relieve lo complejo que es este problema. Como escribió recientemente nuestro director general, Joe Levy, sobre la línea de pobreza en ciberseguridad, de los aproximadamente 359 millones de empresas que hay en el mundo, menos de 35 000 cuentan con un CISO. La ingeniería del «radio de impacto» en el enfoque de la «tríada letal» es precisamente el tipo de trabajo pesado que las organizaciones por debajo de esa línea, sin un CISO o equivalente, no pueden asumir. Esa realidad también influye en nuestro trabajo de producto: gran parte del razonamiento detrás de Sophos Fusion consiste en integrar ese criterio en el propio sistema de defensa, para que las organizaciones que no pueden encargarse de la ingeniería no se vean obligadas a elegir entre prohibir la IA o quedar expuestas a ella. Pero eso es tema para otro artículo. La idea aquí se sostiene por sí sola: los patrones están surgiendo, y seguiremos compartiendo los nuestros a medida que se vayan definiendo.

Qué significa esto si estás evaluando a Sophos o a cualquier otro proveedor

Nada de esto quiere decir que Sophos haya terminado de entender la IA; lo que queremos decir es que la estamos entendiendo de forma deliberada, de manera abierta, adelantándonos a la amenaza en lugar de ir a la zaga. Si estás valorando a cualquier proveedor, incluidos nosotros, las preguntas sobre IA que vale la pena hacer no tienen que ver con los nombres de los modelos. Pregunta quién decide cuándo es aceptable un nuevo caso de uso de la IA y cuánto tiempo lleva tomar esa decisión. Pregunta qué es lo que no dejan que haga la IA y si pueden definir los límites. Pregunta qué han aprendido de un experimento con IA que haya fallado. Los proveedores que han reflexionado sobre esto suelen tener respuestas claras; los que simplemente han prohibido la IA, o simplemente le han dado rienda suelta, a menudo no las tienen.

Ya hemos escrito antes sobre el alto coste de la falta de confianza, y este artículo forma parte del mismo compromiso: mostrar nuestro proceso de trabajo, no solo nuestras conclusiones. Los riesgos inteligentes se acumulan. Lo mismo ocurre con la confianza, y ambos se ganan de la misma manera: de forma deliberada, transparente y pública.