# El stack empresarial, sin la niebla Curso exprés sobre los sistemas que encuentras dentro de una empresa mid-market de EE. UU. cuando construyes agentes de IA allí, actualizado a octubre de 2026. 42 conceptos (jerarquía de recursos de Azure, Managed Identity, Key Vault, Private Endpoint, Microsoft Foundry, IdP y SSO, OIDC y SAML, app registrations y service principals de Entra ID, permisos delegated vs application, Conditional Access, Entra Agent ID, Okta, SCIM, Cross App Access, virtual warehouses y service users de Snowflake, Cortex, Delta Lake y Unity Catalog de Databricks, Agent Bricks, OneLake y capacities de Microsoft Fabric, data agents, least privilege, security review y más), cada uno con su nombre en inglés, un diagrama y una tarjeta: qué es → ejemplo → inconveniente → relaciones. Una hoja de referencia de una página al final. - **Author:** Fedor Chishchin - **Level:** intermediate - **Reading time:** ~55 minutos de lectura - **Published:** 2026-10-16 - **Source:** https://fedorthinks.com/es/learn/enterprise-stack-express --- ## 1. El mapa Seis nombres de producto, tres trabajos. Antes de cualquier detalle, aprende a qué capa pertenece cada sistema y dónde queda tu proyecto de IA entre ellos. ### El mapa: 42 conceptos en ocho capítulos > Un mapa de metro: primero ves todas las líneas juntas, luego recorres estación por estación. El curso sigue las tres capas. Primero la **nube**: Microsoft Azure, donde se ejecutan tu código y los modelos de la empresa. Luego la **identidad**: Microsoft Entra ID y Okta, que deciden quién puede iniciar sesión y qué puede tocar. Luego los **datos**: Snowflake, Databricks y Microsoft Fabric, donde la empresa guarda sus números de ventas, finanzas y CRM. El último capítulo lo junta todo: cómo un agente de IA obtiene el acceso más pequeño posible, pasa la revisión de seguridad del cliente y no espera tres semanas por un rol. _Diagram: Tres capas, seis sistemas: los capítulos 2–7 los siguen. El capítulo 8 explica cómo tu agente se conecta a todos._ ### Cómo leer este curso > Un pasaporte: los mismos campos para todos, así es fácil compararlos. Cada concepto tiene su **nombre en inglés** (la palabra que escucharás en las reuniones y leerás en la documentación), una imagen de la vida cotidiana, un **diagrama** y una **tarjeta**: _qué es_, _ejemplo_, _inconveniente_ y conceptos _relacionados_. Si conoces Google Cloud, verás la equivalencia una y otra vez: la mayoría de los sistemas empresariales son ideas conocidas con otros nombres. Aquí los nombres de producto cambian seguido (Azure AD pasó a ser Entra ID, Azure AI Foundry pasó a ser Microsoft Foundry, Vector Search pasó a ser AI Search), así que el curso también da el nombre viejo. En el cliente escucharás los dos. ### Enterprise Stack: tres capas, un proyecto en el medio > Un edificio de oficinas: el dueño tiene los pisos (la nube), la recepción de seguridad en el lobby revisa las credenciales (la identidad) y el archivo del sótano guarda todos los registros (los datos). Tu nuevo inquilino, la app de IA, necesita las tres cosas. Toda empresa grande tiene las mismas tres capas. La **nube** es donde se ejecuta el código; en una empresa muy Microsoft, casi siempre Azure. La **identidad** es el directorio de personas de la empresa y la recepción que les permite entrar: Entra ID u Okta. Los **datos** son donde viven los registros de la empresa: Snowflake, Databricks o Fabric, casi siempre uno de los tres. Tu app de IA queda en el medio: los empleados inician sesión con el identity provider de la empresa, la app se ejecuta en la nube de la empresa y lee datos con los mínimos derechos que necesita. En resumen: la nube es _dónde corre el código_, la identidad es _quién entra_, los datos son _qué lee_. _Diagram: Los empleados inician sesión con Entra u Okta; tu app recibe un token, se ejecuta en la nube del cliente y lee de una plataforma de datos._ #### Enterprise Stack (nube · identidad · datos) - **Qué es:** Las tres capas que opera toda empresa grande: una nube, un identity provider y una plataforma de datos. - **Ejemplo:** Una empresa de logística: Azure para el código, Entra ID para iniciar sesión, Snowflake para los datos de ventas. El agente de IA toca las tres. - **Inconveniente:** Cada capa tiene su propio administrador, sus propios tickets y sus propias reglas de seguridad. El acceso suele ser la parte más lenta del proyecto. - **Relaciones:** Los capítulos siguen las capas: **Azure**, **Entra ID / Okta**, **Snowflake / Databricks / Fabric**; todo se encuentra en **Least Privilege**. > **La pregunta de fondo:** "Para cada sistema que toco: ¿es la nube (donde corre mi código), la capa de identidad (quién puede entrar) o la capa de datos (lo que leo)? ¿Y quién es el administrador que necesito desde el primer día?" > Seis nombres de producto son en realidad tres trabajos: la nube ejecuta el código, la identidad decide quién entra y la plataforma de datos guarda los registros de la empresa. Tu agente vive entre ellos. ## 2. Nube: Microsoft Azure Azure es la nube de Microsoft. Si conoces AWS o Google Cloud, ya conoces las ideas. Lo que cambia son los nombres, la estructura estricta de carpetas y cuánto de la seguridad se apoya en identidades en lugar de claves. ### Microsoft Azure: la nube que las empresas eligen «porque todo es Microsoft» > Mudarse a una ciudad nueva donde las tiendas son las mismas pero con otros nombres: el supermercado, la farmacia y la panadería están todos ahí, solo necesitas un mapa nuevo. **Microsoft Azure** es la nube de Microsoft, como AWS (Amazon) o Google Cloud: servidores virtuales, contenedores, bases de datos, almacenamiento de archivos, redes, colas. Y además acceso a modelos (OpenAI, Anthropic y otros) a través de **Microsoft Foundry**. ¿Por qué está en todas partes en las empresas mid-market? Ya le pagan a Microsoft por Office 365, Teams y Outlook, y su personal ya inicia sesión con una cuenta de trabajo de Microsoft. Una segunda nube significaría un contrato nuevo, un sistema de inicio de sesión nuevo, abogados nuevos y una revisión de seguridad nueva. Y para la IA hay una razón más grande: muchas empresas no van a enviar datos al `api.openai.com` público, pero los modelos en Azure se ejecutan dentro de _su_ nube, bajo _su_ contrato y _sus_ reglas de acceso. _Diagram: Los mismos bloques en tres nubes. Un proyecto de Google Cloud ≈ una subscription + resource group de Azure; una service account ≈ una managed identity._ #### Microsoft Azure (la nube de Microsoft) - **Qué es:** La nube pública de Microsoft: cómputo, almacenamiento, redes, bases de datos y modelos de IA. - **Ejemplo:** Una empresa con Office 365 ejecuta su nuevo asistente de IA en Azure, facturado en el mismo contrato con Microsoft y con inicio de sesión con las mismas cuentas de trabajo. - **Inconveniente:** Hay dos tipos de derechos: **Azure RBAC** (sobre los recursos) y los roles de Entra (sobre el directorio) son cosas distintas. Ser Contributor en una subscription no te deja crear una app registration. - **Relaciones:** Se organiza con la **Resource Hierarchy**; el inicio de sesión viene de **Entra ID**; los modelos, de **Microsoft Foundry**. ### Resource Hierarchy: tenant → subscription → resource group > Las muñecas rusas: la empresa contiene carpetas de contratos, cada contrato contiene cajas de proyecto, cada caja contiene las cosas reales. Abres la muñeca grande y todo lo de adentro viene con ella. Azure es estricto con la estructura, y la necesitas desde el primer día porque el acceso y las facturas la siguen. El **tenant** es toda la empresa en el mundo de Microsoft: un directorio de personas y apps que vive en Entra ID. Un **management group** es una carpeta de subscriptions con reglas compartidas (**Azure Policy**, como «recursos solo en East US»). Una **subscription** es un contrato + una factura + un límite de acceso; normalmente hay una para prod y otra para dev. Un **resource group** es una carpeta para cosas que viven y mueren juntas: la app, su base de datos, su vault. Borras el grupo y se va todo lo de adentro. La regla clave: un rol de **Azure RBAC** (quién puede hacer qué) dado en un nivel superior se aplica a todo lo que está debajo. Así que pide un rol en _un_ resource group, no en la subscription. _Diagram: Tenant → management group → subscription → resource group → recurso. Un rol dado arriba baja a todo lo que está debajo._ #### Resource Hierarchy (tenant · subscription · resource group) - **Qué es:** Las carpetas anidadas de Azure: tenant → management group → subscription → resource group → recurso. - **Ejemplo:** Tu acceso como contratista: una cuenta de invitado en su tenant y el rol Contributor solo en `rg-ai-agent-dev`. - **Inconveniente:** Un rol nuevo puede tardar unos 5 minutos (a veces más) en empezar a funcionar. Un 403 justo después de otorgarlo es normal: espera. - **Relaciones:** El nivel superior es el tenant de **Entra ID**; los roles se entregan a una **Managed Identity**, a una persona o a un grupo. ### Dónde corre el código: App Service, Container Apps, AKS, Functions > Formas de ir al trabajo: un autobús con horario (Functions), un taxi que solo llamas (App Service), un auto compartido que manejas tú pero nunca mantienes (Container Apps), tu propio auto con todo su mantenimiento (AKS). Azure tiene cuatro hogares habituales para tu código. **App Service**: «solo sube una web app»; como Heroku, un estilo más antiguo, ejecuta Python, Node, .NET o un contenedor. **Container Apps**: contenedores sin servidores en los que pensar y con autoscaling hasta cero; lo más parecido a Google Cloud Run y, por lo general, la mejor opción para el backend de un agente. **AKS (Azure Kubernetes Service)**: Kubernetes completo, como GKE; elígelo solo si el cliente ya tiene una plataforma de Kubernetes. **Functions**: código que se ejecuta ante un evento (HTTP, temporizador, cola); bueno para tareas en segundo plano como «llegó un archivo: procésalo». _Diagram: De menos que gestionar a más control. Para el backend de un agente, Container Apps suele ser la opción por defecto correcta._ #### Container Apps (App Service · AKS · Functions) - **Qué es:** Los contenedores serverless de Azure: el hogar habitual del backend de un agente de IA. - **Ejemplo:** La API del agente corre como una Container App con su propia managed identity y escala a cero de noche. - **Inconveniente:** Un clúster de AKS o una VM grande olvidados cuestan cientos o miles de dólares al mes. Pon alertas de presupuesto en el resource group y borra los recursos de dev. - **Relaciones:** Obtiene sus derechos con una **Managed Identity**; llega a los servicios mediante **Private Endpoints**. ### Managed Identity: una cuenta para tu app, sin ninguna contraseña > Una tarjeta llave de hotel que la recepción te programa cada mañana: nunca tienes una llave maestra, solo abre tus habitaciones y deja de funcionar sola. Una **managed identity** es una cuenta para tu aplicación que Azure crea y cuida por sí mismo. No hay contraseña ni archivo de clave: tu código simplemente le pide un token a Azure. En la práctica llamas a `DefaultAzureCredential()`: en tu laptop usa tu `az login`; dentro de una Container App obtiene de Entra ID un token de vida corta (dura cerca de una hora) a través de un endpoint local. Luego le das a esa identidad exactamente los roles que necesita, como **Cognitive Services OpenAI User** en el recurso de Foundry. Es la versión de Azure de una service account de Google Cloud, pero sin las claves JSON. Hay dos tipos: la **system-assigned** vive y muere con un recurso; la **user-assigned** es un objeto aparte que puedes asignar a varios recursos. _Diagram: La Container App le pide un token a Entra, recibe uno que dura cerca de una hora y llama al modelo con él. No existe ninguna clave que se pueda filtrar._ #### Managed Identity (system- o user-assigned) - **Qué es:** Una cuenta para una app gestionada por Azure: obtiene tokens de Entra ID y nunca tiene contraseña. - **Ejemplo:** El agente llama al modelo con un token de `DefaultAzureCredential()`: ninguna API key en el código ni en la configuración. - **Inconveniente:** Desde octubre de 2025 Microsoft está activando MFA obligatorio para los cambios hechos como usuario desde CLI, SDK y Terraform. Automatiza con una managed identity o una workload identity, no con tu cuenta personal. - **Relaciones:** Un tipo especial de **Service Principal**; lee secretos de **Key Vault**; CI usa workload identity federation (OIDC) del mismo modo. ### Key Vault: la caja fuerte de los secretos > Una caja de seguridad en el banco: los objetos de valor no quedan en un cajón de la oficina, y solo las personas de la lista pueden abrir la caja, con cada visita anotada. A veces sí necesitas un secreto: por ejemplo, una API key del CRM del cliente o una clave privada de Snowflake. **Key Vault** es la caja fuerte de Azure para secretos, claves y certificados, como Secret Manager en Google Cloud. La app lee un secreto con su managed identity, que tiene el rol **Key Vault Secrets User** en ese vault. Nada queda en `config.yaml` ni en un archivo `.env` en git. Es la respuesta que el equipo de seguridad quiere escuchar a «¿dónde están tus secretos?». _Diagram: Antes: contraseñas en archivos de configuración. Después: el agente lee cada secreto de Key Vault con su propia identidad y un rol acotado._ #### Key Vault (secretos · claves · certificados) - **Qué es:** El almacén gestionado de Azure para secretos, claves y certificados. - **Ejemplo:** Al arrancar, el agente obtiene de Key Vault la clave del CRM y la clave privada de Snowflake. - **Inconveniente:** Un vault cerrado con un private endpoint es inalcanzable desde tu laptop: planifica un camino para dev. - **Relaciones:** Se lee mediante una **Managed Identity**; a menudo está escondido detrás de un **Private Endpoint**. ### Private Endpoint: servicios sin puerta a internet > Un edificio de oficinas donde el archivo no tiene ninguna entrada desde la calle: solo puedes llegar por el pasillo interior, después de que el lobby te deje pasar. Una **VNet (Virtual Network)** es la red privada del cliente en Azure, como una VPC en Google Cloud. Un **private endpoint** le da a un servicio (Key Vault, Foundry, Postgres) una dirección IP privada dentro de esa VNet. Después de eso, el servicio se puede cerrar por completo a internet (`publicNetworkAccess: Disabled`). A la seguridad corporativa le encanta, y en las empresas mid-market muchas veces es obligatorio. El precio lo pagas tú: tu código local ya no puede llegar a un servicio cerrado. Necesitarás una VPN, un jump box o un entorno de dev dentro de la VNet, y un **private DNS** bien configurado, la fuente clásica de «¿por qué no resuelve este nombre?». _Diagram: Dentro de la VNet, el agente llega a cada servicio por una IP privada. Internet, y tu laptop, no pueden entrar._ #### Private Endpoint (VNet · private link) - **Qué es:** Una IP privada para un servicio en la nube dentro de la red del cliente, para poder cerrarlo a internet. - **Ejemplo:** Foundry, Key Vault y Postgres reciben cada uno una dirección como `10.0.1.4`; el acceso público está desactivado. - **Inconveniente:** Rompe el acceso desde tu laptop y necesita private DNS. Planifica el camino de dev antes del primer deploy. - **Relaciones:** Una de las primeras preguntas de la **Security Review**; el primo en Google Cloud es Private Service Connect. ### Microsoft Foundry: modelos dentro del tenant del cliente > Un comedor de empresa a cargo de un servicio de catering externo: la comida es la misma que en el restaurante del catering, pero se cocina en tu edificio, con tus reglas y bajo tu contrato. **Microsoft Foundry** es la plataforma de IA de Azure. El nombre cambió muchas veces: Azure AI Studio (2023) → Azure AI Foundry (2024) → **Microsoft Foundry** (desde fines de 2025), y Azure OpenAI ahora es parte de «Foundry Models». En un solo lugar creas un **model deployment**: tu copia con nombre de un modelo (por ejemplo `gpt-4o-contracts`) con su propia **quota**: **TPM** (tokens por minuto) o **PTU** (capacidad comprada por adelantado). Construyes agentes en **Foundry Agent Service** con herramientas y MCP, y tienes evaluaciones, filtros de contenido y trazas. Los endpoints y las claves viejos de Azure OpenAI en general siguen funcionando. El scope de token actual es `https://ai.azure.com/.default`; los ejemplos más viejos usan `https://cognitiveservices.azure.com/.default`. _Diagram: Tu código llama a un deployment por su nombre; Foundry también aloja agentes, evaluaciones y seguridad de contenido. Tres nombres en tres años._ #### Microsoft Foundry (antes Azure AI Foundry · Azure OpenAI) - **Qué es:** La plataforma de Azure para modelos (incluido Azure OpenAI), agentes y evaluaciones. - **Ejemplo:** `model="gpt-4o-contracts"`: el campo lleva el nombre del deployment, no el del modelo. - **Inconveniente:** Puede que el modelo que necesitas no exista en la región del cliente, o que su quota de TPM sea demasiado chica. Revísalo antes de empezar, no el día de la demo. Un 404 muchas veces significa un nombre de deployment equivocado. - **Relaciones:** Se llama con un token de **Managed Identity**, a través de un **Private Endpoint**; el primo en Google Cloud es Vertex AI, y en AWS, Bedrock. > **La pregunta de la nube:** "¿Mi agente corre con una managed identity, con roles solo en un resource group, secretos en Key Vault y servicios detrás de private endpoints? ¿Y revisé la quota del modelo en su región?" > Azure es una nube conocida con carpetas más estrictas. Pide un solo resource group, dale a tu app una managed identity en lugar de claves, guarda los secretos en Key Vault y revisa la quota del modelo el primer día. ## 3. Identidad: SSO y Entra ID Tu app no debería revisar contraseñas. La empresa ya tiene una recepción que conoce a cada empleado. Este capítulo cubre las palabras comunes (IdP, SSO, OIDC) y luego la recepción de Microsoft, Entra ID, donde vive la mayor parte de la confusión. ### Identity Provider y SSO: una sola recepción para todas las apps > La recepción de seguridad de un centro de negocios: el guardia conoce a todos por su credencial. Las oficinas de arriba no revisan pasaportes por su cuenta: confían en la credencial del lobby. Un **identity provider (IdP)** es el sistema que confirma «esta es Anna y está en Ventas». Entra ID, Okta y Google son IdPs. **SSO (Single Sign-On)** es lo que sienten las personas: inician sesión una vez con su cuenta de trabajo y luego entran a todas las apps (Outlook, Salesforce, Jira, tu agente) sin contraseñas nuevas. Antes de esto, cada app tenía su propio login: quince contraseñas por persona, la mitad en notas adhesivas, los nuevos empleados esperando una semana por sus cuentas y gente que ya se había ido todavía podía abrir el CRM seis meses después. Con un IdP, TI desactiva una cuenta y el acceso desaparece en todas partes, y hay un solo registro de quién inició sesión dónde. _Diagram: El empleado inicia sesión una vez en el identity provider; todas las apps, incluida la tuya, confían en ese inicio de sesión._ #### Identity Provider (IdP · SSO) - **Qué es:** El servicio de inicio de sesión de la empresa; con él, una sola cuenta de trabajo abre todas las apps (SSO). - **Ejemplo:** El agente interno no tiene formulario de login: «Iniciar sesión» manda a las personas al Entra ID o al Okta del cliente. - **Inconveniente:** No lo controlas tú. Cada cambio en cómo inicia sesión tu app pasa por el equipo de TI del cliente. - **Relaciones:** Habla **OIDC o SAML**; los dos grandes son **Entra ID** y **Okta**. ### OIDC y SAML: cómo la app le pregunta a la recepción > Dos formas de probar que eres un invitado: un código QR en tu teléfono que la puerta escanea en un segundo (OIDC), o una carta en papel sellada por el anfitrión que el guardia lee línea por línea (SAML). Dos estándares le permiten a tu app «preguntarle a la recepción». **OAuth 2.0** es cómo obtienes un access token para llamar a una API. **OIDC (OpenID Connect)** se apoya en OAuth para el inicio de sesión: añade un **ID token**, un JWT que dice quién es la persona. Para una web app nueva, OIDC es la opción por defecto. **SAML** es el estándar XML más antiguo, todavía común en el SaaS corporativo; úsalo cuando el cliente insista. El flujo OIDC habitual es **authorization code + PKCE**: rediriges al IdP, la persona inicia sesión (con MFA), el IdP devuelve un código de un solo uso y tu backend lo cambia por tokens. Luego verificas el ID token: la firma (claves desde JWKS), `iss`, `aud`, la expiración y el `nonce`. Para trabajo en segundo plano sin una persona, está el flujo **client credentials**; cuando tu API llama a otra API en nombre del usuario, está **on-behalf-of (OBO)**. _Diagram: Authorization code + PKCE: el navegador va al IdP y vuelve con un código; el backend cambia el código por tokens y los verifica._ #### OIDC and SAML (OAuth 2.0 · auth code + PKCE) - **Qué es:** Los estándares que usa tu app para que las personas inicien sesión a través del IdP. OIDC es lo moderno, en JSON/JWT; SAML es el XML más antiguo. - **Ejemplo:** El mismo flujo de código más PKCE que conoces de «Iniciar sesión con Google», apuntando a `login.microsoftonline.com/` o a `acme.okta.com`. - **Inconveniente:** Nunca uses el email como clave del usuario: cambia. Usa el ID estable: `oid` + `tid` en Entra, `sub` en Okta. - **Relaciones:** El IdP detrás es **Entra ID** u **Okta**; la app con la que habla es una **App Registration**. ### Microsoft Entra ID: el directorio de la empresa en la nube > Una guía del personal de la empresa cruzada con un armario de llaves: lista a cada persona y cada grupo, y reparte las llaves. **Microsoft Entra ID** (llamado **Azure AD** hasta 2023) es el directorio en la nube de Microsoft con las personas y apps de una empresa, más su servidor de inicio de sesión. El **tenant** es el directorio de una organización: tiene un ID (un GUID) y dominios como `contoso.com`. Adentro hay **users** (empleados y **guests**: tú, el contratista, normalmente entras como invitado B2B con tu propio email), **groups** (grupos de seguridad para los derechos; pueden ser estáticos o dinámicos, como «todos con department = Sales») y **apps**. Muchas empresas todavía usan el viejo **Active Directory** on-premises y lo sincronizan con Entra mediante **Entra Connect**. La regla para tu app: da derechos a grupos, no a personas. TI agrega a alguien a un grupo, esa persona obtiene acceso y tú nunca tocas el código. _Diagram: Un tenant contiene users (incluidos los guests), groups y apps. El viejo AD on-prem muchas veces se sincroniza con él._ #### Microsoft Entra ID (antes Azure AD) - **Qué es:** El directorio en la nube y el identity provider de Microsoft para empleados, grupos y apps. - **Ejemplo:** El agente de contratos solo deja entrar a los miembros del grupo `AI-Agent-Users` del tenant `contoso.com`. - **Inconveniente:** Para una app interna, usa el tenant ID del cliente, no `/common`, que deja entrar a cualquier organización y a cuentas personales, y verifica `tid` en el token. - **Relaciones:** Las apps viven aquí como **App Registrations** y **Service Principals**; el acceso lo definen los **App Roles** y **Conditional Access**. ### App Registration vs Service Principal: el pasaporte y la visa > Un pasaporte y una visa: el pasaporte (la registration) dice quién eres, una sola vez. La visa (el service principal) la emite cada país al que entras, y es la visa la que dice qué puedes hacer allí. Este es el par que todos confunden. Una **app registration** es el pasaporte de tu app: su **client ID** (público, no es un secreto), su **redirect URI** (adónde mandar a la persona después de iniciar sesión; tiene que coincidir exactamente), sus credenciales, los permisos que pide y los roles que declara. Un **service principal** es la instancia de la app dentro de un tenant concreto; en el portal se llama **Enterprise application**. Los derechos se otorgan al service principal, las personas se le asignan y Conditional Access se le aplica. Una registration puede tener service principals en muchos tenants: así funcionan los productos SaaS. Una **managed identity** también es un service principal, solo que sin un pasaporte que tengas que gestionar. Sobre las credenciales: un **client secret** expira (como máximo a los dos años, muchas veces a los 6–12 meses por política); un certificado es mejor; una **federated credential** es lo mejor, porque no hay nada que expire. _Diagram: La registration es el plano, se hace una vez. Cada tenant que usa la app recibe su propio service principal, y es ese el que tiene los derechos._ #### App Registration vs Service Principal (Enterprise application) - **Qué es:** Registration = la definición de la app (client ID, redirect URI, permisos, roles). Service principal = su copia en un tenant, la que recibe los derechos. - **Ejemplo:** «Contract Assistant»: registration single-tenant, redirect URI `https://agent.contoso.com/auth/callback` y una federated credential en lugar de un secreto. - **Inconveniente:** Probablemente no puedas crear la registration ni otorgar el admin consent tú mismo: eso lo hace un Application Administrator. Manda la lista exacta desde el principio; ahorra semanas. - **Relaciones:** Pide **Delegated or Application Permissions**; declara **App Roles**; una **Managed Identity** también es un service principal. ### Delegated vs Application Permissions: como el usuario o como sí misma > Un asistente personal con la llave de tu oficina abre solo tus puertas. Un guardia nocturno con la llave maestra abre todas las puertas del edificio: útil para las rondas, peligroso en malas manos. Hay dos tipos de derechos para llamar a las APIs de Microsoft. **Delegated permissions** (scopes): la app actúa _en nombre del usuario que inició sesión_ y ve solo lo que ese usuario ve: `User.Read`, `Files.Read`. En el token aparecen en el claim `scp`. **Application permissions**: la app actúa _por sí misma_, sin usuario, para trabajo en segundo plano: `Sites.Read.All` lee todos los sitios de SharePoint. Es muy poderoso y siempre necesita **admin consent**. El **consent** es la aprobación: «sí, esta app puede leer mi perfil». Un usuario puede aprobar derechos comunes si la empresa lo permite; los derechos fuertes solo los aprueba un administrador. Muchas empresas desactivan por completo el consent de usuarios, y de ahí la pantalla más común en el primer inicio de sesión: **«Need admin approval»**. _Diagram: Delegated: el agente ve solo los archivos de Anna. Application: ve todos los sitios, y necesita que un administrador lo apruebe._ #### Delegated vs Application Permissions (scopes · consent · admin consent) - **Qué es:** Delegated = actuar como el usuario que inició sesión, dentro de sus derechos. Application = actuar como la propia app, sobre todo lo otorgado. - **Ejemplo:** Un agente de preguntas y respuestas sobre SharePoint usa `Sites.Read.All` delegated, así SharePoint aplica automáticamente los derechos de cada usuario. - **Inconveniente:** Las application permissions se saltan los derechos de las personas. Con `Sites.Read.All` como application, un agente que responde a empleados puede mostrarle fácilmente a alguien un documento que no debería ver. - **Relaciones:** El corazón de **As the User vs As Itself**; la primera pregunta de la **Security Review**. ### App Roles: tus propios roles, asignados por su TI > Las pulseras de colores en un festival: el organizador decide qué abre la pulsera azul, la taquilla reparte las pulseras y la puerta solo mira el color. Los **app roles** son roles que declaras en tu app registration, por ejemplo `Agent.User` y `Agent.Admin`. El equipo de TI del cliente los asigna a grupos. Cuando alguien inicia sesión, sus roles llegan en el claim `roles` del token y tu backend los revisa: sin `Agent.User` → 403. Activa **«Assignment required»** y quienes no estén asignados ni siquiera podrán iniciar sesión. ¿Por qué no leer simplemente los grupos del token? Por el **groups overage**: si un usuario está en demasiados grupos (más de 200 en un JWT), los grupos no llegan en el token; en su lugar recibes un enlace a Graph. Los app roles evitan eso y dejan el control en manos del cliente: TI mueve a las personas entre grupos y tú nunca tocas el código. _Diagram: Tú declaras los roles, TI los asigna a grupos, llegan en el token y tu backend los revisa._ #### App Roles (roles claim · assignment required) - **Qué es:** Roles declarados por tu app, asignados a grupos por el equipo de TI del cliente y entregados en el token. - **Ejemplo:** `if "Agent.User" not in claims.get("roles", []): abort(403)`; Finanzas recibe `Agent.Admin` a través de su grupo. - **Inconveniente:** Si te apoyas en el claim de grupos, falla para las personas que están en más de 200 grupos: los grupos simplemente no vienen en el token. - **Relaciones:** Se declaran en la **App Registration**; el equivalente en Okta es un groups claim filtrado. ### Conditional Access: reglas en la puerta > El portero de un club con una lista de reglas: los socios pasan, los invitados muestran su documento, nadie entra con zapatillas. Se revisa en la puerta cada vez. **Conditional Access** es un conjunto de reglas «si… entonces» que Entra revisa en cada inicio de sesión: _si_ alguien del grupo de Finanzas abre la app X desde un dispositivo no gestionado, _entonces_ pide MFA, o bloquea. Las condiciones pueden incluir el usuario o el grupo, la app, el dispositivo, la ubicación y el riesgo del inicio de sesión. **MFA** es el segundo factor: un push en Microsoft Authenticator, una llave FIDO2, una passkey. Conditional Access necesita una licencia **Entra ID P1** o superior; los tenants chicos sin P1 pueden tener solo **security defaults** (MFA para todos). El acceso basado en riesgo y PIM necesitan P2, y Conditional Access para service principals necesita una licencia aparte de Workload Identities. «No tenemos esa función» muchas veces significa «no tenemos esa licencia». _Diagram: En cada inicio de sesión Entra revisa quién, qué app, qué dispositivo, desde dónde y con qué riesgo; luego permite, pide MFA o bloquea._ #### Conditional Access (MFA · security defaults) - **Qué es:** Reglas de inicio de sesión en Entra ID: condiciones (quién, app, dispositivo, lugar, riesgo) → acción (permitir, MFA, bloquear). - **Ejemplo:** El agente de contratos queda automáticamente bajo la política de la empresa «MFA más dispositivo gestionado». - **Inconveniente:** «Solo dispositivos gestionados» puede bloquear tus pruebas, tu CI y tu propia laptop. Acuerda las excepciones temprano y verifica que el entorno de dev no quede bloqueado. - **Relaciones:** Se aplica al **Service Principal**; la versión de Okta son las authentication policies. ### Microsoft Graph: una API para todo Microsoft 365 > La central telefónica de un edificio: un solo número te conecta con cualquier oficina (correspondencia, agenda, archivo) en lugar de una línea aparte para cada una. **Microsoft Graph** es una gran API para todo lo que hay en Microsoft 365: usuarios, grupos, correo, calendarios, Teams, archivos en OneDrive y SharePoint. La dirección es `https://graph.microsoft.com/v1.0/…`. Para un agente de IA es la puerta principal a los documentos del cliente: «busca el contrato 42 en SharePoint», «agenda una reunión». Con un token delegated, Graph devuelve solo lo que el usuario que inició sesión puede ver, así que la herramienta de búsqueda del agente hereda gratis los permisos de SharePoint. La vieja API de Azure AD Graph está apagada; solo queda Microsoft Graph. La librería oficial para el inicio de sesión y los tokens es **MSAL** (Python, JS, .NET y más). _Diagram: El agente llama a un solo endpoint, graph.microsoft.com, y llega a usuarios, correo, calendarios, Teams y archivos, dentro de sus scopes._ #### Microsoft Graph (graph.microsoft.com · MSAL) - **Qué es:** La única API REST para los datos de Microsoft 365. - **Ejemplo:** La herramienta de búsqueda del agente llama a `POST /v1.0/search/query` con el access token del usuario y recibe solo los documentos que ese usuario puede abrir. - **Inconveniente:** Lo que devuelve Graph está limitado por los scopes del token. Pide muy poco y las llamadas fallan; pide demasiado y la security review se traba. - **Relaciones:** Se llama con **Delegated or Application Permissions**; el token viene del inicio de sesión con **OIDC**. ### Entra Agent ID: una identidad hecha para agentes de IA > Una credencial de empleado para un robot: tiene su propia foto, su propia lista de accesos, aparece en el registro de visitas y seguridad puede desactivarla en la recepción como la de cualquiera. En 2026 Entra incorporó un tipo de identidad aparte para los agentes de IA: **Agent ID** (disponible de forma general desde abril de 2026). Un agente recibe su propia identidad, creada a partir de una plantilla, un **agent identity blueprint**, y TI la gestiona como a un empleado: permisos, Conditional Access, registros de inicio de sesión, desactivarla. Responde una pregunta que los equipos de seguridad hacen cada vez más: «¿cómo sabemos qué agentes existen y qué pueden hacer?». Es nuevo, así que vale la pena conocer la palabra y preguntarle al cliente si lo usa. _Diagram: Los agentes se crean a partir de un blueprint, cada uno con su propia identidad, y TI los controla como cuentas del personal._ #### Entra Agent ID (agent identity blueprint) - **Qué es:** Un tipo de identidad de Entra de primera clase para agentes de IA, creado a partir de un blueprint y gobernado como un usuario. - **Ejemplo:** El agente de contratos y el agente de ventas reciben cada uno su propio Agent ID, con derechos y registros separados. - **Inconveniente:** Es nuevo en 2026: muchos tenants mid-market todavía no lo adoptaron. Pregunta, no lo des por hecho. - **Relaciones:** El equivalente en Okta es **Cross App Access** con Agent SSO; los dos sirven a **Least Privilege**. > **La pregunta de la identidad:** "¿Mi app hace que las personas inicien sesión con OIDC a través del tenant del cliente, usa el ID estable del usuario, revisa los app roles y actúa con delegated permissions siempre que le responde a una persona?" > Entra ID es el directorio y la recepción de la empresa. Registra la app, deja que TI asigne los app roles a grupos, prefiere delegated permissions y mándale a TI una sola lista precisa para que el admin consent sea rápido. ## 4. Identidad: Okta Okta hace el mismo trabajo que Entra ID, pero es una empresa independiente. Gana donde el cliente usa una mezcla de herramientas y Microsoft no es el centro. Los estándares son los mismos; cambian las palabras y la consola de administración. ### Okta Workforce Identity: la recepción neutral > Una recepción a cargo de una empresa de seguridad independiente en lugar del dueño del edificio: trabaja con todos los inquilinos, sin importar la marca de cerradura que use cada oficina. **Okta Workforce Identity** es el producto de Okta para empleados: conoce a cada persona de la empresa y decide quién puede iniciar sesión dónde. Las personas inician sesión una vez y entran a Slack, Salesforce, Jira, AWS y tu app. Las empresas lo eligen cuando tienen un «zoológico» (Google Workspace, AWS, Slack, Salesforce, Macs) y Microsoft no es el proveedor principal; su catálogo, la **Okta Integration Network (OIN)**, tiene más de 8.000 integraciones listas. Cada empresa tiene una **org** con una dirección como `acme.okta.com`: la versión de Okta de un tenant. Normalmente hay una org de producción y una **preview org** (en `oktapreview.com`): pide primero acceso a la de preview. **Universal Directory** guarda personas (con campos como departamento y jefe), grupos y ahora también agentes de IA; los datos suelen llegar desde el sistema de RR. HH.: «RR. HH. es la fuente de verdad». No confundas Okta con **Auth0**: es la misma empresa, pero Auth0 es para que los _clientes_ de una empresa inicien sesión en su producto; Okta Workforce es para los _empleados_. _Diagram: Las personas llegan desde RR. HH. y AD; la org de Okta guarda el directorio, las políticas, los servidores de tokens y el ciclo de vida; las apps, y tu agente, confían en ella._ #### Okta (Workforce Identity · org · Universal Directory) - **Qué es:** Un identity provider en la nube, independiente, para empleados: directorio, SSO, MFA, provisioning. - **Ejemplo:** El agente es una app integration OIDC en `acme.okta.com`, asignada al grupo `AI-Agent-Users`. - **Inconveniente:** Por defecto, los grupos no se ponen en el token. Necesitas un groups claim con filtro (por ejemplo «empieza con AI-Agent-»): «todos los grupos» infla el JWT y rompe headers y cookies. - **Relaciones:** Los mismos estándares que **Entra ID** (**OIDC and SAML**); provisioning con **SCIM**; tokens de los **Authorization Servers**. ### SCIM: altas, cambios y bajas, de forma automática > Cuando el nombre de un nuevo empleado entra en la lista de RR. HH., el primer día aparecen una credencial, un escritorio y un casillero; cuando se va, la credencial deja de funcionar esa misma tarde, sin que nadie tenga que acordarse. **SCIM** es una API REST estándar para crear, actualizar y desactivar usuarios en una app. El IdP (Okta o Entra) es el cliente SCIM; tu app es el servidor SCIM, con los endpoints `/Users` y `/Groups`. El **lifecycle management** cubre los tres momentos: **joiner** (a alguien se le asigna la app → `POST /scim/v2/Users`), **mover** (cambia de equipo → se actualizan los grupos), **leaver** (se va → `PATCH` con `active=false`: la cuenta se desactiva, no se borra). Sin SCIM, los usuarios aparecen en tu base de datos solo en su primer inicio de sesión (**just-in-time**), y nadie elimina a quienes se fueron: «almas muertas» con su historial de chat y sus ajustes. _Diagram: RR. HH. cambia algo y el IdP llama a tu endpoint SCIM: crear al entrar, actualizar al moverse, desactivar al irse._ #### SCIM (provisioning · joiner–mover–leaver) - **Qué es:** Una API estándar con la que el IdP crea, actualiza y desactiva usuarios en tu app. - **Ejemplo:** Alguien se va el viernes; Okta manda `PATCH active=false` y su cuenta en el agente queda desactivada ese mismo día. - **Inconveniente:** Solo importa si tu app guarda sus propios registros de usuarios. Si lo hace y te saltas SCIM, tendrás cuentas que sobreviven a sus dueños. - **Relaciones:** Lo impulsa **Okta** o **Entra ID**; va en pareja con tokens de vida corta para revocar rápido. ### Authorization Servers: org o custom > Un edificio tiene un pase estándar que abre las puertas principales, pero un laboratorio con reglas especiales imprime sus propios pases con sus propios sellos. Mostrar el pase estándar en la puerta del laboratorio no sirve. La parte de Okta que emite tokens es un **authorization server**, y hay dos tipos. El **org authorization server** viene incluido, con issuer `https://acme.okta.com`; sirve para el inicio de sesión común y para llamar a la propia API de Okta, pero no puedes agregarle tus propios scopes. Un **custom authorization server** (con un issuer como `https://acme.okta.com/oauth2/default`) protege _tus_ APIs: tus scopes como `agent.read` y `agent.tickets.write`, tus claims, tus políticas, machine-to-machine. Necesita la suscripción paga **API Access Management**, y puede que el cliente no la tenga. El error clásico: validar en tu propia API un token del org server como si fuera tu access token. Si construyes una API, necesitas un custom server. Averigua primero el issuer. _Diagram: El org server se encarga del inicio de sesión y de la propia API de Okta; un custom server emite tokens con tus scopes para tu API._ #### Authorization Server (org vs custom · issuer) - **Qué es:** El emisor de tokens de Okta. Org = incluido, para SSO; custom = tus scopes y claims, para tus APIs. - **Ejemplo:** El backend verifica los tokens contra el issuer `…/oauth2/default`, el audience `api://ai-agent` y las claves de `/v1/keys`. - **Inconveniente:** Si los mezclas, falla la verificación de `aud` o no puedes agregar un scope. Para llamar a la API de Okta, usa una OAuth service app, no un token SSWS estático, que se rompe cuando se va su administrador. - **Relaciones:** Emite los tokens de **OIDC**; los agentes pueden llegar a otras apps mediante **Cross App Access**. ### Cross App Access y Agent SSO: agentes que no acumulan tokens > En lugar de que cada asistente cargue un llavero con copias de las llaves de todas las oficinas, la recepción entrega un pase de visita corto para cada visita, y anota cada visita en el libro. El problema nuevo: un agente en la app A quiere datos de la app B en nombre del usuario. A la manera vieja, cada usuario hace clic en «conecta tu Jira» en cada app, el agente guarda esos tokens y TI no puede ver ninguno de esos vínculos. **Cross App Access (XAA)** es un protocolo abierto, construido sobre el borrador de la IETF **ID-JAG** (Identity Assertion JWT Authorization Grant): el agente le pregunta a Okta, Okta revisa la política y emite un token corto para la app B, y Okta ve y registra cada uno de esos vínculos. XAA fue aceptado como extensión Enterprise-Managed Authorization para MCP; entre los socios están Slack, Atlassian, Zoom, Asana, Datadog, Cloudflare y Claude. **Agent SSO** (disponible de forma general desde el 24 de agosto de 2026, incluido sin costo extra en el SSO estándar de Okta) registra un agente compatible con XAA como identidad propia en Universal Directory, junto a las personas, con tokens de vida corta en lugar de API keys estáticas. Más allá de eso, **Okta for AI Agents** es una suscripción paga aparte para descubrimiento y gobierno. Del lado de los clientes, **Auth0 for AI Agents** (GA desde noviembre de 2025) ofrece un Token Vault, aprobación asíncrona por parte de una persona y acceso de grano fino para RAG. _Diagram: A la manera vieja: los usuarios conectan cada app y el agente guarda los tokens. Con XAA: el agente le pregunta a Okta, recibe un token corto como el usuario y Okta lo registra._ #### Cross App Access (XAA · ID-JAG · Agent SSO) - **Qué es:** Una forma, con Okta como intermediario, de que un agente en una app obtenga un token corto y registrado para otra app, como el usuario. - **Ejemplo:** Un agente de ventas crea tickets de Jira mediante XAA: no hay nada que guardar y TI ve el vínculo en Okta. - **Inconveniente:** Solo funciona si tanto la app del agente como la app del recurso lo soportan. Muchos clientes mid-market no lo tendrán activado: mantén OAuth simple con scopes mínimos como plan B. - **Relaciones:** El equivalente de Microsoft es **Entra Agent ID**; es **As the User**, hecho de forma centralizada. > **La pregunta de Okta:** "¿Conozco el issuer y sé qué authorization server es? ¿El groups claim está filtrado? ¿Necesito SCIM? ¿Y puede mi agente usar Cross App Access en lugar de guardar tokens?" > Okta es la recepción neutral: el mismo OIDC que ya conoces, más SCIM para altas y bajas, dos tipos de servidores de tokens y ahora Cross App Access, para que los agentes dejen de acumular tokens. ## 5. Datos: Snowflake ¿Dónde guarda la empresa sus números? Primero, las tres formas que puede tomar el almacenamiento de datos. Luego Snowflake: el warehouse SQL donde el almacenamiento y el cómputo están separados y pagas por segundo. ### Warehouse, Lake, Lakehouse: tres formas de guardar los datos de la empresa > Una biblioteca, un garaje y un archivo moderno. La biblioteca tiene estantes estrictos y un catálogo, pero solo acepta libros terminados. El garaje acepta cualquier cosa, pero encontrar algo es una pesadilla. El archivo guarda todo en cajas baratas, con un catálogo encima. Un **data warehouse** es una base de datos hecha para el análisis, no para hacer funcionar una app: tablas grandes y estrictas y consultas pesadas como «ventas por región en tres años», en SQL. Rápido y confiable, pero más caro, y solo entra la parte limpia de los datos. Un **data lake** son simplemente carpetas de archivos en almacenamiento en la nube (S3, ADLS, GCS): logs, exportaciones del CRM, CSV, JSON, imágenes. Barato y enorme, pero sin orden: no hay transacciones, los archivos se rompen con escrituras concurrentes y nadie sabe qué versión es la correcta. Durante años las empresas usaron los dos y copiaron datos de un lado a otro: dos copias, dos juegos de derechos, reportes que no coincidían con los modelos. Un **lakehouse** (lake + warehouse) guarda los datos una sola vez en almacenamiento barato, en un formato de tabla que añade transacciones, esquema e historial, para que SQL, Spark y ML trabajen todos sobre las mismas tablas. _Diagram: Warehouse: estricto y limpio. Lake: barato y desordenado. Lakehouse: archivos una sola vez, con reglas de tabla encima. Snowflake empezó como lo primero; Databricks y Fabric son lo tercero._ #### Warehouse · Lake · Lakehouse (data warehouse · data lake) - **Qué es:** Tres formas de almacenamiento: tablas SQL estrictas, archivos en bruto de cualquier tipo, o archivos con un formato de tabla encima. - **Ejemplo:** Los reportes de finanzas viven en un warehouse; los logs de la app caen en un lake; un lakehouse sirve a ambos desde una sola copia. - **Inconveniente:** Hoy Snowflake, Databricks y Fabric hacen casi de todo y compiten fuerte: las etiquetas describen dónde empezó cada uno. - **Relaciones:** **Snowflake** (raíces de warehouse), **Databricks** y **Microsoft Fabric** (lakehouse sobre **Delta Lake**). ### Snowflake: el almacenamiento en un lugar, el cómputo a demanda > Un depósito enorme de mercadería con cuadrillas de cargadores separadas que contratas por minuto. ¿Lo necesitas más rápido? Llamas a una cuadrilla más grande. ¿Nadie trabaja? Nadie cobra. **Snowflake** es una base de datos en la nube para analítica. La empresa vuelca sus datos (ventas, CRM, inventario, finanzas) y cada departamento los consulta en SQL simple. Los servidores, discos, índices y backups son trabajo de Snowflake. La gran idea es que **el almacenamiento está separado del cómputo**: una sola copia de los datos, y cada equipo tiene su propio clúster de cómputo que no frena a los demás. Hay tres capas: **cloud services** (el cerebro: inicio de sesión y roles, metadatos, optimizador de consultas, caché de resultados), **compute** (virtual warehouses, pagados en créditos) y **storage** (datos en columnas en micro-partitions, pagados por TB al mes). Snowflake corre sobre AWS, Azure o GCP: el cliente elige la nube y la región. Tu **account** tiene un identificador como `myorg-myaccount`; la consola web es **Snowsight**. De regalo: **Time Travel** lee una tabla «como estaba ayer» (1 día por defecto, hasta 90 en Enterprise), y **zero-copy clone** crea una base de datos de dev a partir de prod en segundos. _Diagram: Tres capas: el cerebro arriba, clústeres de cómputo separados por equipo en el medio, una sola copia compartida de los datos abajo._ #### Snowflake (cloud data warehouse) - **Qué es:** Una plataforma de analítica SQL donde el almacenamiento y el cómputo están separados y el cómputo se cobra por uso. - **Ejemplo:** Las consultas del agente corren en su propio clúster chico, así los dashboards del equipo de BI no se ponen lentos. - **Inconveniente:** Los nombres sin comillas se vuelven MAYÚSCULAS: `"orders"` entre comillas y `orders` son tablas distintas. Y usa el nuevo identificador `org-account`, no el viejo formato de locator. - **Relaciones:** El cómputo es un **Virtual Warehouse**; el acceso son **Roles and RBAC**; la IA es **Cortex**. ### Virtual Warehouse: un clúster de cómputo, no un depósito > Un taxi con taxímetro: llega cuando lo llamas, el taxímetro corre solo mientras viajas y se va cuando terminas. Un auto más grande cuesta más por minuto. La palabra confunde a todos: un **virtual warehouse** no guarda nada. Es un clúster de cómputo que ejecuta tus consultas. Tiene un tamaño (X-Small, Small, Medium, Large, hasta 6X-Large) y cada escalón es el doble de potencia y el doble de precio. El precio va en **créditos**, la moneda interna de Snowflake: X-Small gasta 1 crédito por hora, Small 2, Medium 4, Large 8, X-Large 16 (Gen1). El precio en dólares de un crédito depende de la edición, la nube, la región y el contrato: no hay un único número. Se factura por segundo, con un mínimo de 60 segundos en cada arranque. **Auto-suspend** pone el clúster a dormir cuando está ocioso (configura 60 segundos); **auto-resume** lo despierta con la siguiente consulta; **multi-cluster** (Enterprise) agrega copias bajo carga. Un **resource monitor** pone un tope de créditos: avisar al 80 %, suspender al 100 %. Sin un warehouse activo, el SQL no se ejecuta: «No active warehouse selected». _Diagram: Cada tamaño duplica los créditos por hora. Se despierta con una consulta, factura por segundo, se duerme tras 60 segundos sin actividad, y lo limitas con un resource monitor._ #### Virtual Warehouse (credits · auto-suspend · resource monitor) - **Qué es:** Un clúster de cómputo de Snowflake con un tamaño y un precio en créditos por segundo; no guarda datos. - **Ejemplo:** `AI_AGENT_WH`: X-Small, `AUTO_SUSPEND = 60`, un resource monitor de 50 créditos y un `QUERY_TAG` para seguir el costo del agente. - **Inconveniente:** Sin auto-suspend o con un tamaño demasiado grande = miles de dólares al mes. Un agente que dispara 20 consultas por pregunta mantiene el warehouse despierto todo el día. - **Relaciones:** La capa de cómputo de **Snowflake**; se usa a través de un **Role**. ### Roles and RBAC: los derechos van a los roles, los roles van a los usuarios > Llaves en un tablero de ganchos con etiquetas por puesto, no por nombre: «cajero», «gerente de noche». El personal nuevo recibe el gancho de su puesto; a nadie se le dan llaves sueltas. En Snowflake los derechos nunca se dan directamente a un usuario: van a los **roles**, y los roles van a los usuarios. Esto es **RBAC (role-based access control)**. Roles incluidos: **ACCOUNTADMIN**, el dios de la cuenta (nadie te lo va a dar y no lo necesitas); **SECURITYADMIN** y **USERADMIN** gestionan usuarios y grants; **SYSADMIN** crea bases de datos y warehouses; **PUBLIC** lo tienen todos. Los roles se pueden anidar. Para el agente creas su propio rol, por ejemplo `AI_AGENT_RO`, con `USAGE` sobre su warehouse, su base de datos y su esquema, y `SELECT` sobre las vistas que necesita, más `SNOWFLAKE.CORTEX_USER` si llama a Cortex. Encima de eso, las **row access policies** deciden qué filas ve cada uno y las **masking policies** ocultan valores como el email o el SSN. Los objetos se nombran `DATABASE.SCHEMA.OBJECT`, por ejemplo `SALES.MART.ORDERS_V`. _Diagram: El service user recibe un solo rol de solo lectura; el rol tiene los grants. Arriba están los roles incluidos, de ACCOUNTADMIN hasta PUBLIC._ #### Roles and RBAC (AI_AGENT_RO · row access · masking) - **Qué es:** El modelo de acceso de Snowflake: los grants van a los roles, los roles van a los usuarios y a otros roles. - **Ejemplo:** `GRANT SELECT ON ALL VIEWS IN SCHEMA SALES.MART TO ROLE AI_AGENT_RO`: solo vistas, nunca tablas en bruto con PII. - **Inconveniente:** «Object does not exist» o «no warehouse» casi nunca es un error de tipeo: es un grant de `USAGE` que falta. Snowflake dice «does not exist» cuando el rol no puede verlo. - **Relaciones:** Se da a un **Service User**; un caso de manual de **Least Privilege**. ### Service User: una cuenta de Snowflake para un programa, sin contraseñas > Un robot de reparto entra al edificio con un chip programado, no tecleando el código de la puerta, y el edificio simplemente ya no deja que los robots usen códigos. Un **service user** (`TYPE = SERVICE`) es un usuario de Snowflake para un programa, no para una persona. Las contraseñas le están prohibidas: inicia sesión con un **key pair** (JWT), OAuth, un programmatic access token (PAT) o workload identity federation. Y ahora esto es estricto: entre agosto y octubre de 2026 Snowflake bloqueó por completo el inicio de sesión con contraseña para los service users, y los usuarios `LEGACY_SERVICE` se están pasando a `SERVICE`. Así que los viejos ejemplos de internet con `password=` no funcionan: no los copies. Con **key-pair auth**, generas un par de claves RSA, le das al administrador la clave pública (`RSA_PUBLIC_KEY`) y guardas la clave privada en Key Vault o Secret Manager. Tu conector firma un JWT con ella (`authenticator="SNOWFLAKE_JWT"`). Un segundo espacio, `RSA_PUBLIC_KEY_2`, te permite rotar claves sin cortes; una **network policy** limita desde qué IPs se puede conectar. _Diagram: Sin contraseña. La clave privada en el vault firma un JWT; Snowflake lo verifica contra la clave pública, la network policy y el rol._ #### Service User (TYPE = SERVICE · key-pair auth) - **Qué es:** Un usuario de Snowflake para software, que debe iniciar sesión con una clave, OAuth, PAT o workload identity. - **Ejemplo:** `SVC_AI_AGENT` con `DEFAULT_ROLE = AI_AGENT_RO`, `DEFAULT_WAREHOUSE = AI_AGENT_WH` y solo una clave pública RSA. - **Inconveniente:** Si todos los usuarios del agente pasan por un solo service user, todos ven los mismos datos. Decide temprano: row policies, o inicio de sesión como el usuario vía OAuth desde Okta o Entra. - **Relaciones:** Tiene un **Role**; las claves viven en **Key Vault**; la decisión de diseño es **As the User vs As Itself**. ### Cortex: la IA junto a los datos > En lugar de llevar las cajas del archivo a un experto externo, invitas al experto al archivo: los papeles nunca salen del edificio. **Cortex AI** es la capa de IA de Snowflake, con modelos de Anthropic, OpenAI, Meta, Mistral y otros que corren dentro del perímetro de seguridad de Snowflake. **Cortex AI Functions** (antes «AISQL») ponen un LLM directamente en SQL: `AI_COMPLETE`, `AI_CLASSIFY`, `AI_EXTRACT`, `AI_SENTIMENT`; clasificas 100.000 reseñas en una consulta. **Cortex Analyst** convierte una pregunta en inglés en SQL usando una **semantic view** que define los términos del negocio («revenue = SUM(amount) where status = 'paid'»). **Cortex Search** es una búsqueda RAG lista para usar sobre texto: vectores + palabras clave + reranking. **Cortex Agents** (GA desde noviembre de 2025) planifican pasos y llaman a Analyst, Search, tus procedimientos y conectores MCP; el 28 de agosto de 2026 Snowflake recomendó pasar de la API separada de Analyst a Cortex Agents. **Snowflake Intelligence** es una interfaz de chat lista encima de todo. Un **Snowflake-managed MCP server** (`CREATE MCP SERVER`, hasta 50 herramientas) expone todo esto a agentes externos como Claude o Cursor, con Snowflake OAuth u OAuth externo desde Okta o Entra. _Diagram: Functions, Analyst, Search, Agents, Intelligence: todo dentro de Snowflake. El managed MCP server los abre a agentes externos._ #### Cortex (AI Functions · Analyst · Search · Agents) - **Qué es:** La IA integrada de Snowflake: funciones LLM en SQL, text-to-SQL, búsqueda RAG y agentes, junto a los datos. - **Ejemplo:** El camino B para un agente de «¿por qué bajó el margen en Texas?»: una semantic view + un Cortex Agent, llamado desde tu app. Los datos nunca salen de Snowflake. - **Inconveniente:** Las llamadas a Cortex cuestan créditos por token, una línea aparte en la factura; prueba con 1.000 filas antes de un millón. No todos los modelos están en todas las regiones. Y el text-to-SQL sin una capa semántica miente: nadie sabe qué significa `AMT_NET_2`. - **Relaciones:** Los agentes llegan a él mediante **MCP**; el primo en Databricks es **Agent Bricks**, y en Fabric, el **Data Agent**. > **La pregunta de Snowflake:** "¿Mi agente tiene su propio service user con una clave, un rol de solo lectura sobre vistas, un warehouse chico que se duerme al minuto y un resource monitor? ¿Y hay una capa semántica antes de cualquier text-to-SQL?" > Snowflake separa el almacenamiento del cómputo y cobra el cómputo por segundo. Dale al agente su propio service user firmado con clave, un rol de solo lectura, un warehouse X-Small y un tope de créditos, y mándale al administrador un script SQL listo. ## 6. Datos: Databricks Databricks nació de los archivos y de Spark, no de las tablas SQL. Es el lakehouse: una sola copia de los datos en el almacenamiento en la nube del propio cliente, un solo guardia para todo el acceso y una plataforma de IA sobre las mismas tablas. ### Databricks: un depósito, un taller y un laboratorio en un mismo predio > Un predio industrial: un depósito barato para la materia prima, un taller donde se limpia y se procesa, una vitrina para los productos terminados, un laboratorio para experimentos, y un solo guardia en la entrada que revisa el pase de todos. **Databricks** es una plataforma de datos creada por los autores de Apache Spark. La empresa guarda todos sus datos en almacenamiento de archivos barato en la nube, los procesa con **Spark** (un motor distribuido para datos demasiado grandes para una sola máquina), responde preguntas en SQL y construye modelos de ML y agentes de IA sobre los mismos datos, todo bajo un único sistema de permisos, **Unity Catalog**. Corre sobre la nube del cliente: AWS, Azure (como Azure Databricks) o GCP. Las personas trabajan en **notebooks** (como Jupyter, en el navegador, siempre conectados a cómputo) y **jobs**; los analistas usan SQL y **Genie**; el trabajo de IA vive en **Agent Bricks**. El cómputo (**clusters** para Spark, **SQL warehouses** para SQL, **serverless**) se cobra en **DBU** (Databricks Units). También está **Lakebase**, un Postgres gestionado para apps que necesitan lecturas y escrituras rápidas. _Diagram: Personas y agentes arriba, el cómputo en el medio, Unity Catalog cuidando todo y los datos en el almacenamiento propio del cliente._ #### Databricks (lakehouse platform · Azure Databricks) - **Qué es:** Una plataforma lakehouse: archivos en el almacenamiento en la nube del cliente, Spark y SQL encima, IA sobre las mismas tablas. - **Ejemplo:** Un distribuidor guarda ventas, inventario y CRM en tablas gold `main.sales_gold.*` en Azure Databricks. - **Inconveniente:** Tres nubes, tres productos un poco distintos: en Azure la identidad llega a través de Entra; la disponibilidad de funciones (Lakebase, serverless) depende de la nube y la región. - **Relaciones:** Las tablas son **Delta Lake**; los derechos son **Unity Catalog**; el agente consulta un **SQL Warehouse**. ### Delta Lake: una carpeta de archivos que se comporta como una tabla > El libro de registro de un depósito: las cajas en los estantes son solo cajas, pero el libro en la puerta dice qué cajas forman el stock de hoy. Cambias el libro de un solo trazo y el stock cambia de golpe. **Delta Lake** es un formato de tabla abierto. Por debajo son archivos **Parquet** comunes (un formato de archivo en columnas) más una carpeta `_delta_log`: un diario que registra qué archivos forman la tabla en este momento. Gracias a ese diario, una simple carpeta de archivos obtiene los poderes de una base de datos de verdad: **ACID transactions** (una escritura entra completa o no entra; los lectores nunca ven la mitad), un **schema** (no puedes escribir un texto en una columna numérica), **time travel** (leer la tabla «como estaba ayer») y `MERGE`, `UPDATE`, `DELETE`. Si conoces Postgres: es como el WAL, solo que el diario está junto a los archivos en S3 en lugar de dentro de un servidor de base de datos. Fabric usa el mismo formato. _Diagram: Archivos Parquet simples más un log de transacciones. El log dice qué archivos son la tabla, y eso convierte una carpeta en una tabla de base de datos._ #### Delta Lake (Parquet + transaction log) - **Qué es:** Un formato de tabla abierto: archivos Parquet más un diario `_delta_log` que añade transacciones e historial. - **Ejemplo:** El job nocturno hace MERGE de los pedidos nuevos en `orders`; los analistas nunca ven una tabla escrita a medias. - **Inconveniente:** Es un formato, no un servidor: algo tiene que ejecutar cómputo para leerlo, y ese cómputo es lo que pagas (DBU). - **Relaciones:** La base del **Lakehouse**; lo comparten **Databricks** y **Microsoft Fabric**. ### Unity Catalog: un solo guardia con un solo libro de registro > Un guardia en la única entrada con un libro de registro: no importa si llegas a pie, en auto o como robot de reparto; revisa tu pase y anota lo que te llevaste. **Unity Catalog** es la capa única de permisos y catálogo para todos los datos y la IA en Databricks; viene activada por defecto en cada workspace creado después del 8 de noviembre de 2023. Los nombres tienen tres niveles, `catalog.schema.table`, como `main.sales_gold.orders`, y el mismo esquema cubre vistas, **volumes** (carpetas de archivos como PDFs), funciones y modelos. Los derechos se otorgan con `GRANT` a personas, grupos y **service principals**. Puedes ocultar filas (**row filters**) y columnas (**column masks**). El **lineage** dibuja de dónde vinieron los datos y adónde fueron, y cada acción queda auditada en las **system tables**. Ya sea que la petición venga de un notebook, de SQL o de tu agente, pasa por la misma revisión. Para leer una tabla, un principal necesita tres grants a la vez: `USE CATALOG` + `USE SCHEMA` + `SELECT`. _Diagram: Notebooks, SQL y agentes pasan todos por la misma revisión. Unity Catalog da acceso a tablas, volumes y modelos, y lo registra._ #### Unity Catalog (catalog.schema.table · GRANT · lineage) - **Qué es:** Los permisos, el catálogo, el lineage y la auditoría centrales de Databricks para datos y objetos de IA. - **Ejemplo:** El service principal del agente recibe `SELECT` sobre el esquema `main.sales_gold` y `READ VOLUME` sobre `main.docs.contracts`, y nada más. - **Inconveniente:** Si falta uno de los tres grants, parece «table not found». Los workspaces viejos todavía pueden tener tablas en el `hive_metastore` heredado con reglas viejas: revisa qué se migró. - **Relaciones:** Protege las tablas de **Delta Lake**; se revisa en cada consulta al **SQL Warehouse**. ### Medallion: bronze, silver, gold > Mineral de la mina, metal del horno, un anillo terminado en la vitrina. El joyero vende solo el anillo, pero guarda el mineral por si hay que volver a encender el horno. **Medallion** no es un producto: es la forma habitual de organizar los datos en capas de calidad. **Bronze**: datos en bruto tal como llegaron de la fuente, con duplicados, basura y formatos mezclados. Lo guardas para poder reconstruir todo. **Silver**: datos limpios, con los tipos correctos, sin duplicados y tablas unidas por claves. **Gold**: agregados y tablas de negocio, como ingresos por día o clientes activos. Los reportes y los agentes leen gold. Los pipelines que mueven datos entre capas son **Lakeflow Jobs** (antes Workflows) y **Lakeflow Declarative Pipelines** (antes Delta Live Tables, DLT). La regla para un proyecto de IA: el agente lee gold, a veces silver, nunca bronze. _Diagram: Fuentes → bronze (tal como llegó) → silver (limpio) → gold (listo para el negocio). El agente lee gold._ #### Medallion (bronze · silver · gold) - **Qué es:** Organizar los datos en capas por calidad: en bruto (bronze), limpios (silver), listos para el negocio (gold). - **Ejemplo:** El agente lee `main.sales_gold.orders`; los volcados en bruto del CRM se quedan en bronze, fuera de su alcance. - **Inconveniente:** Gold se actualiza cada noche o cada hora. El agente debería decir de qué fecha son sus números. - **Relaciones:** Se construye sobre **Delta Lake**; dale al agente solo gold a través de **Unity Catalog**. ### SQL Warehouse y OAuth M2M: cómo el agente hace una pregunta > Un mostrador de autoservicio con máquina de turnos: muestras tu documento una vez, recibes un turno válido por una hora y el empleado revisa la lista antes de entregarte nada. Un **SQL warehouse** es cómputo de Databricks hecho solo para SQL; las herramientas de BI y tu app se conectan a él por **server hostname** y **HTTP path** (los dos están en los Connection details del warehouse). Hay tres tipos: **serverless** (recomendado, normalmente arranca en 2–6 segundos), **pro** y **classic** (cerca de 4 minutos). El agente inicia sesión como un **service principal** con **OAuth M2M** (machine-to-machine): cambia `client_id` y `client_secret` por un token de vida corta y luego manda SQL. Unity Catalog revisa los grants y los filtros; el motor lee solo los archivos y columnas necesarios; vuelven las filas, y cada consulta queda en las tablas de auditoría (`system.access.audit`). Pasa los valores como parámetros de consulta (`:since`), no pegando strings, incluso cuando el SQL lo escribe un LLM, y agrega siempre un `LIMIT`. _Diagram: El agente cambia su client ID y su secret por un token corto, manda SQL al warehouse, Unity Catalog lo revisa, vuelven las filas y todo queda auditado._ #### SQL Warehouse (serverless · OAuth M2M · DBU) - **Qué es:** El cómputo solo para SQL de Databricks, que las apps y el agente consultan con un token de service principal. - **Ejemplo:** Un warehouse serverless chico solo para el agente (permiso `CAN USE`): sus costos son visibles y puede tener su propio límite. - **Inconveniente:** Un warehouse classic tarda ~4 minutos en arrancar, así que la primera consulta del agente da timeout, y la API crea classic por defecto. Los personal access tokens (PAT) muchas veces están prohibidos; usa OAuth M2M. - **Relaciones:** Lo revisa **Unity Catalog**; la identidad es un **Service Principal**; la decisión de diseño es **As the User vs As Itself** (U2M / on-behalf-of). ### Agent Bricks: el paraguas de IA de Databricks > Un centro comercial donde todas las tiendas de IA se mudaron bajo un mismo techo y un mismo cartel: las mismas tiendas de antes, un nombre nuevo sobre la entrada. En este rincón es donde más cambiaron los nombres. **Mosaic AI** era el viejo nombre paraguas (después de que Databricks compró MosaicML); desde marzo de 2026 el paraguas de toda la IA es **Agent Bricks**, una plataforma para construir y ejecutar agentes. Soporta modelos frontier y abiertos (OpenAI, Anthropic, Gemini y otros), frameworks como LangGraph, CrewAI y el Claude Agent SDK, tracing con **MLflow**, memoria gestionada para agentes (sobre Lakebase), un sandbox para ejecutar código y parsing de documentos (`ai_parse_document`, `ai_extract`, `ai_classify`). Alrededor: **Model Serving** (un modelo como endpoint REST, compatible con OpenAI para LLMs), **Unity AI Gateway** (una sola puerta para las llamadas a modelos y a MCP: derechos, presupuestos, límites, protección de PII, tracing), **Databricks Apps** (aloja tu agente dentro de Databricks), **Genie** (preguntarle a los datos en inglés, con un Genie MCP server). Vector Search pasó a llamarse **AI Search** el 1 de junio de 2026 y ahora suma búsqueda full-text, híbrida y reranking; un índice puede mantenerse sincronizado con una tabla Delta. _Diagram: Modelos, frameworks, tracing, serving, el AI gateway, la búsqueda, Genie y el hosting de apps: todo bajo Agent Bricks. Más los nombres viejos que todavía vas a escuchar._ #### Agent Bricks (antes Mosaic AI · AI Search · Genie) - **Qué es:** La plataforma de Databricks para construir, ejecutar y gobernar agentes junto a los datos. - **Ejemplo:** Contratos procesados con `ai_parse_document` → una tabla de chunks → un índice de AI Search que se mantiene sincronizado con ella; las llamadas del agente al modelo pasan por Unity AI Gateway. - **Inconveniente:** Cambios de nombre por todos lados: DLT → Declarative Pipelines, Workflows → Lakeflow Jobs, Vector Search → AI Search, Delta Sharing → OpenSharing (junio de 2026). La documentación del cliente usa los nombres viejos: conoce los dos. - **Relaciones:** El equivalente en Snowflake es **Cortex**; en Fabric, el **Data Agent**; en Azure, **Microsoft Foundry**. > **La pregunta de Databricks:** "¿Mi agente lee solo tablas gold, a través de un SQL warehouse serverless chico, como service principal con OAuth M2M y grants de solo lectura en Unity Catalog, con cada consulta en las tablas de auditoría?" > Databricks es el lakehouse: archivos Delta en el almacenamiento del cliente, Unity Catalog como el único guardia, tablas gold para el agente y un warehouse serverless chico con OAuth, no con tokens personales. ## 7. Datos: Microsoft Fabric Fabric es la respuesta de Microsoft a Snowflake y Databricks: un solo producto con almacenamiento, carga de datos, procesamiento, Power BI e IA. Lo eligen las empresas que ya viven en Microsoft. Las ideas nuevas aquí son un solo almacén para toda la empresa y una sola capacity compartida que todos gastan. ### Microsoft Fabric y OneLake: «Office para los datos» > Cinco depósitos en cinco edificios, cada uno con su propia llave, reemplazados por un solo edificio grande con un solo pase y una sola factura de luz. **Microsoft Fabric** es una plataforma de datos SaaS todo en uno: un almacén compartido (**OneLake**), carga de datos (**Data Factory**), procesamiento (Spark, SQL), reportes (**Power BI**) e IA (Copilot, data agents), en un solo portal web, con inicio de sesión mediante Entra ID y pagado como una sola **capacity**. Antes de Fabric, una empresa Microsoft pegaba entre sí Azure Data Factory, ADLS, Azure Synapse y Power BI, cada uno con su propia factura, sus derechos y su red, y copiaba los datos tres o cuatro veces. **OneLake** es un único almacén lógico para todo el tenant, creado automáticamente; Microsoft lo llama «el OneDrive de los datos». Adentro hay carpetas por **workspace** e **item**, con tablas en formato Delta (el mismo formato abierto de Databricks); desde afuera se ve como ADLS Gen2. Los roles de workspace son **Admin**, **Member**, **Contributor** y **Viewer**, y también puedes compartir un solo item. En Power BI, el **semantic model** (antes «dataset») es la capa de negocio con tablas, relaciones y medidas DAX; muchas veces es ahí donde la empresa ya acordó qué significa «revenue». _Diagram: Un tenant de Entra, una capacity paga, workspaces llenos de items y, debajo de todo, OneLake. Los datos externos entran por shortcut o mirroring._ #### Microsoft Fabric (OneLake · workspace · item) - **Qué es:** La plataforma de datos todo en uno de Microsoft, con un solo almacén (OneLake) y una sola factura (capacity). - **Ejemplo:** Una red de clínicas replica su historia clínica electrónica y su facturación desde Azure SQL a Fabric, con reportes en Power BI sobre una F64. - **Inconveniente:** Más simple que Databricks, pero con menos control. Y los nombres se mueven: dataset → semantic model, «license mode» → «workspace type», P SKU → F SKU. - **Relaciones:** Se paga con una **Capacity**; se lee a través del **SQL Analytics Endpoint**; se alimenta con **Shortcuts and Mirroring**. ### Capacity y F SKUs: una sola factura de luz compartida > El contrato de luz de toda una oficina: si tu nueva estufa funciona a todo lo que da, las luces también parpadean en el piso del CFO. Una **capacity** es un pool de cómputo que compra la empresa. Cada workspace está conectado a una capacity, y todo lo que hace (SQL, Spark, actualizaciones de reportes, Copilot) gasta sus **CU (capacity units)**. Los tamaños son **F SKUs**: F2, F4, F8 … F64 … F2048; el número es la cantidad de CU, y F64 equivale al viejo Power BI Premium P1. Se compra en Azure, se factura por segundo (mínimo un minuto) o se reserva por un año con descuento; los precios dependen de la región, así que revisa la calculadora de Azure para la región del cliente. Una capacity se puede pausar, y entonces no funciona nada de lo que tiene adentro. **F64 es un umbral**: de F64 para arriba, las personas con licencia gratuita pueden ver reportes de Power BI; por debajo, cada espectador necesita Pro o PPU. Fabric deja que un trabajo pesado tome por un rato más de lo que compraste (**bursting**) y reparte el costo en el tiempo (**smoothing**: el trabajo interactivo en al menos 5 minutos, el de segundo plano en 24 horas). Si te excedes, empieza el **throttling**: tras 10 minutos de «deuda» las consultas interactivas esperan 20 segundos, tras 60 minutos se rechazan y tras 24 horas se rechaza todo. _Diagram: Todos gastan de una sola capacity. Los picos cortos por encima se suavizan; demasiada deuda significa demoras y luego rechazos._ #### Capacity (F SKU · CU · throttling) - **Qué es:** El pool de cómputo compartido y comprado por adelantado que gasta cada workspace de Fabric conectado a él. - **Ejemplo:** Una F64 atiende a toda la empresa; las consultas del agente se mantienen chicas y se vigilan en la app Capacity Metrics. - **Inconveniente:** El throttling no es «un poco más lento»: son errores `CapacityLimitExceeded` para todos. Y si el cliente pausa la capacity de noche para ahorrar, tu agente no funciona de noche. - **Relaciones:** La factura de **Microsoft Fabric**; el **Virtual Warehouse** por clúster de Snowflake es el modelo opuesto. ### SQL Analytics Endpoint: desde afuera, Fabric parece SQL Server > Una vitrina de museo: puedes mirar cada objeto por todos lados el tiempo que quieras, pero hay un vidrio adelante: no se puede mover ni agregar nada. Fabric tiene dos hogares para las tablas. Un **lakehouse** es para los ingenieros de datos: tablas Delta (carpeta `Tables`) más cualquier archivo (carpeta `Files`), escritos con Spark, notebooks y pipelines. Un **warehouse** es para la gente de SQL: solo tablas, con **T-SQL** completo (el dialecto SQL de Microsoft): `INSERT`, `UPDATE`, `MERGE`. Los dos son Delta en OneLake, y puedes unirlos en una sola consulta. Cada lakehouse (y cada base de datos replicada) recibe automáticamente un **SQL analytics endpoint**: T-SQL de solo lectura sobre sus tablas Delta. Puedes hacer `SELECT`, crear vistas y funciones y configurar seguridad a nivel de fila, pero no cambiar datos. Desde afuera parece SQL Server: tu agente se conecta con ODBC Driver 18 por el puerto 1433 (protocolo TDS) a una dirección como `xxxx.datawarehouse.fabric.microsoft.com`, con un token de Entra para el scope `https://database.windows.net/.default`. Que sea de solo lectura es algo bueno para un agente. _Diagram: Lakehouse vs warehouse de un vistazo. El agente lee un lakehouse a través de su SQL endpoint de solo lectura, como cualquier SQL Server._ #### SQL Analytics Endpoint (lakehouse vs warehouse · T-SQL) - **Qué es:** El endpoint automático, de solo lectura y estilo SQL Server sobre un lakehouse o una base de datos replicada de Fabric. - **Ejemplo:** `pyodbc` + un token de Entra → `SELECT TOP (100) clinic, COUNT(*) … FROM dbo.appointments` con parámetros. - **Inconveniente:** Solo aparecen las tablas de `/Tables`, y las nuevas después de una sincronización de metadatos (a veces con demora). No puedes escribir ahí los logs ni la caché del agente: usa un warehouse, SQL database in Fabric o tu propia base de datos. - **Relaciones:** Gasta la **Capacity**; para acceder, el **Service Principal** necesita un rol de workspace o un permiso sobre el item. ### Shortcuts and Mirroring: datos sin construir ETL > Un acceso directo en tu escritorio abre un archivo que vive en otro lugar. Mirroring es una copia de ese archivo que se actualiza sola cada vez que cambia el original. La forma de Fabric de evitar pipelines de copia. Un **shortcut** es como un symlink: una carpeta en un lakehouse que en realidad apunta a S3, ADLS, Google Cloud Storage, Dataverse, SharePoint/OneDrive u otro item de OneLake. No se copian datos; si borras el shortcut, la fuente queda intacta. En los shortcuts internos, el acceso se revisa con la identidad de quien lee. **Mirroring** es una copia continua: Fabric mantiene una base de datos replicada en OneLake como Delta, casi en tiempo real. Entre las fuentes están Azure SQL, SQL Server, Azure Database for PostgreSQL, Cosmos DB, Snowflake, Google BigQuery, Oracle y SAP. Para Azure Databricks existe el mirroring de metadatos: solo se copia el catálogo y los datos se leen mediante shortcuts. El cómputo de la replicación es gratis, y guardar las réplicas es gratis hasta 1 TB por CU de capacity. _Diagram: Un shortcut apunta a los datos donde ya viven. Mirroring mantiene en OneLake una copia Delta casi en tiempo real._ #### Shortcuts and Mirroring (symlink · copia en vivo) - **Qué es:** Dos formas de traer datos externos a OneLake: apuntar a ellos (shortcut) o mantener una copia en vivo (mirroring). - **Ejemplo:** Las tablas de facturación de Azure SQL se replican en Fabric; el agente las lee a través del SQL endpoint de la base de datos replicada. - **Inconveniente:** Una capacity pausada también detiene el mirroring. Los nombres de los shortcuts no pueden tener espacios ni caracteres no latinos. - **Relaciones:** Deja los datos en el OneLake de **Microsoft Fabric**; las bases de datos replicadas reciben un **SQL Analytics Endpoint**. ### Fabric Data Agent: un «chat con tus datos» listo para usar > Una bibliotecaria de referencia que se sabe el catálogo de memoria y te busca las respuestas, pero solo de los estantes que abre tu carnet, y nunca te deja escribir en los libros. Un **Fabric data agent** es un «chat con los datos» configurable. Eliges hasta cinco fuentes (lakehouse, warehouse, semantic model, base de datos KQL, base de datos replicada, ontología), escribes instrucciones y pares de ejemplo pregunta → consulta, y el agente convierte una pregunta en SQL, DAX o KQL y la ejecuta. Está disponible de forma general. Es **de solo lectura** y funciona **como el usuario**: ve solo lo que esa persona puede ver. Puedes llamarlo desde Microsoft 365 Copilot, Copilot Studio, Teams, Microsoft Foundry o como un MCP server. **Fabric IQ** es una capa más nueva de «significado de negocio» (ontología, semantic models, data agents) para agentes externos; en Foundry Agent Service, la vieja herramienta «Fabric data agent» se retirará el 6 de noviembre de 2026 en favor de Fabric IQ. **Copilot in Fabric**, el asistente integrado, ahora funciona en cualquier capacity paga desde F2 (el requisito de F64 se eliminó en abril de 2025), pero no en una capacity de prueba. _Diagram: Se llama desde Teams, Copilot, Foundry o MCP; convierte una pregunta en SQL, DAX o KQL sobre hasta cinco fuentes, en solo lectura y como el usuario._ #### Fabric Data Agent (Fabric IQ · Copilot) - **Qué es:** El agente integrado de Fabric, de solo lectura, que convierte preguntas en consultas sobre las fuentes elegidas y actúa como el usuario. - **Ejemplo:** El camino A para un agente de «¿por qué suben las inasistencias en Austin?»: un data agent sobre el semantic model, publicado en Teams. Los derechos del usuario se aplican solos. - **Inconveniente:** Solo en inglés, no puedes elegir el LLM, respuestas limitadas a 25 filas × 25 columnas, sin PDFs, y la fuente y el agente deben estar en la misma región de capacity. ¿Necesitas más control? Construye tu propio agente sobre el SQL endpoint (camino B). - **Relaciones:** El primo en Fabric de **Cortex** y **Agent Bricks**; el camino B usa el **SQL Analytics Endpoint**. > **La pregunta de Fabric:** "¿El administrador de Fabric habilitó los service principals? ¿Mi principal tiene el rol más chico sobre un solo item? ¿Las consultas del agente son lo bastante chicas para una capacity compartida? ¿Y no bastaría ya con un data agent sobre su semantic model?" > Fabric es la plataforma de datos de Microsoft en una sola caja: OneLake para el almacenamiento, una sola capacity compartida para el cómputo, un SQL endpoint de solo lectura para tu agente y un data agent integrado cuando el camino simple alcanza. ## 8. Todo junto Ahora el trabajo real: un agente de IA dentro de una empresa cliente. Todos los sistemas de arriba hacen las mismas pocas preguntas: quién es el agente, qué puede leer, en nombre de quién actúa y si el equipo de seguridad puede aprobarlo. Respóndelas temprano y el proyecto avanza; respóndelas tarde y espera. ### El plano: un agente, tres capas > Mudarse a un edificio de oficinas como inquilino nuevo: recibes las credenciales de la recepción, un local del dueño y una llave solo de tu estante en el archivo, todo resuelto antes de que llegue el camión de la mudanza. Un proyecto típico, en palabras sencillas. Los datos del cliente viven en Snowflake (o Databricks, o Fabric). Los empleados inician sesión con Entra ID (u Okta). La app corre en la nube del cliente, muchas veces Azure. Tu agente deja entrar solo a «su gente», a través de su propio inicio de sesión, con app roles que su TI asigna a grupos. Corre como una Container App con una managed identity, llama a un model deployment en Foundry, lee los secretos de Key Vault y queda detrás de private endpoints si seguridad lo pide. Lee los datos con los mínimos derechos: un service user de Snowflake con una clave y un rol de solo lectura, un service principal de Databricks con OAuth M2M y grants solo sobre gold, o un service principal de Fabric con Viewer sobre un solo item. Los logs van a Application Insights, sin datos personales en los prompts. Los deploys salen de GitHub con OIDC, sin secretos en el repo. _Diagram: Inicio de sesión con el IdP del cliente, el agente en su Azure con una managed identity y una sola conexión acotada a la plataforma de datos._ ### Least Privilege: solo lo que el trabajo necesita > La tarjeta llave de la mucama de un hotel abre las habitaciones de su piso durante su turno: no la caja fuerte, no la oficina del gerente, no los otros pisos. **Least privilege** significa dar solo los derechos mínimos necesarios, en el alcance más chico y de solo lectura por defecto. Cada sistema tiene su versión: Contributor en un resource group en lugar de en toda la subscription; un rol como `AI_AGENT_RO` con `SELECT` sobre vistas en lugar de algo cercano a `ACCOUNTADMIN`; `Files.Read.All` delegated en lugar de `Sites.Read.All` como application; Viewer sobre un item de Fabric en lugar de Admin del workspace; solo el esquema gold en Unity Catalog. Importa todavía más para los agentes que para las personas: a un LLM lo puede engañar una prompt injection, y cuando eso pasa, el daño se detiene exactamente en lo que tenía permitido hacer. _Diagram: Los mismos cuatro sistemas: demasiado a la izquierda, lo justo a la derecha._ #### Least Privilege (derechos mínimos · alcance más chico) - **Qué es:** Otorgar solo los derechos que necesita un trabajo, en el alcance más acotado y por el menor tiempo posible. - **Ejemplo:** El rol de Snowflake del agente puede leer tres vistas en `SALES.MART` y nada más, ni siquiera las tablas en bruto que hay detrás. - **Inconveniente:** Si es demasiado acotado, el agente falla de formas raras («table not found»). Empieza por lo mínimo, agrega derechos de a uno y anota por qué existe cada uno. - **Relaciones:** Da forma a los roles de la **Resource Hierarchy**, a **Roles and RBAC** y a los grants de **Unity Catalog**; es lo primero que revisa la **Security Review**. ### As the User vs As Itself: con los ojos de quién mira el agente > Mandar a tu asistente al archivo con tu propio carnet de biblioteca, o con la tarjeta maestra del edificio. Con el tuyo, solo puede traer lo que tú podrías. Con la tarjeta maestra, puede traer cualquier cosa, y tú tienes que decidir qué le muestra a quién. Esta es la decisión de diseño más grande, y toda security review pregunta por ella. **Como el usuario**: el agente llama a la fuente de datos con la identidad de la persona que inició sesión (delegated permissions en Entra, on-behalf-of, OAuth U2M en Databricks, inicio de sesión vía Okta o Entra en Snowflake, el data agent de Fabric). La fuente aplica los derechos de cada persona, así que Anna ve Texas y Ben ve Ohio, gratis. **Como sí mismo**: el agente usa una sola **service account** (un service principal, una managed identity, un service user de Snowflake: «una cuenta para un programa, no para una persona»). Todos los que hablan con el agente ven los mismos datos, así que _tú_ tienes que filtrar: row access policies en Snowflake, row filters en Unity Catalog, RLS en Fabric o tu propio código. Regla práctica: si responde a personas → actuar como el usuario; para tareas en segundo plano como la indexación nocturna → una identidad de servicio chica. _Diagram: Como el usuario: se aplican los derechos de cada persona. Como sí mismo: una sola identidad ve todo, y el filtrado corre por tu cuenta._ #### As the User vs As Itself (delegated / OBO vs service account) - **Qué es:** La elección entre que el agente actúe con la identidad de cada usuario o con su propia identidad de servicio. - **Ejemplo:** El asistente de contratos busca en SharePoint como el usuario; un indexador aparte en segundo plano corre como identidad de servicio con un conjunto chico de application permissions. - **Inconveniente:** Con datos médicos u otros datos sensibles, esta es la pregunta clave de la revisión. Con una sola identidad compartida, prepárate para mostrar exactamente cómo se filtran las filas. - **Relaciones:** Se construye con **Delegated vs Application Permissions**, **Cross App Access** y **Service User**; una pregunta central de la **Security Review**. ### Security Review: el examen antes del lanzamiento > Una inspección del edificio antes del día de la inauguración: el inspector recorre todo con una lista, y las puertas se abren solo cuando se marca la última casilla. Una **security review** es la revisión que hace el equipo de seguridad del cliente de tu solución antes de que salga a producción. Las preguntas son previsibles, así que prepara las respuestas, idealmente en un documento corto que liste cada conexión. ¿Adónde van los datos, en qué región corre el modelo, qué LLM y bajo qué contrato (data residency)? ¿Hay alguna API key? La respuesta correcta es «ninguna: managed identity, secretos en Key Vault». ¿Los servicios están cerrados a internet? ¿Los roles son mínimos? ¿El agente actúa como el usuario o como sí mismo, y quién ve qué? ¿Qué puede _hacer_ por su cuenta (escribir, borrar, mandar emails) y hay confirmación humana? ¿Qué entra en los logs, por cuánto tiempo y hay datos personales en los prompts? ¿Cómo revocamos el acceso (desactivar un usuario, borrar la enterprise app) y funciona de inmediato? También salen las defensas contra prompt injection y los filtros de contenido. _Diagram: Ocho preguntas que hace todo equipo de seguridad. Ten las respuestas por escrito antes de que pregunten._ #### Security Review (la aprobación del cliente) - **Qué es:** La revisión que hace el equipo de seguridad del cliente de los flujos de datos, identidades, derechos, logs y revocación antes del lanzamiento. - **Ejemplo:** Llevas un mapa de una página: cada conexión, su identidad, su rol y por qué se necesita, más las tablas de auditoría que muestran cada consulta. - **Inconveniente:** Los permisos de lectura de toda la aplicación (`*.Read.All`) son los que más asustan a los revisores. Espera tener que justificar cada uno o reemplazarlo por acceso delegated. - **Relaciones:** Revisa **Least Privilege**, **As the User vs As Itself**, **Private Endpoint** y **Key Vault**. ### Day-One Access: empieza primero por la parte lenta > Encargar un traje a medida para una boda: las pruebas llevan semanas, así que lo encargas el día que recibes la invitación, no la semana anterior. En una empresa mid-market, el acceso suele ser la parte más lenta de todo el proyecto. Una cuenta de invitado, un rol en un resource group, una app registration con admin consent, un service user de Snowflake, los grants de Unity Catalog, la opción del tenant de Fabric «Service principals can call Fabric public APIs»: cada cosa es un ticket para un administrador distinto, y todas juntas pueden llevar de una a tres semanas. Tú no eres el administrador, y no lo vas a ser. Así que el primer día manda un solo mensaje con todo: redirect URIs, scopes, app roles, grupos, grants, y por qué se necesita cada uno. Para Snowflake, manda un script SQL listo que el administrador solo tenga que ejecutar. Pide primero el entorno de preview/test. Y revisa la quota del modelo en la región correcta antes de construir, no el día de la demo. _Diagram: Manda la lista completa el primer día y el acceso estará listo cuando lo esté el desarrollo. Pídelo en la tercera semana y la demo espera por un rol._ #### Day-One Access (la lista de accesos) - **Qué es:** La costumbre de pedir cada cuenta, rol y configuración al principio de todo, en una sola lista precisa. - **Ejemplo:** Día 1: guest + Contributor en `rg-ai-agent-dev`, datos de la app registration, script de `SVC_AI_AGENT`, contacto del administrador de Fabric, revisión de quota. - **Cómo evitarlo:** Encuentra temprano a cada administrador: el de Fabric muchas veces no es el de Azure. Sigue las solicitudes como tareas, con responsables y fechas. - **Relaciones:** El lado práctico de **Least Privilege**; alimenta la **Security Review**. ### Cómo se conecta todo > Un rompecabezas: cada pieza sola significa poco; juntas forman la imagen. Los conceptos de este curso son un solo sistema. La rama de la **nube** (la **resource hierarchy** de Azure, la **managed identity**, **Key Vault**, los **private endpoints** y **Foundry**) responde _dónde corre el agente y cómo no tiene secretos_. La rama de la **identidad** (**IdP y SSO**, **OIDC**, **Entra ID** con **app registrations**, **permissions**, **app roles** y **Conditional Access**, **Okta** con **SCIM** y **Cross App Access**, y **Agent ID**) responde _quiénes son el agente y sus usuarios_. La rama de los **datos** (del **lake** al **lakehouse**, **Snowflake**, **Databricks**, **Fabric**) responde _qué puede leer el agente_. Las tres se encuentran en tu agente, unidas por **least privilege**, la decisión de actuar **como el usuario o como sí mismo** y la **security review**. _Diagram: Tres ramas (nube, identidad, datos) se encuentran en tu agente, unidas por least privilege y la security review._ #### Antes de empezar un proyecto de IA dentro de un cliente - **¿Quiénes son los administradores?** Azure, Entra u Okta, la plataforma de datos, Fabric. ¿Le mandé a cada uno la lista exacta? - **¿Dónde corre el agente?** ¿Una Container App con una managed identity y roles en un solo resource group? - **¿Cómo inician sesión las personas?** ¿OIDC con el IdP del cliente, app roles o grupos filtrados, IDs de usuario estables? - **¿Como el usuario o como sí mismo?** Y si es como sí mismo, ¿cómo se filtran las filas? - **¿Qué lee?** ¿Solo tablas gold o vistas, en solo lectura, con un cómputo chico que se duerme? - **¿Qué va a preguntar seguridad?** Claves, red, roles, logs, data residency, revocación. ¿Tengo mis respuestas por escrito? #### Las palabras que ahora dominas - **Tenant, subscription, resource group**, y por qué un rol en un RG es mejor que uno en la subscription. - **Managed identity, Key Vault, private endpoint**: una app sin claves, detrás de ninguna puerta pública. - **IdP, SSO, OIDC, SAML**, y por qué identificas a los usuarios por `oid` + `tid` o `sub`, no por el email. - **App registration vs service principal**, **delegated vs application permissions**, **admin consent**. - **App roles, Conditional Access, Microsoft Graph, Entra Agent ID**. - **Okta org, Universal Directory, SCIM, org vs custom authorization server, Cross App Access**. - **Data warehouse, data lake, lakehouse, Delta Lake, medallion**. - **Virtual warehouse, credits, service user, Cortex**; **Unity Catalog, SQL warehouse, OAuth M2M, Agent Bricks**. - **OneLake, capacity, F SKU, SQL analytics endpoint, shortcut, mirroring, data agent**. - **Least privilege, service account, security review**. ## Hoja de referencia: los 42 conceptos ### El mapa - **Enterprise Stack** (nube · identidad · datos): Tres capas en toda empresa grande; tu agente queda entre ellas. ### Nube: Azure - **Microsoft Azure** (la nube de Microsoft): Ideas de nube conocidas, otros nombres; se elige porque «todo es Microsoft». - **Resource Hierarchy** (tenant · subscription · RG): Carpetas anidadas; un rol dado arriba se aplica a todo lo de abajo. - **Container Apps** (App Service · AKS · Functions): Contenedores serverless: el hogar habitual del backend de un agente. - **Managed Identity** (sin contraseña): Una cuenta de app que obtiene tokens de Entra; nada que se pueda filtrar. - **Key Vault** (caja fuerte de secretos): Donde viven los pocos secretos reales, leídos con un rol acotado. - **Private Endpoint** (VNet): Una IP privada para un servicio, para poder cerrarlo a internet. - **Microsoft Foundry** (antes Azure AI Foundry): Model deployments, agentes y evaluaciones dentro del tenant del cliente. ### Identidad: Entra ID - **Identity Provider** (IdP · SSO): La recepción de la empresa; una sola cuenta de trabajo abre todas las apps. - **OIDC and SAML** (auth code + PKCE): Cómo las apps hacen iniciar sesión a las personas a través del IdP; OIDC para código nuevo. - **Microsoft Entra ID** (antes Azure AD): El directorio en la nube de Microsoft con personas, grupos y apps. - **App Registration vs Service Principal** (Enterprise app): El pasaporte de la app, y su copia en un tenant, que es la que tiene los derechos. - **Delegated vs Application Permissions** (consent): Actuar como el usuario, o como la propia app con admin consent. - **App Roles** (roles claim): Tus roles, asignados a grupos por su TI y revisados por tu backend. - **Conditional Access** (reglas de MFA): Reglas «si… entonces» en cada inicio de sesión; necesita Entra ID P1. - **Microsoft Graph** (graph.microsoft.com): Una sola API para los datos de Microsoft 365, limitada por los scopes del token. - **Entra Agent ID** (agent blueprint): Un tipo de identidad para agentes de IA, gobernado como un empleado. ### Identidad: Okta - **Okta** (Workforce Identity): El IdP neutral para empresas con proveedores mezclados; una org por empresa. - **SCIM** (joiner–mover–leaver): El IdP crea y desactiva usuarios en tu app de forma automática. - **Authorization Server** (org vs custom): Org para el inicio de sesión; custom para los scopes de tu propia API. - **Cross App Access** (XAA · Agent SSO): Los agentes obtienen a través de Okta tokens cortos y registrados para otras apps. ### Datos: Snowflake - **Warehouse · Lake · Lakehouse** (tres formas): Tablas estrictas, archivos en bruto, o archivos con reglas de tabla encima. - **Snowflake** (cloud data warehouse): Analítica SQL con el almacenamiento y el cómputo separados. - **Virtual Warehouse** (credits): Un clúster de cómputo facturado por segundo; configura auto-suspend en 60. - **Roles and RBAC** (AI_AGENT_RO): Los grants van a los roles, los roles a los usuarios; solo vistas para el agente. - **Service User** (TYPE = SERVICE): La cuenta de un programa; key pair u OAuth, contraseñas bloqueadas. - **Cortex** (la IA junto a los datos): Funciones LLM, text-to-SQL, búsqueda y agentes dentro de Snowflake. ### Datos: Databricks - **Databricks** (lakehouse platform): Archivos en el almacenamiento del cliente; Spark, SQL e IA sobre las mismas tablas. - **Delta Lake** (Parquet + log): Una carpeta de archivos que se comporta como una tabla transaccional. - **Unity Catalog** (un solo guardia): Grants, masks, lineage y auditoría para cada forma de entrar. - **Medallion** (bronze · silver · gold): Capas de calidad; el agente lee gold. - **SQL Warehouse** (OAuth M2M): Cómputo SQL; serverless arranca en segundos, classic en minutos. - **Agent Bricks** (antes Mosaic AI): El paraguas de IA de Databricks: modelos, serving, gateway, AI Search, Genie. ### Datos: Fabric - **Microsoft Fabric** (OneLake): Un solo almacén y una sola factura para todas las herramientas de datos de Microsoft. - **Capacity** (F SKU · CU): Un pool de cómputo compartido; gastar de más lleva al throttling. - **SQL Analytics Endpoint** (T-SQL de solo lectura): Un lakehouse visto como SQL Server; ideal para las lecturas de un agente. - **Shortcuts and Mirroring** (sin ETL): Apuntar a datos externos o mantener una copia en vivo en OneLake. - **Fabric Data Agent** (Fabric IQ): Un «chat con los datos» integrado y de solo lectura que actúa como el usuario. ### Todo junto - **Least Privilege** (derechos mínimos): Solo lo que el trabajo necesita, en el alcance más chico. - **As the User vs As Itself** (OBO vs service account): Los derechos de cada usuario, o una sola identidad cuya salida filtras tú. - **Security Review** (la aprobación del cliente): Preguntas previsibles; ten las respuestas por escrito. - **Day-One Access** (la lista de accesos): Pide todo el primer día, en un solo mensaje preciso. > Un agente de IA dentro de una empresa es, sobre todo, un proyecto de accesos. Córrelo en su nube sin claves, haz que las personas inicien sesión con su IdP, lee la porción más chica de datos y pide todo el primer día. Fin del curso exprés · 8 capítulos · 42 conceptos Ahora toca practicar: abre una cuenta gratuita de Azure y despliega una Container App mínima con una managed identity user-assigned que lea un secreto de Key Vault, sin claves en ningún lado. Registra una app en un tenant de prueba de Entra (o en una developer org de Okta), inicia sesión con OIDC y revisa el ID token a mano. Luego abre una prueba de Snowflake, crea un usuario `TYPE = SERVICE` con un key pair y un rol de solo lectura, y consulta una vista desde Python. Anota cada grant que necesitaste y por qué: esa lista es tu primer documento para la security review. Pero conserva una idea por encima de las demás: el stack empresarial son solo tres preguntas (dónde corre, quién es, qué puede leer), y las mejores respuestas siempre son las más chicas.