Los mismos modelos de OpenAI, pero corriendo dentro del perímetro de seguridad de Azure: sin eso, muchas empresas reguladas ni siquiera podrían evaluar GPT como opción.
Azure OpenAI Service despliega los mismos modelos que la API de OpenAI (GPT-4o, GPT-4.1, la serie de razonamiento o1/o3, embeddings, DALL-E 3, Whisper) pero dentro de la infraestructura y el modelo de responsabilidad compartida de Azure. La diferencia no está en la capacidad del modelo, está en el contrato operativo: aislamiento de red por VNet, control de identidad vía Microsoft Entra ID en lugar de API keys sueltas, residencia de datos garantizada por región, y el compromiso contractual de que las entradas y salidas no se usan para reentrenar los modelos base de OpenAI.
Para un CTO evaluando riesgo, esto cambia la conversación con legal y compliance de "no podemos usar IA generativa" a "podemos usarla bajo los mismos controles que ya auditamos en Azure".
El catálogo incluye modelos multimodales (GPT-4o procesa texto, imagen y audio), modelos de razonamiento extendido (o1, o3-mini, orientados a tareas de planificación y matemática donde el modelo "piensa" antes de responder), modelos de embeddings (text-embedding-3-small y large, clave para RAG), y generación de imagen y audio (DALL-E 3, GPT-4o transcribe, Whisper). No todos los modelos están disponibles en todas las regiones ni con la misma cuota; verificar disponibilidad regional es el primer paso antes de diseñar arquitectura, especialmente si hay requisito de residencia de datos en Latinoamérica o Europa.
Existen dos modelos de consumo. Pay-as-you-go factura por token consumido y comparte capacidad con otros clientes en el mismo pool regional, lo que introduce variabilidad de latencia en picos de demanda global. Provisioned Throughput Units (PTU) reserva capacidad de cómputo dedicada, con latencia predecible y throughput garantizado, a cambio de un compromiso de capacidad (por hora o mensual/anual con descuento). La regla práctica: cargas de trabajo con SLA de latencia estricto o volumen alto y constante justifican PTU; prototipos y cargas esporádicas se quedan en pay-as-you-go.
En producción empresarial, el endpoint de Azure OpenAI se expone vía Private Endpoint dentro de una VNet, eliminando exposición a internet público. La autenticación se hace con managed identity en lugar de claves estáticas, eliminando el riesgo de una API key filtrada en un repositorio.
Cada llamada a Azure OpenAI pasa, por defecto, por filtros de Azure AI Content Safety que evalúan violencia, contenido sexual, autolesión y odio en cuatro niveles de severidad, tanto en el prompt de entrada como en la respuesta generada. Estas políticas se pueden ajustar por caso de uso (con aprobación de Microsoft para casos que requieren umbrales más permisivos, como investigación médica) y quedan registradas para auditoría.
Azure OpenAI hereda las certificaciones de Azure: SOC 1/2/3, ISO 27001, HIPAA (con BAA disponible), FedRAMP High en Azure Government, y cumplimiento con GDPR. Los datos de inferencia no salen de la región seleccionada salvo que se configure explícitamente lo contrario, y clientes elegibles pueden solicitar exención del monitoreo de abuso humano cuando su caso de uso maneja datos sensibles y ya tienen controles propios de mitigación de riesgo.
Un patrón común en clientes empresariales: API Management como capa de fachada frente a Azure OpenAI (para rate limiting, versionado y enmascarar el endpoint real), Private Link entre API Management y el recurso de OpenAI, Key Vault para cualquier secreto residual, y Azure Monitor con alertas sobre consumo de tokens y códigos 429 para detectar saturación de cuota antes de que afecte a usuarios finales.
Carlos Montiel es arquitecto de soluciones IA empresarial. Implementa LLMs, Agentes, RAG y orquestadores en empresas de Guatemala y Latinoamérica. Contáctalo para una consultoría.
Contactar a Carlos Montiel