Starting today, Amazon Elastic Cloud Compute (Amazon EC2) P6-B300 instances are available in the Asia Pacific (Seoul) Region. P6-B300 instances provide 8xNVIDIA Blackwell Ultra GPUs with 2.1 TB high bandwidth GPU memory, 6.4 Tbps EFA networking, 300 Gbps dedicated ENA throughput, and 4 TB of system memory.

P6-B300 instances deliver 2x networking bandwidth, 1.5x GPU memory size, and 1.5x GPU TFLOPS (at FP4, without sparsity) compared to P6-B200 instances, making them well suited to train and deploy large trillion-parameter foundation models (FMs) and large language models (LLMs) with sophisticated techniques. The higher networking and larger memory deliver faster training times and more token throughput for AI workloads.

P6-B300 instances are now available in p6-b300.48xlarge size in the following AWS Regions: US West (Oregon), AWS GovCloud (US-East), US East (N. Virginia) and Asia Pacific (Seoul). To learn more about P6-B300 instances, visit Amazon EC2 P6 instances.

​Starting today, Amazon Elastic Cloud Compute (Amazon EC2) P6-B300 instances are available in the Asia Pacific (Seoul) Region. P6-B300 instances provide 8xNVIDIA Blackwell Ultra GPUs with 2.1 TB high bandwidth GPU memory, 6.4 Tbps EFA networking, 300 Gbps dedicated ENA throughput, and 4 TB of system memory. P6-B300 instances deliver 2x networking bandwidth, 1.5x GPU memory size, and 1.5x GPU TFLOPS (at FP4, without sparsity) compared to P6-B200 instances, making them well suited to train and deploy large trillion-parameter foundation models (FMs) and large language models (LLMs) with sophisticated techniques. The higher networking and larger memory deliver faster training times and more token throughput for AI workloads. P6-B300 instances are now available in p6-b300.48xlarge size in the following AWS Regions: US West (Oregon), AWS GovCloud (US-East), US East (N. Virginia) and Asia Pacific (Seoul). To learn more about P6-B300 instances, visit Amazon EC2 P6 instances.  

Today, Amazon Elastic Kubernetes Service (Amazon EKS) announced certificate authority (CA) rotation, enabling customers to rotate their cluster’s CA through a managed lifecycle with automated safeguards. Each Amazon EKS cluster has its own CA that allows encrypted connections to the cluster’s Kubernetes API, and now you can rotate the CA before it expires to ensure your cluster remains operational and secure.

Amazon EKS clusters created since launch in 2018 have CAs with a 10-year validity period, and clusters from that era are now approaching the point where CA rotation activities should begin. CA rotation in Amazon EKS is a shared responsibility. Amazon EKS manages the rotation lifecycle and automatically updates AWS-managed components to trust the successor CA. Customers are responsible for replacing their worker nodes and updating external clients to trust the successor CA before it is activated. EKS Auto Mode instances and AWS Fargate nodes are updated automatically by AWS, but customers are still responsible for updating any external clients that connect to the cluster’s API server. Amazon EKS provides automated safeguards to support customers through this process, including advance notifications before CA expiration, automatic appending of a successor CA if one is not created by the customer, and automatic activation if the customer does not activate on their own schedule. A rollback capability allows customers to revert to the previous CA to resolve any issues that may arise with their updates during the transition to the successor CA.

Amazon EKS CA rotation is available at no additional cost in all commercial AWS Regions. To get started with CA rotation, you can use the AWS CLI, EKS APIs, CloudFormation, and the AWS console. For more information, see the Amazon EKS documentation and Deep dive into Amazon EKS certificate authority rotation.

​Today, Amazon Elastic Kubernetes Service (Amazon EKS) announced certificate authority (CA) rotation, enabling customers to rotate their cluster’s CA through a managed lifecycle with automated safeguards. Each Amazon EKS cluster has its own CA that allows encrypted connections to the cluster’s Kubernetes API, and now you can rotate the CA before it expires to ensure your cluster remains operational and secure.
Amazon EKS clusters created since launch in 2018 have CAs with a 10-year validity period, and clusters from that era are now approaching the point where CA rotation activities should begin. CA rotation in Amazon EKS is a shared responsibility. Amazon EKS manages the rotation lifecycle and automatically updates AWS-managed components to trust the successor CA. Customers are responsible for replacing their worker nodes and updating external clients to trust the successor CA before it is activated. EKS Auto Mode instances and AWS Fargate nodes are updated automatically by AWS, but customers are still responsible for updating any external clients that connect to the cluster’s API server. Amazon EKS provides automated safeguards to support customers through this process, including advance notifications before CA expiration, automatic appending of a successor CA if one is not created by the customer, and automatic activation if the customer does not activate on their own schedule. A rollback capability allows customers to revert to the previous CA to resolve any issues that may arise with their updates during the transition to the successor CA.
Amazon EKS CA rotation is available at no additional cost in all commercial AWS Regions. To get started with CA rotation, you can use the AWS CLI, EKS APIs, CloudFormation, and the AWS console. For more information, see the Amazon EKS documentation and Deep dive into Amazon EKS certificate authority rotation.  

Starting today, customers can protect their origins using Amazon S3 Multi-Region Access Points (MRAP) by using CloudFront Origin Access Control (OAC) to only allow access from designated CloudFront distributions.

Customers use Amazon S3 MRAP with CloudFront to serve content from a single global endpoint that automatically routes to the closest available replicated bucket across regions during a cache miss, improving performance and resilience for globally distributed users. Previously, customers had to compute and forward their own Asymmetric Signature Version 4 (SigV4a) Authorization header using a custom Lambda@Edge Function. Now, CloudFront natively signs requests to S3 MRAP origins. Customers get faster cache-miss fills from the nearest region and restricted, OAC-secured MRAP access without  custom Authorization header computation.

CloudFront OAC support for Amazon S3 MRAP origins is available worldwide, except in the CloudFront China region. To get started, use the CloudFront Console, SDK, CLI, or CloudFormation to enable OAC when configuring your Amazon S3 MRAP endpoint with CloudFront. For more information, refer to the CloudFront Developer Guide. There are no additional fees associated with this feature

​Starting today, customers can protect their origins using Amazon S3 Multi-Region Access Points (MRAP) by using CloudFront Origin Access Control (OAC) to only allow access from designated CloudFront distributions.
Customers use Amazon S3 MRAP with CloudFront to serve content from a single global endpoint that automatically routes to the closest available replicated bucket across regions during a cache miss, improving performance and resilience for globally distributed users. Previously, customers had to compute and forward their own Asymmetric Signature Version 4 (SigV4a) Authorization header using a custom Lambda@Edge Function. Now, CloudFront natively signs requests to S3 MRAP origins. Customers get faster cache-miss fills from the nearest region and restricted, OAC-secured MRAP access without  custom Authorization header computation.
CloudFront OAC support for Amazon S3 MRAP origins is available worldwide, except in the CloudFront China region. To get started, use the CloudFront Console, SDK, CLI, or CloudFormation to enable OAC when configuring your Amazon S3 MRAP endpoint with CloudFront. For more information, refer to the CloudFront Developer Guide. There are no additional fees associated with this feature  

AWS partners can now access AWS Partner Central agents from tools they already use, such as Amazon Quick and Kiro, using OAuth through AWS Sign-In. Partners can authorize agent access with their existing AWS identities, sign-in methods, IAM permissions, and governance controls without installing or maintaining additional authentication software.

Previously, AWS Partners needed to set up an MCP proxy with SigV4 credentials to access Partner Central agents from their existing tools, or sign in to AWS Partner Central through the AWS Management Console with IAM credentials. OAuth simplifies this by allowing partners to use AWS Sign-In to authorize tools such as Amazon Quick and Kiro to access Partner Central agents. Partners can use OAuth from their existing tools for co-sell engagements, AWS funding applications, and AWS Marketplace seller setup. Administrators can govern access with IAM policies, global condition keys, token introspection and revocation APIs, dynamic client registration, and CloudTrail audit events.

OAuth support is available to AWS Partners through AWS Partner Central agents MCP Server, which is available in the US East (N. Virginia) Region. To learn more, visit  Getting started with the Partner Central agents MCP Server , and  Sign-In with OAuth 2.0 .

​AWS partners can now access AWS Partner Central agents from tools they already use, such as Amazon Quick and Kiro, using OAuth through AWS Sign-In. Partners can authorize agent access with their existing AWS identities, sign-in methods, IAM permissions, and governance controls without installing or maintaining additional authentication software.
Previously, AWS Partners needed to set up an MCP proxy with SigV4 credentials to access Partner Central agents from their existing tools, or sign in to AWS Partner Central through the AWS Management Console with IAM credentials. OAuth simplifies this by allowing partners to use AWS Sign-In to authorize tools such as Amazon Quick and Kiro to access Partner Central agents. Partners can use OAuth from their existing tools for co-sell engagements, AWS funding applications, and AWS Marketplace seller setup. Administrators can govern access with IAM policies, global condition keys, token introspection and revocation APIs, dynamic client registration, and CloudTrail audit events.
OAuth support is available to AWS Partners through AWS Partner Central agents MCP Server, which is available in the US East (N. Virginia) Region. To learn more, visit  Getting started with the Partner Central agents MCP Server , and  Sign-In with OAuth 2.0 .  

Amazon SageMaker AI now offers Generative AI Inference Recommendations in SageMaker AI Studio, giving customers a guided, low-code, no-code path to find the best inference configuration for their workload. This builds on the API-based launch in April 2026, extending the same benchmarking infrastructure to teams that prefer a visual workflow over programmatic access.

Deploying generative AI models in production requires finding the right combination of instance type, serving container, and optimization strategy. Getting this right typically involves weeks of manual benchmarking, configuration tuning, and trial-and-error, with no easy way to know if the final setup is actually optimal. With the new experience, customers describe their workload and what matters most, whether that’s latency, throughput, or cost, and SageMaker AI does the rest. It benchmarks multiple configurations on real GPU infrastructure using NVIDIA AIPerf, applies goal-aligned techniques like speculative decoding for throughput or kernel tuning for latency, and returns ranked, production-ready recommendations with measured performance data. Teams get to a validated configuration in hours instead of weeks, without needing to decide which techniques to apply or how to configure them.

With the new experience, customers describe their workload and what matters most, whether that’s latency, throughput, or cost, and SageMaker AI does the rest. It benchmarks multiple configurations on real GPU infrastructure using NVIDIA AIPerf, applies goal-aligned techniques like speculative decoding for throughput or kernel tuning for latency, and returns ranked, production-ready recommendations with measured performance data. Teams get to a validated configuration in hours instead of weeks, without needing to decide which techniques to apply or how to configure them.

In SageMaker AI Studio under Jobs, Inference optimization, customers select a use-case profile (Interact, Generate, Summarize, or Custom), choose an optimization goal (minimize latency, maximize throughput, or minimize cost), and pick their model from JumpStart, S3, Model Registry, or an existing SageMaker model. Recommendations are ranked by TTFT, inter-token latency, throughput, and cost, and can be compared visually before deploying to a SageMaker real-time endpoint directly from Studio.

There is no additional cost for generating recommendations. Standard compute costs apply for optimization jobs and endpoints provisioned during benchmarking. This capability is available in US East (N. Virginia), US West (Oregon), US East (Ohio), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Singapore), Asia Pacific (Tokyo). To learn more, visit the blog post or the documentation.

​Amazon SageMaker AI now offers Generative AI Inference Recommendations in SageMaker AI Studio, giving customers a guided, low-code, no-code path to find the best inference configuration for their workload. This builds on the API-based launch in April 2026, extending the same benchmarking infrastructure to teams that prefer a visual workflow over programmatic access.
Deploying generative AI models in production requires finding the right combination of instance type, serving container, and optimization strategy. Getting this right typically involves weeks of manual benchmarking, configuration tuning, and trial-and-error, with no easy way to know if the final setup is actually optimal. With the new experience, customers describe their workload and what matters most, whether that’s latency, throughput, or cost, and SageMaker AI does the rest. It benchmarks multiple configurations on real GPU infrastructure using NVIDIA AIPerf, applies goal-aligned techniques like speculative decoding for throughput or kernel tuning for latency, and returns ranked, production-ready recommendations with measured performance data. Teams get to a validated configuration in hours instead of weeks, without needing to decide which techniques to apply or how to configure them.
With the new experience, customers describe their workload and what matters most, whether that’s latency, throughput, or cost, and SageMaker AI does the rest. It benchmarks multiple configurations on real GPU infrastructure using NVIDIA AIPerf, applies goal-aligned techniques like speculative decoding for throughput or kernel tuning for latency, and returns ranked, production-ready recommendations with measured performance data. Teams get to a validated configuration in hours instead of weeks, without needing to decide which techniques to apply or how to configure them.
In SageMaker AI Studio under Jobs, Inference optimization, customers select a use-case profile (Interact, Generate, Summarize, or Custom), choose an optimization goal (minimize latency, maximize throughput, or minimize cost), and pick their model from JumpStart, S3, Model Registry, or an existing SageMaker model. Recommendations are ranked by TTFT, inter-token latency, throughput, and cost, and can be compared visually before deploying to a SageMaker real-time endpoint directly from Studio.
There is no additional cost for generating recommendations. Standard compute costs apply for optimization jobs and endpoints provisioned during benchmarking. This capability is available in US East (N. Virginia), US West (Oregon), US East (Ohio), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Singapore), Asia Pacific (Tokyo). To learn more, visit the blog post or the documentation.  

Today, AWS Direct Connect announced inbound prefix controls, a new capability that lets you allocate and manage inbound route-prefix allocations for your private and transit virtual interfaces (VIFs) based on your workload’s needs. You can now allocate up to 1,000 prefixes each for IPv4 and IPv6 on your VIFs on dedicated and hosted connections.

Previously, Direct Connect VIFs accepted a maximum of 100 route prefixes advertised from your on-premises network to AWS on a private or transit VIF. If you had a larger or growing network, you had to architect around this ceiling, for example, by summarizing routes or segmenting across multiple VIFs or connections. With inbound prefix controls, you can allocate up to 1,000 prefixes to a single VIF and advertise your routes directly.

Inbound prefix controls introduce new prefix capacity pools at the dedicated connection level and at the Direct Connect gateway (DXGW) level. When you create or update a VIF, you allocate a specific number of prefixes to it, and that allocation draws from the dedicated connection’s pool and the DXGW’s pool when you attach it. This lets you right-size prefix capacity per workload—for example, a large allocation for a transit VIF carrying many routes and a smaller allocation for a private VIF on the same connection. Connection pool sizes scale with connection speed, and link aggregation group (LAG) pools scale with the number of member connections.

You can configure prefix allocations using the AWS Direct Connect console or CLI/API. Inbound prefix controls are available at no additional cost in all commercial AWS Regions where AWS Direct Connect is available, AWS GovCloud Regions (US-East and US-West), as well as the Amazon Web Services China (Beijing) Region, operated by Sinnet, and the Amazon Web Services China (Ningxia) Region, operated by NWCD.

To learn more, see Inbound prefix controls for AWS Direct Connect in the AWS Direct Connect User Guide.

​Today, AWS Direct Connect announced inbound prefix controls, a new capability that lets you allocate and manage inbound route-prefix allocations for your private and transit virtual interfaces (VIFs) based on your workload’s needs. You can now allocate up to 1,000 prefixes each for IPv4 and IPv6 on your VIFs on dedicated and hosted connections.
Previously, Direct Connect VIFs accepted a maximum of 100 route prefixes advertised from your on-premises network to AWS on a private or transit VIF. If you had a larger or growing network, you had to architect around this ceiling, for example, by summarizing routes or segmenting across multiple VIFs or connections. With inbound prefix controls, you can allocate up to 1,000 prefixes to a single VIF and advertise your routes directly.
Inbound prefix controls introduce new prefix capacity pools at the dedicated connection level and at the Direct Connect gateway (DXGW) level. When you create or update a VIF, you allocate a specific number of prefixes to it, and that allocation draws from the dedicated connection’s pool and the DXGW’s pool when you attach it. This lets you right-size prefix capacity per workload—for example, a large allocation for a transit VIF carrying many routes and a smaller allocation for a private VIF on the same connection. Connection pool sizes scale with connection speed, and link aggregation group (LAG) pools scale with the number of member connections.
You can configure prefix allocations using the AWS Direct Connect console or CLI/API. Inbound prefix controls are available at no additional cost in all commercial AWS Regions where AWS Direct Connect is available, AWS GovCloud Regions (US-East and US-West), as well as the Amazon Web Services China (Beijing) Region, operated by Sinnet, and the Amazon Web Services China (Ningxia) Region, operated by NWCD.
To learn more, see Inbound prefix controls for AWS Direct Connect in the AWS Direct Connect User Guide.  

• Categoría: Company News

agosto 20, 2026

Construir las bases para la IA agéntica en la atención médica

Por: Kees Hertogh, vicepresidente de marketing global de la industria en Microsoft.

Basados en datos fiables, integrados en el flujo de trabajo y en funcionamiento en una infraestructura siempre activa. Lean cómo tres sistemas de salud ponen en marcha a los agentes.

Es martes por la mañana, y el hospital ya va retrasado en aspectos que no se recuperará al final del turno. Una médica lleva 10 pacientes y no ha terminado ni una nota, atrapada en la constante lucha entre la paciente que tiene delante y documentar la que acaba de dejar. Dos pisos más arriba, una enfermera lleva varias horas en un turno de 12 horas y ha pasado más tiempo en un puesto de trabajo que al lado de una cama. Al final del pasillo, los equipos clínicos, de operaciones y financieros persiguen las mismas preguntas urgentes—flujo de pacientes, personal, capacidad y coste—pero las respuestas están dispersas entre sistemas, y cuando los datos se unen, el momento de actuar ya ha pasado. Entonces llega una alerta a TI: la historia clínica electrónica (EHR, por sus siglas en inglés) se ha comenzado a ralentizar, y el CIO sabe que cada minuto que los clínicos no pueden acceder a datos clínicos, de farmacia y de laboratorio en tiempo real, es un minuto que la atención al paciente puede estar en riesgo.

Descubran cómo la IA puede mejorar los resultados reales a gran escala

No son problemas aislados. Son los mismos retos diarios que aparecen en diferentes maneras. Las soluciones desconectadas de proveedores aportan complejidad y coste añadidos, no información ni preocupación.

Las organizaciones sanitarias necesitan soluciones que trabajen en conjunto para evitar la fragmentación.

Una base conectada para la IA agéntica

Microsoft reúne todo lo que la sanidad necesita para desplegar y escalar IA agéntica, reunido en un solo lugar:

• Microsoft Fabric reúne datos de sistemas aislados en una única fuente gobernada de verdad sobre la que los agentes pueden razonar.
• Microsoft Dragon Copilot entrega agentes clínicos que trabajan dentro del flujo de trabajo del clínico.
• Microsoft 365 Copilot y Copilot Studio permiten a cualquier persona de la organización crear y gestionar sus propios agentes empresariales.
• Microsoft Azure y la pila de seguridad de Microsoft proporcionan la infraestructura resiliente y segura que mantiene siempre activos los agentes y el cuidado.

El resultado es un cambio de la fragmentación a la acción coordinada, con agentes que son contextuales, conocedores, fiables y escalables porque están basados en Microsoft IQ —la inteligencia propia de su organización— impulsada por datos de confianza y construida sobre infraestructuras de nivel empresarial.

Como Microsoft IQ es abierto y diversificado en modelos, los clientes construyen sobre su propio IQ y mantienen el control sobre él, en lugar de quedarse atados a la plataforma de otro. Tres sistemas de salud muestran cómo es eso en la práctica.

Los agentes valiosos resuelven problemas reales

Brown University Health, el mayor sistema sanitario de Rhode Island, atiende a un millón de personas y es la columna vertebral de cuidados críticos de la región. Desde 2024 ha crecido con rapidez, ha adquirido dos hospitales en Massachusetts y se ha fusionado con una gran consulta de médicos académicos, todo ello mientras lidia con presiones financieras, escasez de mano de obra y un creciente agotamiento clínico, impulsado en gran parte por la carga documental.

Su primera aplicación de IA, Dragon Copilot, un asistente clínico de IA, abordó esa carga de manera directa, para permitir que los clínicos de todas las especialidades se centraran en el paciente en lugar del teclado, con menos documentación fuera de horario y menor carga cognitiva. Un clínico lo expresó con claridad: «Esto va a prolongar mi carrera.»

Va a devolver la alegría a la práctica de la medicina. Los clínicos entraron en esto porque quieren ayudar a la gente. La mayoría no lo hizo porque quieren interactuar con ordenadores.

Adam Landman, SVP y director de información digital, Brown University Health

Brown pasó entonces de la IA que asiste a la IA que actúa. El equipo creó dos agentes de urgencias integrados en Dragon Copilot: uno que responde a preguntas específicas de políticas y procedimientos del hospital, y otro que muestra horarios y directorios de guardia para que el personal pueda llegar con rapidez al especialista adecuado. Esos son solo dos de más de dos docenas de agentes que el equipo ha construido en toda la organización—y con Copilot Studio, pasaron de la idea al prototipo funcional en un solo día.

La empresa siguió. Brown implementó Microsoft 365 Copilot a nivel organizacional para gestionar las bandejas de entrada, resumir reuniones y analizar contratos. Cuando los líderes necesitaban una política de gobernanza responsable de IA, ponían al agente investigador a trabajar para que estudiara las mejores prácticas e iterara borradores; una política que los líderes esperaban que tardara un año fue ratificada en cuatro meses.

Lean sobre cómo Brown Health escala Microsoft Dragon Copilot

Los agentes de confianza comienzan con datos fiables

Los agentes solo son tan fiables como los datos sobre los que razonan, que es justo donde empezó el Centro Regional de Salud de Peterborough (PRHC, por sus siglas en inglés). Atiende a una población creciente y envejecida frente a presiones conocidas en el sector sanitario: aumento del volumen de pacientes, creciente complejidad clínica y duras limitaciones en personal, financiación y capacidad. Los líderes vieron la oportunidad en la IA y reconocieron que solo funciona cuando se basa en datos sólidos.

Así que empezaron con los datos, no con el modelo. El equipo consolidó 18 sistemas de producción en Microsoft Fabric, una fuente gobernada de verdad para análisis e IA.

Partimos de un lugar de fragmentación e inmadurez de datos bastante significativas. Si alguien necesitaba datos, podía tardar semanas en encontrarlos, y lo que solía aparecer era una hoja de Excel desactualizada que no respondía en verdad a la pregunta.

Lynn Mikula, directora ejecutiva, Centro Regional de Salud de Peterborough

El cambio fue profundo: los equipos pasaron de esperar semanas para informes estáticos y desactualizados a explorar datos en tiempo real juntos, a través de una toma de decisiones más rápidas y seguras en los flujos de trabajo clínicos y operativos. La lección de Mikula refleja un principio fundamental de una estrategia agéntica: la IA escalable no comienza con modelos, comienza con los datos. Con una base gobernada, PRHC creó las condiciones para que los agentes escalen con datos en los que puedan confiar.

Y la recompensa es aparecer donde más importa: en la atención al paciente. PRHC atribuye mejoras en varios departamentos de urgencias y métricas de flujo de pacientes hospitalizados entre enero y marzo de 2026 a este esfuerzo operativo. Menos pacientes esperaban camas de ingreso a las 8 de la mañana, se bajó de 34 a 19, y el tiempo de espera para una cama de ingreso cayó un 43%, de 56,8 a 32 horas. A medida que mejoró el acceso, la proporción de pacientes que se marchaban sin ser atendidos disminuyó del 10% al 8,8%, mientras que las puntuaciones generales de experiencia aumentaron del 77% al 80%. Un nuevo turno de hospitalización mejoró los tiempos de respuesta de las consultas en alrededor de un 20%, lo que ayudó a equilibrar la carga de trabajo hospitalario y la calidad de la atención de apoyo. En conjunto, estos cambios contribuyeron a ganancias a largo plazo en el flujo de pacientes, incluida una reducción aproximada del 70% en los tiempos de descarga de ambulancias.

Exploren cómo PRHC convirtió los datos en información accionable

Agentes fiables se ejecutan sobre infraestructuras resilientes

Los agentes de los que dependen los clínicos no pueden ocultarse. Eso convirtió la infraestructura en la prioridad de Franciscan Health, que migró su Epic EHR a Azure para rendimiento, escalabilidad, recuperación ante desastres y seguridad en una plataforma preparada para el futuro. La apuesta era absoluta. «Si Epic está caído, no tenemos acceso a datos clínicos. No tenemos acceso a farmacia; no tenemos acceso a los resultados de laboratorio», dice el CIO Charles Wagner. «Así que, desde el momento en que eso se cae, la atención al paciente está en riesgo.» El coste es igual de evidente: «nos cuesta entre 10 y 12 millones de dólares al día cada día que nos caemos.»

El corte fue el primer punto de prueba. «Una vez que hicimos el cambio de paso, creo que no recibimos ni una sola llamada. Los clínicos y el personal ni siquiera sabían que había ocurrido», dice Wagner. «Así es como definimos el éxito.» Luego, los resultados se sumaron en rendimiento, coste y recuperación: Franciscan puede ahora poner en funcionamiento su entorno de recuperación ante desastres en menos de una hora, desde las 8 a 12 horas que antes tardaba, para mantener la continuidad de la atención incluso en un incidente grave.

Como migramos a Azure, podemos hacer un conmutador por error y estar listos en 30 minutos. Esto es algo que nunca podríamos hacer en nuestro entorno anterior.

Charles Wagner, CIO, Franciscan Health

La migración a Azure de Franciscan ofreció:

• 45 millones de dólares en ahorros durante cinco años.
• Un 33% menos en los costes de infraestructura.
• Respuesta a la solicitud un 50% más rápida.

Y como Epic se basa en tecnología de Microsoft, Franciscan obtuvo la ventaja de un solo proveedor que facilita la puesta en marcha al siguiente agente, al siguiente modelo, a la siguiente carga de trabajo—la diferencia entre luchar contra tu infraestructura y construir sobre ella.

Franciscan Health utilizó la IA para mejorar el rendimiento, la escalabilidad y la eficiencia

Una plataforma. IA en la que puedes confiar

Tres sistemas de salud, tres puntos de partida, un patrón. El valor no está en herramientas aisladas: está en una plataforma conectada donde los agentes están conectados, embebidos y fiables.

• Brown Health puso a trabajar agentes clínicos y empresariales en dos docenas de departamentos.
• El Centro Regional de Salud de Peterborough construyó la base de datos de los agentes de confianza para razonar sobre ella.
• Franciscan Health estableció la infraestructura resiliente que mantiene en funcionamiento a los agentes y la atención.

Todo funciona en conjunto, lo que facilita llevar nuevas soluciones online y obtener más valor de nuestras inversiones.

Charles Wagner, CIO, Franciscan Health

Ese es el cambio: no más herramientas, sino un sistema que funciona como uno solo, con datos, flujos de trabajo e inteligencia que entienda el contexto, sus procesos de negocio y las interacciones de sus equipos, para permitir a los agentes pasar de la señal a la acción. Fabric deja a la organización lista para IA. Dragon Copilot transforma el flujo de trabajo clínico. Copilot conecta equipos, decisiones y ejecución. Copilot Studio permite a cualquiera crear flujos de trabajo agénticos, escalables y repetibles. En conjunto, estas capacidades están basadas en Microsoft IQ y funcionan en Azure, parar brindar la resiliencia, seguridad y escala de las que dependen las organizaciones sanitarias. Desde el analista que usa Fabric, hasta el clínico que utiliza Dragon Copilot, el resto de sus empleados que usan Copilot, para pasar por los constructores que crean en Copilot Studio, la organización por fin funciona con la misma inteligencia y los mismos agentes, para convertir señales fragmentadas en acciones coordinadas y datos en mejor atención al paciente.

Así, cuando empiece el siguiente turno, los clínicos pueden dedicar más tiempo a atender a los pacientes, los líderes pueden tomar decisiones con confianza y las organizaciones pueden actuar según las ideas antes de que pase el momento de actuar.

Descubran cómo la IA agéntica genera un impacto real a lo largo del continuo de atención

Desde reducir la carga documental y mejorar el flujo de pacientes hasta modernizar las plataformas de datos y fortalecer infraestructuras críticas, las organizaciones sanitarias han puesto la IA a trabajar de manera práctica. Exploren las estrategias, las lecciones aprendidas y los resultados detrás de estas transformaciones reales.

Descarguen el libro electrónico de AI para una mejor atención médica

Etiquetas:

• IA
• Innovación
• Salud

The post Construir las bases para la IA agéntica en la atención médica appeared first on Source LATAM.

​The post Construir las bases para la IA agéntica en la atención médica appeared first on Source LATAM.  

AWS partners can now configure category-based notifications and multi-channel delivery for AWS Marketplace notifications through AWS User Notifications. Previously, partners received their AWS Marketplace notifications through their AWS account’s root email address or custom email aliases, with no way to select notification categories or route each category to the teams responsible for managing it. With this launch, partners can choose which contacts receive each notification category and how those notifications are delivered.

Four notification categories are available. Product listings notifications cover open product tasks, recurring scan findings for AMI and container products, and Vendor Insights security profile snapshots for SaaS products. Offers and agreements notifications cover private offers, reseller activity, professional services requests, agreement starts and cancellations, cancellation requests, and agreement creation failures. Payments and disbursements notifications cover payment requests, billing adjustments, invoice submission outcomes, payment failures, and disbursement issues. Account management notifications cover business and bank account verification actions, approvals, expirations, and rejections.

By default, notifications are delivered by email to the AWS account’s root email address. Partners can add recipients through additional email addresses and distribution lists. Partners can also receive notifications through the AWS Console Mobile Application or Amazon Q Developer in chat applications such as Slack and Microsoft Teams. After enabling managed notifications, partners can select the contacts and delivery channels that receive each category.

AWS Marketplace category-based notifications are available in all AWS Commercial Regions where AWS Marketplace is available. To learn more, see Managing email notifications for AWS Marketplace events in the AWS Marketplace documentation. To enable managed notifications, visit the AWS User Notifications console.

​AWS partners can now configure category-based notifications and multi-channel delivery for AWS Marketplace notifications through AWS User Notifications. Previously, partners received their AWS Marketplace notifications through their AWS account’s root email address or custom email aliases, with no way to select notification categories or route each category to the teams responsible for managing it. With this launch, partners can choose which contacts receive each notification category and how those notifications are delivered.
Four notification categories are available. Product listings notifications cover open product tasks, recurring scan findings for AMI and container products, and Vendor Insights security profile snapshots for SaaS products. Offers and agreements notifications cover private offers, reseller activity, professional services requests, agreement starts and cancellations, cancellation requests, and agreement creation failures. Payments and disbursements notifications cover payment requests, billing adjustments, invoice submission outcomes, payment failures, and disbursement issues. Account management notifications cover business and bank account verification actions, approvals, expirations, and rejections.
By default, notifications are delivered by email to the AWS account’s root email address. Partners can add recipients through additional email addresses and distribution lists. Partners can also receive notifications through the AWS Console Mobile Application or Amazon Q Developer in chat applications such as Slack and Microsoft Teams. After enabling managed notifications, partners can select the contacts and delivery channels that receive each category.
AWS Marketplace category-based notifications are available in all AWS Commercial Regions where AWS Marketplace is available. To learn more, see Managing email notifications for AWS Marketplace events in the AWS Marketplace documentation. To enable managed notifications, visit the AWS User Notifications console.  

Amazon CloudWatch pipelines now includes three new processors that parse and enrich log data as it’s ingested: an Amazon RDS log parser, an XML parser and a GeoIP enrichment processor. CloudWatch pipelines is a fully managed service that ingests, transforms, and routes telemetry to CloudWatch without managing infrastructure.

Log sources often produce data that isn’t immediately queryable without reprocessing the data. RDS Aurora logs arrive in their native engine format, application logs carry embedded XML, and IP addresses lack location context. The new processors address each case. The Amazon RDS processor parses Aurora audit and error logs into structured fields, the XML parser converts a field containing an XML string into JSON, and the GeoIP processor enriches any IP address field with geographic context such as city, country, and coordinates. For example, you can parse an Aurora audit log into structured fields for compliance reporting. In a separate pipeline, you can extract the XML payload from a Windows Event Log into JSON and resolve its source IP to a city and country for security analysis. You can use these processors independently or combine them in one pipeline.

These processors are available at no additional cost in all AWS Regions where CloudWatch pipelines is generally available. CloudWatch logs ingestion and storage rates apply. You can add these processors to your pipelines using the AWS Management Console, AWS CLI, or AWS SDKs. To get started, see the Amazon CloudWatch pipelines documentation.

​Amazon CloudWatch pipelines now includes three new processors that parse and enrich log data as it’s ingested: an Amazon RDS log parser, an XML parser and a GeoIP enrichment processor. CloudWatch pipelines is a fully managed service that ingests, transforms, and routes telemetry to CloudWatch without managing infrastructure.
Log sources often produce data that isn’t immediately queryable without reprocessing the data. RDS Aurora logs arrive in their native engine format, application logs carry embedded XML, and IP addresses lack location context. The new processors address each case. The Amazon RDS processor parses Aurora audit and error logs into structured fields, the XML parser converts a field containing an XML string into JSON, and the GeoIP processor enriches any IP address field with geographic context such as city, country, and coordinates. For example, you can parse an Aurora audit log into structured fields for compliance reporting. In a separate pipeline, you can extract the XML payload from a Windows Event Log into JSON and resolve its source IP to a city and country for security analysis. You can use these processors independently or combine them in one pipeline.
These processors are available at no additional cost in all AWS Regions where CloudWatch pipelines is generally available. CloudWatch logs ingestion and storage rates apply. You can add these processors to your pipelines using the AWS Management Console, AWS CLI, or AWS SDKs. To get started, see the Amazon CloudWatch pipelines documentation.  

Web Search in Amazon Bedrock AgentCore now supports domain filtering and published-date filtering, giving agents per-request control over which web sources and time windows they search. Amazon Bedrock AgentCore provides the infrastructure to build, connect, and optimize AI agents, and Web Search enables those agents to ground responses in current web data.

With runtime domain filtering, agents can narrow search results to trusted sources or block unwanted domains on a per-call basis without requiring admin reconfiguration. Published-date filtering allows agents to constrain results to a specific time window using inclusive from and to date bounds, ensuring responses reflect only timely, relevant content.

With this launch, agents can pass include and exclude domain lists and a published-date range directly in each tool call, while admins gain new gateway-level allowlist support and an increased domain cap of up to 100 domains per list. These capabilities are ideal for regulated industries, research workflows, and applications that require strict control over information sources and recency.

The Web Search Tool is also expanding to Europe (Ireland) (eu-west-1) and Asia Pacific (Tokyo) (ap-northeast-1), joining the existing US East (N. Virginia) (us-east-1) availability. To learn more, read the technical blog about domain and published date filters , and review the Amazon Bedrock AgentCore product documentation.

​Web Search in Amazon Bedrock AgentCore now supports domain filtering and published-date filtering, giving agents per-request control over which web sources and time windows they search. Amazon Bedrock AgentCore provides the infrastructure to build, connect, and optimize AI agents, and Web Search enables those agents to ground responses in current web data. With runtime domain filtering, agents can narrow search results to trusted sources or block unwanted domains on a per-call basis without requiring admin reconfiguration. Published-date filtering allows agents to constrain results to a specific time window using inclusive from and to date bounds, ensuring responses reflect only timely, relevant content. With this launch, agents can pass include and exclude domain lists and a published-date range directly in each tool call, while admins gain new gateway-level allowlist support and an increased domain cap of up to 100 domains per list. These capabilities are ideal for regulated industries, research workflows, and applications that require strict control over information sources and recency. The Web Search Tool is also expanding to Europe (Ireland) (eu-west-1) and Asia Pacific (Tokyo) (ap-northeast-1), joining the existing US East (N. Virginia) (us-east-1) availability. To learn more, read the technical blog about domain and published date filters , and review the Amazon Bedrock AgentCore product documentation.