Una auditoría trimestral de sistemas de IA no es una revisión de desempeño. Es una verificación de deriva de alcance.
La deriva de alcance es silenciosa. El sistema no falla. Simplemente empieza a manejar cosas para las que nunca fue diseñado — a través de rutas de fallback, parches de prompt acumulados y conjuntos de recuperación que crecieron sin una verificación de precisión correspondiente. Para el mes cuatro, el sistema hace algo materialmente distinto a lo que hacía en el mes uno. Nadie lo planeó. Nadie lo documentó.
Esta auditoría toma menos de dos horas. Ejecútala cada trimestre.
Cómo se ve la deriva de alcance en producción
Tres patrones aparecen repetidamente.
Acumulación de rutas de fallback. Cuando una consulta no coincide con la lógica de enrutamiento principal del sistema, cae a un handler por defecto. Eso está bien para casos extremos ocasionales. Es un problema cuando el 15% de las consultas en producción están llegando al fallback — porque eso significa que el 15% de las consultas están fuera del alcance original y el sistema está improvisando.
Acumulación de parches de prompt. Un prompt falla con una entrada específica. Alguien agrega una cláusula condicional para corregirlo. Luego otra. Luego otra más. Seis meses después, el prompt tiene 11 cláusulas condicionales, sin historial de versiones, y nadie puede explicar cuál era la lógica original. Cada parche fue razonable. El conjunto es imposible de mantener.
Expansión del conjunto de recuperación sin verificaciones de precisión. La base de conocimiento crece — nuevos documentos, nuevas fuentes de datos, nuevas integraciones. La cobertura de recuperación mejora. La precisión de recuperación generalmente no. El sistema recupera más, pero los resultados top-k para consultas comunes se vuelven más ruidosos. Nadie ejecutó una muestra de precisión después de la expansión.
La lista de verificación trimestral de cinco puntos
1. Revisión de límites de alcance
Extrae los registros de consultas de los últimos 30 días. Categoriza cada consulta como dentro del alcance, caso extremo o fuera del alcance. Calcula el porcentaje en cada categoría. Compara con el mismo cálculo del trimestre anterior.
Si las consultas fuera del alcance crecieron más de 5 puntos porcentuales, el alcance del sistema ha derivado. Decide si ampliar el alcance definido de forma intencional o agregar una ruta de rechazo explícita para los nuevos tipos de consulta.
Tiempo: 30 minutos.
2. Muestra de precisión de recuperación
Selecciona 20 consultas — 10 del cluster de consultas más común, 10 del cluster de casos extremos con mayor volumen. Ejecuta cada consulta contra el sistema de recuperación actual. Para cada consulta, inspecciona manualmente los 3 resultados recuperados principales y puntúalos: relevante, parcialmente relevante o irrelevante.
Objetivo: el 85% de los resultados top-3 deben puntuar como relevantes o parcialmente relevantes. Por debajo de ese umbral, el conjunto de recuperación necesita poda o re-ranking antes del próximo trimestre.
Tiempo: 30 minutos.
3. Diff de versión de prompt
Compara el prompt actual con el prompt de hace 90 días. Si no tienes historial de versiones, ese es el primer hallazgo — impleméntalo antes del próximo trimestre.
Para cada cambio, documenta: qué entrada provocó el cambio, en qué consistió el cambio y si fue probado contra un conjunto de regresión. Cualquier cambio sin un disparador documentado o sin prueba es un pasivo.
Tiempo: 20 minutos.
4. Análisis del registro de puertas de aprobación
Si el sistema tiene puertas de aprobación — pasos de revisión humana antes de que se actúe sobre los resultados — extrae los registros de las puertas del trimestre. Calcula la tasa de aprobación, la tasa de rechazo y las razones de rechazo más comunes.
Una tasa de rechazo en aumento señala que los resultados del sistema están derivando de lo que los operadores consideran aceptable. Una tasa de rechazo en descenso no es automáticamente buena — puede significar que los revisores están aprobando sin analizar. Ambas tendencias requieren investigación.
Tiempo: 20 minutos.
5. Comparación de percentiles de latencia contra la línea base
Extrae la latencia p50, p90 y p99 del trimestre actual. Compara con la línea base del primer mes del sistema en producción.
El crecimiento de latencia en p99 generalmente significa que el sistema está manejando consultas más complejas, que el conjunto de recuperación creció sin optimización de índices, o que la longitud del prompt aumentó por la acumulación de parches. Cada causa tiene una solución diferente. Identifica cuál aplica antes del próximo trimestre.
Tiempo: 20 minutos.
Ejecutar las cinco verificaciones en menos de dos horas
Las herramientas no necesitan ser sofisticadas.
- Registros de consultas: exporta desde tu stack de observabilidad existente (Datadog, Grafana, CloudWatch — cualquiera de ellos). Filtra por rango de fechas. Exporta a CSV.
- Precisión de recuperación: ejecuta las consultas manualmente contra el endpoint de producción. Puntúa los resultados en una hoja de cálculo. 20 consultas toman aproximadamente 25 minutos si conoces el dominio.
- Diff de prompt: almacena los prompts en control de versiones.
git diffentre el tag de hace 90 días y HEAD es suficiente. - Registros de puertas: exporta desde el sistema que gestiona tu flujo de aprobación. Calcula las tasas en una hoja de cálculo.
- Latencia: extrae desde tu herramienta APM existente. p50/p90/p99 son métricas estándar en todas las plataformas de observabilidad principales.
El objetivo de dos horas asume que los registros son accesibles y que la persona que ejecuta la auditoría conoce el sistema. Si alguna de las dos condiciones no se cumple, corrígela primero.
Qué hacer con los resultados
La auditoría produce un documento breve: cinco secciones, un hallazgo por sección, una acción recomendada por hallazgo. Ese documento va a quien sea responsable del sistema. No es un informe para la dirección — es un insumo operativo para el próximo sprint.
Si el mismo hallazgo aparece en dos auditorías trimestrales consecutivas sin resolución, ya no es un hallazgo. Es un defecto de diseño. Trátalo como tal.
Sistemas como AI Brand Presence se construyen con este tipo de disciplina operativa desde el inicio — límites de alcance definidos, líneas base de precisión de recuperación y seguimiento de versiones de prompt integrados en el proceso de entrega, no agregados después.
La mayoría de los equipos omite la auditoría trimestral porque nada está visiblemente roto. Ese es exactamente el momento en que la deriva de alcance es más difícil de ver y más fácil de corregir.