Auditoría técnica de IA para RAG y agentes

Una auditoría técnica de IA merece la pena cuando el equipo ya no pregunta "¿podemos construir esto?", sino algo más incómodo: "¿tiene sentido seguir construyéndolo así?"

Esa pregunta suele aparecer después de una demo que funciona, pero no transmite confianza en uso real. La recuperación no encuentra documentos obvios. El agente se queda en bucle. El coste de API sube más de lo previsto. Nadie sabe explicar por qué una respuesta salió bien y la siguiente fue peligrosa.

En ese punto, otro sprint de funcionalidades puede empeorar el problema. A veces toca parar y revisar.

Respuesta rápida

Una auditoría técnica de IA debería responder a cinco preguntas:

1. ¿La arquitectura actual encaja con el riesgo de negocio?
2. ¿El equipo puede medir calidad o solo se guía por demos?
3. ¿Se puede rastrear un fallo hasta retrieval, prompts, herramientas, modelo o lógica de producto?
4. ¿Coste, latencia, privacidad y dependencia de proveedores están suficientemente visibles?
5. ¿Qué conviene arreglar, simplificar, pausar o reconstruir antes de producción?

El resultado no debería ser una puntuación genérica de madurez. Debería ser un documento de decisión: seguir, arreglar, simplificar o parar.

Cuándo auditar un sistema RAG

Los sistemas RAG parecen sencillos desde fuera. Entran documentos, entran preguntas y salen respuestas con algo de contexto. Los fallos rara vez se ven en una demo.

Conviene auditar el RAG cuando pasa algo de esto:

• Los usuarios hacen preguntas razonables y el sistema recupera fragmentos irrelevantes.
• Las respuestas suenan seguras, pero citan fuentes flojas o antiguas.
• El equipo no puede reproducir por qué apareció una respuesta concreta.
• La calidad de búsqueda se juzga por opinión, no con un conjunto fijo de evaluación.
• Los cambios en documentos no aparecen de forma fiable en las respuestas.
• La base vectorial, embeddings, fragmentación o reranking se eligieron sin pruebas.
• La empresa está a punto de exponer el sistema a clientes o equipos operativos.

La auditoría debería revisar ingesta, fragmentación, metadatos, embeddings, búsqueda híbrida, reranking, construcción del prompt, citas y datos de evaluación.

En sistemas comerciales, la pregunta clave es directa: ¿puede un comprador, operador o agente de soporte fiarse de la respuesta lo suficiente como para actuar? Si no, el RAG sigue siendo un prototipo.

Cuándo auditar un sistema de agentes IA

Los agentes fallan de otra manera.

Un RAG puede recuperar la evidencia equivocada. Un agente puede recuperar la evidencia equivocada, llamar la herramienta equivocada, repetir la misma acción rota, ignorar un límite de permisos y luego escribir una respuesta convincente.

Conviene auditar el sistema de agentes cuando:

• El flujo tiene más de unas pocas llamadas a herramientas por tarea.
• El agente puede escribir en sistemas, enviar mensajes, crear tickets, actualizar registros o afectar a clientes.
• No hay límite claro de iteraciones o tiempo.
• Las reglas de escalado a humanos no están claras.
• Los esquemas de herramientas son laxos o los errores no están estructurados.
• El equipo no puede reproducir una ejecución fallida desde las trazas.
• Hay varios agentes, pero no hay contratos claros entre ellos.

La auditoría debería revisar estado, permisos de herramientas, orquestación, reintentos, límites de bucle, logs, traspasos humanos y evaluación por paso.

Aquí muchos equipos descubren que todavía no necesitan una arquitectura multi-agente. Necesitan un agente más simple, mejores herramientas y mejor medición.

Qué revisar en una integración LLM

Algunos productos no necesitan RAG ni agentes. Necesitan una integración LLM fiable dentro de un producto existente.

Conviene auditar la integración cuando:

• La calidad cambia tras actualizaciones de modelo.
• El gasto de API sube y nadie sabe qué función lo provoca.
• Los prompts se editan a mano sin versionado.
• No hay casos de prueba para entradas habituales.
• El producto depende de un único proveedor sin ruta alternativa.
• Los logs contienen datos sensibles sin política clara de retención.
• El mismo modelo se usa para todo, desde enrutado hasta razonamiento complejo.

La auditoría debería revisar prompts, enrutado de modelos, salidas estructuradas, errores de API, retención de datos, observabilidad, evaluación, rutas alternativas y atribución de costes.

Muchas integraciones LLM no fallan porque el modelo sea malo. Fallan porque el producto no tiene forma de saber cuándo el modelo está siendo malo.

Checklist de auditoría

Una revisión seria debería cubrir estas áreas.

Arquitectura. Cuáles son los componentes principales. Qué partes son software determinista y qué partes dependen de un modelo. Dónde se puede perder estado.

Límites de datos. Qué datos llegan a proveedores de modelos. Qué queda en logs. Qué se redacta. Qué se conserva. Quién puede acceder a trazas.

Calidad de recuperación. Qué consultas miden el retrieval. Si la búsqueda híbrida ayuda. Si las citas son válidas. Si se filtran documentos antiguos.

Evaluación. Si hay un conjunto representativo de pruebas. Si existen criterios de aprobado o fallo. Si los fallos se revisan por categoría. Si el equipo sabe si la calidad mejora.

Observabilidad. Si se puede reconstruir una ejecución. Si quedan registrados prompts, versiones de modelo, fragmentos recuperados, llamadas a herramientas, latencia y coste.

Coste y latencia. Qué llamadas dominan el gasto. Qué pasos dominan la latencia. Si modelos más baratos pueden hacer enrutado o clasificación simple.

Seguridad y control. Qué puede hacer el sistema sin una persona. Qué acciones requieren aprobación. Qué pasa cuando la confianza es baja.

Riesgo de proveedor. Si el sistema está atado a un proveedor, framework, base vectorial o capa de orquestación. Y si esa decisión fue consciente.

Qué debería entregar una buena auditoría

El resultado útil no es un PDF de 60 páginas que nadie lee.

Una buena auditoría debería dejar al equipo con:

• Un mapa de la arquitectura actual.
• Una lista de fallos críticos.
• Evidencia desde trazas, código, configuración o ejecuciones de muestra.
• Una lista priorizada de arreglos.
• Una decisión sobre qué mantener, simplificar, pausar o reconstruir.
• Un checklist corto para producción.
• Un siguiente paso suficientemente pequeño como para ejecutarlo.

Para equipos que ya tienen proveedor, la auditoría también debería separar problemas del proveedor de problemas internos de producto. A veces el proveedor está bien y el contrato de producto es débil. A veces la arquitectura está bien y los datos son malos. A veces conviene parar el sistema antes de gastar más.

Dónde encaja Pharosyne

Las auditorías de Pharosyne encajan cuando el equipo necesita criterio técnico senior antes de comprometer más presupuesto.

Buenos puntos de entrada:

• Un prototipo RAG que debería convertirse en sistema de conocimiento interno.
• Un flujo de agentes IA que empieza a tocar operaciones reales.
• Una función LLM con calidad o coste impredecible.
• Un fundador preparando due diligence o revisión de seguridad de un cliente.
• Un equipo decidiendo entre arreglar lo actual o cambiar de proveedor.

Si estás en esa situación, empieza por servicios de consultoría IA, consultoría RAG o envía el contexto. La primera conversación de auditoría debería aclarar el sistema, el riesgo, qué evidencia existe y qué decisión hay que tomar.