El modelo de consulta de la PUI, explicado
La PUI no vigila a tus huéspedes en vivo: funciona por consulta. La autoridad de búsqueda pregunta por una persona reportada y el establecimiento responde desde su padrón. Esta página explica cómo opera ese modelo —qué se pregunta, qué se responde y por qué no es monitoreo masivo—, para tranquilizar a dueños y precisar el punto a abogados y consultores.
La idea central: se pregunta por una persona, no se vigila a todas
El diseño de la PUI descansa en un principio simple: la autoridad de búsqueda formula una consulta acotada sobre una persona específica reportada como desaparecida, y el establecimiento responde desde su propio padrón si esa persona se registró. No hay un flujo continuo en el que el gobierno observe en tiempo real a todos los huéspedes de un hotel. Es una pregunta puntual, no una transmisión permanente.
Esta distinción no es un matiz: cambia por completo la naturaleza de la obligación. Para un dueño, significa que su padrón no queda “expuesto” de forma abierta ni se vuelca masivamente; solo responde a una pregunta concreta cuando la hay. Para un abogado o un consultor, significa que el modelo se parece a una consulta dirigida bajo un fundamento de búsqueda, y no a una vigilancia generalizada.
El fin que justifica todo el mecanismo es el de la LGMDFP: localizar a personas reportadas como desaparecidas. El modelo de consulta es la forma de servir a ese fin sin convertir cada registro de hospedaje en un punto de monitoreo permanente.
Cómo funciona la consulta, paso a paso
De la persona reportada a la respuesta del establecimiento, en una secuencia clara.
- Se reporta a una persona desaparecidaLa autoridad de búsqueda necesita rastrear dónde pudo haber estado una persona específica reportada como desaparecida.
- Se formula la consulta acotadaA través del sistema se pregunta por esa persona, identificándola con datos como su CURP o su nombre. La pregunta es sobre una persona, no sobre todos los huéspedes.
- El establecimiento responde desde su padrónSi esa persona se registró, el sistema responde de forma segura; si no, no hay coincidencia. La respuesta sale del padrón propio del hospedaje.
- Se cumple sin volcar datos masivosHaber registrado la identidad y poder responder a la consulta es exactamente lo que la ley exige. No se entrega el padrón completo: se responde a la pregunta.
Por qué NO es monitoreo masivo
Las razones por las que el modelo es de consulta puntual y no de vigilancia continua.
La pregunta es por una persona
La consulta se refiere a una persona específica reportada, no a una lista abierta de todos tus huéspedes.
No es un volcado del padrón
Responder una consulta no es entregar la base completa de huéspedes; es contestar si hay coincidencia con la persona buscada.
Es a demanda, no continuo
No hay un flujo permanente de datos: la consulta ocurre cuando la autoridad busca a alguien, no todo el tiempo.
Fundada en la búsqueda
El modelo se ejerce dentro del marco de la LGMDFP, con la finalidad de localizar a personas reportadas como desaparecidas.
Identidad, no consumo
Lo que se registra y se consulta es identidad (CURP, nombre, documento), nunca tarjeta de crédito ni cuánto gastó el huésped.
Cumplir es estar listo para responder
El deber se satisface registrando bien la identidad y estando en condiciones de contestar la consulta cuando llegue.
Qué se pregunta y qué se responde, con precisión
En el modelo de consulta, la pregunta identifica a una persona específica con datos de identidad, típicamente su CURP o su nombre. La respuesta del establecimiento es, en esencia, si esa persona aparece en su padrón. No se trata de exhibir la información de todos los huéspedes, sino de confirmar o descartar una coincidencia respecto de la persona buscada.
Para los aspectos técnicos de cómo viaja esa consulta y esa respuesta, el Manual Técnico v1.0 (DOF, 23 de enero de 2026) define una arquitectura REST/JSON, autenticación con tokens JWT y cifrado de extremo a extremo con AES-256-GCM, además de hash SHA3-256 y transporte TLS. Es decir, la consulta no es un correo ni una llamada informal: es un intercambio cifrado y autenticado por diseño.
Conviene reiterar el límite material de los datos: lo que se registra y se consulta es identidad. No forman parte del modelo la tarjeta de crédito del huésped, el monto que pagó ni lo que consumió. Quien explique este modelo a un dueño puede afirmarlo con tranquilidad; quien lo analice como abogado puede sostenerlo con precisión.
Fuentes oficiales
Marco: Ley General en Materia de Desaparición Forzada de Personas (LGMDFP), Art. 12 Bis (obligación de registro) y Art. 43 Bis (sanción). Órganos: SEGOB y la Comisión Nacional de Búsqueda (CNB) en la función de búsqueda; RENAPO en identidad; ATDT en soporte técnico.
Especificaciones técnicas: Manual Técnico v1.0 publicado en el Diario Oficial de la Federación (DOF) el 23 de enero de 2026 (arquitectura REST/JSON, JWT, AES-256-GCM, SHA3-256, TLS). Otras publicaciones: reforma a la LGMDFP en julio de 2025; Lineamientos el 27 de noviembre de 2025; Manual de Operación del SNIP, pendiente a junio de 2026.