La arquitectura invisible: por qué tu hotel no tiene un problema de IA, tiene un problema de organigrama

Este artículo forma parte de una serie de seis análisis sobre inteligencia artificial, marketing hotelero, revenue management y distribución, coordinada por Oliver Espinosa y Laura Laiz (Entrega 5)

"Cuando un hotel tiene un Business Intelligence bien montado, una plataforma que consolida datos y los presenta en paneles, suele dar por resuelto el problema del dato.

Y en parte lo está: ese hotel ve con precisión su ADR, su pickup, su ocupación por segmento, lo que ya lo coloca por delante de la mayoría. Pero ese BI casi nunca recoge todo el dato del hotel: suele ser, sobre todo, lo que llega del PMS y del RMS, el núcleo comercial clásico.

Marketing tiene su plataforma de analítica web. UX usa una herramienta que graba sesiones y mapea el recorrido del usuario. Distribución trabaja con su channel manager. Fidelización tiene su CRM de loyalty. Reputación gestiona reseñas en su propia herramienta. Reservas, sea online o por teléfono, tiene su propio sistema.

Cada departamento tiene su propio sistema, que resuelve bien lo suyo, pero rara vez ha sido pensado para hablar con el resto.

El problema no es tecnológico, es organizativo

Esto tiene una explicación que rara vez se aplica a un hotel, aunque no es nueva: es un patrón descrito en ingeniería de sistemas desde 1967, cuando Melvin Conway formuló lo que hoy se conoce como su ley.

Toda organización que diseña un sistema termina construyendo un sistema que copia su propia estructura de comunicación.

Si cada departamento apenas comparte un número al mes con los demás, los sistemas que cada uno compra y configura reproducirán exactamente esa distancia.

No es que la tecnología falle; es que cada área contrata, con toda lógica, la mejor herramienta para su propio problema, sin que ninguna haya sido pensada para hablarle a las demás.

Y cada vez más, esos mismos sistemas llevan su propia capa de IA incorporada: el motor de pricing del RMS, el asistente de campañas de la plataforma de medios, el chatbot del CRM...

Cada uno aprende, pero solo de los datos de su propio silo.

La fragmentación no desaparece con la llegada de la IA: se multiplica, porque ahora hay varias inteligencias trabajando en paralelo sin verse entre sí

Gobernar el dato no da titulares

Si la fragmentación es tan visible, ¿por qué casi ningún hotel la corrige?

La barrera principal es de prioridad, no de precio ni de dificultad técnica: gobernar el dato es, en la práctica, un centro de coste, y así es como se percibe en cualquier dirección.

No genera ingresos directos ni medibles en el mismo trimestre, aunque sí genera valor, uno que no encaja en ninguna casilla de una hoja de resultados.

Cerrar el trimestre con el RevPAR más alto de los últimos tres años, presentar la campaña que dispara la conversión, anunciar que se ha reajustado la cuota a la OTA líder o renegociado la comisión con un mayorista: eso es lo que se cuenta en dirección, lo que sube a un titular de prensa del sector, lo que construye una carrera.

Decidir qué dato capturar hoy para un uso que aún no existe, y obligar a media docena de proveedores a compartir una misma definición, con toda la complejidad técnica y fricción organizativa que implica, no genera una cifra atractiva que enseñar.

Es coste, sin ingreso claramente atribuible que lo compense en el mismo trimestre.

Gobernar no significa controlar

Y conviene ser cuidadoso con la palabra "gobernar", porque tiene una lectura incómoda: si un único responsable decide qué es el dato correcto, ¿no se concentra ahí un riesgo desproporcionado y se apaga la iniciativa de cada departamento?

En parte sí, si el rol se define mal.

Pero lo que hay que gobernar no son las decisiones de marketing ni las de revenue —cada uno sigue siendo dueño de su estrategia, su campaña y su tarifa— sino dos piezas acotadas y compartidas: qué se captura hoy y cómo se pone a disposición, de forma unificada, de quien lo necesite mañana, sea una persona o un sistema de inteligencia artificial.

Es la diferencia entre un árbitro que vela por una única regla y un entrenador que decide cada jugada.

Lo primero es gobernable sin asfixiar a nadie; lo segundo sí es un riesgo.

Un dashboard no alimenta una inteligencia artificial

Con esto claro, vale la pena bajar al terreno técnico, porque aquí es donde el problema suele malinterpretarse.

Aunque una organización se propusiera unificar todos sus sistemas en un cuadro de mando único, seguiría chocando con un límite que no tiene que ver con la frecuencia de actualización, sino con la naturaleza del dato.

Un panel puede refrescarse al minuto y el problema seguir intacto.

La diferencia no está en cuándo se actualiza la cifra, sino en para quién está pensada.

Un panel de visualización existe para que una persona lo abra, lo lea y decida.

La IA que decide si ofrecer un upsell o un upgrade gratuito en el check-in no abre paneles.

Necesita saber, en el momento de decidir, si esa reserva ya viene con margen ajustado, y ese dato solo sirve si le llega como fuente fiable, no como una cifra suelta que alguien revisa a final de mes.

El dato que no se guarda hoy puede perderse para siempre

Y no basta con que el dato esté disponible en el momento en el que decide un sistema de inteligencia artificial; alguien tiene que haber decidido antes qué merece capturarse pensando en un uso futuro.

Si esa decisión no se toma con criterio, el dato de hoy no espera pacientemente a que alguien lo necesite: se sobrescribe, se agrega de una forma que ya no se puede desagregar o no ha sido guardado con el detalle suficiente.

Conectar lo que ya existe cuando por fin hace falta es la parte fácil. Decidir hoy qué merece guardarse para un uso todavía sin definir es la que de verdad cuesta.

La IA necesita unos cimientos que todavía no existen

Conviene ser realista sobre lo que la inteligencia artificial puede y no puede hacer aquí.

Un modelo puede cruzar datos, detectar correlaciones y ajustar modificaciones de precio o señales de puja en tiempo real, ya sea un motor de pricing dinámico que reajusta la tarifa por franja horaria o un asistente de reservas que decide si ofrecer un upsell según el margen real de esa reserva.

Pero necesita que esos datos existan como fuente accesible en el momento de decidir y que exista histórico suficiente para aprender de él.

Un hotel que despliega uno de estos sistemas sin esa base común está construyendo sobre un cimiento que todavía no existe, por mucha IA que lleve encima.

Integrar ya no es el gran problema

La tecnología que conecta estos sistemas se llama iPaaS (Integration Platform as a Service): conectores ya construidos que enlazan sistemas distintos sin programar cada conexión desde cero.

Cuesta desde unas decenas de euros al mes en su versión más ligera hasta unos pocos miles en el nivel intermedio, donde encajaría un hotel independiente o una pequeña cadena.

Solo en el extremo enterprise, para grupos grandes con muchos sistemas heredados, la factura sube a decenas o cientos de miles de euros al año.

El coste, para la mayoría de los hoteles, no es la barrera.

Aunque tampoco hay que minimizar la complejidad real de conectar sistemas antiguos o proveedores poco dispuestos a abrir su API.

La verdadera ventaja competitiva

Todo esto se resume en dos preguntas que cualquier hotel puede hacerse hoy:

• ¿Decidimos con criterio qué capturar y estructurar, o dejamos que se acumule sin más?
• ¿Y de lo que ya tenemos, llega de forma unificada a los sistemas y agentes de IA que deciden por sí solos, o solo a los paneles que alguien tiene que abrir?

Gobernanza y destino del dato. Fuente: IA Claude / Hosteltur.

Un hotel con buen BI no ha resuelto este problema, aunque dentro de cada silo vea con claridad.

La ventaja de los próximos años no va a estar en quién tenga la IA más sofisticada, ni siquiera en quién tenga el mejor BI. Va a estar en quién esté dispuesto a incomodar su propio organigrama lo justo, ni más ni menos, para que el dato que de verdad importa tenga por fin un único dueño y un criterio claro que supere los silos y permita a toda la organización aprovecharlo".