Su equipo de seguridad aprobó la suscripción a Azure. Su equipo de cumplimiento aprobó el acuerdo de manejo de datos. Su equipo legal revisó el contrato del proveedor. Y ahora alguien en una reunión del martes por la tarde pregunta cuándo se puede “comenzar a enviar indicaciones” a la modelo. Este es el momento en el que las implementaciones de IA empresarial se hacen bien o rápidamente, y esas dos cosas rara vez son lo mismo.

Implementando Servicio Azure OpenAI en un entorno corporativo no es como utilizar una herramienta SaaS. Los datos que fluyen a través de él (consultas de los empleados, aportaciones de los clientes, documentos internos introducidos en los canales de recuperación) pueden ser confidenciales, estar regulados o ambas cosas. Equivocarse en la arquitectura al principio significa modernizar los controles de seguridad más adelante, lo cual es costoso, doloroso y el tipo de cosas que se documentan en las autopsias de incidentes.

Aquí le mostramos cómo hacerlo bien desde el primer día.

Bloquee la red primero

La configuración predeterminada de Azure OpenAI expone un punto de conexión público. Eso significa que cualquier persona con una clave API válida puede llamar a su modelo desde cualquier lugar de Internet. Para una implementación corporativa, eso no es aceptable.

La solución es Enlace privado de Azureque aprovisiona un punto final privado dentro de su red virtual (VNet). El tráfico hacia el modelo nunca sale de la columna vertebral de Microsoft: no hay tránsito público de Internet ni exposición a análisis externos. Una vez que habilita esto, deshabilita explícitamente el acceso a la red pública en la configuración de red de Azure OpenAI. No “restringirlo”. Desactívelo. La distinción importa cuando un auditor hace preguntas.

Consejo profesional: no habilite Private Link y deje el acceso público en “redes seleccionadas” como alternativa. Eso no es un control de seguridad; es una puerta que dejaste abierta porque no pudiste encontrar la llave.

La mayoría de las empresas que implementan IA a escala ya ejecutan una topología de red Hub-and-Spoke. Coloque el recurso Azure OpenAI en una Spoke VNet, con su Hub VNet central manejando la inspección del firewall, la resolución de DNS y el filtrado de salida a través de Cortafuegos azul. El emparejamiento de VNet los conecta. Cada solicitud al modelo se enruta a través del Hub para su inspección antes de que llegue al recurso.

Si también necesita servicios específicos de Azure, como un Búsqueda de IA en Azure instancia para una canalización RAG: para llegar al punto final de OpenAI, utilice reglas de instancia de recursos. Estos permiten que los recursos de Azure con nombre omitan la restricción del firewall y al mismo tiempo mantengan el punto de conexión privado. Es más estricto que la lista de IP permitidas y sobrevive a los cambios de infraestructura sin actualizaciones manuales.

Reemplace las claves API con identidades administradas

Las claves API son prácticas para empezar. También es fácil enviarlos accidentalmente a un repositorio, difíciles de auditar y tediosos de rotar. A escala empresarial, se convierten en un problema de seguridad incluso antes de que se envíe el proyecto.

El enfoque correcto es Identidades administradas. Su aplicación, ya sea que se ejecute en Azure App Service, Azure Kubernetes Service o una función de Azure, obtiene una identidad asignada por el sistema o por el usuario respaldada por Microsoft Entra ID (anteriormente Azure AD). No hay credenciales que administrar, ni secretos en las variables de entorno, ni nadie que pegue claves API en Slack.

Una vez establecida la identidad, asigne el Cognitive Services OpenAI User rol a través de Control de acceso basado en roles (RBAC). Esa función otorga exactamente lo que la aplicación necesita para realizar llamadas de inferencia, nada más. Evite asignar Cognitive Services Contributor o Owner a identidades en tiempo de ejecución. ¿Te suena familiar? Debería. El privilegio mínimo se aplica aquí de la misma manera que en cualquier otro lugar.

Comprenda lo que Microsoft hace (y no hace) con sus datos

Esto surge en cada revisión de cumplimiento, y la respuesta es realmente tranquilizadora: Microsoft no utiliza indicaciones ni completaciones de los clientes para entrenar o mejorar los modelos OpenAI subyacentes. Eso está contractualmente establecido y documentado en Documentación de privacidad de datos de Azure.

Lo que controlas es el cifrado. De forma predeterminada, los datos en reposo se cifran con claves administradas por Microsoft. Para los servicios financieros, la atención médica u otras industrias reguladas, eso a menudo no es suficiente. Necesitará claves administradas por el cliente (CMK) almacenadas en Bóveda de claves de AzureY cuando configure ese Key Vault, habilite la protección de eliminación temporal y depuración. Si una clave se elimina accidentalmente y no puedes recuperarla, perderás el acceso a tus datos. Esa conversación con el CISO no es algo que desee tener.

Azure OpenAI también admite el cifrado de infraestructura, que agrega una segunda capa de cifrado a nivel del disco físico. Es una característica opcional, pero si está construyendo para una industria que requiere cifrado profundo, habilítela durante el aprovisionamiento. Para modernizarlo más adelante es necesario volver a implementarlo.

Estos se heredan de la plataforma Azure, no son específicos del servicio OpenAI. Verificar el alcance actual en el Documentación de cumplimiento de Azure antes de comprometerse con una hoja de ruta de cumplimiento: las certificaciones pueden variar según la región y el nivel de servicio.

Configure el filtrado de contenido antes de que alguien envíe un mensaje

Azure OpenAI incluye Seguridad del contenido de IA de Azure como una capa incorporada. De forma predeterminada, selecciona cuatro categorías: odio, contenido sexual, violencia y autolesión. Cada categoría tiene umbrales de gravedad configurables (seguro, bajo, medio, alto) y usted decide qué se bloquea.

Para una aplicación orientada al cliente, “bloquear todo lo que esté por encima del nivel Bajo” es un punto de partida razonable. Para las herramientas internas utilizadas por analistas de seguridad o profesionales médicos, es posible que deba ajustar esos umbrales para que no se marquen consultas legítimas. El punto es que configure esto antes de la implementación, no después del primer incidente.

Advertencia: La política de filtrado de contenido predeterminada no está “desactivada”, pero tampoco está configurada para su caso de uso específico. Revise y personalice la política antes de pasar a producción. “Usamos los valores predeterminados” no es una respuesta defendible cuando alguien pregunta por qué el modelo respondió de la forma en que lo hizo.

También puede cargar listas de bloqueo personalizadas para evitar que el modelo discuta temas específicos, mencione competidores o haga referencia a información interna confidencial. Esto es particularmente útil para los asistentes externos donde se cruzan el riesgo legal y de marca.

Cree la arquitectura de registro de auditoría en torno a APIM

Este es el problema con el registro de diagnóstico estándar de Azure para servicios de IA: captura metadatos (recuentos de solicitudes, latencia, tasas de error) pero no el contenido real de las solicitudes y finalizaciones. Esto es por diseño, por razones de privacidad. Para una empresa que necesita demostrar lo que el modelo le dijo a un usuario específico en una fecha específica, eso es insuficiente.

La solución es colocar Gestión de API de Azure (APIM) frente al punto final de Azure OpenAI. APIM tiene una capacidad nativa de “Registrar mensajes de LLM” que captura cargas útiles completas de solicitudes y respuestas y las enruta a un espacio de trabajo de Log Analytics. Obtiene el contenido de la conversación, el recuento de tokens, los parámetros del modelo: todo lo que necesita para la reconstrucción de la auditoría.

Habilite la configuración de diagnóstico en el propio recurso de Azure OpenAI para la supervisión operativa: latencia por modelo, tasas de éxito de solicitudes, limitación de eventos. Y habilite el registro de actividad de Azure para realizar un seguimiento de las acciones administrativas: quién cambió la política de filtrado de contenido, quién regeneró una clave API y quién modificó las reglas de red. Ésa es su pista de auditoría de gestión de cambios.

Información clave: el registro de actividad de Azure y los registros de solicitudes de APIM resuelven diferentes problemas. Los registros de actividad responden “quién cambió el sistema”. Los registros APIM responden “qué dijo el sistema”. Necesitas ambos.

Planifique la carga de producción antes de que sea necesario

Si está creando un sistema RAG de producción (búsqueda de documentos, bases de conocimiento internas, asistentes de atención al cliente), el modelo de pago por uso (PAYG) eventualmente creará problemas. La facturación basada en tokens con capacidad compartida implica picos de latencia bajo carga, y esos picos tienden a ocurrir exactamente en el momento equivocado.

Unidades de rendimiento aprovisionadas (PTU) brindarle capacidad dedicada con rendimiento garantizado y latencia constante. Usted reserva computación por región por modelo y esa capacidad es suya. La compensación es el compromiso: las PTU requieren compras de capacidad reservada en lugar de facturación por consumo.

Para la mayoría de las implementaciones empresariales, la respuesta correcta es un modelo híbrido: PTU para su carga de trabajo predecible de referencia, PAYG para manejar picos. Su asignación de PTU debe cubrir la carga de estado estable que pueda pronosticar; PAYG maneja el desbordamiento sin necesidad de aprovisionar en exceso la capacidad reservada. Trabaje con su equipo de cuentas de Azure para evaluar esto antes de comprometerse: la compra de PTU no es trivialmente reversible.

La arquitectura no es opcional

La conversación sobre la seguridad de la IA tiende a ocurrir de dos maneras: antes de la implementación, cuando todavía hay tiempo para construirla correctamente, o después de un incidente, cuando no lo hay. Puntos finales privados, identidades administradas, políticas de filtrado de contenido, registros basados ​​en APIM, cifrado CMK: estas no son características que agregue cuando el proyecto madure. Son la base sobre la que se ejecuta el proyecto.

Las organizaciones que hacen esto bien son las que trataron la gobernanza de la IA empresarial como un problema de infraestructura desde el primer día, no como una casilla de verificación de cumplimiento a la que eventualmente llegarían. Ahora tienes la arquitectura para hacer eso. La reunión de pie puede esperar.