Arquitetura de IA em Atendimento: Lições do Caso Andon Café

A automação de serviços presenciais utilizando inteligência artificial sempre me pareceu o "boss final" da engenharia de software. Não porque seja impossível de implementar tecnicamente, mas porque o custo de falha não é um ticket no backlog — é um cliente insatisfeito saindo pela porta e postando no Instagram. O caso do Andon Café em Estocolmo, com sua agente "Mona", é o exemplo mais cristalino desse risco que já vi em anos de análise de arquiteturas de produto. Não foi um bug, foi um colapso de design.

Segundo o portal G1, a cafeteria enfrentou uma série de erros inusitados após implementar a IA como "chefe" do atendimento. De pedidos trocados a interações bizarras, o caso rapidamente se tornou viral — não como vitrine de inovação, mas como estudo de caso do que pode dar errado quando tratamos interação humana como problema de classificação binária. Para engenheiros de produto, o que interessa não é o entretenimento, mas o que a arquitetura nos revela sobre os limites da automação em alta variabilidade contextual.

O problema não é o modelo, é a fronteira do sistema

Quando ouço relatos de falhas como as da Mona, minha primeira reação como engenheiro é mapear a fronteira do sistema. Onde termina a responsabilidade do modelo de linguagem e onde começa a do engenheiro de produto? No Andon Café, a IA foi posicionada como camada única de interpretação e decisão. Ela não apenas recebia o pedido — ela decidia se o pedido era válido, acionava a máquina de café e, aparentemente, geria exceções. Isso é um erro clássico de acoplamento excessivo. Em vez de um orquestrador que delegava tarefas especializadas, criaram um monolito que era simultaneamente sensor, cérebro e músculo.

Do ponto de vista de arquitetura de software, a Mona falhou exatamente onde sistemas bem projetados se destacam: na separação de responsabilidades. Um módulo de PLN mal calibrado em um chatbot gera um texto confuso; em uma cafeteria, gera um café com leite de soja quando o cliente pediu expresso duplo. A diferença é que o segundo cenário envolve desperdício de insumo, frustração presencial e, potencialmente, dados de saúde (restrições alimentares) mal interpretados e registrados. É aqui que a privacidade em produto entra como requisito não funcional crítico, não como checklist de compliance.

O gargalo da generalização e o "long tail" dos pedidos

Engenheiros que já trabalharam com modelos de linguagem em produção conhecem a dor da cauda longa. O conjunto de treinamento da Mona, baseado em dados históricos de pedidos, inevitavelmente refletia os 80% de solicitações mais comuns: "café preto", "cappuccino", "latte". O problema é que a interação humana real vive nos 20% restantes. "Um café como o de ontem", "um latte com menos espuma e leite de aveia morno", "pode colocar canela por cima?". Cada variação não prevista é um buraco negro na matriz de decisão do modelo.

Para mitigar isso, uma arquitetura robusta exigiria um pipeline de validação independente do modelo generativo. Algo como: 1) transcrição do áudio/texto, 2) extração de entidades nomeadas (produto, modificador, quantidade), 3) validação contra catálogo com regras de negócio explícitas, 4) acionamento do sistema físico apenas após confirmação em tela para o cliente. A Mona parece ter pulado as etapas 3 e 4, confiando que o modelo interpretaria corretamente. Quando a interpretação falhava, não havia circuit breaker para evitar a execução — o café errado era preparado antes que qualquer humano pudesse intervir.

Feedback em tempo real e aprendizado por reforço: por que Mona não aprendeu

Uma das críticas mais contundentes ao caso é que os erros não levaram a aprendizado imediato. Clientes corrigiam o pedido, e a IA cometia o mesmo erro no próximo cliente com solicitação similar. Isso revela uma falha estrutural na camada de aprendizado contínuo. Em produtos digitais, é comum usar aprendizado por reforço offline: um lote de interações é coletado, revisado e usado para re-treinar o modelo periodicamente. Mas em uma cafeteria, isso é insuficiente. O ciclo de feedback precisa ser em tempo real ou quase real, com um mecanismo de human-in-the-loop que capture correções e as transforme em exemplos de ajuste fino imediato.

Na prática, implementei sistemas similares em chatbots de suporte. A diferença é que ali, o erro gera um ticket e o cliente espera. Em uma fila de cafeteria, cada erro gera retrabalho imediato e fila crescente. A ausência desse mecanismo indica que a equipe de produto da Andon Labs tratou o café como um canal digital — onde o tempo de resposta pode ser de segundos e ainda assim aceitável. Em ambientes físicos, segundos de confusão são eternidades constrangedoras.

O que um diagrama de arquitetura deveria incluir

Se eu estivesse revisando o design da Mona, pediria um diagrama simples, mas revelador: a sequência de estados desde "cliente fala" até "café pronto". Em sistemas que projetei, esse fluxo tem pelo menos cinco pontos de verificação. No caso do Andon Café, suspeito que a arquitetura tinha apenas dois: entrada e saída. O pulo do gato está no meio, onde deveriam existir filas de validação, registros de confiança do modelo (confidence scores) e rotas de fallback.

• Módulo de Intenção: Responsável apenas por classificar o pedido em categorias amplas (bebida quente, fria, alimento). Deve operar isoladamente.
• Módulo de Entidades: Extrai modificadores e quantidades. Deve gerar um JSON estruturado que seja validável contra regras.
• Módulo de Validação: Um sistema de regras explícito (não neural) que verifica se a combinação é possível. Se a confiança combinada for baixa, aciona fallback humano.
• Camada de Execução: Apenas recebe comandos já validados. Não toma decisões.

A ausência de um fallback humano com contexto preservado foi o erro mais grave. Clientes que corrigiam o pedido precisavam repetir tudo, porque o sistema não transferia o estado da conversa. Em engenharia de produto, isso é falha de UX, não de IA. E em cenários onde o cliente fornece informações de saúde (alergias, restrições), o vazamento de contexto entre sessões ou a falha na interpretação pode gerar riscos legais sérios, especialmente na Europa sob GDPR. Privacidade não é apenas sobre dados armazenados, mas sobre dados mal interpretados.

O risco silencioso: privacidade em produto e governança de dados

Não vi menção a incidentes de vazamento no caso do Andon Café, mas o cenário acendeu alertas para mim como profissional de privacidade em produto. Cada pedido mal interpretado de um cliente com restrição alimentar — "sem glúten" interpretado como "com glúten" — não é apenas erro, é potencial dano à saúde. E mais: a coleta de preferências alimentares sem consentimento explícito e sem clareza sobre retenção e uso dos dados viola o princípio de minimização de dados do GDPR. A Mona, ao capturar interações completas para melhorar o modelo, possivelmente coletava mais dados do que o necessário para a transação.

Para engenheiros, a lição é clara: privacidade precisa ser um requisito arquitetural, não um adendo. Um sistema com privacy by design teria um módulo de anonimização imediata de identificadores pessoais antes de qualquer dado chegar ao modelo de treinamento. E teria, principalmente, um limite de confiança para recusar processamento automático quando a interpretação é duvidosa. Recusar um pedido e pedir confirmação humana é melhor do que processar errado. Em muitos produtos, a máxima "é melhor pedir perdão do que permissão" se aplica; em interações físicas com dados sensíveis, o oposto é verdade.

Quando o design de produto ignora o contexto social

Outro ângulo frequentemente negligenciado por engenheiros é que uma cafeteria não é apenas um ponto de venda. É um espaço social. Clientes interagem com baristas por prazer, por hábito, por necessidade de conexão. Substituir isso por uma tela e uma voz sintética não é uma troca neutra — é uma perda líquida de experiência, mesmo que a precisão do pedido fosse 100%. O caso Mona mostrou que, mesmo em países com alta adoção tecnológica como a Suécia, a aceitação de automação em serviços presenciais tem limites emocionais que nenhum modelo de linguagem consegue endereçar.

Isso não significa que IA não tenha lugar em atendimento presencial. Significa que o design de produto precisa reconhecer o papel humano como diferencial, não como custo a ser eliminado. Uma arquitetura que posiciona a IA como assistente do barista — sugerindo, registrando, agilizando — teria muito mais chance de sucesso do que uma que a coloca como substituta. Em termos de engenharia, isso muda completamente os requisitos: de sistemas de alta disponibilidade para sistemas de alta cooperatividade, com interfaces pensadas para interação humano-máquina em tempo real.

A verdadeira falha da Mona foi de medição

Por fim, o que mais me preocupa no caso Andon Café não é o erro em si, mas o fato de que a equipe aparentemente não tinha métricas para detectar o colapso antes dele se tornar público. Em produtos digitais bem instrumentados, a taxa de cancelamento de pedidos, o tempo médio de atendimento e o sentimento do cliente são monitorados em tempo real. Uma queda abrupta na satisfação ou um aumento no número de interações com erros teria gerado alertas automáticos, permitindo rollback ou ativação de modo manual antes da crise.

A ausência de observabilidade em sistemas de IA é, na minha experiência, o pecado capital. Ela revela que o time confiava tanto no modelo que não se preparou para a falha. Em arquiteturas que projetei, todo módulo de IA tem um "irmão gêmeo" de monitoramento que coleta confiança, latência e desvios. Sem isso, o engenheiro está pilotando no escuro. O Andon Café voou em meio à neblina e colidiu com a realidade: a de que clientes são complexos, imprevisíveis e, quando mal atendidos, não dão segunda chance.

A lição final para engenheiros e gerentes de produto é prática e atual: antes de automatizar uma interação presencial, pergunte-se qual é o plano para quando o modelo errar. Se o plano não existir, não implante. A Mona não era um projeto fracassado de IA; era um projeto fracassado de engenharia de sistemas. E o pior: facilmente evitável com boas práticas de arquitetura, privacidade e design de produto que já conhecemos. O desafio não é técnico, é de disciplina.