WhatsApp multi-cliente: modelo de tenancy + anti-extracción (2026-09-26)

Contexto: nef quiere “una cuenta de WhatsApp multi-proyecto, despliegue por cliente (web/WhatsApp + su corpus)“. Parte de [CREDENCIAL].md (RAG por cliente para clínicas dentales). En Meta no hay nada creado todavía.

1. Transporte: no hay alternativa legítima

El transporte es Meta WhatsApp Cloud API. Las únicas otras opciones son reverse-engineered (Baileys, whatsapp-web.js, WAHA): violan ToS, se banean por número, y no son presentables ante un negocio que te paga. No son una opción de arquitectura, son una opción de Qi.

Y para anti-extracción la oficial es la mejor postura, no la peor:

• El harness (chunking, retrieval, rerank, prompt) vive en infra tuya. El cliente nunca ve código, ni prompts, ni pesos. Solo un número y una URL.
• El WABA y los números se registran en tu business portfolio → conservas la cuenta, el historial y la capacidad de migrarlos. Si el WABA viviera en el portfolio del cliente, en el churn te quedas sin nada.
• El acceso al corpus nunca pasa por Meta: el bot responde, no entrega documentos. Meta es el teléfono, no el warehouse.

2. Tres hechos que mandan en el diseño (verificados en docs de Meta)

1. Cap de números: 2 iniciales → 20 al verificar. Un business portfolio nuevo empieza con 2 números registrados. Sube a 20 automáticamente si el negocio se verifica o si llegas a 2,000 mensajes. Con 2 números tienes 2 clientes simultáneos, no “multi-proyecto”. La verificación del negocio no es burocracia, es el desbloqueo comercial del producto.
2. El registro es 100% por API. No se puede registrar un número desde WhatsApp Manager ni desde el App Dashboard. El flujo es: añadir el número al WABA + verificar propiedad (código) → POST /<PHONE_NUMBER_ID>/register con messaging_product: "whatsapp" y pin de 6 dígitos. Límite: 10 requests de registro por número cada 72h (error 133016 si lo excedes).
3. México NO tiene data localization. Regiones disponibles: APAC, Europe EU, LAM (BR, ZA, EG, SA, AE), NORAM (solo Canadá). Para una clínica en México Esto es un hecho de cumplimiento, no de preferencias: los datos del paciente (síntomas, citas, RFC) se almacenan en región de Meta que no puedes fijar a MX. El corpus lo mantienes en tu infra (D1/Vectorize/R2 bajo tu cuenta) y a Meta solo sale la respuesta.

3. Dos bombas de fecha (verificadas)

• 1-oct-2026 — se cobra el mensaje de servicio. Anunciado el 1-jul-2026. Hoy los replies del bot dentro de la ventana de 24h son gratis; a partir del 1-oct se cobran al mismo precio que utility/authentication por mercado, con 1,000 mensajes de servicio gratis por mes y por número de negocio (no rollover, resetea mensual). Esto es exactamente el caso de uso del RAG bot: 1,000 gratis por número/cliente/mes es el presupuesto de diseño. 5 días.
• 15-oct-2026 — Embedded Signup v2 queda deprecado. Si más adelante usas Embedded Signup para que el cliente registre su propio número, hay que ir a v4.

4. Modelo de tenancy: 1 app, 1 WABA, N números, 1 webhook

Lo explícito porque la intuición con “multi-proyecto” es montar N workers. No.

Meta app (1)  ── WABA (1)  ── phone_number_id × N  (un número por cliente)
                                    │
        webhook (1 endpoint) ────────┘
                                    │  resolve por metadata.phone_number_id
                                    ▼
                            Worker (1)  ── tenant_id
                                    │
                    ┌───────────────┴────────────────┐
              Vectorize/D1                     RAG harness
          namespace = tenant_id              (Space HF o lo que sea)
          corpus vive en TU cuenta

Un solo Worker, un solo endpoint, un solo token. El webhook de messages trae metadata.phone_number_id y metadata.display_phone_number: eso es el tenant. Un mapa phone_number_id → tenant_id en D1 resuelve todo. Cada cliente nuevo es una fila, no un deploy.

Por qué NO un worker por cliente: N deploys, N dominios, N secretos, N Surface de ataque, y un cliente con un bug tumba a todos. El aislamiento real lo da el namespace del corpus, no el proceso.

5. Anti-extracción: los 4 vectores reales

El transporte NO es el vector. Estos sí, y son los que hay que diseñar:

Vector	Qué es	Control
El bot como oráculo del corpus	50 preguntas reconstruyen los documentos del cliente. Este es el fuga real.	Respuestas cortas, nunca verbatim. Tope de cita (~25 palabras). Sin IDs de chunk, sin nombres de archivo, sin listar documentos. Rate limit por usuario. Rechazar “repite el documento completo”.
Fuga de prompt	En WhatsApp la gente conversa más que en web: “cuales son tus instrucciones”	Prompt como dato, nunca eco. Detectar meta-instrucciones entrantes y responder con fallback. No loguear el system prompt a un destino que el cliente pueda leer.
Claves en el cliente	Widget web con tu token de API = token extraíble	Todo por Worker. El browser nunca habla con Meta ni con tu harness. Cero secretos en el bundle.
Contractual	Churn: ¿quién tiene el WABA, el corpus, el historial?	WABA en tu portfolio. Corpus en tu cuenta, nunca en el repo del cliente. Cláusula explícita en contrato.

El control #1 es el que de verdad importa y es el más fácil de hacer mal: un RAG sin tope de citas es un SELECT * con interfaz de chat.

6. Runbook: lo que tienes que hacer tú (no puedo crear tu portfolio)

Meta exige documentos legales del negocio y verificación con ---------------------------------------------------------------------------- representante. Eso es in-persona/legal; no lo puedo automatizar.

1. Crear Business Portfolio en business.facebook.com con los datos de tu negocio (o el de una empresa que factura).
2. Verificar el negocio (documento de identidad del representante + registro fiscal del negocio). Desbloquea el cap de 20 números. Empieza aquí.
3. Crear la App de Meta → agregar producto WhatsApp → obtener el token permanente con permisos whatsapp_business_management y whatsapp_business_messaging. Guárdalo en un secret, no en un repo.
4. Crear el WABA y añadir el primer número vía WhatsApp Manager (verificar propiedad con código). Luego POST /<PHONE_NUMBER_ID>/register.
5. Poner el webhook de un solo endpoint y suscribir messages.
6. Meter el phone_number_id como tenant_id en D1. Empezar con 1 cliente.

7. NO hacer todavía

• NO Embedded Signup todavía (v2 muere el 15-oct; si se usa, v4). Para 1-2 clientes, alta manual es más rápida.
• NO multi-tenant billing / portal de clientes. No hay ni un cliente todavía.
• NO Baileys “para probar”. Un número de producción en Baileys se quema.
• NO mandar plantillas de marketing para validar. Cargan. Valida con la ventana de 24h (service, gratis hasta el 30-sep) y mide.

8. Estado / siguiente paso

• Requiere: pasos 1-2 del runbook (verificación del negocio). Es tiempo de Meta, no de código. Días, no horas.
• Mientras tanto sí se puede construir: el Worker con routing por phone_number_id, el mapa de tenants en D1, y los controles anti-oráculo del §5 (que son transport-agnostic y se testifican con un payload de webhook falso).
• El Space [usuario]/sonrisa-inference sigue en CPU sin ZeroGPU (ver [CREDENCIAL].md). Es el otro bloqueador del mismo piloto, independiente de esto.

Facts verificados contra

• developers.facebook.com/docs/whatsapp/cloud-api/phone-numbers (cap 2→20)
• developers.facebook.com/docs/whatsapp/cloud-api/reference/registration (registro solo por API, 10/72h, pin 6 dígitos)
• developers.facebook.com/documentation/business-messaging/whatsapp/pricing (per-message desde 2025-07-01; service de pago desde 2026-10-01, 1,000 gratis por número/mes; cero cambios Oct-2026 en utility/auth)
• developers.facebook.com/docs/whatsapp/solution-providers/phone-numbers/registering-phone-numbers (Embedded Signup v2 deprecado 2026-10-15; regiones de data localization)