Telcel, exposición de datos y un problema en la industria

 Estos días se habló mucho del portal de registro de líneas móviles (Telcel) y del hecho —reportado por varios usuarios y medios— de que el sistema podía mostrar datos personales del titular antes de que existiera verificación por SMS. El debate público se fue rápido a lo obvio: “hubo una filtración” y “qué tan grande fue”. Ese dimensionamiento fue necesario, pero para mí no es el núcleo del problema. La pregunta más relevante es otra: ¿cómo se organizó (o más bien, desorganizó) el equipo que diseñó y puso en producción ese módulo?

Primero hay que desarrollar la pregunta con cuidado. Esto exige algo que hoy se practica poco: arqueología de software. Leer el comportamiento del sistema como si fuera un fósil técnico y, a partir de él, inferir las decisiones, prioridades y limitaciones del equipo que lo construyó.

Cuando un módulo expone datos completos antes de una verificación mínima, no estamos ante un bug “accidental”. Estamos viendo una decisión conciente. Alguien decidió que era más fácil traer todo desde la base de datos y “resolverlo” en el frontend. Alguien decidió que la validación podía posponerse. Alguien decidió que la lógica de control no viviera en el backend. Y esas decisiones no describen a una persona: describen un perfil de equipo.

Ese perfil suele compartir ciertos rasgos. Equipos pequeños, presionados por tiempo, con una fuerte orientación al resultado visible (“que funcione”, “que muestre algo”), y con una clara preferencia por trasladar complejidad hacia el cliente, por que es lo inmediato, lo tangible. El frontend se convierte en el lugar donde se “ordena” la información, donde se filtra, donde se decide qué mostrar y qué no. El backend queda reducido a un proveedor de datos crudos.

El síntoma no es que haya lógica en el frontend; el síntoma es que la lógica crítica esté ahí por incapacidad de modelarla en otro lado, y este patron no aparece por malicia, aparece cuando el backend se percibe como un lugar hostil, difícil de modelar correctamente, o simplemente desconocido. Y eso resulta más complejo que “traer todo y ya veremos”.

A partir de ahí empiezan a emerger más pistas. APIs que responden con errores 500 ante entradas inválidas, en lugar de códigos 4xx bien definidos. Respuestas que no distinguen entre “no existe”, “no estás autorizado” o “falló el sistema”. Flujos donde el orden correcto de validación se invierte porque así “avanza la pantalla”. Nada de esto es casual. Es el resultado de equipos que nunca fueron obligados a pensar el sistema como un todo, sino como una sucesión de pantallas que hay que desbloquear.

Cuando uno observa estos comportamientos, empieza a intuir las motivaciones detrás. No se trata de gente “incompetente”. Se trata de equipos formados para entregar features, no para construir sistemas. Equipos donde no hubo mentoría real en ingeniería de software, donde nadie enseñó a desconfiar del propio código. Equipos que aprendieron que “así se hace” porque así funcionó una vez, y repitieron ese patrón durante años.

Con esto en mente, la pregunta se empieza a volver mas incomoda, mas interesante: ¿qué tipo de formación, de incentivos y de cultura produce sistemáticamente este tipo de decisiones?

Hasta aquí la pregunta se mantiene abierta, y es mejor mantenerla de esta manera un poco más, obligarnos a seguir entendiento el contexto para no caer en la comodidad de un juicio rápido, pero austero.