Las 25 reglas BESKAR para bots WhatsApp seguros (compliance Meta + LFPDPPP + anti-fraude)

BESKAR es el set de 25 reglas operacionales que evitan baneos Meta y fraudes en bots WhatsApp empresariales. Se organizan en 5 categorías: (1) Compliance Meta (ventana 24h, opt-in, anti mass blast, categorización templates, Quality Rating); (2) Anti-suplantación (identidad bot declarada, sin firma humana real); (3) Anti-fraude check-in (GPS, pHash fotos, face matching, EXIF); (4) LFPDPPP MX (aviso privacidad, consentimiento, derechos ARCO, retención, territorialidad); (5) Seguridad técnica (webhook signature, IP whitelist, rate limiting, strip URLs no allowlist, anti SQL injection).

Las 25 reglas BESKAR para bots WhatsApp seguros

BESKAR (Beskar es la aleación legendaria de Mandalore) es el set de reglas operacionales que Varela Insights aplica a cada bot WhatsApp en producción para evitar baneos Meta, fraudes, suplantación, leaks de datos y degradación de Quality Rating. Las 25 reglas se implementan como pre-flight checks automáticos antes de cada mensaje outbound y cada acción crítica.

Categoría 1 — Reglas Meta (compliance regulatorio)

1. Ventana 24h respetada: verificar timestamp último inbound < 24h antes de mensaje libre. Si excede, requerir template aprobado.
2. Opt-in documentado: antes de mensaje Marketing, verificar registro de consentimiento en tabla opt_ins.
3. No mass blast: ningún script puede enviar >50 mensajes únicos en <5 minutos sin throttling.
4. Categorización templates correcta: Marketing solo para promocional, Utility solo para transaccional, Authentication solo para OTP.
5. Quality Rating monitoring: alert si rating baja a "Medium" o "Low" en Meta Business Manager.

Categoría 2 — Anti-suplantación

6. Identidad bot declarada: primer mensaje del bot en una conversación nueva debe declarar "Soy el asistente IA de [Empresa]" — NUNCA pretender ser persona humana específica.
7. Sin firma humana real: bot NO firma como "Atte. Mariana" si Mariana es persona real del equipo. Usar "Equipo Soporte" o "Asistente IA".
8. Reconocimiento explícito en TTS: si bot envía mensaje de voz, audio debe iniciar con "Soy el asistente de IA de [Empresa]".
9. No imitar voz/personalidad de persona específica: incluso si el cliente lo solicita, mantener identidad bot.
10. Disclaimer en escalamiento humano: mensaje claro cuando se transfiere a humano: "Te conecto con [nombre real] del equipo, está en línea".

Categoría 3 — Anti-fraude check-in/identidad

11. Verificación GPS coordenadas: para apps que requieren ubicación (asistencia, delivery), validar lat/lon vs ubicación esperada con tolerancia.
12. Verificación pHash de fotos: detectar fotos duplicadas/reciclar entre check-ins distintos.
13. Face matching contra referencia: verificar facial vs foto registrada en onboarding.
14. Detección manipulación EXIF: validar metadata foto (fecha, dispositivo) no manipulada.
15. Trust signals visible: watermark visible + SHA-256 del binario original guardado en DB para auditoría posterior.

Categoría 4 — Datos personales (LFPDPPP MX)

16. Aviso privacidad accesible: link visible en primer mensaje del bot.
17. Consentimiento explícito: antes de tratamiento datos sensibles, confirmar consent.
18. Derechos ARCO operacionales: el bot debe responder a "quiero eliminar mis datos" con proceso claro.
19. Retención clara: chat_memory tiene TTL configurado (30-90 días típico).
20. Infraestructura territorial MX: bot operado en VPS México o con cláusulas LFPDPPP equivalentes.

Categoría 5 — Seguridad técnica

21. Webhook signature validation: verificar firma Meta/Evolution antes de procesar payload (anti spoofing).
22. IP whitelist webhooks: aceptar solo IPs Meta (149.154.160.0/20, etc.) o Evolution dedicado.
23. Rate limiting per phone: max 30 mensajes/min from any source — anti spam attack.
24. Strip URLs no whitelisted: LLM puede generar URLs inventadas; nuclear strip URLs no en allowlist (sólo permitir maps.google.com, wa.me, dominios propios).
25. Anti SQL injection: nunca concatenar input usuario en queries SQL — siempre parameterized.

Implementación práctica

Las 25 reglas se implementan como un módulo Python beskar.py con funciones tipo can_send_message(), verify_optin(), strip_urls(), etc. El bot llama estas funciones antes de cada acción crítica. Si alguna falla, la acción se detiene y se loggea para auditoría.

Patrón anti-pattern típico: equipos que implementan reglas BESKAR "cuando haya tiempo". Resultado: 3-6 meses después, primer incidente serio (baneo Meta, leak datos, fraude check-in no detectado), y las reglas se implementan reactivamente con costo 10× mayor. Implementar BESKAR desde día 1 es prerequisito, no opcional.

Dr. Irving Varela — Ph.D, PMP Fundador de Varela Insights · Director de Estudios Aplicados GEO · Monterrey, México. Ver perfil completo →