Deuda técnica: Los desarrolladores la usan para explicar código difícil de mantener, decisiones rápidas que luego cuestan más, componentes acoplados, pruebas insuficientes, librerías antiguas o diseños que ya no escalan bien.
Los equipos de infraestructura también tienen su propia deuda: servidores obsoletos, configuraciones manuales, redes poco documentadas, ambientes inconsistentes, monitoreo insuficiente o plataformas que dependen de conocimiento tribal.
Pero en una institución financiera digital, algunas de esas deudas dejan de ser solo un problema interno de ingeniería. Pueden convertirse en riesgo tecnológico. Y cuando ese riesgo afecta servicios críticos, clientes, continuidad, seguridad, cumplimiento, datos o resiliencia, la conversación ya no pertenece únicamente al backlog técnico.
La idea de fondo es simple: no toda deuda técnica es un riesgo tecnológico, pero toda deuda técnica relevante debe evaluarse por su potencial de convertirse en riesgo operacional.
¿Cuál es la diferencia entre deuda técnica y riesgo tecnológico?#
La deuda técnica representa el costo futuro generado por decisiones técnicas que reducen mantenibilidad, calidad, escalabilidad o capacidad de evolución. El riesgo tecnológico representa la posibilidad de que una falla, debilidad o dependencia tecnológica genere impacto en operación, clientes, seguridad, cumplimiento, continuidad o reputación. La deuda técnica habla del costo de ingeniería; el riesgo tecnológico habla del impacto organizacional.
Cuando todo se queda como deuda técnica, el riesgo tecnológico se vuelve invisible#
Uno de los errores más comunes es dejar bajo la etiqueta de “deuda técnica” problemas que ya tienen impacto potencial sobre operación, seguridad, continuidad, cumplimiento o experiencia del cliente.
Código difícil de leer, infraestructura antigua, APIs sin versionamiento, ambientes manuales, bases de datos sin depuración, pruebas incompletas, pipelines frágiles, monitoreo limitado y dependencias sin soporte pueden terminar en el mismo saco.
El problema es que no todas las deudas técnicas tienen la misma relevancia. Algunas son molestas, pero tolerables. Algunas generan costo de mantenimiento, pero no amenazan la operación. Otras pueden esperar.
Pero algunas son distintas: pueden provocar indisponibilidad, debilitar controles de seguridad, afectar reportes regulatorios, impedir una recuperación oportuna, exponer datos sensibles o bloquear la evolución de una capacidad crítica.
Cuando eso ocurre, la conversación cambia.
Ya no se trata solo de “limpiar código” o “modernizar infraestructura”. Se trata de gestionar riesgo tecnológico como parte del universo de riesgo operacional.
Cuando todo se queda como deuda técnica, el riesgo tecnológico se vuelve invisible.
La deuda técnica como costo futuro#
La deuda técnica es un concepto poderoso porque ayuda a explicar que una decisión técnica puede entregar velocidad hoy, pero generar costo mañana.
A veces la deuda se toma conscientemente. Se acepta una solución menos elegante para salir rápido, validar un producto o cumplir una fecha. Eso no siempre está mal. En tecnología, no toda deuda es irresponsable.
El problema aparece cuando la deuda no se reconoce, no se documenta, no se mide, no se prioriza, no tiene dueño, no tiene fecha de pago, se acumula en sistemas críticos o se normaliza como “así funciona el sistema”.
La deuda técnica sana tiene trazabilidad y plan.
La deuda técnica peligrosa se vuelve costumbre.
Puede manifestarse en código acoplado, servidores sin soporte, pipelines frágiles, linaje incompleto, hardening insuficiente, secretos mal gestionados o logging limitado. No todo eso es riesgo tecnológico de inmediato, pero puede convertirse en riesgo si afecta una capacidad relevante.
Riesgo tecnológico: cuando el impacto sale del equipo técnico#
El riesgo tecnológico aparece cuando una condición tecnológica puede generar impacto negativo para la organización.
No se trata solo de si el código es elegante o si la infraestructura está moderna. Se trata de entender qué podría pasar si esa debilidad se materializa.
Puede afectar disponibilidad, continuidad, seguridad, integridad de datos, experiencia del cliente, cumplimiento, fraude, resiliencia, reputación, terceros o evidencia ante auditoría.
La deuda técnica pregunta:
¿Cuánto nos cuesta mantener o cambiar esto?
El riesgo tecnológico pregunta:
¿Qué impacto tendría si esto falla, se degrada, se explota, se vuelve inmantenible o impide operar?
Ambas preguntas son necesarias, pero no pertenecen al mismo nivel. La primera vive principalmente en ingeniería y arquitectura. La segunda debe entrar en gobierno, riesgo, operación y dirección.
ISO 31000: traducir deuda técnica al lenguaje de riesgo#
La conversación mejora cuando se usa un marco de gestión de riesgos.
ISO presenta ISO 31000:2018, Risk management — Guidelines como una norma internacional de alcance global para orientar la gestión de riesgos. Su valor para este tema está en permitir que la organización deje de discutir riesgos como opiniones aisladas y empiece a tratarlos como incertidumbre que puede afectar objetivos.
Un problema técnico se vuelve relevante para riesgo cuando puede afectar objetivos de negocio, operación, seguridad, cumplimiento, continuidad o experiencia del cliente.
Por ejemplo: si un componente obsoleto solo incomoda al equipo, puede ser deuda técnica. Si no tiene soporte y sostiene un proceso crítico, puede ser riesgo tecnológico. Si una API mal versionada conecta originación digital, fraude y core bancario, su falla puede convertirse en riesgo operacional.
ISO 31000 ayuda a ordenar preguntas básicas: qué objetivo puede afectarse, qué evento puede ocurrir, cuál sería el impacto, qué controles existen, qué riesgo residual queda y qué tratamiento se requiere.
Ahí la deuda técnica empieza a hablar el lenguaje de dirección.
La matriz 5x5 no es ISO 31000, pero ayuda a aplicarla#
Conviene hacer una precisión: ISO 31000 no obliga a usar una matriz 5x5.
Lo que aporta ISO 31000 es un marco para gestionar riesgos mediante contexto, identificación, análisis, evaluación, tratamiento, monitoreo, revisión, comunicación y consulta. Dentro de ese proceso, muchas organizaciones usan matrices de probabilidad por impacto y mapas de calor para priorizar y comunicar riesgos.
Una escala práctica puede usar cinco niveles de probabilidad e impacto:
| Impacto / Probabilidad | 1 Muy baja | 2 Baja | 3 Media | 4 Alta | 5 Muy alta |
|---|---|---|---|---|---|
| 5 Muy alto | 5 | 10 | 15 | 20 | 25 |
| 4 Alto | 4 | 8 | 12 | 16 | 20 |
| 3 Medio | 3 | 6 | 9 | 12 | 15 |
| 2 Bajo | 2 | 4 | 6 | 8 | 10 |
| 1 Muy bajo | 1 | 2 | 3 | 4 | 5 |
Una lectura práctica podría ser:
| Resultado | Tratamiento sugerido |
|---|---|
| 1–4 | Gestionar en backlog técnico o monitorear. |
| 5–9 | Priorizar en roadmap técnico con seguimiento. |
| 10–14 | Elevar a gobierno de arquitectura y definir mitigación. |
| 15–19 | Registrar como riesgo tecnológico con dueño, fecha y plan. |
| 20–25 | Escalar a comité de riesgo, dirección o gobierno ejecutivo. |
Lo importante no es el número por sí mismo. Lo importante es la conversación que habilita.
La matriz evita dos errores: tratar toda deuda como crítica o tratar deuda crítica como mejora opcional.
Riesgo operacional, resiliencia y DORA#
En servicios financieros, el riesgo tecnológico suele relacionarse con el riesgo operacional porque una falla tecnológica puede afectar procesos, servicios, clientes, cumplimiento y continuidad.
El Basel Committee on Banking Supervision (BCBS), en Principles for operational resilience, plantea la resiliencia operativa como capacidad de entregar operaciones críticas durante una disrupción. La idea conecta tecnología con operación real: importa si la institución puede sostener operaciones críticas cuando algo falla.
También vale mirar el Digital Operational Resilience Act (DORA) como referencia europea. EIOPA lo presenta como un marco asociado a resiliencia digital y terceros TIC críticos. Para México y Latinoamérica no aplica de forma directa, pero sí envía una señal: la resiliencia digital ya no es un asunto técnico aislado, sino parte del gobierno de riesgo, continuidad, incidentes, terceros y evidencia.
Desde esa perspectiva, una deuda técnica puede convertirse en riesgo operacional cuando afecta canales digitales, integraciones con terceros, transacciones, validaciones de identidad, decisiones de crédito, fraude, reportes regulatorios, conciliaciones, recuperación o evidencia de auditoría.
Aquí la arquitectura cumple un papel fundamental: traducir elementos técnicos en dependencias operativas.
Caso aplicado: una versión obsoleta que parecía solo deuda técnica#
Imaginemos una plataforma interna que usa un runtime obsoleto.
Durante meses, el equipo técnico ha pedido actualizarlo. La solicitud compite con funcionalidades, cambios regulatorios, mejoras de canal y proyectos comerciales. Desde fuera, parece una petición técnica más.
El argumento inicial es:
“Tenemos deuda técnica; hay que actualizar.”
Eso puede no mover la prioridad.
Ahora veamos el mismo caso desde riesgo tecnológico: el runtime ya no recibe parches, sostiene una API de canales digitales, procesa datos personales, participa en originación, tiene pocas pruebas, despliegue manual y conocimiento concentrado en pocas personas.
La conversación cambia.
Ya no estamos ante una simple modernización. Estamos ante una condición tecnológica que puede afectar seguridad, continuidad, operación, cumplimiento y experiencia del cliente.
El tratamiento tampoco sería solo “refactorizar”. Podría incluir actualización, controles compensatorios, monitoreo reforzado, pruebas automatizadas, plan de rollback, fecha límite, dueño de riesgo y aceptación formal del riesgo residual.
Ese cambio de lenguaje es esencial.
No toda deuda técnica debe escalarse como riesgo#
También hay que evitar el extremo contrario: convertir toda deuda técnica en riesgo crítico.
Eso desgasta la conversación y reduce credibilidad. Si todo es riesgo alto, nada es riesgo alto.
Hay deudas técnicas que pueden gestionarse dentro del backlog de ingeniería: duplicidad menor en un módulo no crítico, mejora de legibilidad sin impacto operativo, refactorización deseable o documentación incompleta de un componente no crítico.
Eso no significa ignorarlas, sino gestionarlas en el nivel adecuado.
La arquitectura debe distinguir entre deuda aceptable, deuda que limita evolución, deuda que incrementa exposición, deuda que debe escalarse como riesgo tecnológico y riesgo que debe tratarse como operacional.
Criterios para saber cuándo escalar una deuda técnica#
Una deuda técnica debería evaluarse como riesgo tecnológico cuando afecta o puede afectar al menos una de estas dimensiones:
- disponibilidad o continuidad de un servicio crítico;
- seguridad, vulnerabilidades o exposición de datos;
- integridad de información;
- cumplimiento, auditoría o evidencia;
- resiliencia operativa;
- obsolescencia sin soporte;
- dependencia crítica de terceros;
- capacidad de cambio ante regulación, negocio o seguridad;
- fraude, abuso o explotación de APIs;
- riesgo acumulado por varias deudas relacionadas.
El último punto es importante. Una deuda individual puede parecer tolerable, pero varias deudas en un mismo sistema crítico pueden revelar fragilidad estructural.
El riesgo no siempre vive en una deuda aislada; a veces vive en la acumulación.
NIST CSF y TOGAF: seguridad, gobierno y traducción arquitectónica#
Cuando la deuda técnica se conecta con seguridad, exposición o resiliencia digital, también puede analizarse con marcos de ciberseguridad.
El National Institute of Standards and Technology (NIST), mediante The NIST Cybersecurity Framework (CSF) 2.0, plantea funciones como gobernar, identificar, proteger, detectar, responder y recuperar. Esta estructura ayuda a evaluar si una deuda técnica afecta inventario, configuración, protección, logs, runbooks, respaldos, recuperación o accountability.
Por otro lado, The Open Group presenta TOGAF Standard como un estándar de arquitectura empresarial para conectar estrategia, capacidades, procesos, información, aplicaciones y tecnología. Esa conexión es fundamental.
Un desarrollador puede ver un módulo acoplado. Un ingeniero de infraestructura puede ver una plataforma obsoleta. Un arquitecto debe ver qué capacidad depende de eso. Un CTO debe ver qué decisión ejecutiva se requiere. Riesgo debe ver qué exposición queda abierta. Negocio debe entender qué impacto puede aceptar.
Sin esa traducción, la deuda técnica suele quedarse en el backlog. Con esa traducción, puede entrar al gobierno adecuado.
Matriz práctica: de deuda técnica a riesgo tecnológico#
Una forma útil de elevar la conversación es crear una matriz sencilla:
| Elemento | Pregunta clave |
|---|---|
| Deuda técnica | ¿Cuál es la condición técnica problemática? |
| Capacidad afectada | ¿Qué servicio, proceso o capacidad depende de ella? |
| Evento de riesgo | ¿Qué podría ocurrir si la deuda se materializa? |
| Impacto | ¿Afecta clientes, operación, seguridad, cumplimiento, datos o continuidad? |
| Probabilidad | ¿Qué tan factible es que ocurra? |
| Nivel 5x5 | ¿Qué resultado genera la matriz probabilidad × impacto? |
| Controles actuales | ¿Qué controles reducen la exposición? |
| Riesgo residual | ¿Qué riesgo permanece? |
| Dueño | ¿Quién acepta, mitiga o gestiona el riesgo? |
| Tratamiento | ¿Se corrige, se mitiga, se transfiere, se acepta o se monitorea? |
| Evidencia | ¿Cómo se demuestra avance o control? |
Esta matriz evita dos extremos: trivializar la deuda o dramatizarla sin análisis.
Tratamiento: no todo se resuelve con refactoring#
Cuando una deuda técnica se convierte en riesgo tecnológico, el tratamiento no siempre es “refactorizar”.
Puede haber varias respuestas: eliminar la deuda, mitigar temporalmente, aplicar controles compensatorios, monitorear más de cerca, aceptar formalmente riesgo residual, rediseñar la arquitectura, reemplazar un componente, aislar exposición, limitar uso, automatizar controles, mejorar observabilidad, planificar retiro, fortalecer pruebas, negociar con proveedor o establecer fecha de remediación.
La clave es que el tratamiento sea explícito.
Una deuda técnica no gestionada se convierte en deuda silenciosa.
Un riesgo tecnológico no tratado se convierte en exposición aceptada de facto.
Mi postura: la deuda técnica debe aprender a hablar riesgo#
Una de las razones por las que la deuda técnica no se atiende es que muchas veces se explica en lenguaje que no mueve decisiones ejecutivas.
“Hay que refactorizar.”
“Esto está viejo.”
“El código está feo.”
“La infraestructura no está ideal.”
“Nos falta automatización.”
Aunque todo eso puede ser cierto, no siempre es suficiente.
La conversación debe evolucionar: qué objetivo está en riesgo, qué operación crítica puede afectarse, qué impacto tendría, qué controles existen, qué riesgo residual queda, qué pasa si no se atiende y quién debe aceptar el riesgo.
La deuda técnica debe aprender a hablar riesgo, y el riesgo tecnológico debe entender el lenguaje de arquitectura.
Reflexión de arquitectura: no basta con ver componentes, hay que ver consecuencias#
Como arquitecto, creo que uno de los mayores aportes de la arquitectura es hacer visibles las consecuencias de las decisiones técnicas.
Una deuda técnica no es solo una imperfección interna. Puede ser una restricción sobre la capacidad de evolucionar, operar, proteger, auditar o recuperarse.
El trabajo arquitectónico consiste en mostrar relaciones: qué sistema depende de qué componente, qué proceso depende de qué integración, qué dato depende de qué pipeline y qué operación depende de qué proveedor.
Cuando esas relaciones son visibles, la deuda técnica deja de ser un reclamo técnico y se convierte en conversación de gobierno.
Reflexión CTO: no financiar deuda crítica también es una decisión#
Desde una mirada CTO, ignorar deuda técnica crítica no es neutral.
Es una decisión.
Puede ser una decisión consciente, si se entiende el riesgo residual y se acepta temporalmente. Pero muchas veces es una decisión implícita: no se financia, no se prioriza, no se corrige, no se monitorea.
La dirección tecnológica debe distinguir entre deuda que puede esperar y deuda que erosiona capacidades críticas. No se trata de financiar refactorizaciones por estética, sino resiliencia, seguridad, continuidad, capacidad de cambio y confianza.
Cuando una deuda técnica puede afectar operación, clientes, cumplimiento o seguridad, ya no debe competir como una tarea invisible dentro del backlog.
Debe tratarse como una decisión de riesgo.
Conclusión: cuando la deuda técnica afecta objetivos, se vuelve conversación de riesgo#
La deuda técnica es parte natural de la evolución tecnológica. El problema no es su existencia, sino su invisibilidad, acumulación y mala clasificación.
Cuando una deuda puede afectar disponibilidad, seguridad, datos, cumplimiento, continuidad, resiliencia, fraude, experiencia del cliente o capacidad de recuperación, ya no puede quedarse solo en manos del equipo técnico.
La deuda técnica habla del costo futuro de una decisión técnica. El riesgo tecnológico habla del impacto que esa decisión puede tener sobre la organización.
La madurez está en saber cuándo una se convierte en la otra.
Glosario breve#
Deuda técnica
Costo futuro generado por decisiones técnicas que reducen mantenibilidad, calidad, escalabilidad, seguridad, automatización o capacidad de evolución.
Riesgo tecnológico
Posibilidad de impacto negativo derivado de fallas, debilidades, obsolescencia, dependencias o decisiones tecnológicas que puedan afectar operación, seguridad, cumplimiento, continuidad o valor de negocio.
Riesgo operacional
Riesgo de pérdida o afectación derivado de fallas en procesos, personas, sistemas o eventos externos. En banca digital, la tecnología puede ser una fuente relevante de riesgo operacional.
ISO 31000
Norma internacional de directrices para gestión de riesgos. Ayuda a estructurar identificación, análisis, evaluación, tratamiento, monitoreo y comunicación del riesgo.
Matriz 5x5
Herramienta de análisis que cruza niveles de probabilidad e impacto para priorizar riesgos. No sustituye la gestión de riesgos, pero ayuda a comunicar severidad y tratamiento.
DORA — Digital Operational Resilience Act
Regulación de la Unión Europea orientada a fortalecer la resiliencia operativa digital del sector financiero, incluyendo riesgo TIC, incidentes, pruebas de resiliencia y terceros tecnológicos.
Riesgo residual
Riesgo que permanece después de aplicar controles. Debe ser entendido, aceptado, monitoreado y gestionado.
Resiliencia operativa
Capacidad de una organización para mantener operaciones críticas durante una disrupción, responder, recuperarse, adaptarse y aprender.
BCBS — Basel Committee on Banking Supervision
Comité internacional de supervisión bancaria que emite principios y recomendaciones para fortalecer la gestión de riesgos, supervisión y estabilidad del sistema financiero.
NIST CSF — NIST Cybersecurity Framework
Marco del National Institute of Standards and Technology para gestionar riesgos de ciberseguridad mediante funciones como gobernar, identificar, proteger, detectar, responder y recuperar.
TOGAF — The Open Group Architecture Framework
Estándar de arquitectura empresarial desarrollado por The Open Group. Ayuda a conectar estrategia, capacidades, procesos, información, aplicaciones y tecnología.
Gobierno de arquitectura
Conjunto de procesos, criterios, roles y mecanismos de decisión para asegurar que las soluciones tecnológicas se alineen con principios, estándares, riesgos, estrategia y capacidades organizacionales.
Referencias#
ISO, ISO 31000:2018 — Risk management — Guidelines — alcance global para gestión de riesgos
https://www.iso.org/standard/65694.htmlBasel Committee on Banking Supervision (BCBS), Principles for operational resilience — alcance global para banca, con adopción proporcional según contexto regulatorio
https://www.bis.org/bcbs/publ/d516.pdfEuropean Insurance and Occupational Pensions Authority (EIOPA), Digital Operational Resilience Act (DORA) — Unión Europea; referencia útil para resiliencia operativa digital, riesgo TIC y terceros críticos
https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_enNational Institute of Standards and Technology (NIST), The NIST Cybersecurity Framework (CSF) 2.0 — Estados Unidos, referencia de adopción internacional para gestión de riesgos de ciberseguridad
https://www.nist.gov/publications/nist-cybersecurity-framework-csf-20National Institute of Standards and Technology (NIST), The NIST Cybersecurity Framework (CSF) 2.0 PDF
https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdfThe Open Group, The TOGAF Standard — alcance global para arquitectura empresarial
https://www.opengroup.org/togafComisión Nacional Bancaria y de Valores (CNBV), Sitio institucional — México
https://www.gob.mx/cnbvBanco de México, Seguridad de la información — México
https://www.banxico.org.mx/sistema-financiero/seguridad-informacion-banco.html