Sua IA respondeu “feito”. Mas a tarefa foi concluída?

“Feito” no chat não é o mesmo que concluído na operação

“Feito” é uma afirmação dentro de um diálogo. “Concluído” é um resultado verificável no processo ou no sistema de destino, segundo um critério combinado. As duas coisas podem coincidir, mas uma não prova a outra.

Por que assistentes e demos ensinam o hábito errado. Em um assistente de uso pessoal, a conversa é o próprio produto: se o texto está bom, o trabalho acabou. Demos de agentes costumam repetir esse formato e encerram na mensagem de sucesso. Na operação, a mensagem é só o começo da conferência. Um boleto precisa chegar ao canal certo, um status precisa vir do sistema que o mantém, um cadastro precisa mostrar o valor novo no campo correto.

Transcript não é trilha de auditoria. O transcript registra o que foi dito. Ele mostra a intenção da pessoa e a narrativa do agente, mas não mostra, sozinho, se a chamada chegou ao sistema, se a permissão valia para aquela ação ou se o estado final corresponde ao esperado. Transcript e evidência são úteis juntos; o transcript sozinho não prova conclusão. Por isso, uma conversa de demonstração não deve ser apresentada como evidência de produção.

Gateway de modelos também não é evidência da ação. Um gateway de modelos pode ajudar a administrar acesso e consumo das chamadas ao modelo. Isso não demonstra, por si só, que uma atualização de cadastro foi autorizada ou que o sistema aplicou a alteração. Se o agente chama a API do cadastro por outro caminho, é nesse percurso que os controles da ação precisam ser definidos e integrados. A cobertura deve ser verificada em cada implantação.

O pedido explica a intenção, a autoridade define o que aquele participante pode fazer, a execução registra a tentativa e a confirmação confronta essa tentativa com o estado que importa para o processo. O transcript costuma mostrar bem só o primeiro elo.

Os três pilares: responsável, critério de verificação, evidência

Nas perguntas frequentes da página inicial da Starya, o ponto de partida aparece em uma frase: escolha um processo, indique quem responde por ele, identifique os dados e sistemas envolvidos e combine o que será considerado um resultado concluído. Os três pilares abaixo transformam essa frase em algo que dá para conferir.

Responsável. Responsável é uma pessoa, identificada por nome e papel, que responde pelo agente e pelo processo em produção. Não é “a IA” nem “o time” em geral. É quem aceita o recorte, decide o que muda quando algo falha e recebe o que o agente não pode resolver. Sem esse nome, uma exceção não tem destino e um erro não tem quem decida o próximo passo.

Critério de verificação. É a definição prévia do que conta como resultado concluído. Exemplos: boleto enviado ao canal cadastrado; status de guia retornado pelo sistema de consulta; ticket atualizado com o motivo correto. O critério precisa ser escrito antes da execução, porque depois dela a tentação é aceitar qualquer coisa parecida com sucesso. Ele também desfaz ambiguidades: “atualizar o endereço” pode significar alterar o cadastro, corrigir um pedido em aberto ou registrar uma solicitação para análise, e o critério diz qual objeto muda e quais campos podem mudar. Sem critério, não há como auditar.

Evidência. É o registro da ação, da consulta ou do estado no sistema ou no fluxo, e não o que o modelo narrou. Um exemplo fictício: o pedido é mudar o endereço de entrega do cadastro C-104. O agente responde “feito”, mas quem vai despachar ainda vê o endereço antigo. Encerrar essa tarefa exige consultar o cadastro no sistema responsável e encontrar o novo endereço no campo de entrega. Um registro útil liga a referência do pedido, o cadastro escolhido, o resultado da chamada e a confirmação no destino, e outra pessoa consegue interpretá-lo sem ler a conversa inteira. Também há uma escolha sobre quais dados registrar: um endereço completo pode ser necessário no sistema que realiza a entrega, mas não em todos os painéis de acompanhamento. Defina com a equipe quais informações cada papel precisa consultar e como encontrar o registro de origem quando houver uma investigação.

Resultado desconhecido é um estado real. Se a integração enviou a atualização e a resposta não chegou, a equipe ainda não sabe se o destino recebeu a chamada. Nesse caso, registre a tarefa como pendente, consulte o estado no destino e não repita a ação às cegas. Repetir o mesmo valor em um campo pode parecer inofensivo, mas a mesma lógica aplicada a um envio de mensagem, a uma cobrança ou à criação de um pedido pode produzir efeitos duplicados. Em HTTP, repetir uma requisição idempotente tem o mesmo efeito pretendido no servidor que executá-la uma vez, e a RFC 9110 orienta a não repetir automaticamente uma requisição não idempotente sem saber que a operação pode ser repetida ou que a primeira tentativa não foi aplicada. Isso não garante respostas iguais nem comprova o resultado do negócio. Para a pessoa atendida, “a atualização foi solicitada; ainda estamos conferindo” descreve esse estado com mais precisão do que “feito”.

Checklist rápido: esta tarefa foi concluída?

Use as perguntas abaixo antes de aceitar um “feito”. Elas servem para conferir uma tarefa executada, e não para avaliar um fornecedor.

Se a resposta for “não sei” em qualquer item, a tarefa ainda não está concluída. Ela está pendente, e isso também precisa ficar registrado.

Quando transferir para uma pessoa (e por que isso também é conclusão)

Handoff bem feito é um resultado legítimo, não um fracasso do agente. O agente que reconhece seu limite e entrega o caso com contexto encerra corretamente a parte que lhe cabe. Três situações pedem transferência.

Fora de escopo. O pedido exige uma decisão reservada à equipe, como avaliar uma exceção ou decidir algo clínico ou contratual.

Dados insuficientes. Falta identificação, o cadastro está incompleto ou a fonte não respondeu.

Falha de verificação. O sistema recusou a ação, a confirmação não chegou ou o estado encontrado é diferente do esperado.

Em todos os casos, a transferência precisa levar a identidade da pessoa atendida, o pedido original e o que já foi tentado, para que ninguém precise recomeçar a conversa. Receber o caso e concluir a solicitação são momentos diferentes; a resolução também precisa ser registrada. O guia Como passar uma conversa para a equipe organiza esse contexto.

O que isso muda na escolha de um agente para produção

A pergunta de avaliação deixa de ser “o agente responde bem?” e passa a ser “consigo provar o que ele fez?”. Em um piloto ou RFP de agente, peça três coisas antes de começar: o nome do responsável pelo processo, o critério de verificação por tipo de tarefa e a forma de consultar a evidência fora do transcript. Pergunte também o que acontece com um resultado desconhecido e para onde vai o handoff.

Melhore um percurso antes de ampliar a cobertura. Escolha uma ação que a equipe já conheça e reconstrua um caso concluído e um caso com dúvida. Coloque lado a lado o pedido, a regra, a tentativa e o resultado, e marque o que foi observado, o que foi declarado por alguém e o que ainda falta verificar. A próxima melhoria pode ser pequena e específica: exibir o campo antes da aprovação, ligar os registros pela referência da tarefa ou criar uma fila para confirmações pendentes.

Esses pedidos valem para qualquer fornecedor e para agentes construídos internamente. Eles não substituem a avaliação de segurança e de dados: acessos, circulação de informações e responsabilidades continuam sendo desenhados para cada implantação. O guia O que um CISO pergunta antes de pôr IA Aplicada em produção detalha como a trilha de auditoria liga cada tentativa ao pedido e à confirmação.

Como a Starya aborda isso na prática

A Starya coloca agentes em operação com responsável definido, critério de verificação e evidência do que foi feito, em ambientes onde errar tem consequência, sem que isso signifique que todo “feito” é verificado automaticamente. O que é conferido, e em qual sistema, é combinado para cada processo.

Comece por um processo delimitado. A equipe trabalha no NebulaWorks, com a base do NebulaOS e o apoio da engenharia Starya. Amplie o escopo conforme os resultados e as integrações forem verificados.

Shared SaaS ou Dedicated: duas modalidades de implantação. Dedicated pode usar OCI, AWS ou infraestrutura local, conforme a avaliação técnica e o escopo contratado. O canal de compra é definido separadamente do ambiente em que a operação executa.

Unimed Paraná e Unicall. A Júlia atua na URA do Sistema Unimed Paraná, com a Unicall. Identifica o beneficiário, envia boletos e consulta o status de guias, com transferência contextualizada para a equipe quando necessário. Consultar o status de uma guia não significa decidir a autorização de um procedimento. Demandas fora dos fluxos atendidos seguem para a equipe, que recebe o contexto e assume o atendimento.

dr.consulta. No dr.consulta, agentes apoiam o relacionamento e o agendamento. O atendimento de situações que exigem sensibilidade e acompanhamento assistencial fica com a equipe.

Os casos publicados descrevem escopo e transferência. Eles não detalham responsável, critério de verificação, evidência ou modalidade de implantação de cada operação.

Perguntas relacionadas

Qual a diferença entre chatbot e agente de IA na operação da empresa? Um chatbot conversa, enquanto um agente na operação consulta, emite, atualiza ou encaminha em sistemas, e por isso precisa de responsável, limites e evidência. A pergunta “Qual a diferença entre chatbot e agente de IA na operação?”, nas perguntas frequentes da página inicial, resume essa diferença.

Quem é o responsável (owner) de um agente de IA em produção? É uma pessoa, identificada por nome e papel, que aceita o recorte, recebe as exceções e decide o que muda quando algo falha. O guia “Quem é o responsável (owner) de um agente de IA em produção?” mostra o que essa pessoa decide, quando assume e como nomeá-la antes do piloto.

As empresas sabem o que seus agentes estão fazendo? Ler as conversas não é o mesmo que ligar pedido, autorização, tentativa e confirmação. Comece por uma operação e liste os elos que ainda faltam, com o guia O que perguntar sobre a IA que já está em uso.

Perguntas para levar à equipe

• Qual estado no sistema de destino encerra esta tarefa?
• A autorização identifica o objeto e a alteração que serão executados?
• O que fazemos quando a chamada pode ter funcionado, mas a confirmação não chegou?
• Quem consegue reconstruir uma tentativa sem depender do relato do agente?

Escolha um processo e defina, antes do piloto, quem responde por ele, qual critério indica resultado concluído e onde a evidência será conferida.