{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreib3y6paifhgh6xukaum5wcyizkzn2v4s7matq5ny5tqo2ks4pcp3q",
    "uri": "at://did:plc:qz6ohvpdsdvv5kniizyfz25y/app.bsky.feed.post/3mhxgfuxngst2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreic67opvr6alv5e4b26xhuv37a2aoq25mmviobni2dpynv2dqqxcuy"
    },
    "mimeType": "image/jpeg",
    "size": 1645760
  },
  "path": "/article/4150411/la-dependencia-tecnologica-que-mas-impacta-en-el-cio-el-conocimiento.html",
  "publishedAt": "2026-03-26T10:10:35.000Z",
  "site": "https://www.cio.com",
  "tags": [
    "Careers, IT Leadership, IT Operations, IT Strategy, Project Management",
    "banco británico TSB abordó una migración crítica de plataforma",
    "migración",
    "impacto",
    "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"
  ],
  "textContent": "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.\n\n## El caso TSB: el problema no fue una migración compleja\n\nEn 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.\n\nUna 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.\n\nLa 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.\n\nLa 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**.\n\n## La dependencia que no es noticia: el conocimiento\n\nCuando 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**.\n\nSe produce cuando la organización no conserva dentro suficiente conocimiento interno para discutir la tecnología, o someterla a un contraste serio.\n\nEl 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.\n\n## El verdadero _lock-in_ y una nueva definición de soberanía para el CIO\n\nCon 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.\n\nDe 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.\n\nPor 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?\n\nDesde 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.\n\n## Las dependencias de conocimiento están escondidas\n\nEl **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.\n\nUna 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.\n\nOtro 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.\n\nEn 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.\n\n## El conocimiento que el CIO no puede permitirse perder\n\nTodo 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.\n\nA 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.\n\nSi 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.\n\n## Conclusión: el debate para el CIO\n\nLa 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.\n\nPor 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**.\n\n_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._",
  "title": "La dependencia tecnológica que más impacta en el CIO: el conocimiento"
}