La seguridad de los agentes de IA en reservas hoteleras ya no es un asunto técnico: es operativo. Un agente puede atender a cualquier hora, comprobar inventario y confirmar reservas. El problema es que, para hacerlo, necesita tocar el PMS, el calendario y los datos del huésped.

La pregunta no es si automatizar. Es cómo hacerlo sin convertir el sistema en una puerta abierta a los datos de sus clientes.

Qué cambia cuando el agente puede actuar

Un chatbot responde preguntas. Un agente ejecuta: consulta disponibilidad, modifica una reserva, emite un reembolso. Ahí el riesgo deja de ser solo el hackeo clásico de la plataforma y pasa a incluir algo nuevo: que el propio agente haga algo que no debía, porque interpretó mal una instrucción o porque alguien se la coló.

Microsoft avisa de que cada interacción entre agentes, servicios y herramientas abre una oportunidad de filtración o de acción no autorizada. Puede ampliarlo en su guía sobre gestión del riesgo en sistemas agénticos.

Los riesgos principales

  • Exposición de datos del huésped. Nombres, teléfonos, historial de estancias, datos de pago. Si una consulta es «¿hay habitaciones el viernes?», el agente no necesita el historial de nadie para responder.
  • Inyección de instrucciones. Un mensaje —o un documento que el agente lee— puede llevar órdenes ocultas. El agente nunca debe tratar texto recuperado de una fuente externa como una orden autorizada.
  • Permisos que no distinguen informar de actuar. Una IA que consulta disponibilidad tiene un perfil de riesgo distinto de una que puede cancelar y reembolsar.
  • La cadena de suministro. El riesgo no está solo en el agente: está en sus conectores, plugins y bases de conocimiento. Cada integración añadida debe justificar su presencia.
  • Decisiones que no se pueden explicar. Debe poder responder por qué se recomendó una opción o se rechazó una solicitud. Witness AI lo trata en detalle para hostelería.

Confianza cero y privilegios mínimos

Confianza cero significa tratar toda entrada externa como no fiable por defecto. Privilegios mínimos, dar al agente solo el acceso imprescindible para su tarea. En un hotel eso se traduce en separar funciones:

  • Agente de disponibilidad: consulta inventario. No cancela.
  • Agente de postventa: gestiona incidencias. No modifica tarifas.
  • Cualquier reembolso o cambio con impacto económico: propuesta del agente, aprobación de una persona.

Controles desde el primer día

  • Enmascarar antes del modelo. Que el agente trabaje con un identificador de reserva, no con el nombre completo ni el número de documento.
  • Los fundamentos de siempre: cifrado, autenticación reforzada en funciones administrativas y acceso interno por responsabilidad. Sin atajos.
  • Filtros en las dos direcciones: a la entrada, detectar manipulaciones; a la salida, evitar que se filtren datos que no tocaba mostrar.
  • Registro de cada interacción: qué se pidió, qué consultó el agente, qué regla aplicó, qué herramienta usó y qué devolvió. Un registro que nadie revisa no es auditoría.

Pruébelo antes de que lo pruebe un cliente

Las demostraciones internas no valen como validación. Diseñe escenarios reales: alguien que intenta modificar la reserva de otra persona, un mensaje que trata de convencer al agente de saltarse una política, una herramienta caída a mitad de operación. Los permisos y los límites se definen antes de procesar la primera interacción, no después.

Si valora ejecutar el modelo en local para no sacar datos de huéspedes fuera, aquí analizamos las implicaciones: Muse Glimmer y los agentes de IA locales. Y si su caso es más de CRM y ERP que de PMS, lo tratamos en seguridad de los agentes de IA en reservas empresariales.

Lo que vemos en la práctica

Este mismo blog está automatizado, y al montarlo tuvimos que decidir exactamente lo que plantea el artículo. Al crear el token que publica en el repositorio, la opción cómoda era darle acceso a todo. Le dimos permiso a un solo repositorio y una sola función: escribir archivos. Nada más. Si mañana ese token se filtra, el daño está acotado de antemano.

Es la pregunta de cada diagnóstico, y casi nadie la ha respondido antes de conectar nada: no qué puede hacer la herramienta, sino qué no debería poder hacer. Con una segunda que también se olvida: qué gasto genera cada conexión.