IA para festivales de música: qué automatizar y qué no

El problema no es tecnológico, es estacional

En un festival de música el problema nunca es el volumen de trabajo medio: es el pico. Durante once meses el equipo son cinco o seis personas. Durante las tres semanas previas al evento, ese mismo equipo tiene que cerrar producción, coordinar proveedores, resolver acreditaciones y responder miles de mensajes repetidos de asistentes. No se puede contratar a tres personas para tres semanas al año, y por eso la automatización en este sector no compite con la plantilla: compite con las horas que la plantilla no tiene.

La pregunta útil, entonces, no es qué se puede automatizar en un festival. Es qué parte del pico desaparece si lo repetitivo se resuelve antes de que llegue.

Eso cambia el criterio de decisión. En una empresa con carga estable, automatizar un proceso se justifica por el ahorro anual. En un festival se justifica por otra cosa: por lo que evita en tres semanas concretas, y por lo que permite que el equipo haga en su lugar. Un informe de horas ahorradas al año se queda corto para medirlo. Lo que hay que mirar es cuántas de esas horas caen dentro del pico.

También cambia el calendario. Un agente que se monta en junio para un festival de julio llega tarde: no da tiempo a alimentarlo con información fiable ni a probarlo con casos reales. Estas cosas se montan en invierno, cuando el equipo todavía puede pensar.

Atención al asistente: las cinco preguntas de siempre

Es el caso más maduro del sector y el que antes devuelve horas. Las preguntas se repiten con una consistencia casi cómica:

• ¿Hay parking? ¿Dónde?
• ¿Se puede entrar con comida o bebida?
• ¿A qué hora toca tal artista?
• ¿Es accesible? ¿Hay zona adaptada?
• ¿Qué está prohibido meter en el recinto?
• No me ha llegado el correo con la entrada

Todas menos la última se responden con información que ya existe y que además es pública: el cartel, los horarios, las condiciones de acceso, el plano del recinto. El problema no es que la información no esté, es que está repartida entre la web, un PDF, un carrusel de Instagram y la cabeza de tres personas.

Un agente conectado a esas fuentes responde en segundos, a cualquier hora y en varios idiomas. Pero lo determinante no es lo que responde: es lo que no debe responder. Un agente que improvisa sobre devoluciones, sobre una incidencia médica o sobre la posición de la organización ante una cancelación no ahorra trabajo, lo crea. Los límites se definen antes de conectar nada, y todo lo que caiga fuera se escala a una persona con el contexto ya recogido.

El asistente también es marca

Este es el punto que más se subestima y en este sector es el que más pesa.

Un festival vende una experiencia con un tono muy concreto. Si el asistente responde correcto pero suena a formulario de banco, rompe el tono de todo lo demás: del cartel, del copy de redes, de la señalética. Y el asistente es, muchas veces, el primer contacto directo que tiene una persona con la organización.

Eso implica tres decisiones que no son técnicas:

• Nombre propio, no «asistente virtual». Un personaje se recuerda, se comparte y admite que se le hable de tú. Una etiqueta genérica no.
• Voz escrita antes de conectar el modelo. Cómo saluda, si tutea, qué hace cuando no sabe algo. Decir «esto no lo sé, te paso con el equipo» puede sonar a fallo o a atención honesta, y la diferencia está en cómo esté escrito.
• Dónde vive. Obligar a volver a la web para preguntar algo es fricción. El asistente tiene que estar donde ya está la conversación: enlace en la biografía, stories, WhatsApp. Cuanto menos haya que buscarlo, más descarga al equipo.

Conectar el agente al ticketing: el salto que casi nadie da

Toda la información pública —cartel, horarios, accesos, normas— es la parte fácil. El mensaje verdaderamente caro es el que empieza por «mi entrada».

No me llegó el correo. Quiero cambiar el nombre del titular. Compré dos y solo me aparece una. ¿Esta que me han reenviado es válida? Ese bloque de mensajes no se resuelve con información pública, porque la respuesta depende de un dato concreto de una persona concreta. Y es exactamente el que más tensa al equipo, porque llega con urgencia y a veces con enfado.

Para que un agente lo resuelva tiene que poder consultar el sistema de venta, comprobar el estado real de una entrada y, según el caso, ejecutar una acción acotada o escalar con todo el contexto ya recogido. Ahí es donde deja de ser un chatbot de preguntas frecuentes y pasa a ser un agente de verdad: algo conectado a vuestros datos, con permisos definidos y con un registro de lo que hace.

Es también donde aparece el requisito incómodo: hace falta que el ticketing tenga API y que alguien se responsabilice de los permisos. Si esa parte no está resuelta, el agente se queda en la mitad informativa. Que ya es mucho, pero conviene saberlo desde el principio en vez de descubrirlo a mitad del proyecto.

Acreditaciones: el caso menos vistoso y el más rentable

Prensa, artistas, proveedores, invitados, personal de barras. Cada colectivo con su formulario, su hoja de cálculo, su cadena de correos y su lista que alguien cruza a mano el día antes.

No tiene glamour y por eso casi nunca sale en las conversaciones sobre innovación, pero suele ser el proceso que más horas devuelve por euro invertido. Y buena parte no necesita ni inteligencia artificial: necesita conectar herramientas que ya tenéis para que un formulario alimente una base de datos, esa base genere las acreditaciones y el estado se actualice solo.

Es el ejemplo perfecto del orden que defendemos: primero ordena, luego automatiza, y solo entonces IA. Meter un modelo de lenguaje encima de un proceso de acreditaciones que nadie ha ordenado no lo arregla, lo acelera.

Riders y avanzadas: leer para que otro no lea

Aquí sí aporta la IA algo que una automatización clásica no puede.

Cada artista manda su rider técnico y su hoja de hospitality. Documentos de veinte, treinta o cuarenta páginas, cada uno con su formato, redactados por gente distinta. Alguien del equipo de producción los lee y transcribe a mano lo que importa: necesidades de sonido, backline, camerinos, catering, horarios de carga.

Extraer eso a una ficha estructurada y comparable es un trabajo de interpretación de lenguaje, y es de las pocas cosas en un festival donde un modelo aporta valor claro. Con una condición: la ficha extraída es un borrador que una persona valida, no una verdad. En producción un error de transcripción no es un error de datos, es un artista sin monitores a las nueve de la noche.

Dónde no la metería todavía

• La programación del cartel. Es criterio artístico, relaciones y negociación. No es un problema de datos.
• Las decisiones de booking. Lo mismo, con dinero de por medio.
• La comunicación durante una crisis. Una cancelación por meteorología, una evacuación, un incidente. Ahí se responde con una persona con nombre, no con un agente.
• La moderación de comunidad sin supervisión. El coste de un mensaje automático desafortunado en el perfil de un festival es muy superior al ahorro.

Por dónde empezar

Si vuestro festival es en verano, esto se decide en otoño o invierno. No por vendernos antes, sino porque un agente necesita información ordenada, y ordenar información en junio con la producción encima no sale bien.

El primer paso no es elegir herramienta. Es mirar qué preguntas os llegaron de verdad el año pasado, cuántas se repetían y cuánto tiempo se fue en contestarlas. Con eso sobre la mesa se decide qué merece la pena y en qué orden — y a veces la conclusión es que primero hay que ordenar, y de IA todavía nada.

Cuéntanos vuestro caso y lo miramos. Si la conclusión es que aún no os toca, también os lo decimos.