De 80 horas a minutos: cómo IriusRisk está llevando GenAI a producción en ciberseguridad

La inteligencia artificial generativa está entrando en productos reales con una mezcla de ambición, presión y dudas razonables. En este episodio de IA lo hicieron, Berenice Pila, Director of AI en IriusRisk, comparte cómo están incorporando GenAI en un producto de ciberseguridad que ya estaba en el mercado, qué decisiones han tomado y qué aprendizajes les ha dejado el camino.

La conversación gira alrededor de un reto muy concreto: cómo acelerar el Threat Modeling sin perder calidad, trazabilidad ni control. Y, sobre todo, cómo llevar ese tipo de capacidades a producción en un entorno donde la credibilidad importa mucho.

Si quieres seguir la serie y acceder al material complementario de cada episodio, puedes suscribirte a la base de datos de IA lo hicieron. Al final del artículo también encontrarás el acceso al Playbook de esta entrevista.

• Introducción: qué cuenta este episodio de IA lo hicieron
• Qué hace IriusRisk y por qué el Threat Modeling necesita evolucionar
• De 80 horas a 8 horas y de 8 horas a minutos
• Cuándo usar GenAI y cuándo apostar por un enfoque determinista
• Cómo se formó el equipo para llevar la IA al producto
• Del laboratorio al producto: una forma de trabajar guiada por cliente y negocio
• Cómo se integra la IA en el flujo del producto
• Cómo eligen modelos y por qué usan una estrategia multi-modelo
• RAG en dos iteraciones: rediseñar cuando la primera versión no llega
• Memoria, contexto y documentos: qué guardar y qué no
• Cuatro arquitecturas agénticas para cuatro tipos de problemas
• Guardrails, evaluación continua y control de costes
• Las tres decisiones que Berenice Pila considera clave para llevar GenAI a producción
• Suscríbete a IA lo hicieron y accede al Playbook de la entrevista
• Conclusión

El foco de este episodio no está en la teoría general sobre GenAI, sino en las decisiones reales que aparecen cuando una empresa intenta introducir esta tecnología en un producto que ya resuelve un problema concreto. En este caso, IriusRisk trabaja en un ámbito especialmente sensible: la ciberseguridad.

Berenice explica cómo han ido incorporando IA para acelerar partes del flujo, mejorar la experiencia de usuario y dar más valor a sus clientes. Pero también deja claro que no se trata de meter GenAI “porque sí”. En la conversación aparecen preguntas muy reconocibles para cualquier equipo que esté haciendo este recorrido: cuándo tiene sentido usar IA, cómo formar el equipo, cómo elegir modelos, cómo iterar un RAG que no llega al listón esperado o cómo plantear guardrails, evals y control de costes.

IriusRisk trabaja en Threat Modeling, una rama de la ciberseguridad orientada a modelar amenazas desde el punto de vista del diseño. Tal y como explica Berenice, no se trata de una práctica reactiva que llega cuando el sistema ya está en producción, sino de una forma de analizar diagramas, información del sistema y cambios previstos antes de desplegar.

A partir de esa información, el software genera modelos de amenazas y recomendaciones. El objetivo es que los equipos puedan identificar riesgos antes de poner cambios en producción. Berenice subraya además que este trabajo impacta en sistemas que todos usamos cada día, como sistemas bancarios, de salud o cualquier entorno con datos sensibles.

El problema de partida era claro. Los equipos de seguridad de sus clientes no podían abarcarlo todo. Con equipos pequeños y tiempo limitado, lo habitual era centrarse en lo más crítico y dejar fuera una larga cola de sistemas y casos menos prioritarios. El valor del producto, por tanto, no era solo ahorrar tiempo, sino liberar capacidad para que esos equipos pudieran cubrir más superficie con confianza y trazabilidad.

Berenice resume bien la evolución del producto con una secuencia muy concreta. Antes del software, modelar un sistema a mano podía llevar en torno a 80 horas. Con el software de IriusRisk, ese tiempo pasó a una media de 8 horas. Y con la introducción de IA en partes del flujo, algunas de esas etapas han pasado de horas a minutos.

Ese salto no se presenta como una sustitución del equipo humano. De hecho, Berenice insiste en que el objetivo no es quitar gente, sino liberar a equipos de ciberseguridad que ya estaban limitados por tamaño y capacidad. Gracias a esa aceleración, sus clientes pueden modelar muchos más sistemas y acercarse a una cobertura mucho más amplia.

En concreto, la IA les ayuda a automatizar la incorporación de datos del sistema, generar diagramas de forma automática, preparar cuestionarios para validación y avanzar hacia la generación del modelo de amenazas. También introducen una capa de análisis que facilita navegar amenazas y vulnerabilidades de forma más inteligente, con filtros y consultas en lenguaje natural para priorizar riesgos y decidir dónde invertir tiempo.

Uno de los mensajes más claros de toda la entrevista es que, para Berenice, si algo se puede hacer de forma determinista, es mejor hacerlo de forma determinista. Lo dice de forma explícita: tiene menos costes, menos incertidumbre y evita reinventar soluciones que ya existen.

Por eso, la decisión de introducir GenAI no vino de la moda, sino del tipo de problema que tenían delante. En su caso, estaban trabajando con datos no estructurados, alta variabilidad entre clientes y la necesidad de comprender y procesar lenguaje natural. Además, cada cliente podía trabajar con proveedores, componentes y sistemas muy distintos, desde banca hasta hardware, lo que hacía muy difícil abarcar todos los casos con reglas programáticas y excepciones mantenibles.

Berenice explica que intentar resolver ese nivel de variabilidad con lógica basada en reglas llevaba a árboles muy profundos, monolíticos, poco flexibles y complejos de cambiar. Ahí es donde vieron que la flexibilidad y adaptabilidad de la IA sí aportaban una ventaja real. Y, según cuenta, la adopción de los clientes y los resultados internos refuerzan esa decisión, aunque sin ocultar que siguen apareciendo retos cuando llegan sistemas especialmente complejos o con volúmenes muy altos de componentes.

En la conversación también aparece un tema clave para muchos equipos: cómo montar la estructura adecuada para llevar IA a producción. Berenice explica que IriusRisk partía de un equipo fuerte en plataforma y producto SaaS, pero sin experiencia previa en Machine Learning.

La empresa valoró formar internamente a personas del equipo, pero concluyó que era un proceso demasiado lento para el momento que vivían y para la velocidad con la que el mercado pedía soluciones. Además, en un contexto como la ciberseguridad, entregar algo sin el nivel de calidad esperado podía dañar la credibilidad con los clientes.

Por eso decidieron incorporar talento externo y construir el equipo desde cero con perfiles que ya tuvieran exposición a GenAI, NLP o Machine Learning. En sus entrevistas, según cuenta Berenice, no buscan solo gente que conozca lo último o que repita términos de moda. Les importa mucho el conocimiento técnico, pero también la mentalidad práctica, la orientación a resolver problemas, la afinidad con negocio, la comprensión de la calidad, la fidelidad y la reproducibilidad, y la capacidad crítica para no sacrificar criterio por velocidad.

Otra idea muy repetida en la entrevista es que en IriusRisk no les funciona el modelo de laboratorio. Berenice lo plantea de forma muy directa: al ser una empresa de software como servicio, trabajan con una mentalidad muy cercana al cliente y al producto, y eso condiciona cómo experimentan.

Sí hay espacio para probar y fallar, pero no para hacerlo sin dirección. La lógica que describe es otra: experimentar rápido, aprender rápido y estar guiados por necesidades reales. Habla de iniciativas que nacen como prototipo, se ponen delante del cliente para recoger feedback y, si la respuesta es positiva, entran en el ciclo habitual de evolución del producto.

Ese ciclo pasa por introducir primero una alfa, luego una beta y, más adelante, una versión completa. También insiste en evitar los proyectos “submarino”, esos que desaparecen durante meses y reaparecen al final. Para ella, la entrega incremental reduce riesgo, permite corregir el rumbo y genera confianza porque el valor se va mostrando paso a paso.

En IriusRisk no han optado por un copilot general dentro del producto. Berenice explica que la IA se integra en partes concretas del flujo, y que esa decisión está muy conectada con el trabajo transversal con el equipo de producto y diseño.

Según cuenta, la colaboración con producto empieza desde la idea, incluso antes de programar nada. Hacen discovery, analizan fricciones, trabajan el encaje de cada iniciativa y deciden dónde la IA puede mejorar realmente la experiencia. En algunos casos, las propias ideas salen del equipo de producto, que conoce muy bien cómo navegan los usuarios por el software y dónde aparecen los puntos de fricción.

A partir de ahí, iteran bastante para comprobar que la interacción es natural, intuitiva y coherente con el flujo del producto. También usan releases progresivas para validar cómo responde el usuario real y ajustar lo que haga falta antes de abrir más el acceso.

La elección de modelos en IriusRisk responde a un criterio claramente pragmático. Berenice cuenta que trabajan con varias familias de modelos fundacionales y que su filosofía es ser bastante agnósticos: utilizar lo que mejor funcione para cada caso, siempre teniendo en cuenta el coste y el retorno.

Uno de los ejemplos más concretos que comparte tiene que ver con un servicio donde necesitaban manejar muchísimo contexto. En ese caso, la ventana de contexto se convirtió en un factor limitante y eligieron Google Gemini porque era la opción que les permitía introducir toda la información necesaria. El resto de ventajas o desventajas del modelo tenían que compensarlas luego con prompting, ajustes y evaluación.

También hacen benchmarking periódico cuando aparecen nuevos modelos. Si hay que cambiar, cambian. Berenice lo resume con una idea sencilla: no hay que cogerle cariño a las herramientas. Además, dentro de sus sistemas agénticos no usan necesariamente la misma familia ni la misma versión de modelo para todos los agentes. En tareas distintas usan modelos distintos, y para agentes críticos que evalúan la respuesta de otros también consideran útil combinar familias diferentes para evitar sesgos compartidos.

Uno de los bloques más concretos de la entrevista es el del RAG. Berenice explica que ya han pasado por dos iteraciones. La primera resolvía parte del problema, pero no alcanzaba el nivel de calidad que necesitaban.

El caso de uso que describe consiste en traducir lo que dicen los clientes a un lenguaje que el núcleo del software pueda entender. El core de IriusRisk trabaja con librerías y componentes bien definidos, pero los clientes no siempre nombran esos elementos de forma estándar. Algunos usan nombres claros, otros usan términos ambiguos y otros directamente envían nombres que no permiten inferir nada útil.

La primera versión del RAG ayudaba, pero no llegaba al nivel de aceptación que querían. Por eso decidieron rediseñarlo. La versión actual incorpora nuevas tecnologías, anotadores que enriquecen contexto y dos modelos internos de NLP y NLU entrenados por ellos para capturar mejor jerarquías, semántica y señal útil en el re-ranking. Además, también tuvieron que trabajar cuestiones de escalabilidad y arquitectura de base de datos vectorial para soportar un crecimiento previsto en usuarios concurrentes.

La gestión de memoria también aparece como una decisión muy condicionada por la sensibilidad de los datos. Berenice explica que, en general, prefieren trabajar con una lógica de memoria efímera ligada a la propia sesión.

Tiene sentido con el tipo de clientes con el que trabajan. Cuanta menos información persistan, más cómodos se sienten muchos de esos equipos. La principal excepción que menciona es la de los PDFs y documentos. Ahí sí ven valor claro en guardar información, porque no sería práctico pedir al usuario que vuelva a subir una y otra vez la misma documentación para poder aprovechar la IA.

Esa persistencia se plantea para que el sistema pueda analizar documentos que describen sistemas, políticas, controles o estándares y utilizar esa información para ayudar al usuario. Berenice también comenta un aprendizaje técnico importante: no solo importa la cantidad de memoria o de contexto, sino la versión del modelo y su capacidad de atención sobre esa memoria. Es un punto que, según cuenta, les ha generado bastante fricción en algunos momentos.

IriusRisk no utiliza una única arquitectura agéntica. Berenice habla de cuatro enfoques distintos y explica que el equipo escoge uno u otro según la naturaleza del problema.

La arquitectura jerárquica la usan en procesos de extracción y comprensión donde el flujo está muy definido. Ahí empezaron con un único agente, encontraron problemas de memoria y decidieron especializar tareas y ordenar los handovers entre agentes.

También tienen sistemas por pares, donde un agente ejecuta y otro critica. Según cuenta, esto les encaja bien en procesos de decisión donde las preguntas del usuario están relativamente bien definidas y pueden construir pares especializados para distintos tipos de consulta.

En otros casos usan una arquitectura tipo swarm, más útil cuando la información está más dispersa y el problema es más complejo. Ahí los agentes interactúan, compiten, colaboran y van construyendo una conclusión a partir de señales parciales. Además, menciona una arquitectura peer-to-peer. Más allá de los nombres, lo importante de este bloque es que no están intentando resolver todo con una sola forma de orquestar agentes, sino adaptando la estructura al problema.

La parte menos vistosa de la IA en producción ocupa bastante espacio en la entrevista, y con razón. Berenice insiste en que los guardrails son una de las primeras cosas que hay que poner y que no son opcionales. En su caso, los colocan al inicio de la interacción para controlar desde el principio el abuso, la desviación de tema, el tipo de lenguaje o intentos como el prompt injection.

Cuenta incluso una anécdota interna bastante ilustrativa: un usuario consiguió, a base de deriva en la conversación, que el sistema escribiera una canción sobre ciberseguridad. No hubo fuga de datos ni salida del ámbito temático, pero sí una desviación clara de tarea. Y eso, en un producto serio, ya es un problema reputacional.

En cuanto a la evaluación, explica que al principio fue especialmente dura porque no retenían datos de cliente y no partían de una base propia amplia. La forma de construir evals fue recoger casos reales que fallaban, pedir permiso, anonimizar y añadirlos a su fuente de verdad. También comenta que los datos sintéticos son mejores que nada, pero que siempre arrastran sesgos del humano que los crea y no recogen bien toda la casuística del uso real.

Sobre costes, la gestión también ha ido evolucionando. Han introducido límites en el número de interacciones para evitar loops innecesarios, y están observando con atención cómo cambian los consumos en nuevas funcionalidades donde los usuarios podrán hacer más preguntas abiertas. En algunos casos, como la edición Community, ya contemplan límites claros de uso.

Al final de la entrevista, Berenice resume tres decisiones que para ella han sido especialmente importantes.

1. La primera es ser muy honesto con el valor esperado. No empezar un proyecto de IA porque sea la palabra de moda, sino porque existe un retorno claro, ya sea en optimización interna o en valor entregado al cliente.
2. La segunda es estructurar desarrollo y entrega de forma incremental. Mostrar valor pronto, reducir riesgo, aprender sobre la marcha y corregir el rumbo antes de haber invertido meses en una sola dirección.
3. La tercera es entender que hacer IA es un deporte de equipo. No basta con tener buenos ingenieros o buenos perfiles de negocio por separado. Hace falta trabajo multidisciplinar, colaboración con producto, con perfiles cercanos al cliente, con expertos del dominio y con el resto de especialidades que participan en el producto.

Si te interesa seguir aprendiendo de casos reales sobre cómo se está introduciendo GenAI en productos de producción, puedes suscribirte a la base de datos de IA lo hicieron para recibir los próximos episodios.

Y si quieres profundizar en esta conversación, también puedes acceder al Playbook de la entrevista con Berenice Pila.

Además, si todavía no lo has leído, también puedes consultar el post de LambdaLoopers que explica qué es IA lo hicieron y a quién va dirigida la serie.

La conversación con Berenice Pila deja una idea bastante nítida: llevar GenAI a producción no consiste solo en añadir un modelo a un producto. Exige decidir bien dónde aporta valor, formar el equipo adecuado, iterar con criterio, aceptar rediseños cuando algo no llega al nivel esperado y tomarse muy en serio la operación real.

En el caso de IriusRisk, ese recorrido se está haciendo en un entorno donde la exigencia es alta y donde la credibilidad importa. Precisamente por eso, el episodio resulta especialmente útil para cualquier equipo que esté intentando introducir IA generativa en producto sin perder el foco en calidad, control y utilidad real.