Microsoft AI Agent Builder Associate (AB-620) — Questions d'entraînement et examen blanc

Les principes de l'IA responsable ne deviennent applicables que lorsque chacun correspond à une pratique concrète qu'une équipe de livraison peut planifier. L'équité se rattache aux données et à la validation indépendante des résultats. La responsabilité se rattache à des personnes nommées qui répondent du système. L'éthique se rattache à qui se trouve dans la pièce pendant la conception et à un cadre de gouvernance qui audite le résultat. La transparence est celle qui façonne la surface du produit vue par l'utilisateur, car elle s'acquitte par la divulgation plutôt que par un processus interne. Dans un contexte réglementé comme la santé, cette distinction compte, puisqu'un comité d'examen demandera ce que le patient voit et ce qu'on lui dit, et pas seulement ce qu'a fait l'équipe de livraison. Planifier une stratégie d'IA responsable, c'est attribuer à chaque principe un responsable et un livrable plutôt que de traiter les quatre comme un seul engagement indifférencié.

Les trois extensions de contrôle se distinguent par l'endroit du déploiement où elles insèrent leur étape personnalisée, et se tromper revient généralement à faire tourner la vérification après le moment qu'elle était censée protéger. Une validation qui doit avoir lieu avant que quoi que ce soit ne quitte l'environnement de développement se place à la frontière de l'export, c'est pour cela que cette extension retient l'export jusqu'à ce que ta logique signale la fin du traitement et pour cela qu'elle ne se place que sur la première phase. Exécuter des déploiements sous une autre identité est un sujet distinct, pris en charge par l'extension déléguée, qui permet aux makers de demander des déploiements vers des environnements où ils n'ont aucun droit. Une validation humaine finale après l'approbation relève de l'étape de pré-déploiement. Une fois les artefacts exportés, ils sont stockés dans l'hôte et ne peuvent plus être altérés, et le même artefact traverse dans l'ordre chaque phase suivante, donc une vérification ultérieure ne peut pas défaire un mauvais export.

Les frontières de propriété déterminent ce qu'un bouton de suppression supprime réellement, et ici la frontière passe entre les deux produits. La base de connaissances est un actif Foundry : ses sources, ses paramètres de récupération et son cycle de vie appartiennent à celui qui l'a construite, et elle est conçue pour être réutilisée par plusieurs agents. Ce que détient Copilot Studio, c'est une référence et une description d'outil. Supprimer cette référence détache un consommateur et laisse l'actif intact, ce qui est exactement ce que tu veux quand plusieurs agents le partagent. La même asymétrie explique les recommandations de réglage, puisque modifier le comportement de classement doit se faire là où réside l'actif. Astuce d'examen : quand une ressource est décrite comme réutilisable et créée ailleurs, attends-toi à ce qu'une suppression côté consommateur soit un détachement et non une suppression.

Le générateur d'outils REST API n'est qu'une fine couche au-dessus du pipeline de connecteurs personnalisés Power Platform, et c'est pourquoi ses exigences d'entrée ressemblent à celles d'un connecteur plutôt qu'à celles d'un agent. Le document doit arriver en JSON, et le pipeline ramène un contrat plus récent à la version qu'il traite. Tout ce qui suit le téléversement sert à aider l'orchestrateur : tu choisis quelles combinaisons d'endpoint et de méthode doivent devenir des outils, et tu rédiges des descriptions assez précises pour que le modèle les distingue les unes des autres. Les formes des valeurs d'entrée et de sortie viennent directement de la spécification et sont en lecture seule, mais leurs descriptions, c'est à toi de les écrire et elles ne peuvent pas rester vides. Astuce d'examen : la version de la spécification et le format du fichier sont deux exigences distinctes, et les questions n'en modifient souvent qu'une seule.