Revocación del bot: perfil de negocio de WhatsApp + página propia (2026-09-26)

Decisión que deroga lo anterior: no hay chatbot, no hay Cloud API, no hay WABA, no hay portfolio de developers, no hay verificación de negocio. La superficie de WhatsApp es el perfil de negocio de la app gratuita de WhatsApp Business, y el CTA “Para comunicarse” apunta a un dominio propio o a t.me/clinica.

1. Por qué esto resuelve la objeción de E1

La objeción de la Enmienda era: “un chatbot es exactamente la cosa que rompe el cifrado de extremo a extremo”, porque Cloud API descifra y Meta lee.

Un perfil de negocio no es Cloud API. No hay webhook, no hay messages endpoint, no hay claves que Meta administre, no hay descifrado de parte de Meta. El paciente ve un perfil con un link. Si nunca presiona “Mensaje”, no se escribe nada, no hay nada que descifrar, y no hay dato de salud en manos de Meta.

Meta lo dice explícitamente (FAQ enero 2021):

“WhatsApp will not give your number to a business, and our policies prohibit businesses from contacting you on WhatsApp without first receiving your approval to do so.”

Ver el perfil y tocar el link no entrega el número del paciente. Eso es una propiedad fuerte y es la razón de que la objeción de E1 desaparezca: ya no hay mensaje que romper.

2. Lo que se derrumba del plan anterior (todo el stack de riesgo y costo)

Se elimina de un golpe todo lo que justificaba el costo y el riesgo:

• Cloud API → fuera. Con ella iban las claves, el descifrado, los 30 días de retención de contenido y los identificadores.
• Templates → fuera. Sin templates no hay revisión de CTA, ni rechazo por “engaño”, ni caída de quality rating.
• Opt-in de Messaging Policy → fuera. Ese opt-in es para iniciar mensajes por parte del negocio. Un perfil que muestra un link no inicia nada. (Ojo: esto no aplica si más adelante se quiere mandar recordatorios proactivos — eso sí requiere opt-in y template.)
• Verificación de negocio → fuera. La app gratuita no la pide. La que lo pide es la vía Cloud API.
• Costo por mensaje → fuera. Nada se cobra: no hay messaging.
• Costo de números → fuera. Se usa el número que la clínica ya tiene, en la app gratuita. De los ~$300-800MXN/mesqueestimamosparadosn\acute{u}meros,estobajaa\ast \ast$0**.
• Meta en el camino del dato → sale. El dato del paciente (o no) vive en el dominio propio o en Telegram.

Costo total del canal WhatsApp: $0.Infra:$0 si se queda en el Free plan.

3. La ruta, corregida

Propuesta de nef: QR → WhatsApp → perfil → CTA a example.com o t.me/clinica.

Un ajuste: si el destino final es el dominio propio, el QR debe ir directo al dominio. El salto por WhatsApp añade dos toques y app-switch sin ganancia.

Ruta recomendada:

• QR → example.com (dominio propio). Página con: aviso de privacidad, horarios, ubicación, y los dos links co-presentes — el chat en la página y t.me/clinica. El paciente elige; el que no quiere instalar Telegram no se queda sin nada.
• El perfil de WhatsApp se queda como presencia, no como embudo. Vale $0 y es donde la gente busca la clínica. Perfil: nombre, categoría, dirección, horarios, email, y el website apuntando al dominio.

Pie de página del perfil — el riesgo real de este diseño: el perfil tiene botón de “Mensaje”. Sin bot detrás solo hay el saludo/ausencia estático de la app gratuita. Una fracción de los pacientes lo va a presionar y va a escribir a un vacío. Es aceptable, pero es un final de camino muerto que hay que asumir a propósito, no por accidente.

4. Lo que el perfil NO puede hacer (y por qué está bien)

• Mensajes proactivos: recordatorios de cita, confirmaciones,AUSencias. Nada de eso existe sin Cloud API + templates + opt-in.
• Escalar a messaging: hundreds de conversaciones simultáneas, catálogos, campañas.
• Integrarse con el RAG: el perfil no es un endpoint.

Consecuencia de diseño, y es la buena: la clínica no queda atada a Meta. Recordatorios, si alguna vez hacen falta, son un increment posterior con número concreto y decisión consciente de la clínica — no un precondición de la primera versión. Esto es exactamente el sesgo de “scope down” aplicado al canal.

5. Costo de la opción (a): el chat en la página

workers.new/templates/llm-chat-app-template — no pude leer la página: es JS-rendered y el fetch devolvió solo el shell. No conozco sus bindings exactos. Hay que desplegarlo y leer el wrangler.jsonc real. Se ofrece hacerlo.

Datos de costo verificados de Cloudflare:

Concepto	Free	Paid
Workers AI	10,000 Neurons/día gratis	+ $0.011 / 1,000 Neurons
Workers	100,000 req/día (compartido con Pages Functions)	mayor
Static assets	gratis e ilimitados	gratis e ilimitados
Egress / ancho de banda	sin cargo	sin cargo
Workers Logs	200,000 eventos/día, retención 3 días	20M/mes, 7 días
Logpush	no	$0.05/M req
Mínimo Workers Paid	—	$5 USD/mes

La trampa concreta: varios modelos ahora exigen Workers Paid y devuelven 403 con error interno 5035 en plan Free. Entre ellos: @cf/moonshotai/kimi-k2.6, @cf/moonshotai/kimi-k2.7-code, @cf/zai-org/glm-5.2, glm-5.3, glm-5.3-flash, @cf/deepseek-ai/deepseek-v4-flash-0731, deepseek-v4-pro-0813.

Modelos que sí siguen en Free:

• @cf/zai-org/glm-4.7-flash
• @cf/google/gemma-4-26b-a4b-it
• @cf/nvidia/nemotron-3-120b-a12b

→ Al desplegar el template hay que fijar el model ID a uno de esos tres. Si el template trae un modelo de pago por defecto, va a fallar con 403/5035 y va a parecer que es un problema de facturación. No lo es: es el ID del modelo.

Alternativa si el Free se queda corto: **$5/mesdeWorkersPaid\ast \ast ,no$17-47 de números. El orden de magnitud del costo se reduce en un orden.

6. El template NO es el RAG — no confundir

El template de workers.new es un chat LLM: interfaz + prompt + un model ID. No tiene corpus, ni retrieval, ni aislamiento por tenant, ni las protecciones anti-oráculo. Eso vive en [CREDENCIAL].md y en el piloto de proyecto_1_dentistas.

Orden de incrementos (scope down, un paso a la vez):

1. Desplegar el template, fijar model ID de Free, $0. La clínica ya tiene una URL real y usable. Esto es lo que se ve.
2. Ponerle los controles anti-oráculo de §5: respuestas nada más, citas ≤25 palabras, cero IDs y nombres de archivo, rate limit, sin prompt echo, sin secretos en el cliente. El template solo no cumple esto.
3. Recién entonces, colgar el corpus del piloto detrás.

El paso 1 es lo que produce un artefacto concrete hoy. Los pasos 2 y 3 no se anticipan: se hacen cuando el paso 1 esté en manos de alguien.

7. Estado y siguiente paso

• Canal WhatsApp: perfil de negocio, $0, CTA a dominio propio o t.me/clinica.
• Canal web: Worker con el template de workers.new, $0 en Free con model ID correcto.
• Canal Telegram: t.me/clinica, sin cambios.
• Derogado: Cloud API, WABA, portfolio, verificación, templates, bots.
• Pendiente, sin resolver: [usuario]/sonrisa-inference sigue en CPU sin ZeroGPU.
• Siguiente acción: desplegar el template y leer el wrangler.jsonc real para confirmar bindings y model ID. Es la única incógnita técnica que queda.

Facts verificados contra

• faq.whatsapp.com/1182985198951186: “WhatsApp will not give your number to a business, and our policies prohibit businesses from contacting you on WhatsApp without first receiving your approval to do so.”
• developers.cloudflare.com/workers-ai/platform/pricing: “included in both the Free and Paid Workers plans”; “10,000 Neurons per day at no charge”; “$0.011 per 1,000 Neurons”; lista de modelos que exigen Paid
• developers.cloudflare.com/changelog/post/2026-07-28-models-require-workers-paid/: Kimi K2.6, Kimi K2.7 Code y GLM-5.2 devuelven 403 (error 5035) en Free; “Workers Paid plan starts at $5 per month”
• developers.cloudflare.com/workers/platform/pricing: mínimo de $5 USD/mes en Paid; “There are no additional charges for data transfer (egress) or throughput (bandwidth)”
• developers.cloudflare.com/pages/functions/pricing: “On both free and paid plans, requests to static assets are free and unlimited”
• developers.cloudflare.com/workers/observability/logs/workers-logs/: Free 200,000 eventos/día con 3 días de retención; Logpush solo en Paid