Política de privacidad

Esta política explica qué datos personales pasan por Noctel, para qué, quién los ve y quién responde por ellos.

Hay dos grupos de personas involucradas, y no es lo mismo:

• La gente del hotel —el dueño y los usuarios de recepción— que tiene una cuenta en el sistema. De esos datos el responsable somos nosotros.
• Los huéspedes del hotel, que nunca entran al sistema pero cuyos datos el hotel carga en él. De esos datos el responsable es el hotel, y nosotros somos el encargado del tratamiento. La sección 2 explica qué significa eso.
• Quien solo pasa por una página pública —esta, los términos, la página de presentación— o usa el buscador de disponibilidad del sitio de un hotel. De esa persona no se guarda ninguna ficha. Si usa el buscador de disponibilidad, su dirección IP queda en el control de abuso y se borra al día siguiente (sección 3). Y en cualquiera de esas páginas su navegador le pide la tipografía de los iconos a Google (sección 9).

Si sos huésped de un alojamiento que usa este sistema y querés saber qué datos tuyos tiene, tenés que pedírselo a ese alojamiento: es quien decide qué se guarda de vos. En la sección 12 está explicado.

La ley 25.326 de protección de datos personales de Argentina distingue dos papeles, y todo lo demás depende de cuál te toca.

Qué significa en la práctica, de nuestro lado:

• Usamos los datos de los huéspedes únicamente para hacer funcionar el sistema del hotel que los cargó. Nada más.
• No los vendemos, no los cedemos, no los usamos para publicidad, no armamos perfiles y no entrenamos modelos de inteligencia artificial con ellos. El chatbot de WhatsApp es una máquina de estados escrita a mano: no manda las conversaciones a ningún servicio de inteligencia artificial.
• No cruzamos datos entre hoteles. Cada alojamiento ve lo suyo y nada más (sección 7).
• Solo subcontratamos los proveedores listados en la sección 9. No metemos otros sin avisar.
• Si un huésped nos escribe a nosotros pidiendo ver, corregir o borrar sus datos, no lo podemos resolver solos: lo derivamos al hotel, que es quien decide, y lo ayudamos a hacerlo. [A DEFINIR: en cuánto tiempo nos comprometemos a derivar ese pedido y a asistir al hotel]
• La ley dice que, terminada la prestación, los datos tratados por el encargado deben destruirse salvo que haya autorización para conservarlos. Hoy no hay ningún borrado implementado. Es un hueco real y está detallado en la sección 11.

Qué significa en la práctica, del lado del hotel:

• Tiene que informarles a sus huéspedes qué datos les pide y para qué, y contar con base legal para pedirlos (normalmente, que hagan falta para la reserva y la estadía).
• Decide a quién le da un usuario del sistema. Lo que ve cada uno, en cambio, no se configura: hay dos roles fijos —dueño y empleado— y el panel crea siempre empleados. Si el hotel necesita que alguien vea menos que un empleado, hoy el sistema no lo permite y la única forma de limitarlo es no darle usuario.
• Es quien atiende los pedidos de acceso, rectificación, actualización y supresión de sus huéspedes, y quien responde si no los atiende.
• Es responsable de lo que carga: si escribe en las observaciones de una reserva algo que no debería estar ahí, ese dato queda guardado. El sistema no controla el contenido de los campos de texto libre.
• [A DEFINIR: si hace falta que el hotel inscriba su base de datos ante la Agencia de Acceso a la Información Pública y si esta política alcanza como contrato de tratamiento (art. 25) o hay que firmar un anexo aparte con cada hotel]

Esto es lo que el sistema guarda de una persona que se aloja o consulta. Está enumerado tabla por tabla para que se pueda verificar contra el código.

Dos cosas de huéspedes quedan enumeradas más abajo, en la sección 4, porque viven en tablas del sistema y no del hotel: la dirección IP de quien usa el buscador de disponibilidad o el formulario de reservas del sitio web (tabla limites_intentos, se borra al día siguiente) y cualquier dato de un huésped que el hotel escriba en un campo de texto libre de otra tabla, como el título de una actividad.

De esta parte el responsable somos nosotros: son los datos de la cuenta, los de la gente que la usa y el rastro que deja su trabajo en el sistema.

Cookies: el sistema usa una sola cookie propia, hs_sesion, que mantiene la sesión iniciada durante 12 horas. Es httpOnly (el JavaScript de la página no la puede leer) y viaja cifrada en producción. No hay cookies de publicidad, de analítica ni de terceros.

• Del mostrador: lo que carga el hotel en el panel.
• Del sitio web del hotel: el buscador de disponibilidad y el formulario de reservas. El huésped completa nombre, apellido, email, teléfono, fechas, cantidad de personas, si viene con mascota y comentarios.
• De WhatsApp: lo que el huésped le dicta al chatbot durante la conversación.

No compramos bases de datos, no importamos contactos de ningún lado y no enriquecemos los datos con fuentes externas.

Los datos se usan para:

• Prestar el servicio: reservas, disponibilidad, consumos, stock, gastos e informes del hotel que los cargó.
• Contactar a la gente del hotel por cosas del servicio. Los correos que el sistema manda hoy son exactamente cuatro: el enlace para restablecer la contraseña, el aviso de que a un usuario le cambiaron la contraseña, el aviso de que la prueba se termina (uno cuando falta una semana o menos y otro el día que se termina) y el aviso de que la cuenta pasó a modo consulta. Un cobro rebotado no genera correo: se ve en el panel y nada más.
• Cobrar la suscripción y poder conciliar un pago discutido.
• Encontrar y arreglar errores: cuando algo falla, se registra el error para poder repararlo.

Los datos no se usan para:

• Publicidad, propia ni de terceros.
• Venderlos o cederlos a nadie.
• Cruzarlos entre hoteles distintos.
• Entrenar modelos de inteligencia artificial.

El sistema nunca le manda correos ni mensajes a los huéspedes. Todos los correos que salen van a la gente del hotel. Al huésped le habla el hotel, por sus propios medios, o el chatbot dentro de la conversación que él mismo empezó.

Cada alojamiento es un inquilino separado. La separación no depende de que las pantallas filtren bien: está en la base de datos.

• Sobre las tablas donde están los datos de los huéspedes y del negocio —habitaciones, clientes, reservas, pedidos y sus ítems, gastos, actividades, stock y sus movimientos, conversaciones del chatbot e historial de cambios de las reservas— Postgres aplica Row Level Security: cada consulta solo puede ver las filas del hotel que está fijado en esa transacción, aunque la consulta se escriba mal.
• Encima de eso, la aplicación abre cada operación dentro de un envoltorio que fija ese hotel y se niega a ejecutar si la conexión usa un rol que pudiera saltear el aislamiento.
• Son dos capas independientes a propósito: si una falla, la otra sigue conteniendo.
• Hay tablas que quedan afuera de esa primera capa, y conviene decirlo: las de los alojamientos y sus usuarios, las claves del chatbot, los tokens de recuperación, los intentos de acceso y la suscripción con sus eventos de pago. Están afuera porque se consultan antes de saber quién llama —el login busca un email sin saber todavía a qué hotel pertenece—, así que ahí el aislamiento lo sostiene una sola capa: el filtro por hotel escrito en cada consulta de la aplicación. En esas tablas no hay datos de huéspedes; sí están el nombre, el email y el hash de contraseña de la gente del hotel.

• El dueño del alojamiento ve todo lo de su alojamiento.
• Los usuarios de recepción ven lo que necesitan para atender: reservas y calendario, clientes, stock, tarifas, gastos y actividades, y cargan pedidos del restobar. No ven el listado de facturación del restobar, la analítica del negocio, la administración de usuarios, la configuración del hotel, las claves del chatbot ni la suscripción.
• Nosotros, para operar el servicio y resolver problemas, tenemos acceso técnico a la base de datos. Lo usamos para eso y nada más. [A DEFINIR: quiénes concretamente tienen ese acceso, con qué credenciales, si queda registro de cada acceso y bajo qué compromiso de confidencialidad. Hoy no hay registro de accesos de lectura ni un acuerdo firmado]
• Los proveedores de la sección 9, cada uno con la parte que le toca.
• Autoridades, si hay una orden judicial o un pedido legal válido. [A DEFINIR: si nos comprometemos a avisarle al hotel cuando llegue un pedido de ese tipo, salvo que la orden lo prohíba]

Estos son los proveedores que efectivamente intervienen. Bajo la ley 25.326 son subencargados: tratan datos para que nosotros podamos prestarle el servicio al hotel.

Transferencias internacionales: [A DEFINIR: si los datos salen de Argentina y con qué figura legal se amparan esas transferencias (art. 12 de la ley 25.326). Depende de las ubicaciones que queden confirmadas arriba]

Lo que hay hoy, verificable en el código:

• Las contraseñas se guardan con bcrypt. No se pueden leer, ni siquiera desde adentro.
• La sesión viaja en una cookie httpOnly y firmada, que dura 12 horas y en producción solo viaja por conexión cifrada.
• Aislamiento entre hoteles en dos capas independientes (sección 7).
• De las claves del chatbot y de los enlaces de recuperación se guarda solo el hash.
• Hay límite de intentos en el ingreso, el registro, la recuperación de contraseña, el cambio de contraseña, la emisión de claves y el formulario de reservas del sitio web.
• Las notificaciones de Mercado Pago se verifican con firma: si no se puede verificar quién las mandó, no se procesan.
• La conexión con la base de datos va cifrada, y la aplicación se conecta con un rol que no puede saltear el aislamiento.
• Los datos de tarjeta no pasan por nuestro servidor.

Lo que hoy no hay, dicho para que nadie asuma lo contrario:

• Segundo factor de autenticación.
• Cifrado adicional de campos sensibles dentro de la base (el DNI y el teléfono se guardan tal cual).
• Registro de quién consultó qué. Se audita lo que se modifica en las reservas, no lo que se mira.
• [A DEFINIR: política de copias de seguridad y prueba de restauración (ver también los términos, sección 10)]

Lo que efectivamente pasa hoy:

• Los datos se conservan mientras la cuenta del alojamiento exista. No hay borrado automático por antigüedad: una reserva de hace tres años sigue guardada.
• Los registros de intentos de acceso —con IP, email y teléfono— se borran solos: un proceso diario elimina todo lo que tenga más de un día.
• Dentro del panel, un cliente se puede eliminar solo si no tiene ninguna reserva asociada; si tiene, el sistema no lo deja, para no dejar el historial de facturación sin nombre.
• Una reserva no se borra: se cancela. Queda en el historial con el nombre del huésped.
• Falta de pago, suspensión y baja de la suscripción no borran nada.

El hueco, dicho claro: hoy no existe una política de retención ni una forma de dar de baja una cuenta con borrado de sus datos. No hay pantalla, no hay endpoint y no hay proceso. Si un hotel se va y pide que borremos todo, eso hoy se resolvería a mano.

[A DEFINIR: la política de retención completa: cuánto se conserva cada tipo de dato después de que termina la relación con el alojamiento, qué se guarda igual por obligación contable o fiscal y por cuánto, cómo se pide el borrado, en qué plazo se hace y si antes se entrega una copia de los datos. Hace falta escribirla y además implementarla: es la deuda más grande de este documento]

Toda persona tiene derecho a saber qué datos suyos hay, a pedir que se corrijan o actualicen si están mal, y a pedir que se supriman cuando corresponde. A quién se le pide depende de quién sea el responsable.

Si sos huésped de un alojamiento: el pedido va al alojamiento, no a nosotros. Es quien decidió qué datos tuyos guardar y quien puede resolverlo. Si nos escribís a nosotros, derivamos el pedido a ese alojamiento y lo asistimos, pero no podemos borrar ni modificar datos de su base por nuestra cuenta.

Qué puede hacer el hotel hoy, desde el sistema, para atender uno de esos pedidos:

• Ver y entregar los datos: la ficha del cliente y sus reservas se consultan en el panel, y las pantallas de reservas, pedidos e informes exportan a CSV.
• Corregir: los datos del cliente y de la reserva se editan.
• Suprimir: un cliente sin reservas se puede eliminar. Uno que ya tiene reservas, no —el sistema lo bloquea para no romper el historial—. [A DEFINIR: cómo se resuelve un pedido de supresión de un huésped que ya tuvo estadías: qué exige conservar la normativa fiscal y de registro de pasajeros, y qué se puede anonimizar. Hoy el sistema no ofrece ninguna forma de anonimizar una reserva]

Si sos usuario del sistema (dueño o empleado de un alojamiento): sobre tus propios datos de cuenta el responsable somos nosotros. Escribinos a santinomartins539@gmail.com y lo resolvemos. [A DEFINIR: confirmar plazos y su cita: la ley prevé diez días corridos para contestar un pedido de acceso (art. 14) y cinco días hábiles para rectificar o suprimir (art. 16). El abogado tiene que confirmar los plazos, la gratuidad y cada cuánto se puede volver a pedir]

La autoridad de control en Argentina es la Agencia de Acceso a la Información Pública, ante la que se puede reclamar si un pedido no se atiende. [A DEFINIR: si corresponde incluir el texto exacto de la leyenda reglamentaria de la autoridad de control y en qué términos]

Si detectamos un acceso indebido o una filtración que afecte datos de un alojamiento, se lo avisamos con lo que sepamos: qué pasó, qué datos estuvieron involucrados y qué hicimos.

[A DEFINIR: en cuánto tiempo nos comprometemos a avisar, por qué medio, qué le corresponde notificar al hotel como responsable, y ante qué organismo. Hoy no existe un procedimiento escrito de respuesta a incidentes: hay reporte automático de errores y logs, nada más]

Si esta política cambia, se actualiza la fecha de arriba. Cuando el cambio afecte de verdad cómo se tratan los datos, se lo avisamos por correo al dueño de cada alojamiento.

[A DEFINIR: con cuánta anticipación se avisa y si se conservan las versiones anteriores de esta política. Hoy no se guarda ninguna]

Por cualquier cosa relacionada con datos personales —tuyos o de un huésped—: santinomartins539@gmail.com.

Si el pedido es de un huésped, contanos de qué alojamiento se trata: lo derivamos a quien tiene que resolverlo.

Las condiciones del servicio están en los términos y condiciones.