Dependencia tecnológica: lo que Stop Killing Games enseña a las empresas

La dependencia tecnológica aparece cuando tu negocio necesita un software o un servicio para operar, pero no controlas ni ese software ni a quien lo entrega, y no tienes una salida razonable si algo cambia. El movimiento Stop Killing Games la hizo visible en los videojuegos: personas que compraron un juego y un día no pudieron volver a jugarlo porque su editor apagó los servidores. Ese mismo mecanismo puede afectar al sistema con el que tu empresa vende, factura o atiende a sus clientes.

Este artículo usa el movimiento como punto de partida, pero no trata de videojuegos. Te explicamos, sin tecnicismos, qué compras realmente cuando contratas software, de qué depende ese software para seguir funcionando y qué conviene exigir desde el diseño para que tu negocio no quede atado a decisiones ajenas.

¿Qué es Stop Killing Games y por qué importa?

Stop Killing Games («dejen de matar los videojuegos») es un movimiento de consumidores que reclama que los juegos vendidos como productos completos no se vuelvan inservibles cuando su empresa decide cerrar los servidores. Importa fuera del mundo gamer porque plantea una pregunta general: ¿qué ocurre con un producto digital cuando quien lo mantiene deja de hacerlo?

El origen: el cierre de The Crew

La campaña nació como reacción a la decisión de Ubisoft de apagar los servidores de The Crew, un juego de carreras lanzado en 2014. Sin esos servidores, el juego dejó de poder jugarse y no se ofreció una alternativa para usarlo sin conexión. Quienes lo habían comprado quedaron con un producto que ya no podían usar. El movimiento lo impulsó el creador de contenido Ross Scott, y desde ahí fue ganando respaldo.

Qué piden en concreto

No se pide que los servidores funcionen para siempre. Se pide planificación: que, antes de retirar el soporte, exista un plan de fin de vida, por ejemplo un parche o una modificación que permita seguir usando lo que se compró. Es una exigencia de responsabilidad en el diseño, no de eternidad.

Dónde está hoy

La iniciativa tomó la forma de una Iniciativa Ciudadana Europea, un mecanismo que obliga a la Comisión Europea a responder cuando reúne un millón de firmas en al menos siete países. Según informó la Comisión Europea, la iniciativa reunió 1.294.188 firmas verificadas y se le entregó el 26 de enero de 2026. Siguieron una audiencia pública en el Parlamento Europeo el 16 de abril y un debate en el pleno el 21 de mayo.

El 16 de junio de 2026, la Comisión respondió que no propondrá una ley que obligue a mantener jugables los juegos descontinuados, y que dialogará con consumidores y editores antes de que termine 2026 para mejorar los estándares de la industria. La campaña continúa y busca que sus propuestas se incorporen a la Digital Fairness Act, una normativa europea sobre protección del consumidor en entornos digitales.

¿Qué sucede cuando una empresa apaga sus servidores?

Cuando una empresa apaga sus servidores, los productos que dependen de ellos pueden dejar de funcionar aunque no tengan ninguna falla propia. Un servidor es un computador remoto, de propiedad de otra empresa, donde corre una parte del software que usamos. Muchos productos digitales, no solo los videojuegos, necesitan «conversar» con ese computador para funcionar: validar una licencia, guardar información, procesar una operación o cargar contenido. Mientras el servidor exista y su dueño quiera mantenerlo, todo marcha.

Tres formas en que un producto deja de servir

• >Cierre del servicio: el proveedor decide retirar el producto o apagar la infraestructura que lo sostiene.
• >Cambio de condiciones: el proveedor modifica precios, funciones, límites de uso o la forma de conectarse, y lo que antes servía deja de servir o deja de convenir.
• >Caída o cambio de proveedor: una interrupción prolongada, un traspaso de la empresa o un giro de estrategia dejan al producto sin soporte.

En los tres casos el patrón es el mismo: la decisión no es de quien usa el producto. Y en los tres, el costo de no haber planificado una salida lo paga quien depende de él.

¿Eres propietario del software o solo tienes acceso?

Con frecuencia, quien paga por un software compra un derecho de uso con condiciones, no el producto ni su código. Lo que cada parte puede hacer lo establecen el contrato o los términos de uso, y por eso conviene leerlos antes, no después de un problema. Esta es una descripción general, no una opinión legal sobre un caso en particular.

La falsa sensación de propiedad nace ahí: pagas, usas el sistema a diario y termina sintiéndose propio. La diferencia solo se nota cuando algo cambia. Por eso la pregunta útil no es «¿pagué por esto?», sino «¿qué puedo hacer si mañana el proveedor no está?».

El mismo problema en el software empresarial

En el software empresarial el riesgo es el mismo que en un videojuego: tu negocio usa algo que depende de servidores y decisiones de otros. Se manifiesta de cuatro formas: el software como servicio, los servicios externos conectados, la obsolescencia y la manera en que el proveedor diseña y documenta el sistema.

Software como servicio (SaaS): comodidad con condiciones

El SaaS, es decir, el software que se usa por internet y se paga por suscripción, tiene ventajas reales: no hay que instalar nada, las actualizaciones llegan solas y el costo inicial suele ser menor. Usarlo no es un error. Lo que conviene tener claro es el costo menos visible: la información de tu negocio vive dentro del sistema de otro, y precios, funciones y condiciones los define el proveedor. La portabilidad de los datos, de hecho, aparece entre los derechos de las personas que repasamos en nuestra guía de auditoría de datos personales y Ley 21.719.

Servicios externos conectados al sistema

Muchos sistemas modernos se apoyan en servicios de terceros: medios de pago, envío de correos, mapas, inicio de sesión. A esas conexiones se les llama API. Si el tercero cambia la forma de conectarse, sube el precio o cierra, lo que depende de él deja de funcionar. Un diseño sano reconoce esas dependencias, las deja registradas y prevé cómo reemplazarlas.

Obsolescencia tecnológica

El software también envejece. Un sistema sin mantenimiento va quedando incompatible con navegadores, dispositivos y servicios nuevos, y sus componentes dejan de recibir actualizaciones de seguridad. No hace falta que alguien apague un servidor para que un producto se vuelva inviable: basta con que nadie lo siga manteniendo. Un ejemplo reciente fue la vulnerabilidad de PHP de octubre de 2026, ante la cual la primera medida recomendada fue confirmar con el proveedor qué versión de PHP corría cada sitio y cuándo se había actualizado. Por eso la continuidad no es solo un asunto de infraestructura: también depende del mantenimiento y de una documentación que permita a otro equipo continuar el trabajo.

La responsabilidad de quienes desarrollan y entregan tecnología

Quien diseña un sistema toma decisiones que el cliente rara vez ve: qué servicios externos usa, dónde quedan los datos, quién tiene las claves. Esas decisiones determinan si tu negocio podrá moverse o quedará atado. La responsabilidad de un proveedor tecnológico incluye explicarlas con claridad, dejarlas documentadas y no presentar como propiedad lo que en realidad es acceso. Es una cuestión de transparencia y de buen diseño, antes que un asunto legal.

¿No sabes qué pasaría con tu sistema si tu proveedor cambia o desaparece? Solicita una demostración con Itechnova y revisemos cómo se vería, en tu negocio, un sistema que te entregue el código, los respaldos y los accesos a tu nombre.

Cinco principios para diseñar software que no deje a tu empresa en rehén

Un software que no deje a tu empresa en rehén se diseña con cinco principios: portabilidad, independencia tecnológica, respaldo de información, continuidad operativa y propiedad y acceso claros. No se trata de evitar la nube ni los servicios externos: usar un medio de pago o un servicio de alojamiento conocido es una decisión razonable. El problema aparece cuando dependes de ellos sin poder salir, y estos principios apuntan a conservar esa salida. Son criterios de diseño que recomendamos en Itechnova, no una norma ni un estándar.

1. Portabilidad

Un sistema es portable cuando sus datos y su aplicación pueden moverse a otro proveedor sin empezar de cero. En la práctica significa usar formatos abiertos, poder exportar la información completa y evitar tecnologías que solo funcionan en un único lugar. Mientras más fácil sea irse, menos riesgoso resulta quedarse.

2. Independencia tecnológica

Consiste en evitar depender innecesariamente de un único servicio externo. La palabra clave es «innecesariamente»: algunas dependencias aportan un beneficio claro y vale la pena aceptarlas, pero deberían ser decisiones conscientes, registradas y con una alternativa a la vista. Si un servicio crítico no tiene reemplazo posible, tu negocio debe saberlo y evaluarlo antes de comprometerse.

3. Respaldo de información

Si un sistema falla, el software puede volver a instalarse, pero los datos de tu negocio solo se recuperan si existe un respaldo. Un respaldo útil es una copia reciente, guardada en un lugar distinto del sistema principal y que tu empresa pueda recuperar por sí misma. Conviene además comprobar cada cierto tiempo que la restauración funciona, porque un respaldo que nunca se probó es solo una suposición.

4. Continuidad operativa

Es la capacidad de seguir operando, o de volver a hacerlo rápido, cuando algo falla o cambia. Implica prever qué pasa si cae un servicio, si un proveedor sube sus tarifas o si hay que migrar. Un plan de continuidad no necesita ser complejo: debe decir quién hace qué, con qué información y en qué orden.

5. Propiedad y acceso claros

Debe quedar escrito qué recibes como cliente: si te entregan el código, dónde está el repositorio, quién administra el dominio y las cuentas, y qué documentación acompaña al sistema. Sin esa claridad, la propiedad es solo una impresión. Con ella, sabes exactamente qué puedes hacer si decides cambiar de proveedor.

Cómo se traduce esto en un desarrollo a medida

Un desarrollo a medida permite aplicar los cinco principios desde el primer día, porque no se parte de un producto cerrado de otra empresa.

En Itechnova, estudio de desarrollo de software con sede en Chile, consideramos que esa autonomía debe formar parte del proyecto desde el inicio. Por eso, en nuestros desarrollos a medida contemplamos la entrega del código fuente y el repositorio, la documentación de dependencias externas, los respaldos bajo control del cliente y la administración del dominio y los accesos a su nombre. También definimos mecanismos de continuidad para facilitar la recuperación ante fallos o cambios de proveedor.

En concreto, como cliente recibes:

• >Código y repositorio: el código del proyecto y el repositorio donde vive.
• >Dependencias documentadas: el detalle de los servicios externos que usa el sistema.
• >Respaldos bajo tu control: la administración de los respaldos queda en tus manos.
• >Plan de continuidad: un plan ante caídas o cambios de proveedor.
• >Dominio y accesos a tu nombre: el control del sitio y sus cuentas es tuyo desde el inicio.

Nada de esto elimina la necesidad de mantener el sistema en el tiempo, pero cambia lo que significa cambiar de proveedor: si algún día decides hacerlo, es un trámite ordenado y no un rescate.

Si estás evaluando un sistema nuevo, o quieres reemplazar uno que hoy te tiene atado, revisa el servicio de desarrollo a medida de Itechnova y cotiza tu proyecto. Y si ya tienes un sistema o una suscripción funcionando, no necesitas cambiarlos de inmediato: parte por hacerle las preguntas del checklist a tu proveedor actual.

Checklist: preguntas para hacerle a un proveedor antes de contratar

Siete preguntas bastan para saber cuánto control tendrías sobre un software antes de contratarlo. Sirven tanto para un desarrollo a medida como para una suscripción:

Las respuestas vagas también informan. Un proveedor que no puede explicar con claridad qué entrega y de qué depende está mostrando un riesgo. Y si ya tienes un sitio o sistema funcionando, nuestra guía de auditoría de seguridad web en Chile te ayuda a revisar en qué estado está. Si todavía estás en la etapa previa, nuestra guía sobre cómo planificar un sitio web antes de contratar a un desarrollador te ayuda a ordenar qué pedir.

El futuro de la propiedad digital

La discusión sobre qué significa «comprar» algo digital seguirá abierta. Stop Killing Games no consiguió una ley europea, pero logró que un parlamento hablara de algo que antes era una queja de jugadores: los productos digitales pueden desaparecer, y planificar esa posibilidad no debería ser opcional.

En nuestra opinión, es razonable esperar que cada vez más clientes, también los empresariales, pregunten por portabilidad, respaldos y condiciones de salida. Las empresas que resuelvan eso desde el diseño estarán mejor preparadas, sin esperar a que una norma lo exija.

Conclusión: que la decisión siga siendo tuya

La dependencia tecnológica rara vez se nota mientras todo funciona. Se nota el día en que un proveedor cambia, cierra o modifica sus condiciones. El criterio práctico para el dueño de un negocio es simple: antes de contratar, preguntar qué recibe, de qué depende el sistema y cómo se sale. Un desarrollo a medida bien planteado responde esas tres preguntas desde el principio: con código entregado, dependencias documentadas, respaldos bajo tu control y un plan de continuidad. Así trabaja Itechnova en sus desarrollos a medida, para que la decisión siga siendo de tu negocio.

Preguntas frecuentes sobre dependencia tecnológica

¿Cómo sé si mi negocio depende demasiado de un proveedor de software?

Si no puedes exportar tu información, no sabes de qué servicios externos depende el sistema, no controlas los respaldos o el dominio está a nombre del proveedor, tu negocio depende más de lo conveniente. Si además no existe un plan para cuando el proveedor cambie o cierre, la salida tendrá que improvisarse.

¿Pagar por un software significa que soy dueño de él?

No necesariamente. Con frecuencia se paga por un derecho de uso con condiciones, no por el código ni por la infraestructura. Lo que recibe cada parte debe estar escrito en el contrato o en los términos de uso, y conviene revisarlo antes de contratar.

¿Usar software como servicio (SaaS) o la nube es un error?

No. Son opciones válidas y cómodas. El riesgo está en depender de ellas sin poder exportar tu información ni migrar a otro proveedor. Por eso conviene preguntar por portabilidad, respaldos y condiciones de salida, y usarlas sabiendo qué datos quedan dentro del sistema del proveedor y cómo podrías salir.

¿Qué pasa con mi negocio si mi proveedor de software desaparece?

Depende de lo que se haya previsto desde el diseño. Si cuentas con el código, la documentación, respaldos propios y un plan de continuidad, puedes trasladar el sistema a otro equipo. Sin eso, la operación queda expuesta: hay que reconstruir sobre la marcha qué hace el sistema, de qué depende y dónde están los datos.

¿Qué debería recibir mi empresa cuando encarga un desarrollo a medida?

Como mínimo, el código y el repositorio, la documentación de las dependencias externas, respaldos que puedas controlar, un plan de continuidad y el dominio y los accesos a tu nombre. Conviene que todo eso quede escrito desde el inicio. En Itechnova trabajamos de esa manera en nuestros desarrollos a medida.

¿Qué es Stop Killing Games?

Es un movimiento de consumidores que nació tras el cierre de los servidores de The Crew y pide que los juegos tengan un plan de fin de vida cuando el editor retire el soporte. Su iniciativa ciudadana europea reunió 1.294.188 firmas verificadas.