Bachata Vibes Music es un sello discográfico en el que la voz, la instrumentación, las portadas y el video se generan íntegramente con modelos de IA (Suno para el audio, un servicio local de difusión estable para los fondos, Claude para las letras y la orquestación), publicado en YouTube, Facebook, Instagram y TikTok sin intervención humana directa en el ciclo diario. El sistema funciona sobre una Raspberry Pi 5 como orquestador 24/7, con un puente asíncrono hacia una máquina con GPU dedicada al renderizado. Este artículo describe la arquitectura, las estrategias de gestión de fallos que hicieron el sistema fiable en producción, y los resultados operativos recogidos en unos seis meses de actividad continuada.
1. Introducción
La pregunta de partida no era "¿puede la IA generar música pasable?", cuya respuesta ya está asumida. Era: ¿puede un sistema gestionar por sí solo todo el ciclo — producción, edición visual, publicación, gestión de errores — el tiempo suficiente para sostener meses de actividad sin supervisión constante? Bachata Vibes Music es la respuesta práctica a esa pregunta: un canal musical (bachata, salsa, merengue, cha cha cha) activo desde marzo de 2026, con más de 870 videos publicados en el momento de escribir esto, gestionado por una única Raspberry Pi 5 que orquesta cada fase sin DJ humano.
La restricción del proyecto es la opuesta a la de Guerda Music, otro proyecto del mismo autor: allí la voz debe seguir siendo humana y real, aquí es la IA la que la genera por completo. Los dos proyectos comparten infraestructura (misma Raspberry Pi, misma máquina de renderizado) pero responden a una restricción editorial opuesta — un caso útil para aislar qué cambia realmente cuando se elimina el último elemento humano de la cadena de producción.
2. Arquitectura del sistema
El sistema está distribuido en tres máquinas con roles intencionadamente desiguales, conectadas por una cola asíncrona en Google Drive en lugar de una conexión directa siempre activa:
| Componente | Rol |
|---|---|
| Raspberry Pi 5 | Orquestador 24/7: un cron cada hora decide la categoría del día, produce o publica, publica en YouTube/Facebook/Instagram, gestiona la cola |
| PC Windows + GPU | Renderizado de video pesado (FFmpeg/NVENC) — encendido solo cuando está disponible, no es un requisito de disponibilidad del resto del sistema |
| Suno (API) | Generación completa del audio: voz, arreglo, mezcla |
| Modelo de difusión local | Genera los fondos de las portadas, luego marcados con overlay Pillow |
| Claude (Haiku) | Generación de letras y metadatos SEO, coste marginal por pista |
La decisión más contraintuitiva fue precisamente la última: usar Google Drive como puente entre la Pi y el PC en lugar de una conexión directa (SSH/API). Un PC de escritorio no está pensado para permanecer encendido 24/7 con la misma fiabilidad que una Raspberry Pi de bajísimo consumo. En lugar de hacer que todo el sistema dependa de la disponibilidad del PC, la Pi escribe una solicitud de renderizado en una carpeta de Drive y sigue con lo demás; un worker en el PC la recoge cuando la máquina está encendida, y escribe el resultado en otra carpeta que la Pi recupera en el siguiente ciclo. El desacoplamiento no elimina el problema — si el PC permanece apagado varios días la cola crece — pero convierte un posible bloqueo total de la pipeline en un retraso local y recuperable.
3. La pipeline de producción, paso a paso
Cada hora, el orquestador en la Pi evalúa si producir contenido nuevo o consumir el que ya está en cola, según el estado real del sistema (cuota de YouTube restante, cola de renderizado, contenido ya publicado hoy). Cuando produce:
- Elección del género — un módulo de puntuación lee las curvas de retención reales del canal (cuánto tiempo se quedan los espectadores en bachata sensual frente a merengue frente a cha cha cha en la última semana) y elige la categoría del día en consecuencia, no por rotación fija
- Letras — Claude genera letras coherentes con un tema, con un conjunto estático como respaldo si la API no responde
- Audio — la solicitud va a Suno vía API REST (con un camino vía automatización de navegador como respaldo cuando la API no está disponible); el título que se pasa en esta fase es deliberadamente genérico (categoría + marca temporal), no el título final — un detalle técnico menor que una vez causó un error real, corregido después (ver sección 4)
- Portada — un fondo generado o extraído de un conjunto existente, luego personalizado con texto, logo y una paleta de color específica del subgénero
- Video — solicitud de renderizado enviada al puente de Drive; el PC la procesa con FFmpeg/NVENC cuando está disponible
- Publicación — subida a YouTube vía Data API con gestión de cuota, generación automática de carpetas de publicación para Facebook/Instagram/TikTok con horarios calculados según las franjas óptimas por plataforma
4. Gestionar los fallos sin nadie de guardia
La parte más interesante de un sistema que debe funcionar meses sin supervisión no es la generación en sí — es qué pasa cuando algo se rompe, y es estadísticamente seguro que tarde o temprano algo se romperá: un proveedor externo cambia de comportamiento, una API introduce un límite de frecuencia no documentado, un timeout demasiado optimista hace fallar un paso por lo demás inofensivo. Algunos patrones resultaron necesarios en producción, no previstos de antemano:
Degradar, no bloquear. Cada componente externo (renderizado en PC, generación de audio, subida) tiene un camino de respaldo o un timeout que permite que el resto de la pipeline continúe. Si el renderizado no está disponible, la solicitud queda en cola en lugar de bloquear el siguiente ciclo horario.
Archivos centinela en lugar de flags en el código. Para pausar temporalmente un único componente (por ejemplo la publicación en TikTok durante un periodo de shadowban algorítmico) basta con que exista un archivo en el sistema de archivos, comprobado en cada ejecución — sin cambios de código, sin despliegue, reversible borrando el archivo.
Verificar siempre el estado real, nunca la respuesta declarada. El caso más instructivo: un proveedor de alojamiento de imágenes respondía siempre Content-Length: 0 a una solicitud HEAD de verificación, incluso cuando una solicitud GET real sobre la misma URL servía el archivo completo — la pipeline daba por bloqueada cada publicación durante un día entero antes de que el código de verificación se corrigiera para usar un GET en streaming en lugar de fiarse de la cabecera. La lección general: cuando un sistema externo está fuera de tu control, verificar el comportamiento observado es más fiable que fiarse del contrato declarado por la API.
Concurrencia entre ejecuciones. Un cron que se ejecuta cada 30 minutos puede solaparse con una ejecución anterior aún en curso (por ejemplo tras una ralentización de red) — sin un bloqueo explícito con timeout, esto produce publicaciones duplicadas. Un archivo de bloqueo con caducidad (liberado automáticamente si un proceso muere sin limpiarlo) eliminó toda esa clase de error.
Un sistema autónomo no es el que nunca se rompe — es aquel en el que un fallo local se queda local, se autoinforma, y no necesita a una persona despierta a las 3 de la madrugada para contenerlo.
5. Resultados operativos
Algunos números concretos recogidos en los primeros seis meses de actividad continuada (marzo–septiembre 2026):
- Más de 870 videos publicados en YouTube, con generación, renderizado y publicación totalmente automatizados en el ciclo ordinario
- Cuatro géneros musicales producidos de forma autónoma (bachata sensual, salsa, merengue, cha cha cha), con la selección del género del día guiada por datos reales de retención, no por un calendario fijo
- Publicación multiplataforma (YouTube, Facebook, Instagram, TikTok) desde una única cola de contenido listo, con horarios por plataforma calculados según las franjas históricamente más eficaces
- Coste marginal por pista del orden de pocos céntimos de dólar para el componente textual (Claude Haiku), frente a un coste de generación de audio fijo por suscripción a Suno independiente del volumen
6. Límites, y qué no resuelve la pipeline por sí sola
Honestidad intelectual antes que marketing: no todo se puede automatizar con seguridad, y no todo lo automatizable debería automatizarse sin control. Algunos ejemplos concretos:
- Detectar un shadowban algorítmico (TikTok, en particular) sigue siendo un problema de monitorización estadística continua — el sistema detecta el patrón (una caída de visualizaciones en las subidas nuevas independientemente de la calidad del contenido) pero la decisión sobre cómo reaccionar (reducir el ritmo, cambiar la estrategia de hashtags) sigue siendo una decisión editorial, no delegada a la automatización
- Las plataformas con políticas anti-bot explícitas (LinkedIn, para proyectos conectados) imponen un límite que no es técnico sino de riesgo de cuenta — ahí la automatización se detiene deliberadamente un paso antes de publicar
- La calidad editorial agregada — un sistema que produce a diario tiende a converger en patrones seguros (mismos temas, mismas estructuras textuales) si no se le empuja periódicamente hacia variaciones nuevas: la diversidad creativa requiere una intervención deliberada, no surge sola de la repetición automática
Conclusión
El resultado no es "la IA sustituye a un sello discográfico" en sentido absoluto — es que un sistema bien diseñado para la degradación controlada, más que para la ausencia de fallos, puede sostener meses de producción y publicación continuada con una carga de supervisión humana mucho menor de lo que la intuición sugeriría. La parte técnicamente interesante no fue enseñar a un modelo a generar una canción de bachata verosímil — fue construir la infraestructura alrededor que permite que esa generación ocurra de forma fiable, día tras día, sin que un ser humano pulse play.