por Enric López, C.
Tras dos años de experimentación intensiva en el sector hotelero, el debate sobre la inteligencia artificial ha madurado: ya no se trata de acumular herramientas novedosas, sino de integrar la tecnología de forma real y segura en los procesos diarios de los equipos. Conversamos con Albert Pérez Llanos y Gian Franco Mercado, fundadores de Hospitalidad Emprendedora, profesionales del turismo y la hostelería, apasionados exploradores de diversos aspectos de innovación en nuestro sector para conocer su opinión sobre qué ha funcionado, los errores más frecuentes al escalar pilotos y las claves para que la automatización sirva de asistencia real sin perder el criterio humano. Una visión práctica y rigurosa sobre cómo la IA está transformando la operativa de los hoteles más allá de las demostraciones teóricas.
¿Qué ha cambiado desde aquellos primeros proyectos?
Lo que ha cambiado no es solo la capacidad de la tecnología, sino el tipo de conversación que tenemos con los hoteles. Al principio nos preguntaban qué podía hacer la inteligencia artificial (IA) o cómo conseguir una mejor respuesta. Ahora hablamos de cómo encaja en el trabajo: a qué información accede, quién valida el resultado, qué ocurre cuando duda y cómo se mantiene actualizado.
También hemos pasado del usuario que experimenta en solitario al equipo que quiere reutilizar lo aprendido. Para nosotros, la señal de madurez ya no es tener más herramientas, sino conseguir que un compañero pueda repetir un buen resultado sin depender del «mago del prompt». En hotelería esto es especialmente importante porque hay turnos, excepciones y momentos de presión. La IA empieza a aportar cuando se adapta al proceso real, no cuando obliga al proceso a adaptarse a una demostración.
¿Qué aplicaciones están generando valor de verdad?
Las que generan valor suelen ser menos espectaculares de lo que aparece en una demo, pero están muy cerca del trabajo diario. Por ejemplo: preparar el traspaso entre turnos a partir de incidencias, priorizar mensajes entrantes, revisar una rooming list antes de cargarla, comparar propuestas de proveedores o detectar temas recurrentes en los comentarios de huéspedes.
Todas comparten tres rasgos: ocurren con frecuencia, parten de información identificable y su resultado se puede comprobar antes de actuar. Además, ahorran un trabajo de preparación que casi nunca se ve, pero que consume muchas horas. La IA no sustituye la decisión del profesional; le entrega el terreno más ordenado para que pueda decidir antes y con más contexto.
¿Por qué muchos experimentos siguen sin convertirse en procesos?
Porque una demostración funciona en condiciones ideales y un proceso tiene que funcionar un lunes a primera hora, con prisas, datos incompletos y excepciones. Muchos pilotos dependen de una persona entusiasta que conoce el contexto, corrige los fallos sin registrarlos y guarda las instrucciones en su espacio personal. Cuando esa persona no está, el caso de uso desaparece.
El salto exige trabajo menos vistoso: definir un responsable, ordenar las fuentes, contemplar excepciones, fijar permisos, documentar una alternativa manual y decidir quién mantiene el sistema. Una prueba técnica demuestra que algo es posible; un proceso demuestra que otras personas pueden usarlo de forma repetible y segura.
¿Qué errores se repiten con mayor frecuencia?
Vemos cuatro errores muy repetidos. El primero es empezar por la solución y buscar después el problema. El segundo, automatizar un proceso que ya era confuso: si las fuentes se contradicen o nadie sabe quién aprueba, la IA solo acelera el desorden. El tercero es probar únicamente con ejemplos fáciles y no incluir casos límite, datos faltantes o instrucciones ambiguas.
Y el cuarto es olvidar el mantenimiento. Cambian los procedimientos, las tarifas, las políticas y los equipos, pero el caso de uso queda congelado. Desde el inicio debería existir una persona responsable, una fecha de revisión y un criterio para corregirlo o retirarlo. Saber cerrar un piloto que no aporta suficiente valor también es implementar bien.
¿Qué tareas no deberían delegarse sin supervisión?
Aplicamos una regla sencilla: cuanto más difícil sea revertir una decisión y mayor sea su impacto sobre una persona, más control humano necesita. No delegaríamos sin supervisión comunicaciones de crisis, decisiones sobre seguridad, compensaciones o reembolsos, resolución de reclamaciones sensibles, pagos, ni decisiones que afecten a contratación, evaluación o condiciones laborales.
También pondríamos límites estrictos cuando intervienen datos personales o una recomendación puede discriminar, generar una promesa comercial incorrecta o perjudicar al huésped. Supervisar no significa revisar para siempre cada palabra. En tareas de bajo riesgo se puede evolucionar hacia muestreos, alertas y escalado por excepción. Pero la persona debe seguir definiendo el criterio y asumiendo la responsabilidad del resultado.
¿Cómo medir antes de escalar un caso de uso?
Antes del piloto hay que medir el proceso actual: volumen, tiempo empleado, errores, retrabajo, escalados y, cuando aplique, satisfacción del equipo o del huésped. Después se formula una hipótesis concreta y se fijan umbrales de aceptación. No basta con preguntar si «funciona»; hay que acordar qué mejora esperamos y qué tipo de fallo obligaría a detener la prueba.
Durante el piloto conviene separar el tiempo que tarda la IA del tiempo total, incluida la revisión y las correcciones. También mediríamos adopción real, coste por ejecución e incidencias. Un caso merece escalar cuando es más eficiente, mantiene o mejora la calidad, lo puede utilizar más de una persona y sus fallos están controlados. Si solo brilla con ejemplos preparados, todavía no está listo.
¿Cómo puede empezar un hotel sin perseguir cada nueva herramienta?
Empezaría por una fricción concreta, no por un catálogo de herramientas. Elegiría una tarea frecuente y de bajo riesgo que hoy quite tiempo al equipo, nombraría a una persona responsable y dibujaría el proceso actual, incluidas sus excepciones. Después prepararía datos seguros, una métrica de partida y un piloto corto en modo asistencia: la IA propone y la persona decide.
Durante la prueba registraría correcciones, dudas e incidencias, y compartiría los aprendizajes con un grupo pequeño. Al terminar, solo hay tres decisiones válidas: escalar, corregir o cerrar. Para empezar, no hace falta una arquitectura enorme, sino disciplina. Nuestra fórmula sería: un problema, un responsable, un indicador y una fecha de revisión. Las herramientas pueden cambiar; ese método sigue siendo útil.
¿Qué habilidades prácticas necesitan desarrollar los profesionales?
La primera es aprender a describir bien una tarea: qué entra, qué resultado se espera, qué límites existen y cómo sabremos si está bien. La segunda es seleccionar el contexto y los datos adecuados, sin compartir información innecesaria. La tercera es verificar: contrastar fuentes, revisar cifras y detectar cuándo una respuesta plausible no es una respuesta correcta.
También es clave documentar el aprendizaje para que otra persona pueda repetirlo y reconocer cuándo la herramienta debe detenerse y escalar. Por eso insistimos en formaciones basadas en tareas reales de cada departamento. El valor profesional se desplaza: no consiste solo en producir un primer borrador, sino en plantear mejor el problema, juzgar la salida e integrarla en el trabajo sin perder empatía, criterio ni responsabilidad.
Aprovechamos en invitar a todos los profesionales de la hotelería y turismo a que se inscriban en el curso gratis de IA para hoteles que tendremos los próximos 23 y 24 de septiembre online, y 100% gratuito. Un curso en el que iremos desde la creación de asistentes de IA hasta el trabajo con agentes, y todas las personas que se unan a la sesión en vivo tendrán acceso a las presentaciones formativas y a un certificado de participación:
Miembro del Grupo de Investigación en Alojamientos Turísticos y Restauración del Campus CETT – UB. Profesor en Marketing Digital. Conferenciante. Miembro en Comités Científicos de Congresos. Foundrising, Entrepreneurship & Awards CETT Fundació – CETT. Doctor (PhD) Universidad de Barcelona.
