El despliegue de Microsoft Foundry en mi organización

Un plan de implementación estructurado le ayuda a evitar brechas de seguridad, saturaciones de costos y expansión del acceso al adoptar Microsoft Foundry a escala. Use esta guía para definir límites de carga de trabajo, elegir una topología de recursos y establecer la gobernanza para los equipos de autoservicio.

Requisitos previos

Antes de empezar a planear, confirme que tiene:

  • Comprensión de la configuración de referencia de la suscripción de Azure de su organización y de la organización de los grupos de recursos.
  • Información sobre los requisitos de seguridad de su organización en materia de redes, cifrado y aislamiento de datos.
  • Un plan de región inicial basado en la disponibilidad de características y modelos. Para más información, consulte Disponibilidad de características entre regiones en la nube.
  • Acuerdo sobre los requisitos de seguridad para redes, cifrado y aislamiento de datos en su organización.
  • Un inventario de las características y API de Foundry que los equipos planean usar.

Definición de límites de aislamiento

Comience con Cloud Adoption Framework guía de decisión para el uso compartido de plataformas de IA y aplique esas decisiones a Foundry:

Aunque cada situación es única, para la organización común se recomienda la siguiente secuencia:

  1. Defina límites de uso compartido no negociables entre unidades de negocio, dominios de datos, propiedad del producto y niveles de entorno.
  2. Establezca una directiva de producción con aislamiento como opción predeterminada, salvo que una excepción documentada permita la coubicación.
  3. Establezca una directiva de exploración que tenga como valor predeterminado la colocación para una experimentación más rápida, a menos que el cumplimiento o la validación requieran aislamiento.
  4. Asigne un responsable a cada límite, incluida la responsabilidad sobre la seguridad, los costes y la respuesta ante incidentes.

Identificación de los requisitos de funcionalidad y acceso

Determine qué características y API de Foundry requiere cada carga de trabajo antes de finalizar la topología.

Note

No todas las API de Foundry admiten toda la variedad de modos de autenticación, niveles de cifrado de almacenamiento y aislamiento de nivel de proyecto. Algunas de las API de Foundry Tools pueden requerir asignaciones de roles en el ámbito del recurso de Foundry primario.

Para los casos de uso ubicados conjuntamente que comparten un recurso Foundry, use proyectos de Foundry como áreas de trabajo aisladas para cada caso de uso. Por ejemplo, los equipos que experimentan con una idea pueden crear un proyecto para organizar recursos coherentes sin repetir la configuración de la infraestructura para la seguridad, las implementaciones de modelos y el acceso a herramientas.

La mayoría de las API foundry centradas en agentes más recientes admiten permisos de ámbito de proyecto. Algunas API tradicionales de Foundry Tools (anteriormente Azure AI Services), como la conversión de voz en texto, siguen necesitando acceso de ámbito de recursos primario. Planee límites y RBAC para que todas las funcionalidades necesarias sean accesibles en el ámbito de administración de acceso previsto.

Área de funcionalidad Organización por proyecto Aislamiento de RBAC de nivel de proyecto Traiga su propio almacenamiento Compatibilidad con redes y cifrado Implicación del planeamiento
Funcionalidades del agente (agentes, respuestas, evaluaciones, conjuntos de datos, índices, archivos y recursos de parque infantil) Limitado en la configuración básica (almacenamiento administrado). Para una cobertura completa, use "estándar". Buena opción para la segmentación de proyectos por caso en entornos compartidos.
Entrenamiento de ajuste fino No (solo proyecto predeterminado) No Parcial (solo entradas) Si cada equipo necesita un ajuste preciso independiente, utilice recursos de Foundry separados. Las implementaciones ajustadas se pueden compartir y utilizar entre proyectos dentro de un mismo recurso.
Imagen, vídeo y procesamiento por lotes de OpenAI No No Parcial (solo Batch) Use una configuración de carga de trabajo aislada y, si se requiere almacenamiento administrado, valide las restricciones de RBAC antes.
Descripción del contenido No Si se requiere aislamiento estricto de acceso por caso de uso, prefiera recursos de Foundry independientes.
Speech Sí (ajuste) No Limitado en la configuración básica (almacenamiento administrado). Para una cobertura completa de cifrado de CMK, use BYO Storage.
Language Sí (ajuste) No Limitado en la configuración básica (almacenamiento administrado). Para una cobertura completa de cifrado de CMK, use BYO Storage.
Translator No No No Utilice un recurso de Foundry independiente si el aislamiento es imprescindible.

Importante

Confirme la combinación exacta de funcionalidades antes del lanzamiento. Si una API necesaria solo funciona en el ámbito de recursos de Foundry, asigne roles en ese ámbito o aísle las cargas de trabajo en recursos de Foundry independientes.

Elección de la topología de recursos de Foundry

Después de definir los límites y las necesidades de funcionalidad, elija topología por entorno.

Ruta de acceso a la decisión Configuración recomendada de Foundry Mejor ajuste Compromiso principal
Cargas de trabajo ubicadas conjuntamente Un recurso Foundry con varios proyectos (normalmente un proyecto por caso de uso) Entornos intensivos de experimentación, prototipos iniciales y equipos que se benefician de implementaciones compartidas y herramientas o datos conectados compartidos Radio de explosión compartido para incidentes de producción, agotamiento de cuota y configuración incorrecta
Cargas de trabajo totalmente aisladas Un recurso de Foundry por cada límite de carga de trabajo de producción (a menudo, con un proyecto principal por carga de trabajo) Cargas de trabajo de producción que requieren una contención operativa estricta, un control de acceso independiente y límites de cuota o costo independientes La implementación de autoservicio es más difícil, con más recursos que gestionar y un mayor esfuerzo de configuración inicial.

Tip

Para producción, trate el aislamiento como valor predeterminado. Utilice la colocación únicamente como una excepción deliberada cuando estén alineados los límites de la carga de trabajo, los requisitos de datos y la aceptación del riesgo.

Captura de pantalla de un diagrama que muestra el recurso Foundry.

Planeamiento de la línea de base de seguridad

Use esta tabla de referencia como lista de comprobación para las decisiones de diseño de seguridad.

Area Qué decidir Comenzar con una
Identidad y acceso Defina los roles de administrador, administrador de proyectos y usuario del proyecto. Asigne cada perfil a roles de privilegios mínimos y grupos de Microsoft Entra ID. Control de acceso basado en rol en Foundry
Redes Elija el modelo de red por entorno. Use una red virtual administrada para una configuración más segura y sencilla. Use la red virtual bring-your-own (BYO) para el control de red avanzado y los requisitos de enrutamiento personalizados. Valida el DNS privado y el flujo de aprobación del punto de conexión antes de pasar a producción. Configuración de una red virtual administrada, Configuración del vínculo privado para Foundry y configuración protegida por red (red virtual BYO)
Protección y claves de datos Decida si las claves administradas Microsoft cumplen los requisitos de directiva o si se requieren claves administradas por el cliente. Claves administradas por el cliente en Foundry
Modelo de autenticación Prefiere Microsoft Entra ID y RBAC para personas y servicios. Use claves de API solo cuando no se requiera granularidad de roles. Control de acceso basado en rol en Foundry

Planeamiento del modelo, la región y la estrategia de capacidad

Para cada carga de trabajo, defina:

  • Familias de modelos y tipos de implementación requeridos por el caso de uso.
  • Requisitos de procesamiento de datos (por ejemplo, restricciones globales o regionales).
  • Objetivos de rendimiento y latencia para escenarios interactivos y por lotes.
  • Requisitos de cuota y capacidad aprovisionada para cargas de estado estable y pico.

Utilice estas referencias:

Planeamiento de la conectividad y la integración de datos

Para cada carga de trabajo, identifique las dependencias externas y los patrones de conexión:

  • Orígenes de datos y almacenes de datos.
  • API internas y sistemas de línea de negocio.
  • Herramientas SaaS no Azure requeridas por agentes o flujos de orquestación.
  • Requisitos de red, incluidos los puntos de conexión privados, la resolución DNS, los controles de salida y si se requiere una red administrada o una red virtual BYO.

Use Agregar conexiones en Foundry para estandarizar la configuración de la conexión.

Se pueden conexiones crear tanto en el nivel del recurso de Foundry principal como en el nivel del proyecto secundario, en función del ámbito de aislamiento deseado. Las conexiones configuradas en el nivel primario están disponibles para todos los proyectos.

Captura de pantalla de un diagrama que muestra la conectividad e integración del proyecto Foundry con otros servicios Azure.

Planeamiento de la automatización y las operaciones

Defina cómo los equipos crean y administran recursos de forma coherente entre entornos.

  • Utilice infraestructura como código para aprovisionar recursos básicos y las configuraciones predeterminadas de las directivas.
  • Normalice las canalizaciones de implementación para proyectos, conexiones, implementaciones de modelos y cambios de configuración.
  • Defina los procedimientos de reversión y respuesta a incidentes para los cambios de modelo y directiva.

Para los patrones de automatización y las implementaciones de inicio, use:

Las plantillas de ejemplo incluyen patrones de un extremo a otro para escenarios de seguridad comunes, como redes privadas, claves administradas por el cliente y control de acceso basado en roles.

Definir barreras de protección de autoservicio

Habilite el autoservicio solo dentro de restricciones claras:

  • Defina qué roles pueden crear proyectos, implementar modelos y conectar herramientas externas.
  • Aplique controles de directiva para el comportamiento de implementación y tiempo de ejecución del modelo, incluidos los proveedores de modelos y qué conexiones de herramientas se permiten.
  • Establezca controles de costos y alertas presupuestarias para entornos compartidos y aislados.
  • Aplicar registro de seguimientos a la observabilidad central en Microsoft Foundry, Microsoft Copilot Studio y Microsoft 365.

Utilice estas referencias:

Asignación de propiedad y gobernanza

Trate este paso como la transición de la infraestructura aprovisionada al uso del desarrollador operativo.

La mayoría de las organizaciones ya administran el acceso a través de grupos de Microsoft Entra ID creados previamente. Asigne esos grupos a roles de Foundry en el ámbito necesario y, a continuación, valide las rutas de acceso de administración y desarrollo.

Foundry divide el acceso en:

  • Acciones de RBAC del plano de control para administración de recursos.
  • Acciones RBAC del plano de datos para cargas de trabajo de desarrollo.

Importante

Los roles de administración como Propietario o Colaborador no son suficientes para todos los escenarios de desarrollo. Por ejemplo, un usuario puede administrar recursos, pero aún necesita roles de plano de datos para chatear con un agente en Foundry.

Para obtener instrucciones de asignación de roles y combinaciones de roles necesarias, consulte Control de acceso basado en roles en Foundry.

Después de incorporar los grupos de usuarios, considere la posibilidad de establecer o expandir paneles de gobernanza para realizar un seguimiento del uso, la confiabilidad, el linaje y el cumplimiento de Foundry:

Despliegue de plataforma de ejemplo

La organización de TI de Contoso debe admitir varios equipos a la vez que equilibra dos prioridades:

  • Innovación rápida, donde los desarrolladores pueden probar rigurosamente las tecnologías de inteligencia artificial más recientes mediante datos que no son de producción.
  • Entornos totalmente aislados de desarrollo/pruebas y de producción para casos de uso probados que reciben financiación para su puesta en operación.

En el diagrama se muestra cómo Contoso localiza conjuntamente una instancia de Foundry de exploración compartida para la innovación, disponible para todos los equipos, con capacidad limitada y herramientas y datos previamente conectados. La lista de trabajo pendiente de ejemplo refleja funciones empresariales habituales, como atención al cliente, servicio de asistencia al empleado, operaciones financieras, compras y ventas. Históricamente, solo unos pocos casos de uso llegan a demostrar su viabilidad o a obtener financiación para un despliegue de desarrollo/pruebas. De estas, un subconjunto aún más pequeño pasa a producción. La muestra también presenta dos casos de uso de ventas relacionados que siguen coubicados durante la exploración y desarrollo/pruebas porque comparten los mismos datos de CRM, perfiles de usuario y sistemas conectados. A medida que los casos de uso maduran, a los equipos se les asignan entornos con aislamiento progresivamente más fuerte, que culminan en la separación completa de nivel prod cuando sea necesario.

Diagrama que muestra los casos de uso de Contoso que pasan de un entorno compartido de Foundry de exploración a entornos de desarrollo y pruebas aislados o coubicados y, a continuación, a entornos de producción aislados para un número menor de cargas de trabajo.

Aprende más

Paso siguiente