La soberanía tecnológica suele debatirse en términos de jurisdicción, cumplimiento o procedencia del proveedor. Todo eso es importante, pero deja fuera una cuestión que impacta directamente en el trabajo del CIO: qué conocimiento crítico conserva su departamento.
El caso TSB: el problema no fue una migración compleja
En abril de 2018, el banco británico TSB abordó una migración crítica de plataforma. La operación se apoyaba en una estructura que, sobre el papel, tenía garantías: proveedor validado, pruebas y gobierno formal del programa.
Una vez que la migración se completó, la nueva plataforma empezó a sufrir fallos técnicos. El resultado fue una interrupción significativa de servicios en oficina, banca telefónica, banca online y móvil, que afectó a gran parte de sus 5,2 millones de clientes, que no se resolvió hasta el final del año.
La crisis tuvo además un fuerte impacto económico: Sabadell, que había adquirido TSB en 2015, tuvo que asumir un impacto superior a 200 millones de euros. Pero la historia no terminó ahí. Cuatro años después, en diciembre de 2022, los reguladores británicos impusieron al banco una multa conjunta de 48,65 millones de libras por fallos de gestión del riesgo operativo, de gobierno y de supervisión del outsourcing ligado a la migración. Por último, en abril de 2023, la PRA (Prudential Regulation Authority o supervisor prudencial del Banco de Inglaterra) sancionó personalmente al entonces CIO con 81.620 libras por no haber dado los pasos razonables para asegurar una supervisión adecuada.
La lección que trae este caso no está en que una gran migración puede salir mal (lo saben todos los CIO), sino en otro aspecto: TSB no contaba con la capacidad suficiente para gobernar y cuestionar una dependencia crítica de proveedor.
La dependencia que no es noticia: el conocimiento
Cuando se habla de dependencia tecnológica, lo habitual es pensar en concentración de mercado, contratos largos, formatos propietarios, dificultad de migración o poder negociador con el proveedor. Todo eso existe y seguirá siendo importante. Pero hay otra forma de dependencia que aparece más tarde en la conversación y afecta más al día a día del CIO: la dependencia de conocimiento.
Se produce cuando la organización no conserva dentro suficiente conocimiento interno para discutir la tecnología, o someterla a un contraste serio.
El caso de TSB fue un claro ejemplo: la supervisión de una dependencia crítica se apoyó demasiado en garantías del proveedor que no se cuestionaron. Es decir, no había suficiente capacidad interna para gobernar la relación de outsourcing de forma rigurosa.
El verdadero lock-in y una nueva definición de soberanía para el CIO
Con este ejemplo, el lock-in cambia de significado. Ya no se manifiesta en el momento en que migrar resulta prohibitivo o en que una arquitectura se vuelve inamovible. Empieza antes: cuando la empresa está operando su tecnología, pero ya no puede evaluarla con seguridad.
De hecho, esta dependencia no es fácil de percibir, porque convive con una sensación de funcionamiento razonable. Los servicios están disponibles y los proveedores responden, y si embargo se está corriendo un riesgo.
Por otro lado, obliga a ampliar la palabra soberanía. La cuestión va más allá de dónde reside el dato, bajo qué jurisdicción opera un proveedor o qué grado de exposición regulatoria introduce una plataforma. Aparece otra pregunta: ¿cuánto conocimiento crítico conserva la empresa sobre aquello que sostiene su operación?
Desde esta perspectiva, mantener la soberanía no equivale a revisar la propiedad de la tecnología o internalizar la ejecución. Este matiz evita reducir la conversación a un debate legal o geopolítico.
Las dependencias de conocimiento están escondidas
El error habitual al hablar de dependencia tecnológica es mirar solo hacia donde hay más ruido: cloud, IA, grandes plataformas o residencia del dato. Cuando se habla de dependencia de conocimiento, hay que mirar hacia dentro, y además no es fácil de detectar.
Una de las áreas a tener en cuenta es la arquitectura. Aunque los sistemas funcionen, es posible que cada vez cueste más responder a preguntas básicas: por qué está diseñado así el entorno, qué partes son sustituibles o qué implicaría cambiar una capa crítica. Si se da este caso, es una señal de dependencia.
Otro aspecto es la operación. Externalizar la ejecución puede tener todo el sentido. El problema aparece cuando también se externaliza el entendimiento. Es decir, cuando el equipo interno necesita salir fuera tomar decisiones o resolver problemas.
En tercer lugar, la dependencia puede esconderse en la propia complejidad de las capas tecnológicas. Es decir, no tiene por qué estar directamente ligada a una gran plataforma, sino al conjunto de integraciones y conectores que hay alrededor, o un ecosistema de partners que se ha convertido en una maraña. Si nadie entiende el mapa completo, hay una dependencia.
El conocimiento que el CIO no puede permitirse perder
Todo esto desplaza el foco hacia una responsabilidad concreta: el conocimiento. No todas las capacidades pesan igual y ni tienen el mismo valor estratégico. Pero hay un umbral decisivo: el momento a partir del cual la organización deja de entender suficientemente una dependencia para poder gobernarla.
A partir de ahí, el riesgo va más allá de la operación. Se va debilitando la calidad de las decisiones y se reduce la capacidad de maniobra del CIO para discutir riesgos o costes. Se terminan aceptando muchos aspectos por sin que haya una decisión clara detrás.
Si no se detecta a tiempo, se corre el riesgo de llegar a un punto de no retorno, en el que se pierda el control de la hoja de ruta tecnológica.
Conclusión: el debate para el CIO
La conclusión no es necesariamente desconfiar por principio de proveedores o externalización. Hay una cuestión más sutil y exigente para el CIO: decidir con claridad en qué conocimiento puede cederse fuera y cuál no puede salir. En los próximos años, una parte creciente de la autonomía real de la empresa se jugará ahí. Porque esta dependencia no se anuncia con una gran crisis.
Por eso, el debate sobre soberanía necesita volverse más ejecutivo. Es decir, vincularse a la capacidad real de la empresa para entender aquello de lo que depende, y cambiar el rumbo cuando sea necesario. En un entorno de plataformas complejas, servicios encapsulados e inteligencia externalizada, preservar la capacidad de decisión va a ser una condición indiscutible para la autonomía tecnológica.
La siguiente tribuna llevará esta discusión un paso más allá: al impacto de la inteligencia artificial sobre estas dependencias y sobre el propio papel del CIO. Porque cuando la IA empiece a intervenir no solo en lo que la empresa usa, sino también en cómo diseña, opera y decide su tecnología, la cuestión dejará de ser solo de soberanía o de proveedores. Cambiará también el papel del CIO frente a ella.
Read More from This Article: La dependencia tecnológica que más impacta en el CIO: el conocimiento
Source: News