Arquitectura Técnica de un Sistema Voice AI Escalable

Construir un sistema de voice AI escalable que pueda procesar miles de llamadas de cobranza simultáneas en múltiples países de Latinoamérica es un desafío de ingeniería de alto nivel. No se trata solo de conectar una API de reconocimiento de voz con un chatbot: requiere arquitectura distribuida, orquestación compleja, baja latencia, alta disponibilidad y cumplimiento regulatorio estricto.

En este artículo técnico desglosamos la arquitectura completa de un sistema voice AI de producción, desde la capa de telefonía hasta los modelos de machine learning, con ejemplos de stack tecnológico, patrones de diseño y consideraciones de escalabilidad basados en sistemas reales que procesan millones de minutos mensuales como Kleva.

Requisitos de un sistema voice AI para cobranza a escala

Antes de diseñar la arquitectura, definamos los requisitos no funcionales críticos:

Escalabilidad

• Llamadas concurrentes: debe soportar 1,000-10,000+ llamadas simultáneas con degradación graceful
• Elasticidad: escalar automáticamente en horas pico (mañanas) y reducir capacidad en horas valle
• Multi-región: despliegue en múltiples regiones de LATAM para cumplir requisitos de latencia y soberanía de datos

Latencia

• End-to-end latency:

End-to-end latency:

• ASR latency:

ASR latency:

• NLU + Dialog latency:

NLU + Dialog latency:

• TTS latency:

TTS latency:

Disponibilidad y resiliencia

• Uptime SLA: 99.9% de disponibilidad (máximo 43 minutos de downtime mensual)
• Failover automático: si una región falla, las llamadas se redirigen a otra
• Circuit breakers: prevenir cascading failures cuando un servicio dependiente falla

Compliance y regulación

• Grabación de llamadas: almacenamiento encriptado con retención configurable por país
• Horarios de contacto: respetar regulaciones de cada país sobre cuándo se puede llamar
• Do Not Call lists: integración con registros nacionales
• GDPR/LGPD: cumplimiento con regulaciones de privacidad de datos

Arquitectura de alto nivel: componentes principales

Un sistema voice AI escalable se compone de múltiples capas independientes pero orquestadas:

Capa 1: Telefonía y gestión de sesiones

Esta capa maneja la conexión telefónica física y el routing de llamadas:

• SIP Trunks: conectividad a redes telefónicas públicas (PSTN) en cada país
• Media Server: maneja streams de audio RTP, codecs, DTMF, grabación
• Session Border Controller (SBC): seguridad, NAT traversal, transcoding
• Load Balancer de telefonía: distribuye llamadas entrantes entre múltiples media servers

Stack tecnológico típico: Twilio/Vonage para SIP trunking, FreeSWITCH o Asterisk para media server, Kamailio como SBC.

Capa 2: Procesamiento de voz (ASR y TTS)

Conversión bidireccional entre audio y texto:

• ASR (Automatic Speech Recognition): transcribe audio del usuario a texto en tiempo real
• TTS (Text-to-Speech): sintetiza las respuestas del agente IA en audio natural
• VAD (Voice Activity Detection): detecta cuándo el usuario empieza y termina de hablar
• Barge-in detection: permite que el usuario interrumpa al agente IA

Stack tecnológico: Google Cloud Speech-to-Text, AWS Transcribe, Whisper (OpenAI), o modelos custom fine-tuned. Para TTS: Google Wavenet, Amazon Polly, Azure Neural TTS.

Capa 3: Inteligencia conversacional (NLU + Dialog)

El cerebro del agente IA que entiende intenciones y decide respuestas:

• NLU (Natural Language Understanding): extrae intenciones, entidades y sentimientos del texto
• Dialog Manager: mantiene el estado de la conversación y decide la siguiente acción
• Business Rules Engine: aplica reglas de negocio (ofertas, descuentos, escalaciones)
• Context Store: almacena historial de conversación y contexto del usuario

Stack tecnológico: Rasa, Dialogflow, Lex, o motores custom con LLMs (GPT, Claude) para NLU. Redis/DynamoDB para context store.

Capa 4: Integración y datos

Conecta el voice AI con sistemas empresariales:

• CRM Connector: consulta y actualiza información del deudor en tiempo real
• Payment Gateway Integration: procesa pagos durante la llamada
• Scoring Service: calcula probabilidad de pago y priorización
• Campaign Manager: gestiona listas de llamadas, horarios, reintentos

Capa 5: Orquestación y observabilidad

Coordina todos los componentes y monitorea el sistema:

• Call Orchestrator: coordina el flujo completo de cada llamada entre todos los servicios
• Metrics Collector: recopila métricas en tiempo real (latencia, tasa de éxito, errores)
• Logging y Auditoría: logs estructurados de cada interacción para compliance
• Alerting: notificaciones automáticas cuando métricas críticas se degradan

Arquitectura detallada: flujo de una llamada

Veamos el flujo técnico completo de una llamada de cobranza desde inicio hasta fin:

1. Iniciación de llamada (0-2 segundos)

1. Campaign Manager selecciona el siguiente deudor a contactar basándose en scoring predictivo
2. Consulta Do Not Call registry y valida horario permitido para el país/región
3. Envía request al Load Balancer de telefonía con número destino y campaña
4. Load Balancer selecciona un Media Server con capacidad disponible
5. Media Server inicia llamada saliente a través de SIP Trunk del país correspondiente
6. Empieza grabación encriptada de la llamada para compliance

2. Detección de contestación (2-30 segundos)

1. AMD (Answering Machine Detection) analiza los primeros 2-4 segundos de audio
2. Clasifica si contestó: humano, buzón de voz, tono de ocupado, o no contesta
3. Si es buzón: deja mensaje pregrabado y termina llamada
4. Si es humano: activa VAD y espera que el usuario diga "Hola" o similar
5. Call Orchestrator carga contexto del deudor desde CRM y scoring

3. Conversación activa (loop continuo)

Por cada turno de conversación:

Usuario habla:

1. VAD detecta que el usuario empezó a hablar, pausa la salida del TTS (barge-in)
2. Media Server bufferiza el audio (típicamente frames de 20ms)
3. Audio se envía via WebSocket/gRPC al servicio de ASR
4. ASR transcribe en tiempo real (streaming) con resultados parciales cada 200-500ms
5. VAD detecta que el usuario terminó de hablar (pausa de 500-800ms)
6. ASR envía transcripción final al NLU Service

Agente IA procesa y responde:

1. NLU extrae intención, entidades y sentimiento (latencia: 100-200ms)
2. Dialog Manager decide la siguiente acción basándose en:
   - Intención del usuario
   - Estado actual de la conversación
   - Historial de interacciones previas
   - Business rules configuradas
3. Si se requiere información externa: consulta CRM/scoring en paralelo (150-300ms)
4. NLG (Natural Language Generation) genera el texto de respuesta personalizado
5. Texto se envía al TTS Service para síntesis (latencia: 200-400ms)
6. Audio sintetizado se streamea de vuelta al Media Server
7. Media Server reproduce el audio al usuario via RTP
8. Actualiza Context Store con el nuevo turno de conversación

Este loop se repite hasta que:

• Se logra el objetivo (promesa de pago, pago inmediato, acuerdo de reestructuración)
• El usuario pide hablar con un humano → transferencia a agente
• El sistema detecta frustración alta → escalación automática
• Se alcanza tiempo máximo de llamada (típicamente 5-8 minutos)

4. Finalización y post-procesamiento

1. Dialog Manager ejecuta acción final (registrar promesa, procesar pago, agendar callback)
2. Actualiza estado en CRM con resultado de la llamada
3. Finaliza grabación y la almacena encriptada en storage compliance (S3, GCS)
4. Analytics Pipeline procesa la conversación para:
   - Métricas de performance (duración, resultado, sentimiento)
   - Datos de reentrenamiento de modelos de ML
   - Reportes de cumplimiento regulatorio
5. Libera recursos del Media Server para la siguiente llamada

Diseño para escalabilidad: patrones arquitectónicos

Microservicios stateless

Todos los servicios de procesamiento (ASR, NLU, Dialog, TTS) son stateless: no mantienen estado entre requests. Esto permite:

• Escalar horizontalmente agregando más instancias
• Reemplazar instancias sin pérdida de datos
• Balanceo de carga sin session affinity

El estado de conversación se externaliza en Redis Cluster o DynamoDB con latencia de lectura

Event-driven architecture

Los componentes se comunican via eventos asíncronos:

• Message Queue (Kafka, RabbitMQ, SQS) para eventos de llamadas
• Permite retry automático de operaciones fallidas
• Desacopla productores de consumidores
• Facilita auditoría completa del flujo

Circuit breaker pattern

Si un servicio downstream (por ejemplo, CRM externo) empieza a fallar:

• Circuit breaker detecta tasa de error alta
• Abre el circuito: deja de enviar requests al servicio fallido
• Usa fallback: cache de datos o respuesta degradada
• Intenta periódicamente reconectar (half-open state)
• Previene cascading failures que tirarían todo el sistema

Auto-scaling basado en métricas

El sistema escala automáticamente basándose en:

• CPU/Memoria: métricas estándar de infraestructura
• Queue depth: si hay llamadas esperando procesamiento
• Latencia p95: si el percentil 95 de latencia supera threshold
• Llamadas concurrentes: predicción basada en patrones históricos

ComponenteTrigger de ScalingMin InstancesMax Instances

Media ServerLlamadas concurrentes > 80%10200

ASR ServiceQueue depth > 100 o latency p95 > 500ms20500

NLU + DialogCPU > 70% o latency p95 > 300ms15300

TTS ServiceQueue depth > 5010200

Stack tecnológico recomendado por capa

Infraestructura y orquestación

• Cloud Provider: AWS, GCP o Azure (multi-región en LATAM: São Paulo, Virginia, Oregon)
• Container Orchestration: Kubernetes (GKE, EKS, AKS) para gestión de microservicios
• Service Mesh: Istio o Linkerd para traffic management, observability, security
• Load Balancing: AWS ALB/NLB, GCP Load Balancer con health checks inteligentes

Procesamiento de voz

• ASR: Google Cloud Speech-to-Text con modelos fine-tuned para dialectos LATAM, o Whisper large v3
• TTS: Google Cloud Text-to-Speech (WaveNet), Amazon Polly (Neural), o ElevenLabs para voces ultra-naturales
• VAD: Silero VAD o WebRTC VAD para detección de actividad de voz

NLU y diálogo

• NLU: Rasa NLU custom fine-tuned, o LLMs (GPT-4, Claude) con prompts especializados
• Dialog Management: Rasa Core, o state machine custom con reglas de negocio complejas
• Context Store: Redis Cluster (ElastiCache, Cloud Memorystore) para baja latencia

Datos y almacenamiento

• Transactional DB: PostgreSQL (RDS, Cloud SQL) para datos de campaña y resultados
• Time-series DB: InfluxDB o TimescaleDB para métricas de llamadas
• Object Storage: S3, GCS para grabaciones encriptadas (con lifecycle policies)
• Data Warehouse: BigQuery, Redshift, Snowflake para analytics

Observabilidad

• Logging: ELK Stack (Elasticsearch, Logstash, Kibana) o Splunk
• Metrics: Prometheus + Grafana o Datadog
• Tracing: Jaeger o AWS X-Ray para distributed tracing
• Alerting: PagerDuty o Opsgenie integrado con Prometheus Alertmanager

Consideraciones de costo y optimización

Operar un sistema voice AI a escala tiene costos significativos:

Costos de telefonía

• Llamadas salientes: $0.01-$0.05 USD por minuto dependiendo del país
• Números telefónicos: $1-$5 USD/mes por número (necesitas cientos para paralelizar)
• SIP trunking: $0.005-$0.02 USD por minuto

Para 1 millón de minutos mensuales: $10,000-$50,000 USD solo en telefonía.

Costos de IA/ML

• ASR: $0.006-$0.024 USD por minuto (Google, AWS)
• TTS: $0.004-$0.016 USD por millón de caracteres
• LLM API calls: $0.001-$0.03 USD por request para GPT-4 level models

Para 1 millón de minutos: $6,000-$24,000 USD en servicios de IA.

Costos de infraestructura

• Compute: Kubernetes cluster con 50-200 nodes: $15,000-$60,000 USD/mes
• Storage: almacenamiento de grabaciones: $0.023/GB/mes (puede crecer rápido)
• Network: egress de audio/datos: $0.08-$0.12 per GB

Optimizaciones para reducir costos

• Batch TTS: pre-sintetizar frases comunes y cachearlas
• Compression: usar codecs eficientes (Opus) para reducir bandwidth
• Spot instances: usar compute de bajo costo para cargas no críticas
• Lifecycle policies: mover grabaciones antiguas a cold storage (Glacier, Coldline)
• Regional optimization: deployar servicios de IA en regiones más baratas cuando sea posible

Build vs Buy: el caso de plataformas especializadas

Construir y operar esta arquitectura completa requiere:

• Equipo de 20-30 ingenieros: DevOps, Backend, ML, Telefonía ($300k-$600k USD/mes en salarios LATAM)
• 12-18 meses de desarrollo hasta tener un sistema de producción
• $50k-$150k USD/mes en infraestructura para volúmenes medios
• Costo total año 1: $4M-$8M USD

Plataformas especializadas como Kleva ofrecen toda esta arquitectura como SaaS:

• Implementación en 2-4 semanas vs 12-18 meses
• Costo mensual: $10k-$30k USD vs $350k-$750k de build propio
• Opera en 7 países de LATAM sin necesidad de infraestructura por país
• Procesa 900,000+ minutos mensuales con 94% de resolución en primera llamada
• 70% de reducción de costos comparado con build interno
• 0 violaciones regulatorias gracias a compliance incorporado

Para el 95% de empresas, el ROI de comprar una plataforma especializada es 10-20x mejor que construir internamente.

Conclusión: la complejidad justifica la especialización

La arquitectura técnica de un sistema voice AI escalable es significativamente más compleja que la mayoría de sistemas empresariales. Requiere expertise profundo en telefonía, machine learning, sistemas distribuidos, procesamiento en tiempo real y cumplimiento regulatorio multi-país.

Para empresas cuyo core business no es la tecnología de voice AI, intentar construir esta arquitectura internamente representa un riesgo enorme de tiempo, costo y ejecución. Las plataformas especializadas han invertido años y millones en resolver estos problemas de forma productizable.

Kleva es un ejemplo de plataforma que maneja toda esta complejidad, permitiendo que empresas de cobranza, fintechs y bancos se enfoquen en su negocio mientras confían la infraestructura técnica a especialistas que procesan volúmenes que ninguna empresa individual podría igualar.