Alertas en bots de trading: cómo interpretar falsos positivos y falsos negativos

Un falso positivo aparece cuando una alerta señala una condición que la referencia de evaluación no confirma. Un falso negativo ocurre cuando esa condición sí existe en la referencia, pero la alerta no la identifica. En bots de trading, estas categorías sirven para leer informes técnicos con cuidado. No describen por sí solas ganancias, pérdidas ni la conveniencia de una decisión financiera.

Antes de interpretar una cifra de aciertos hace falta saber qué se estaba intentando detectar. Una anomalía de datos, un mensaje duplicado y una interrupción son objetos de evaluación diferentes. Este artículo explica cómo leer esas distinciones y sus métricas con un ejemplo ficticio. No propone ajustes de un bot ni instrucciones para utilizar servicios financieros.

Primero hay que definir la condición examinada

La palabra «positivo» no significa bueno. Indica que el mecanismo de detección ha señalado la condición que se está buscando. «Negativo» significa que no la señaló. Para distinguir una detección correcta de un error necesitamos una referencia que permita clasificar los casos examinados, además de una definición de la condición.

Un informe podría evaluar si un registro contiene un campo de fecha ausente. Otro podría evaluar si una secuencia de mensajes está incompleta. Aunque ambos usen la palabra «alerta», sus cifras no serían directamente comparables. El nombre de la métrica no borra las diferencias entre la pregunta, los datos y el criterio de revisión.

Los cuatro resultados posibles

Si el sistema señala la condición y la referencia la confirma, se trata de un verdadero positivo. Si la señala y la referencia no la confirma, es un falso positivo. Si no la señala, pero la referencia sí la confirma, es un falso negativo. Cuando ninguno de los dos la identifica, el caso se clasifica como verdadero negativo.

NIST SP 800-94 describe falsos positivos y negativos en el contexto de detección de intrusiones. Aquí se emplea esa distinción para explicar la lectura de una evaluación, sin trasladar resultados de ciberseguridad al desempeño de un bot financiero. La publicación es de 2007 y no se presenta como una guía actual de implementación.

Las cuatro categorías dependen del criterio usado como referencia. Si no se conoce cómo se revisaron los casos, la tabla puede parecer completa y seguir siendo difícil de interpretar. Una etiqueta escrita por una persona tampoco demuestra que esa revisión sea correcta; debe reconocerse su alcance y la posibilidad de desacuerdo.

Un ejemplo ficticio con cien registros

Imaginemos una muestra inventada de cien registros. La revisión de referencia identifica veinte con una fecha ausente y ochenta sin ese problema. El mecanismo de alerta señala dieciocho de los veinte casos con el campo ausente. Los otros dos pasan sin aviso. Entre los ochenta restantes, ocho generan una alerta y setenta y dos no la generan.

El recuento queda así: dieciocho verdaderos positivos, ocho falsos positivos, dos falsos negativos y setenta y dos verdaderos negativos. Las cuatro cantidades suman cien. Este caso es exclusivamente didáctico; no proviene de C-Tech, de una herramienta comercial ni de una medición sobre personas. Tampoco representa una proporción esperable de errores en un sistema real.

La muestra tiene veintiséis alertas en total: las dieciocho confirmadas y las ocho que la referencia no confirma. Esa cantidad será el denominador de una pregunta distinta de la que usa los veinte casos con fecha ausente. Mantener los denominadores separados es esencial para entender por qué pueden aparecer porcentajes diferentes sin que exista una contradicción.

Sensibilidad y precisión responden preguntas diferentes

En el ejemplo, la sensibilidad pregunta qué proporción de los veinte casos con fecha ausente fue detectada. Son dieciocho de veinte, es decir, un noventa por ciento. La precisión pregunta qué proporción de las veintiséis alertas correspondía a un problema confirmado por la referencia. Son dieciocho de veintiséis, aproximadamente un sesenta y nueve por ciento.

Ambos cálculos se refieren a la misma muestra ficticia. El primero se concentra en los casos que tenían la condición; el segundo, en los casos que generaron alertas. No son porcentajes de rentabilidad ni probabilidades de obtener un resultado financiero. Tampoco permiten anticipar qué ocurrirá con otra muestra.

La proporción global de clasificaciones correctas sería noventa de cien: dieciocho verdaderos positivos más setenta y dos verdaderos negativos. Aunque también da un noventa por ciento, responde una tercera pregunta. Un informe que solo diga «noventa por ciento de aciertos» deja oculto qué denominador utilizó y qué errores quedaron fuera de esa descripción.

La frecuencia de la condición cambia la lectura

La utilidad de una métrica depende de la composición de la muestra. Si un conjunto tiene pocos casos con la condición examinada, una clasificación global puede estar dominada por los casos sin esa condición. Una cifra alta de clasificaciones correctas podría convivir con una detección deficiente de los casos que interesaba encontrar.

Como contraste puramente lógico, si un conjunto ficticio contiene un único caso con una condición entre cien, un mecanismo que nunca emite alertas clasificaría correctamente los otros noventa y nueve. Sin embargo, no habría detectado el caso buscado. El ejemplo no recomienda ese comportamiento; muestra por qué una cifra global aislada puede ocultar un fallo relevante.

Los casos inciertos no deberían desaparecer del informe

A veces la referencia no permite decidir si una condición estaba presente. Puede faltar parte del registro, existir desacuerdo entre revisiones o no haberse definido una excepción. Forzar esos casos dentro de una clasificación definitiva hace que el resultado parezca más preciso de lo que permite la evidencia.

Un informe claro puede separar los casos no evaluables y explicar cómo afectan al alcance del cálculo. Si solo se revisaron los eventos que ya tenían alerta, no se conoce qué ocurrió en los casos silenciosos. Por lo tanto, esa muestra no basta para estimar los falsos negativos del conjunto completo. El límite es del método de evaluación, no solo de la presentación.

Una alerta también necesita contexto

OWASP propone registrar contexto de los eventos y documentar criterios coherentes de clasificación. En la lectura de un informe, esa referencia recuerda que la severidad declarada, la confianza analítica y el resultado observado no son conceptos intercambiables. Un mensaje puede ser urgente y seguir pendiente de confirmación.

La lectura sobre registros y monitoreo ante un incidente amplía la diferencia entre un aviso y una explicación de lo sucedido. Una alerta puede justificar una revisión documental, pero no demuestra por sí sola la causa de un incidente. Su significado debe situarse dentro del alcance del expediente y de las relaciones que estén respaldadas.

Qué preguntar antes de comparar dos evaluaciones

Para interpretar una comparación interesa conocer si ambas evaluaciones usaron la misma condición, el mismo criterio de referencia y muestras comparables. También importa saber cómo trataron los casos inciertos y si hubo registros repetidos. Sin esa información, atribuir una diferencia a una mejora del mecanismo sería una inferencia sin respaldo suficiente.

Esto es distinto del sesgo de quien lee una señal. Aquí se examina cómo se cuenta una detección frente a una referencia. La explicación sobre límites de la automatización y la IA ayuda a mantener esa separación: un sistema puede seguir reglas fijas, no utilizar IA y aun así requerir una evaluación técnica bien delimitada.

Un control técnico no predice el mercado

La CFTC advierte que la IA no puede anticipar el futuro ni los cambios repentinos del mercado. Una alerta sobre datos o errores no elimina ese límite. La evaluación de detección describe una tarea concreta y un conjunto de casos; no demuestra que una estrategia sea adecuada ni que produzca resultados financieros determinados.

Una conclusión proporcionada indica qué se evaluó, con qué referencia y qué parte permanece incierta. Puede reconocer una detección correcta sin convertirla en una garantía general. Leer los denominadores y las exclusiones suele aportar más claridad que comparar porcentajes llamativos sin contexto.

Preguntas frecuentes

¿Un falso positivo significa que el bot perdió dinero?

No. La categoría depende de la condición técnica evaluada y del criterio de referencia. No informa por sí misma sobre una ganancia o una pérdida. Mezclar detección de eventos y resultado financiero cambia el significado de la evaluación.

¿Una sensibilidad alta demuestra que todas las alertas son correctas?

No. La sensibilidad se calcula sobre los casos con la condición. Para conocer qué proporción de alertas fue confirmada hace falta otro denominador. Ambas medidas deben interpretarse junto con la muestra y sus límites.

¿Se pueden contar falsos negativos revisando solo las alertas?

Esa selección no permite evaluar los casos sin aviso. Para conocer las omisiones hace falta una referencia sobre los casos que el mecanismo no señaló. El informe debe dejar visible esa limitación de la muestra.

¿Las cifras del ejemplo representan un desempeño real?

No. Los cien registros y sus resultados fueron inventados para explicar los cálculos. No son datos propios ni una estimación del mercado. Tampoco deben utilizarse como expectativa para un sistema real.

Fuentes y alcance de la evidencia

NIST SP 800-94: conceptos de falsos positivos y falsos negativos. Guía final de febrero de 2007 sobre detección de intrusiones. Se emplean conceptos, no recomendaciones actuales de despliegue ni tasas financieras. El borrador de revisión de 2012 no llegó a ser final y fue retirado. URL: https://csrc.nist.gov/pubs/sp/800/94/final

OWASP: contexto y clasificación de eventos registrados. Referencia técnica consultada el 18 de octubre de 2026; no aporta métricas de bots de trading. URL: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html

CFTC: advertencia educativa sobre IA y bots de trading. Aviso de una autoridad estadounidense, consultado el 18 de octubre de 2026; no se reproducen marcas, casos o cifras comerciales. URL: https://www.cftc.gov/LearnAndProtect/AdvisoriesAndArticles/AITradingBots.html

Los ejemplos del artículo son didácticos e hipotéticos. No describen un bot real ni constituyen datos de rendimiento de C-Tech.