Lista de verificação de implantação

A demonstração prova que um agente pode funcionar em uma situação selecionada. Implantação o disponibiliza em seu ambiente pretendido; entrar em produção significa que pessoas reais podem depender dele. Isso muda a pergunta de “Ele pode responder?” para “Podemos operá‑lo de forma responsável quando a resposta está errada, o serviço está lento ou a solicitação está fora do seu escopo?”

Use esta lista de verificação como uma revisão de lançamento, não como uma cerimônia. Cada item marcado deve apontar para evidências e um responsável. Uma captura de tela da configuração pode provar que uma configuração existe; um resultado de teste mostra se funciona. Nenhum substitui uma pessoa nomeada que pode tomar uma decisão quando algo dá errado.

Defina o que significa prontidão #

Comece com uma promessa de serviço precisa. Um agente de suporte que explica políticas publicadas tem riscos diferentes de um que altera detalhes de contas. Declare quem pode usá‑lo, quais tarefas ele trata e quais ações permanecem decisões humanas. A decisão de lançamento deve aplicar‑se a esse escopo, não a uma ideia indefinida de um “assistente inteligente”.

Um problema bloqueante é um problema suficientemente sério para impedir o lançamento, como informações privadas chegando ao cliente errado ou uma ação não autorizada sendo bem‑sucedida. Outras questões podem ser aceitáveis dentro de um piloto restrito se tiverem um responsável, uma mitigação e uma data de revisão. Registre essas decisões explicitamente; uma lista quase completa não é razão para ignorar a questão de segurança restante.

Revisar a lista de verificação de lançamento #

Inspecione os limites, não apenas as respostas #

Permissões determinam o que um usuário ou sistema pode ler ou mudar. Não confie apenas em uma instrução dizendo “Nunca acessar o pedido de outro cliente”. A aplicação e o serviço conectado devem impor esse limite. Teste com um usuário que deveria ser recusado, uma identidade ausente e uma conexão expirada, assim como uma solicitação válida. Recusar corretamente é um resultado de segurança bem‑sucedido, não um defeito a ser contornado.

Dados pessoais são informações relacionadas a uma pessoa identificável. Decida o que o agente realmente precisa e evite coletar o restante. Registros de conversas, resultados de ferramentas e logs de diagnóstico podem conter material sensível. Confirme quem pode acessá‑los, por quanto tempo são mantidos e como as solicitações de exclusão são tratadas. Requisitos legais dependem da situação; use Privacy, LGPD and GDPR para enquadrar as perguntas para seu revisor de privacidade ou jurídico responsável.

Verificações de conhecimento devem testar acesso assim como atualidade. Um manual interno pode estar atualizado, mas inadequado para um canal de suporte público. Uma busca bem‑sucedida não basta: o trecho recuperado deve aplicar‑se à situação do usuário e ser permitido para esse público. Quando a fonte não responde à pergunta, teste se o agente reconhece a lacuna e segue o próximo passo acordado.

Torne as falhas visíveis e acionáveis #

Observabilidade significa ser capaz de entender o que um sistema está fazendo a partir de seus sinais registrados. Um log registra eventos; um trace conecta etapas pertencentes a uma solicitação. Capture informações suficientes para distinguir uma busca falha de uma ferramenta falha ou de uma resposta de modelo inadequada, sem registrar conteúdo privado desnecessário. Logs, traces and monitoring explica como transformar esses sinais em evidências operacionais úteis.

Teste um alerta criando deliberadamente uma falha segura em um ambiente de teste. Confirme que ele chega à pessoa certa e inclui contexto suficiente para ação. Um painel que ninguém verifica não é um plano de resposta a incidentes. Anote como pausar a capacidade afetada, preservar evidências adequadas e explicar a situação aos usuários sem adivinhar a causa.

Uma escalonamento humano transfere um caso ou decisão para uma pessoa. Especifique o que a dispara: incerteza não resolvida, solicitação explícita do usuário, decisão sensível ou falhas repetidas. Inclua o histórico relevante e as etapas tentadas, com apenas as informações que a equipe receptora precisa. Human in the loop descreve onde a aprovação e revisão humana pertencem em um fluxo de trabalho do agente.

Não prometa ajuda imediata quando a equipe de suporte estiver indisponível. Explique a próxima rota disponível e o que o usuário deve esperar. Teste o que acontece quando a própria transferência falha, e garanta que o usuário possa distinguir “Seu caso foi recebido” de “Alguém resolveu seu caso”. São compromissos diferentes.

Implantar gradualmente, usando evidências #

Um piloto é um período deliberadamente limitado de uso real com um público adequado. Não é permissão para expor usuários a comportamentos conhecidos como inseguros. Escolha tarefas de menor risco primeiro, mantenha o suporte disponível e explique as limitações do serviço. A implantação gradual então aumenta a exposição apenas depois que a fase atual atende aos critérios de aceitação pré‑definidos.

Use a conclusão de tarefas, resultados inseguros, tempo de espera, escalonamento e custo em conjunto. Uma alta taxa de conclusão não é aceitável se o agente a alcançar fazendo promessas não autorizadas. Falhas graves infrequentes merecem revisão individual ao invés de serem ocultas por uma média alta. Decida antes do lançamento quais evidências fariam a expansão parar.

Para uma revisão ilustrativa, imagine que a maioria dos itens está concluída, mas um problema de controle de acesso permanece. Contar caixas concluídas ajuda a coordenar o trabalho, mas não pode superar esse bloqueador. Os números abaixo descrevem apenas essa revisão fictícia e não são limites recomendados ou prova de prontidão.

O que vem a seguir: aplique esta lista de verificação a um serviço concreto em Customer support agent.