Telegram Bot API frente a MTProto: la revisión empieza por los permisos
Compara Bot API y MTProto para supervisar grupos de Telegram: identidad de acceso, visibilidad de mensajes, custodia de credenciales, permisos y revocación.
- 01Primera capa: identificar al actor de Telegram
- 02Segunda capa: definir el alcance de los mensajes antes de hablar de funciones
- 03Tercera capa: separar el acceso del permiso para tratar datos
Señales que conviene observar
- La visibilidad de Bot API depende de los chats a los que se añade el bot, sus permisos y el modo de privacidad
- MTProto es un protocolo, no una identidad de usuario; este artículo compara un bot de Bot API con una implementación habitual basada en una sesión de usuario MTProto
- Una revisión de compra debe cubrir identidad, alcance de las fuentes, políticas, almacenamiento y revocación
Telegram Bot API y MTProto no son dos interfaces equivalentes que solo difieren en velocidad o comodidad. Bot API es la interfaz HTTPS de Telegram para bots. MTProto es el protocolo con el que los clientes de Telegram se comunican con sus servidores. Al evaluar una herramienta para supervisar grupos, las preguntas importantes son qué identidad se conecta, a qué fuentes puede acceder, qué almacena la aplicación y cómo se revoca el acceso.
La documentación de Bot API define una interfaz HTTP para crear bots. La documentación oficial de MTProto describe el protocolo cliente-servidor que utilizan las aplicaciones de Telegram. MTProto también admite la autorización de bots; no implica por sí mismo una cuenta de usuario. Para concretar la comparación, este artículo enfrenta la identidad de un bot de Bot API con una sesión habitual de usuario autorizada mediante MTProto, no un protocolo con una identidad.
Para el arquitecto, descubrir un día después de la revisión de seguridad que el diseño propuesto utiliza en realidad una sesión de usuario puede significar que la ventana de pruebas controladas ya se cerró y que el equipo tendrá que esperar al siguiente ciclo para validar el método de conexión.
Antes de una revisión formal, pide al proveedor que demuestre cómo trataría tres mensajes simulados. Son entradas sintéticas, no mensajes de un grupo real ni resultados del producto:
«¿Alguien gestiona devoluciones locales en Alemania?»
«Gestionamos la preparación y el envío de pedidos y podemos preparar un presupuesto».
«Todavía no necesito presupuestos. Pregunto por un cliente; no están definidos ni el volumen ni la ciudad».
Pregunta qué mensajes entrarían en el sistema con la configuración real, si se conservarían las relaciones entre respuestas y si el rol y el volumen seguirían figurando como datos desconocidos. El modo de privacidad del bot, su condición de administrador y el hecho de que un mensaje responda o no al bot pueden cambiar el resultado. No deduzcas la cobertura solo por el nombre de la arquitectura.
Primera capa: identificar al actor de Telegram
Una integración con Bot API utiliza la identidad de un bot
Un bot es una cuenta independiente de Telegram controlada mediante un token. Debe añadirse al grupo objetivo y los mensajes que recibe dependen de los permisos del grupo, su condición de administrador y el modo de privacidad. Las preguntas frecuentes sobre bots explican qué categorías de mensajes reciben los bots según la configuración.
Esta arquitectura hace visible al actor. Los miembros pueden ver que el bot se ha unido y un administrador puede retirarlo. Su límite es igual de importante: un grupo al que el bot no se ha unido queda fuera de su alcance. Bot API no sirve para leer todo el historial de la cuenta de una persona ni conversaciones privadas ajenas.
En esta comparación, la vía MTProto utiliza una sesión de usuario autorizada
Un cliente MTProto suele utilizar un API ID, un API hash, el inicio de sesión del usuario y una sesión persistente. Su visibilidad técnica está limitada por la cuenta autorizada. Puede parecerse más a un cliente convencional, pero también aumenta la responsabilidad operativa: alguien debe controlar las credenciales de acceso, los archivos de sesión, la verificación en dos pasos, la respuesta ante inicios de sesión inusuales y la baja de la cuenta.
Utilizar una sesión de usuario no autoriza a una aplicación a reproducir todas las acciones que puede realizar esa persona. El comprador debe exigir que el proveedor indique si su implementación puede enviar mensajes, unirse a grupos, recuperar historial o sincronizar contactos, y que desactive cualquier acción innecesaria para una revisión de solo lectura. La visibilidad técnica tampoco demuestra que exista una finalidad de tratamiento lícita o permitida.
Segunda capa: definir el alcance de los mensajes antes de hablar de funciones
| Punto de revisión | Arquitectura con Bot API | Arquitectura con cliente MTProto | Evidencia que conviene solicitar |
|---|---|---|---|
| Identidad de acceso | Una cuenta de bot independiente | Una sesión de usuario autorizada | La cuenta exacta y la persona responsable de ella |
| Alcance de grupos | Grupos en los que está presente el bot y puede recibir actualizaciones | Grupos a los que puede acceder el usuario y que la aplicación selecciona de forma deliberada | Una lista explícita de grupos permitidos, no la sincronización predeterminada de todas las conversaciones |
| Chats privados | No debe venderse como acceso a las conversaciones privadas de un empleado | Una sesión de usuario puede exponer técnicamente chats visibles para esa cuenta, por lo que el producto debe excluirlos | Un control documentado del producto y de la arquitectura que excluya los chats privados |
| Mensajes anteriores | Bot API no ofrece un método general para recuperar un historial arbitrario del grupo; el bot recibe principalmente las nuevas actualizaciones permitidas mientras está presente | Las consultas de historial de un cliente de usuario dependen de los permisos de la cuenta, los métodos del cliente y los límites del producto | Si la incorporación recupera historial, con qué fundamento y hasta qué fecha |
| Revocación | Retirar el bot, revocar el token o cambiar sus permisos | Revocar la sesión, retirar la autorización de la cuenta y eliminar las credenciales | Cuánto tarda en detenerse el tratamiento y en eliminarse las copias conservadas |
Rechaza afirmaciones como «admite todos los grupos» o «sincronización completa» si omiten al actor. Una respuesta verificable identifica la cuenta, la persona que la aprueba, los grupos permitidos, la fecha de inicio, los campos tratados y la finalidad empresarial.
Tercera capa: separar el acceso del permiso para tratar datos
Supongamos que un vendedor pertenece a un grupo sectorial y puede leer sus mensajes en el teléfono. Eso demuestra que una cuenta puede entrar en el grupo. No demuestra que las reglas del grupo permitan el acceso automatizado, que los miembros esperen un almacenamiento prolongado, que la empresa pueda transferir el contenido a un encargado del tratamiento o que la legislación aplicable permita el uso previsto.
Las Condiciones de servicio de la API de Telegram son una capa obligatoria de la revisión, pero no la única. Las Condiciones de licencia de contenido vigentes restringen expresamente el scraping, la indexación, la recopilación y la agregación, así como el uso del contenido para entrenar, ajustar, validar, desarrollar, mejorar, comparar o desplegar sistemas de inteligencia artificial o aprendizaje automático. La excepción descrita es limitada: todos los usuarios afectados deben otorgar de manera individual un consentimiento explícito, informado, afirmativo y continuado para utilizar ese contenido concreto en ese chat, canal u otro contexto no global concreto. El consentimiento no se traslada a otro contexto. Una revisión humana no corrige un tratamiento no permitido. También deben revisarse seguridad, privacidad, contratos y legislación aplicable; consulta los límites de datos en la supervisión de Telegram y la gobernanza de fuentes.
Cuarta capa: asignar la custodia de cada credencial
Los tokens de bot, API hashes, códigos de acceso y archivos de sesión no deberían aparecer en registros rutinarios, capturas del equipo de soporte ni documentos compartidos. La revisión de compra debe establecer:
- si cada credencial la crea el cliente o el proveedor y dónde se almacena;
- qué roles pueden recuperarla y protegerla, además de rotarla o revocarla cuando el mecanismo lo permita;
- si las pruebas utilizan una cuenta y un grupo independientes;
- qué sucede cuando un empleado deja la empresa o termina el contrato con el proveedor;
- si quedan registrados los accesos correctos, los fallidos y los cambios de permisos.
No es un mero apéndice para el equipo de seguridad. Una custodia deficiente impide que el equipo de operaciones de ventas demuestre que un mensaje candidato procede de una fuente aprobada y dificulta detener el tratamiento cuando un grupo sale del alcance autorizado.
Quinta capa: exigir una salida que permita volver a la fuente
Sea cual sea la arquitectura de acceso subyacente, el vendedor no debería recibir solo un resumen generado por IA. Un registro verificable necesita el grupo de origen, el texto original, la marca de tiempo visible, las respuestas relevantes y las transformaciones importantes, como traducción o deduplicación. Sin esos elementos, ni siquiera una integración técnicamente completa puede mostrar si «necesito un presupuesto» procede de un comprador, de la promoción de un proveedor o de un reenvío antiguo.
La lista de campos para pasar de Telegram al CRM y la guía sobre procedencia de los mensajes explican con más detalle los requisitos de entrega y auditoría.
Termina la revisión de arquitectura con cuatro preguntas
No basta con preguntar «¿admite Bot API o MTProto?». Formula estas cuatro preguntas:
- ¿Qué identidad visible se conecta y quién la controla?
- ¿Qué conversaciones se tratan de forma predeterminada y cómo se excluyen los chats privados y los grupos no seleccionados?
- ¿Durante cuánto tiempo se conservan los mensajes originales, las fuentes y el contexto, y quién puede consultarlos?
- Tras la revocación, ¿cómo se detienen o eliminan el tratamiento activo, las cachés y las copias exportadas?
Si un proveedor no puede responder en términos de identidad, listas de grupos permitidos, campos y plazos, todavía no dispone de una arquitectura de permisos lista para una evaluación de compra. TOP Prospect procesa únicamente grupos que el usuario conecta y selecciona de manera deliberada y a los que tiene derecho a acceder. No lee chats privados ni grupos no autorizados, no contacta con miembros y no confirma oportunidades comerciales. Aun así, el comprador debe verificar el método de acceso real, la base conforme a las condiciones aplicables y los controles de datos, en vez de deducir la implementación a partir de este artículo.
Preguntas frecuentes
¿Bot API o MTProto pueden leer todos los mensajes de Telegram?
Ninguna arquitectura creíble debería describir cualquiera de las dos opciones como acceso a todos los mensajes de Telegram. Un bot solo recibe las actualizaciones que tiene permiso para recibir. Un cliente MTProto también está limitado por la cuenta autorizada y los mecanismos de acceso de Telegram. Ninguno da acceso a chats privados ajenos ni a grupos no autorizados.
¿Iniciar sesión con la cuenta de Telegram de un empleado hace que la supervisión cumpla las normas?
No. La visibilidad de la cuenta es una condición técnica, no una conclusión de cumplimiento. También deben revisarse las condiciones de la plataforma, las reglas del grupo, las políticas de la empresa, los contratos, la finalidad, la conservación y la legislación aplicable.
Fuentes y lecturas adicionales
Cómo se descubre una Signal que merece atención
La metodología muestra cómo Top Prospect encuentra y organiza Signals que conviene revisar, conserva el contexto original de Telegram, elimina duplicados y ayuda a decidir qué mirar primero. Tú decides si hacer seguimiento y qué hacer después.
