La velocidad no está en la tecnología: por qué el verdadero freno suele estar en la forma de decidir#
En muchas organizaciones, el diagnóstico se repite casi de memoria: vamos lento porque tenemos legacy. Y sí, la tecnología heredada puede imponer restricciones reales, encarecer cambios, multiplicar dependencias y hacer más pesado el time-to-market. Pero reducir toda la lentitud a ese factor suele ser una simplificación cómoda.
Porque, en la práctica, muchas instituciones no avanzan lento por falta de tecnología nueva. Avanzan lento porque deciden mal, tarde o de forma fragmentada.
Ese problema se vuelve todavía más visible en servicios financieros. Cuando negocio impulsa una iniciativa, tecnología la traduce, riesgo la revisa, seguridad la cuestiona, cumplimiento la corrige y operaciones la recibe al final, la organización no está corriendo como un sistema. Está operando como una serie de relevos con fricción acumulada.
El resultado no es solo demora. Es retrabajo, desgaste, pérdida de foco y una falsa sensación de que la tecnología es el villano principal.
¿Por qué muchas organizaciones reguladas avanzan lento aunque inviertan en tecnología?#
Porque la velocidad organizacional depende menos de cuánta tecnología se compra y más de cómo se toman decisiones entre negocio, tecnología, riesgo, seguridad y cumplimiento.
En banca regulada, el mayor cuello de botella suele aparecer cuando los roles no están claros, la gobernanza entra tarde y cada área evalúa el cambio desde su propia lógica, sin un mecanismo común para decidir temprano. Los principios del Basel Committee on Banking Supervision sobre riesgo operacional subrayan que una gobernanza interna sólida es la base de una gestión efectiva del riesgo operacional y que roles, responsabilidades y comunicación entre líneas de defensa deben estar claramente definidos.
El problema no es solo el legacy: es la coreografía institucional#
Culpar al legacy tiene una ventaja política: permite señalar un obstáculo visible sin tocar la conversación incómoda sobre cómo decide la organización. Pero en muchos casos, el problema más serio no es la plataforma anterior. Es la coreografía institucional alrededor del cambio.
El Basel Committee on Banking Supervision indica que la gestión del riesgo operacional no debe verse como piezas aisladas, sino como componentes integrados del marco general de riesgo y resiliencia, y además advierte que la confusión sobre roles y responsabilidades puede afectar la efectividad del modelo de líneas de defensa.
Eso explica algo que muchos equipos viven, aunque no siempre lo nombren bien: la lentitud no nace solo del sistema heredado, sino del circuito organizacional que convierte cualquier decisión en una negociación tardía entre áreas que se integraron demasiado tarde.
Cuando la gobernanza llega tarde, la velocidad se vuelve teatral#
Hay empresas que anuncian squads, laboratorios, células ágiles, herramientas modernas y nuevos proveedores, pero mantienen intacto su modelo real de decisión. En apariencia se ven más rápidas. En la práctica siguen dependiendo de aprobaciones secuenciales, ownership difuso y revisiones ex post.
NIST, en el Cybersecurity Framework 2.0, ubica la función Govern como la capa que conecta el riesgo de ciberseguridad con la estrategia más amplia de gestión del riesgo empresarial, incluyendo contexto organizacional, estrategia, responsabilidades, autoridades, política y supervisión. Eso es importante porque confirma algo que muchas organizaciones todavía separan artificialmente: la velocidad no puede sostenerse si la gobernanza no está integrada al sistema de decisión.
Dicho de otro modo: una organización puede modernizar componentes y seguir siendo lenta si no moderniza la forma en que decide.
Lo que realmente frena: decisiones sin dueño claro, revisión tardía y criterios incompatibles#
Cuando una iniciativa estratégica pasa por múltiples áreas con mandatos legítimos, pero sin una lógica común de decisión, aparecen tres frenos muy costosos.
El primero es la ambigüedad. Nadie sabe con precisión quién decide qué, quién asume qué riesgo y quién puede desbloquear una excepción.
El segundo es la tardanza. Riesgo, seguridad, arquitectura o cumplimiento entran cuando ya existe presión política o comercial por salir, y entonces cualquier observación técnica se interpreta como freno, no como prevención.
El tercero es la incompatibilidad de criterios. Cada área optimiza una variable distinta: negocio busca velocidad, seguridad busca reducción de exposición, riesgo busca control, operaciones busca estabilidad, arquitectura busca sostenibilidad. Todas tienen razón, pero si se integran tarde, sus racionalidades chocan en vez de complementarse.
La guía de gestión tecnológica del FFIEC señala que los consejos deben supervisar y la alta dirección implementar un proceso de planeación de TI alineado al negocio, con identificación y medición de riesgos antes de realizar cambios o nuevas inversiones, e integrando el gasto tecnológico al proceso presupuestal y al análisis de beneficios directos e indirectos frente al costo total de propiedad.
Ese punto es clave: el problema no es que existan varias perspectivas. El problema es que la organización no tenga un diseño explícito para resolverlas temprano.
Una organización lenta no siempre es una organización prudente#
Aquí hay una confusión peligrosa, especialmente en sectores regulados. A veces se cree que demorar decisiones es sinónimo de ser más responsable. Pero no siempre es así. En muchos casos, la demora solo es falta de claridad disfrazada de prudencia.
La misma guía del FFIEC recuerda que tener un plan documentado no garantiza un proceso efectivo y que la medida real de su calidad es si responde a las necesidades del negocio. Es una observación valiosa porque separa dos cosas que suelen confundirse: tener artefactos formales y tener un sistema que decide bien.
En otras palabras, una empresa puede llenar comités, minutas y controles, y seguir siendo estructuralmente torpe para cambiar.
Un ejemplo realista: dos bancos, la misma idea, dos velocidades distintas#
Imaginemos dos instituciones que quieren lanzar una mejora importante al onboarding digital.
La primera tiene buena intención, presupuesto y presión comercial. Negocio impulsa la iniciativa, producto la aterriza, tecnología la estima, luego arquitectura opina, después seguridad revisa, más tarde cumplimiento entra a ajustar y operaciones se entera cuando el proyecto ya tiene fecha comprometida. El avance parece rápido durante varias semanas, hasta que empiezan los conflictos: cambios al flujo, dudas regulatorias, excepciones de control, dependencia excesiva de un tercero, inconsistencias de datos y una salida a producción cada vez más costosa.
La segunda institución no necesariamente tiene menos restricciones, pero decide distinto. Antes de elegir proveedor o solución, define qué decisión necesita tomar, qué métricas de negocio justifican el cambio, qué riesgos cambian, qué capacidades deben reutilizarse, qué áreas participan desde el inicio y qué umbrales obligan a una revisión más profunda. No todo se vuelve simple, pero la fricción aparece antes, cuando todavía se puede diseñar, no cuando el costo político y técnico ya se disparó.
La diferencia entre ambas no está solo en la tecnología. Está en la forma en que el sistema organizacional convierte una idea en una decisión ejecutable.
Lo que debería rediseñarse primero no siempre es la arquitectura#
Como arquitecto, me interesa decir esto con precisión: la arquitectura importa muchísimo, pero no siempre es la primera palanca que conviene mover.
Si la organización conserva un modelo de decisión donde cada área participa como estación de revisión y no como parte de un mecanismo temprano de diseño, incluso una buena arquitectura terminará atrapada en un flujo torpe. Vas a tener mejores diagramas, quizá mejores principios, incluso más modularidad, pero no necesariamente más velocidad.
El Basel Committee on Banking Supervision también remarca que la función de gobernanza del riesgo operacional debe integrarse plenamente en la estructura general de gobierno del riesgo, y que cada línea de defensa debe contar con roles definidos, recursos adecuados y comunicación suficiente para reforzar el marco de gestión.
Eso refuerza una idea incómoda pero útil: muchas organizaciones no se frenan por falta de ideas ni de arquitectura. Se frenan por cómo distribuyen autoridad, responsabilidad y secuencia de decisión.
Reflexión de Arquitectura#
Cuando una organización dice que “arquitectura frena”, muchas veces lo que está describiendo no es un problema de arquitectura, sino un problema de integración tardía del diseño al proceso de decisión. La arquitectura madura no debería aparecer solo para observar restricciones. Debería entrar antes para reducir complejidad, ordenar dependencias y evitar que la velocidad se construya comprando excepciones.
La velocidad sostenible exige un modelo de decisión explícito#
Si una empresa quiere acelerar de verdad, necesita pasar de una gobernanza implícita a una gobernanza diseñada.
Eso significa al menos cinco cosas.
Primero, definir qué tipo de decisiones existen y cuáles merecen qué nivel de revisión.
Segundo, aclarar quién decide, quién recomienda, quién valida y quién asume el riesgo residual.
Tercero, integrar a riesgo, seguridad, cumplimiento, arquitectura y operaciones antes de que el proyecto llegue políticamente “cerrado”.
Cuarto, usar umbrales de impacto y riesgo para evitar que todas las iniciativas recorran el mismo circuito burocrático.
Quinto, medir no solo cuánto tarda un proyecto en salir, sino cuánto tarda la organización en decidir con calidad.
La OECD, en su Going Digital Measurement Roadmap, ha insistido en que medir la transformación digital requiere metodologías comunes y capacidades de monitoreo que permitan evaluar no solo actividad, sino impacto y evolución de forma más consistente. Aunque su enfoque es más amplio que la gestión interna de proyectos, la lección aplica bien aquí: sin medición coherente, las organizaciones terminan confundiendo movimiento con progreso.
Lo que un CTO debería leer detrás de este problema#
Desde la perspectiva de dirección tecnológica, este tema no es solo de gobernanza documental. Es un asunto de rendimiento organizacional.
Un CTO no debería limitarse a pedir más presupuesto, mejores plataformas o más talento si el sistema de decisión sigue roto. Porque, en ese escenario, cualquier mejora tecnológica terminará absorbida por el mismo patrón: decisiones lentas, conflictos tardíos, accountability difuso y desgaste entre áreas.
La función Govern del NIST CSF 2.0 deja claro que las responsabilidades, autoridades, políticas y supervisión forman parte del diseño del riesgo, no de un anexo administrativo. Esa mirada es poderosa porque obliga a sacar la conversación de la zona cómoda del tooling y llevarla a donde realmente duele: el operating model.
Reflexión CTO#
La tecnología moderna mejora la capacidad de ejecución, pero no corrige por sí sola una organización que decide mal. El liderazgo real aparece cuando se rediseña el sistema de decisión para que velocidad, control y sostenibilidad no compitan entre sí en cada iniciativa.
Mi opinión: la lentitud más costosa es la que se normaliza#
Hay una lentitud visible y una lentitud invisible.
La visible es la del proyecto que se retrasa, la aprobación que tarda o la salida a producción que se mueve de fecha.
La invisible es más peligrosa: la organización se acostumbra a que decidir tarde es normal, a que integrar áreas al final es normal, a que arquitectura corrija después es normal, a que riesgo y seguridad sean “el último filtro” es normal. Y cuando eso se normaliza, la empresa deja de ver que su verdadero problema no está en la tecnología, sino en el diseño de su coordinación.
Por eso, mi tesis es esta: el cuello de botella más serio en innovación regulada no suele ser el legacy aislado. Suele ser un modelo de decisión incapaz de convertir desacuerdos legítimos en decisiones tempranas y ejecutables.
Conclusión#
La velocidad no está solo en la tecnología. Tampoco en el discurso de transformación. Mucho menos en la cantidad de pilotos que una organización logra anunciar.
La velocidad real aparece cuando negocio, tecnología, riesgo, seguridad, cumplimiento y operaciones dejan de interactuar como bloques secuenciales y empiezan a decidir como un solo sistema.
En instituciones financieras reguladas, esa diferencia es decisiva. Porque el legacy puede poner fricción, sí. Pero la forma de decidir puede convertir esa fricción en una demora administrable o en una parálisis permanente.
Y ahí está, para mí, una de las conversaciones más importantes de 2026: antes de obsesionarnos con la siguiente tecnología, conviene revisar si nuestra organización sabe decidir al ritmo que dice necesitar.
Glosario breve#
Basel Committee on Banking Supervision (BCBS)
Comité de Supervisión Bancaria de Basilea. Emite principios y lineamientos internacionales para fortalecer la supervisión prudencial, la gestión de riesgos y la resiliencia en la banca.
BIS (Bank for International Settlements)
Banco de Pagos Internacionales. Muchas publicaciones del BCBS se alojan en su sitio oficial, por eso varias referencias de Basilea aparecen bajo el dominio bis.org.
NIST (National Institute of Standards and Technology)
Instituto Nacional de Estándares y Tecnología de Estados Unidos. Sus marcos y guías, como el Cybersecurity Framework, son usados globalmente como referencia para gobierno del riesgo, ciberseguridad e integración con gestión empresarial.
FFIEC (Federal Financial Institutions Examination Council)
Consejo Federal de Examinación de Instituciones Financieras de Estados Unidos. Publica guías para la supervisión tecnológica y operativa de entidades financieras.
OECD (Organisation for Economic Co-operation and Development)
Organización para la Cooperación y el Desarrollo Económicos. Publica marcos y estudios sobre transformación digital, medición, políticas públicas y gobernanza.
Referencias#
Basel Committee on Banking Supervision, Revisions to the Principles for the Sound Management of Operational Risk
https://www.bis.org/bcbs/publ/d515.pdfNIST, The NIST Cybersecurity Framework (CSF) 2.0
https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdfFFIEC, IT Examination Handbook – Management Booklet
https://www.ffiec.gov/sites/default/files/media/press-releases/2015/2015-it-examination-handbook-management-booklet.pdfOECD, The OECD Going Digital Measurement Roadmap
https://www.oecd.org/en/publications/the-oecd-going-digital-measurement-roadmap_bd10100f-en.html