Alertas de caída de visibilidad en IA: cómo separar ruido de un incidente
Tu marca pasa de aparecer en el 42 % de las respuestas a hacerlo en el 31 %. El dashboard pinta la serie en rojo. ¿Debe alguien interrumpir su trabajo, o solo estás viendo una oscilación normal de un sistema generativo?
Una alerta útil no responde con un porcentaje aislado. Primero comprueba que la ejecución es válida; después exige una caída mayor que el ruido esperado, persistencia suficiente y relevancia para el negocio. Solo entonces abre un incidente, lo agrupa, asigna una severidad y entrega evidencia al responsable adecuado.
Esta guía diseña esa capa operativa. Parte de un benchmark estable y no repite el protocolo para medir la variabilidad de las respuestas de IA. Si aún no conoces el rango normal de cada métrica, resuelve primero ese requisito: una alerta sin perfil de ruido convierte la aleatoriedad en urgencia.
Una alerta no es una caída ni una causa
Separa tres conceptos que suelen mezclarse:
- Observación: un valor calculado para una ventana, con numerador, denominador y versiones conocidas.
- Candidato: un cambio que cruza un límite inicial, pero todavía puede deberse a ruido, baja cobertura o un evento suprimido.
- Incidente: un candidato válido que cumple las reglas de confirmación y requiere una respuesta operativa.
El incidente tampoco contiene la causa. Indica que la señal se ha apartado del comportamiento esperado de forma material. El análisis de modelo, fuentes, contenido, entidad o competidores ocurre después. Mantener esta frontera evita que el mensaje de alerta afirme explicaciones que los datos aún no sostienen.
El objetivo no es detectar cada movimiento. Es detectar pocos cambios con una relación razonable entre coste de reacción y riesgo de no actuar.
Define el contrato antes del umbral
Cada regla debe tener un contrato legible por una persona que no la programó:
| Campo | Pregunta que debe responder |
|---|---|
| Unidad | ¿Qué marca, intención, modelo, mercado e idioma vigila? |
| Métrica | ¿Mención, recomendación, posición, share of voice o exactitud? |
| Baseline | ¿Contra qué periodo y versión se compara? |
| Cobertura | ¿Cuántas observaciones válidas necesita? |
| Magnitud | ¿Qué cambio absoluto y relativo abre un candidato? |
| Persistencia | ¿En cuántas ventanas válidas debe repetirse? |
| Confirmación | ¿Exige deterioro frente a competidores o amplitud transversal? |
| Supresión | ¿Qué condiciones impiden evaluar o notificar? |
| Severidad | ¿Cómo combinan impacto, extensión y confianza? |
| Recuperación | ¿Qué regla cierra el incidente? |
| Owner y SLA | ¿Quién acusa recibo y en cuánto tiempo? |
Versiona el contrato junto al banco de prompts y la extracción. Cambiar un umbral sin fecha ni motivo rompe la trazabilidad igual que editar una pregunta en silencio.
Vigila celdas comparables, no un promedio global
La unidad mínima útil suele ser una celda como:
marca × intención × modelo × mercado × idioma × métrica
Un promedio global puede ocultar una caída crítica en intención de compra porque otra celda informativa crece. También puede abrir una alarma general por un problema limitado a un proveedor. Evalúa primero las celdas comparables y agrega después para decidir severidad.
Etiqueta cada celda por valor de negocio, riesgo reputacional y volumen. Una intención de selección de proveedor puede requerir más rapidez, pero no menos evidencia mínima.
Instala un gate de cobertura antes de mirar la caída
Una regla no debe evaluar magnitud cuando faltan datos. El gate puede exigir:
- porcentaje mínimo de prompts ejecutados;
- mínimo de repeticiones válidas por celda;
- ausencia de errores o respuestas truncadas por encima del límite;
- versión reconocida de modelo, prompt bank y clasificador;
- ventana temporal completa y zona horaria correcta;
- distribución comparable de dispositivos, mercados o modos cuando corresponda.
Si falla el gate, emite un evento de calidad de datos, no una alerta de pérdida de visibilidad. Son colas y responsables distintos. "No pudimos medir" nunca debe aparecer como "la marca desapareció".
Este principio conecta la alerta con la gobernanza de la medición de visibilidad en IA, pero aquí se aplica a una decisión concreta: permitir o bloquear la evaluación de una regla.
Combina magnitud absoluta y relativa
Un umbral solo relativo exagera muestras pequeñas. Pasar de dos menciones a una es una caída del 50 %, pero quizá representa una única observación. Un umbral solo absoluto puede ignorar un deterioro proporcional importante en una celda pequeña y valiosa.
Usa ambas condiciones. Por ejemplo, abre un candidato cuando:
delta_pp <= -8 puntos y delta_relativo <= -20 %
Los números son ilustrativos. Deben calibrarse contra la distribución y el coste de error de cada celda. Para posición, recomendación o share of voice, define el signo y la unidad de forma explícita; "bajar tres puestos" no se evalúa igual que "perder tres puntos porcentuales de menciones".
El límite de magnitud debe quedar fuera de la envolvente de ruido estimada. Si el intervalo esperado ya permite oscilaciones de nueve puntos, un umbral de ocho puntos disparará candidatos de forma rutinaria.
Exige persistencia sin esconder incidentes rápidos
La persistencia reduce falsas alarmas. Una regla sencilla puede exigir que el candidato aparezca en dos de tres ventanas válidas consecutivas. Así tolera una recuperación puntual sin esperar tres fallos seguidos.
Define también una vía rápida para eventos extremos. Por ejemplo, una pérdida superior a 25 puntos, presente en varias intenciones de alto valor y acompañada de ganancia competitiva, puede abrir un incidente crítico en una sola ventana válida. La vía rápida nunca anula el gate de cobertura.
La cadencia cambia el significado. Dos ventanas horarias durante un lanzamiento no equivalen a dos semanas en seguimiento estable. Para una campaña temporal usa el protocolo de monitorización de lanzamientos en ChatGPT, Gemini y Perplexity; esta guía gobierna la operación recurrente fuera de ese timebox.
Añade confirmación competitiva cuando la pregunta es pérdida de terreno
Una marca puede bajar porque toda la categoría se volvió menos visible, porque cambió el formato de respuesta o porque un competidor ganó presencia. No mezcles esos patrones.
Para alertas de pérdida frente a rivales, combina la métrica propia con una señal relativa:
- baja la tasa de mención de la marca;
- baja su share of voice dentro del mismo conjunto válido;
- uno o más competidores ganan parte de esa diferencia;
- el patrón persiste en intenciones comparables.
La confirmación competitiva aumenta confianza, pero no demuestra causalidad. El competidor puede beneficiarse del mismo cambio sin haberlo provocado. Guarda las respuestas y las posiciones observadas para la investigación posterior.
Asigna severidad por impacto, extensión y confianza
No uses la magnitud como único criterio. Separa tres ejes:
- Impacto: valor comercial o reputacional de la intención afectada.
- Extensión: número de modelos, mercados, intenciones o métricas afectadas.
- Confianza: cobertura, persistencia y distancia frente al ruido esperado.
Una matriz operativa puede quedar así:
| Severidad | Condición orientativa | Respuesta |
|---|---|---|
| Informativa | Candidato válido, localizado y de bajo impacto | Registrar; revisar en la siguiente ventana |
| Warning | Persistente o extendido en una celda de valor medio/alto | Owner en un día laborable; reunir evidencia |
| Crítica | Vía rápida o deterioro amplio, persistente y de alto impacto | Acuse inmediato; abrir incidente y coordinar responsables |
La severidad puede subir si la caída se extiende y bajar solo mediante una transición definida.
Suprime eventos que no deben notificar
Una supresión no borra datos. Conserva el candidato y documenta por qué no se notificó. Casos típicos:
- mantenimiento o indisponibilidad conocida del proveedor;
- despliegue de una nueva versión del banco de prompts;
- cambio del clasificador o de la definición de la métrica;
- campaña o lanzamiento con reglas temporales propias;
- ventana incompleta o retraso de ingestión;
- incidente ya abierto que cubre las mismas celdas;
- periodo de cooldown después de una notificación.
Toda supresión necesita alcance, inicio, fin, owner y motivo. Una supresión indefinida es una alerta desactivada sin control.
Usa histéresis para cerrar sin oscilaciones
Si abres al caer ocho puntos y cierras en cuanto recupera esos mismos ocho, una serie cercana al límite alternará entre abierta y resuelta. Define un umbral de recuperación diferente y exige estabilidad.
Ejemplo ilustrativo:
- abrir cuando la caída supera 8 puntos en dos de tres ventanas válidas;
- mantener abierta mientras la recuperación no supere -3 puntos;
- cerrar cuando la serie queda por encima de -3 puntos durante dos ventanas válidas.
Esta separación se llama histéresis. Añade también un estado monitoring entre mitigado y cerrado cuando la respuesta operativa necesita confirmación.
Agrupa duplicados en un solo incidente
Una caída amplia puede disparar decenas de reglas: varios prompts, dos métricas y tres mercados. Enviar un mensaje por celda destruye la señal.
Genera una clave de agrupación con marca, familia de intención, modelo o evento padre y ventana. Abre un incidente principal y añade celdas afectadas como evidencia. Durante el cooldown, actualiza magnitud, extensión y severidad en lugar de crear otro caso.
Entrega un paquete de evidencia accionable
Cada notificación debe permitir decidir sin abrir cinco herramientas. Incluye:
- regla y versión que se activó;
- celda, métrica y severidad;
- valor actual, baseline, delta absoluto y relativo;
- numerador, denominador y cobertura;
- ventanas que confirmaron la persistencia;
- rango de ruido usado y fecha de calibración;
- comparación competitiva cuando aplique;
- enlaces a respuestas originales y ejecuciones;
- versiones de modelo, prompts y extractor;
- supresiones evaluadas y descartadas;
- owner, SLA y enlace al incidente agrupado.
El rastreador de visibilidad en IA debe conservar estas piezas, no solo mostrar una línea roja. Sin denominador ni respuestas originales, la persona que recibe la alerta no puede distinguir señal, error de datos o cambio metodológico.
Diseña el routing y el escalado
Asigna destino por tipo y severidad: calidad a data operations; caída comercial confirmada a GEO y producto; y riesgo reputacional a marca o legal según la política interna. Define canal y respaldo, owner y sustituto, tiempos de acuse y clasificación, condición de escalado y permisos para silenciar, degradar o cerrar. Una alerta sin owner es una visualización; un owner sin SLA es una sugerencia.
Calibra con backtesting y shadow mode
Antes de activar notificaciones, ejecuta las reglas sobre historia versionada. Cuenta cuántos candidatos habría producido cada umbral, cuáles coincidieron con deterioros conocidos y cuánto tiempo tardaron en abrir y cerrar.
Después usa shadow mode durante varias ventanas: calcula y registra alertas sin enviarlas. Revisa:
- precisión: qué proporción merecía atención;
- recall operativo: qué incidentes conocidos se habrían detectado;
- tiempo hasta detección;
- duración y oscilaciones;
- volumen por owner y severidad;
- supresiones incorrectas.
No optimices para cero falsas alarmas: define el coste de revisar un warning frente al de perder un incidente crítico.
Ejemplo completo de una regla
Supón una celda de intención de compra para España en un modelo concreto. Su tasa de recomendación de marca tiene un baseline de 40 %, una envolvente normal de ±5 puntos y al menos 80 observaciones válidas por ventana.
La política ilustrativa exige:
- cobertura mínima del 90 % y 80 observaciones válidas;
- caída de al menos 9 puntos y 20 % relativo;
- confirmación en dos de tres ventanas;
- pérdida de al menos 6 puntos de share of voice frente al conjunto competitivo;
- ausencia de cambio de prompt bank, fallo de proveedor o lanzamiento activo.
Las ventanas observadas son 29 %, 34 % y 30 %. Dos cruzan magnitud, las tres están fuera del ruido y el share of voice cae ocho puntos. La regla abre un warning. Si además el patrón aparece en dos modelos o afecta una intención marcada como crítica, la severidad escala.
La conclusión válida es: "existe un deterioro confirmado que merece diagnóstico". No es válido afirmar que un competidor, una fuente o una actualización concreta causó la caída.
Matriz de decisión
| Patrón | Estado | Acción |
|---|---|---|
| Cobertura insuficiente | Data quality | Bloquear la regla y reparar medición |
| Cruza magnitud una vez | Candidato | Esperar confirmación o vía rápida |
| Cruza magnitud y persistencia | Incidente | Abrir, agrupar y asignar severidad |
| Marca baja, categoría también | Incidente de mercado/formato | Separar de pérdida competitiva |
| Marca baja y rivales ganan share | Pérdida competitiva confirmada | Priorizar diagnóstico comparativo |
| Cambio bajo supresión activa | Suprimido | Registrar sin notificar |
| Recuperación parcial | Monitoring | Mantener abierto |
| Recuperación supera histéresis | Resuelto | Cerrar con evidencia y resultado |
Errores frecuentes
- Alertar por cualquier delta negativo.
- Aplicar el mismo porcentaje a todas las celdas.
- Evaluar una ventana con cobertura incompleta.
- Confundir ausencia de datos con ausencia de marca.
- Recalcular el baseline con la propia caída y reducir su magnitud.
- Cambiar prompts o extractores sin reiniciar la comparabilidad.
- Enviar una alerta por prompt en lugar de agrupar el evento.
- Silenciar sin caducidad ni owner.
- Cerrar al tocar el mismo umbral de apertura.
- Incluir una causa no demostrada en el asunto del incidente.
Checklist de implementación
- [ ] Unidad, métrica y dirección del deterioro definidas.
- [ ] Baseline y perfil de ruido versionados.
- [ ] Gate de cobertura y calidad antes de magnitud.
- [ ] Umbral absoluto y relativo calibrados.
- [ ] Persistencia y vía rápida documentadas.
- [ ] Confirmación competitiva para pérdida de terreno.
- [ ] Severidad basada en impacto, extensión y confianza.
- [ ] Supresiones con alcance, owner y caducidad.
- [ ] Histéresis y estado de recuperación.
- [ ] Agrupación, deduplicación y cooldown.
- [ ] Paquete de evidencia completo.
- [ ] Routing, SLA y escalado aprobados.
- [ ] Backtesting y shadow mode revisados.
- [ ] Historial de cambios y resultados conservado.
Cuando la regla confirma un incidente, el trabajo pasa a la investigación: consulta cómo diagnosticar una caída de visibilidad en ChatGPT para recorrer un árbol causal ordenado en lugar de saltar a la primera explicación plausible.
FAQ
¿Qué es una alerta de caída de visibilidad en IA?
Es una regla que detecta un deterioro operativo en una métrica de visibilidad para una unidad definida, como marca, intención, modelo y mercado. Solo debe abrir un incidente cuando la ejecución es válida y el cambio supera condiciones de magnitud, persistencia y relevancia previamente acordadas.
¿Qué porcentaje de caída debe activar una alerta?
No existe un porcentaje universal. El límite debe superar el ruido normal de esa celda, considerar el volumen de observaciones y combinar un cambio relativo con un mínimo absoluto. Una caída del 20 % puede ser crítica en una intención estable y no concluyente en una muestra pequeña o muy variable.
¿Cuántas ventanas debe persistir una caída?
Depende de la cadencia y del coste de reaccionar, pero una política común exige confirmación en dos de tres ventanas válidas. Las celdas de alto valor pueden usar una vía rápida si la magnitud es extrema y existe confirmación competitiva, siempre con cobertura suficiente.
¿Cómo evito alertas causadas por la variabilidad normal de la IA?
Estima primero el rango de variación con repeticiones y una metodología versionada. Después usa ese rango como límite mínimo, bloquea ejecuciones con cobertura o calidad insuficientes y exige persistencia. La alerta consume el perfil de ruido; no debe recalcularlo de forma improvisada cada vez.
¿Cuándo se debe cerrar una alerta de visibilidad?
Se cierra cuando la métrica supera un umbral de recuperación distinto y más estable que el de apertura durante el número de ventanas definido. Esta histéresis evita que el incidente se abra y cierre repetidamente cuando el valor oscila junto al límite.
¿Una alerta explica por qué cayó la visibilidad?
No. Una alerta demuestra que una serie válida se ha apartado de su comportamiento esperado con suficiente relevancia para investigar. La causa puede estar en la muestra, el modelo, las fuentes, la marca o los competidores y requiere un diagnóstico posterior con evidencia adicional.
Convierte cambios en incidentes defendibles
Una buena alerta no es la más sensible. Es la que conserva la diferencia entre dato inválido, ruido, candidato e incidente; entrega el contexto necesario y activa una respuesta proporcional.
Empieza con pocas celdas de alto valor, calibra sobre historia, opera en shadow mode y revisa cada falso positivo y cada incidente omitido. Cuando el contrato sea estable, amplía cobertura sin relajar los gates.
Mentio permite medir menciones, recomendaciones, posición y competidores en respuestas de IA y conservar la evidencia que una política de alertas necesita. Empieza a medir tu visibilidad en IA y transforma una serie cambiante en decisiones con trazabilidad.
¿Quieres saber si la IA menciona tu marca?
Descubre tu visibilidad en ChatGPT, Claude y Gemini en minutos.
Artículos relacionados
Cómo medir la variabilidad de las respuestas de IA sin sesgar tu benchmark
Aprende a repetir prompts, controlar cambios y separar señal de ruido para construir un benchmark fiable de visibilidad de marca en respuestas de IA.
Analítica GEOGobernanza de la medición de visibilidad en IA: ownership, QA y versiones
Implanta owners, diccionario de datos, controles de calidad, trazabilidad y versiones para que tu medición de visibilidad en IA sea auditable.
Guías prácticasRastreador de visibilidad en IA: qué debe medir una herramienta seria (2026)
Un rastreador de visibilidad en IA no solo cuenta menciones: mide posición, framing, competidores, fuentes y cambios por modelo. Guía para elegir bien.