Un recorte histórico en la empresa más grande del mundo

Amazon, con más de 1,5 millones de trabajadores en todo el mundo, ha comenzado uno de los ajustes laborales más grandes de su historia. En un primer anuncio, la compañía confirmó el despido de alrededor de 14.000 empleados, principalmente del área corporativa: ingenieros, gerentes, analistas y personal de oficinas.

Si se compara, es como si Amazon hubiera eliminado toda la plantilla actual de empresas como Netflix. Aunque la cifra parece descomunal, representa apenas un 4% de su fuerza laboral corporativa.

El CEO de la empresa, Andy Jassy, explicó en una carta interna que el objetivo no es simplemente reducir costos, sino reorganizar la estructura interna para ser “más ágil, eficiente y con menos capas de gestión”. En otras palabras, Amazon quiere volver a comportarse como una “startup gigante”: menos burocracia, más autonomía y decisiones más rápidas.

¿Por qué están ocurriendo estos despidos?

Los motivos detrás de los recortes no se limitan a un solo factor. Según reportes de Business Insider y Reuters, Amazon está respondiendo a una combinación de presiones económicas y tecnológicas:

• Exceso de contratación durante la pandemia: entre 2020 y 2022, la empresa contrató a cientos de miles de personas para hacer frente al boom del comercio electrónico.
• Caída en la demanda y aumento de costos: con la normalización postpandemia, las ventas se estabilizaron y los costos de operación crecieron, especialmente por temas logísticos y arancelarios.
• Transformación interna impulsada por la IA: la inteligencia artificial está empezando a sustituir tareas administrativas, análisis de datos, gestión de inventarios e incluso atención al cliente.

En otras palabras, Amazon está ajustándose a una nueva realidad en la que la IA no solo reemplaza manos, sino también decisiones.

El papel de la inteligencia artificial: menos manos, más máquinas

Amazon planea automatizar hasta un 75% de sus operaciones para 2033.

Esto significa que en menos de una década, tres de cada cuatro tareas que hoy realizan empleados humanos podrían ser ejecutadas por sistemas de IA y robots. Desde los almacenes hasta las oficinas, la empresa busca reducir tareas repetitivas y optimizar tiempos y recursos.

Este cambio, sin embargo, no se limita a Amazon. Otras grandes corporaciones como Meta, Intel o General Motors ya están anunciando procesos similares. El mensaje es claro: la automatización ya no se concentra solo en fábricas o centros logísticos; ahora amenaza también los empleos de oficina.

Una transformación profunda del empleo

Lo que está ocurriendo en Amazon es, en realidad, el reflejo de una revolución laboral global.
Durante la primera Revolución Industrial, las máquinas reemplazaron el trabajo manual. Hoy, la IA reemplaza tareas cognitivas: análisis, redacción de informes, gestión de correos, toma de decisiones simples.

Según Harvard Business Review, casi todos los trabajos actuales contienen tareas que la inteligencia artificial puede realizar igual o mejor que los humanos. Y el fenómeno se acelera: lo que se esperaba para dentro de 10 años está ocurriendo en apenas uno o dos.

El impacto no será uniforme. Los puestos más amenazados son aquellos donde las tareas son rutinarias, predecibles o repetitivas, incluso en entornos administrativos.
Por el contrario, los trabajos que implican creatividad, pensamiento estratégico, liderazgo o trato humano seguirán siendo esenciales y más difíciles de automatizar.

“El futuro del trabajo” ya comenzó

En un video viral sobre los despidos, el creador de contenido y exingeniero de Netflix, ThePrimeTimeTech, explicaba que Amazon busca “eliminar procesos innecesarios” y dar más autonomía a los empleados que permanezcan. Según él, más del 70% de los despidos actuales afectan a cargos directivos o intermedios, lo que coincide con la intención del CEO de reducir capas jerárquicas.

Sin embargo, el especialista advierte que esta transición, aunque necesaria para la empresa, no es una buena noticia para los trabajadores que dependen de la estabilidad corporativa.
A corto plazo, la IA está generando más incertidumbre que oportunidades. Pero, a largo plazo, podría impulsar un mercado laboral más competitivo, flexible y basado en habilidades reales.

¿Qué significa esto para los trabajadores?

Para quienes hoy temen por sus empleos, los expertos insisten en un mensaje: la clave está en la adaptación.
“Las empresas que no sigan el camino de Amazon se quedarán atrás. Y los trabajadores que no se reconviertan, también.”

Esto no significa que todo el mundo deba aprender a programar o dominar la IA, pero sí implica mantenerse en constante aprendizaje: desarrollar pensamiento crítico, habilidades comunicativas y conocimientos digitales básicos.

Las oportunidades seguirán existiendo, pero no necesariamente en los mismos lugares.
El futuro del trabajo no será humano o artificial, sino una mezcla de ambos.

Amazon marca el inicio de una nueva etapa

Los despidos masivos de Amazon no son solo un ajuste interno: son el inicio de una transformación estructural del mercado laboral global.
Así como en el pasado la mecanización cambió las fábricas, hoy la inteligencia artificial redefine qué significa trabajar.

Las empresas buscarán eficiencia. Los trabajadores, estabilidad. Y en medio de ambos, la tecnología seguirá avanzando sin pausa.

El reto, ahora, es que esta nueva era no deje atrás a las personas, sino que las impulse a reinventarse.
Como diría un experto del MIT: “El trabajo no desaparecerá. Lo que desaparecerán son las tareas que ya no necesitan de nosotros.”

Fuentes consultadas

• Business Insider: “AI job apocalypse: how automation is reshaping Amazon’s workforce” (2025)
• Negocios.com: “Amazon planea automatizar el 75% de sus operaciones para 2033” (25 de octubre de 2025)
• Reuters, BBC, The Guardian (actualizaciones sobre despidos y automatización)

¿Qué es NPM y qué lenguajes lo usan?

NPM (Node Package Manager) es el gestor de paquetes predeterminado para el ecosistema de JavaScript. Es una herramienta que utilizan principalmente los desarrolladores de Node.js y aplicaciones web para administrar fácilmente las librerías o “dependencias” de sus proyectos. En otras palabras, NPM funciona como una enorme biblioteca o almacén de código reusable: ofrece acceso a un vasto repositorio con más de un millón de módulos de código abierto que cualquiera puede instalar con simples comandos. Esto permite que los programadores compartan y reutilicen código, ahorrando tiempo al no tener que reinventar la rueda para tareas comunes.

NPM soporta principalmente proyectos escritos en JavaScript (y su superset TypeScript), ya que viene incluido con Node.js y es parte integral del desarrollo web moderno. Gracias a NPM, frameworks populares de JavaScript como React, Angular o Vue, así como herramientas de servidor en Node.js, pueden integrar miles de paquetes creados por la comunidad. La razón por la que tantos proyectos usan NPM es porque facilita la instalación, actualización y gestión de dependencias de forma centralizada, asegurando que cada proyecto tenga las librerías correctas en la versión adecuada. De hecho, NPM es el registro de software más grande del mundo en cuanto a cantidad de paquetes disponibles. En resumen, prácticamente cualquier aplicación web o móvil moderna que use JavaScript probablemente dependa de paquetes instalados vía NPM, lo que explica por qué un ataque a NPM puede tener un impacto tan amplio.

¿Cómo se descubrió el ataque y cuál fue el problema?

El ataque se descubrió a principios de septiembre de 2025, cuando expertos en seguridad detectaron que se habían publicado versiones sospechosas de ciertos paquetes muy populares de NPM. Todo comenzó cuando un actor malicioso logró comprometer la cuenta de un mantenedor reconocido de NPM. En particular, el desarrollador Josh Junon (conocido en NPM como “qix”) fue víctima de una campaña de phishing altamente sofisticada. Este mantenedor recibió un correo electrónico que parecía venir del equipo oficial de NPM, usando un dominio falso casi idéntico (npmjs.help). En el mensaje se le amenazaba con bloquear su cuenta si no “actualizaba” urgentemente la configuración de autenticación de dos factores (2FA). Lamentablemente, al hacer clic en el enlace y proporcionar sus datos, el atacante obtuvo el usuario, la contraseña y el código 2FA de una sola vez, tomando control total de la cuenta.

Una vez dentro de la cuenta del mantenedor, el atacante publicó nuevas versiones maliciosas de al menos 18 paquetes muy utilizados, incluyendo librerías famosas como debug y chalk. Estas librerías por sí solas acumulan cientos de millones de descargas cada semana (por ejemplo, debug tiene ~357 millones semanales y chalk casi 300 millones). Sumando todos los paquetes afectados (como ansi-styles, color-convert, strip-ansi, entre otros), superaban los 2 mil millones de descargas por semana – lo que da una idea del alcance de la intrusión. En efecto, se trató de un ataque masivo: al comprometer la cuenta de un solo desarrollador influyente, los atacantes lograron infiltrar malware en decenas de miles de proyectos río abajo que dependían de esas librerías sin saberlo.

La comunidad detectó algo extraño rápidamente. En cuestión de horas, desarrolladores y empresas de seguridad notaron que el código de estas nuevas versiones contenía lógica ofuscada (escondida) sospechosa, específicamente fragmentos de código que no pertenecían a las versiones legítimas. Alrededor de las 9 AM (EST) del 8 de septiembre ya se habían publicado los paquetes infectados, y antes del mediodía ese mismo día el incidente fue expuesto públicamente y el propio mantenedor confirmó la brecha. Inmediatamente se iniciaron acciones de mitigación: se publicaron actualizaciones “limpias” de los paquetes para reemplazar a las comprometidas y NPM retiró las versiones maliciosas en pocas horas. Además, NPM procedió a bloquear o “congelar” las cuentas afectadas para investigar y evitar más daños. En total, las versiones infectadas estuvieron disponibles alrededor de dos horas antes de ser eliminadas. Sin embargo, ese breve lapso fue suficiente para que muchas aplicaciones automáticamente las descargaran (por ejemplo, mediante dependencias que se actualizan en procesos de construcción CI/CD), propagando el malware con una rapidez alarmante.

¿Qué hace el malware y cuáles son las consecuencias para los usuarios?

El código malicioso introducido en estos paquetes estaba diseñado con un objetivo principal: robar criptomonedas y datos sensibles de las aplicaciones que usaran las librerías comprometidas. A diferencia de un virus tradicional, este malware no infecta el sistema operativo ni se instala como un programa independiente; más bien, actúa como una especie de “polizón” dentro de aplicaciones web. Cuando un desarrollador actualizó (sin saberlo) una de estas dependencias comprometidas y luego su proyecto fue desplegado en la web, el código malicioso se integraba al JavaScript de la aplicación. Así, cualquier usuario final que cargaba esa aplicación en su navegador podía estar ejecutando también el malware en segundo plano.

En términos más sencillos, el ataque funcionó así: el malware se infiltra en el navegador web del usuario a través del sitio o aplicación afectada, y allí comienza a vigilar ciertas operaciones financieras. Por ejemplo, intercepta llamadas a APIs de criptomonedas y funciones de red como fetch o XMLHttpRequest (usadas para comunicar con servidores). También engancha las interfaces de wallets (billeteras digitales) en el navegador, como window.ethereum que usan herramientas tipo MetaMask. El malware está constantemente escaneando si el usuario va a realizar una transacción de criptomoneda (ya sea enviar fondos o aprobar un movimiento en Ethereum, Bitcoin, Solana, Tron, Litecoin, etc). En el momento en que detecta una transacción, astutamente reemplaza la dirección de destino legítima por una perteneciente a los atacantes. Esto lo hace de forma silenciosa y cuidada: utiliza técnicas para que la dirección modificada se parezca a la original (cambiando algunos caracteres por otros similares) de modo que a simple vista en la interfaz nada parezca raro. Así, cuando la persona afectada confirma la transacción pensando que todo está correcto, en realidad está enviando dinero al monedero del hacker sin darse cuenta.

Las consecuencias directas de este ataque pueden ser muy graves para los usuarios finales y las empresas: desde pérdida de fondos en criptomonedas (imagine que transfiere dinero a los atacantes sin saberlo), hasta potencial filtrado de datos sensibles. Afortunadamente, hasta donde se ha reportado, el impacto efectivo en robo de criptodivisas fue limitado – al parecer los atacantes no lograron hacer mucho botín antes de ser descubiertos. Sin embargo, el daño potencial fue enorme, y solo la rápida respuesta evitó un desastre mayor. Además, aunque no todos los proyectos afectados eran aplicaciones financieras, el incidente causó una especie de “denegación de servicio” a la industria en el sentido de que miles de desarrolladores tuvieron que pausar su trabajo para revisar si sus aplicaciones estaban comprometidas, actualizar dependencias y reforzar medidas de seguridad. En otras palabras, incluso donde no hubo robo directo, sí hubo pérdidas de tiempo, confianza y productividad.

Para la comunidad de desarrolladores, este ataque fue un balde de agua fría. Demostró lo vulnerable que puede ser la cadena de suministro de software: si un solo mantenedor es engañado, el efecto dominó puede impactar a miles de proyectos y millones de usuarios. Muchos desarrolladores, incluso juniors o personas no técnicas, se preguntan cómo es posible que algo así ocurra y qué se puede hacer al respecto. A continuación, veremos cómo respondió la comunidad y qué medidas se están tomando.

¿Qué hizo la comunidad al respecto?

La respuesta de la comunidad y de los administradores de NPM fue rápida y contundente. Una vez identificado el problema, como mencionamos, se eliminaron las versiones maliciosas y se restauró la seguridad de los paquetes afectados en cuestión de horas. El mantenedor comprometido (Josh “qix” Junon) comunicó abiertamente lo ocurrido, admitiendo que fue víctima del phishing, lo cual sirvió de alerta para otros desarrolladores sobre este tipo de trampas. NPM, por su parte, bloqueó las cuentas involucradas y muy probablemente contactó a los demás propietarios de paquetes populares para reforzar sus medidas de seguridad.

Este incidente también aceleró conversaciones en la comunidad sobre mejorar la seguridad del ecosistema open-source. Ya antes NPM (que es administrado por GitHub/Microsoft) había comenzado a exigir autenticación de dos factores obligatoria para los mantenedores de paquetes críticos. Tras el ataque, se reiteró la importancia de que todos los autores de paquetes tengan 2FA habilitado, para que incluso si una contraseña se ve comprometida, los atacantes no puedan acceder tan fácilmente. Sin embargo, como vimos, el phishing logró saltarse incluso la 2FA al engañar al usuario para que revelara su código temporal. Por ello, algunos expertos sugieren implementar métodos más robustos, como llaves de seguridad física o sistemas de firma digital de paquetes, que hagan más difícil suplantar la identidad de un mantenedor legítimo.

La comunidad de código abierto también está discutiendo la necesidad de herramientas automatizadas de detección de malware en paquetes. Empresas de seguridad como Aikido, Wiz, JFrog, Sonatype, entre otras, han desarrollado sistemas de monitoreo que analizan las nuevas versiones publicadas en NPM en busca de comportamientos sospechosos. De hecho, en este caso varios de esos sistemas alertaron casi de inmediato cuando se publicó el código malicioso, lo que permitió contener el incidente rápidamente. Es posible que en el futuro cercano veamos integradas en NPM algunas de estas medidas, de modo que cuando alguien intente publicar una versión de un paquete que contenga código potencialmente malicioso, se emitan alertas o bloqueos preventivos antes de que llegue a los usuarios.

Otro aspecto que la comunidad ha enfatizado es la educación y concienciación. Muchos desarrolladores están compartiendo sus experiencias sobre cómo identificar correos de phishing como el que engañó al mantenedor. NPM y organizaciones afines podrían enviar recordatorios más visibles sobre nunca hacer clic en enlaces sospechosos y verificar dos veces los dominios de los correos (por ejemplo, notar que npmjs.help no es el dominio oficial npmjs.com). También se está recomendando revisar los logs de proyectos para ver si entre las dependencias instaladas en ese periodo de tiempo entró alguna versión comprometida, y si es así, volver a instalar una versión segura inmediatamente.

En resumen, la comunidad reaccionó con rapidez reparando el daño, y ahora se centra en aprender de lo ocurrido para fortalecer la seguridad a futuro. Esto incluye desde medidas técnicas (2FA, firmas digitales, escáneres de malware) hasta buenas prácticas humanas (desconfiar de correos inesperados, revisar las dependencias antes de actualizar, etc.).

¿Qué puedes hacer para evitar este tipo de ataques en tus dependencias de NPM?

Si bien es difícil para un desarrollador individual anticipar un ataque de esta naturaleza, sí hay buenas prácticas que puedes adoptar para minimizar los riesgos en tus proyectos:

• Mantén tus dependencias actualizadas, pero con precaución: Actualizar regularmente ayuda a obtener parches de seguridad, pero hazlo de forma informada. Lee las notas de versión y presta atención a alertas de la comunidad. Si se reporta que cierta versión fue comprometida, evita instalarla. Herramientas como npm audit o servicios de monitoreo de vulnerabilidades pueden ayudarte a enterarte de problemas conocidos rápidamente.
• Habilita la autenticación de dos factores (2FA) en tu cuenta de NPM si eres un mantenedor de paquetes. Esto añade una capa extra de seguridad para que nadie más pueda publicar versiones en tu nombre sin ese código adicional. Y nunca compartas ni ingreses tu código 2FA en sitios que no sean los oficiales; NPM nunca te pedirá que “revalides” tu 2FA por correo de esa manera.
• Revisa las fuentes de tus paquetes: Mientras sea posible, intenta usar paquetes populares y mantenidos por comunidades confiables. Evita descargar dependencias de fuentes desconocidas o fuera del registro oficial de NPM. Si usas un paquete poco común, considera mirar su código fuente o los comentarios de otros usuarios para asegurarte de que no haya comportamientos extraños.
• Monitorea tus aplicaciones en producción: Si tu aplicación maneja transacciones (por ejemplo, comercio electrónico o integra criptomonedas), implementa monitoreos que detecten actividades inusuales. En este ataque, por ejemplo, si de repente varias transacciones iban a la misma dirección desconocida, podría saltar una alarma. Revisar los logs y tener alertas de movimientos sospechosos de fondos es recomendable.
• Sigue las recomendaciones de seguridad de la comunidad: Mantente informado con blogs de seguridad, foros de desarrolladores y las comunicaciones oficiales de NPM/GitHub. Cuando ocurren incidentes como este, suelen publicarse guías de cómo mitigar el problema (por ejemplo, qué versiones específicas actualizar). Participar en la conversación te ayudará a reaccionar rápido si algo afecta a tus proyectos.

Para quienes no programan, puede sonar alarmante que un componente invisible en el código de una aplicación pueda comprometer la seguridad de tantos usuarios. Sin embargo, la comunidad está trabajando activamente para reforzar la cadena de suministro del software y prevenir futuros incidentes.

En medio de este debate, la división de investigación Microsoft Research ha dado a conocer un estudio que ofrece datos concretos sobre el impacto de la IA en distintos empleos. Un grupo de investigadores de Microsoft analizó qué 40 profesiones son las más susceptibles de automatización mediante IA, basándose en el uso real de estas herramientas en cada campo. El estudio se centró en el mercado laboral de EE.UU., pero sus hallazgos pueden extrapolarse a muchos otros países desarrollados y en desarrollo. Según los resultados, más de 8,4 millones de trabajadores estadounidenses ya están empleados en alguno de estos 40 roles altamente impactados por la IA.

Un estudio para medir el impacto real de la IA en el trabajo

A diferencia de estudios teóricos previos, Microsoft abordó esta cuestión analizando datos reales de uso de IA. Específicamente, los expertos recopilaron 200.000 conversaciones anónimas entre usuarios y la plataforma Bing Chat / Copilot (el asistente basado en IA de Microsoft) a lo largo de 9 meses durante 2024. Cada interacción se mapeó contra las bases de datos de tareas laborales del Departamento de Trabajo de EE.UU. (concretamente el estándar O*NET), identificando qué actividades de cada profesión estaban involucradas en las consultas a la IA.

A partir de este mapeo, los investigadores crearon una “puntuación de aplicabilidad de la IA” para cada ocupación. Esta puntuación combina varios indicadores: por ejemplo, cuán exitosamente la IA pudo completar las tareas solicitadas, qué porcentaje de personas acudió al asistente para resolver cierta tarea y hasta qué punto el resultado fue útil según el feedback de usuarios. En esencia, mide el solapamiento entre las capacidades actuales de la IA y las tareas típicas de cada empleo. Cuanto más alta la puntuación, mayor es la porción del trabajo que ya puede ser realizada (al menos parcialmente) con ayuda de IA generativa.

^“Nuestro estudio explora cómo la IA puede moldear las ocupaciones examinando el uso en el mundo real. Introduce una puntuación de aplicabilidad de la IA que mide las capacidades de la IA frente a las tareas laborales, destacando dónde la IA podría cambiar la forma en que se realiza el trabajo^”, explicó Kiran Tomlinson, investigador principal del proyecto. En otras palabras, no se trata de predecir en abstracto, sino de ver dónde la IA ya está siendo utilizada con éxito en tareas laborales cotidianas.

Las 40 profesiones con mayor probabilidad de ser impactadas por la IA

El resultado más llamativo del estudio fue un listado de 40 puestos de trabajo que obtuvieron las puntuaciones más altas de aplicabilidad de IA. Esto significa que en estos roles la IA tiene una alta capacidad de ayudar (o potencialmente reemplazar ciertas tareas), en comparación con otras ocupaciones. Importante: una puntuación alta no implica necesariamente que la IA vaya a eliminar esos empleos por completo, sino que muchas de sus tareas pueden ser automatizadas o asistidas por IA. A continuación presentamos la lista completa de los 40 empleos más expuestos, junto a la puntuación de IA que Microsoft les asignó en el estudio:

Como se observa, muchos de los trabajos en la lista comparten un perfil “informacional”: son roles que implican procesar lenguaje, manejar datos, comunicar información o realizar tareas rutinarias de oficina. Por ejemplo, traductores, escritores, periodistas y correctores dependen principalmente de la generación y revisión de texto, algo que los modelos de IA generativa (como GPT-4) ya hacen sorprendentemente bien. Del mismo modo, los representantes de ventas y servicio al cliente pasan gran parte del día comunicándose con personas, resolviendo preguntas o promoviendo productos, tareas en las que un chatbot avanzado puede desempeñarse con eficacia. No es sorprendente entonces que la IA tenga alta aplicabilidad en estos campos que no requieren presencia física ni destrezas manuales, sino trabajo cognitivo que una máquina puede imitar.

Los profesionales dedicados a escribir, traducir o generar contenido se encuentran entre los más expuestos a la IA. Herramientas de redacción automática, traducción y creación de informes pueden acelerar (o reemplazar parcialmente) muchas de sus tareas cotidianas.

Llama la atención la presencia de algunos empleos en apariencia muy calificados en la lista, como científicos de datos (29º) o profesores universitarios de ciertas áreas (Negocios, Economía, Biblioteconomía). Esto no significa que la IA vaya a suplantar por completo a estos profesionales, sino que incluso en ocupaciones altamente especializadas ya se está usando IA para tareas puntuales. Por ejemplo, un científico de datos puede apoyarse en un asistente de IA para generar código o documentar hallazgos, y un profesor puede emplear ChatGPT para elaborar material didáctico o evaluaciones. Así, la IA actúa más como un “copilot” que realiza parte del trabajo pesado, mientras el humano supervisa y aporta la creatividad o el criterio donde la máquina no llega.

¿Qué tan segura está mi profesión frente a la IA?

Es importante recalcar que “impacto” no equivale automáticamente a despidos masivos. Los mismos autores del estudio advierten que sería un error concluir que las ocupaciones con alto solapamiento verán una pérdida inmediata de empleos. La investigación de Microsoft midió qué tareas puede hacer la IA actualmente, pero no predice directamente las decisiones empresariales ni las dinámicas económicas a largo plazo. De hecho, el efecto de la automatización podría manifestarse de formas diferentes según el caso: algunas empresas podrían reducir plantilla para ahorrar costos, mientras otras podrían aspirar a más y mantener (o incluso contratar) personal apoyado por IA para ser más productivos. Como explican los investigadores, su análisis se limita a la capacidad de la IA para realizar tareas, sin datos sobre las consecuencias posteriores en creación o eliminación de puestos.

En otras palabras, un puntaje alto de IA indica que esa profesión cambiará significativamente gracias a estas tecnologías, pero no necesariamente para mal. En muchos casos, veremos una transformación del rol más que su eliminación. Por ejemplo, en vez de desaparecer el trabajo de un redactor, es posible que la IA se encargue de los borradores iniciales o de la documentación repetitiva, dejando al humano las tareas de edición fina, estrategia de contenido y creatividad. Un traductor humano podría centrarse en matices culturales y calidad estilística, apoyándose en traducciones automáticas como base. Y así en muchas otras áreas: la colaboración hombre-máquina podría ser el modelo dominante, al menos en el corto plazo.

Por supuesto, existen voces tanto optimistas como pesimistas sobre este tema. Algunos líderes de la industria tecnológica han advertido que la IA podría llegar a eliminar hasta la mitad de los empleos de oficina y administrativos en los próximos años. Por el contrario, otros (como el empresario Mark Cuban) sostienen que la IA, al automatizar el trabajo tedioso, acabará generando más empleos de los que destruye, impulsando nuevas industrias y aumentando la demanda de trabajadores en áreas emergentes. Lo que sí parece claro es que la naturaleza del trabajo evolucionará: tareas que antes requerían horas de esfuerzo ahora se completarán en minutos con un botón, mientras surgirán necesidades antes inexistentes (por ejemplo, prompt engineers, supervisores de resultados de IA, etcétera).

Finalmente, cabe mencionar que el estudio de Microsoft deliberadamente se enfocó en IA de tipo modelo de lenguaje (LLM) operando en entornos digitales. Esto explica por qué los trabajos manuales o técnicos (operarios, mecánicos, construcción, salud asistencial, etc.) aparecen como los “menos afectados” en esta investigación. Ocupaciones que demandan esfuerzo físico considerable o manejo de maquinaria quedaron al fondo del ranking de aplicabilidad de IA. En la lista complementaria de 40 empleos menos amenazados (no mostrada aquí), aparecen roles como auxiliares de enfermería, técnicos de laboratorio clínico, albañiles, limpiadores, instaladores, operadores de maquinaria pesada, entre otros. Estos puestos hoy por hoy requieren destrezas motoras, contacto humano directo o adaptabilidad a entornos cambiantes, cosas donde las IA actuales (basadas solo en software) no pueden competir. Sin embargo, eso no significa que estén completamente fuera del alcance de la automatización en el futuro: avances en robótica e IA especializada podrían algún día abordar también parte de esas tareas físicas. Por ejemplo, aunque un dron autónomo difícilmente reemplace pronto a un albañil, ya existen robots pintores, prototipos de enfermeros robóticos e incluso vehículos autónomos en prueba. La frontera de lo que la IA puede o no puede hacer se mueve constantemente.

Una realidad en desarrollo: adaptabilidad y aprendizaje continuo

El estudio de Microsoft nos ofrece un valioso vistazo a cómo la IA ya está incidiendo en el mundo laboral actual. Identificar los 40 empleos más impactados por la IA no equivale a dictar sentencia de muerte para esas profesiones, sino a reconocer que son las que más verán transformadas sus dinámicas de trabajo.

Al igual que otras revoluciones tecnológicas del pasado, traerá disrupción pero también nuevas oportunidades. Los datos de Microsoft dejan algo bien claro: aquellos trabajos centrados en manipular información, comunicarse o generar contenido serán los primeros en sentir la ola de la IA.

La inteligencia artificial ha llegado para quedarse, y comprender cómo encaja en nuestro entorno laboral es el primer paso para sacarle el mejor provecho en vez de temerle.

Referencias

• Tomlinson, K. et al. (2025). Measuring the Occupational Impact of Generative AI: A Data-Driven Approach. Microsoft Research.
  Disponible en: https://arxiv.org/abs/2507.07935
  PDF directo: https://arxiv.org/pdf/2507.07935

Diana Castro
Ingeniera en Sistemas

---

¿Cuántas veces hemos escuchado frases como “si algo puede fallar, fallará, y en el peor momento” o hemos hecho referencia a la Ley de Murphy? Probablemente miles de veces, especialmente en nuestra área. Aunque solemos bromear al respecto, ¿cuántos de nosotros realmente tomamos estas frases en serio y planificamos con la posibilidad de que ocurra lo peor?

Planificar para lo inesperado es esencial para garantizar que nuestro negocio podrá mantenerse a flote, permitiendo que nuestras cargas de trabajo soporten el embate de eventos desafortunados.

Estos eventos pueden variar desde situaciones de pequeña o mediana escala hasta incidentes de proporciones épicas. Para amenazas comunes y de magnitud controlable, los esquemas de alta disponibilidad (HA) ofrecen una protección adecuada. Sin embargo, los eventos de gran magnitud requieren un enfoque más robusto: la implementación de estrategias de Recuperación ante Desastres, que es precisamente el tema en el que nos queremos enfocar.

Algunos conceptos básicos detrás del DR

¿Qué es un desastre?

Un desastre puede definirse como cualquier evento desafortunado que impide que la carga de trabajo logre su cometido. Aunque estos eventos son poco comunes, suelen ser graves: desastres naturales, fallas técnicas catastróficas o errores humanos, ya sean intencionados o no.

¿Cuál es el costo de un desastre?

La respuesta es variable y como diría un colega y amigo depende, y de qué depende, de la criticidad que tenga la carga de trabajo (definamos carga de trabajo como cualquier conjunto de servicios, sistemas etc. que generan valor) para nuestro negocio, una salida de operación de un sistema critico puede ser caro en dinero, en costo de oportunidad, en imagen ninguna excluyente. Imaginemos una tienda en línea que se ve afectada por un desastre en Black Friday o en Cyber Monday, un total desastre.

Para definir que tan critica es nuestra carga de trabajo el negocio, nos debe definir dos parámetros importantes los cuales corresponden por sus siglas en inglés a RPO y RTO

• Recovery Point Objective (RPO): La pérdida máxima de datos que el negocio puede tolerar.
• Recovery Time Objective (RTO): El tiempo máximo que un sistema puede estar fuera de servicio.

Fuente: Arquitectura de Recuperación ante Desastres en AWS, Parte 1

Esta imagen ilustra muy bien los conceptos anteriores, en términos simples significan cuantos datos puedo perder desde el último respaldo al momento del incidente y cuanto tiempo después del incidente se dispone como máximo para restablecer la operación.

Dependiendo de la criticidad de la carga las respuestas variarán, en algunos casos recibiremos de un mismo cliente un variopinto de duplas RTO y RPO para sus distintas cargas de trabajo, por ejemplo, en una entidad financiera, el sistema a cargo del control de vacaciones tendrá valores más laxos en sus RPO y RTO que los del Core Bancario. Por supuesto entre mas exigentes los valores establecidos más compleja y por lo tanto más onerosa la solución.

En resumen, estos conceptos responden a: ¿cuántos datos puedo perder y cuánto tiempo puedo estar sin servicio?

Estrategias de Recuperación ante Desastres

Tal y como mencionamos anteriormente, entre más complejo el escenario mayor el costo, existen diversas estrategias que aplican dependiendo de los criterios del negocio, en la siguiente figura se visualizan las principales estrategias.

Me concentraré en este artículo en solamente dos de ellas

Backup and Restore

Es una estrategia esencial en cualquier plan de recuperación, especialmente cuando los tiempos de RPO y RTO permitidos son altos, lo que la convierte en una solución económica pero no rápida. Es crucial no descartar esta estrategia bajo ninguna circunstancia, ya que resulta indispensable en casos como la necesidad de retroceder en el tiempo para corregir errores o recuperar datos tras ataques como ransomware, entre otros. Este enfoque actúa como la base mínima para garantizar la recuperación de información crítica

Luz Piloto (Pilot Light)

Diseñada para tiempos de recuperación más exigentes, generalmente entre 10 y 12 minutos, con una pérdida mínima de datos. Este esquema mantiene un subconjunto de elementos replicados y componentes básicos activos, mientras los principales permanecen inactivos hasta que son necesarios. Esto permite acelerar significativamente la recuperación manteniendo los costos controlados, ya que no implica operar dos ambientes activos simultáneamente.

Implementando una estrategia Luz Piloto con AWS Elastic Disaster Recovery

Al definir una estrategia de recuperación, es fundamental considerar varios aspectos clave: primero, garantizar que satisfaga los criterios de criticidad del negocio; segundo, que se implemente de manera costo-efectiva; tercero, asegurar que el mecanismo de recuperación sea práctico y factible de ejercitar, ya que una estrategia que no se prueba regularmente es equivalente a no tener ninguna; y, por último, que el proceso de failback sea simple y eficiente.

¿Por qué AWS Elastic Disaster Recovery?

En el contexto descrito, AWS ofrece Elastic Disaster Recovery como una solución ideal para implementar una estrategia de Luz Piloto. Además de ser una opción costo-efectiva, esta herramienta destaca por las siguientes bondades:

• Facilita la creación de un entorno de recuperación independientemente de la ubicación original de las cargas de trabajo, ya sea que estas se encuentren on-premise, en otra nube o en una región de AWS
• Permite cumplir con tiempos de recuperación (RTO) en cuestión de minutos.
• Ofrece la capacidad de lograr objetivos de punto de recuperación (RPO) extremadamente bajos.
• Simplifica la ejecución de ejercicios de recuperación, haciéndolos accesibles y prácticos.

Consideraciones importantes

No es mi intención en este artículo replicar el manual de instalación de EDR pero tras nuestra experiencia me gustaría destacar puntos importantes del proceso.

Staging Area Subnet:
Componente crítico se encuentra definida dentro de la VPC de destino en AWS, actúa como un área de preparación temporal para los servidores de replicación, facilitando una transición segura y controlada durante el proceso de recuperación. Factores clave a considerar:

• Comunicación de Servidores: Habilitación del puerto 1500 entre servidores de origen y la subnet de staging, para permitir la trasferencia de datos durante la replicación
• Conectividad con Endpoint de EDR: se debe habilitar la comunicación directa mediante puerto 443 (HTTPS)

Agentes de Replicación:
Es requerido la instalación de agentes de replicación en los servidores origen, la cual es permitida tanto para servidores con sistemas operativos Windows o Linux, se debe realizar una validación previa de las versiones soportadas

Desafíos de Seguridad:
En el caso de que se utilicen herramientas de seguridad empresarial como por ejemplo con Kaspersky Endpoint Security Cloud se requiere que previo a la instalación se habilite de manera explicas las rutas en las que se estará instalando el agente, esto previene bloqueos durante la implementación del agente

Gestión del Ancho de Banda:
En condiciones normales, EDR es capaz de gestionar el ancho de banda, pero ante limitaciones económicas y alta cantidad de transferencia se puede optar por un enfoque secuencial, con algo de paciencia en ante limitaciones de este tipo es perfectamente posible abordar la sincronización inicial.

Simulacros de Recuperación

Los ejercicios de replicación pueden ser dolorosos complejos y suelen convertirse en un dolor de cabeza en escenarios tradicionales. Con EDR es muy sencillo realizar un ensayo. Entre sus fortalezas puedo citar :

• Flexibilidad para realizar pruebas en uno o todos los servidores
• No se interrumpe la operación principal
• El costo de infraestructura es viable pues luego del ejercicio el ambiente se destruye con facilidad
• El tiempo de despliegue es en promedio de 12 minutos

La ejecución de simularos es estratégica pues permite a los responsables practicar que deben hacer ante un desastre y aplicamos la filosofía de la práctica hace al maestro

Conclusión

La implementación de un sitio de recuperación de desastres requiere algo más que una instalación. Es fundamental desarrollar un plan detallado, documentado y probado regularmente.

Simulacros regulares validan la estrategia técnica y preparan al equipo, minimizando el impacto operativo, económico y sobre la reputación de la organización.

AWS Elastic Disaster Recovery es una excelente opción para la implementación de nuestra estrategia con un costo efectivo y con la agilidad requerida para que nuestros equipos adquieran la pericia que requerirán ante un desastre real.