🤖 Azure AI Foundry: Arquitectura, Seguridad & Gobernanza de GenAI
Guía de nivel principal sobre el diseño, aislamiento de equipos, administración de cuotas, controles de red privada, políticas de filtrado y evaluación continua en Azure AI Foundry.
01. Hub vs Proyecto: Patrón de Aislamiento de Equipos
El modelo jerárquico de Azure AI Foundry separa la infraestructura crítica de la capa de experimentación y desarrollo mediante el esquema Hub & Projects.
El Hub (Recurso Padre)
Es administrado exclusivamente por el equipo de Plataforma / DevOps. Centraliza todos los componentes costosos y complejos de configurar:
- Networking: Managed VNet, Private Endpoints e Ingress/Egress rules.
- Recursos de soporte: Conexiones fijas a Key Vault, Storage Accounts y AI Search.
- Políticas globales: Connections compartidas y configuraciones de seguridad.
El Proyecto (Recurso Hijo)
Es asignado a equipos de desarrollo o Data Science. Hereda automáticamente toda la seguridad del Hub sin permitir su alteración:
- Espacio autónomo para desarrollar prompt flows, crear deployments y realizar evaluaciones.
- RBAC delimitado a nivel de Proyecto (los ingenieros no pueden tocar el Hub).
- Consumo transparente de conexiones compartidas.
hub-prod-eastus) controlado por Plataforma, y un Proyecto por equipo o caso de uso (ej: proj-chatbot-finance). Los data scientists obtienen autonomía total en su proyecto sin comprometer la infraestructura de red o las credenciales globales.
02. Opciones de Despliegue: ¿Serverless, Managed Compute o Azure OpenAI?
La elección del modelo de ejecución determina la estructura de costos, la latencia y la responsabilidad operativa.
| Modelo de Despliegue | Mecanismo de Cobro | Caso de Uso Principal | Ventajas & Desventajas |
|---|---|---|---|
| Serverless API | Pay-as-you-go (por 1K tokens procesados). | Modelos del catálogo (Llama 3, Mistral, Cohere) con tráfico variable o no predecible. | Pro: Cero administración de infra. Contra: Menos control sobre la GPU subyacente. |
| Managed Compute | Pago fijo por hora de VM/GPU (incluso ocioso). | Modelos que solo ofrecen formato IaaS/VM o cargas con throughput constante. | Pro: Control total del entorno e instancias dedicadas. Contra: Gestión operativa de compute. |
| Azure OpenAI (Standard) | Pay-as-you-go basado en consumo de tokens. | Aplicaciones generales que consumen GPT-4o o Embeddings sin garantía estricta de SLA. | Pro: Sin costo fijo inicial. Contra: Posible throttling (HTTP 429) en picos globales. |
| Azure OpenAI (PTU) | Provisioned Throughput Units (reserva fija). | Producción crítica con alta demanda que exige latencia predecible y cero throttling. | Pro: Rendimiento garantizado. Contra: Compromiso financiero y costo inicial alto. |
03. Gestión de Cuotas TPM y Contención entre Equipos
La cuota de Azure OpenAI se asigna a nivel de Suscripción y Región expresada en Tokens Per Minute (TPM). Cuando múltiples proyectos compiten por la misma cuota, se generan cuellos de botella y errores HTTP 429 (Too Many Requests).
💡 Estrategia de Gobernanza de Cuotas:
1. Asignación Explícita: Distribuir cuota de TPM por deployment en función de la prioridad del negocio.
2. Reserva PTU: Aislar cargas de producción críticas mediante PTUs para evitar la contención por cuota compartida.
3. AI Gateway (Azure API Management): Colocar un API Gateway delante de los servicios de IA para aplicar rate-limiting por consumidor, balancear solicitudes entre múltiples regiones/cuentas y registrar métricas de consumo exactas por equipo.
4. Aislamiento Físico: Si la contención persiste, migrar los equipos a suscripciones independientes, ya que la cuota está delimitada por suscripción-región.
04. Asegurando la Red del Hub & Reglas Outbound
En entornos empresariales y regulados, el acceso público al Hub de AI Foundry debe deshabilitarse completamente (publicNetworkAccess: Disabled).
Private Endpoints
El tráfico de los desarrolladores y aplicaciones debe ingresar a través de ExpressRoute o VPN privada conectada a la VNet. Se crean Private Endpoints dedicados para:
• El Hub de AI Foundry
• Azure Storage Account
• Azure Key Vault
• Azure AI Search / Azure OpenAI
Outbound Rules Restringidas
La VNet administrada del Hub puede configurarse en modo "Allow only approved outbound". En este modo, es imperativo autorizar las FQDNs explícitas requeridas por el Model Catalog y Serverless APIs para comunicarse con las dependencias de Microsoft.
Costo Operativo: Bloquear todo requiere mantener una lista blanca activa de endpoints para evitar fallos en la descarga de pesos de modelos.
05. Roles RBAC Específicos & Connections Passwordless
La seguridad en el plano de control y de datos exige descartar el uso de API Keys compartidas en favor de roles RBAC granulares y Managed Identities.
Matriz de Roles RBAC en AI Foundry
| Rol RBAC | Nivel de Asignación | Permisos Otorga / Restringe |
|---|---|---|
| Azure AI Developer | Proyecto | Permite: Desarrollar prompt flows, crear deployments y consumir connections. Restringe: No puede crear ni modificar Hubs, redes ni RBAC. |
| Azure AI Inference Deployment Operator | Proyecto / Hub | Permite: Gestionar y actualizar únicamente los deployments de inferencia de modelos. |
| Cognitive Services OpenAI User | Recurso de IA | Permite a identidades de aplicación (Service Principals/Managed Identities) consumir inferencia (Data Plane). |
| Contributor / Owner | Hub / Suscripción | Reservado exclusivamente para el equipo de Plataforma/DevOps para administrar infraestructura. |
Gestión de Credenciales en Connections
Las Connections son referencias reutilizables hacia recursos externos (AI Search, Storage, Azure OpenAI). Se almacenan encriptadas en el Key Vault vinculado al Hub. La arquitectura recomendada elimina completamente los secretos mediante Connections basadas en Entra ID y Managed Identity, evitando los ciclos de rotación manual.
06. Content Safety & Filtros Personalizados
Azure AI Content Safety analiza entradas (prompts) y salidas (respuestas) clasificando el contenido en 4 categorías: Odio, Violencia, Contenido Sexual y Autolesión.
07. Evaluación de LLMs & Observabilidad Continua
La validación de aplicaciones GenAI no se limita al despliegue inicial; requiere un ciclo continuo de evaluación cuantitativa y cualitativa.
Evaluaciones Pre-Release
Se ejecutan usando un "Modelo Juez" (LLM-as-a-Judge) contra datasets de prueba integrados al pipeline de CI/CD como quality gate:
- Calidad: Groundedness (fundamentación), Relevance (relevancia), Coherence y Fluency.
- Riesgo: Evaluación de vulnerabilidades a Jailbreaks y contenido dañino.
Monitoreo Continuo & Tracing
Tracing distribuido mediante exportación directa a Application Insights:
- Captura de prompts, herramientas (tools) invocadas, tokens utilizados y latencia end-to-end.
- Evaluación continua sobre muestras de tráfico real para detectar degradación o alucinaciones en producción.
08. Gobernanza de Modelos del Catálogo con Azure Policy
Para evitar el uso no autorizado de modelos no evaluados o costosos, las organizaciones aplican gobernanza declarativa a nivel de infraestructura.
💡 Mecanismo de Control con Azure Policy:
Mediante políticas integradas de Azure Policy asignadas a nivel de Management Group, se restringe el despliegue de modelos del catálogo por colección, proveedor o lista blanca explícita. Al utilizar el efecto deny, la plataforma rechaza automáticamente cualquier intento de despliegue no autorizado, garantizando que solo los modelos aprobados por el Centro de Excelencia (AI CoE) sean operables.