Rechazo del plan “QR → WhatsApp → pide descargar Telegram” (2026-09-26)

Plan propuesto por nef: QR en la clínica → deep link a WhatsApp → el que escribe recibe respuesta automática → “por políticas de privacidad, para continuar te pedimos descargues Telegram”.

Veredicto: no. El pretexto de privacidad es falso por construcción, el flujo de opt-in es inválido, y el plan se contradice con la estrategia de Telegram-first.

1. El pretexto de privacidad es falso (esto solo lo tumba)

El QR ya mandó el mensaje a la red de Meta antes de que exista la descarga. Si Meta es el problema de privacidad, el primer mensaje ya salió. La descarga no repara nada retroactivo: solo agrega un paso después del daño.

“Descarga esta app por política de privacidad” además no es una medida de privacidad, es un dark pattern. Y bajo LFPDPPP es ilegal como mecanismo de consentimiento porque el consentimiento debe ser informado, específico y expreso, con aviso de privacidad. Un instalador no da ninguna de las tres cosas:

• No informa: no dice qué datos, ni para qué, ni quién los ve.
• No es específico: no distingue datos personales de salud.
• No cubre la transferencia a un tercer país (Telegram: Amsterdam + Miami, constituida en Dubai). LFPDPPP exige consentimiento expreso para transferencia internacional, y eso no se pide en un instalador.
• Y el dato de salud (síntomas, expediente) es dato personal sensible.

Para el usuario que dijo “no quiero dar mis biométricos a Meta”, esto es peor que lo que estaba evitando: ahora el paciente entrega su número a Meta y su consentimiento no vale.

2. El opt-in no se puede obtener dentro de WhatsApp

Verificado en la documentación pública de opt-in de WhatsApp y guías del sector (Landbot, Picky Assist, sendwo):

• “An opt-in cannot happen via WhatsApp.” El usuario debe entregar su número por un tercer canal del negocio (web, app, email, SMS, punto de venta).
• El opt-in debe ser activo, disparado por una acción del usuario.
• Debe haber un elemento visual (checkbox) junto al nombre y logo de WhatsApp.
• Debe haber texto adyacente que explique qué mensajes recibirá.
• El usuario debe poder elegir o editar el número.
• Meta revisa los flujos de opt-in rutinariamente y monitorea señales de calidad; “si Too many people start blocking you, you might be up for a review”.

El QR abre un chat con mensaje precargado. Eso no es opt-in: nadie recoge consentimiento, nadie ve un checkbox, nadie elige número. El flujo entero nace sin la pieza que Meta exige antes de cualquier mensaje.

3. La CTA está fuera de la lista permitida en templates

La revisión de templates evalúa la intención del contenido, no solo la forma. CTAs aprobadas: Reply YES / NO, Confirm / Reschedule, View details, Contact support. Se rechazan por claims engañosos y por pedir datos sensibles. “Descarga Telegram para continuar” no es una CTA de negocio: es un engaño sobre la naturaleza del servicio, y se lee como tal.

La cadena de daño es larga y todo sube: template rechazado → quality rating baja → menos límites de mensajería → más revisión por reportes/bloqueos → baneo.

Y la enumeración es asimétrica: Meta puede banearte por algo que no pretendías, sin aviso previo (“in some cases, WhatsApp may ban you outright with no warning”). Estás construyendo un generador de reportes: cada persona que se molesta e imprime “spam” o bloquea baja tu calidad.

Honestidad sobre lo que NO verifiqué: no encontré la cláusula textual que prohíba por nombre “sacar al usuario de WhatsApp”. No la voy a citar porque no la tengo. Lo que sí es verificable y suficiente: el opt-in falla en ambos canales, la CTA está fuera de la lista, y la superficie de reportes que generas es el trigger documentado de revisión.

4. El plan contradice la estrategia que acabamos de cerrar

Todo el argumento de Telegram-first era: Meta no está en el camino. Este plan pone a Meta en el camino para reclutar usuarios de Telegram. Pagas los $17-47 USD/mes de los números, tomas el riesgo de baneo de Meta, necesitas el opt-in que Meta exige — y luego le pides al usuario que se vaya. Estrictamente peor que apuntar el QR directo a Telegram.

5. Los tres planes que sí funcionan

A — Soberano, $0, cero fricción (recomendado)

QR → página propia en tu dominio. Un Worker, un dominio, el RAG en el navegador, aviso de privacidad real, horarios, mapa, precios. Telegram y WhatsApp como opciones con link, nunca como condición. El paciente que no quiere instalar nada ya resolvió su duda ahí.

Es el “web en paralelo” del §7 del primer documento, y ahora con sentido: es la puerta de entrada, no el plan B.

B — Telegram-first, $0

QR → t.me/<bot>/<appname>. Direct link a la Mini App o al bot. Meta fuera completamente, opt-in innecesario (el usuario inicia la conversación con un gesto explícito), $0. Si el usuario no tiene Telegram, el prompt de instalación es de Telegram, no tuyo — y eso sí es legítimo.

C — WhatsApp, después, sin divert

QR → wa.me / Click-to-WhatsApp, con el opt-in capturado ANTES en tu web. Es el patrón documentado: el QR es un tercer canal válido, pero la página propia recoge el consentimiento con checkbox y el usuario elige número. La conversación se queda en WhatsApp. Nunca pides salir.

Un QR impreso no es un template, así que no choca con la prohibición de wa.me dentro de templates. Para tracking, tu propio dominio con UTM — nada de shorteners (WhatsApp los bloquea y los marca).

6. La corrección de fondo

“Descarga nuestra app por política de privacidad” es una falsa promesa de seguridad. Si te importa la privacidad de verdad, el diseño correcto es: el usuario resuelve su duda sin entregar nada, y la decisión de instalar o no es suya. El plan propuesto invierte eso: no resuelve nada sin entregar datos, y finge que la entrega es la protección.

Un QR de recepción existe para quitar fricción, no para crear una. Pedirle a alguien parado en el mostrador que instale Telegram para preguntarle el precio de una limpieza es absurdo en cualquier caso — incluso si fuera legal.

7. Estado

• Este plan queda descartado. Si vuelve a aparecer, esta es la referencia.
• El trabajo que sí está desbloqueado es el §5A (página propia) o el §5B (Telegram), ambos $0 y ninguno de los dos requiere nada de Meta.
• Pendiente sin resolver, de antes: Space [usuario]/sonrisa-inference sigue en CPU sin ZeroGPU.

Facts verificados contra

• Landbot, “Collecting WhatsApp Opt-In”: “An opt-in cannot happen via WhatsApp”; opt-in por tercer canal, activo, con elemento visual, con el usuario controlando el número
• Picky Assist, “WhatsApp Opt-In Guidelines”: checkbox junto al nombre y logo de WhatsApp, texto adyacente, control del número; Meta revisa los opt-in flows y monitorea quality signals, “if too many people start blocking you, you might be up for a review”
• sendwo, “WhatsApp Business Policy Violations”: baneo permanente, “This account can no longer use WhatsApp”, “in some cases, WhatsApp may ban you outright with no warning”
• whatsboost, “WhatsApp API Template Approval Rules”: CTAs permitidas (Reply YES/NO, Confirm/Reschedule, View details, Contact support); rechazo por claims engañosos y por pedir datos sensibles
• Green Tick, “Template Rejected: 10 Proven Reasons”: WhatsApp bloquea URL shorteners y enlaces wa.me dentro del cuerpo de templates; usar dominio propio
• Business Insider, 2021-02-19: el cambio de política de privacidad de WhatsApp de enero 2021 “pushed many users to Signal and Telegram”; Meta revirtió. Contexto de riesgo reputacional de intentar sacar usuarios
• core.telegram.org/bots/webapps: direct link t.me/<bot>/<appname>; Mini Apps alojadas por el cliente

---

Enmienda 2026-09-26 — nef tiene razón sobre el número, y el número no era el payload

nef objeta: “Meta ya tenía el número, lo queremos sacar de ahí.”

Concedido en la parte estrecha. Mi redacción era incorrecta. Si el paciente ya tenía el número de la clínica o ya le escribió, Meta ya lo tenía; decir que “le entregas el número a Meta” es falso para ese caso. Corrección registrada.

Pero el número nunca fue el dato que importa, y aquí está el hallazgo real.

E1. El contenido NO es end-to-end encrypted en la ruta Cloud API

Esto es lo contrario de lo que cualquiera asume. Evidencia directa de Meta (developers.facebook.com/docs/whatsapp/cloud-api/overview/data-privacy-and-security):

“When a user sends a message to a business that uses Cloud API, the message travels encrypted via WhatsApp between the user and Cloud API. Once Cloud API receives the message, Cloud API decrypts the message and forwards it to the business.”

“In order to send and receive messages through Cloud API, Cloud API manages the encryption/decryption keys on behalf of the business.”

Y de faq.whatsapp.com:

“When you message a business account, your message is delivered securely to the destination chosen by the business. Once the message is received, it will be subject to the business’s own privacy practices.”

Lo que esto significa, y es el punto que cierra la discusión:

• Un chat personal con la clínica es E2EE. Meta no lee el contenido.
• Un bot sobre ese mismo número no puede ser E2EE. El bot requiere Cloud API, Cloud API descifra, y Meta queda leyendo cada mensaje del paciente.

Un chatbot es exactamente la cosa que rompe el cifrado de extremo a extremo. Si el motivo para sacar los datos de Meta es la privacidad del mensaje, el bot es el enemigo del argumento, no la solución. Esto no lo había considerado antes y es más fuerte que lo que escribí en §1.

E2. Retención y rol de Meta

• Contenido: “Messages have a maximum retention period of 30 days in order to provide the base features and functionality of the Cloud API service”.
• Identificadores: “Cloud API uses identifiers as sources or destinations of individual messages; as such, Cloud API deletes them within 30 days of the last status update (sent, delivered, read)“.
• Rol: “Meta, in providing Cloud API service, acts as a data processor/service provider on behalf of the business”.
• Lo que Meta NO hace: “Cloud API will not automatically use WhatsApp messages to inform the ads that a person sees”.
• El carve-out que importa: “However, as is always the case, businesses can use messages they receive for their own marketing purposes, which may include advertising on Facebook or other channels”.

Traducción: el riesgo de privacidad no desaparece, se traslada a la clínica. Y si la cuenta la administra un BSP, se traslada también al BSP. Meta se declara “data processor”; el que decide el uso es la clínica. Zak Doffman (Digital Barriers), citado por WIRED 2021: “WhatsApp says Facebook can’t use this data, but the business can mine chats for advertising.”

E3. El precedente de 2021, con números

WIRED, 2021-07-24: tras el cambio de política de enero 2021, Signal subió 35× a 8.8 millones de descargas en una semana y Telegram 11 millones en la semana siguiente a la actualización. Business Insider confirmó que Meta revirtió a los días.

Hacer la migración a Telegram por el embudo de Meta es pedir exactamente el resultado que hizo que Meta entrara en pánico en 2021. Y esta vez de forma deliberada, con un mensaje que dice “te sacamos de aquí”.

E4. El redirect no borra el evento

“Se lo sacamos de Meta” suena arelsativo, pero la primera interacción ya ocurrió: el paciente escaneó y escribió. Mover la conversación en adelante mueve el dato continuo; no borra el evento de que esa persona contactó a esa clínica por WhatsApp. El evento ya está en los sistemas de Meta y no hay un “des-ver”.

El redirect no es salida. Es la primera entrega, y la que no se puede deshacer.

E5. El objetivo y el mecanismo son incompatibles

nef quiere sacar el dato de Meta. El plan usa Meta como puerta de entrada. Eso es una categoría: no se puede usar el sistema del que quieres salir como portón. Un QR a tu dominio no registra nada en Meta — cero. Un QR a wa.me registra todo lo de E1 y E2.

La conclusión operativa no cambia y ahora tiene mejor fundamento: A (dominio propio) o B (Telegram directo), y ninguno de los dos empieza en Meta.

Facts verificados contra

• developers.facebook.com/docs/whatsapp/cloud-api/overview/data-privacy-and-security: “Once Cloud API receives the message, Cloud API decrypts the message and forwards it to the business”; “Cloud API manages the encryption/decryption keys on behalf of the business”; “maximum retention period of 30 days”; identificadores borrados “within 30 days of the last status update”; Meta “acts as a data processor/service provider”; “will not automatically use WhatsApp messages to inform the ads that a person sees”; “businesses can use messages they receive for their own marketing purposes, which may include advertising on Facebook”
• faq.whatsapp.com/820124435853543: “When you message a business account, your message is delivered securely to the destination chosen by the business. Once the message is received, it will be subject to the business’s own privacy practices.” Los chats con AI de Meta se marcan y “we do not consider messages with these businesses to be end-to-end encrypted”
• faq.whatsapp.com/1182985198951186 (enero 2021): “whether you communicate with a business by phone, email, or WhatsApp, it can see what you’re saying and may use that information for its own marketing purposes, which may include advertising on Meta”
• WIRED 2021-07-24: Signal 35× a 8.8M; Telegram 11M en la semana tras la actualización; cita de Zak Doffman, Digital Barriers
• sleekflow.io, “Is WhatsApp secure?”: “Meta’s own developer documentation states that Cloud API manages the encryption and decryption keys on behalf of the business”; “Personal WhatsApp chats and chats with businesses using the free WhatsApp Business app are end-to-end encrypted by default… business messaging through the API works differently”