La Inteligencia Artificial (IA) está cambiando la forma en que se desarrolla el software. Hoy, un asistente funcional, un agente o una primera versión de una funcionalidad pueden construirse en horas, en lugar de semanas. A medida que Santander amplía el uso de la IA en ingeniería de software, atención al cliente, operaciones y gestión del riesgo, esa velocidad plantea un nuevo reto: demostrar que los productos de IA son fiables, seguros y justos, y que siguen siéndolo a medida que evolucionan.
Este proceso de verificación, y el reto asociado, comienza con una pregunta de IA Responsable. Antes de poner un producto conversacional frente a los clientes, los equipos necesitan saber que el sistema respetará sus límites, tratará a los clientes con justicia y no responderá de una forma sesgada, insegura o simplemente incorrecta. Estas revisiones nacen de la propia práctica de IA Responsable de Santander, en la que los equipos ya estaban poniendo a prueba sistemas conversacionales y basados en agentes. El objetivo de esos análisis es detectar riesgos que las pruebas habituales suelen pasar por alto, tales como respuestas sesgadas o incoherentes, respuestas inseguras y posibles manipulaciones que solo aparecen tras varias interacciones. La demanda de los equipos era tan transversal y constante que la revisión manual tuvo que convertirse en algo mayor. La solución pasó por establecer una capacidad de todo el banco que comprobaba automáticamente esas cuestiones de IA Responsable y seguía haciéndolo a lo largo de toda la vida del producto, en lugar de hacerlo solo una vez antes del lanzamiento.
El responsable técnico de esta iniciativa dentro del equipo de Data & AI Science, Andrés Herranz, explica que “partimos de una pregunta de IA Responsable (si este sistema es seguro y justo, y cómo lo sabríamos) y nos dimos cuenta de que la respuesta honesta tenía que ser medible. Por eso, hemos creado una forma común de evaluar productos de IA en rendimiento, comportamiento, seguridad y equidad. La idea no es pasar una prueba antes del lanzamiento. La idea es seguir demostrando, durante toda la vida del producto, que sigue haciendo lo que debe hacer”.
Una necesidad integrada
La idea central de este trabajo es que la IA Responsable no es una lista de comprobación separada añadida a la calidad, sino que forma parte de lo que significa calidad. Un producto que muestra sesgos, bloquea una solicitud legítima o puede ser inducido a dar una respuesta incorrecta no es un producto de alta calidad, por muy rápido o fluido que parezca. Por tanto, la seguridad y la equidad se evalúan en el mismo lugar que la precisión y el rendimiento, en una única visión de la calidad. Si un producto no cumple en materia de IA Responsable, no puede considerarse bueno.
La necesidad de este enfoque nace de la propia naturaleza de la IA. El software tradicional es determinista: la misma entrada produce el mismo resultado, salvo que cambie el código. Los productos basados en grandes modelos de lenguaje (LLMs) y agentes se comportan de forma diferente. Sus respuestas pueden depender de la redacción, del contexto, de las fuentes que recuperan, de la orquestación que las rodea y de las actualizaciones de los modelos subyacentes. Un producto puede funcionar bien en el lanzamiento y después desviarse porque se ha actualizado un modelo o ha cambiado una fuente de datos.
Por eso la evaluación se trata como parte del desarrollo y no como una barrera al final del proceso. Las pruebas de regresión siguen siendo importantes, pero confirmar que un sistema no ha empeorado no es lo mismo que demostrar que es bueno. Cada vez más, construir productos de IA es un bucle: generar una respuesta, evaluarla, mejorarla, volver a evaluarla. Y este marco está diseñado para ese bucle.
Todo parte del propio producto. En lugar de aplicar un conjunto genérico de pruebas, lee lo que el sistema debe hacer y genera casos de evaluación específicos a partir de sus propios requisitos y políticas. Estas evaluaciones incluyen sus obligaciones de IA Responsable, de modo que la equidad, la seguridad y el cumplimiento de los límites se prueban con el mismo rigor que la corrección funcional. Después examina el comportamiento más allá de esos casos, para detectar debilidades que nadie había previsto, mientras que un conjunto seleccionado de comportamientos esperados proporciona un punto de referencia estable para que las regresiones aparezcan cuando cambian los prompts, los modelos o los datos. La misma lógica se aplica antes y después del despliegue: un control integral de calidad antes del lanzamiento y una supervisión continua en producción para detectar desviaciones, degradación y vulnerabilidades emergentes; una única definición coherente de calidad, que incluye la IA Responsable, a lo largo de toda la vida del producto.
Más allá de la propia tecnología, la ambición es cultural. Los ingenieros deben poder moverse rápido y entender el impacto de cada cambio. Los equipos de producto deben priorizar la evidencia. Y los equipos de IA Responsable y Gobernanza deben basarse en las mismas métricas que las personas que publican el producto, de modo que la seguridad y la equidad se midan al mismo tiempo que el rendimiento, y no se añadan después.
Para el cliente, nada de esto es visible, y ese es precisamente el objetivo. La gente no pide IA Responsable; pide un producto que responda correctamente, mantenga una conversación normal y le trate con justicia. La buena calidad desaparece dentro de una buena experiencia, y lo mismo ocurre con la buena IA Responsable. Cuando funciona bien, nadie la nota y simplemente confía en el producto. A medida que la IA se convierte en una parte cada vez mayor de la forma en que opera el Banco, esa confianza no puede ser algo que demos por sentado. Tiene que ser observable, medible y mejorada de forma continua. Para eso sirve esta capacidad: no solo para mejorar las pruebas, sino para construir y escalar productos de IA de una forma más responsable y más fiable.
