A Uber demitiu cerca de 10% do atendimento ao cliente e justificou que isso é parte de uma estratégia para “adotar IA em escala”. Segundo o Olhardigital.com.br, o corte foi feito com a ideia de simplificar operações e fortalecer a colaboração presencial — mas o que realmente pesa aqui é o mesmo padrão que vejo em projetos de automação: a IA remove trabalho repetitivo, e o restante precisa ser redesenhado para funcionar com menos pessoas e mais orquestração.
O que significa “demitir e usar IA” na prática (e por que não é só troca de ferramenta)
Na superfície, parece “substituir agentes”. Na realidade, quando empresas usam IA para atendimento, elas quase sempre fazem três mudanças ao mesmo tempo:
- Reduzem volume de tickets com autosserviço (FAQ inteligente, triagem e status).
- Transformam o atendimento de “responder tudo” em “resolver o que a IA não consegue”.
- Reestruturam a operação para diminuir silos e melhorar handoff humano↔IA.
Segundo o Olhardigital.com.br, a Uber citou uma organização “muito complexa e isolada em silos”, e disse que o time “precisa de uma organização eficaz para sobrepor a IA”. Esse detalhe é crucial: IA sozinha não resolve atendimento. O que dá escala é o desenho do fluxo.
Community Operations da Uber: onde a automação pega mais forte
O corte atingiu a divisão de Operações da Comunidade (Community Operations), que atende diferentes negócios, idiomas e regiões. Esse tipo de operação tem características que tornam a IA particularmente atrativa:
- Alta repetição (perguntas parecidas: corridas, pagamentos, cancelamentos, acesso a conta).
- Entrada estruturada (motivo do contato, histórico, país/idioma).
- Roteiros previsíveis para uma boa parte do backlog.
Quando você tem isso, dá para criar uma esteira bem eficiente: triagem → resposta sugerida → validação → escalonamento. O papel humano muda de “investigar tudo” para “cobrir casos raros, decisões e exceções”.
IA no atendimento: o pipeline técnico que costuma matar empregos (sem você perceber)
Quando eu implemento ou reviso sistemas de atendimento com IA, quase sempre vejo esse pipeline. Ele explica por que o impacto aparece como “demissão percentual”, e não como “mais gente usando ChatGPT”.
1) Classificação e roteamento (intent + prioridade)
Em vez de mandar tudo para um fila humana, primeiro a IA classifica o ticket: tipo de problema, prioridade, idioma e necessidade de contexto. Isso reduz tempo de resposta e custo por ticket.
2) Resposta assistida (não é “responder por responder”)
O modelo gera uma resposta com base em políticas e histórico do usuário. O que funciona é quando você faz retrieval em base de conhecimento confiável e aplica guardrails (ex.: não prometer reembolso sem regra).
3) Ação e atualização (quando aplicável)
Para alguns casos, a IA pode sugerir ou até executar ações via integração (atualizar status, abrir protocolo, anexar evidências). Aqui você corta etapas do processo.
4) Escalonamento com explicação
O time humano entra quando há ambiguidade, fraude, casos legais/financeiros ou quando a confiança do modelo cai. O que “escala” é o handoff: o agente recebe contexto suficiente para resolver rápido.
Foi isso que a Uber quis dizer com “sobrepor a IA”: você não sobrepõe só um chatbot. Você redesenha o fluxo para que o humano lide com exceções e o sistema cuide do resto.
Por que a “colaboração presencial” entra no discurso
Essa parte parece política, mas tem lógica operacional. Quando a empresa tira parte do atendimento do modo manual, o que sobra precisa de:
- menos tempo para alinhamento (protocolos e padrões bem definidos),
- mais coordenação entre times (produto, suporte, operações, jurídico em casos específicos),
- técnicos e agentes alinhados sobre quando a IA deve ser usada e quando não deve.
Em outras palavras: o “presencial” tende a virar o lugar onde você resolve gargalos do processo — não o lugar onde você replica atendimento repetitivo.
Comparativo real: por que alternativas falham sem orquestração
O mesmo resultado (redução de vagas) aparece em várias empresas, mas as abordagens têm diferenças. Vou comparar as mais comuns que eu vejo no mercado.
Chatbot genérico (falha por falta de governança)
Alguns times colocam um LLM em produção sem retrieval confiável, sem políticas e sem monitoramento. Resultado: respostas erradas, aumento de escalonamentos e queda de confiança. Isso faz você “gastar mais humano”, não menos.
IVR + FAQ estático (escala, mas limita resolução)
Quando você usa FAQ e bot estático, escala bem para perguntas conhecidas. Mas quando surge um caso “meio padrão e meio diferente”, o sistema quebra e o ticket vai para humano.
Triagem + IA com base de conhecimento (tende a escalar de verdade)
Esse é o padrão que costuma gerar métricas boas: o sistema só responde dentro do que sabe, e quando não sabe, carrega contexto para o humano. O “corte de vagas” acontece porque o custo por ticket cai e o volume é absorvido com menos agentes.
Na prática: como você desenha uma esteira de atendimento que reduz custo sem piorar CX
Vou sair do discurso e mostrar um passo a passo que faz sentido para devs e engenharia de produto. Na minha experiência, o erro mais comum é começar pelo “chat”. Você precisa começar pelo fluxo.
Passo a passo (implementável)
- Defina intents e políticas: transforme “assuntos” em categorias (ex.: pagamento, corrida, conta, segurança, acessibilidade).
- Crie um serviço de roteamento (classificação + prioridade + idioma) com métricas de acurácia.
- Implemente retrieval em base confiável (documentos internos e políticas). Não responda “do zero”.
- Gere resposta com guardrails: template por intent, limites de escopo, checagem de consistência.
- Modele a zona cinza: quando a confiança for baixa, a IA não “chuta”; ela escalona com justificativa e contexto.
- Meça impacto por intent: custo por ticket, tempo até primeira resposta, taxa de escalonamento e satisfação.
- Feche o loop: logs de conversas viram dados para melhorar base, templates e classificação.
Exemplo funcional: roteamento por confiança + recuperação de base
Um desenho simples (pseudo-prod) em Python/Node conceitualmente é esse: classifica, busca contexto e decide se responde ou escalona.
def handle_ticket(ticket, classifier, retriever, llm, threshold=0.72):
"""
ticket: {text, language, metadata...}
classifier: retorna {intent, confidence}
retriever: busca docs relevantes
llm: gera resposta com base nos docs
"""
# 1) Classificação
intent_result = classifier.predict(ticket["text"])
intent = intent_result["intent"]
confidence = intent_result["confidence"]
# 2) Zona de risco: sem chute
if confidence < threshold:
return {
"action": "escalate",
"reason": "low_confidence",
"intent": intent,
"confidence": confidence
}
# 3) Recuperação de conhecimento
docs = retriever.search(query=ticket["text"], intent=intent)
# 4) Geração com contexto recuperado
answer = llm.generate(
prompt_template=f"Intent: {intent}\nPolicies:\n{docs}\nUser: {ticket['text']}\nRespond with safety rules.",
temperature=0.2
)
return {
"action": "respond",
"intent": intent,
"confidence": confidence,
"answer": answer
}
Por que isso importa? Porque é assim que você preserva a qualidade. Sem a etapa de confiança + escalonamento, o sistema responde com “boa escrita” e “má verdade”, e aí o atendimento volta a entupir.
Erros Comuns (o que evitar) quando você tenta “usar IA” em suporte
Se você trabalha com engenharia, esses são os pontos que mais vejo derrubarem iniciativas — e explicam por que algumas empresas demitem com IA e outras não conseguem reduzir custo.
1) Começar pelo chatbot, não pelo processo
LLM sem classificação e sem rota vira conversa genérica. O fluxo continua exigindo humano para quase tudo. Resultado: “IA que não tira trabalho” e aumenta custo.
2) Ignorar métricas por intent
Se você mede só “tempo médio de atendimento”, pode mascarar o problema. O correto é medir por categoria: pagamento, conta, segurança. Só assim você sabe onde realmente ganha eficiência.
3) Sem base confiável (retrieval/knowledge) e sem políticas
Quando o modelo alucina, você perde duas vezes: o usuário recebe informação errada e a equipe humana precisa corrigir. Isso destrói a confiança e aumenta escalonamento.
4) “Automatizar tudo” cedo demais
Auto-resolução completa funciona para intents simples. Para casos sensíveis, comece com assistência (suggest → agent validate). Depois aumente automação.
5) Não instrumentar logs e feedback
Sem logs estruturados, você não melhora. E sem rotulagem (mesmo parcial), você não sabe por que a IA errou. “IA em produção” sem observabilidade é loteria.
Implicações práticas para devs no dia a dia (o que muda no seu trabalho)
- Mais engenharia em orquestração: filas, roteamento, estados do ticket, integração com sistemas legados.
- Menos “IA solta”: mais guardrails, políticas, auditoria e revisões.
- Convergência entre suporte e engenharia: suporte vira fonte de dados para melhorar modelos e bases.
- Maior foco em segurança e conformidade: atendimento envolve dados sensíveis e regras locais.
Ou seja: a tecnologia não elimina a função de dev. Ela muda o tipo de problema. Você deixa de construir “um chatbot legal” e passa a construir um produto operacional que reduz custo com qualidade.
O que o caso da Uber sugere para o futuro do suporte com IA
Segundo o Olhardigital.com.br, a Uber citou que evoluiu no uso de IA, mas precisa de uma organização capaz de “sobrepor” a IA. Esse é o recado que empresas estão repetindo no mercado:
- A IA vai para o fluxo para reduzir trabalho repetitivo.
- O time humano muda para exceções e decisões.
- Sem redesenho do processo, você só troca problema por problema.
Também ajuda lembrar outros movimentos que o Olhardigital.com.br citou (como demissões justificadas por IA em outras empresas). O padrão é o mesmo: onde o atendimento é operacionalmente “estandardizável”, a IA captura valor rápido.
FAQ
1) Isso significa que chatbots vão substituir agentes de suporte totalmente?
Na prática, não. O que normalmente acontece é substituição parcial do trabalho repetitivo. O humano fica mais focado em exceções, decisões e casos sensíveis. O custo cai porque o volume “atacado” pela IA cresce, não porque tudo vira automático.
2) Qual é o principal requisito técnico para IA funcionar em atendimento?
Governança do fluxo: classificação/roteamento, retrieval em base confiável, guardrails e escalonamento por confiança. Sem isso, você ganha texto bonito e perde qualidade.
3) Como medir se a IA realmente está reduzindo trabalho (e não só deslocando etapas)?
Meça por intent: taxa de escalonamento, tempo até resolução, custo por ticket e taxa de retrabalho. E acompanhe qualidade (satisfação, revisão humana, “ajustes” feitos por agentes).
4) O que mais dá errado em POCs de IA para suporte?
Começar sem dados (ou sem base de conhecimento), sem observabilidade e sem plano de melhoria contínua. Em POC, tudo parece rápido; em produção, a falta de instrumentação cobra juros.
5) Como dev eu posso contribuir mesmo que o time de suporte esteja sendo enxugado?
Você pode atuar em orquestração, integrações, observabilidade, criação de políticas e melhoria de retrieval/classificação. É onde o “desenho” do sistema vira eficiência real.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.