O que é um piloto automático no Microsoft Foundry?

Um piloto automático é um tipo de agente que funciona sob sua própria identidade como um membro persistente nomeado da sua organização. Ele desempenha um papel contínuo, em vez de responder a uma solicitação por vez. Tem seu próprio perfil de segurança em seu locatário e um gerente responsável por ele.

Cada agente do Foundry tem uma identidade de agente Microsoft Entra desde o momento em que você a cria. O que diferencia um Autopilot é que ele também tem uma conta de usuário de agente do Entra. Essa conta fornece ao piloto automático seu próprio email, calendário, OneDrive, presença do Teams e um lugar no organograma, e permite que o piloto automático execute Microsoft 365 ações como ele mesmo.

Por que os pilotos automáticos existem

Sem uma conta de usuário do agente, um agente pode executar Microsoft 365 ações, como enviar um email ou editar um documento, somente em nome de um usuário conectado. Isso funciona bem para um assistente individual, mas deixa de funcionar em duas situações comuns.

• Nenhum usuário no loop. Um agente disparado por um evento não tem nenhum usuário autenticado em nome de quem possa agir, portanto não pode executar ações do Microsoft 365 de forma alguma.
• Configurações de grupo. Em um bate-papo em grupo, o agente tem que adivinhar em cujo nome agir, e não há resposta certa. Seja quem for que ele selecionar, as permissões dessa pessoa se aplicam a toda a conversa. As ações são atribuídas a alguém que não perguntou e os membros podem ser expostos ao conteúdo que não podem acessar.

Uma conta de usuário do agente resolve ambos os problemas. O piloto automático executa Microsoft 365 ações como ele mesmo, para que ele possa trabalhar com uma equipe inteira de uma só vez e responder a um gatilho quando nenhum usuário estiver presente.

O que não define um piloto automático

Os pilotos automáticos geralmente são descritos por um conjunto de recursos: memória, proatividade, raciocínio, planejamento e aprendizado. Esses recursos descrevem o que um piloto automático pode fazer. Não estabelecem quem está agindo, e mudam a cada versão. Se os recursos definissem a categoria, um agente que adiciona memória em uma versão posterior se tornaria um piloto automático sem que nada mudasse sobre quem ela é, o que ela pode fazer ou quem responde por ela. Essa é uma lista de recursos, não uma definição.

A autonomia também não define um piloto automático e os dois são independentes. Um agente de serviço em segundo plano pode ser executado por conta própria o dia todo e não é um Autopilot. Um piloto automático não precisa ser totalmente autônomo: sua organização controla quando responde, com quem pode interagir, com o que pode acessar e quais ações ela pode tomar.

As funcionalidades descrevem um piloto automático. A identidade o estabelece.

O que os pilotos automáticos permitem

Você raramente faz trabalho corporativo sozinho. A maioria dos trabalhos empresariais é colaborativa e contínua, distribuída entre equipes, reuniões, documentos e chats em grupo. Os pilotos automáticos são criados para esse tipo de trabalho. Eles trabalham com uma equipe inteira em vez de um usuário por vez e podem agir sem serem solicitados.

Um piloto automático tem uma função e os trabalhos que vêm com ele, e seu contexto abrange cada interação, independentemente da superfície ou do usuário. Atribua o trabalho em Outlook e solicite o resultado no Teams. Como sua função é permanente e ela tem permissões próprias, pode atuar proativamente quando você quiser, sem sair do escopo que você define.

A responsabilidade vem com a autonomia. Todo piloto automático tem um gerente que responde por ele e está sujeito aos controles de segurança, privacidade e governança que você já executa.

Como os pilotos automáticos se comparam a outros agentes do Foundry

Os pilotos automáticos e outros agentes do Foundry diferem na identidade que possuem, na forma como você os cria e em como eles alcançam as pessoas que os usam.

O modelo de identidade

Um agente do Foundry regular tem uma forma um-para-um: um agente, um blueprint, uma identidade de agente e nenhuma conta de usuário do agente. O blueprint consiste em um aplicativo blueprint de agente e uma entidade de serviço blueprint de agente, que fornecem o contexto de segurança e as credenciais.

Um Autopilot segue uma estrutura de um para muitos: um modelo e várias instâncias contratadas, em que cada instância recebe sua própria identidade de agente e sua própria conta de usuário do agente.

Os dois objetos de identidade fazem trabalhos diferentes e nunca são intercambiáveis.

Objeto	O que é	O que ele contém
Identidade do agente	Um principal de serviço	A ID do agente, o nome do agente, o patrocinador e as permissões com as quais o agente se autentica. Para um piloto automático, essa identidade protege a infraestrutura que executa o agente.
Conta de usuário do agente	Um objeto de usuário	O nome de exibição, o gerente e o nome principal de usuário que dão presença ao Autopilot no Microsoft 365.

A distinção entre um agente e um piloto automático é binária. Um agente ou tem sua própria conta de usuário ou não, e é isso que torna a identidade uma forma confiável de definição.

A criação de qualquer tipo de agente começa da mesma maneira: a Foundry cria um blueprint de identidade do agente e uma identidade de agente. Para um agente regular, a identidade do agente representa o agente em runtime. Para um piloto automático, a identidade do agente serve como sua identidade de infraestrutura, enquanto a conta de usuário do agente representa o piloto automático quando executa Microsoft 365 ações.

Tipos de agentes que você pode criar no Foundry

A Foundry dá suporte a três tipos de agente e apenas um deles é um piloto automático.

Tipo	Identity	O que ele pode fazer	Mais adequado para
Assistiva	Identidade do agente com contexto de usuário conectado	Atua em nome de um usuário. Ele pode executar ações somente dentro das permissões desse usuário.	Produtividade pessoal, como um agente de preparação de reunião que elabora uma apresentação a pedido.
Serviço em segundo plano	Identidade do agente	Age como si próprio por meio de permissões somente do aplicativo, sem uma conta de usuário conectada nem uma conta de usuário de agente. Ele pode agir de forma autônoma, mas não pode executar ações Microsoft 365.	Automação de aplicativos e fluxos de trabalho de back-end, como um agente de operações que reinicia uma máquina virtual em resposta a um alerta.
Autopilot	Identidade do agente e conta de usuário do agente	Atua como se fosse em Microsoft 365, inclusive nas configurações de grupo. Ele pode agir de forma autônoma dentro do escopo definido por você.	Colegas de trabalho digitais, como um gerente de lançamento que coordena o trabalho em um chat em grupo do Teams.

Por que você cria um blueprint, não um piloto automático

Você não cria um piloto automático. Você cria um modelo que as equipes usam para criar suas próprias instâncias do Autopilot, cada uma com identidade própria e acesso restrito à equipe.

Criar o agente o vincula diretamente a uma equipe, pois o acesso que o torna útil é o mesmo acesso que o bloqueia. Se você adicionar uma conta de usuário do agente ao grupo de segurança da sua equipe e conceder a ela acesso ao seu projeto e ao site do SharePoint, esse é justamente o propósito do agente. É também por isso que ninguém mais pode reutilizá-lo: acabariam herdando um acesso que não deveriam ter, então constroem o seu próprio. Dez equipes depois, a organização passou a ter dez agentes quase idênticos, cada um gerenciado separadamente. Seus controles se desfazem, e uma ferramenta comprometida tem que ser perseguida por um agente de cada vez.

Um blueprint resolve esse problema. Ele define duas coisas: o que o agente sabe fazer, como quais APIs ele pode chamar e a infraestrutura de plataforma que o agente precisa, como armazenamento para itens rastreados e memória. O que ele nunca concede é acesso aos recursos de negócios de uma equipe específica. Um agente já vem sabendo como atualizar itens de trabalho do Azure DevOps e ler conteúdo do SharePoint, enquanto cada gerente decide qual projeto do Azure DevOps e qual site do SharePoint suas instâncias podem acessar. Cada instância criada a partir do blueprint tem sua própria identidade, permissões e atribuição.

Essa separação também se mantém em tempo de execução. Manter uma ferramenta não é o mesmo que manter o acesso aos dados por trás dela. Dar a um piloto automático uma ferramenta do SharePoint não lhe dá acesso a nenhum site do SharePoint, e dar a ele uma caixa de correio não lhe dá a capacidade de enviar e-mails.

A política é uma camada de governança separada. Configure a política uma vez e cada instância a herdará. Atualize o blueprint e todas as instâncias serão atualizadas. Bloqueie o blueprint e todas as instâncias param.

Somente os agentes hospedados no Foundry podem ser publicados como blueprints de Autopilot.

Tipos de pilotos automáticos que você pode criar

Os pilotos automáticos se enquadram em três padrões, que diferem em quem servem.

• Piloto automático de grupo – funciona para uma equipe. Ele está onde a equipe trabalha, preserva o contexto compartilhado por toda a equipe e coordena o trabalho entre as pessoas, em vez de atender uma pessoa de cada vez.
• Piloto automático em toda a empresa – fornece uma funcionalidade gerenciada centralmente disponível para todos na organização, normalmente como uma instância de produção por processo de negócios.
• Piloto automático pessoal – funciona para uma pessoa, como uma instância isolada criada e usada por essa pessoa.

Conteúdo relacionado

• O ciclo de vida do Autopilot no Microsoft Foundry abrange os estágios, desde a criação de um blueprint até o término de uma instância.
• Os conceitos de identidade do agente no Microsoft Foundry abordam como o Foundry provisiona e usa identidades de agente em runtime.
• A Integração do Microsoft Agent 365 com o Foundry abrange a sincronização do Registro e os tipos de agente oferecem suporte à publicação Autopilot.