Curso exprés · No. 39

Entra a una empresa de EE. UU. con unos miles de personas y escucharás los mismos nombres todos los días: Azure, Entra, Okta, Snowflake, Databricks, Fabric. Suenan a seis mundos distintos. En realidad son tres capas: dónde se ejecuta el código, quién tiene permiso para entrar y dónde viven los datos de la empresa. Este curso explica cada sistema con palabras sencillas y luego muestra cómo un agente de IA se conecta a todos ellos sin asustar al equipo de seguridad.

42 conceptos · un diagrama para cada uno · actualizado a octubre de 2026 · hoja de referencia al final

§ 01

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.

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.

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.

ConceptEnterprise 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.

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.

§ 02

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.

Los mismos bloques en tres nubes. Un proyecto de Google Cloud ≈ una subscription + resource group de Azure; una service account ≈ una managed identity.

PlatformMicrosoft 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.

Tenant → management group → subscription → resource group → recurso. Un rol dado arriba baja a todo lo que está debajo.

ConceptResource 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».

De menos que gestionar a más control. Para el backend de un agente, Container Apps suele ser la opción por defecto correcta.

ToolContainer 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.

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.

ConceptManaged 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?».

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.

ToolKey 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?».

Dentro de la VNet, el agente llega a cada servicio por una IP privada. Internet, y tu laptop, no pueden entrar.

ConceptPrivate 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.

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.

PlatformMicrosoft 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.

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.

§ 03

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.

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.

ConceptIdentity 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).

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.

ConceptOIDC 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/<tenant-id> 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.

Un tenant contiene users (incluidos los guests), groups y apps. El viejo AD on-prem muchas veces se sincroniza con él.

PlatformMicrosoft 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.

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.

ConceptApp 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».

Delegated: el agente ve solo los archivos de Anna. Application: ve todos los sitios, y necesita que un administrador lo apruebe.

ConceptDelegated 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.

Tú declaras los roles, TI los asigna a grupos, llegan en el token y tu backend los revisa.

ConceptApp 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».

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.

ConceptConditional 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).

El agente llama a un solo endpoint, graph.microsoft.com, y llega a usuarios, correo, calendarios, Teams y archivos, dentro de sus scopes.

ToolMicrosoft 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.

Los agentes se crean a partir de un blueprint, cada uno con su propia identidad, y TI los controla como cuentas del personal.

ConceptEntra 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.

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.

§ 04

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.

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.

PlatformOkta· 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.

RR. HH. cambia algo y el IdP llama a tu endpoint SCIM: crear al entrar, actualizar al moverse, desactivar al irse.

ConceptSCIM· 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.

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.

ConceptAuthorization 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.

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.

ConceptCross 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.

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.

§ 05

¿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.

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.

ConceptWarehouse · 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.

Tres capas: el cerebro arriba, clústeres de cómputo separados por equipo en el medio, una sola copia compartida de los datos abajo.

PlatformSnowflake· 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».

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.

ConceptVirtual 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.

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.

ConceptRoles 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.

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.

ConceptService 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.

Functions, Analyst, Search, Agents, Intelligence: todo dentro de Snowflake. El managed MCP server los abre a agentes externos.

PlatformCortex· 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.

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.

§ 06

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.

Personas y agentes arriba, el cómputo en el medio, Unity Catalog cuidando todo y los datos en el almacenamiento propio del cliente.

PlatformDatabricks· 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.

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.

ConceptDelta 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.

Notebooks, SQL y agentes pasan todos por la misma revisión. Unity Catalog da acceso a tablas, volumes y modelos, y lo registra.

ToolUnity 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.

Fuentes → bronze (tal como llegó) → silver (limpio) → gold (listo para el negocio). El agente lee gold.

PatternMedallion· 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.

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.

ToolSQL 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.

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.

PlatformAgent 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.

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.

§ 07

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».

Un tenant de Entra, una capacity paga, workspaces llenos de items y, debajo de todo, OneLake. Los datos externos entran por shortcut o mirroring.

PlatformMicrosoft 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.

Todos gastan de una sola capacity. Los picos cortos por encima se suavizan; demasiada deuda significa demoras y luego rechazos.

ConceptCapacity· 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.

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.

ToolSQL 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.

Un shortcut apunta a los datos donde ya viven. Mirroring mantiene en OneLake una copia Delta casi en tiempo real.

ConceptShortcuts 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.

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.

ToolFabric 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.

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.

§ 08

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.

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.

Los mismos cuatro sistemas: demasiado a la izquierda, lo justo a la derecha.

PrincipleLeast 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.

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.

ConceptAs 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.

Ocho preguntas que hace todo equipo de seguridad. Ten las respuestas por escrito antes de que pregunten.

PracticeSecurity 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.

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.

PitfallDay-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.

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 Stacknube · identidad · datos: Tres capas en toda empresa grande; tu agente queda entre ellas.

Nube: Azure

Microsoft Azurela nube de Microsoft: Ideas de nube conocidas, otros nombres; se elige porque «todo es Microsoft».
Resource Hierarchytenant · subscription · RG: Carpetas anidadas; un rol dado arriba se aplica a todo lo de abajo.
Container AppsApp Service · AKS · Functions: Contenedores serverless: el hogar habitual del backend de un agente.
Managed Identitysin contraseña: Una cuenta de app que obtiene tokens de Entra; nada que se pueda filtrar.
Key Vaultcaja fuerte de secretos: Donde viven los pocos secretos reales, leídos con un rol acotado.
Private EndpointVNet: Una IP privada para un servicio, para poder cerrarlo a internet.
Microsoft Foundryantes Azure AI Foundry: Model deployments, agentes y evaluaciones dentro del tenant del cliente.

Identidad: Entra ID

Identity ProviderIdP · SSO: La recepción de la empresa; una sola cuenta de trabajo abre todas las apps.
OIDC and SAMLauth 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 IDantes Azure AD: El directorio en la nube de Microsoft con personas, grupos y apps.
App Registration vs Service PrincipalEnterprise app: El pasaporte de la app, y su copia en un tenant, que es la que tiene los derechos.
Delegated vs Application Permissionsconsent: Actuar como el usuario, o como la propia app con admin consent.
App Rolesroles claim: Tus roles, asignados a grupos por su TI y revisados por tu backend.
Conditional Accessreglas de MFA: Reglas «si… entonces» en cada inicio de sesión; necesita Entra ID P1.
Microsoft Graphgraph.microsoft.com: Una sola API para los datos de Microsoft 365, limitada por los scopes del token.
Entra Agent IDagent blueprint: Un tipo de identidad para agentes de IA, gobernado como un empleado.

Identidad: Okta

OktaWorkforce Identity: El IdP neutral para empresas con proveedores mezclados; una org por empresa.
SCIMjoiner–mover–leaver: El IdP crea y desactiva usuarios en tu app de forma automática.
Authorization Serverorg vs custom: Org para el inicio de sesión; custom para los scopes de tu propia API.
Cross App AccessXAA · Agent SSO: Los agentes obtienen a través de Okta tokens cortos y registrados para otras apps.

Datos: Snowflake

Warehouse · Lake · Lakehousetres formas: Tablas estrictas, archivos en bruto, o archivos con reglas de tabla encima.
Snowflakecloud data warehouse: Analítica SQL con el almacenamiento y el cómputo separados.
Virtual Warehousecredits: Un clúster de cómputo facturado por segundo; configura auto-suspend en 60.
Roles and RBACAI_AGENT_RO: Los grants van a los roles, los roles a los usuarios; solo vistas para el agente.
Service UserTYPE = SERVICE: La cuenta de un programa; key pair u OAuth, contraseñas bloqueadas.
Cortexla IA junto a los datos: Funciones LLM, text-to-SQL, búsqueda y agentes dentro de Snowflake.

Datos: Databricks

Databrickslakehouse platform: Archivos en el almacenamiento del cliente; Spark, SQL e IA sobre las mismas tablas.
Delta LakeParquet + log: Una carpeta de archivos que se comporta como una tabla transaccional.
Unity Catalogun solo guardia: Grants, masks, lineage y auditoría para cada forma de entrar.
Medallionbronze · silver · gold: Capas de calidad; el agente lee gold.
SQL WarehouseOAuth M2M: Cómputo SQL; serverless arranca en segundos, classic en minutos.
Agent Bricksantes Mosaic AI: El paraguas de IA de Databricks: modelos, serving, gateway, AI Search, Genie.

Datos: Fabric

Microsoft FabricOneLake: Un solo almacén y una sola factura para todas las herramientas de datos de Microsoft.
CapacityF SKU · CU: Un pool de cómputo compartido; gastar de más lleva al throttling.
SQL Analytics EndpointT-SQL de solo lectura: Un lakehouse visto como SQL Server; ideal para las lecturas de un agente.
Shortcuts and Mirroringsin ETL: Apuntar a datos externos o mantener una copia en vivo en OneLake.
Fabric Data AgentFabric IQ: Un «chat con los datos» integrado y de solo lectura que actúa como el usuario.

Todo junto

Least Privilegederechos mínimos: Solo lo que el trabajo necesita, en el alcance más chico.
As the User vs As ItselfOBO vs service account: Los derechos de cada usuario, o una sola identidad cuya salida filtras tú.
Security Reviewla aprobación del cliente: Preguntas previsibles; ten las respuestas por escrito.
Day-One Accessla 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.