Assistentes agentes: integrações seguras com calendário e Gmail

Minha afirmação: construir assistentes agentes seguros e utilizáveis que atuem em calendários, Gmail e aplicativos conectados requer projetar um tempo de execução focado em permissões, separando planejamento de ação e incorporando fluxos de auditoria e reversão na camada de execução desde o primeiro dia. Este artigo apresenta uma checklist de engenharia concisa e prompts executáveis para alcançar esse objetivo.

DESIGN DE PERMISSÃO PARA ASSISTENTES AGENTES

Comece com OAuth por usuário e escopos de menor privilégio. Use OAuth vinculado ao usuário em vez de uma conta de serviço compartilhada, exceto quando um administrador exigir explicitamente a delegação de domínio. A documentação do Google sobre escopos granulares é a base; mapeie cada capacidade do agente para um único escopo OAuth e documente a intenção legível por humanos para esse escopo. Mantenha tokens fora dos prompts. Armazene-os em um cofre e injete credenciais apenas no momento da chamada dentro de um serviço de execução que aplique a política.

Observamos que equipes que tratam permissões como UX do produto, com telas de consentimento claras e prévias de escopo, recebem bem menos chamados de suporte. Um problema que encontramos é a proliferação de tokens a partir de lógica de atualização ingênua; centralize a atualização e gire os tokens de atualização regularmente.

PLANEJAMENTO VERSUS AÇÃO

Separe o assistente em um planejador e um executor. O planejador produz um plano de ação discreto: ler tópicos recentes, propor dois horários de reunião, compor um rascunho de e-mail. O executor executa apenas após uma verificação de política e, para ações sensíveis, uma etapa de confirmação humana. Esse padrão impede que o modelo improvise operações privilegiadas e torna a autorização auditável.

Compromisso prático: latência maior para aprovação humana versus menor risco. Para muitas ações de calendário e e-mail, uma pausa de 30 a 60 segundos com intervenção humana é aceitável. Para tarefas de alta frequência, aprovações em lote funcionam melhor do que cliques por ação.

TESTES, REGISTROS E RECUPERAÇÃO

Toda ação deve produzir uma entrada de auditoria imutável contendo a intenção solicitada, a saída do planejador, a decisão de política, a chamada do ator e a resposta da API retornada. Mantenha um formato de comando reproduzível para que você possa reproduzir e reverter. Forneça um revogar com um clique para as últimas N ações e um fluxo de recuperação que cria eventos compensatórios, por exemplo, cancelar um evento e enviar um follow-up corretivo.

Observamos que barreiras de nível de prompt falham sem um motor de política externa. Na prática, modelos sugerem mudanças que parecem plausíveis, mas infringem a política. Um portão de execução que recusa qualquer escrita quando a confiança está abaixo de um limite calibrado reduz esses incidentes.

CHECKLIST PARA PRODUTO E ENGENHARIA

1. OAuth por usuário com escopos mínimos e texto de consentimento explícito. 2. Cofre de tokens e serviço de execução que injeta credenciais em tempo de execução. 3. Separação planejador/ator com verificações de política. 4. Escalonamento com humano no processo para ações sensíveis. 5. Registros de auditoria imutáveis e formato de ação reproduzível. 6. Fluxos de reversão e compensação com UI clara.

Vincule a UX do produto aos padrões de fluxo de trabalho descritos em Projetando fluxos de trabalho humano-IA e use a introdução sobre diferenças de agentes em Agentes de IA vs chatbots para justificar a separação planejador/ator.

Experimente você mesmo. Os prompts abaixo demonstram a saída do planejador em contraste com instruções seguras do executor. Espere planos concisos em formato JSON do planejador e confirmações curtas do executor.

Este prompt pede ao modelo para produzir um plano contido de horários de reunião candidatos e uma justificativa; use-o como o planejador. Espere de 2 a 3 faixas de horários candidatos e uma justificativa em uma frase.

Você é um planejador de reuniões. O usuário tem 3 horários livres hoje: 10:00, 14:30, 16:00. Retorne exatamente três horários candidatos de reunião em formato ISO com uma justificativa em uma linha para cada um, e uma nota de privacidade em uma linha dizendo se o convite toca e-mails externos.

Este prompt é para o executor. Espera um token de confirmação humana e uma passagem de verificação de política explícita antes de criar o evento.

Executor: dado o token de confirmação do usuário X e o plano do planejador Y, chame Calendar.CreateEvent com os campos {start,end,attendees,summary} apenas se policy_check(policy_id:calendar_write) retornar pass. Se policy_check falhar, retorne o código de falha e a ação humana necessária.

Um contra-argumento é que controles rigorosos atrasam a adoção. Minha estimativa é que, quando as equipes aplicam esses padrões, a retenção inicial de usuários melhora porque a confiança cresce, mesmo que a ativação inicial seja mais lenta. O compromisso é claro: um rollout mais rápido sem esses controles cria risco mensurável e custos de remediação mais altos.