Un auditor con IA que no lo lee todo.

Una consultora de project management audita la calidad de sus proyectos con una rúbrica propia: criterios agrupados en gestión documental, de proyecto y contractual, cada uno con una escala y una descripción por nivel. Hasta ahora, cada auditoría eran horas de abrir carpetas para encontrar la evidencia de cada criterio.

Esta nota explica cómo está diseñado el agente que hace ese trabajo en el sistema a medida que construimos, y por qué la decisión más importante fue no dejar que lo leyera todo.

El error típico: RAG a ciegas

La tentación es indexar toda la documentación, hacer una gran pregunta («¿cumple este proyecto la rúbrica?») y dejar que el modelo componga una respuesta con lo que recupere. Funciona en una demo. En producción tiene tres problemas:

• Recupera fragmentos parecidos, no la evidencia que pide cada criterio.
• No se puede comprobar de dónde sale cada puntuación.
• Cuando no encuentra nada, no lo dice: puntúa igualmente.

La alternativa: un criterio cada vez

El agente recorre la rúbrica criterio a criterio, como haría un auditor con oficio. Para cada uno:

para cada criterio de la rúbrica:
    reglas    = reglas del criterio (sacadas de auditorías de referencia)
    consulta  = búsqueda dirigida: qué documento probaría este criterio
    evidencia = los ~10 fragmentos más relevantes, solo de este proyecto
    si no hay evidencia suficiente:
        resultado = "sin evidencia suficiente"      # nunca un nivel bajo por defecto
    si no:
        resultado = modelo(rúbrica + niveles + reglas + evidencia)
    guardar(resultado, referencias = documento + hash + página + fragmento)
    checkpoint()                                    # si algo falla, se reanuda aquí

Tres detalles marcan la diferencia:

«Sin evidencia suficiente» es una respuesta válida

Si la búsqueda no encuentra nada, el criterio no se puntúa bajo por defecto. Se marca como sin evidencia y lo decide el auditor. Un sistema que admite lo que no sabe se gana la confianza mucho antes que uno que siempre responde.

Cada puntuación lleva su prueba

Cada resultado guarda las referencias de la evidencia: ruta del documento, huella del archivo, página y fragmento. En la revisión, la evidencia se abre con un clic. Si el documento cambia después, la huella lo delata.

Checkpoints por criterio

Una auditoría completa son muchas llamadas al modelo. Si falla una a mitad, el agente no empieza de cero: reanuda en el criterio donde se quedó. Además, la rúbrica y sus descripciones viajan en caché entre llamadas, lo que abarata cada auditoría.

La revisión humana, bien diseñada

Cada auditoría pasa por estados: borrador → en curso → pendiente de revisión → aprobada o rechazada. La base de datos guarda por separado el nivel que propone el agente, el que fija el revisor y el definitivo. Así se puede medir dónde acierta y dónde no.

Hay un riesgo poco comentado: el sesgo de automatización, es decir, que el revisor apruebe sin mirar porque «lo ha dicho la IA». La interfaz lo combate registrando qué evidencias abre el revisor y obligándole a abrirlas en los criterios donde agente y referencia discrepan.

El auditor ya no busca: valida. Y el sistema sabe si de verdad ha validado.

Dónde corre y con qué modelos

Todo funciona en el servidor del propio cliente. La documentación de los proyectos se lee en solo lectura desde su gestor documental y no sale de su infraestructura. Un modelo local se encarga de lo extractivo (indexar, trocear, recuperar), donde una alucinación hace poco daño; el razonamiento de cada criterio lo hace un modelo en la nube, que recibe solo los fragmentos imprescindibles.

Cómo se sabe si audita bien

«Acierta casi siempre» no es una métrica. La calibración se hace contra auditorías reales hechas a mano:

• Matriz de confusión por criterio, no una media global que esconde los fallos.
• Sesgo con signo: no basta con saber cuánto se equivoca; importa si tiende a puntuar alto o bajo.
• Acuerdo entre auditores humanos como techo: si dos personas discrepan en un criterio, no se le puede pedir más a la máquina.
• Ejemplos concretos por criterio en el prompt y evaluación continua para detectar derivas.