O Caso Air Canada: Quando um Palpite Vira Política
Em 2024, um cliente da Air Canada perguntou ao chatbot sobre tarifas de falecimento. O bot citou com confiança uma política de reembolso que não existia. A companhia se recusou a honrar. Um tribunal deu razão ao cliente. 😬
O bot não decidiu nada. Ele previu texto plausível. Mas a interface apresentou essa previsão com a mesma confiança de um documento oficial — sem ressalvas, sem fallback para humano, sem incerteza visível. O usuário leu confiança como compromisso. Juridicamente, o tribunal também leu.
Esse é o risco central de colocar IA em produção hoje: sistemas probabilísticos embrulhados em interfaces determinísticas.
A gente é programado pra pensar de forma determinística. Joga uma moeda 999 vezes e dá cara em todas — a mente determinística assume que a moeda tá viciada. A mente probabilística aceita que o 1000º lançamento ainda pode dar coroa. É essa segunda cabeça que os times de produto precisam agora.
Esse guia é sobre usar IA pra afinar o julgamento — não terceirizar ele. O argumento completo está no deep dive da Smashing Magazine sobre design com incerteza.
Pensamento Probabilístico: Trate Saídas de IA como Sinais, Não Veredictos
A maioria das perguntas que fazemos pra IA não tem resposta binária. Pergunta "existem aliens?" e você recebe algo entre plausível e incerto. A resposta não resolve a pergunta — ela enquadra como probabilidade.
A Netflix não sabe que você vai gostar de Superstore porque assistiu The Office. Ela estima a probabilidade e coloca o título na frente. A interface responde a uma previsão.
Decisões de design podem seguir a mesma lógica. Imagina um cenário onde analytics apontam 60% vs. 90% de confiança de que o usuário vai finalizar a compra:
- A 60%: o design precisa fazer trabalho persuasivo — depoimentos, comparações, sinais de segurança.
- A 90%: o usuário já está motivado — remova atrito pra ação acontecer rápido.
Mesma tela. Problemas de design completamente diferentes. 🎯
Avaliando Designs com Prompts Estruturados
Quando você não tem acesso direto ao grupo-alvo, prompts estruturados podem simular a avaliação. Olha só esse template pra analisar um design sob a ótica de usuários neurodivergentes:
Avalie [arquivo de design ou URL] quanto a usabilidade,
acessibilidade e relevância de conteúdo sob a ótica de
usuários neurodivergentes (ex.: espectro autista, TDAH,
dificuldades de aprendizagem).
Critérios:
- Layout e navegação são intuitivos pra esse grupo?
- Linguagem e conteúdo são apropriados e engajantes?
- Existem barreiras técnicas, cognitivas ou sensoriais?
- O site atende bem aos objetivos específicos deles?
Saída: análise SWOT + score de probabilidade de uso
bem-sucedido + recomendações concretas.
Trate isso como ponto de partida de conversa com o time — não como veredicto. E lembra: simulações não substituem experimentação. Modelos treinados em dados históricos refletem o comportamento passado mais do que predizem mudanças futuras.
O Problema do Canhoto
Pede pra um modelo de imagem gerar uma pessoa escrevendo com a mão esquerda e você pode ainda receber um canhoto... quer dizer, um destro. A razão é estatística: a maioria é destra, e os dados de treino refletem isso. O que você recebe não é verdade — é a saída estatisticamente mais provável dado o dataset.
Esse é exatamente o modo de falha que afundou a ferramenta experimental de recrutamento da Amazon. Treinado em cerca de uma década de dados enviesados, o modelo aprendeu a rebaixar currículos que continham a palavra "women's" — tipo "women's chess club captain". O sistema não era intencionalmente enviesado. Os dados eram. A Amazon teria cancelado o projeto depois de não conseguir garantir que o viés não ressurgiria de outras formas.
Human-in-the-Loop é Motor de Refinamento, Não Rede de Segurança
IA deve aumentar o julgamento humano, não substituir. Os sistemas mais confiáveis são projetados com momentos claros onde pessoas podem revisar, questionar, corrigir ou sobrescrever sugestões da máquina.
Como HITL Aparece na Prática
GitHub Copilot oferece sugestões inline que devs aceitam com Tab, editam ou ignoram. O sistema nunca commita código em nome do usuário. Cada aceite, rejeição ou edição é feedback implícito sobre o que foi útil.
Smart Compose do Gmail apresenta texto previsto como opcional, mantendo tom e intenção nas mãos do usuário.
Em contextos de maior risco, HITL fica explícito. Sistemas antifraude usam scores de probabilidade pra rotear decisões:
| Nível de Risco | Ação |
|---|---|
| Baixo | Prossegue automaticamente |
| Médio | Dispara verificação adicional |
| Alto | Escala pra revisor humano |
Combinando Padrões de Interação com Nível de Risco
| Tipo de Usuário | Risco | Objetivo do Design |
|---|---|---|
| Confia demais | Age rápido, confia fácil na IA | Mostrar incerteza em destaque |
| Desconfiado | Ignora a IA completamente | Mostrar acurácia histórica ou níveis de confiança |
| Cético/Equilibrado | Usa IA como guia | Reforçar assistência, deixar decidir |
Comunicar Incerteza Sem Perder Confiança
Uma janela de entrega "sexta a segunda" diz a verdade sobre variabilidade. Um horário específico que atrasa corrói confiança toda vez. Um reconhecimento facial que pergunta "esse parece o Pratik, tá certo?" cria expectativas mais honestas do que um que silenciosamente rotula a foto.
Comunicar incerteza não enfraquece a confiança — fortalece. 💪
Otimize pra Resiliência, Não Só Conversão
Bom design se adapta quando o cenário muda. Um sistema resiliente:
- Se adapta conforme novos dados e comportamentos emergem
- Falha de forma segura, não catastrófica
- Permanece transparente e explicável
- Evita padrões de interação frágeis e superotimizados
- Antecipa efeitos de segunda ordem e não intencionais
O Exemplo do Duolingo
O sistema de corações do Duolingo introduz atrito: erra demais, acaba os corações, precisa esperar ou praticar material antigo. No papel, parece matador de conversão. Na prática, apoia motivação e retenção de longo prazo — a métrica que realmente importa pra um app de aprendizado. Engajamento de curto prazo cai; resultado de longo prazo melhora. 🦉
Checklist de Resiliência Pré-Lançamento
- Como o sistema se comporta sob baixa confiança da IA?
- Qual é o fallback seguro quando a assistência de IA desaparece totalmente?
- Que drifts antecipamos em dados, comportamento e performance do modelo?
- Que efeitos de segunda ordem essa otimização projeta como sombra?
O Reframe Que Muda Tudo
Para de perguntar "isso vai funcionar?" Começa a perguntar: "qual a probabilidade disso funcionar, e o que acontece quando não funcionar?"
Esse único reframe muda como você escreve hipóteses, interpreta saídas de IA, dimensiona experimentos e projeta pros momentos em que o sistema erra. IA não introduziu incerteza no nosso mundo — ela só tornou impossível ignorar a incerteza que sempre esteve lá.
Pense em faixas, não em pontos. Teste premissas, não features. Construa pra adaptação, não pra perfeição.
Leitura relacionada: