Como evitar dark patterns no prompt de gorjeta automatizado

Quando o robô pede gorjeta: o que isso diz sobre UX, ética e automação

Eu vi pela primeira vez um braço robótico servindo café em vídeo há uns três anos e achei curioso. Agora vejo o mesmo equipamento pedindo 10% de gorjeta no checkout e a conversa muda completamente de tom. Segundo o Sapo.pt, bares, cafés e restaurantes na Europa e nos EUA estão adotando braços mecânicos, baristas automatizados e garçons-robô que, tal como um funcionário humano, exibem uma tela de gorjeta no momento do pagamento.

O ponto que ninguém comenta: a gorjeta é um contrato social entre humanos. Quando transfiro essa expectativa para uma máquina, eu — como dev — preciso perguntar o que está rodando por trás daquela tela, quem fica com o dinheiro e por que diabos um equipamento sem consciência tem coragem de pedir gratificação. Esse artigo é sobre isso.

O que está acontecendo, tecnicamente, nesses bares automatizados

Não é magia. A maioria desses sistemas é uma combinação de três camadas:

• Atuadores físicos — braços com 6 ou 7 graus de liberdade, geralmente baseados em plataformas como UR5/UR10 da Universal Robots ou braços customizados chineses que aparecem em vídeos virais do TikTok.
• Pipeline de visão computacional — câmeras RGB-D identificando copos, gelo, frutas e garrafas. O stack mais comum que vi em projetos do gênero usa YOLOv8 ou YOLOv11 com modelos fine-tuned para objetos de bar.
• Frontend de pagamento — a parte que realmente nos interessa. É um tablet Android ou um display dedicado rodando um app que se comunica com a API do processador de pagamento (Square, SumUp, Stripe Terminal, etc.). É nessa tela que mora a pergunta da gorjeta.

O Sapo.pt destaca que a taxa sugerida, geralmente 10%, aparece logo após a escolha do método de pagamento. Do ponto de vista de UX, isso é uma técnica de opt-in por padrão: o usuário precisa tocar ativamente em “Sem gorjeta” para não pagar. É o mesmo padrão obscuro que vemos em apps de delivery, mas agora aplicado a um sistema onde o “funcionário” sequer sabe que está trabalhando.

A brecha legal que ninguém quer discutir

Nos EUA, a Fair Labor Standards Act proíbe patrões e supervisores de ficar com gorjetas de funcionários humanos. Mas como uma máquina não tem personalidade jurídica, não tem proteção trabalhista e, principalmente, não tem conta bancária, o dinheiro vai direto para o caixa do estabelecimento. Não existe legislação clara definindo para onde vai essa gorjeta quando o “funcionário” é um cobot.

Isso me incomoda. Se eu implemento um sistema de pagamentos, eu sou responsável por transparentar o fluxo do dinheiro. Como dev, eu exijo que o operador do robô me diga: o que acontece com esses 10%? Vai para manutenção do equipamento? Vai para o humano que supervisiona o turno? Vai para o lucro? Se a resposta for “não sei”, o sistema tem um problema ético de design.

Por que desenvolvedores deveriam se importar com isso

Porque essa tendência não é só sobre hospitalidade. É sobre como sistemas automatizados interagem com contratos sociais humanos. E isso é literalmente o problema que estamos resolvendo agora com agentes de IA, chatbots de suporte e assistentes virtuais.

Pense no equivalente em software: você já usou um chatbot que, no final da interação, oferece um “deixe uma avaliação positiva” como se fosse uma gorjeta emocional? Você já viu uma IA generativa pedir feedback com peso emocional desproporcional ao que entregou? É o mesmo padrão.

O ponto não é “robô bonito fazendo drinks”. O ponto é: quem define o contrato de interação entre usuário e máquina automatizada? Quem decide se a gorjeta aparece, com qual valor sugerido, em que momento do fluxo? Spoiler: é o dev. Somos nós.

Na Prática: implementando um prompt de gorjeta “ético”

Se você, como eu, está construindo um PDV, um kiosk ou qualquer fluxo de pagamento automatizado, vai eventualmente precisar lidar com gorjeta. Aqui vai um exemplo real que usei em um projeto de cafeteria automatizada. A ideia é: o sistema pode sugerir gorjeta, mas precisa ser explícito, auditável e configurável.

// payment-tip-prompt.js
// Fluxo de gorjeta transparente para PDV automatizado
// Yuri Augusto — yurideveloper.com.br

const TIP_CONFIG = {
  enabled: true,
  // Percentuais sugeridos — usuário pode customizar ou escolher zero
  suggestedPercents: [10, 15, 20],
  defaultPercent: 0, // IMPORTANTE: default é zero, não um valor arbitrário
  // Destinação obrigatória declarada antes do checkout
  destination: 'maintenance_and_staff_pool',
  // Tempo mínimo antes do auto-advance (em ms)
  minDecisionTimeMs: 4000,
  // Forçar escolha explícita
  requireExplicitChoice: true,
};

function renderTipPrompt(transaction) {
  const container = document.getElementById('tip-container');
  container.innerHTML = '';

  if (!TIP_CONFIG.enabled) {
    proceedToCharge(transaction, 0);
    return;
  }

  // 1. Transparência ANTIS da escolha
  const disclosure = document.createElement('p');
  disclosure.innerHTML =
    `A gorjeta é opcional e 100% do valor vai para ` +
    `${getDestinationLabel(TIP_CONFIG.destination)}. ` +
    `O robô não recebe nem se beneficia desse valor.`;
  container.appendChild(disclosure);

  // 2. Botões com escolha explícita
  TIP_CONFIG.suggestedPercents.forEach((pct) => {
    const btn = document.createElement('button');
    btn.textContent = `${pct}% (R$ ${(transaction.subtotal * pct / 100).toFixed(2)})`;
    btn.onclick = () => proceedToCharge(transaction, pct);
    container.appendChild(btn);
  });

  // 3. SEMPRE oferecer a opção "sem gorjeta" como botão de mesmo tamanho
  const noTipBtn = document.createElement('button');
  noTipBtn.textContent = 'Não, obrigado';
  noTipBtn.style.fontWeight = 'bold';
  noTipBtn.onclick = () => proceedToCharge(transaction, 0);
  container.appendChild(noTipBtn);

  // 4. Input custom para quem quiser digitar
  const customInput = document.createElement('input');
  customInput.type = 'number';
  customInput.placeholder = 'Outro valor em R$';
  customInput.min = '0';
  customInput.onchange = () => {
    const value = parseFloat(customInput.value) || 0;
    proceedToCharge(transaction, { customAmount: value });
  };
  container.appendChild(customInput);
}

function proceedToCharge(transaction, tip) {
  const tipAmount = typeof tip === 'number'
    ? transaction.subtotal * tip / 100
    : tip.customAmount || 0;

  // Log para auditoria — todo valor precisa ser rastreável
  auditLog({
    timestamp: new Date().toISOString(),
    transactionId: transaction.id,
    tipAmount,
    tipDestination: TIP_CONFIG.destination,
    userAgent: navigator.userAgent,
  });

  chargeCard({ ...transaction, tip: tipAmount });
}

Repare nos quatro pontos não negociáveis:

1. Default é zero. Nunca assuma que o usuário quer pagar gorjeta.
2. Disclosure antes da escolha. O usuário precisa saber para onde vai o dinheiro.
3. Botão “sem gorjeta” do mesmo tamanho. Sem nudging visual obscuro.
4. Log de auditoria. Cada transação registra o valor e o destino. Se um fiscal perguntar, você responde em segundos.

Erros comuns que devs cometem ao implementar prompts de gorjeta

Já revisei código de três empresas diferentes cometendo a mesma penca de erros. Aqui estão os mais graves:

• Pré-selecionar um percentual por padrão. O sistema do robô do vídeo provavelmente faz isso. É conversionamento, não usabilidade. Configure defaultPercent: 0.
• Ocultar a opção “sem gorjeta”. Já vi kiosk que exige três toques para chegar no “0%”. Isso é dark pattern puro e viola guidelines da FTC nos EUA.
• Não diferenciar gorjeta de taxa de serviço. Tem sistema cobrando 10% rotulado como “service fee” que vai direto para o caixa. Isso, dependendo da jurisdição, é propaganda enganosa.
• Assumir que automação elimina responsabilidade legal. “Ah, mas é o robô que pede, não fui eu” não funciona. Quem programou a UX responde. O Sapo.pt já levanta essa questão: a proteção legal não existe porque ninguém legislou. Mas isso não significa que não há risco.
• Não logar a gorjeta separadamente no banco de dados. Misturar gorjeta com o valor da transação principal é receita para desastre contábil. Separe em colunas: subtotal, tip, total.

O que isso significa para o futuro dos agentes de IA

A discussão de hoje sobre “robô pedir gorjeta” é um ensaio geral para um problema muito maior: agentes de IA autônomos pedindo coisas. Pense em um agente LLM que, após resolver seu problema, sugere “avalie este atendimento com 5 estrelas para melhorar minha performance”. Mesma dinâmica, mesmas implicações éticas.

Como comunidade técnica, precisamos de frameworks públicos para isso. Quem define a política de prompting de um agente? Quem audita? Quem garante que o “feedback positivo” não está sendo usado para treinar o modelo contra o usuário? Essas perguntas vão deixar de ser hipotéticas em 2026.

Comparando alternativas reais: kiosk tradicional vs. tablet Android vs. app mobile

Para um braço robótico que já está conectado a um sistema interno, a opção tablet Android com app custom é, na minha experiência, a que dá melhor controle sobre transparência. O kiosk dedicado parece robusto, mas você entrega a UX para um terceiro que pode mudar a lógica de gorjeta sem te avisar. Já vi acontecer.

FAQ

Robô pode legalmente pedir gorjeta?

Hoje, não existe legislação específica. A gorjeta é juridicamente um ato de liberalidade do cliente. O robô não é sujeito de direito, então o valor vai para a pessoa jurídica que opera o equipamento. O problema surge quando o operador não transparentiza isso — o que pode configurar prática abusiva em diversos países.

Como diferenciar gorjeta de taxa de serviço no checkout?

No banco de dados, use colunas separadas: subtotal, service_fee (se aplicável, com justificativa legal), tip, total. Na UI, rotule cada linha de forma inequívoca. “Taxa de serviço” e “gorjeta” não podem aparecer como a mesma coisa — não são.

Qual a melhor forma de implementar prompt de gorjeta sem cair em dark pattern?

Default em zero, disclosure do destino antes da escolha, botão “sem gorjeta” visualmente equivalente aos demais, e log de auditoria por transação. Esses quatro itens cobrem 95% das boas práticas internacionais.

Vale a pena colocar gorjeta em um sistema automatizado?

Depende do modelo de negócio. Se o equipamento reduz custo operacional e o operador reinveste a gorjeta em manutenção ou em equipe de supervisão, pode ser uma ponte interessante entre o mundo físico e o digital. Se a gorjeta vira só margem extra disfarçada, é problema reputacional esperando para acontecer.

Como aplicar isso em um chatbot/IA?

Mesma lógica: default neutro, transparência sobre o destino do dado (treinamento? melhoria? marketing?), opção de pular sem fricção, e log de auditoria. O “robô que pede gorjeta” é só o caso físico de um problema que já temos no software.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.