Empezamos por hacer explícitos los mecanismos del motor de políticas mediante domain learning. En este contexto, las políticas combinan condiciones sobre indicadores de comportamiento como la huella del dispositivo, los cambios de ubicación, la velocidad de gasto y el historial de fallos previos, con resultados como permitir, bloquear o activar una autenticación reforzada. La interfaz existente mostraba estas reglas como vistas de base de datos y tablas de configuración. No se ajustaba a cómo los analistas razonan sobre los patrones de fraude ni a cómo explican las decisiones a los equipos de auditoría interna.

A través de talleres con los equipos de producto, ingeniería y seguridad de Callsign durante Sandbox Experiments, mapeamos las estructuras de reglas existentes, los escenarios de fraude que debían cubrir y los puntos donde aparecían conflictos o vacíos. Este ejercicio de mapeo condujo a una separación clara entre el modelo de detección de fraude que puntúa los eventos y la capa de políticas que aplica umbrales, excepciones y decisiones de flujo de trabajo. El trabajo se convirtió en un ejemplo de UX design para sistemas de IA, donde la interfaz controla cómo los resultados del modelo se traducen en acciones en el mundo real.

A partir de ahí, definimos una arquitectura de la información para la seguridad empresarial que trata una policy como el objeto central. Cada policy agrupa sus condiciones, acciones, historial y enlaces a reglas relacionadas. Los analistas pueden seguir una policy desde la definición hasta la evaluación sin perder el contexto. Las decisiones se registran de forma que respaldan las revisiones de auditoría y los controles regulatorios relacionados con SCA, PCI DSS y la gobernanza interna. Validamos las primeras versiones de esta estructura con los equipos de Callsign mediante escenarios concisos en lugar de diagramas abstractos, y la ajustamos según su feedback.

Con la arquitectura ya establecida, rediseñamos los recorridos de los analistas para reflejar cómo los equipos de fraude piensan realmente un caso. La experiencia anterior obligaba a los usuarios a saltar entre pantallas de configuración, documentos de referencia y tablas de datos cuando querían ajustar una sola regla. Sustituimos esto por un flujo centrado en la policy. Los analistas identifican un escenario, abren el conjunto de policies relevante, ajustan las condiciones en contexto y ven de inmediato en qué parte del workflow se aplica el cambio.

El concepto central de interacción se basó en un modelo de tres gestos, diseñado para el interaction design de analistas de fraude. Los analistas arrastran para crear o recolocar nodos en el workflow, hacen clic para abrir y editar los parámetros de las reglas en línea, y dibujan una conexión para enlazar nodos y definir la secuencia. Estos gestos son coherentes en toda la herramienta, lo que reduce el esfuerzo de aprendizaje para usuarios con experiencia en riesgo o cumplimiento normativo más que en producto.

También tuvimos que hacer scope trade offs mediante tension-driven reasoning. Para la primera versión priorizamos la creación de policies, la visibilidad de conflictos y la explicación de impactos por encima de funciones avanzadas de colaboración o vistas completas del historial de versiones. Esta decisión reflejaba el objetivo inmediato de hacer que las demostraciones con equipos de riesgo y seguridad de grandes bancos fueran efectivas y creíbles. Las primeras pruebas internas con analistas de Callsign confirmaron que los nuevos recorridos reducían el tiempo necesario para expresar un escenario de fraude común en la herramienta y hacían que las explicaciones durante las llamadas con clientes fueran más directas.

La configuración por sí sola no era suficiente. Callsign necesitaba una forma para que los analistas y las partes interesadas de los bancos entendieran qué haría un conjunto determinado de policies en escenarios realistas. Creamos un modo de evaluación en el que los usuarios definen un contexto de simulación mediante filtros de estilo lenguaje natural, como el segmento de clientes, la geografía o el tipo de transacción. El sistema ejecuta estas configuraciones a través del modelo de detección de fraude y el motor de políticas, y presenta los resultados en una vista analítica enfocada.

La vista de evaluación es central para la experiencia de usuario de las herramientas de gestión de riesgos, porque cierra el ciclo entre configuración e impacto. Los analistas pueden ver con qué frecuencia un escenario conduce a una aprobación automática, a una autenticación reforzada o a un bloqueo, y comprobar si los casos de alto riesgo podrían pasar desapercibidos. Para que esto fuera interpretable, utilizamos data visualisation para sistemas bancarios implementada con D Three, empleando representaciones de gráficos y flujos que muestran dónde se concentra el tráfico y dónde las policies crean cuellos de botella.

Mantuvimos una relación muy clara entre la configuración y la evaluación. Las policies siempre se editan en el espacio de configuración, y el entorno de evaluación consume esas definiciones sin permitir que los usuarios las modifiquen directamente. Esta barrera evita cambios no rastreados durante el análisis. Utilizamos evidence based UX para IA con el fin de perfeccionar el flujo de evaluación, observando cómo los analistas interpretaban los gráficos y dónde surgían malentendidos, y simplificando después las etiquetas y las interacciones. El resultado es un bucle controlado pero flexible en el que los analistas pueden probar, ajustar y justificar estrategias de policy sin exponer los detalles internos del modelo.

Desde las primeras semanas tratamos cada pantalla como parte de un design system y no como un artefacto aislado durante Concept Convergence. El sistema cubre la construcción de workflows, la gestión de policies, las vistas de evaluación y las estructuras de navegación de soporte. Cada componente cuenta con estados documentados, reglas de interacción y notas de uso. Esta base se convirtió en un design system para productos bancarios que ayuda a Callsign a mantener la coherencia en nuevas funcionalidades de seguridad y en módulos futuros.

En el lado de ingeniería nos alineamos desde el principio con el equipo de front end. Los componentes de policy y workflow se modelaron como unidades React que pueden componerse para crear pantallas más complejas sin duplicación. Por ejemplo, el mismo módulo de resumen de policy aparece en las listas de configuración, en el lienzo de workflow y en los resultados de evaluación, con un contrato de comportamiento coherente. Las visualizaciones basadas en D Three se integran en contenedores React dedicados, de modo que las responsabilidades de diseño y renderizado quedan claramente separadas, lo que facilita la optimización del rendimiento para conjuntos de datos más grandes.

Estructuramos los entregables para encajar en su proceso de desarrollo durante Implementation Partnership. Las especificaciones seguían la estructura de su trabajo existente en Git y Confluence, y participábamos en sesiones regulares con los ingenieros para resolver edge cases antes de que llegaran a la implementación. Tras unas ocho semanas, el proyecto alcanzó un estado estable. Los nuevos workflows y las interfaces de gestión de policies estaban listos para demostraciones enterprise, y el design system era lo suficientemente completo como para guiar el trabajo interno posterior. Los propios diseñadores de Callsign utilizaron más tarde este sistema como base para módulos adicionales más allá del fraude y la autenticación.