Cuando alguien revisa mi trabajo —arquitecturas serverless en AWS, pipelines de datos, predicción de margen con machine learning— y luego pregunta qué estudié, la respuesta casi siempre genera una pausa: Ciencia Policial.
La reacción es comprensible. Pareciera que no tienen nada que ver. Pero después de años diseñando sistemas, estoy convencido de lo contrario: esa licenciatura fue uno de los mejores entrenamientos posibles para lo que hago hoy. No por lo que aprendí sobre la policía, sino por la forma de pensar que me dejó. Este artículo es sobre ese hilo conductor que une los dos mundos: la investigación.
El hilo conductor: investigar es investigar
La Ciencia Policial, en el fondo, es una disciplina de investigación. Te enseña a no quedarte con la primera explicación, a separar el hecho de la suposición, a reconstruir qué pasó a partir de rastros incompletos y a sostener una conclusión solo cuando la evidencia la respalda.
Resulta que diagnosticar un incidente en producción es exactamente el mismo ejercicio. Un sistema falló a las 3 de la mañana. Nadie vio el momento exacto. Solo tienes rastros: logs, métricas, trazas. Tu trabajo es reconstruir la secuencia de eventos, descartar hipótesis y llegar a la causa real —no a la primera que parece encajar. Cambia el escenario del crimen por un dashboard de CloudWatch, pero el método es idéntico.
La mentalidad forense = el análisis de causa raíz
En investigación, el peor error es detenerse en el síntoma. Un cristal roto no es el caso; es una pista. La pregunta forense siempre va más atrás: ¿por qué pasó esto, y qué lo hizo posible?
En ingeniería lo llamamos análisis de causa raíz, y el sesgo a evitar es el mismo. Reiniciar el servidor que se cayó resuelve el síntoma; no responde por qué se quedó sin memoria. La disciplina forense me entrenó para no soltar el caso hasta llegar al por qué —y para desconfiar de la explicación cómoda que cierra el ticket pero deja la causa intacta, esperando para repetirse la próxima semana.
Cadena de custodia = trazabilidad y auditoría
En el trabajo policial, la evidencia no vale nada si no puedes demostrar quién la tocó, cuándo y cómo. Esa es la cadena de custodia: cada paso registrado, sin huecos, de modo que la historia sea reconstruible y defendible.
La primera vez que diseñé el sistema de auditoría de una aplicación —quién accedió a qué dato, cuándo lo modificó, desde dónde— me di cuenta de que estaba implementando una cadena de custodia digital. Los logs inmutables, los registros de auditoría, la trazabilidad de extremo a extremo no son una carga burocrática: son lo que permite reconstruir la verdad cuando algo sale mal. Es el mismo principio que sostiene la asignación de responsabilidad en seguridad, solo que aprendido en otro idioma primero.
Análisis criminal = modelado de amenazas y gestión de riesgos
El análisis criminal no espera a que ocurra el delito: estudia patrones, identifica vulnerabilidades y anticipa dónde es más probable que algo pase para concentrar recursos limitados donde más rinden.
Esa es, palabra por palabra, la lógica del modelado de amenazas y de la gestión de riesgos en TI. No puedes proteger todo con la misma intensidad; tienes que pensar como quien quiere romper el sistema, priorizar por probabilidad e impacto, y poner los controles donde realmente importan. Pensar como adversario para defender mejor es una habilidad que se entrena —y yo empecé a entrenarla mucho antes de escribir mi primera política de IAM.
El método sobre la corazonada = decisiones basadas en evidencia
Si hay una sola idea que me llevé de la formación científica aplicada a lo policial, es esta: la corazonada propone, la evidencia dispone. Una hipótesis sin datos que la sostengan es exactamente eso, una hipótesis.
Es la misma convicción que me lleva hoy a medir antes de rediseñar, a caracterizar un sistema en producción antes de tocarlo, a preferir un forecast con intervalos de confianza sobre una afirmación tajante. Cuando escribí sobre bajar la latencia de un reporte de 30 segundos a milisegundos, lo primero que conté no fue la solución, sino la medición que reveló dónde estaba —y dónde no estaba— el problema. Ese reflejo de no confiar en la intuición sin evidencia tiene raíces más viejas que mi carrera en tecnología.
Lo que cada mundo le aporta al otro
La tecnología, a cambio, le dio escala a esa mentalidad. Lo que antes era un expediente es hoy un sistema que procesa millones de eventos; lo que era una libreta de notas es un pipeline de observabilidad. La disciplina de investigar no cambió; cambió el tamaño del caso.
Y creo que esa combinación es justamente lo que me diferencia. Muchos pueden escribir el mismo Terraform o la misma Lambda. Menos personas llegan a esos sistemas con el reflejo de preguntar ¿qué evidencia tengo?, ¿estoy resolviendo el síntoma o la causa?, ¿puedo reconstruir qué pasó si esto falla?. Ese reflejo no lo aprendí en un bootcamp de cloud. Lo aprendí estudiando cómo se investiga.
Conclusión
No defiendo que todo arquitecto de soluciones deba estudiar Ciencia Policial. Defiendo algo más general: las mejores habilidades técnicas suelen tener raíces no técnicas. El rigor, la curiosidad, la honestidad intelectual de seguir la evidencia hasta donde lleve —eso se entrena en muchos lugares, y se nota en cómo diseñas sistemas.
Mi camino de la Ciencia Policial a la nube no fue un giro de 180 grados. Fue la misma disciplina, aplicada a un escenario nuevo. Y cada vez que diagnostico un incidente, diseño una auditoría o modelo una amenaza, sigo —en el fondo— investigando.