--- title: "Arquitetura de um call center de IA para provedores de internet" description: "Como se constrói um atendimento por voz e WhatsApp que fala com o cliente 24/7: telefonia SIP, STT/TTS em tempo real, LLM com fallback e integração com o ERP do provedor." slug: arquitetura-call-center-ia-provedores lang: pt date: 2026-07-22 updated: 2026-07-22 author: Lucas Silva category: deep-dive tags: [Call Center IA, Telefonia, SIP, LiveKit, ISP, Provedores, Voz, STT, TTS] reading_time: 13 featured: true --- Provedor de internet (ISP) vive de duas coisas: cliente conectado e cliente atendido. A primeira é rede; a segunda, historicamente, é gente no telefone. E é aqui que a conta não fecha: o volume de ligações de "minha internet caiu", "cadê meu boleto", "quero a segunda via" é gigante, repetitivo e cresce junto com a base. Contratar atendente na mesma velocidade que a base cresce é insustentável. Foi esse problema que me levou a construir o **ConectaAI** — um call center de IA que atende por voz e por WhatsApp, 24 horas por dia, integrado ao sistema do provedor. Este post é a arquitetura por trás disso. Não é teoria: é o que precisa existir pra uma IA atender uma ligação de telefone de verdade e resolver o problema do cliente. ## O problema real: voz em tempo real é difícil Todo mundo sabe fazer um chatbot de texto. Voz é outro jogo. Numa ligação, o cliente fala, espera resposta, interrompe, muda de assunto — e cada milissegundo de latência é percebido como "esse atendimento é ruim". Se a IA demora 3 segundos pra responder, a conversa morre. Então o desafio central é: **transformar uma ligação telefônica em uma conversa com IA com latência baixa o suficiente pra soar humana.** Isso quebra em várias peças que precisam funcionar juntas em tempo real. ## As camadas do sistema ### 1. A borda de telefonia (SIP) A ligação chega pelo mundo da telefonia tradicional — protocolo SIP, troncos de operadora, tudo isso. Essa borda precisa de um componente robusto que aguente o tráfego real e faça a ponte entre a telefonia e o mundo de mídia em tempo real. É a camada mais chata e menos glamourosa, e é a que mais quebra se você errar. Ela cuida de registro de tronco, roteamento de chamada e a conversão do áudio da telefonia (codecs, RTP) para algo que o resto do sistema entende. ### 2. O transporte de mídia em tempo real Com a chamada estabelecida, o áudio precisa fluir com latência mínima entre o cliente e o agente de IA. Aqui entra uma camada de mídia em tempo real (do mundo WebRTC/streaming) que carrega o áudio nos dois sentidos. Pensa nela como o "cano" por onde a voz trafega, otimizado pra tempo real, não pra qualidade de estúdio. ### 3. O pipeline de voz do agente Este é o coração. Num loop contínuo, para cada turno de fala do cliente: ``` Áudio do cliente → STT (speech-to-text) transcreve em tempo real, com detecção de fim de fala → LLM entende a intenção, decide a resposta e as ferramentas → TTS (text-to-speech) sintetiza a resposta em voz natural → Áudio de volta ao cliente ``` Cada etapa tem que ser *streaming*. O STT não espera o cliente terminar a frase pra começar a transcrever. O TTS começa a falar assim que as primeiras palavras da resposta saem do LLM. É essa sobreposição que derruba a latência percebida. Alguns pontos que aprendi: - **Detecção de fim de fala (endpointing)** é decisiva. Cortar o cliente cedo demais irrita; esperar demais soa lento. É afinação constante. - **Barge-in** (o cliente interromper a IA no meio da fala) não é opcional. Sem isso, a IA parece um menu de URA burro. - **A voz importa.** Uma voz sintética robótica destrói a confiança. Vozes neurais boas (com fallback entre provedores de TTS) mudam a percepção do cliente completamente. ### 4. O cérebro: LLM com contexto e ferramentas O LLM não conversa no vácuo. Ele recebe: - **O histórico** da ligação (e do cliente, se já ligou antes). - **Os dados do cliente**, puxados do ERP do provedor no início da chamada — plano, status financeiro, situação da conexão. - **As ferramentas** que ele pode acionar durante a conversa. E é nas ferramentas que a mágica de negócio acontece. O agente não *descreve* como resolver — ele resolve: - Consulta o status da conexão (a ONU do cliente está online?) e faz o diagnóstico. - Gera a **segunda via** do boleto e manda o PIX na hora. - Abre uma **ordem de serviço** e agenda a visita técnica. - Verifica pagamentos e desbloqueia o acesso. Isso exige integração direta com o ERP do provedor (no mundo dos ISPs, sistemas como o IXC dominam). Cada ferramenta é uma chamada de API validada, com confirmação nos passos irreversíveis e log de tudo. ### 5. Fallback multi-LLM Já falei disso no [post sobre agentes no WhatsApp](https://www.lucassilva.io/blog/agente-ia-whatsapp-producao), mas em voz é ainda mais crítico: numa ligação ao vivo, você não tem o luxo de "tenta de novo". Se o LLM primário engasga, o sistema cai pro secundário em milissegundos, sem o cliente perceber. Nenhum ponto único de falha na resposta. ## Dois canais, um cérebro O ConectaAI atende por voz **e** por WhatsApp. A tentação é construir dois sistemas. O erro é construir dois sistemas. O canal (telefone ou WhatsApp) é só a camada de entrada/saída — o cérebro, as ferramentas e a lógica de negócio são compartilhados. Isso significa que o mesmo agente que resolve por voz resolve por texto, com a mesma integração com o ERP e as mesmas regras. Um cliente pode começar no WhatsApp e ligar depois, e o contexto acompanha. Arquitetar assim desde o início economiza meses e evita que os dois canais divirjam em comportamento. ## Por que não é "só plugar um chatbot" Se você tirar uma lição daqui, tire esta: **um call center de IA de verdade é 20% modelo de linguagem e 80% engenharia de sistema em tempo real e integração.** O LLM é a parte fácil e comoditizada. O difícil — e onde está o valor — é: - Fazer a telefonia SIP não cair. - Manter latência de voz abaixo do limiar do desconforto. - Integrar de verdade com o ERP legado do provedor. - Garantir resiliência: fila, retry, fallback, observabilidade. - Saber a hora de passar pro humano com o contexto inteiro. Isso é software de infraestrutura, não um wrapper de API. E é exatamente por isso que a maioria dos "call centers de IA" prometidos por aí não entrega: pararam no protótipo de texto e nunca encararam a voz em produção. ## O resultado que importa O provedor não compra "IA". Ele compra: atendimento que não dorme, fila que não estoura no horário de pico, segunda via resolvida às 2h da manhã sem ninguém acordar, e time humano liberado pra resolver o que é realmente complexo. A IA absorve o repetitivo — que é a maioria — e o humano cuida da exceção. Essa é a arquitetura de um call center de IA que funciona. Não porque o modelo é esperto, mas porque o sistema inteiro foi construído pra aguentar o mundo real de um provedor com milhares de clientes ligando. --- *Construo produtos de IA em produção — inclusive atendimento por voz e WhatsApp para provedores. Se você tem um ISP afogado em ligações repetitivas, [vamos conversar](https://www.lucassilva.io).*