Cómo auditar un bot de trading: registros, alertas y trazabilidad

Cuando un bot de trading hace algo inesperado, lo que se ve suele ser el final de una cadena: datos que llegaron, una regla que se activó, una orden que salió, una respuesta del broker y, a veces, una persona que intervino. Sin registros suficientes, reconstruir esa cadena depende de la memoria y de capturas sueltas. Auditar un bot es poder responder, con evidencia, qué pasó, por qué y quién decidió qué.

Esta guía explica qué debe poder responder un registro, cómo leer marcas de tiempo y alertas, qué conservar y cómo revisar un incidente. Usa como ejemplo los controles que declaran los bots de C-Tech, para ver qué se puede auditar en la práctica. No es una recomendación ni una promesa de resultados.

Contenido educativo para personas adultas. No es asesoramiento financiero. Operar con bots implica riesgo de pérdida de capital y ninguna cifra pasada garantiza resultados futuros. Actualizado el 2 de noviembre de 2026.

La auditoría se diseña antes del incidente

Registrar después de un problema produce una historia incompleta: algunos datos se sobrescriben y ciertos eventos solo existen unos segundos. Por eso conviene decidir antes qué eventos importan, cuánto tiempo se guardan, quién puede consultarlos y cómo se protege su integridad. El marco de ciberseguridad del NIST incluye la detección y el monitoreo continuo entre sus funciones, y su guía de respuesta a incidentes recomienda preparar la respuesta antes de que ocurra el incidente, no durante.

Qué debe poder responder un registro

Una entrada útil ayuda a contestar al menos cinco preguntas: cuándo ocurrió el evento, qué componente lo originó, qué dato o regla intervino, cuál fue la respuesta del sistema y qué persona revisó el caso, si la hubo. Las guías de registro de OWASP siguen la misma lógica: cuándo, dónde, quién y qué. Un registro no necesita capturar todo: la acumulación indiscriminada crea ruido, cuesta dinero y puede exponer datos sensibles.

Un ejemplo: qué controles declaran los bots de C-Tech y qué hay que auditar de cada uno

Un control solo es auditable si se puede comprobar que actuó. Esto es lo que declaran las fichas y páginas de producto, y la pregunta de auditoría que se desprende de cada control:

• Adamantium. Permite fijar un límite de drawdown, en porcentaje o en dinero. Según su ficha técnica, cuando se supera puede responder de cuatro maneras: detener nuevas operaciones, cerrar las posiciones abiertas, detener el bot por completo o esperar 24 horas antes de volver a operar. Además controla el spread máximo antes de abrir, el horario, el margen libre mínimo y el número máximo de operaciones, y anota internamente el beneficio y la pérdida flotantes máximos. Pregunta de auditoría: ¿qué respuesta estaba configurada cuando se superó el límite y qué hizo realmente el bot?
• Scalper X. Declara take profit, stop loss y trailing stop, límites de lote, horario y número de operaciones, cierre global por equity y una protección del equity con límites máximos de pérdida; al alcanzarlos puede detener nuevas operaciones o cerrar posiciones. Pregunta: ¿el cierre global actuó al nivel configurado, o el equity lo superó antes?
• Alpha Bot. Según su ficha técnica, coloca órdenes pendientes en los extremos de un rango y, al activarse una, elimina la contraria; usa stop loss y trailing stop, con un porcentaje de riesgo por operación que elige la persona usuaria. Pregunta: ¿el registro muestra tanto la orden activada como la eliminación de la opuesta?

Hay un límite que conviene decir con claridad: las fichas describen los controles, pero no publican un formato de registro. Qué queda anotado en las pestañas «Expertos» y «Diario» de MetaTrader depende de la plataforma y de cómo esté programado cada bot. Por eso, ante cualquier proveedor, la pregunta correcta no es «¿tiene controles?» sino «¿cómo compruebo que actuaron?».

Marcas de tiempo: cuándo ocurrió de verdad

La hora del evento no siempre es la hora del registro: una orden puede ejecutarse en un momento y anotarse después. Además, los registros pueden usar horas distintas: la del equipo, la del servidor del broker o la del VPS. Si dos fuentes no usan la misma referencia, un evento posterior puede parecer anterior y desviar toda la investigación. Conviene comprobar qué hora usa cada registro y, cuando sea posible, una referencia común con su desfase explícito. El formato de RFC 3339 existe para eso: fecha, hora y desfase respecto a UTC en una sola cadena.

Una hora ordenada tampoco prueba la causa: saber que A ocurrió antes que B no demuestra que A provocó B.

Alertas, errores e incidentes no son lo mismo

Una alerta es una señal de que algo podría requerir revisión; un error es un fallo técnico; un incidente es un evento que afecta a la operación o a los fondos. Una alerta puede no ser un incidente, y un incidente puede ocurrir sin alerta. Al evaluar un sistema de alertas hay cuatro resultados posibles: alerta que acierta, alerta falsa (falso positivo), problema sin alerta (falso negativo) y ausencia correcta de alerta. La guía del NIST sobre sistemas de detección y prevención de intrusiones trata esta distinción: muchas alertas falsas llevan a ignorarlas, y pocas alertas pueden esconder problemas reales. Una tasa de aciertos sola no dice cuál de los dos errores es más frecuente.

Versiones y cambios: qué reglas corrían en ese momento

El mismo dato puede producir respuestas distintas después de un cambio de reglas o de parámetros. Un registro útil identifica la versión del bot y la configuración usada, y los cambios se documentan con fecha, motivo y responsable. La guía de gestión de configuración del NIST parte de esa idea: no se puede evaluar un comportamiento si no se sabe qué configuración lo produjo. Atribuir una mejora o un fallo a una versión sin ese historial es una conclusión sin prueba.

Qué conservar, cuánto tiempo y cómo comprobar que no cambió

Conservar tiene sentido cuando responde a una finalidad: detectar fallos, revisar decisiones, comprobar cambios, resolver una disputa o cumplir una obligación legal. El plazo depende de esa finalidad y de las obligaciones aplicables, no de una cifra copiada de otro sitio. La guía del NIST sobre gestión de registros recomienda definir de antemano qué se genera, cuánto se guarda y cómo se protege. Dos precauciones: no conservar datos personales o credenciales que no hagan falta y limitar quién puede consultar los registros.

Para comprobar que un archivo no cambió se usa una huella hash: un resumen digital del contenido que cambia si el contenido cambia. Una huella igual indica que la copia coincide con la referencia con la que se compara. No prueba que los eventos descritos sean ciertos, que el registro esté completo ni quién lo generó: un archivo parcial puede conservar su huella sin cambios.

Revisión humana: un panel en verde no es una prueba

Un sistema no evalúa por sí solo si su fuente de datos cambió o si una regla dejó de ser apropiada. Tampoco conviene dar demasiada autoridad a una salida automática solo porque es automática: un panel sin alertas puede significar que todo va bien o que la alerta no está bien definida. La respuesta responsable ante una duda es pausar, comparar fuentes y reconocer que no toda afirmación se puede verificar de inmediato. La CFTC lo recuerda en su aviso sobre bots de trading con inteligencia artificial: la tecnología no puede anticipar cambios repentinos del mercado, y un historial ordenado no es evidencia de capacidad predictiva.

Lista de verificación para revisar un incidente

1. ¿Cuándo ocurrió, y en qué hora está cada registro?
2. ¿Qué versión y qué configuración tenía el bot?
3. ¿Qué dato o condición activó la regla?
4. ¿Qué control debía actuar y actuó? ¿Qué respuesta tenía configurada?
5. ¿Qué respondió el broker y con qué retraso?
6. ¿Hubo una alerta? Si no la hubo, ¿debía haberla?
7. ¿Los registros están completos para el periodo, y se puede comprobar que no se modificaron?
8. ¿Quién intervino y qué decidió, y quedó documentado?

Para evaluar cualquier cifra de rendimiento que se presente junto a un registro, ayudan las 7 preguntas antes de creer una cifra de rentabilidad. Y para ver estos controles comparados entre bots, las características de un bot de trading.

Preguntas frecuentes

¿Qué diferencia hay entre monitoreo y registro?

El monitoreo observa el estado del sistema mientras funciona; el registro conserva la evidencia para revisar lo ocurrido después. Se necesitan los dos: el primero detecta, el segundo permite reconstruir.

¿Cuánto tiempo deben conservarse los registros?

Depende de la finalidad (revisión técnica, disputas, obligaciones legales) y de las normas aplicables. No existe un plazo universal; lo importante es fijarlo de antemano y proteger los datos mientras se conservan.

¿Un historial completo demuestra que el bot funciona bien?

No. Demuestra lo que ocurrió y, si es íntegro, permite revisarlo. No prueba que la estrategia sea adecuada ni que los resultados vayan a repetirse.

¿Qué revisar primero ante una alerta crítica?

Cuándo ocurrió, qué regla la activó, si el control que debía actuar actuó y si los datos de entrada eran correctos, antes de sacar conclusiones sobre el mercado.

¿Una huella hash prueba que un registro es verdadero?

No. Indica que una copia coincide con una referencia. La veracidad, el origen y la exhaustividad del registro necesitan otra evidencia.

Fuentes

• NIST: Cybersecurity Framework 2.0 (CSWP 29)
• NIST SP 800-61 rev. 3: guía de respuesta a incidentes
• NIST SP 800-92: guía de gestión de registros
• NIST SP 800-94: guía de sistemas de detección y prevención de intrusiones
• NIST SP 800-128: gestión de configuración
• OWASP: Logging Cheat Sheet
• IETF RFC 3339: fecha y hora en Internet
• CFTC: Customer Advisory «AI Won’t Turn Trading Bots into Money Machines»
• Páginas de producto y fichas técnicas de Adamantium, Scalper X y Alpha Bot.