Konect: transcripción y análisis de audio

Las organizaciones acumulan horas de audio —llamadas, grabaciones, buzones de voz— que nadie puede consultar. Konect convierte ese audio en texto analizable y buscable.

Trabajé en el equipo de Irontec que construyó la plataforma, como arquitecto de software y arquitecto de plataformas: definir la arquitectura orientada a eventos, la búsqueda híbrida y el modelo de despliegue por cliente.

Qué es Konect

Konect nace en el departamento de comunicaciones de Irontec, que opera centralitas de telefonía VoIP para diversos clientes. El objetivo era dotar a un servicio tan tradicional como la telefonía de funciones personalizadas de transcripción y análisis.

Llamadas, grabaciones, emails y documentos entran por el mismo registro y la plataforma hace el resto: transcribir, analizar, indexar y buscar. Cada conversación queda clasificada por categoría y con su análisis de sentimiento. Sobre eso, una API, una aplicación web, una app móvil y un sistema de informes.

No es un servicio de transcripción puntual: es una plataforma pensada para operarse como un SaaS, donde cada cliente trabaja sobre su propia instancia aislada.

Arquitectura de jobs y eventos

Todo gira alrededor de un job: la unidad de trabajo que representa algo a procesar —una llamada, un email, un documento—. Cada job declara su propio pipeline en una recipe:

1. Ingesta por API.
2. Transcripción.
3. Análisis con IA.
4. Indexación para búsqueda.

Un router de pipelines encadena los pasos a través de la cola, y cada cambio de estado emite un evento de dominio —JobCreated, AnalysisCompleted y una veintena más— que mantiene el sistema desacoplado.

La clave para adaptarse a cada cliente sin romper el producto es que los jobs son componibles: todos los clientes comparten el job genérico que ejecuta los análisis principales, y cuando alguien pide algo a medida se programa un job específico que se engancha al mismo protocolo de mensajes sobre Redis. La lógica personalizada queda contenida y aislada, fuera del núcleo —el worker de categorización de Omnia es el ejemplo: escucha los eventos y aplica las categorías propias de ese cliente sin tocar el pipeline común—.

El backend es Python con FastAPI, organizado con DDD y comandos y consultas separados (CQRS). Los trabajos pesados corren en workers Taskiq sobre Redis Streams, escalables de forma selectiva según el tipo de tarea.

Transcripción multiproveedor

Ningún proveedor de voz es el mejor para todo. La plataforma integra cuatro y permite elegir por trabajo:

• Deepgram, con diarización y una docena de idiomas.
• Whisper, servido a través del gateway de modelos.
• Google Cloud Speech.
• Trebe, un proveedor de STT en euskera.

Un gateway de modelos con LiteLLM

Todo el acceso a modelos de IA pasa por un gateway LiteLLM propio. Eso da tres cosas: alias estables para STT, análisis y embeddings —cambiar de modelo no toca el código del producto—, cálculo de costes por modelo y, junto con Langfuse, trazas y observabilidad de los prompts.

Búsqueda vectorial con pgvector

Cada transcripción y análisis se indexa en PostgreSQL con pgvector: embeddings en columnas halfvec con índices HNSW para la búsqueda semántica y tsvector en español para el full-text. Búsqueda híbrida sin salir de la base de datos.

Identidad y acceso: OIDC y RBAC

Konect no gestiona contraseñas: delega la identidad en Keycloak mediante OIDC. Los roles viajan en el token y la plataforma aplica RBAC de verdad —el rol konect-admin abre la administración en API y en interfaz; el resto de usuarios quedan limitados a su trabajo—, además de tokens de sistema para integraciones máquina a máquina.

Plataforma: Kubernetes, GitOps y entornos de preview

La infraestructura se versiona igual que el producto. Un repositorio GitOps propio alimenta un clúster de Kubernetes sincronizado por ArgoCD en modo app-of-apps:

• Devcontainers para que todo el equipo desarrolle sobre el mismo entorno.
• cert-manager con wildcard TLS de Let's Encrypt vía Cloudflare.
• Secretos en Infisical, inyectados con External Secrets Operator.
• Harbor como registro privado de imágenes y charts.
• CI en Jenkins con tests de backend y frontend en paralelo.

El detalle que más me gusta: cada pull request levanta automáticamente un entorno de preview completo que replica el entorno de staging y copia sus datos. Revisar un cambio deja de ser un acto de fe.

RBAC + multi-tenancy

Cada cliente opera su propio despliegue: su overlay de Kustomize, su realm de Keycloak, sus datos aislados y, cuando lo necesita, workers dedicados a su lógica —como el worker de categorización de Omnia. RBAC dentro de la aplicación y multi-tenancy por despliegue: así es como la plataforma se vende y se opera como un SaaS.

Del dato al informe

Los resultados no se quedan en la base de datos. Un servidor MCP expone búsqueda, facetas, agregaciones y gráficos como herramientas; un chat embebido las usa para responder preguntas sobre el contenido; y los informes se descargan como .docx.

Conclusiones

Konect demuestra que el camino grabación → texto → análisis → respuesta cabe en una sola plataforma, operada como un SaaS multi-tenant sin compartir datos entre clientes.

A nivel personal, este proyecto me ha permitido sumergirme de lleno en Kubernetes —no como ejercicio, sino operando la plataforma real—. Y gran parte de las tecnologías que hemos implementado aquí (GitOps, registry propio, gestión de secretos, entornos de preview) han consolidado un conocimiento muy sólido sobre lo que significa construir plataformas como servicio.