Revisar las acciones de los empleados
Cómo registra Pilotbot las acciones del equipo para que propietarios y managers puedan ver quién hizo qué, cuándo y en qué cuenta.
Pilotbot Team
Autor
En esta página
- Arquitectura del registro: qué eventos supervisa Pilotbot
- Jerarquía de acceso: quién controla el registro
- Protección del sistema frente a la acción humana: cómo diferenciar los eventos
- Análisis de casos prácticos: 3 situaciones reales de negocio
- Caso 1. Traspaso de turnos sin discrepancias
- Caso 2. Investigación de una caída brusca de volumen
- Caso 3. Protección frente a manipulaciones no autorizadas
- Artículos relacionados
Escalar un negocio P2P siempre se enfrenta a un desafío clave: equilibrar la velocidad operativa del equipo con el control exhaustivo de riesgos. Cuando decenas de anuncios en Binance y Bybit son atendidos por varios operadores en múltiples turnos, el coste de la falta de coordinación se dispara. ¿Quién desactivó un anuncio en pleno pico de volumen nocturno? ¿Quién modificó el spread objetivo? ¿Fue un desajuste provocado por un fallo humano o se activó un mecanismo de protección del exchange?
Para resolver estas cuestiones, Pilotbot incorpora un registro integral de actividad del equipo (Audit Log). Se trata de la bitácora unificada de tu espacio de trading: cualquier modificación operativa relevante queda registrada con precisión de segundos, identificando al ejecutor, la cuenta de destino y el contexto de la acción.
Arquitectura del registro: qué eventos supervisa Pilotbot
El registro de actividad documenta todos los sucesos capaces de repercutir en los saldos, el estado de los anuncios o la seguridad de las cuentas. A diferencia de los registros técnicos convencionales, las entradas de auditoría en Pilotbot están estructuradas por entidades de negocio:
- Operaciones de automatización de anuncios — inicio del bot en una estrategia, parada manual, ajuste forzado de márgenes de precios o límites de orden.
- Calibración de estrategias y precios — actualización de fórmulas de recálculo dinámico, modificación de desfases (offsets) de market making y umbrales de beneficio mínimo.
- Gestión de cuentas de exchange — vinculación de claves API, modificación de permisos operativos y sincronización de saldos.
- Gestión de accesos y del equipo — envío de invitaciones, asignación y revocación de roles, reasignación de accesos a subcuentas concretas.
Cada apunte contiene cuatro elementos probatorios inseparables:
- Marca temporal (UTC / hora local) — instante exacto de ejecución de la acción.
- Iniciador (Actor) — nombre y correo electrónico del empleado responsable.
- Objeto modificado (Target) — ID del anuncio, exchange, par de divisas o entidad estratégica.
- Naturaleza del cambio (Diff) — valor inicial del parámetro y su nuevo estado tras la modificación.
Jerarquía de acceso: quién controla el registro
La información sobre las operaciones de todo el equipo representa un activo de gestión estrictamente confidencial. En Pilotbot se aplica con rigidez el principio de mínimo privilegio (Principle of Least Privilege):
| Rol en el sistema | Acceso al Audit Log del equipo | Finalidad y contexto |
|---|---|---|
| Propietario (Owner) | Acceso irrestricto total | Control estratégico, salvaguarda financiera y auditoría de alto nivel |
| Manager (Gestor) | Visualización completa del registro | Supervisión de turnos de trading, resolución de discrepancias y dirección operativa |
| Trader (Operador) | Acceso bloqueado | Enfoque exclusivo en la ejecución de órdenes y anuncios, sin distracciones |
| Observador (Viewer) | Acceso bloqueado | Supervisión analítica y estado del mercado únicamente en modo «read-only» |
| Auditor | Acceso bloqueado | Inspección de cuentas e informes conforme a los permisos asignados |
Esta compartimentación asegura que el registro de auditoría permanezca a salvo de manipulaciones y no genere fricciones internas entre los operadores de línea.
Protección del sistema frente a la acción humana: cómo diferenciar los eventos
Una de las mayores fuentes de estrés para el titular de un equipo P2P radica en discernir si un problema se debió a un error humano o a la intervención normal de los algoritmos de seguridad. En Pilotbot esta distinción es nítida:
- Acciones del personal — se etiquetan con la identificación personal del operador. Por ejemplo:
El Trader Carlos cambió el anuncio #48921 al estado OFFLINE. - Mecanismos automáticos de seguridad — se registran como eventos de protección del sistema (System / Circuit Breaker). Por ejemplo, si el exchange interrumpió la sesión WebSocket o el anuncio alcanzó un límite de parada en la propia plataforma, el sistema dejará constancia de que la desconexión obedeció a una respuesta algorítmica de seguridad.
De este modo sabrás con certeza si la parada nocturna de un anuncio fue decisión del trader de turno o si respondió a la activación del escudo protector ante una brecha repentina de precios en el mercado.
Análisis de casos prácticos: 3 situaciones reales de negocio
Caso 1. Traspaso de turnos sin discrepancias
En la operativa P2P continua, el turno de día transfiere el testigo al de noche. Gracias al registro de auditoría, el manager entrante evalúa en 30 segundos qué anuncios se han pausado, dónde se ajustaron los límites de tarjetas bancarias y qué cuentas han pasado a modo manual. Sin notas dispersas en Telegram: todo el historial queda reflejado en pantalla.
Caso 2. Investigación de una caída brusca de volumen
Si el volumen de transacciones de un turno cae un 40%, el gestor accede al registro y filtra por eventos de parada de automatización. Si se constata que un operador detuvo el recálculo de precios en dos estrategias clave a las 14:00 y olvidó reactivarlo, el origen del incidente queda esclarecido en segundos con datos irrefutables, no con conjeturas.
Caso 3. Protección frente a manipulaciones no autorizadas
Si un trader intenta ajustar por iniciativa propia el spread por debajo del umbral de rentabilidad saltándose la estrategia establecida, el registro capturará el cambio y la hora exacta. Esto infunde rigor en el equipo y destierra la excusa de atribuir un fallo a un supuesto «error de la plataforma».