Solo observación es diseño, no un interruptor de política

Infraestructura solo observación significa que tu plataforma comercial puede leer telemetría, calcular diagnósticos y enviar alertas, pero no puede cerrar operaciones, modificar overrides ni ejecutar acciones heredadas de apply. No es un interruptor de marketing: es una decisión de arquitectura que limita la superficie de ataque y la responsabilidad legal.

En trading algorítmico, la tentación de anadir un botón de pánico remoto es comprensible. Sin embargo, cada ruta mutante es un vector de error humano, compromiso de credenciales o bug de despliegue. Solo observación fuerza a que las acciones de riesgo permanezcan en el terminal bajo control del operador o del EA autorizado.

Los equipos que gestionan flotas MT5 suelen subestimar cuantas rutas heredadas existen en un monolito comercial: cierre de posiciones, cambios de modo, borrado de registros, ajustes tácticos. Un middleware de observación debe bloquear esas rutas de forma centralizada cuando ObservationOnly=true, devolviendo respuestas consistentes y auditables.

La observación no implica pasividad. Puedes tener alertas agresivas, dashboards en tiempo casi real, correlación multi-cuenta e informes de cumplimiento. Lo que no puedes hacer es mutar el estado de trading desde la API pública. Esa linea protege tanto al proveedor SaaS como al trader que confía en el servicio.

Para prop firms y cuentas fondeadas, solo observación demuestra independencia: la herramienta de monitorización no compite con el EA ni interviene en ejecución. Eso reduce preguntas sobre copia oculta, latencia artificial o manipulación remota durante evaluaciones.

Implementar solo observación exige pruebas automatizadas. Cada ruta protegida debe tener un test que confirme HTTP 403 en modo observación y comportamiento esperado en entornos internos no comerciales. Sin tests, un refactor puede reabrir endpoints peligrosos sin que nadie lo note.

Los operadores deben entender la diferencia entre alerta y acción. Una alerta de drawdown elevado invita a revisar el terminal; no cierra operaciones automáticamente. Entrenar al equipo en ese matiz evita falsas expectativas y tickets de soporte innecesarios.

También impacta el diseño de integraciones. Agentes de telemetría deben ser unidireccionales. Dashboards deben usar GET. Webhooks de alerta pueden ser salientes, pero nunca deben aceptar comandos de retorno que alteren cuentas. Piensa en observación como lectura certificada del estado, no control remoto.

La trazabilidad mejora porque cada intento de mutación bloqueada puede registrarse. Eso crea evidencia de que la plataforma rechazo acciones no permitidas, útil en revisiones de seguridad y auditorías de terceros.

Quantisentry mantiene ObservationOnly=true en V1 comercial. Sentinel Cloud expone bootstrap, telemetría y diagnósticos públicos mientras el middleware comercial bloquea rutas protegidas. Es el equilibrio correcto para SaaS de monitorización antes de fases futuras con acciones explicitamente autorizadas.

Por que no basta con prometer no operar

Fail-closed en código, no en documentación

Prometer que no operareis es fácil; demostrarlo en código es lo que importa. Un middleware centralizado que evalua cada request contra una lista de rutas protegidas elimina ambiguedad. Los clientes pueden verificar con herramientas standard que POST y DELETE a rutas de apply fallan de forma predecible.

La validación de configuración debe lanzar error si alguien intenta desactivar ObservationOnly en builds comerciales. Defensa en profundidad evita despliegues accidentales con permisos excesivos.

Cuando considerar acciones mutantes

Solo después de fases explícitas con auth fuerte, auditoría, modos WARN_ONLY y aprobación del operador deberían abrirse acciones mutantes selectivas. Hasta entonces, observación pura reduce riesgo reputacional y operativo mientras construyes confianza en la telemetría.