Stratégies intégrées pour le déploiement de modèles dans le portail Microsoft Foundry

Azure Policy fournit des définitions de stratégie intégrées qui vous aident à régir le déploiement de modèles IA dans Microsoft portail Foundry. Vous pouvez utiliser ces stratégies pour contrôler les modèles que vos développeurs peuvent déployer dans le portail Foundry.

Note

Pour déployer et utiliser le routeur model pendant que cette stratégie est affectée, incluez Microsoft dans la liste des éditeurs autorisés, car Microsoft est l’éditeur du routeur de modèle. Incluez également le nom de l’éditeur de chaque modèle pris en charge que vous déployez pour le routage, comme indiqué sur la carte du modèle dans le catalogue de modèles. Par exemple, pour rediriger vers des modèles Claude, déployés séparément, incluez également Anthropic. Si la liste des éditeurs autorisés n’inclut pas ces noms, la stratégie bloque le déploiement du routeur de modèle.

Conditions préalables

Microsoft Foundry fournit des définitions de Azure Policy intégrées pour vous aider à régir les modèles qui peuvent être déployés dans votre organisation. Les définitions suivantes s’appliquent aux déploiements de modèles :

Policy Purpose Status
Lors du déploiement de modèles Foundry, seuls des modèles approuvés doivent être utilisés Limitez les déploiements à une liste spécifique de modèles ou d’éditeurs que votre organisation approuve explicitement. Généralement disponible
Les déploiements de modèles Foundry doivent répondre aux exigences d’éligibilité Limitez les déploiements en fonction des attributs du modèle, tels que la source (directement depuis Azure) et le statut du cycle de vie (Aperçu). Généralement disponible

Les deux stratégies sont évaluées au moment du déploiement. Le catalogue ne masque pas les modèles. Au lieu de cela, l’action Déployer est désactivée avec une raison claire lorsqu’une stratégie bloque le déploiement. Vous pouvez attribuer une ou les deux stratégies en fonction de vos besoins de gouvernance.

Note

Ces stratégies régissent également les modèles sous-jacents que le routeur de modèle sélectionne. Le routeur de modèle achemine uniquement les requêtes vers des modèles qui répondent à vos stratégies affectées. Par conséquent, les mêmes règles d’approbation et d’éligibilité s’appliquent si vous déployez un modèle directement ou utilisez le routeur de modèle pour choisir un modèle par requête. En outre, les définitions de stratégie intégrées dédiées pour le routeur de modèle sont disponibles en version préliminaire publique. Ces définitions étendent la gouvernance à d’autres aspects des déploiements de routeur de modèle, notamment les régions de déploiement, les règles de routage requises et les configurations de journalisation. Pour plus d’informations, consultez Gérer les déploiements de routeurs de modèle avec Azure Policy.

Fonctionnement de ces stratégies

Les deux stratégies sont complémentaires et répondent à différentes questions de gouvernance :

  • Les modèles approuvés répondent à la question « Ce modèle exact figure-t-il sur la liste verte de mon organisation ? » — en fonction de l’identité du modèle.
  • Les critèresd’éligibilité répondent-ils à « Ce modèle répond-il aux normes de mon organisation pour la source et la maturité ? » en fonction des attributs du modèle.

Si vous attribuez les deux stratégies et qu’un modèle n’est conforme à aucune des deux, l’expérience Deploy affiche d’abord le motif ayant la priorité la plus élevée (approbation, puis éligibilité), afin que les utilisateurs reçoivent un message unique, clair et sur lequel ils peuvent agir.

Les déploiements de modèles Foundry ne doivent utiliser que des modèles approuvés

Utilisez cette stratégie pour limiter les déploiements à une liste spécifique de modèles ou d’éditeurs que votre organisation approuve explicitement.

Note

Cette stratégie portait auparavant le nom Les déploiements de Cognitive Services ne doivent utiliser que des modèles de registre approuvés. L’ID de définition de stratégie n’est pas modifié, de sorte que les affectations existantes continuent de fonctionner sans aucune action.

Attribuer la stratégie de modèles approuvés

Utilisez Azure CLI pour rechercher la définition de stratégie intégrée et l’affecter à une étendue.

  1. Connectez-vous et sélectionnez l’abonnement dans lequel vous souhaitez travailler :

    az login
az account set --subscription "<subscription-id>"

  2. Recherchez l’ID de définition de stratégie pour la définition intégrée :

    az policy definition list \
   --query "[?displayName=='Foundry model deployments should only use approved models'].{name:name, id:id}" \
   --output table

    Résultat attendu : une ligne qui inclut la stratégie id.

  3. Créez un fichier de paramètres (exemple) :

    {
   "effect": {
      "value": "Deny"
   },
   "allowedPublishers": {
      "value": ["OpenAI"]
   },
   "allowedAssetIds": {
      "value": [
         "azureml://registries/azure-openai/models/gpt-5/",
         "azureml://registries/azure-openai/models/gpt-5.2/versions/1"
      ]
   }
}

    Résultat attendu : fichier JSON qui correspond aux noms de votre éditeur approuvé et aux ID de modèle.

    Important

    Chaque ID de ressource est mis en correspondance en tant que préfixe. Un ID sans barre oblique de fin correspond également à d’autres modèles dont les noms commencent par les mêmes caractères , par exemple, azureml://registries/azure-openai/models/gpt-5 correspond à GPT-5 et GPT-5.2 et GPT-5.4. Ajoutez une barre oblique de fin (/) pour limiter la correspondance à ce modèle spécifique uniquement , par exemple, azureml://registries/azure-openai/models/gpt-5/ correspond uniquement à GPT-5 (toutes ses versions) et exclut GPT-5.2 et GPT-5.4. Pour autoriser une seule version, utilisez l’ID complet de la ressource, y compris la version (par exemple). azureml://registries/azure-openai/models/gpt-5.2/versions/1

    Important

    Les noms de paramètres de cet exemple doivent correspondre à la définition de stratégie que vous attribuez. S'ils varient dans votre instance, mettez à jour les clés JSON pour qu'elles correspondent aux paramètres de la définition de stratégie.

  4. Affectez la stratégie à une étendue (exemple : étendue de l’abonnement) :

    az policy assignment create \
   --name "allow-only-approved-models" \
   --display-name "Allow only approved models" \
   --scope "/subscriptions/<subscription-id>" \
   --policy "<policy-definition-id>" \
   --params @params.json

    Résultat attendu : la commande retourne une charge utile JSON qui inclut l’affectation id.

Référence:

Les déploiements de modèles Foundry doivent satisfaire aux critères d’éligibilité

Utilisez cette stratégie pour restreindre les déploiements basés sur des attributs de modèle plutôt que sur une identité de modèle spécifique. Cette restriction est utile lorsque vous souhaitez appliquer des normes organisationnelles plus larges - par exemple, « aucun modèle en préversion en production » ou « uniquement des modèles fournis directement par Microsoft » - sans conserver de liste d’autorisation explicite.

La stratégie prend actuellement en charge les attributs suivants :

Paramètre Type Default Comportement lorsque true
onlyAllowDirectFromAzure Boolean false Refuse le déploiement de modèles qui ne proviennent pas de Azure.
denyPreviewModels Boolean false Empêche le déploiement de modèles dont le statut du cycle de vie est préversion.

Les deux paramètres sont par défaut false, donc une affectation non configurée n’impose aucune restriction. Activez les bascules qui correspondent à la posture de votre organisation.

Affecter la stratégie d’éligibilité

  1. Connectez-vous et sélectionnez l’abonnement dans lequel vous souhaitez travailler :

    az login
az account set --subscription "<subscription-id>"

  2. Recherchez l’ID de définition de stratégie :

    az policy definition list \
   --query "[?displayName=='Foundry model deployments should meet eligibility requirements'].{name:name, id:id}" \
   --output table

  3. Créer un fichier de paramètres (exemple : bloquer les modèles d’aperçu, autoriser n’importe quelle source) :

    {
   "effect": {
      "value": "Deny"
   },
   "onlyAllowDirectFromAzure": {
      "value": false
   },
   "denyPreviewModels": {
      "value": true
   }
}

  4. Attribuez la stratégie :

    az policy assignment create \
   --name "foundry-model-eligibility" \
   --display-name "Foundry model eligibility" \
   --scope "/subscriptions/<subscription-id>" \
   --policy "<policy-definition-id>" \
   --params @params.json

Ce que les développeurs voient lorsqu’un déploiement est bloqué

Lorsqu’un développeur tente de déployer un modèle qu’une stratégie bloque, l’action Déployer est désactivée et un message explique pourquoi. Le modèle lui-même reste visible dans le catalogue afin que le développeur comprenne ce qui a été tenté.

Scénario Ce que le développeur voit
Le modèle est approuvé et éligible Déploiement activé.
Le modèle ne figure pas dans la liste approuvée Déploiement désactivé : le message précise que le modèle n’est pas approuvé par l’organisation et invite à contacter l’administrateur de l’abonnement ou de Foundry.
Le modèle est approuvé, mais ne répond pas à l’éligibilité (par exemple, un modèle en préversion lorsqu’il denyPreviewModels est activé) Déployer désactivé : le message indique que le modèle ne répond pas aux exigences d’éligibilité de l’organisation (état source ou cycle de vie), avec un pointeur pour contacter l’administrateur.
Plusieurs stratégies bloquent le déploiement Déploiement désactivé — la raison ayant la plus haute priorité est affichée (approbation, puis éligibilité).

Chaque message inclut le nom de la stratégie et l’ID d’affectation afin que les administrateurs puissent identifier rapidement quelle stratégie applique la restriction.

Surveiller la conformité

Pour surveiller la conformité à la stratégie, procédez comme suit :

  1. Dans le portail Azure, sélectionnez Policy à gauche de la page. Vous pouvez également rechercher la stratégie dans la barre de recherche en haut de la page.

  2. À gauche du tableau de bord Azure Policy, sélectionnez Compliance. Chaque attribution de stratégie est répertoriée avec l’état de conformité. Pour afficher plus de détails, sélectionnez l’attribution de stratégie.

Mettre à jour l’attribution de stratégie

Pour mettre à jour une attribution de stratégie existante avec de nouveaux modèles, procédez comme suit :

  1. Dans le portail Azure, sélectionnez Policy à gauche de la page. Vous pouvez également rechercher la stratégie dans la barre de recherche en haut de la page.
  2. À gauche du tableau de bord Azure Policy, sélectionnez Assignments et recherchez l’attribution de stratégie existante. Sélectionnez les trois points (...) situés à côté de l’affectation, puis choisissez l’option Modifier l’affectation.
  3. Sous l’onglet Paramètres , mettez à jour les ID de ressource autorisés et les éditeurs de modèles autorisés avec les nouveaux ID de modèle approuvés et les noms de l’éditeur.
  4. Dans l’onglet Révision + Enregistrer , sélectionnez Enregistrer pour mettre à jour l’attribution de stratégie.

Meilleures pratiques

  • Étendue granulaire : affectez des stratégies à l’étendue appropriée pour équilibrer le contrôle et la flexibilité. Par exemple, appliquez au niveau de l’abonnement pour contrôler toutes les ressources de l’abonnement ou appliquer au niveau du groupe de ressources pour contrôler les ressources d’un groupe spécifique.
  • Nomination des politiques : utilisez une convention de dénomination cohérente afin de faciliter l'identification de leur objectif. Incluez des informations telles que l’objectif et l’étendue dans le nom.
  • Balises : utilisez des balises pour catégoriser et gérer vos stratégies. Par exemple, les règles d’étiquetage par environnement (développement, test, prod) ou par service.
  • Documentation : Conservez les enregistrements des affectations et des configurations de stratégie à des fins d’audit. Documentez les modifications apportées à la stratégie au fil du temps.
  • Révisions régulières : passez régulièrement en revue les affectations de stratégie pour vous assurer qu’elles s’alignent sur les exigences de votre organisation.
  • Test : testez les stratégies dans un environnement hors production avant de les appliquer aux ressources de production.
  • Communication : assurez-vous que les développeurs connaissent les stratégies en place et comprennent les implications de leur travail.

Vérifier l’efficacité de la stratégie

Après avoir affecté la stratégie, vérifiez qu’elle fonctionne comme prévu :

  1. Attendez au moins 15 minutes pour que l’attribution de stratégie prenne effet. Les nouvelles affectations ne s’appliquent pas instantanément.

  2. Essayez de déployer un modèle qui n’est pas dans la liste autorisée. Si la stratégie utilise l’effet Refuser , le déploiement échoue avec une erreur de violation de stratégie.

  3. Vérifiez que le déploiement d’un modèle approuvé réussit toujours.

  4. Vérifiez le tableau de bord Compliance dans Azure Policy pour vérifier que la stratégie évalue correctement les ressources. Les ressources non conformes apparaissent dans un cycle d’évaluation de conformité (généralement jusqu’à 24 heures).

Résoudre les échecs d’affectation de stratégie

Symptôme Cause Résolution
Échec de l’attribution de stratégie avec une erreur d’autorisations Votre compte n’a pas le rôle Propriétaire ou Contributeur de stratégie de ressource au niveau de l’étendue cible. Attribuez le rôle requis et réessayez. Consultez les conditions préalables.
La stratégie ne bloque pas les déploiements non conformes L’attribution de stratégie n’a pas encore été propagée, ou l’effet est défini sur Audit au lieu de Refuser. Attendez au moins 15 minutes, puis réessayez. Vérifiez que le paramètre Effect est défini sur Refuser.
Le modèle approuvé est bloqué de manière inattendue L’ID de ressource de modèle ou le nom de l’éditeur dans les paramètres de stratégie ne correspond pas exactement au modèle. Comparez les valeurs des paramètres par rapport à la carte de modèle dans le catalogue de modèles. Les ID de ressource et les noms d’éditeur sont sensibles à la casse.
Le tableau de bord de conformité n’affiche aucune donnée L’évaluation de conformité n’a pas encore été effectuée. Azure Policy évalue les nouvelles affectations dans les 24 heures. Attendez le prochain cycle d’évaluation ou déclenchez une analyse d’évaluation à la demande.
Erreur d’incompatibilité de nom de paramètre lors de l’affectation Les clés de paramètre JSON ne correspondent pas à la définition de stratégie. Exécutez az policy definition show --name "<definition-id>" pour récupérer les noms de paramètres exacts de la définition. Utiliser allowedPublishers et allowedAssetIds.

Contenu connexe

  • Last updated on