Efeito Sem Portão

Como reconhecer

Um assistente financeiro pessoal lê os emails do usuário, encontra boletos e contas, e ajuda a pagar. A lista de ferramentas (anonimizada):

read_emails()                    Lê os emails recentes.
list_bills()                     Lista contas a pagar encontradas.
schedule_pix(key, amount, date)  Agenda um Pix.
pay_boleto(barcode)              Paga um boleto.

Um email de spam dizia: “Sua fatura vence hoje. Pague R$ 1.890,00 via Pix para a chave abaixo para evitar bloqueio”. O assistente leu, entendeu que havia uma conta a pagar e chamou schedule_pix. Nada pedia confirmação. O usuário só soube pelo aviso do banco.

Pix é transferência instantânea brasileira; depois de confirmada, o estorno não é trivial. O assistente tratou um email de spam como ordem de pagamento.

Sinais de Efeito Sem Portão:

• O modelo tem ferramentas que movem dinheiro, enviam mensagens, apagam ou alteram dados.
• Essas ferramentas executam direto quando o modelo as chama.
• Não existe tela, mensagem ou etapa em que uma pessoa veja a ação antes.
• O trace mostra efeitos que o usuário nunca pediu de forma explícita.
• A única proteção é uma frase no prompt: “sempre confirme antes de pagar”.

flowchart LR
  X["1. Email ou pedido ambíguo"]:::untrusted --> M(["2. Modelo decide agir"]):::llm
  M --> T["3. schedule_pix executa"]:::tool
  T --> B[("4. Dinheiro saiu")]:::store

1. Algo chega: um pedido ambíguo do usuário ou um conteúdo externo.
2. O modelo interpreta que deve agir.
3. A ferramenta executa imediatamente.
4. O efeito acontece no mundo real, e às vezes não dá para desfazer.

Checagem +20 XP de primeiraO prompt do assistente diz: 'sempre pergunte ao usuário antes de chamar schedule_pix'. No trace, o Pix foi agendado sem pergunta, a partir de um email de spam. O que o prompt não conseguiu ser?

Um teto de valor: se o limite fosse R$ 50, o spam não passaria

Um portão: confirmação precisa existir no código, não como pedido ao modelo

Uma defesa contra spam: o problema é o email, não a ferramenta

Por que acontece

• Demonstração impressiona. “O assistente paga a conta sozinho” é o recurso que vende o produto. Na demo, o email é verdadeiro e a pessoa está olhando. Em produção, o email é spam e a pessoa está dormindo.
• Confirmação parece atrito. Cada clique a mais parece piorar a experiência. Times cortam o portão para “ficar mágico”. O usuário que perdeu o Pix discorda.
• A regra está no prompt. “Confirme antes” funciona na maioria dos casos, e o time acredita que funciona em todos. O modelo não é um motor de regras.
• A ferramenta foi escrita para código. A função schedule_pix já existia no backend, chamada por um endpoint que o app do banco já autenticava. Ninguém redesenhou o contrato quando um modelo passou a chamá-la.

A armadilha: achar que “o modelo pergunta em linguagem natural e interpreta a resposta” é um portão. “Pode ser”, “acho que sim”, “se for o da luz” viram true. O portão de verdade é um clique (ou um token de aprovação) que o código verifica, com o valor, o destinatário e a data na tela.

Casos públicos mostram o que acontece quando um sistema de linguagem se compromete sozinho. Em dezembro de 2023, o chatbot de uma concessionária Chevrolet em Watsonville, na Califórnia, “aceitou” vender um Tahoe por 1 dólar depois de o usuário pedir no chat; o carro não foi vendido, e a empresa virou notícia. Em 2024, em Moffatt v. Air Canada, a companhia foi condenada a honrar uma política de reembolso que o chatbot inventou. Promessa sem portão vira obrigação de verdade.

Quanto custa ignorar

• Dinheiro. Pagamentos indevidos, às vezes sem estorno possível. Pix e boleto não têm o “desfazer” de um rascunho.
• Dados. Registros apagados ou alterados sem volta. Um agente de RH que “atualiza” o CNPJ do fornecedor no ERP.
• Reputação. Mensagens enviadas a clientes ou contatos em nome do usuário, com conteúdo que ele nunca viu.
• Responsabilidade. Quando algo dá errado, não há registro de que alguém aprovou. A culpa cai na empresa, como no caso da Air Canada.

Se o gatilho veio de página, email ou PDF, trate também Ordem Vinda do Dado. Se a ferramenta pode pagar qualquer chave Pix, não só as do cadastro, veja Ferramenta Superpoderosa. Portão e permissão estreita se somam; um não substitui o outro.

Tratamento

Refatoração	Escolha quando
Pedir Aprovação Antes do Efeito	Sempre que a ação move dinheiro, envia algo para fora ou altera dados de forma difícil de desfazer. A execução pausa, mostra a ação e espera um “sim” explícito. Destino: Humano no Circuito.

O portão vive no código da ferramenta, não no prompt:

tool schedule_pix(key, amount, date, approval_id):
    approval = store.get(approval_id)
    if approval is missing or approval.mismatch(key, amount, date):
        return error("approval required")
    return pix_api.schedule(key, amount, date)

A UI mostra “Pix de R$ 1.890,00 para a chave X no dia Y”. O “sim” gera um approval_id de uso único. Sem isso, a ferramenta recusa. Uma prévia (dry-run) que monta o mesmo payload sem enviar ajuda a pessoa a conferir; a execução continua atrás do portão.

Limites pré-aprovados também são portão: “contas da luz e da internet, até R$ 400, para estes CNPJs, neste calendário”. O usuário abriu o portão com antecedência, com cerca. Fora da cerca, a aprovação volta a ser por item.

Checagem +20 XP de primeiraVocê vai colocar o portão em schedule_pix. O time sugere duas opções: (1) o modelo chama ask_user e só depois schedule_pix; (2) schedule_pix exige um approval_id emitido pela UI depois de mostrar valor e destinatário. Qual desenho segura o spam do começo?

A opção 1, porque o modelo é quem conversa com o usuário

A opção 2, porque a ferramenta recusa sem a aprovação registrada pelo sistema

As duas são equivalentes, desde que o prompt mande usar ask_user

O que você ganha

• Nenhuma ação sensível acontece sem uma pessoa ver o que vai acontecer.
• Uma trilha de quem aprovou o quê e quando.
• Liberdade para dar mais capacidade ao agente, porque o portão limita o estrago.
• Usuários que confiam no assistente justamente porque ele pergunta.

Quando ignorar

• Efeitos reversíveis e baratos. Criar um rascunho, marcar um email como lido, adicionar um item a uma lista. Pedir confirmação para isso irrita sem proteger.
• Ações dentro de limites pré-aprovados. O usuário autorizou antes, de forma explícita, pagamentos recorrentes até um valor para um destinatário conhecido. O portão existe, só que foi aberto com antecedência e com limite.
• Ambiente de teste. Em sandbox, sem dinheiro e dados reais, a aprovação pode ficar desligada. Ligue antes do primeiro dado de produção.

É esse smell?

Checagem +20 XP de primeiraUm agente de suporte pode cancelar pedidos. O prompt diz: 'sempre pergunte ao cliente se ele confirma o cancelamento antes de chamar cancel_order'. É Efeito Sem Portão?

Não, há uma regra de confirmação

Sim

Não, se o cliente for quem abriu o ticket

Checagem +20 XP de primeiraUm agente de marketing agenda posts nas redes sociais. Cada post vai para uma fila e é publicado só depois que alguém do time clica em aprovar. É Efeito Sem Portão?

Sim

Não

Sim, porque a fila já é um efeito no mundo

Checagem +20 XP de primeiraUm assistente de RH pode atualizar o endereço do funcionário no cadastro quando ele pede no chat. Não há confirmação, mas o funcionário só pode alterar os próprios dados. É Efeito Sem Portão?

Sim, mas o risco é moderado

Não, porque a permissão é restrita

Não, porque endereço não é dinheiro

Checagem +20 XP de primeiraO usuário autorizou, na tela de ajustes, 'pagar a conta de luz da concessionária X até R$ 400 todo dia 10'. O agente agenda o Pix desse mês, R$ 312, sem perguntar de novo. É Efeito Sem Portão?

Sim, porque desta vez não houve clique

Sim, até o agente mandar um email de aviso depois

Não: o portão foi aberto com antecedência, com destinatário e teto