Azure OpenAI en producción: cuotas, red y el modelo de permisos

Los pilotos de Azure OpenAI casi nunca fracasan por la calidad de las respuestas. Fracasan por tres cosas operativas que nadie mira durante la demo: al despliegue se le acabó la cuota, el equipo de seguridad no aprobaba un endpoint público y nadie sabía explicar por qué un comercial podía recuperar un documento de recursos humanos.

Esta es la forma que sobrevive a las tres.

La cuota es la primera restricción de arquitectura

La capacidad de Azure OpenAI se asigna como tokens por minuto, por modelo, por región y por suscripción. Dos consecuencias que moldean el diseño:

• La cuota que tienes en tu región preferida puede no ser la que necesitas. Planifica varios despliegues regionales detrás de un enrutador desde el principio, aunque al principio uses uno solo. Añadir el segundo después significa cambiar todos los clientes.
• La cuota de pago por uso es compartida y puede limitar. Las unidades de rendimiento aprovisionado te dan capacidad dedicada y predecible con un perfil de latencia que puedes poner en un SLA. El punto de cruce está en un volumen alto y estable; por debajo, los despliegues estándar con reintentos y espera exponencial salen más baratos.

Pon Azure API Management delante de los despliegues. Te da cuotas de tokens por consumidor, reintentos entre regiones ante un 429, un único endpoint para los clientes y, sobre todo, medición de uso por equipo. Sin medición no puedes responder "cuánto cuesta esto por equipo", y esa pregunta llega siempre.

Red, que es lo que el equipo de seguridad pregunta de verdad

Los endpoints por defecto de Azure OpenAI son públicos con autenticación por clave. Vale para un piloto y suele ser inaceptable en producción con datos de clientes. La forma de producción:

• Endpoint privado dentro de tu VNet, acceso de red público desactivado.
• Autenticación con Entra ID e identidades gestionadas, no claves de API. Las claves en un Key Vault siguen siendo claves; una identidad gestionada no tiene nada que filtrar.
• Claves gestionadas por el cliente para los datos en reposo del recurso, si tu marco de cumplimiento lo exige.
• Configuración de diagnóstico hacia Log Analytics, para que los metadatos de prompts y respuestas sean auditables. Sé deliberado sobre si registras el contenido — puede ser justo lo que necesitas para depurar y justo lo que no debes conservar según tus compromisos de privacidad.

La recuperación y el problema de los permisos

Azure AI Search es la capa natural de recuperación y admite lo que importa: filtros de seguridad en el momento de la consulta. Indexa cada documento con los identificadores de seguridad de los grupos autorizados a verlo y pasa la pertenencia a grupos de quien pregunta como filtro en cada consulta.

Dos reglas de proyectos que salieron mal:

Filtra en la recuperación, nunca después. Si recuperas de forma amplia y filtras en el código de la aplicación antes de mostrar resultados, al modelo ya se le ha dado el texto. Cualquier inyección de prompt o paso de resumen lo filtra.

Resincroniza permisos, no solo contenido. Tu pipeline de ingesta probablemente se ejecuta cuando cambia un documento. Los permisos cambian sin que cambie el documento —alguien deja un equipo— y una ACL rancia en el índice es una exposición de datos real. Programa una resincronización de permisos aparte.

Más allá de eso, AI Search te da recuperación híbrida (BM25 más vectores) y ranking semántico. Activa ambos. La recuperación solo vectorial se pierde los identificadores exactos, que en un corpus corporativo son códigos de producto, números de ticket y nombres — justo lo que la gente busca.

Seguridad de contenido y anclaje

Los filtros de Azure AI Content Safety se aplican en entrada y salida, con umbrales de severidad configurables y un escudo de prompts para intentos de jailbreak e inyección indirecta. La inyección indirecta importa más de lo que se espera en un sistema RAG: la carga del atacante llega dentro de un documento recuperado, no del usuario.

Añade una comprobación de anclaje de la respuesta generada contra los pasajes recuperados, y haz que el asistente se abstenga en lugar de adivinar por debajo de un umbral. Decir "no he encontrado esto" es una función, y es el comportamiento que más determina si la gente sigue usando el asistente después de la tercera semana.

Coste y evaluación

Sigue el coste por pregunta, por equipo, desde la primera semana. Agrupa los embeddings en lotes, cachea con agresividad y usa un modelo pequeño para reescribir consultas y enrutar — el patrón general está en las cuatro decisiones que deciden un proyecto de RAG.

Y escribe el conjunto de evaluación antes de construir: cincuenta preguntas reales, cada una con el documento que debería responderla, ejecutadas en cada cambio. Las herramientas de evaluación de Azure AI Foundry ejecutarán sobre él métricas de anclaje, relevancia y recuperación, pero las preguntas tienen que venir de tus usuarios. Ese conjunto es el artefacto que los proyectos atascados resulta que no tienen, y por eso es lo primero que construimos en un proyecto de IA aplicada.

Qué hacer esta semana

Comprueba tu cuota de tokens por minuto para el modelo que usas, en la región que usas, y divídela entre los tokens que consume tu petición media. Ese número es tu techo real de concurrencia, y casi ningún equipo lo ha calculado.