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

Um piloto automático é um tipo de agente que funciona sob a sua própria identidade como membro persistente e nomeado da sua organização. Desempenha uma função permanente em vez de responder a um pedido de cada vez. Tem o seu próprio perfil de segurança no seu tenant e um gestor responsável pelo mesmo.

Cada agente do Foundry tem uma identidade de agente do Microsoft Entra a partir do momento em que é criado. O que torna um piloto automático diferente é que também tem uma conta de utilizador de agente Entra. Essa conta dá ao piloto automático o seu próprio email, calendário, OneDrive, presença no Teams e um lugar no organigrama, permitindo que o piloto automático execute as ações do Microsoft 365 como ele próprio.

Por que existem os pilotos automáticos

Sem uma conta de utilizador agente, um agente pode realizar ações do Microsoft 365, como enviar um email ou editar um documento, apenas em nome de um utilizador iniciado sessão. Isso funciona bem para um assistente individual, mas falha em duas situações comuns.

• Sem intervenção do utilizador. Um agente acionado por um evento não tem nenhum utilizador com sessão iniciada em nome do qual atuar, pelo que não pode executar de todo ações no Microsoft 365.
• Definições de grupo. Num grupo de chat, o agente tem de adivinhar em nome de quem deve agir, e não há uma resposta certa. Seja quem for a pessoa escolhida, as permissões dessa pessoa aplicam-se a toda a conversa. As ações são atribuídas a alguém que não pediu, e os membros podem ser expostos a conteúdos a que não têm acesso.

Uma conta de utilizador agente resolve ambos os problemas. O piloto automático executa ações do Microsoft 365 como ele próprio, podendo assim trabalhar com toda a equipa de uma vez e responder a um gatilho quando não há utilizador presente.

O que não define um piloto automático

Os pilotos automáticos são frequentemente descritos por um conjunto de capacidades: memória, proatividade, raciocínio, planeamento e aprendizagem. Essas capacidades descrevem o que um piloto automático pode fazer. Não estabelecem quem está a atuar, e mudam a cada lançamento. Se as capacidades definissem a categoria, um agente que adiciona memória numa versão posterior tornar-se-ia um piloto automático sem que nada mudasse sobre quem é, o que pode fazer ou quem responde por ela. Isso é uma lista de funcionalidades, 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 executar-se autonomamente durante todo o dia e não é um piloto automático. Um piloto automático não tem de ser totalmente autónomo: a sua organização controla quando responde, com quem pode interagir, ao que pode aceder e que ações pode tomar.

Capacidades descrevem um piloto automático. A identidade estabelece-a.

O que os pilotos automáticos permitem

Raramente fazes trabalho empresarial sozinho. A maior parte do trabalho empresarial é colaborativa e contínua, distribuída por equipas, reuniões, documentos e grupos de conversa. Os pilotos automáticos são feitos para esse tipo de trabalho. Trabalham com uma equipa inteira em vez de um utilizador de cada vez, e podem agir sem serem solicitados.

Um piloto automático tem um papel e as funções que o acompanham, e o seu contexto abrange todas as interações, independentemente da superfície ou do utilizador. Atribui-lhe trabalho no Outlook e pede o resultado no Teams. Como o seu papel é permanente e tem permissões próprias, pode agir de forma proativa quando quiser, permanecendo dentro do âmbito que define.

A responsabilidade vem com a autonomia. Cada autopilot tem um gestor que é responsável por ele e está sujeito aos controlos de segurança, de privacidade e de governação que já tem em vigor.

Como os pilotos automáticos se comparam com outros agentes da Foundry

Os pilotos automáticos e outros agentes da Foundry diferem na identidade que possuem, na forma como os constrói e na forma como chegam às pessoas que os utilizam.

O modelo de identidade

Um agente regular da Foundry tem uma forma um-para-um: um agente, um blueprint, uma identidade de agente e sem conta de utilizador agente. O blueprint consiste numa aplicação do agente blueprint e num principal serviço de agente blueprint, que fornece o contexto de segurança e as credenciais.

Um piloto automático tem uma forma de um-para-muitos: um plano e muitas instâncias contratadas, onde cada instância recebe a sua própria identidade de agente e a sua própria conta de utilizador agente.

Os dois objetos identidade desempenham funções diferentes e nunca são intercambiáveis.

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

Criar qualquer um dos tipos de agente começa da mesma forma: a Foundry cria um blueprint de identidade de agente e uma identidade de agente. Para um agente normal, a identidade do agente representa o agente em tempo de execução. Para um piloto automático, a identidade do agente serve como identidade de infraestrutura, enquanto a conta de utilizador do agente representa o piloto automático quando executa ações do Microsoft 365.

Tipos de agentes que pode criar na Foundry

A Foundry suporta três tipos de agentes, e apenas um deles é piloto automático.

Por que constróis um projeto, não um piloto automático

Não se constrói um piloto automático. Constróis um plano que as equipas usam para criar as suas próprias instâncias de piloto automático, cada uma com a sua identidade e acesso definido por equipa.

Construir o agente vincula-o diretamente a uma equipa, porque o acesso que o torna útil é o mesmo que o restringe. Se adicionares uma conta de utilizador do agente ao grupo de segurança da tua equipa e lhe deres acesso ao teu projeto e ao site do SharePoint, esse acesso é precisamente a razão de ser do agente. É também por isso que mais ninguém o pode reutilizar: herdariam acessos a que não deveriam ter, por isso criam o seu próprio. Dez equipas depois, a organização tem dez agentes quase idênticos, cada um governado separadamente. Os seus mecanismos de controlo divergem, e uma ferramenta comprometida tem de ser localizada, um agente de cada vez.

Um plano resolve esse problema. Define duas coisas: o que o agente sabe fazer, como que APIs pode chamar, e a infraestrutura da plataforma de que o agente necessita, como armazenamento para itens rastreados e memória. O que nunca concede é acesso aos recursos empresariais de uma equipa específica. Um agente já vem preparado para atualizar itens de trabalho do Azure DevOps e ler conteúdo no SharePoint, enquanto cada administrador decide a que projeto do Azure DevOps e a que site do SharePoint a sua instância pode aceder. Cada instância criada a partir do blueprint tem a sua própria identidade, permissões e atribuição.

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

A política é uma camada de governação separada. Configura a política uma vez e cada instância herda-a. Atualiza o blueprint e todas as instâncias são atualizadas. Bloquear o esquema e todas as instâncias deixam de funcionar.

Apenas os agentes hospedados no Foundry podem ser publicados como blueprints de piloto automático.

Tipos de pilotos automáticos que podes construir

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

• Piloto automático de grupo — funciona para uma equipa. Vive onde a equipa trabalha, mantém o contexto que toda a equipa partilha e coordena-se entre as pessoas em vez de servir uma de cada vez.
• Piloto automático a nível da empresa — oferece uma capacidade gerida centralmente disponível para todos na organização, normalmente como uma instância de produção por processo de negócio.
• 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 cobre as etapas desde a construção de um plano até ao fim de uma instância.
• Os conceitos de identidade de agente no Microsoft Foundry cobrem como o Foundry fornece e utiliza identidades de agentes em tempo de execução.
• A integração do Microsoft Agent 365 com o Foundry cobre a sincronização do registo e quais os tipos de agentes que suportam a publicação no piloto automático.