Read this article in English

Canonical ha publicado una guía de referencia para construir, mantener y asegurar la infraestructura que sustenta las llamadas AI factories, donde los clústeres GPU permanecen en producción a lo largo de varias generaciones de modelos y frameworks. El artículo oficial del 2 de noviembre de 2026 define este concepto como la infraestructura y los procesos usados para desarrollar, entrenar y servir modelos, de modo que sus requisitos de seguridad se extienden a lo largo del ciclo de vida de producción. La propuesta combina parcheo de ciclo de vida extendido, automatización de cumplimiento, parcheo de kernel sin reinicio, cadena de suministro de contenedores minimizada, orquestación Day‑2 y cómputo confidencial con GPU acelerada.

Marco AI factory y mantenimiento extendido

El marco AI factory implica que la estabilidad del sistema operativo y de las dependencias de IA/ML debe garantizarse durante años, no meses. Ubuntu Pro ofrece hasta 15 años de parcheo de seguridad para el SO y los paquetes del archivo de Ubuntu, cubriendo todo el ciclo de vida típico de un clúster de entrenamiento. Esta cobertura elimina la presión de migrar cargas de trabajo solo por fin de soporte del SO base.

El mantenimiento a largo plazo no se limita al kernel: abarca bibliotecas de cómputo, runtimes de contenedores y toolchains de IA que evolucionan en calendarios propios. La suscripción Ubuntu Pro incluye módulos criptográficos certificados FIPS 140‑3 para entornos regulados como gobierno, finanzas y salud. La gratuidad para uso personal en hasta cinco máquinas permite validar la pila completa antes de comprometer contratos empresariales.

La coherencia entre nodos se vuelve crítica cuando la flota crece a cientos de GPUs. Cualquier deriva de configuración introduce superficie de ataque y complica la auditoría. El enfoque de Canonical trata la infraestructura como un producto versionado, no como un conjunto de scripts ad‑hoc, lo que facilita la reproducibilidad y la respuesta a incidentes.

Ubuntu Pro, Livepatch y cumplimiento automatizado

Livepatch permite aplicar correcciones críticas de seguridad del kernel sin reinicio, de modo que los trabajos de entrenamiento de modelos de larga duración no tienen por qué interrumpirse. Esta capacidad es decisiva en clústeres donde una ventana de mantenimiento de horas implica costes de GPU inactiva y riesgo de no converger a tiempo. Livepatch cubre parches de kernel Canonical; no sustituye reinicios para actualizaciones de glibc, systemd, firmware o microcódigo.

La Ubuntu Security Guide (USG) automatiza la aplicación y auditoría de perfiles CIS y DISA‑STIG, ayudando a demostrar que cada entorno cumple el mismo estándar. El comando de auditoría sudo usg audit cis_level1_server genera informes HTML y XML bajo /var/lib/usg/. USG forma parte de Ubuntu Pro y está documentada como gratuita para uso personal en un número pequeño de máquinas. Según la guía auditd, la auditoría puede integrarse en pipelines de cumplimiento.

La automatización de endurecimiento reduce el error humano y el tiempo de validación en flotas grandes. Sin embargo, USG modifica configuración del sistema; algunos controles CIS pueden romper aplicaciones legacy, por lo que es obligatorio probar en staging antes de producción. La remediación con sudo usg fix cis_level1_server debe ser parte de un pipeline de cambio controlado.

Cadena de suministro de contenedores minimizada

Container Build Service aborda el desafío de mantener imágenes base de IA/ML mediante builds personalizados y mantenimiento de seguridad para sus dependencias, incluido software como PyTorch, TensorFlow y CUDA. Rockcraft proporciona builds declarativos OCI‑compliant basados en Ubuntu, mientras que Chisel selecciona solo los archivos que una aplicación necesita, permitiendo omitir componentes innecesarios.

La minimización de superficie de ataque mediante Chisel exige declarar dependencias explícitas, lo que puede romper imágenes de tipo kitchen‑sink que asumen la presencia de herramientas de diagnóstico o shells completos. El pipeline CI/CD debe adaptarse para generar SBOMs y firmar imágenes, integrando la verificación de proveniencia en cada promoción a producción.

El mantenimiento de dependencias de IA/ML más allá del SO base cierra una brecha habitual: las vulnerabilidades en capas de framework o drivers CUDA a menudo quedan sin parchear porque el SO base está al día. Container Build Service extiende el parcheo a esas capas, proporcionando una cadena de confianza continua desde el silicio hasta el modelo servido.

Orquestación Day‑2 y MLOps con Juju

Charmed Kubeflow proporciona pipelines de ML en Kubernetes empaquetados como charms, operadores de software que contienen código específico para despliegue, configuración, actualizaciones soportadas e integraciones. Juju, el motor de orquestación de código abierto de Canonical, ejecuta estos operadores, reduciendo scripts de integración y procedimientos manuales de actualización de Kubeflow, MLflow, Kubernetes e Istio.

El modelo charm introduce una curva de aprendizaje: los equipos deben validar compatibilidad de versiones upstream antes de cada actualización. La automatización Day‑2 baja el error humano y el tiempo de validación, pero requiere disciplina en pruebas de integración y estrategias de rollback probadas en entornos representativos.

La orquestación declarativa permite tratar la plataforma MLOps como infraestructura versionada, aplicando los mismos principios de GitOps y compliance que al SO base. Esto alinea los ciclos de vida de modelo, datos e infraestructura, facilitando auditorías y respuesta a incidentes coordinada.

Cómputo confidencial con GPU H100

Ubuntu soporta máquinas virtuales confidenciales usando Intel TDX y AMD SEV‑SNP, con aislamiento reforzado por hardware diseñado para proteger la memoria del huésped del hipervisor. Configuraciones soportadas con GPUs NVIDIA H100 extienden el cómputo confidencial a cargas de trabajo de IA aceleradas. La atestación remota proporciona evidencia sobre el entorno de ejecución.

El despliegue de VMs confidenciales con GPU H100 requiere hardware compatible: CPU Intel de 4ª/5ª generación o AMD EPYC 9004, GPU H100 y BIOS/firmware habilitado. La atestación remota necesita infraestructura de verificación, como Azure Attestation, Google Confidential Space o stack propio. Sin esa cadena de verificación, la garantía de aislamiento queda incompleta.

Esta capacidad abre la puerta a cargas de trabajo multi‑tenant o datos regulados (salud, finanzas) sin confiar en el hipervisor del proveedor cloud. El rendimiento de cifrado en módulos FIPS 140‑3 puede degradarse frente a implementaciones no‑FIPS; los equipos deben medir el impacto en sus pipelines de entrenamiento e inferencia antes de mandatar su uso.

Recomendaciones aplicables, condiciones y límites

• Activar Ubuntu Pro y USG en todos los nodos de IA: requiere suscripción (gratis ≤5 máquinas uso personal; producción empresarial requiere contrato).
• Ejecutar sudo usg audit cis_level1_server como baseline y sudo usg fix cis_level1_server para remediación: probar en staging; algunos controles CIS pueden romper aplicaciones legacy.
• Habilitar Livepatch en clústeres de entrenamiento largos: solo cubre parches de kernel Canonical; no sustituye reinicios para glibc, systemd, firmware o microcódigo.
• Usar Container Build Service + Rockcraft + Chisel para imágenes base de IA: requiere cuenta Canonical y pipeline CI/CD adaptado; Chisel exige dependencias explícitas.
• Desplegar VMs confidenciales (TDX/SEV‑SNP) con GPU H100 para cargas sensibles: hardware compatible necesario; atestación remota requiere infraestructura de verificación.
• Adoptar Charmed Kubeflow + Juju para MLOps: curva de aprendizaje del modelo charm; validar compatibilidad upstream antes de cada actualización.
• Imponer FIPS 140‑3 en entornos regulados: solo módulos certificados por Canonical; puede degradar rendimiento en cifrado simétrico/asimétrico vs. OpenSSL default.

La guía de Canonical constituye una referencia técnica primaria para endurecimiento integral de infraestructura de IA, combinando parcheo de 15 años, compliance automatizado, kernel sin reinicio, contenedores minimizados, orquestación Day‑2 y cómputo confidencial con GPU.

{
  "format": "rafael-fuentes-article/1.0",
  "language": "es",
  "title": "Canonical publica guía de endurecimiento para IA con Ubuntu Pro, USG",
  "summary": "Canonical publica una guía técnica para endurecer y mantener infraestructuras de IA con Ubuntu Pro, USG, Livepatch, contenedores minimizados y cómputo confidencial con GPU H100.",
  "author": "Rafael Fuentes",
  "publicationDate": "2026-11-05T20:01:35.040+01:00",
  "eventDate": "2026-11-02",
  "url": "https://falifuentes.com/rafael-fuentes-2026-11-05-pm-es/",
  "translation": {
    "language": "en",
    "url": "https://falifuentes.com/rafael-fuentes-2026-11-05-pm-en/"
  },
  "topics": [
    "Automatización y Robótica",
    "Compliance y Normativas",
    "Criptografía",
    "Español",
    "IA",
    "Inteligencia artificial"
  ],
  "sources": [
    "https://canonical.com/blog/how-to-build-maintain-and-secure-infrastructure-for-ai-factories",
    "https://tech-insider.org/auditd-setup-ubuntu-augenrules-13-steps-50-min-2026"
  ]
}

La entrada Canonical publica guía de endurecimiento para IA con Ubuntu Pro, USG se publicó primero en Fali Fuentes.

Read this article in English

El 4 de noviembre de 2026, Debian y Canonical publicaron avisos coordinados (DSA-6607-1, DLA-4880-1, USN-8996-1) que corrigen CVE-2026-109518, una falla en APT que permite a un atacante en posición de red intermedia instalar paquetes sin verificar y ejecutar código como root. El fallo rompe la cadena de confianza del gestor de paquetes al sustituir el contenido verificado tras una redirección HTTP y un reintento de descarga.

Mecanismo de la vulnerabilidad: reutilización de hard links y redirecciones

El fallo reside en la forma en que APT gestiona enlaces duros al seguir una redirección HTTP y reintenta la descarga del mismo archivo. Cuando el servidor responde con una redirección, el cliente puede asignar la misma URI a dos descargas distintas; al reintentar, el contenido verificado originalmente se sobrescribe con el suministrado por el atacante, sin que la comprobación de firmas detecte el cambio. Esta sustitución silenciosa rompe la cadena de confianza del gestor de paquetes.

Max Justicz, descubridor del fallo, ya había reportado en 2019 el error de redirección CVE-2019-3462 que también concedía root a un atacante de red. La lógica defectuosa persiste en el manejo inseguro de los enlaces duros cuando el cliente sigue redirecciones y reintenta la descarga de archivos de paquetes, permitiendo la sustitución silenciosa del contenido verificado. El hallazgo subraya la recurrencia de patrones de fallo en el gestor de descargas.

El vector requiere que el cliente APT siga redirecciones HTTP y reintente descargas, condiciones habituales en repositorios oficiales que usan mirrors y balanceadores de carga. Un mirror malicioso, un proxy corporativo comprometido o una red Wi‑Fi pública controlada por el atacante son superficies de exposición realistas para este ataque Man‑in‑the‑Middle. La amplia adopción de mirrors aumenta la probabilidad de encuentro con un nodo controlado.

Condiciones de explotabilidad: Acquire::Retries y configuración por defecto

La explotación exige que la configuración Acquire::Retries sea distinta de cero. El valor por defecto es 3 desde Debian 12 (bookworm) y Ubuntu 22.04 LTS (Jammy Jellyfish), por lo que las versiones antiguas no son vulnerables en su configuración original. Esto convierte a la configuración estándar moderna en un factor de riesgo inesperado para administradores que no revisan los parámetros de reintento.

El CVSS v4.0 asigna una puntuación base de 7.7 (High) con vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. La complejidad de ataque baja y la ausencia de privilegios previos reflejan la facilidad de posición de red intermedia, mientras que la interacción de usuario requerida se limita a ejecutar apt install o apt upgrade. La métrica subraya la exposición real en entornos de producción estándar actuales y de alta criticidad.

No existen reportes de explotación activa ni exploits públicos al 3 de noviembre de 2026, y el catálogo CISA KEV no la incluye. Sin embargo, la ausencia de evidencia no equivale a ausencia de riesgo: la cadena de suministro de software expone esta superficie en entornos cloud, CI/CD y redes corporativas donde el control del canal de red no está garantizado. La vigilancia continua sigue siendo esencial.

Impacto en la cadena de suministro y derivados

Cualquier derivado de Debian o Ubuntu —Kali, Linux Mint, Pop!_OS, imágenes base de contenedores, runners de CI/CD— hereda la vulnerabilidad hasta que su mantenedor publique el backport correspondiente. La ubiquidad de APT como gestor de paquetes universal amplifica el radio de blast potencial más allá de las distribuciones upstream. Cada capa de la cadena de suministro debe validar la versión de apt antes de promover artefactos.

Las imágenes de contenedores que incorporan apt vulnerable y se reconstruyen automáticamente en pipelines comprometen la integridad del software desplegado. Un atacante con posición en el registro de contenedores o en la red de construcción puede inyectar código en la capa de paquetes del sistema base, persistiendo en producción tras el despliegue. La automatización de builds sin verificación de la versión de apt propaga el fallo silenciosamente.

La paradoja de la auto‑actualización agrava el escenario: APT debe actualizarse a sí mismo sobre un canal de red de confianza. Si el atacante controla ese canal, puede bloquear o corromper la propia actualización de apt, impidiendo la remediación y manteniendo la persistencia en el sistema objetivo. Esta dependencia circular convierte la propia herramienta de corrección en vector de ataque.

Mitigaciones efectivas y sus limitaciones reales

La mitigación definitiva es actualizar apt a las versiones listadas en los avisos oficiales: 3.0.4 en trixie, 2.6.2 en bookworm LTS, 3.3.3ubuntu0.1 en Ubuntu 26.10, 3.2.1ubuntu0.1 en 26.04 LTS, 2.8.4ubuntu0.1 en 24.04 LTS y 2.4.15ubuntu0.1 en 22.04 LTS; las versiones ESM para 20.04, 18.04, 16.04 y 14.04 requieren Ubuntu Pro. Consulte USN-8996-1 y DSA-6607-1 para los detalles completos de cada release.

Desactivar reintentos mediante Acquire::Retries ‘0’; en /etc/apt/apt.conf.d/99no-retries elimina la condición Acquire::Retries ≠ 0, pero no cierra la raíz del fallo: el manejo inseguro de enlaces duros. Solo reduce la ventana de exposición y no sustituye al parche. Forzar HTTPS en sources.list mitiga MitM pasivo, pero no protege contra mirrors o proxies maliciosos que terminan TLS legítimamente en entornos productivos y de alta criticidad.

Verificar hashes manualmente con apt download pkg && sha256sum es operativamente inviable a escala; útil solo para paquetes críticos puntuales. La reconstrucción de imágenes base de contenedores y pipelines CI/CD tras la disponibilidad de apt fijado en cada release es obligatoria para cerrar la brecha en la cadena de suministro. La integración de comprobaciones de versión en los pipelines evita la propagación inadvertida.

Actualización segura: la paradoja del canal de confianza

Ejecutar apt update && apt install apt debe realizarse sobre una ruta de red verificada: consola local, VPN corporativa validada o mirror interno auditado. Si el atacante domina el camino de red, puede envenenar la propia actualización de apt, creando un bucle de compromiso irrompible sin intervención física o fuera de banda. La planificación de una ventana de mantenimiento aislada reduce drásticamente el riesgo.

Los equipos de operaciones deben priorizar la actualización de apt en bastiones de gestión, servidores de salto y nodos de construcción antes que en cargas de trabajo expuestas. La monitorización del catálogo CISA KEV y de avisos de derivados eleva la prioridad operativa si la vulnerabilidad es incluida en futuras revisiones. La coordinación entre equipos de seguridad y operaciones acelera la respuesta.

La lección estructural es que la confianza en la verificación criptográfica de paquetes no basta si la lógica de instalación puede ser subvertida por condiciones de carrera en el sistema de archivos. CVE-2026-109518 demuestra que la cadena de confianza se rompe en el instante entre verificación e instalación cuando el gestor de paquetes reutiliza recursos del sistema de archivos sin validar su integridad post‑redirección. Revisar el código de manejo de descargas en gestores de paquetes críticos es una medida preventiva.

{
  "format": "rafael-fuentes-article/1.0",
  "language": "es",
  "title": "CVE-2026-109518: APT permite instalación de paquetes no verificados y ejecución root vía MitM",
  "summary": "Una vulnerabilidad en APT permite a un atacante MitM instalar paquetes sin verificar y ganar root; se corrige en Debian 12/13 y Ubuntu 22.04-26.10.",
  "author": "Rafael Fuentes",
  "publicationDate": "2026-11-05T06:01:35.059+01:00",
  "eventDate": "2026-11-04",
  "url": "https://falifuentes.com/rafael-fuentes-2026-11-05-am-es/",
  "translation": {
    "language": "en",
    "url": "https://falifuentes.com/rafael-fuentes-2026-11-05-am-en/"
  },
  "topics": [
    "Automatización y Robótica",
    "Ciberseguridad",
    "Español",
    "Noticias de Ciberseguridad",
    "Supply Chain"
  ],
  "sources": [
    "https://ubuntu.com/security/notices/USN-8996-1",
    "https://security-tracker.debian.org/tracker/DSA-6607-1"
  ]
}

La entrada CVE-2026-109518: APT permite instalación de paquetes no verificados y ejecución root vía MitM se publicó primero en Fali Fuentes.

Read this article in English

Amazon Web Services y Microsoft han publicado casi simultáneamente sendas actualizaciones que cambian la forma en que los agentes de IA interactúan con la lógica de negocio ya desplegada. En lugar de reescribir flujos o incrustar reglas en el modelo, ambas plataformas exponen los motores de orquestación existentes —Step Functions y Logic Apps— como herramientas invocables por el agente, manteniendo el control determinista fuera del LLM.

AWS: Step Functions como herramientas de agente vía AgentCore Gateway y MCP

AWS anuncia que los flujos Standard y Express de Step Functions —que ya coordinan más de 220 servicios— pueden entregarse al agente como herramientas a través de Amazon Bedrock AgentCore Gateway, que habla Model Context Protocol (MCP). El agente decide cuándo ejecutar un flujo y qué entrada pasar; Step Functions garantiza el orden y la semántica exactly‑once tal como se definió, sin que el modelo manipule credenciales ni secuencia de pasos.

La compatibilidad es inmediata: cualquier flujo existente califica como objetivo de conector en todas las regiones donde AgentCore Gateway está disponible, con tarifas estándar. MoEngage expuso aproximadamente 400 APIs REST internas como herramientas de agente mediante este gateway, ahorrando unos seis meses de ingeniería de plataforma; los agentes buscan herramientas describiendo la tarea, no recibiendo catálogos completos, lo que evita más de 20.000 tokens por conexión según el blog oficial de AWS.

Como contexto adicional, OpenAI GPT‑6.1 Terra llega a Bedrock con precios al menos un 50 % inferiores a GPT‑6.1 Sol y GPT‑5.6 Terra, 1 millón de tokens de entrada y, según datos de OpenAI, tres veces más rápido en Agents’ Last Exam; se recomienda validar en conjunto de evaluación propio antes de producción.

Microsoft: Logic Apps Automation orquesta agentes Foundry (Prompt y Hosted)

Microsoft presenta Logic Apps Automation como plano de control determinista alrededor de agentes Foundry —Prompt Agents configurados y Hosted Agents basados en contenedor con código personalizado—. Llamadas API, programaciones y eventos de conector disparan al agente, mientras Logic Apps aporta ramificación, reintentos, timeouts, ejecución en paralelo e historial de ejecución alrededor de la invocación.

El patrón de seguridad documentado muestra un agente Foundry invocando Logic Apps mediante herramienta OpenAPI con managed identity y Entra ID, eliminando claves SAS. Además, se detalla una ruta de migración obligatoria antes del 1 de diciembre de 2026, fecha en que Foundry workflows se retiran, para mover agentes interactivos a procesos de negocio trazables y orientados a eventos según el boletín de Azure Integration Services.

En preview público, las concesiones mensuales por suscripción Azure incluyen 108.000 segundos de ejecución de flujo, 1 GB de retención, 1.000 llamadas a conectores Standard y 500 Enterprise, almacenamiento de conocimiento y uso de IA; el entorno gestionado es gratuito solo los primeros 60 días. También se libera una extensión CLI local para desarrollo de Logic Apps Standard con creación de proyectos, descubrimiento de conectores, validación y diagnóstico desde terminal.

Comparativa de paradigmas: Bring your own workflow vs. Orquestación nativa

AWS adopta un enfoque “bring your own workflow”: los flujos existentes se exponen como herramientas MCP sin reescritura, y el gateway gestiona el contrato agente‑herramienta con búsqueda semántica que reduce token bloat. Microsoft opta por “orquestación nativa”: Logic Apps se convierte en control plane que envuelve a los agentes Foundry, aportando gobernanza determinista (branching, retries, timeouts) alrededor de la llamada no determinista.

En ambos casos la superficie de ataque se reduce: en AWS la identidad del inquilino nunca llega al modelo (caso MoEngage); en Azure las reglas de negocio permanecen en el workflow auditado y el agente solo conversa y delega. La gobernanza de costes difiere: AWS cobra tarifas estándar de Step Functions más AgentCore Gateway; Azure ofrece grants generosos en preview pero el entorno gestionado gratis expira a los 60 días.

La experiencia de desarrollador también diverge: AWS proporciona catálogo dinámico de herramientas por tarea y MCP 2025‑11‑25 para intercambio de tokens on‑behalf‑of con Entra ID; Microsoft libera CLI local (preview), SDK tipado C#, Connector Namespace y Copilot skill para validación y diagnóstico, complementando el diseñador visual.

Seguridad y gobernanza: reducción de superficie de ataque y control de costes

La separación estricta entre decisión del agente y ejecución del flujo elimina la necesidad de incrustar secretos en el código del agente. En AWS, AgentCore Gateway media el acceso mediante MCP y gestiona identidades sin exponer credenciales al modelo. En Azure, el artículo comunitario “Don’t Rebuild Your Workflows Inside Agents” muestra invocación segura con managed identity y Entra ID, sin claves SAS ni secretos en el agente.

La trazabilidad mejora porque cada ejecución de flujo queda registrada en el motor de orquestación (Step Functions o Logic Apps) con historial completo, inputs, outputs y tiempos, facilitando auditoría y cumplimiento. Los costes son predecibles: AWS usa tarifas por transición de estado y llamadas a gateway; Azure publica grants mensuales y precios base más compute scale‑to‑zero, con capacidades opcionales que se facturan por separado.

Ambas plataformas exigen validar que la lógica de negocio expuesta sea determinista y no requiera improvisación del modelo. Solo flujos Standard/Express (AWS) o Standard (Azure) cualifican; flujos con comportamiento no determinista o dependientes de contexto conversacional extenso deben rediseñarse antes de exponerlos como herramienta.

Migración urgente y recomendaciones prácticas

La fecha límite del 1 de diciembre de 2026 para Foundry workflows obliga a los equipos Azure a migrar a Logic Apps Automation en menos de 30 días; se debe usar la guía oficial y el repositorio de referencia Form‑to‑Action, validando correlación end‑to‑end mediante correlation ID. En AWS, no hay migración forzosa, pero se recomienda inventariar flujos candidatos y adoptar MCP como contrato estándar, lo que requiere AgentCore Gateway o implementación propia de servidor MCP versión 2025‑11‑25 para OBO token exchange.

Para evitar token bloat, implementar búsqueda semántica de herramientas (patrón MoEngage): el agente describe la tarea y el gateway devuelve la herramienta relevante, reduciendo de >20k tokens a pocos cientos por conexión. Evaluar GPT‑6.1 Terra en Bedrock para cargas everyday sensibles a coste/latencia, validando en propio eval set porque los benchmarks son cifras de OpenAI, no test independiente.

Habilitar CLI local y SDK tipado para CI/CD de Logic Apps Standard (preview) integrándolos con GitHub Actions o Azure DevOps para policy‑as‑code y validación previa a despliegue. Aprovechar los grants gratuitos de Logic Apps Automation (108k exec‑sec/mes, 1 GB retención, 1k/500 llamadas conector Std/Ent) para validar arquitectura agente‑orquestada, recordando que el entorno gestionado gratis dura solo 60 días y no es recurrente.

{
  "format": "rafael-fuentes-article/1.0",
  "language": "es",
  "title": "AWS y Microsoft habilitan orquestación nativa de agentes IA sobre flujos empresariales",
  "summary": "AWS y Microsoft exponen Step Functions y Logic Apps como herramientas invocables por agentes IA, preservando la ejecución determinista y reduciendo superficie de ataque.",
  "author": "Rafael Fuentes",
  "publicationDate": "2026-11-04T06:01:35.096+01:00",
  "eventDate": "2026-11-02",
  "url": "https://falifuentes.com/rafael-fuentes-2026-11-04-am-es/",
  "translation": {
    "language": "en",
    "url": "https://falifuentes.com/rafael-fuentes-2026-11-04-am-en/"
  },
  "topics": [
    "Automatización y Robótica",
    "Español",
    "IA",
    "Inteligencia artificial",
    "OpenAI"
  ],
  "sources": [
    "https://aws.amazon.com/blogs/aws/aws-weekly-roundup-gpt-6-1-terra-on-bedrock-step-functions-as-agent-tools-and-more-november-2-2026",
    "https://techcommunity.microsoft.com/blog/integrationsonazureblog/logic-apps-aviators-newsletter---november-2026/4569378"
  ]
}

La entrada AWS y Microsoft habilitan orquestación nativa de agentes IA sobre flujos empresariales se publicó primero en Fali Fuentes.