Glosario de Arquitectura Azure para Agentes de IA

Los términos que aparecen una y otra vez en el Curso de Arquitectura Azure para Agentes de IA. Como el glosario de GCP, asume el vocabulario común de la serie (definido en el glosario de AWS) y se concentra en lo propio de Microsoft y las equivalencias que evitan traducir mal. Como todo glosario de la academia, crece con cada bloque nuevo.

El mapa: tenant, suscripciones y resource groups

Tenant — Tu instancia de Entra ID: el directorio de identidades que existe antes que cualquier recurso de Azure y del que todo cuelga — el mismo directorio de Microsoft 365. La inversión filosófica de Azure: la nube vive dentro del directorio, no al revés. Se desarrolla en el mapa de Azure.

Entra ID (ex Azure Active Directory) — El directorio de identidades de Microsoft: humanos, grupos, aplicaciones y — la gracia para esta serie — las identidades de los agentes, todos en el mismo plano.

Suscripción (subscription) — El contenedor de facturación, cuotas y límites: el nivel “cuenta de AWS”. Prod, dev y sandbox como suscripciones separadas es el patrón base.

Resource group (RG) — El agrupador con ciclo de vida común que AWS y GCP no tienen como ciudadano de primera clase: los recursos del agente se despliegan, permisos y borran juntos. RG por agente es el patrón de la serie en esta casa.

Management group — La jerarquía sobre las suscripciones donde Azure Policy se declara una vez y se hereda hacia abajo — las carpetas de GCP, versión Microsoft.

Azure Policy — El techo duro y el músculo de cumplimiento: desde “solo estas regiones” hasta “ningún recurso sin tags” o “todo servicio con acceso público deshabilitado” — denegado en el despliegue, no auditado después. La pieza que convierte disciplina voluntaria en requisito estructural.

Cloud Adoption Framework (CAF) — La documentación prescriptiva de Microsoft: landing zones de referencia con opinión para casi toda decisión. Bendición (no partes de cero) y riesgo (la landing zone enterprise para tres agentes es sobre-arquitectura con sello).

Identidad

Managed identity — La identidad de workload de Azure en su forma más cómoda: Azure la crea, rota e inyecta — no existe llave exportable. System-assigned (nace y muere con el recurso) o user-assigned (recurso propio, estable entre redespliegues — la forma que la identidad-del-agente prefiere). Se desarrolla en identidad.

RBAC (role-based access control) — Roles (listas de permisos: Storage Blob Data Reader) asignados a identidades en scopes jerárquicos (management group → suscripción → RG → recurso), con herencia hacia abajo. El modelo de bindings de GCP con nombres Microsoft; se audita hacia arriba, igual.

Role assignment — La tripleta de RBAC: esta identidad, este rol, este scope. El mínimo privilegio se arma con roles built-in en el scope más chico que funcione.

Contributor — El comodín de esta casa (el Editor de GCP, el * de AWS): permisos amplios que nacen “temporales” y mueren nunca. Se caza en auditoría.

Service principal — La identidad de aplicación en Entra para lo que corre fuera de Azure. Su forma moderna usa federación de credenciales (OIDC de GitHub Actions → acceso, sin secretos guardados); su forma vieja — el client secret en un repo — es la llave de larga vida de Azure.

Cómputo

Container Apps — El Cloud Run de Azure: contenedores estándar sin administrar Kubernetes, con revisiones, scale-to-zero y KEDA integrado. Sus dos caras: apps (servicios continuos) y jobs (tareas que corren hasta terminar — manuales, cron o por evento). Se desarrolla en cómputo.

KEDA (Kubernetes Event-Driven Autoscaling) — El escalado por métricas de evento: el consumidor escala por el largo de su cola de Service Bus — cero réplicas con la cola vacía, N en el pico — como configuración, no como código. El regalo de Azure a los agentes; con tope de réplicas alineado a las cuotas de modelo.

Azure Functions — Las funciones cortas por evento. La frontera function-vs-contenedor es de empaque, como en GCP.

Durable Functions — La pieza propia: orquestaciones con estado escritas como código (C#, Python, JS) — el flujo llama actividades, espera eventos externos y duerme días sin facturar, con replay determinista. Sus patrones de fábrica (encadenamiento, fan-out/fan-in, interacción humana con timer de timeout) son el índice del módulo 11. El precio: determinismo en el orquestador — el trabajo va en las actividades.

Logic Apps — El hermano low-code de la orquestación: flujos declarativos con un catálogo enorme de conectores (correo, Teams, SharePoint, SAP) — incluido el conector de aprobaciones que manda el correo con botones. Código vs. conector es decisión de equipo, no de doctrina.

AKS — Kubernetes administrado. Tercera nube, misma regla: razón organizacional o Container Apps.

Redes

VNet — La red virtual, regional como la VPC de AWS (peering y hub-and-spoke del CAF para unir). Subnets, y NSGs (network security groups) como firewall de reglas. Se desarrolla en redes.

Private endpoint — El mecanismo universal de Azure: proyecta un servicio PaaS (base, bucket, modelo, vault) dentro de tu VNet con IP privada, permitiendo negar todo acceso público. En la plataforma madura, cada servicio de datos e IA lleva el suyo — en pareja obligatoria con “acceso público deshabilitado”, exigida por policy.

Zona DNS privada — La pieza que hace funcionar el private endpoint: el nombre del servicio resuelve a la IP privada desde tu red. Su ausencia es el clásico “el endpoint no responde” — es parte del despliegue, no un extra.

Azure Firewall (reglas FQDN) — El filtro de egress por nombre de dominio: “permitir api.crm.com, denegar el resto” escrito literalmente. La lista corta anti-exfiltración de la serie, por fin con nombres legibles — con ruta forzada (UDR) desde la subred del agente para que no sea decorativa.

Integración

Service Bus — La cola enterprise, la más equipada de la serie: queues (cola) y topics con suscripciones filtradas (abanico), DLQ integrada de fábrica, sesiones (orden y afinidad por entidad — la conversación del cliente X procesada en orden), deduplicación por message ID y entrega programada. Cada finura se enciende por una razón del caso; la idempotencia del consumidor sigue siendo ley. Se desarrolla en integración.

Event Grid — El bus de eventos: sucesos de la infraestructura y propios, enrutados por filtros. Enrutador de eventos, no buffer de trabajo — la distinción evento/comando con nombres locales.

Storage Queues — La cola austera y baratísima sin topics ni sesiones. Legítima para volumen bruto sin requisitos; la plataforma de agentes vive mejor en Service Bus.

API Management (APIM) — El portero de APIs con doble vida en Azure: guarda la puerta de entrada (auth, rate limits) y — con sus políticas GenAI (límites de tokens por consumidor, balanceo entre despliegues, registro de uso) — reaparece como gateway semi-administrado de LLMs: el punto medio entre “el servicio es el gateway” y el proxy propio.

Estado y datos

Cosmos DB — La base de sesiones de esta casa: documentos serverless con TTL nativo, multi-modelo y con búsqueda vectorial integrada — la sesión y sus embeddings en el mismo registro. Más versátil que sus pares y por eso más honeypot: TTL, PII y acceso mínimo no se relajan. Se desarrolla en estado y datos.

Azure Database for PostgreSQL — El Postgres administrado con pgvector: la fila relacional y el punto de partida vectorial sano de la serie.

Blob Storage — El S3 de Azure: objetos con puntero, la regla que no envejece.

Azure Managed Redis — El Redis administrado actual de Azure, sucesor de Azure Cache for Redis (cuyos niveles se retiran entre marzo de 2027 y septiembre de 2028): caché caliente y claves de idempotencia. El ElastiCache / Memorystore de esta casa.

Azure AI Search — El buscador administrado con la tríada completa — vectorial + BM25 + híbrida con re-ranking semántico — diseñado como pieza de RAG: es el camino oficial de grounding del stack de agentes de Microsoft y trae ingesta integrada desde Blob. El OpenSearch de esta casa, con ecosistema.

Modelos y agentes

Microsoft Foundry — La plataforma de modelos y agentes (evolución de Azure AI Foundry / Azure OpenAI): el catálogo con OpenAI como primera parte — GPT con contrato, red privada y compliance de Azure — más Claude (GA en Foundry desde mediados de 2026), Llama, Mistral y compañía. El nombre es de noviembre de 2025 (Ignite); antes, Azure AI Foundry. Se desarrolla en el LLM gateway.

Despliegue (deployment) — La unidad de consumo de modelos en Azure: tu instancia nombrada de un modelo, con versión anclada y capacidad TPM asignada. El mejor control de versión y cuota de la serie: el routing apunta a despliegues, el freno vive en ellos.

TPM (tokens per minute) — La capacidad del despliegue en la unidad que importa. El freno de fábrica de Azure: el consumo del agente acotado por construcción — y el tope con el que KEDA debe alinearse.

PTU (provisioned throughput units) — La capacidad dedicada comprada para volumen sostenido. Tercera nube, misma regla: con curva medida, jamás el día uno.

Agent Service — El runtime administrado de Foundry: hilos de conversación persistentes, orquestación de herramientas, content safety en el flujo, identidad y observabilidad conectadas. El AgentCore Runtime / Agent Runtime de esta casa, con más baterías — y la gravedad de suite que exige adoptar por pieza. Se desarrolla en Foundry Agent Service.

Agent Framework — El framework open source de Microsoft para escribir agentes (heredero unificado de Semantic Kernel y AutoGen; 1.0 GA en abril de 2026, .NET y Python). Se evalúa como framework — contra LangGraph y ADK — no como nube: corre donde quieras.

Foundry IQ — La capa de conocimiento/grounding de Foundry, con AI Search debajo. El Knowledge-Bases de esta casa: RAG commodity en días; el RAG-producto sigue siendo tuyo.

Entra Agent ID (GA abril 2026) — Las identidades de agentes como ciudadanos del directorio corporativo: el inventario de agentes donde el CISO ya mira. El fruto concreto de la tesis “la nube dentro del directorio”.

Seguridad y operación

Key Vault — Secretos, llaves y certificados con acceso por managed identity y lectura auditada — detrás de su private endpoint. El patrón del borde de la serie: el agente usa llaves que jamás ve. Se desarrolla en seguridad.

Content Safety — El guardrail declarativo de Azure: filtros de contenido, detección de material protegido, task adherence (uso de herramientas desalineado — pensado para agentes), groundedness detection (el detector de alucinación; en vista previa y solo en inglés) y los Prompt Shields — el detector especializado de inyección directa e indirecta (la que viene en los documentos que el agente lee). La PII no es suya: la detecta y redacta Azure AI Language. Una capa entre seis, como todos sus parientes.

Defender for Cloud — El vigilante empaquetado: postura + amenazas, con un plan específico para cargas de IA (GA mayo 2025: jailbreaks, inyecciones en el tráfico de modelos, credenciales anómalas). La anomalía conductual de una managed identity — la firma del agente comprometido — sin reglas artesanales.

Log Analytics workspace — El destino central de logs y métricas — en la suscripción de seguridad, fuera del alcance del incidente. La caja negra de esta casa, con la ventaja de ser directamente consultable.

KQL (Kusto Query Language) — El lenguaje que interroga todo lo centralizado: logs, trazas, métricas. La distribución de salidas del agente, la tasa de escalada, el cruce por versión — consultas de cinco líneas. El instrumento único de la operación Azure. Se desarrolla en operación autónoma.

Application Insights — El APM de Azure Monitor: trazas distribuidas, mapa de dependencias y eventos custom del agente, con instrumentación casi gratis sobre Container Apps. El más maduro de los tres stacks de observabilidad de la serie.

Action group — El despachador de respuestas: ante la alerta (budget, métrica, log), ejecuta — correo, webhook, Function, runbook. La pieza que convierte presupuestos y alarmas en frenos.

Diagnostic settings — El interruptor que envía los logs de datos de cada servicio (accesos, operaciones) al workspace central. Se activa para lo sensible el día uno — el pariente de los data access logs de GCP.