AWS Transform for migrations now supports all AWS commercial regions as migration targets. A migration target region is the AWS region where migrated resources are deployed, including landing zones, network infrastructure, and server rehosting. Customers can now deploy workloads in any commercial region, making it easier to meet data residency requirements.
The new migration target regions are: US East (N. California), Africa (Cape Town), Asia Pacific (Bangkok), Asia Pacific (Hong Kong), Asia Pacific (Hyderabad), Asia Pacific (Jakarta), Asia Pacific (Kuala Lumpur), Asia Pacific (Melbourne), Asia Pacific (New Zealand), Asia Pacific (Taipei), Canada (Calgary), Europe (Milan), Europe (Spain), Europe (Zurich), Mexico (Querétaro) and Middle East (Tel Aviv).
Target region selection is available in the AWS Transform for migrations workflow. For the most up-to-date availability information, see the supported migration target region list.
AWS Transform for migrations now supports all AWS commercial regions as migration targets. A migration target region is the AWS region where migrated resources are deployed, including landing zones, network infrastructure, and server rehosting. Customers can now deploy workloads in any commercial region, making it easier to meet data residency requirements. The new migration target regions are: US East (N. California), Africa (Cape Town), Asia Pacific (Bangkok), Asia Pacific (Hong Kong), Asia Pacific (Hyderabad), Asia Pacific (Jakarta), Asia Pacific (Kuala Lumpur), Asia Pacific (Melbourne), Asia Pacific (New Zealand), Asia Pacific (Taipei), Canada (Calgary), Europe (Milan), Europe (Spain), Europe (Zurich), Mexico (Querétaro) and Middle East (Tel Aviv). Target region selection is available in the AWS Transform for migrations workflow. For the most up-to-date availability information, see the supported migration target region list.
AWS HealthOmics now supports Nextflow profiles, enabling customers to activate predefined execution settings at run time. Nextflow profiles allow customers to define reusable settings and select them at the point of execution, making it easy to switch between execution settings without modifying workflow source code. AWS HealthOmics is a HIPAA-eligible service that helps healthcare and life sciences customers accelerate scientific breakthroughs at scale with fully managed bioinformatics workflows.
With Nextflow profiles, you can cleanly separate platform-specific settings such as resource limits or execution options from core workflow logic. You can switch between development and production settings without creating separate workflow definitions. This reduces errors from manual edits, accelerates workflow portability, and saves time when scaling from development to production. If you use nf-core workflows, you can now activate the built-in and institutional profiles those pipelines already ship with.
You can now specify one or more Nextflow profiles in your workflow runs in all AWS HealthOmics Regions: US East (N. Virginia), US West (Oregon), Europe (Frankfurt, Ireland, London), Israel (Tel Aviv), and Asia Pacific (Singapore, Seoul). To learn more, visit the Nextflow Profiles section on HealthOmics Nextflow engine settings documentation.
AWS HealthOmics now supports Nextflow profiles, enabling customers to activate predefined execution settings at run time. Nextflow profiles allow customers to define reusable settings and select them at the point of execution, making it easy to switch between execution settings without modifying workflow source code. AWS HealthOmics is a HIPAA-eligible service that helps healthcare and life sciences customers accelerate scientific breakthroughs at scale with fully managed bioinformatics workflows.
With Nextflow profiles, you can cleanly separate platform-specific settings such as resource limits or execution options from core workflow logic. You can switch between development and production settings without creating separate workflow definitions. This reduces errors from manual edits, accelerates workflow portability, and saves time when scaling from development to production. If you use nf-core workflows, you can now activate the built-in and institutional profiles those pipelines already ship with.
You can now specify one or more Nextflow profiles in your workflow runs in all AWS HealthOmics Regions: US East (N. Virginia), US West (Oregon), Europe (Frankfurt, Ireland, London), Israel (Tel Aviv), and Asia Pacific (Singapore, Seoul). To learn more, visit the Nextflow Profiles section on HealthOmics Nextflow engine settings documentation.
AWS introduces Lambda MicroVMs, a new serverless compute primitive that provides VM-level isolation, near-instant launch and resume speeds, and state preservation for executing user or AI-generated code. You can now give each user or job their own compute environment to securely run code without managing virtualization infrastructure or choosing between isolation, speed, and state retention.
Developers are increasingly building multi-tenant applications that execute code supplied by end users or AI for use cases such as interactive coding environments, data analytics platforms, coding assistants, and vulnerability scanning platforms. For these applications, developers need to allocate a separate, isolated execution environment per user or session to limit the impact of incorrect or malicious code on other concurrently running users or jobs. Previously, developers needed to choose between strong isolation, fast launch times, and state retention when building these applications. Starting today, Lambda MicroVMs provides you these capabilities without any trade-offs. You get VM-level isolation, near-instant launch speeds, and the ability to suspend and resume execution for up to 8 hours. Lambda MicroVMs is built on Firecracker virtualization, the technology powering more than 15 trillion monthly Lambda Function invocations.
To get started, create a MicroVM image from your Dockerfile, then launch MicroVMs from that image. Give each user or job their own MicroVM with a dedicated HTTPS URL that supports popular connectivity protocols such as HTTP/2, gRPC, and WebSockets.
Lambda MicroVMs is available today in the following AWS Regions: US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Tokyo), and Europe (Ireland). To learn more, visit the AWS Lambda MicroVMs developer guide and the launch blog post. Get started with MicroVMs through the AWS Lambda console, AWS CloudFormation, AWS Cloud Development Kit, or use the Agent Toolkit for AWS with your preferred Agentic development tools. You pay for baseline compute resources while your MicroVM is running, and only for the active duration of additional resources consumed when your workload exceeds the baseline. To learn more about pricing, see Lambda MicroVMs pricing.
AWS introduces Lambda MicroVMs, a new serverless compute primitive that provides VM-level isolation, near-instant launch and resume speeds, and state preservation for executing user or AI-generated code. You can now give each user or job their own compute environment to securely run code without managing virtualization infrastructure or choosing between isolation, speed, and state retention.
Developers are increasingly building multi-tenant applications that execute code supplied by end users or AI for use cases such as interactive coding environments, data analytics platforms, coding assistants, and vulnerability scanning platforms. For these applications, developers need to allocate a separate, isolated execution environment per user or session to limit the impact of incorrect or malicious code on other concurrently running users or jobs. Previously, developers needed to choose between strong isolation, fast launch times, and state retention when building these applications. Starting today, Lambda MicroVMs provides you these capabilities without any trade-offs. You get VM-level isolation, near-instant launch speeds, and the ability to suspend and resume execution for up to 8 hours. Lambda MicroVMs is built on Firecracker virtualization, the technology powering more than 15 trillion monthly Lambda Function invocations.
To get started, create a MicroVM image from your Dockerfile, then launch MicroVMs from that image. Give each user or job their own MicroVM with a dedicated HTTPS URL that supports popular connectivity protocols such as HTTP/2, gRPC, and WebSockets.
Lambda MicroVMs is available today in the following AWS Regions: US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Tokyo), and Europe (Ireland). To learn more, visit the AWS Lambda MicroVMs developer guide and the launch blog post. Get started with MicroVMs through the AWS Lambda console, AWS CloudFormation, AWS Cloud Development Kit, or use the Agent Toolkit for AWS with your preferred Agentic development tools. You pay for baseline compute resources while your MicroVM is running, and only for the active duration of additional resources consumed when your workload exceeds the baseline. To learn more about pricing, see Lambda MicroVMs pricing.
AWS Outposts now provides self-service capabilities for configuration, quoting, ordering, subscription management, renewal, and decommissioning directly from the AWS Management Console, CLI, and API. Previously, customers relied on AWS teams for managing their Outposts lifecycle, from evaluation through end of term.
A new configuration and quoting tool generates real-time cost estimates across payment options and term lengths, and proactively surfaces account and regional constraints before order submission. Quotes are generated in seconds and can be converted to orders directly in the console, for both new deployments and capacity additions. Subscription details, including term dates and billing, are now available in the console and programmatically, eliminating the need to contact AWS for contract information. When your term approaches its end date, self-service workflows let you renew with a new term and payment option, or decommission your Outpost through a guided workflow that handles resource cleanup.
These features are available in all commercial AWS Regions that support AWS Outposts. To learn more, refer to the Launch Blog.
AWS Outposts now provides self-service capabilities for configuration, quoting, ordering, subscription management, renewal, and decommissioning directly from the AWS Management Console, CLI, and API. Previously, customers relied on AWS teams for managing their Outposts lifecycle, from evaluation through end of term. A new configuration and quoting tool generates real-time cost estimates across payment options and term lengths, and proactively surfaces account and regional constraints before order submission. Quotes are generated in seconds and can be converted to orders directly in the console, for both new deployments and capacity additions. Subscription details, including term dates and billing, are now available in the console and programmatically, eliminating the need to contact AWS for contract information. When your term approaches its end date, self-service workflows let you renew with a new term and payment option, or decommission your Outpost through a guided workflow that handles resource cleanup. These features are available in all commercial AWS Regions that support AWS Outposts. To learn more, refer to the Launch Blog.
AWS IAM Identity Center now supports separate quotas for the number of AWS accounts and applications that can be configured in an IAM Identity Center instance. By default, you can configure up to 7,000 AWS accounts and up to 7,000 applications independently, so that using more of one does not consume capacity from the other. Quotas can be further increased by submitting a quota increase request through AWS Service Quotas console.
Customers with existing higher limits are automatically granted the same limit for both accounts and applications, with no action required. Organizations managing thousands of AWS accounts can now onboard applications without consuming account quota capacity.
This update is available in all AWS Regions where IAM Identity Center is available.
AWS IAM Identity Center now supports separate quotas for the number of AWS accounts and applications that can be configured in an IAM Identity Center instance. By default, you can configure up to 7,000 AWS accounts and up to 7,000 applications independently, so that using more of one does not consume capacity from the other. Quotas can be further increased by submitting a quota increase request through AWS Service Quotas console.
Customers with existing higher limits are automatically granted the same limit for both accounts and applications, with no action required. Organizations managing thousands of AWS accounts can now onboard applications without consuming account quota capacity.
This update is available in all AWS Regions where IAM Identity Center is available.
To learn more, see Quotas for IAM Identity Center. Visit the IAM Identity Center product page to get started.
AWS Network Firewall now uses «Application drop established (server-directed only)» as the default stateful action for all newly created firewall policies, replacing the previous default of «Application drop established (bidirectional)» (formerly named «Application layer drop established»). No action is required to benefit from this change when creating new policies.
AWS Network Firewall is a managed service that lets you deploy network protections across your Amazon VPCs. Previously, the “Application drop established (bidirectional)” default could silently drop legitimate server-to-client TCP packets, such as window updates, keep-alives, and resets — causing intermittent connection failures that were difficult to diagnose. With the safer default now in place, new policies avoid this issue.
If your existing environment requires “Application drop established (bidirectional)” to support post-quantum cryptography (PQC) fragmented TLS handshakes, refer to our documentation for guidance on on switching to «Application drop established (server-directed only)» or adding the “to_server” flag to your TCP drop rules so legitimate flow control packets are not blocked.
AWS Network Firewall now uses «Application drop established (server-directed only)» as the default stateful action for all newly created firewall policies, replacing the previous default of «Application drop established (bidirectional)» (formerly named «Application layer drop established»). No action is required to benefit from this change when creating new policies. AWS Network Firewall is a managed service that lets you deploy network protections across your Amazon VPCs. Previously, the “Application drop established (bidirectional)” default could silently drop legitimate server-to-client TCP packets, such as window updates, keep-alives, and resets — causing intermittent connection failures that were difficult to diagnose. With the safer default now in place, new policies avoid this issue. If your existing environment requires “Application drop established (bidirectional)” to support post-quantum cryptography (PQC) fragmented TLS handshakes, refer to our documentation for guidance on on switching to «Application drop established (server-directed only)» or adding the “to_server” flag to your TCP drop rules so legitimate flow control packets are not blocked. This update is available in all AWS Regions where AWS Network Firewall is offered. To get started, see Managing evaluation order for Suricata compatible rules in the AWS Network Firewall service documentation.
AWS Batch now offers the Best Fit Progressive Ordered (BFPO) and Spot Capacity Optimized Prioritized (SCOP) allocation strategies, giving you more control over instance type prioritization in your compute environments. BFPO and SCOP enable you to manually define instance type ordering based on your workload-specific performance characteristics.
To use these features in AWS Batch, specify BEST_FIT_PROGRESSIVE_ORDERED allocation strategy for your on-demand compute environments or SPOT_CAPACITY_OPTIMIZED_PRIORITIZED for your Amazon EC2 Spot compute environments and provide an ordered list of instance types or families. These features are available via the AWS Batch API (CreateComputeEnvironment or UpdateComputeEnvironment) or the AWS Batch Management Console.
BFPO and SCOP allocation strategies are supported today in all AWS Regions where AWS Batch is available. For more information, see the AWS Batch User Guide.
AWS Batch now offers the Best Fit Progressive Ordered (BFPO) and Spot Capacity Optimized Prioritized (SCOP) allocation strategies, giving you more control over instance type prioritization in your compute environments. BFPO and SCOP enable you to manually define instance type ordering based on your workload-specific performance characteristics. To use these features in AWS Batch, specify BEST_FIT_PROGRESSIVE_ORDERED allocation strategy for your on-demand compute environments or SPOT_CAPACITY_OPTIMIZED_PRIORITIZED for your Amazon EC2 Spot compute environments and provide an ordered list of instance types or families. These features are available via the AWS Batch API (CreateComputeEnvironment or UpdateComputeEnvironment) or the AWS Batch Management Console. BFPO and SCOP allocation strategies are supported today in all AWS Regions where AWS Batch is available. For more information, see the AWS Batch User Guide.
5 bases para transformar el futuro de la educación y la IA
Por: Mark Sparvell, director de Microsoft Education.
Pregunten a un responsable de contratación qué busca hoy y escucharán algo que hace dos años habría sonado inusual: no una lista más larga de herramientas, sino un conjunto más profundo de capacidades humanas. Una nueva investigación de Microsoft, Preparing Students for the Future of Work, revela que alrededor del 70% de las habilidades utilizadas en la mayoría de los empleos se espera que cambien para 2030, la alfabetización en IA aparece ahora en las ofertas de empleo unas seis veces más a menudo que hace un año, y el 66% de los líderes afirma que no contrataría a alguien sin habilidades en IA.
Para los educadores, es una oportunidad para moldear el futuro.
El éxito en la educación siempre ha dependido de la interacción entre conocimientos, aptitudes y habilidades. La formación de habilidades es la capacidad que convierte la nueva tecnología en una práctica segura y de confianza. La cuestión no es si preparar a los estudiantes para un mundo con forma de IA. Es cómo hacerlo de una manera que mantenga el florecimiento humano, no solo la empleabilidad, en el centro.
Esta frase, extraída de la conclusión del informe, merece la pena mantenerla. Las tecnologías van a continuar con los cambios. Lo que perdura es, con claridad, humano: curiosidad, juicio, capacidad de aprender y reaprender, y la sabiduría para aplicar bien el conocimiento. La OCDE presenta el mismo argumento en su marco de 2025, Educación para el Florecimiento Humano, que sostiene que la educación debe ayudar a cada alumno a vivir «una vida que tenga motivos para valorar», para ir más allá de una visión limitada basada en el capital humano sobre la educación.1
En conjunto, los informes señalan un patrón constante: el mercado laboral actual recompensa cada vez más a las personas que pueden aplicar su inteligencia, adaptarse al contexto y no dejar de aprender. Por tanto, el propósito duradero de la educación es desarrollar y perfeccionar esas habilidades y disposiciones.
La curiosidad, el juicio y la capacidad de aprender se desarrollan a través de una colaboración significativa, no solo de la tecnología.
Cinco nuevos fundamentos que remodelan lo que significa estar preparado
El informe de la OCDE identifica cinco cambios que redibujan de manera discreta la línea entre «nivel de entrada» y «experimentado». Para las escuelas y universidades, el informe señala que se construye la preparación para la IA no solo a través del acceso a la tecnología, sino también mediante capacidades humanas, gobernanza y experiencia práctica que ayudan a la IA a funcionar de forma responsable.
Expectativas elevadas para los niveles de entrada
Trabajar con IA como socio para convertirse en un «jefe agente»
Ingeniería del contexto
Juicio, voz y el estándar humano
Desde credenciales hasta capacidades
Habilidades de arraigo en el florecimiento humano
Si esos cinco fundamentos describen lo que ahora recompensa el lugar de trabajo, el marco de la OCDE describe la base humana que hay bajo ellos. Se centra en actuar en el mundo con la capacidad de moldear la propia vida y contribuir a los demás. Esto se apoya en cuatro competencias:
Resolución adaptativa de problemas
Competencia ética
Entender el mundo
Apreciar el mundo
La superposición es llamativa. La «ingeniería de contexto» y la mentalidad de «jefe agente» son soluciones adaptativas de problemas en un medio nuevo. «El juicio y el estándar humano» es competencia ética hecha práctica. Desarrollar habilidades para el futuro del trabajo y educar para una vida próspera no son objetivos en competencia; si se hace bien, son el mismo trabajo.
La autonomía, la resolución de problemas y el juicio ético crecen cuando los alumnos tienen el espacio y el apoyo para aplicarlos.
Cómo se ve esto en las aulas hoy en día
Esto no es teórico. Las escuelas y universidades ya han convertido estas ideas en la práctica cotidiana, y los primeros resultados son alentadores.
En las Escuelas del Condado de Fulton, los estudiantes utilizan la IA como un socio de reflexión para explorar ideas, generar confianza y abordar problemas del mundo real, para cambiar el aprendizaje del uso de la tecnología a la creación con ella en un distrito que atiende a casi 87.000 estudiantes.
En la Universidad de Sídney, la plataforma «Cogniti» permite a los educadores diseñar herramientas de IA que guían a los estudiantes a través del razonamiento—un ejemplo práctico de enseñar a los estudiantes a dirigir la IA, no solo a usarla.
La Universidad de California en San Diego rediseñó un curso introductorio de informática centrado en GitHub Copilot, para ayudar a los estudiantes a completar tareas de programación más rápido, construir proyectos más ambiciosos y desarrollar habilidades prácticas de IA para el entorno laboral.
En la educación K-12 y superior, el patrón es el mismo: la IA está integrada en el aprendizaje y la enseñanza cotidianos, para construir la alfabetización y adaptabilidad que los empleadores describen como «capacitada para toda la vida».
Empoderar a los educadores para que fomenten estas habilidades es uno de los objetivos del programa Microsoft Elevate for Educators. Está diseñado para proporcionar a educadores y líderes escolares acceso a una comunidad global, credenciales y oportunidades de formación para integrar con confianza la IA en la enseñanza y el aprendizaje.
Saber qué habilidades importan es el primer paso. Construirlas, a gran escala, es lo siguiente. Estén atentos a nuestras próximas entradas de blog que detallan los productos y programas que ayudan a los educadores a poner en práctica esta intención de capacitación, desde herramientas de IA listas para el aula hasta aprendizaje profesional que llega a los educadores donde se encuentran.
IA en el trabajo: Rediseñar primero. Luego la IA tan solo comienza a trabajar
Las organizaciones no se transforman mediante mejores modelos: lo hacen al volver a elaborar la manera en que se ejecutan las tareas, de modo que la tecnología se vuelve invisible dentro de ellas.
Por: Jared Spataro, CMO de IA en el Trabajo de Microsoft.
El comentario más compartido sobre la IA ahora mismo parte de una observación difícil de discutir: la brecha entre lo que pueden hacer los modelos actuales y lo que las empresas despliegan es enorme, y eso genera frustración. Ethan Mollick captó esa sensación de más más contundente en un artículo reciente para The Economist, donde argumenta que las empresas domestican la IA antes de que tenga la oportunidad de hacer su mejor trabajo—que la gobernanza de TI, los procesos aversos al riesgo y el impulso de adaptar la tecnología a las estructuras existentes son el principal cuello de botella. Erik Brynjolfsson en Stanford lleva 30 años en documentar por qué ocurre esto. Su marco de curvas en J—el patrón de caída antes del pago que suele seguir la adopción tecnológica—es la arquitectura intelectual detrás de la afirmación de que el retraso organizativo, y no la calidad del modelo, determina si una tecnología se acumula o se estanca.
Ambos tienen razón. El diagnóstico es grave y fundamentado. Lo que añadiría es una interpretación diferente de qué crea la brecha en primer lugar.
Aquí está la parte que yo insistiría. La fricción que Mollick argumenta que las empresas deberían desmantelar—el control burocrático, el impulso de sobreindexar pilotos y experimentación—no es la misma que la infraestructura que permite escalar a la IA. Identidad. Permisos. Una conexión con los datos sobre los que en verdad funciona su negocio. Un registro de lo que hicieron los agentes de IA y por qué. Integración con las herramientas donde ya hay trabajo. Esa capa no es donde la IA va a morir. Es lo que permite que la IA desaparezca dentro del trabajo, lo cual es una condición necesaria para la escala.
Cómo se difunde la tecnología
Geoffrey Moore documentó el patrón en Cruzando el Abismo: los comportamientos que definen a los primeros adoptantes —la disposición a realizar actos antinaturales para una tecnología que aún no es fluida— son justo lo que los hace poco representativos de los demás. Los pragmáticos no cruzan el abismo porque la tecnología se vuelve más capaz. La cruzan cuando la tecnología les encuentra dentro del trabajo que ya realizan.
La web no transformó el comercio mediante experimentos exóticos de navegadores. Transformó el comercio cuando se convirtió en la capa invisible bajo lo que Amazon construyó—cuando pedir pasta de dientes no requería entender en absoluto la tecnología subyacente. Esa invisibilidad se ganó. Amazon reconstruyó la infraestructura logística, de cumplimiento y precios desde cero antes de que la tecnología pudiera desaparecer en la compra. La invisibilidad fue el resultado del rediseño, no una alternativa. El móvil siguió el mismo arco. No ganaba cuando era nuevo y experimental, sino cuando la interfaz desaparecía en la tarea misma.
En cada caso, la tecnología se volvió relevante cuando la mayoría dejó de pensar en ella. El trabajo estructural deliberado ocurrió antes de que la experiencia se volviera sencilla. El principal indicador de madurez tecnológica empresarial nunca ha sido la novedad de la interfaz. Es lo indetectable que es la tecnología bajo el trabajo cotidiano. La IA no está exenta de este patrón.
La misma forma, siempre
La web, el móvil y ahora la IA siguen la curva: ruidosos y visibles al principio, soportantes e invisibles al final. El valor aumenta a medida que la interfaz desaparece.
La capa que soporta el peso
La visión desde arriba y la experimentación en toda la empresa importan. Pero ninguna de las dos da resultado sin lo que hay debajo: la capa que sabe quién pregunta, qué pueden ver, los datos sobre los que funciona el negocio y las herramientas donde ya se realiza el trabajo.
El problema que resuelve esa capa es el reaprendizaje. La IA actual aborda cada tarea como si fuera una nueva incorporación desde el primer día. En cada prompt o especificación, tienen que explicar dónde están los datos, cómo formatear la salida y qué estándares se aplican. Lo que las organizaciones aprenden ahora a construir son habilidades: conjuntos estructurados de instrucciones que codifican cómo se ejecuta un trabajo específico. Una habilidad es diferente de un prompt de la misma manera que un manual de proceso es diferente de un correo electrónico. Un prompt le pide a la IA que lo descubra. Una habilidad le dice a la IA cómo ha decidido hacer esta organización. Desarrollar esas habilidades a gran escala—decidir qué deben codificar, mantenerlas a medida que evolucionan los flujos de trabajo, distribuirlas para que los equipos no empiecen cada uno desde cero—es el trabajo de formalización que separa un modelo operativo de un piloto bien financiado.
La mayoría de las organizaciones están más cerca de esto de lo que se imaginan. La capacidad subyacente se ha acumulado en el software empresarial durante años: en funciones que no se utilizaron, flujos de trabajo demasiado complejos para adoptar, datos sin estructura en sistemas diseñados para la navegación humana. La IA generativa hace que esas capacidades sean accesibles a gran escala, pero solo cuando la infraestructura esté disponible para habilitarlas.
El problema del modelo operativo en el que los líderes están atascados
Los líderes entienden en gran medida que la integración de la IA requiere trabajo de rediseño. El problema más difícil es saber cómo. Los procesos que necesitan cambiar son los mismos de los que depende la organización hoy en día, y nadie tiene una pausa en dirigir el negocio para reconstruirlo.
Hay un momento en la IA escalable en el que se puede sentir el techo. El velocímetro dice que el coche puede ir más rápido, pero el motor ya está al máximo. Lo que desbloquea la siguiente marcha no es una mejora incremental. Es un paso atrás respecto a cómo está estructurado en la actualidad el trabajo y preguntarse si la estructura debería existir en absoluto.
Eso requiere una intervención deliberada. En Microsoft, los equipos de desarrollo de producto realizaron Camp AIR, un programa inmersivo de tres semanas que ofrecía a los participantes tiempo protegido, coaches internos y un conjunto compartido de herramientas de IA. Como dijo un líder, durante esas tres semanas su prioridad no fue entregar la funcionalidad en la que trabajaban, sino descubrir cómo trabajar de manera diferente con IA. El tiempo se había delimitado. Los flujos de trabajo se mapeaban de principio a fin. Había que construir nuevas prácticas antes de que las antiguas pudieran reafirmarse.
Los líderes que no creen esa estructura acabarán enfrentándose a una versión de ella impuesta por la presión competitiva, con menos tiempo y menos opciones. No hay un mapa terminado, y el ritmo de desarrollo de la IA ha hecho que cualquier plano sea provisional. Lo que está disponible en cambio es un dominio que se desarrolla de manera visible por delante: el desarrollo de software, donde los nuevos patrones de trabajo ya están documentados. No es una plantilla. Es un relé. Alguien delante por la misma carretera, envía señales sobre cómo es el terreno. Lo que muestran esas señales no es que la IA abrume a la gente. Son personas que rediseñan la obra para que la tecnología se convierta en la parte que nadie nota.
Lo que todo esto significa para los líderes
La curva en J se resuelve—siempre lo ha hecho. Mollick y Brynjolfsson tienen razón en eso. Lo que determina si una organización lidera o sigue es si construye el cableado mientras los demás siguen con discusiones sobre el interruptor.
La cuestión práctica no es cuánta capacidad de IA está disponible dentro de su organización. Depende de si la infraestructura bajo sus inversiones en IA es de carga o tan solo sirve de cobertura a más pilotos. El primer paso es más pequeño de lo que parece. Elige un flujo de trabajo recurrente que importe—un informe, un ciclo de revisión, un traspaso entre funciones—y hagan tres preguntas:
¿Dónde se queda el trabajo hoy?
¿Dónde intervienen los humanos solo para hacer avanzar las cosas?
¿Qué haría falta para que un agente manejara eso sin que le enseñen de nuevo cada vez?
Las respuestas son la base para crear la habilidad. Construir un pozo, distribuirlo y observar cómo funciona en condiciones reales es lo que se considera en la práctica al tratar la infraestructura como una decisión de modelo operativo. Una vez que lo han visto funcionar en un solo lugar, el patrón se vuelve visible en todas partes. Y entonces, si el trabajo se ha hecho bien, deja de ser visible por completo. La IA que nadie menciona en la reunión, el informe que llega sin que nadie lo saque, el resumen que estaba ahí—así es como funciona la IA.
Para más información sobre la IA y el futuro del trabajo, suscríbanse a este boletín.
Today, Amazon CloudWatch Synthetics announces support for multilocation canaries, allowing developers and site reliability engineers to run the same canary across multiple AWS Regions simultaneously from a single point of management. Previously, monitoring application availability from multiple geographic locations required creating and managing separate canaries in each Region, adding operational overhead and increasing the risk of configuration drift. With multilocation canaries, you create and manage a canary in one primary Region, and CloudWatch Synthetics automatically replicates it to the additional Regions you choose, consolidating all run data, metrics, and artifacts in the primary Region.
Multilocation canaries help you ensure consistent user experience worldwide, identify region-specific performance bottlenecks, and validate that third-party dependencies like CDNs and payment processors work across all locations. Replica canaries run independently, giving you resilient monitoring coverage across geographic locations. You can also configure alarms that activate only when issues are detected from multiple locations, increasing alert confidence and helping your team focus on real customer-impacting problems. Amazon CloudWatch Synthetics multilocation canaries are available in all AWS commercial Regions that support CloudWatch Synthetics. You can upgrade existing single-region canaries to multilocation by adding replica Regions without recreating them. For more information about regional availability, see the AWS Region table.
Today, Amazon CloudWatch Synthetics announces support for multilocation canaries, allowing developers and site reliability engineers to run the same canary across multiple AWS Regions simultaneously from a single point of management. Previously, monitoring application availability from multiple geographic locations required creating and managing separate canaries in each Region, adding operational overhead and increasing the risk of configuration drift. With multilocation canaries, you create and manage a canary in one primary Region, and CloudWatch Synthetics automatically replicates it to the additional Regions you choose, consolidating all run data, metrics, and artifacts in the primary Region.
Multilocation canaries help you ensure consistent user experience worldwide, identify region-specific performance bottlenecks, and validate that third-party dependencies like CDNs and payment processors work across all locations. Replica canaries run independently, giving you resilient monitoring coverage across geographic locations. You can also configure alarms that activate only when issues are detected from multiple locations, increasing alert confidence and helping your team focus on real customer-impacting problems. Amazon CloudWatch Synthetics multilocation canaries are available in all AWS commercial Regions that support CloudWatch Synthetics. You can upgrade existing single-region canaries to multilocation by adding replica Regions without recreating them. For more information about regional availability, see the AWS Region table.
To learn more about CloudWatch Synthetics, see Using synthetic monitoring in the Amazon CloudWatch User Guide. To get started, visit the Amazon CloudWatch product page.
