La nube no borra las dependencias: apagón de Salesforce

El hecho, en una frase

El 16 de septiembre de 2026, Salesforce sufrió un apagón global que duró alrededor de 7,5 horas y afectó a múltiples instancias en todas las regiones. El servicio se restableció a las 2:59 p.m. hora del Este. No fue un ataque ni una falla de la infraestructura de un tercero: según reportó la propia compañía, fue una dependencia interna oculta la que, bajo carga, terminó limitando la capacidad de procesar solicitudes en un componente central.

Ese detalle es el que debería interesar a cualquier director de tecnología, y no la caída en sí. La noticia de un proveedor caído dura un día; la lección sobre cómo se sostienen las integraciones dura años.

La causa que importa más que el apagón

El análisis publicado por CIO.com el 17 de septiembre de 2026 lo resume con una frase que conviene leer despacio. Abbas Jaffery, director de asesoría de Info-Tech Research Group, lo puso así: la nube no elimina las dependencias arquitectónicas. Y cuando la plataforma es tu sistema de registro, esas dependencias ocultas dejan de ser un riesgo tecnológico y se vuelven un riesgo de negocio.

Es una verdad incómoda, porque contradice el supuesto con el que muchas empresas migraron a la nube. El razonamiento era: "si está en la nube, es resiliente". Pero la resiliencia de un proveedor no es la resiliencia de tu operación. Tu empresa no depende solo de que el proveedor esté arriba: depende de las conexiones entre ese proveedor y todo lo demás. Y esas conexiones casi nunca están en el diagrama.

El apagón de Salesforce expuso exactamente eso. Fue una dependencia interna, no visible en la superficie, la que tumbó el procesamiento global. Los puntos de falla más peligrosos son los que nadie mapeó.

El problema del día después

Aquí está el punto que la mayoría de las empresas no tiene en cuenta. El incidente no termina cuando los usuarios vuelven a entrar. Ahí es donde empieza el trabajo difícil.

Info-Tech lo llama el "problema de los datos temporales": eventos que debían ocurrir en distintos momentos pueden ocurrir más tarde, fallar del todo o llegar fuera de orden. En términos de negocio, eso significa transacciones y procesos retrasados, APIs y middleware acumulando reintentos y timeouts, registros temporalmente inconsistentes, trabajos programados que no se ejecutan, y datos que divergen entre sistemas.

Pensalo como una fila de dominó que se detiene a la mitad del camino. Las piezas que siguen no caen en orden: algunas caen tarde, otras no caen, y otras se cruzan con la siguiente fila. Cuando "vuelve la luz", la cadena no está como estaba: está desordenada, y nadie sabe con certeza en qué punto.

Peor todavía: muchas veces no se perdió ningún dato. Simplemente quedó inconsistente, que para el negocio es igual de grave. Una factura duplicada, un inventario que no cuadra, un pedido que se procesó dos veces o nunca. Eso se convierte en un problema de facturación, de operación y de servicio al cliente que puede durar semanas.

Las preguntas que su equipo debería poder responder hoy

La recomendación de Info-Tech es directa: entrar a una fase de reconciliación e integridad apenas los usuarios pueden volver a entrar, sin dar el incidente por cerrado. Para saber si su empresa está preparada, hay cuatro preguntas que un director de TI debería poder responder sin convocar una reunión:

1. ¿Qué transacciones fallaron, quedaron a medias o se duplicaron? Si no hay una forma de saberlo rápido, ese es el primer punto ciego.
2. ¿Qué procesos asíncronos no se ejecutaron? Los trabajos programados y los flujos automáticos son los que primero se pierden en un apagón, y los que nadie nota hasta que ya deberían haber corrido.
3. ¿Las integraciones reintentaron bien, o generaron una avalancha? Un sistema que reintenta sin control transforma un apagón corto en un backlog largo, con colas que se saturan cuando el servicio vuelve.
4. ¿Los sistemas downstream quedaron consistentes? El ERP, la pasarela de pagos, el e-commerce y el sistema heredado: todos tienen que estar de acuerdo, no solo el proveedor de nube.

Si alguna respuesta es "no lo sabemos", ahí está el riesgo: en la capa de integración que conecta sus sistemas y que nadie mapeó.

De la reacción a la capacidad

El error más común es tratar la reconciliación como un plan de emergencia, algo que se activa cuando pasa un incidente. Lo correcto es tratarla como una capacidad permanente: saber, en todo momento, qué depende de qué, cómo reintentan las integraciones y cómo se reconcilian los datos cuando algo se sale de orden.

Eso se construye con disciplina de integración. Mapear las dependencias ocultas entre sistemas, definir qué hace cada integración cuando el servicio del que depende no responde, y ponerle dueño a esa capa. Es trabajo de ingeniería senior, no una herramienta que se instala y hace magia, y es exactamente el tipo de proyecto que un equipo interno enfocado en el roadmap del producto no puede meter en el sprint.

Byxel hace ese trabajo: integraciones multi-sistema entre sistemas que no se hablan entre sí, con responsabilidad técnica explícita de punta a punta.

Para seguir leyendo: el costo de mantener sistemas conectados a mano, la deuda de integración como pasivo que crece y el ROI de IA frente a la deuda técnica.

La pregunta que queda

El apagón de Salesforce fue una demostración de que la nube hace las dependencias más fáciles de crear y más difíciles de ver. Un sistema caído es una noticia; datos divergentes entre sistemas son un problema de negocio.

La pregunta, entonces, es si su empresa sabría qué hacer con las transacciones, los datos y las integraciones que quedaron desordenadas después de un apagón. La que responde esa pregunta antes de que ocurra es la que no pierde semanas reconciliando datos, sino que sigue operando.

¿Tenés sistemas que no se hablan entre sí y no sabés qué dependencias ocultas hay entre ellos? Hablemos de integraciones: escribinos por WhatsApp o agendá una reunión.