Una trayectoria construida desde la operación hacia control, automatización y criterio de riesgo.

Cómo llegué hasta acá

Mi recorrido profesional no parte en un área de compliance ni en un comité de riesgo. Parte en la ingeniería electrónica, en el contacto directo con sistemas que debían quedar funcionando, ser mantenibles y responder bajo presión. Esa base importa porque moldea la forma de mirar un problema: antes de preguntar por un control, tiendo a preguntarme qué proceso sostiene ese control, qué dependencia lo vuelve frágil y qué evidencia realmente demuestra que opera como se declara.

En First Security ese enfoque tomó forma práctica. Primero desde el diseño y supervisión de proyectos de seguridad electrónica, donde el valor estaba en lograr implementaciones sólidas en terreno, coordinando instaladores, clientes y contratistas. Después, en un rol más orientado a sistemas, la mirada se desplazó hacia la operación continua: recepción de video, VMS en SOC, evaluación de desempeño de plataformas, automatización con Power BI, Power Apps y Python, además de configuración avanzada de redes con MikroTik. Más tarde, al asumir responsabilidades de estandarización, puesta en marcha e I+D, el trabajo dejó de ser solo técnico en el sentido estrecho y pasó a incluir calidad, consistencia, criterio de implementación y coordinación entre áreas.

Ese tránsito entre instalación, operación, estandarización y mejora continua es lo que hoy alimenta un trabajo centrado en automatización de procesos, reportería y diseño de controles dentro del sector bancario. El interés por TPRM nace precisamente ahí: en cómo convertir tareas repetitivas y evidencia dispersa en flujos más consistentes, trazables y útiles para decisiones futuras. Ahí está el puente entre la experiencia previa y la dirección profesional que estoy construyendo.

Cómo trabajo

• Evidencia antes que intuición. La experiencia sirve para formular hipótesis, pero no para reemplazar la validación. En entornos críticos, la calidad de la decisión depende de la calidad de la evidencia disponible.
• Automatización donde exista repetición. Si un control, seguimiento o reporte se repite de forma predecible, lo razonable es diseñar un flujo que reduzca fricción, mejore trazabilidad y libere tiempo analítico.
• Documentación como activo. Un estándar técnico bien escrito no es burocracia: es una pieza de control, una herramienta de transferencia y una forma concreta de reducir variabilidad operacional.
• Lenguaje técnico traducido a decisión. Parte importante del trabajo es conectar detalle técnico con impacto de negocio, para que el análisis no quede atrapado entre jerga operativa o abstracción regulatoria.

El punto de intersección

Lo que busco desarrollar es una práctica profesional situada en un cruce poco habitual: automatización, arquitectura de control y gestión de riesgo tecnológico con sensibilidad operativa real. Haber trabajado con cámaras, alarmas, VMS, redes, software de apoyo, estandarización y despliegues permite leer de otra manera las dependencias de un proveedor, las superficies de falla y los controles compensatorios que sí son viables. No se trata de romantizar la experiencia de terreno, sino de usarla como una ventaja metodológica al momento de diseñar mejores procesos y, más adelante, evaluar riesgo con más criterio.

Ese enfoque también dialoga con la formación académica reciente. El Máster en Inteligencia Artificial e Ingeniería del Conocimiento ya completado aportó estructura para pensar automatización, análisis y diseño de soluciones. En paralelo, la Maestría en Seguridad Informática Avanzada, actualmente en curso, amplía el marco para seguir profundizando en ciberseguridad con una mirada integrada entre operación, arquitectura y control.

Qué me interesa construir

Este sitio existe como una extensión de esa tesis profesional. No busca funcionar como una vitrina genérica de habilidades, sino como un lugar donde ordenar ideas, documentar criterios y publicar análisis que conecten operación técnica con automatización, control y riesgo. Los proyectos propios entran en esa misma lógica: aplicaciones pequeñas, privadas y mantenibles que convierten fricciones repetidas en herramientas concretas. El blog, en particular, será el espacio para desarrollar esa conversación con más profundidad: cómo cambia la lectura de un proveedor cuando se ha estado del lado de la implementación, cómo traducir lenguaje de compliance a términos verificables para equipos técnicos y cómo usar automatización para hacer controles más consistentes y auditables.

En términos simples, me interesa trabajar en problemas donde el rigor técnico, el criterio de control y el diseño de herramientas se necesiten mutuamente. Ese es el hilo conductor de la trayectoria hasta ahora, y también la dirección de lo que viene.