Cómo evaluar la seguridad de un punto de venta para hotel antes de firmar

Cuando eliges el sistema que va a correr el restaurante de tu hotel, la demo siempre luce bien: la pantalla es rápida, el mesero levanta la orden en segundos, el cargo a la habitación aparece con una animación agradable. Lo que casi nadie te enseña en la demo es qué pasa el día que un empleado intenta ver algo que no le toca, o que alguien pide borrar una línea de un corte de caja que ya se cerró. Ese día es el que define si elegiste bien.

Por qué la seguridad no es una casilla en la hoja de comparación

La mayoría de las hojas de comparación de sistemas para el restaurante de un hotel tienen una fila que dice “seguridad” con una palomita. Esa palomita no dice nada. Un sistema puede tener contraseñas, roles y hasta un candado en el ícono, y aun así permitir que cualquier mesero con acceso a la tablet edite un ticket ya cobrado, o que un gerente que salió del hotel hace seis meses todavía tenga una sesión activa en algún dispositivo olvidado.

La seguridad real de un punto de venta para el restaurante de un hotel se juzga en tres terrenos concretos: quién puede hacer qué, y quién decide eso; si lo que ya ocurrió se puede alterar después; y qué tan protegidos están los datos del huésped mientras viajan entre la tablet, el servidor y el sistema de recepción. Vamos por los tres.

Dónde viven los permisos: en el servidor, no en la aplicación

Hay una diferencia enorme entre un sistema que oculta un botón en la pantalla del mesero y un sistema que impide la acción en el servidor. En el primer caso, el botón de “aplicar descuento” simplemente no aparece en la tablet del mesero, pero si alguien conoce el punto correcto para enviar la orden directamente, sin pasar por esa pantalla, el descuento se aplica igual. En el segundo caso, no importa por dónde llegue la solicitud: el servidor pregunta quién la está haciendo y revisa si esa persona tiene el permiso, y si no lo tiene, la rechaza sin importar qué pantalla, qué dispositivo o qué versión de la aplicación se use.

Esta distinción no es un detalle técnico menor. Ocultar un botón en la interfaz protege contra el error honesto de un mesero que no debía tocar algo. Verificar el permiso en el servidor protege contra la persona que sabe exactamente lo que está haciendo y busca un atajo. Un hotel con rotación de personal, con turnos nocturnos sin supervisión directa y con dispositivos que a veces se quedan sin bloquear necesita la segunda protección, no solo la primera.

La pregunta que le tienes que hacer al proveedor es directa: si yo desde otro dispositivo, o incluso desde una llamada directa a tu sistema, pido hacer algo que mi rol no permite, ¿tu servidor lo rechaza, o solo confía en que la aplicación no me lo iba a dejar hacer? Si la respuesta tarda en llegar o suena evasiva, ya tienes tu respuesta.

El registro de auditoría inmutable: la palabra clave es “no se puede editar”

Todo sistema serio para el restaurante de un hotel tiene un registro de auditoría: una bitácora que anota quién hizo qué y cuándo. La pregunta que separa un registro útil de uno decorativo es si ese registro se puede modificar o borrar después de creado. Un registro que se puede editar no es evidencia de nada, porque cualquiera con acceso suficiente puede reescribir la historia antes de que alguien la revise.

Un registro de auditoría inmutable funciona distinto: cada evento que ocurre en el sistema, desde que se abre una mesa hasta que se aplica una cortesía o se cancela un platillo ya enviado a cocina, se escribe una sola vez y queda ahí para siempre, sin importar quién lo consulte después ni con qué nivel de permisos. Corregir un error no borra el registro original: agrega un evento nuevo que dice qué se corrigió, quién lo corrigió y por qué. La historia completa queda visible, incluyendo el error.

Por qué esto importa más en un hotel que en un restaurante suelto

En el restaurante de un hotel hay una capa adicional de riesgo que un restaurante independiente no tiene: el cargo a la habitación mueve dinero entre el restaurante y el folio del huésped, y ese movimiento termina en el estado de cuenta que la recepción le entrega al huésped al momento de la salida. Si alguien puede editar en silencio un cargo ya aplicado a un folio, no solo se pierde el control interno del restaurante: se abre la puerta a una disputa con el huésped que nadie va a poder resolver, porque no habrá manera de reconstruir qué pasó de verdad.

Cifrado: en tránsito y en reposo, no solo en el discurso comercial

Cuando un proveedor dice “usamos cifrado”, la pregunta de seguimiento es en qué momentos. Hay dos momentos distintos y los dos importan. El primero es en tránsito: cuando la tablet del mesero le habla al servidor, cuando el servidor le habla al sistema de recepción para verificar un folio, cuando alguien abre el panel de reportes desde su celular. Ese tráfico debe viajar cifrado de punta a punta, de modo que si alguien intercepta la red del hotel no vea nada útil.

El segundo momento es en reposo: los datos guardados en el servidor, incluyendo los números de las tarjetas de pago cuando el sistema los procesa. Un proveedor serio no guarda el número completo de la tarjeta en texto plano en ninguna base de datos, y trabaja con un procesador de pagos certificado para el estándar de la industria de tarjetas, de modo que ese dato sensible nunca vive expuesto en el sistema del restaurante.

• Tráfico cifrado entre la tablet del mesero, el servidor y el sistema de recepción.
• Contraseñas guardadas con una función de un solo sentido, nunca en texto plano.
• Números de tarjeta procesados por un tercero certificado, nunca almacenados completos en el sistema del restaurante.
• Copias de respaldo también cifradas, no solo la base de datos en uso.

Llaves de acceso por propiedad: un hotel no debe poder ver los datos de otro

Si el sistema que evalúas atiende a más de un hotel, la pregunta siguiente es obligatoria: ¿qué separa mis datos de los del hotel del otro lado de la ciudad que también usa el mismo proveedor? La respuesta correcta es que cada propiedad tiene su propia llave de acceso, y que ni una consulta mal escrita, ni un error humano, ni un permiso configurado a la ligera pueden mezclar los datos de dos propiedades distintas. Esto se conoce como aislamiento por propiedad, y debe estar garantizado por el diseño del sistema, no por la buena fe de quien lo administra.

Pregunta específicamente cómo se implementa ese aislamiento. Un proveedor que responde con claridad técnica, mencionando que cada solicitud al servidor lleva la identidad de la propiedad y que el servidor la valida antes de tocar cualquier dato, transmite confianza. Un proveedor que responde “no te preocupes, eso lo manejamos nosotros” sin explicar cómo, no.

Diez preguntas para hacerle al proveedor antes de firmar

1. ¿Los permisos se verifican en el servidor o solo se ocultan en la pantalla de la aplicación?
2. ¿El registro de auditoría se puede editar o borrar por alguien con acceso administrativo?
3. ¿Qué queda registrado cuando se corrige un error: solo el estado final, o también el error original?
4. ¿El tráfico entre la tablet, el servidor y el sistema de recepción viaja cifrado?
5. ¿Dónde y cómo se procesan los pagos con tarjeta, y quién tiene la certificación correspondiente?
6. ¿Cómo se aísla mi propiedad de otras propiedades que usan el mismo sistema?
7. ¿Quién dentro de tu empresa puede ver mis datos operativos, y bajo qué justificación?
8. ¿Qué pasa con mis datos si dejo de ser cliente: se borran, se conservan, por cuánto tiempo?
9. ¿Tienen un proceso documentado para cuando detectan un intento de acceso indebido?
10. ¿Puedo pedir el historial completo de auditoría de mi propiedad en cualquier momento?

No hace falta que el proveedor tenga un departamento de seguridad enorme para responder bien estas diez preguntas. Hace falta que las haya pensado antes de que tú las hicieras, y que las respuestas sean específicas, no genéricas.

Un ejemplo ilustrativo del costo de no tener auditoría

Las cifras que siguen son inventadas para mostrar el cálculo, no describen a ningún hotel real. Imagina que en el corte de caja de una noche falta un monto y nadie puede explicar de dónde salió la diferencia porque el sistema anterior permitía editar un ticket después de cobrado sin dejar rastro de qué decía antes.

En el ejemplo, la falta de un registro inmutable no solo deja sin explicar los 1,850 originales: agrega 1,800 adicionales en horas de gerencia y contraloría intentando reconstruir algo que un sistema con auditoría real habría mostrado en un reporte de un minuto. Con un registro que no se puede editar, la misma investigación toma el tiempo de abrir el historial del ticket y ver exactamente qué pasó, quién lo hizo y a qué hora.

Señales de alerta durante la evaluación

Hay respuestas que deberían hacerte pausar antes de firmar cualquier contrato con un proveedor de punto de venta para el restaurante de tu hotel.

• El proveedor no puede explicar en qué capa se verifican los permisos, solo dice que “el sistema es seguro”.
• El registro de auditoría se describe como un reporte más, no como un historial que no se puede alterar.
• No hay respuesta clara sobre el aislamiento entre propiedades cuando el sistema atiende a varios hoteles.
• El manejo de tarjetas de pago no menciona a un procesador certificado, sino que “el sistema guarda los datos de forma segura” sin más detalle.
• Nadie del equipo comercial sabe a quién referirte cuando preguntas por el equipo técnico o de seguridad.

Qué hacer esta semana

1. Escribe las diez preguntas de esta guía y envíalas por correo a tu proveedor actual o a los que estás evaluando; pide respuestas por escrito, no en una llamada.
2. Pide un caso de prueba: que alguien intente editar un ticket ya cobrado y muestra qué queda registrado en el historial.
3. Verifica con tu equipo de sistemas si el tráfico entre tus dispositivos y el servidor del punto de venta usa una conexión cifrada.
4. Revisa el contrato para confirmar que los pagos con tarjeta pasan por un procesador certificado y no por el propio servidor del restaurante.
5. Si atiendes a más de una propiedad, pide una demostración específica de cómo se separan los datos entre ellas.
6. Guarda las respuestas por escrito; te van a servir el día que necesites reconstruir un incidente.

Inn Restaurant construye estas tres protecciones como parte del diseño del sistema, no como una capa opcional: permisos verificados en el servidor, un registro de auditoría que no se puede editar y aislamiento real entre propiedades. Si quieres ver cómo funciona en la práctica, puedes revisar la página de seguridad (Seguridad y control) o agendar una demo de 15 minutos (contacto) donde te mostramos el historial de auditoría en vivo.