Microsoft AI Agent Builder Associate (AB-620) — Questões de prática e simulado

Os princípios de IA responsável só viram algo acionável quando cada um deles corresponde a uma prática concreta que a equipe de entrega consegue colocar no cronograma. A justiça se apoia nos dados e na validação independente dos resultados. A responsabilização se apoia em pessoas com nome e sobrenome que respondem pelo sistema. A ética se apoia em quem está na sala durante o design e em um modelo de governança que audita o resultado. A transparência é a que molda a superfície do produto que a pessoa usuária vê, porque ela é cumprida por meio da divulgação e não de um processo interno. Em um setor regulado como a saúde essa distinção importa, já que um comitê de revisão vai perguntar o que o paciente vê e o que é dito a ele, não apenas o que a equipe de entrega fez. Planejar uma estratégia de IA responsável significa atribuir a cada princípio uma pessoa responsável e um artefato, em vez de tratar os quatro como um compromisso único e indiferenciado.

As três extensões de controle se diferenciam pelo ponto da implantação em que inserem a etapa personalizada, e escolher a errada normalmente significa que a verificação roda depois do momento que ela deveria proteger. A validação que precisa acontecer antes de qualquer coisa sair do ambiente de desenvolvimento fica na fronteira da exportação, e é por isso que essa extensão segura a exportação até a sua lógica sinalizar que terminou, e por isso que ela vale só para o primeiro estágio. Executar implantações sob outra identidade é um assunto separado, tratado pela extensão delegada, que permite aos makers solicitar implantações em ambientes onde não têm direitos. Uma aprovação humana final depois da autorização pertence à etapa de pré-implantação. Depois que os artefatos são exportados, eles ficam armazenados no host e não podem ser adulterados, e o mesmo artefato percorre em ordem cada estágio seguinte, então uma verificação posterior não desfaz uma exportação ruim.

Os limites de propriedade decidem o que um botão de excluir realmente exclui, e aqui o limite passa entre os dois produtos. A base de conhecimento é um ativo do Foundry: as fontes, as configurações de recuperação e o ciclo de vida dela pertencem a quem a construiu, e ela foi feita para ser reutilizada por vários agentes. O que o Copilot Studio guarda é uma referência mais uma descrição de ferramenta. Remover essa referência desconecta um consumidor e deixa o ativo intacto, que é exatamente o que você quer quando vários agentes o compartilham. A mesma assimetria explica a orientação de ajuste, já que mudar o comportamento de ranqueamento tem que acontecer onde o ativo vive. Dica de prova: quando um recurso é descrito como reutilizável e criado em outro lugar, espere que remover no consumidor seja um desacoplamento e não uma exclusão.

O construtor de ferramentas de REST API é uma casca fina sobre o pipeline de conectores personalizados do Power Platform, e é por isso que os requisitos de entrada dele parecem requisitos de conector, e não de agente. O documento precisa chegar como JSON, e o pipeline normaliza um contrato mais novo para a versão que ele processa. Tudo depois do envio serve para ajudar o orquestrador: você escolhe quais combinações de endpoint e método devem virar ferramentas e escreve descrições específicas o suficiente para o modelo diferenciar uma da outra. Os formatos dos valores de entrada e saída vêm direto da especificação e são somente leitura, mas as descrições são você quem escreve e elas não podem ficar em branco. Dica de prova: a versão da especificação e o formato do arquivo são requisitos separados, e as perguntas costumam mudar só um deles.