Este proyecto se desarrolló bajo acuerdo de confidencialidad. Este texto omite el nombre del producto, los nombres de las personas involucradas, las métricas internas, los detalles de implementación y cualquier captura de pantalla. Las decisiones de diseño y los principios que se articulan aquí son míos, y puedo defenderlos en detalle en conversación.
Cualquier “portal” es una excavación arqueológica
En las industrias tradicionales hay un patrón que se repite: los portales de operación interna son, en su mayoría, arqueología de software acumulada por décadas. Para ejecutar un trámite cualquiera, un usuario interno entra por un lado y salta a otro, recorriendo el camino entre interfaces modernas y otras que llevan más años en producción que el iPhone.
Esos sistemas funcionan, pero por costumbre. El conocimiento operativo está distribuido en la cabeza de quienes los usan a diario, y sus manuales tienen versiones en PDF y versiones “te lo explico por WhatsApp”. Una burocracia paralela de correos y presiones informales entre equipos sostienen lo que el software, por sí solo, no termina de orquestar.
El usuario real no es el que se nombra
El primer hallazgo de la investigación no fue sobre el stack, sino sobre quién lo usa. El portal se llama “portal de asesores”, y la suposición es que lo operan los asesores propiamente tales… y no es así. Un asesor es un agente comercial con cartera propia; lo último que hace en su día es llenar pantallas de captura. Quien está frente al software son sus asistentes: una población mayoritariamente Gen Z y millennial joven, formada en interfaces móviles — TikTok, WhatsApp, Spotify, ChatGPT – que deben sentarse varias horas al día y hacer frente a decisiones que se tomaron cuando ellos estaban en secundaria o francamente no existían.
Esa brecha es el problema, y no es de capacidad técnica: los asistentes aprenden las rutinas sin dificultad. Es de expectativa. Cuando todo el resto de tu día digital responde a lenguaje natural y el sistema con el que trabajas te pide más de tres clics para desplegar un combo de una sola opción, la fricción deja de ser operativa y pasa a ser generacional, algo que no necesariamente se recupera con capacitación.
Eso cambia la pregunta de diseño: ya no es cómo modernizamos el portal, sino cómo cerramos la distancia entre las herramientas que alguien elige fuera del trabajo y las que está obligado a usar adentro… y no se responde con un rediseño, sino cambiando la categoría de la interfaz.
Ni reemplazar ni unificar: envolver
En una institución grande y altamente regulada, modernizar el stack heredado significa proyectos multianuales muy caros y con riesgo regulatorio acumulado en cada liberación: cada sistema legacy carga una integración, una decisión de cumplimiento y un caso de uso que sólo está en la cabeza de quien lo construyó… hace una década (o más). Empezar de cero no era opción, y unificar tampoco: la operación del día a día no puede quedar en suspenso mientras el back se reescribe.
La salida propuesta fue envolver el legado en una capa conversacional de inteligencia artificial. En arquitectura de software, esto es un strangler fig: no se demuele el sistema viejo, se lo va rodeando hasta que deja de ser el punto de contacto. Mientras el usuario, en una UI moderna, explica en lenguaje natural lo que necesita, se traduce la solicitud en llamadas correctas a las APIs que ya existen, y el problema generacional se disuelve sin tocar la ingeniería que hace correr al negocio.
Qué decidí
Lo que hice con las manos es lo de menos. Lo que sostiene el producto fueron estas decisiones:
- La topología conversacional. Cuántas ramas de diálogo abrir, cuándo bifurcar, cuándo cerrar, cuándo escalar a una persona. No es obvio: cada bifurcación adicional es flexibilidad para el usuario y deuda de mantenimiento para el equipo. Definí una topología que privilegia el “happy path” de cada flujo por encima de la cobertura exhaustiva, partiendo de que un caso mal resuelto por la IA le hace más daño a la confianza en la compañía (y en la solución) que un caso que se pueda derivar a una persona real.
- Fidelidad estricta sobre naturalidad. Puede sonar contraintuitivo a nivel de producto, pero se hace un no negociable en compliance: una palabra reinterpretada por el modelo puede significar un trámite rechazado y un riesgo reputacional. Eso obligó a enrielar explícitamente ciertos flujos, sacrificando algo de fluidez en aquellos puntos donde un texto tiene consecuencias legales.
- El microcopy regulatorio. Decidir, una y otra vez, si poner “ADVERTENCIA” en altas o meterle “Importante:” a todo comunica lo mismo; si la negrita basta; si una pausa visual puede reemplazar una mayúscula. Hubo que defender que la interfaz tiene una gramática propia frente a requerimientos legales que no la leen así, y que tampoco se pueden ignorar.
- Componentes de interfaz conversacional en chat. Lo más fácil era copiar patrones de interacción de los laboratorios de frontera, pero no es el mismo uso ni funciona igual por atrás. En cada paso del proceso, el criterio que primo fue que el usuario pudiera sostener una conversación que se sienta humana sin sacrificar la exactitud de la captura.
- El alcance de las pruebas adversariales. Definí en sesiones de trabajo con el equipo qué se probaba, con qué severidad se clasificaba cada hallazgo y qué tenía que estar resuelto antes de liberar. Es la parte del trabajo que menos se parece a diseño y más a seguridad, y sin embargo es una decisión de diseño: cada guardarraíl es una restricción de experiencia, y cada restricción se paga en flexibilidad.
Qué ayudé a descartar
- Prompts monolíticos. La forma rápida de que un asistente cubra más casos es alargar sus instrucciones, y se rompe cuando hay que cambiar una regla de negocio, porque nadie sabe qué más se movió. Apoyé en la creación de capacidades modulares con reglas canónicas compartidas: una regla vive en un solo lugar y se cambia sin releer todo, apoyando la expansión de la cobertura de trámites.
- El estado sostenido por el modelo. Suena tentador dejar que sea el modelo quien recuerde en qué punto va la operación y, la verdad, un sistema probabilístico no es el mejor lugar donde guardar el estado de una transacción regulada. Propuse establecer estados deterministas en el orquestador y generar bitácoras de sólo adición: cada paso queda escrito, nada se sobrescribe, y la operación se puede reconstruir después para hacerla auditable.
- La estimación de costo del proveedor. No cuadraba con el comportamiento real del producto. Modelé la economía unitaria por transacción (turnos, documentos adjuntos y consumo a precios vigentes de inferencia), corregí el número y dimensioné una fase de ruteo y caché agresivo que reduce 42% el costo por trámite.
Lo que me llevo
Este proyecto me obligó a traducir una categoría de diseño que tiene menos de cinco años (las interfaces conversacionales de IA) al lenguaje de una organización regulada.
Lo que uno hace como usuario cotidiano de estas herramientas no es lo que puede empujar dentro de una institución de más de 85 años de operación. Ser puente entre esas dos orillas es el trabajo: los patrones de interacción se están escribiendo en caliente en laboratorios de frontera, y hay que aterrizarlos en flujos BAU que no pueden fallar.
Eso no se enseña en ningún lado: se aprende haciéndolo, y ahora sé hacerlo.