Hay dos cosas que la gente llama «auditoría de IA», y no pueden ser más distintas. Una pregunta dónde deberíamos aplicar IA: esa es la auditoría de oportunidades, y ya escribimos sobre ella en «La auditoría es el producto». Este texto va de la otra: la auditoría de sistema. El sistema ya está construido. Está en producción, o a punto, o lo heredaste, o simplemente se cayó encima de producción. Ahora alguien tiene que decirte si de verdad se puede operar.
Es otro trabajo y huele distinto. Una auditoría de oportunidades produce una hoja de ruta. Una auditoría de sistema produce un veredicto, una lista de lo que va a romperse y el orden en que hay que arreglarlo. Si estás mirando una demo que funciona y te preguntas si puedes confiarle clientes reales y dinero real, esta es la auditoría que quieres.
Primero, ten claro qué auditoría estás comprando
Una auditoría de sistema da por hecho que el sistema existe. No estamos calificando tu estrategia: estamos leyendo tu código, tus traces, tus prompts, tu configuración de recuperación, tus reglas de acceso y tu factura. El resultado es aburrido a propósito: esto es sólido, esto es un incidente latente, esto lo estás pagando sin saberlo.
Tiene sentido en cuatro momentos. Antes del lanzamiento, previo a apuntarlo a clientes. Al heredar, cuando un sistema aterriza en tu escritorio sin nadie que responda por él. Después de un incidente, cuando hizo algo mal y necesitas saber si fue un caso aislado o una categoría entera. Y antes de escalar, cuando 100 usuarios pasan a ser 10.000 y cada fallo silencioso recibe un megáfono.
Eval y calidad: ¿se lanza a ojo?
Es lo primero que buscamos y lo que más veces falta. Hazle al equipo una sola pregunta —«¿cómo saben que un cambio mejoró las cosas?»— y la respuesta te lo dice todo. Si es «probamos unos prompts y se veía bien», están lanzando a ojo.
Qué buscamos: un arnés de evaluación que corra en cada cambio. Un conjunto de ground truth que refleje inputs reales y feos de producción, no doce ejemplos del happy path que alguien escribió un viernes. Tests de regresión, para que arreglar un caso no rompa en silencio otros cinco. Y una métrica de calidad con la que algún humano estuvo de acuerdo en algún momento.
Fallo común: ningún eval, y un equipo que mejora el sistema por sensación. El segundo más común: un eval que existe pero se escribió una vez, nunca se actualizó y ya no se parece a lo que los usuarios mandan. Un eval obsoleto es peor que ninguno, porque fabrica confianza.
Seguridad y control de acceso: ¿de quién puede ver los datos?
A los sistemas de IA les encanta filtrar datos, y filtran de maneras que las apps tradicionales no. El agujero clásico: la recuperación y las tools corren con más permisos que el usuario que pregunta. Alguien consulta al asistente y este trae encantado un documento que jamás podría abrir en la aplicación real.
Qué buscamos: ¿la recuperación respeta los permisos reales del usuario, aplicados en el momento de la consulta y no filtrados después dentro del prompt? ¿Las fronteras entre tenants son de verdad, o están a un booleano de derrumbarse? ¿La PII se maneja a conciencia —redactada, acotada, registrada con cuidado— o se cuela por accidente en los prompts y en los logs de modelos de terceros? Y la inyección de prompts: si tu sistema lee texto no confiable (correos, páginas web, archivos subidos), da por hecho que ese texto va a intentar secuestrar tus tools. Comprobamos si hay alguna defensa o solo optimismo.
Fallo común: permisos aplicados en la interfaz pero no en la capa de recuperación. El modelo se convierte en un confused deputy con acceso de modo dios.
Costo y eficiencia: el gasto operativo que nadie midió
Casi todos los sistemas que auditamos pagan de más, y casi ningún equipo sabe decirnos su costo por petición sin ir a buscarlo. Esa es la señal.
Qué buscamos: la economía de tokens por petición —input, output y el sobrecoste de recuperación y tools que nadie cuenta. La inflación de contexto, cuando el prompt fue creciendo en silencio hasta meter la base de conocimiento entera en cada llamada. El cache: el prompt cache para prefijos estables suele ser dinero gratis tirado al suelo. Y el enrutamiento de modelos: ¿estás usando tu modelo más caro en tareas que uno más barato resuelve perfectamente?
Fallo común: un system prompt gigante y fijo enviado en cada petición sin cache, más una sobre-recuperación que triplica el conteo de tokens sin ninguna ganancia medible de calidad. El arreglo suele partir el costo por la mitad sin tocar la calidad.
Observabilidad y traces: ¿puedes ver una sola petición?
Elige una petición real que salió mal ayer. ¿Puedes reconstruir exactamente qué pasó: el prompt, los fragmentos recuperados, las tool calls, el output del modelo, la latencia de cada salto? Si la respuesta es «tendríamos que añadir logging», estás volando a ciegas, y vas a depurar el próximo incidente igual: adivinando.
Qué buscamos: trazabilidad de punta a punta en cada petición, no solo en los errores. Spans que atraviesen recuperación, llamadas al modelo y tools. Monitoreo de calidad y de drift en producción: no solo disponibilidad, sino si los outputs empeoran a medida que cambian las entradas. Las herramientas modernas de tracing y evaluación hacen esto barato hoy; ya no hay excusa para una caja negra.
Fallo común: logs que capturan el output final pero no los pasos intermedios, así que cada sesión de depuración es una excavación arqueológica.
Confiabilidad y modos de fallo: ¿qué pasa cuando se rompe?
Se va a romper. La API del modelo va a dar timeout, una tool call va a devolver basura, la recuperación va a volver vacía. La pregunta es si tu sistema se degrada con elegancia o se lleva la petición entera por delante.
Qué buscamos: timeouts en cada llamada externa, con valores por defecto sensatos. Fallbacks: un modelo más barato, una respuesta cacheada, un honesto «esto ahora no puedo hacerlo» en lugar de un cuelgue o una invención. Manejo de tool calls mal formadas y de output inválido del modelo, porque a escala las dos cosas pasan constantemente. Retries que no provoquen estampidas. Hacemos red team de los caminos infelices a propósito, porque ahí es donde vive producción de verdad.
Fallo común: un sistema de happy path sin fallbacks, donde una dependencia lenta se convierte en timeouts en cascada y una experiencia de usuario muerta.
Calidad de datos y recuperación: la trampa específica de RAG
Si es un sistema RAG, la calidad de la recuperación es el techo de todo lo demás. Un modelo perfecto razonando sobre los tres fragmentos equivocados te da una respuesta equivocada con total aplomo.
Qué buscamos: un chunking que respete la estructura real del documento en lugar de cortar a ciegas por tamaño fijo. Precisión de recuperación: ¿los primeros resultados son de verdad relevantes, medido y no supuesto? Frescura: cuando cambia la fuente, ¿cuánto tarda el índice en enterarse? Probamos la recuperación por separado, porque un bug de recuperación y uno de generación se ven idénticos desde fuera y se arreglan en sitios completamente distintos.
Fallo común: nadie midió nunca la recuperación por sí sola, así que un problema de precisión se diagnostica como problema de prompt y el equipo se pasa un mes ajustando la capa equivocada.
Qué recibes
En Zoff.tech hacemos una auditoría de alcance cerrado sobre sistemas de IA en producción, exactamente sobre estas dimensiones: eval, seguridad y acceso, costo, observabilidad, confiabilidad y recuperación. Recibes un veredicto por escrito, una lista priorizada de lo que va a romperse y de lo que te está costando, y los arreglos concretos en el orden que importa. No una presentación que podrías pasarle a tu competencia cambiando los logos. Una lectura de tu sistema y una respuesta directa sobre si está listo. Pídela antes del lanzamiento, o después del incidente que te trajo hasta este artículo.