El problema
La red ferroviaria española tiene aproximadamente 15.000 km de vía y genera millones de tren-kilómetro de datos de vibración y acústicos cada año. Los trenes de auscultación, los vehículos que miden el estado de la vía, están entre los instrumentos más sofisticados del arsenal de mantenimiento. Los datos que recogen son detallados, estructurados y, en teoría, accionables.
En la práctica, llegan en un PDF.
Del sensor al ingeniero de mantenimiento, la cadena es esta: los datos se recogen, se procesan de forma centralizada, se maquetan en un informe, se distribuyen por correo electrónico y los interpreta el ingeniero que tiene que decidir, a menudo en la misma reunión en la que se priorizan otra docena de cosas, adónde enviar una brigada esta semana. Para cuando un defecto de desgaste ondulatorio llega a alguien con autoridad para actuar, han pasado días o semanas desde que era detectable por primera vez en la señal.
El accidente de Adamuz de enero de 2026 puso la infraestructura de seguridad ferroviaria española bajo el escrutinio de todo el país. Entre las brechas que hizo visibles: la distancia entre lo que el sistema sabe y lo que llega a las personas que pueden hacer algo al respecto. BaseLine se construyó para abordar una parte concreta de esa brecha: el problema de la auscultación.
Investigación y validación
Antes de construir nada, hice una validación estructurada de la oportunidad en el espacio del problema, abordándolo como investigador UX y con un escepticismo deliberado hacia los planteamientos "resolubles con tecnología".
Los problemas estructurales son reales: huecos de periodicidad entre pasadas de auscultación, baja relación señal-ruido en los datos brutos, visibilidad fragmentada entre brigadas de campo y salas de control, y una latencia en la escalada manual que obliga a trabajar de forma reactiva en lugar de preventiva. No son anécdotas: son estructurales a cómo funciona hoy el flujo de inspección.
El usuario principal del MVP es una sola persona: el ingeniero de triaje de mantenimiento. Ni maquinistas, ni reguladores, ni controladores de operaciones, ni directivos. El ingeniero de triaje ya toma decisiones de priorización, ya sufre el dolor de la detección tardía y puede actuar sin cambiar la operación de los trenes. Todos los demás grupos de usuarios quedaron explícitamente fuera del alcance de la primera versión.
Problema sólido, alta complejidad, riesgo de adopción significativo. La recomendación: no construir primero una plataforma completa. Empezar con una clase de defecto, un corredor y un grupo de usuarios. Demostrar que la detección temprana cambia el comportamiento antes de ampliar nada.
Las tasas altas de falsos positivos provocan un abandono rápido. Las predicciones de caja negra se ignoran o generan desconfianza. Las preocupaciones sindicales sobre vigilancia y culpa son bloqueos reales. Cualquier sistema que insinúe "defectos no detectados" crea tensión de responsabilidad con los reguladores. No son problemas de UX: son restricciones políticas y organizativas que tenían que dar forma al diseño desde el principio.
La cuña del MVP
La definición del alcance fue tan importante como cualquier decisión de diseño del proyecto. La cuña se eligió lo bastante estrecha para sobrevivir a la política organizativa, lo bastante útil para cambiar el comportamiento y lo bastante legible para ganarse la confianza de reguladores e ingenieros.
El desgaste ondulatorio del carril produce firmas acústicas y de vibración características, se desarrolla de forma gradual (lo que da tiempo para detectar y responder) y los ingenieros de mantenimiento ya lo conocen bien, lo que facilita calibrar la confianza. Las líneas de alta velocidad AVE quedaron explícitamente excluidas del MVP: el riesgo político y de seguridad es demasiado alto para empezar por ahí.
Un único corredor de cercanías de alto tráfico, con material rodante mixto y problemas de mantenimiento históricos conocidos. La tarea principal: "ayudarte a decidir dónde mirar primero esta semana". Ni predicción. Ni sustitución de las inspecciones. Ni alertas en tiempo real. Apoyo al triaje para la decisión semanal de priorización que los ingenieros ya están tomando.
Lo que el MVP explícitamente no hace: No alerta a los maquinistas en tiempo real. No activa limitaciones temporales de velocidad automáticas. No sustituye las inspecciones. No clasifica el rendimiento de brigadas ni maquinistas. No ofrece plazos predictivos de fallo ("fallo en X días"). Cada uno de estos no-objetivos fue una elección deliberada para reducir la fricción de adopción y el riesgo de responsabilidad.
Lo que diseñé
El prototipo es una interfaz de triaje pensada primero para web y creada en Figma Make: una aplicación React funcional, no una maqueta. Tiene dos vistas principales.
Lista de anomalías — la vista de triaje
La pantalla principal es una tabla ordenable y filtrable de las anomalías detectadas en el corredor. Cuatro tarjetas de KPI en la parte superior dan al ingeniero una lectura inmediata de la situación actual: detecciones totales, pendientes de revisión, severidad alta y tendencia a empeorar. Cada fila muestra las cinco señales necesarias para tomar una decisión de triaje sin entrar en el detalle: ubicación (punto kilométrico, PK), banda de severidad, nivel de confianza, dirección de la tendencia y estado de corroboración. Los filtros se reducen a severidad, confianza, tendencia y estado; ni más, ni menos.
Detalle de la anomalía — la vista de decisión
Configuración — umbrales controlados por el ingeniero
Los ingenieros pueden ajustar los umbrales de detección por clase de defecto directamente en la interfaz. Cada cambio queda registrado. No es un ajuste enterrado en un panel de administración: es un flujo de primera clase, porque la calibración forma parte de la relación de confianza entre el ingeniero y el sistema.
Al entrar en el detalle aparece la evidencia que hay detrás de la detección: un gráfico de señal de 52 pasadas con el historial de vibración en bruto y el umbral, una tarjeta de explicación en lenguaje llano, el estado de corroboración con las fuentes de sensor identificadas y todo el contexto técnico (PK, sección, % de cambio de amplitud, pasadas confirmatorias consecutivas). El panel de acciones de la derecha es el único lugar donde el ingeniero interactúa con el sistema: revisado, inspeccionar en el próximo ciclo, programar mantenimiento, falso positivo. Cada decisión queda registrada con la identidad del usuario y una marca de tiempo.
Decisiones de diseño clave
Cada tarjeta de anomalía empieza con una explicación en lenguaje llano de qué se detectó y por qué el sistema lo señaló: "Aumento sostenido de la amplitud de vibración lateral en el carril derecho. Los valores superaron el umbral establecido en 7 de las últimas 10 pasadas de medición. El patrón de evolución sugiere un posible defecto de desgaste ondulatorio de onda larga. Confirmado de forma independiente por sensor de vía y tren de auscultación." El ingeniero lee la evidencia antes de ver la etiqueta de severidad, no al revés. Es una inversión deliberada de cómo se diseñan la mayoría de los sistemas de alertas.
Cada anomalía muestra si ha sido confirmada por más de una fuente independiente. Las detecciones corroboradas se marcan; las de una sola fuente, no. Esta única señal visual hace mucho trabajo: calibra la confianza del ingeniero antes de que lea nada más, reduce el coste cognitivo de priorizar y hace legible, en lugar de ocultar, la propia incertidumbre del sistema. Una detección de severidad alta sin corroborar debe investigarse, pero de forma distinta a una corroborada.
La vista de detalle incluye una nota persistente: "Las decisiones registradas aquí quedan asociadas a tu usuario y a la fecha. El sistema no ejecuta acciones automáticas sobre la infraestructura." No es un descargo de responsabilidad. Es el compromiso de seguridad central del diseño. Una herramienta de triaje en un dominio crítico para la seguridad que actúe de forma automática, o insinúe que podría hacerlo, generará desconfianza, se sorteará o la bloquearán los reguladores. La persona es siempre quien decide. El trabajo del sistema es darle mejor información, más rápido.
El MVP es deliberadamente estrecho: una clase de defecto, un corredor y umbrales ajustables por los ingenieros. El principio de diseño detrás de esto es que las tasas altas de falsos positivos son el camino más rápido al abandono en un flujo crítico para la seguridad. Un ingeniero que descarta tres alertas sin actuar no mirará la cuarta. En esta etapa, la precisión importa más que la exhaustividad. La ampliación a más tipos de defecto, más corredores y flujos de datos más ricos llega solo después de que el sistema se haya ganado la confianza operativa.
En los sistemas críticos para la seguridad, el valor no viene de algoritmos sofisticados. Viene de la coordinación entre personas y datos, de la explicabilidad, de reducir la fricción operativa y de un diseño orientado a la adopción real.
Prototipo en vivo
Creado en Figma Make: una aplicación React funcional, no una maqueta. Abre la versión a pantalla completa para interactuar con la lista de anomalías, entrar en una vista de detalle y usar el panel de acciones.
Propuesta de piloto
BaseLine está diseñado para validarse en un piloto operativo de 90 días antes de cualquier compromiso de despliegue más amplio. El piloto está estructurado para producir evidencia binaria: ¿los ingenieros actúan de forma distinta gracias a él, o no?
Acceso a los datos existentes del tren de auscultación de un corredor, sin hardware nuevo más allá de la escala del piloto. Entre cuatro y seis ingenieros de triaje de mantenimiento participando en sesiones de revisión quincenales. Un compromiso de que las recomendaciones del piloto no generan responsabilidad salvo que el ingeniero decida actuar a partir de ellas.
Señal principal de éxito: el 30 % o más de las anomalías revisadas se traducen en un cambio de prioridad de inspección o mantenimiento. Señales secundarias: los ingenieros informan de que conocen antes defectos que no habrían detectado tan pronto; la tasa de falsos positivos se mantiene dentro de la tolerancia que ellos mismos declaran; cero incidentes operativos causados por recomendaciones del piloto. Señal de fracaso: la herramienta se consulta una vez y se ignora; las alertas se descartan sin revisar; los ingenieros piden los PDF en su lugar.
Segunda clase de defecto (quemaduras por patinaje de rueda). Corroboración enviada por los maquinistas (solo tras la parada, sin interacción en marcha). Cobertura ampliada de corredores. Aplicación móvil complementaria de solo lectura. Capa de planificación de mantenimiento predictivo. Cada paso depende de que el anterior demuestre impacto en el comportamiento, no de la capacidad técnica de construirlo.
El prototipo está completo y documentado. La especificación de integración, la facilitación de investigación UX y el diseño del piloto están disponibles. Quien esté interesado puede escribirme a josue@perex.design o reservar una llamada de 30 minutos.
Resultado
Un prototipo funcional validado con un marco de investigación estructurado, con una definición de MVP muy acotada y una propuesta de piloto concreta. BaseLine no es un concepto: es una herramienta de apoyo a la decisión que puede ponerse delante de ingenieros de mantenimiento y evaluarse con resultados de comportamiento medibles en 90 días.
La investigación, el prototipo y el marco del piloto están disponibles. El siguiente paso es un operador que quiera ser socio.
Cómo se hizo
BaseLine se investigó, especificó y prototipó con asistencia de IA de principio a fin, trabajando con Claude en la investigación del dominio y con Figma Make en la construcción interactiva. Las decisiones de alcance, el ingeniero de triaje como único usuario y la exclusión de las líneas de alta velocidad AVE, fueron las partes que ninguna herramienta tomó por mí.
La dirección de producto, las restricciones y cada decisión de criterio son mías. Dejo constancia del método explícitamente porque es como trabajo ahora, y porque ser vago sobre la procedencia socavaría el argumento.