Blog
Historias reales desde el campo de compliance, FinOps y operaciones
Aprendizajes, frameworks y lecciones de 15+ años implementando SGSI, optimizando costos cloud y escalando equipos de Service Delivery en fintech y banca digital en LATAM. Sin vendor pitch. Sin humo.
Cuánto cuesta certificarte, cuánto tarda, y qué evidencia pide un regulador.
Compliance (ISO 27001 · SOC 2)
Cuánto cuesta certificarte, cuánto tarda, y qué evidencia pide un regulador.
El día que te pidieron la evidencia
2015. Todavía éramos una startup pequeña, pero ya habíamos llegado al punto donde 'cada quien hace las cosas a su manera' dejó de ser una virtud ágil y se convirtió en un riesgo. Cuando tú mismo definiste el proceso, la primera verificación que te pide mostrar evidencia se siente como un peligro. No lo es: una auditoría se trata de los procesos, no de las personas.
¿Cuánto cuesta y cuánto tarda certificarse en ISO 27001 en México?
El costo de certificar ISO 27001 en México va de $80,000 a $450,000 MXN para startups y empresas SaaS/fintech, y el tiempo típico es de 9 a 14 meses. Te explico de qué depende cada bloque de costo, por qué varía tanto entre proveedores, y por qué un diagnóstico inicial es la forma más económica de no sobrecotizar ni subestimar el proyecto.
¿Cómo elegir un consultor de ISO 27001 en México?
Antes de contratar, evalúa cinco criterios objetivos: la certificación real del consultor (Auditor Líder, no solo 'especialista'), si trabajas directo con quien ejecuta, si el alcance cubre también costos de nube y salud de cuentas, la transparencia de precio, y si el acompañamiento continúa después de la certificación.
¿Debe tu organización pasar del pentest anual a monitoreo continuo con IA?
El modelo de pentesting anual ya no es defendible cuando el entorno cambia a diario. La validación continua con IA agéntica ya es categoría de mercado formal (Gartner: Adversarial Exposure Validation, 2026). El reto real ya no es la tecnología, sino la gobernanza: quién es dueño del hallazgo cuando quien lo detecta es un agente de IA.
El costo real de no tener ISO 27001: contratos perdidos y cómo cuantificarlos
El costo más común de no tener ISO 27001 no es una multa — es el contrato, la licitación o la ronda de inversión que se pierde en silencio. La certificación ya no es un diferenciador: es el filtro de entrada mínimo en la compra enterprise. Un método de 3 preguntas para cuantificar la pérdida.
Seguridad de la información para fintechs en Colombia: qué exige la SFC en 2026
Finanzas abiertas obligatorias (Decreto 0368/2026), ciberseguridad (Circular Externa 007), SARLAFT 4.0 y datos biométricos sensibles. Por qué ISO 27001 es la forma más directa de demostrar cumplimiento ante la SFC.
Seguridad de la información para fintechs en Perú: qué exige la SBS en 2026
Departamento de Finanzas Abiertas, reglamento de Banking as a Service (BaaS), régimen sancionador y Decreto Legislativo 1700. Por qué la SBS convirtió la seguridad en requisito, no opción, para fintechs.
¿Por qué el compliance está pasando de evento anual a servicio continuo?
El mercado de Compliance as a Service ya supera los $6,000 millones de dólares y sigue creciendo porque las empresas abandonan el modelo de "prepararse antes de la auditoría" a favor de estar siempre listas. Qué significa el cambio, por qué la auditoría anual ya no alcanza, y cómo adoptarlo.
Cómo lograr que producto priorice un control de auditoría SOC
Producto veía el control de accesos como tema técnico de baja prioridad. Traducirlo a riesgo contractual —opinión con salvedades, penalizaciones de clientes clave— cambió la conversación. El cambio entró al sprint y la opinión SOC salió limpia.
El requisito de seguridad que casi bloquea un go-live, y cómo se resolvió en una semana
Un banco en Perú exigió tokenización personalizada semanas antes del go-live. El requisito ya se había mencionado varias veces, pero nadie lo escaló como bloqueador. Escalarlo como P1 permitió entregarlo en menos de una semana.
El riesgo de seguridad que nadie ve: accesos activos de quien ya no trabaja contigo
Tickets manuales para inactivar exempleados: 10–15% del volumen mensual de un banco en Colombia, urgentes por naturaleza. Automatizar la detección del correo de baja eliminó el riesgo, el volumen, y sirvió luego para el alta.
Por qué escalar cómputo tapa el problema real y cómo recuperar el control del gasto.
FinOps (Costos Cloud)
Por qué escalar cómputo tapa el problema real y cómo recuperar el control del gasto.
El costo que nadie ve: usuarios, ambientes no productivos y el vacío del contrato
El costo total de tu factura de nube no te dice si tu arquitectura escala bien — el costo por usuario sí. Una historia real sobre cómo definir un benchmark de no-productivo vs. productivo, cerrar el vacío contractual del SLA en QA, y qué hacer cuando un cliente satura tus ambientes de prueba sin mala intención.
La estación Pantitlán del fin de mes: por qué escalar bien es más que escalar barato
Dimensionar infraestructura para que nunca falle, sin mirar datos reales de uso, casi siempre significa pagar de más todo el mes para cubrir un pico que ocurre pocos días. Cómo detectar el sobreaprovisionamiento silencioso y por qué el autoescalado necesita conocer el calendario del negocio, no solo la hora del día.
FinOps — El PDF que costó 1,500 dólares al mes por un diseño sin supervisión
¿Cuánto cuesta un mal diseño de arquitectura en la nube, y cómo se corrige de fondo? Un caso real: una instancia de Chrome que nunca se cerraba generó más de $1,500 USD/mes en costos evitables. La solución real no fue más cómputo — fue corregir la causa raíz y migrar a Kubernetes.
El cliente que estaba tumbando a los demás, sin querer
Un tenant saturada la capacidad de cómputo compartida y generaba timeouts que afectaban a otros clientes en la misma plataforma. La solución fue un circuit breaker — aislar y hacer retroceder ese consumo — el patrón que Netflix popularizó con Hystrix.
La variable que no debió cambiar entre ambientes, y sí cambió
Un componente de integración bancaria no trataba las variables de ambiente como inmutables entre QA y DEV — el primer cambio deshabilitó operaciones reales. Las fallas de configuración son la causa #1 de interrupciones (Uptime Institute 2026).
Cómo revertir un NPS negativo, evitar el churn silencioso y escalar la operación.
Customer Success
Cómo revertir un NPS negativo, evitar el churn silencioso y escalar la operación.
De NPS negativo a +24: el turnaround de Customer Success que hicimos en Formiik
Cuando empezamos a medir el NPS en un cliente nuevo, los números estaban en rojo y las 52 cuentas enterprise en 7 países mostraban señales de churn silencioso. Identificamos los puntos de fricción en cada etapa del customer journey, tuvimos un acercamiento directo con el cliente y definimos una ruta de estabilización y mejora a sus flujos operativos. En 12 meses, el NPS era +24.
Proyecto Fenix: cuando tu cliente gana un premio internacional y tú estabas detrás de la operación
Nuestro cliente más grande en Perú —con más de 2 mil usuarios de campo y más de 300 oficinas— ganó el Innovation Excellence Award 2026 de Global Banking & Finance Review con el proyecto Fenix de digitalización de agentes de campo. Las plataformas que operábamos fueron la herramienta clave, y yo estaba ejecutando el rol de Director of Operations asegurando que todo funcionara al nivel que un proyecto de esta visibilidad exigía.
El 30% de los casos que nunca debieron ser nuestros
Una reducción de headcount del cliente nos dejó absorbiendo trabajo fuera de nuestro alcance contractual. La solución no fue solo automatizar — fue automatizar primero y renegociar el alcance después: 70-75% menos tiempo de configuración, 40% menos casos.
Cuando "es simple" no significa "vale la pena"
Un stakeholder insistió en una funcionalidad visual descrita como "simple, quick win", mientras el backlog real de negocio seguía sin completarse. Sostener la prioridad correcta —no la más ruidosa— fue lo que permitió que el proyecto escalara a todas las oficinas del cliente.
Cuando no hay playbook, construye la pieza que falta
Distintos clientes se atoraban en el mismo paso de la integración. En vez de esperar el roadmap, construimos un proyecto base de .NET con las clases listas: 10–15% menos tiempo de integración y casi cero sesiones repetidas.
Por qué el 20% de tus tickets repetidos nunca deberían haber vuelto a abrirse
Cerrar tickets rápido es gestión de incidentes. Tratar los known errors como categoría propia —Gestión de Problemas— bajó los casos repetitivos más de 20% en dos años, sosteniendo 97% CSAT, +60 NPS y 99.95% uptime.
Historias y reflexiones en primera persona sobre operar plataformas SaaS.
Liderazgo & Operación
Historias y reflexiones en primera persona sobre operar plataformas SaaS.
El cómputo que tapa problemas sin resolverlos
Tu plataforma no es lenta porque le falta cómputo. Y en el fondo, ya lo sabes. Después de 15 años operando software en producción, aprendí que la tecnología más cara falla si no hay un equipo que la opere bien. Escalar infraestructura es políticamente más fácil que identificar la causa raíz — pero el problema de fondo sigue ahí.
Cuando la salida de una sola persona casi nos cuesta la cuenta
Un colaborador clave salió de forma no planeada de una cuenta bancaria 100% presencial atendida en remoto — los indicadores cayeron. Una intervención en sitio y el cambio estructural de posición remota a local revirtieron la tendencia y reconstruyeron la confianza.
La evidencia que construyó confianza donde no había jerarquía
Un error de integración generaba falsos positivos entre nuestra plataforma y el core bancario de un cliente. Sin autoridad formal sobre el proveedor externo, la evidencia irrefutable —no la jerarquía— logró la colaboración y la corrección.
Por qué un hotfix de un problema "conocido" puede tumbar la operación
El hotfix sí corrigió la causa raíz — pero los pipelines de UAT apuntaban a un TenantId obsoleto. La familiaridad con el problema hizo que nadie evaluara el riesgo. 35 transacciones afectadas. Checklist para evitarlo.
Las 15-20 horas a la semana que un equipo de 7 países perdía en mantenimiento manual
Backups a mano, tuning de bases de datos, redimensionar recursos: 15–20 horas semanales, casi medio FTE, en un equipo de 7 países. Automatizarlo con runbooks lo redujo a casi cero en dos meses, sin sumar una persona.
El error que borró 5,000 registros, y la lección que sigo usando 15 años después
Como desarrollador junior corrí una consulta mal acotada y afecté ~5,000 registros de envíos. Lo que definió el resultado no fue el error — fue la reacción de mi líder: impacto, opciones, comunicación. La sigo usando 15 años después.
Historias sobre desarrollar, corregir el rumbo, y cuidar a las personas de un equipo.
Liderazgo de Personas
Historias sobre desarrollar, corregir el rumbo, y cuidar a las personas de un equipo.
El feature de 6 horas que nunca debió construirse
Un gerente nuevo estaba a punto de solicitar un feature de 6-8 horas que la plataforma ya resolvería. Mostrar los reportes en vivo evitó el desarrollo y construyó su modelo mental. Fondo: 17.3 h/semana de los ingenieros se van en deuda técnica (Stripe).
Lo que los números no explicaban, hasta que pregunté
El desempeño de una persona cayó sin razón aparente. En vez de vigilarla, le pregunté: era un tema de salud, no de compromiso. Ajustar su horario restauró sus números. Fondo: 86% de los empleados valora la empatía del liderazgo (EY).
Por qué fracasa un plan de desarrollo de talento (y cómo detectarlo a tiempo)
Un plan de crecimiento impecable en papel: cursos definidos, retroalimentación regular, destino claro. Faltaba la convicción de la persona. Nunca se completó la capacitación y salió por desempeño. Hitos fechados y conversación honesta.
Las horas extra que nadie ve: cómo evitar el burnout en un equipo de soporte bajo presión
Una reducción de headcount nos dejó sobre capacidad: 30–40% de los casos eran configuraciones fuera de contrato. El riesgo no eran las horas extra — era que se volvieran parte del paisaje. Compensación a elección, plan visible y automatización.
Cómo construimos, desde cero, el equipo que después generó más de la mitad de nuestro ARR
Cuatro personas construidas sin un proceso definido, documentando mientras atendíamos clientes. Repartir responsabilidades según la fortaleza real de cada quien y resolver desacuerdos con criterio objetivo —no jerarquía— lo sostuvo. Ese equipo generó más de 50% del ARR.
Por qué tardamos 30% más en contratar a un DevOps, y por qué valió la pena
Dependíamos por completo de Jenkins sin experto interno y R&D estaba bloqueado. La presión decía "contrata a quien lo mantenga". Esperamos a alguien que modernizara de verdad: retiró Jenkins, migró a Azure DevOps y formó a los líderes de infraestructura de hoy.
Cuando alguien no eligió el rol que le tocó liderar
Una colega pasó a Chief of Staff del CEO durante una reestructuración — un rol que no eligió. El acompañamiento no fue sobre el proceso, sino sobre comunicación: llevar preocupaciones reales al CEO sin suavizarlas. La confiabilidad de compromisos mejoró más de 25%.
La retroalimentación que más me costó aceptar, y cómo la convertí en hábito
Retroalimentación directa de que la comunicación ejecutiva era un área real de mejora. En vez de defensiva, un plan concreto y la IA como segundo par de ojos al preparar resúmenes ejecutivos. Sigo trabajándolo: práctica continua, no casilla marcada.
Estar de acuerdo con la decisión, en desacuerdo con cómo se comunicó
El CEO dividió el equipo en implementación y soporte. La asignación de personas nunca se discutió conmigo antes, y fui directo con mi líder sobre el desacuerdo con la forma —no con la decisión. La especialización aceleró el onboarding y dio base para expandirse.
¿Quieres recibir cada artículo en tu correo?
Sin spam. Una historia real cada 2-3 semanas sobre lo que funciona (y lo que no) en compliance, cloud y operaciones para fintech.