Hay dos cosas que la gente llama "auditoría de IA", y no podrían ser más distintas. Una pregunta dónde deberíamos aplicar IA — esa es una auditoría de oportunidades, y ya escribimos sobre ella en "La auditoría es el producto". Este texto trata de la otra: la auditoría de sistema de IA. Ya construiste la cosa. Está en producción, o casi, o la heredaste, o simplemente se cayó en producción. Ahora alguien tiene que decirte si de verdad está lista para operar.
Ese es otro trabajo con otro olor. 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 un demo que funciona y te preguntas si puedes confiarle clientes reales y dinero real, esta es la auditoría que quieres.
Primero, sabé qué auditoría estás comprando
Una auditoría de sistema asume que el sistema existe. No estamos calificando tu estrategia. Estamos leyendo tu código, tus trazas, 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 estás pagando sin saberlo.
Consíguela en cuatro momentos. Pre-lanzamiento, antes de apuntarla a clientes. Heredado, cuando un sistema aterriza en tu escritorio sin nadie que responda por él. Post-incidente, cuando hizo algo mal y necesitás saber si fue un caso aislado o una categoría. Y antes de escalar, cuando 100 usuarios pasan a ser 10.000 y cada falla silenciosa recibe un megáfono.
Evaluación y calidad: ¿se lanza a puro instinto?
Esto es lo primero que buscamos y lo que más comúnmente falta. Hacele al equipo una pregunta — "¿cómo saben que un cambio lo mejoró?" — y la respuesta te dice todo. Si es "probamos unos prompts y se veía bien", están lanzando a puro instinto.
Qué buscamos: un arnés de evaluación que corra en cada cambio. Un conjunto de verdad de referencia (ground truth) que refleje entradas reales y feas de producción — no doce ejemplos del camino feliz que alguien escribió un viernes. Pruebas de regresión, para que arreglar un caso no rompa silenciosamente otros cinco. Una métrica de calidad con la que un humano de verdad estuvo de acuerdo en algún momento.
Fallo común: ninguna evaluación, y un equipo que mejora el sistema por sensación. El segundo más común: una evaluación que existe pero se escribió una vez, nunca se actualizó y ya no se parece a lo que los usuarios realmente envían. Una evaluación obsoleta es peor que ninguna, porque fabrica confianza.
Seguridad y control de acceso: ¿los datos de quién puede ver?
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 herramientas corren con más permisos que el usuario que pregunta. Alguien consulta al asistente, y este trae felizmente un documento que jamás podría abrir en la app real.
Qué buscamos: ¿la recuperación respeta los permisos reales del usuario, aplicados al momento de la consulta y no filtrados después dentro del prompt? ¿Las fronteras de datos entre inquilinos (tenants) son reales, o están a un booleano de colapsar? ¿La PII se maneja deliberadamente — redactada, acotada, registrada con cuidado — o fluye hacia los prompts y los logs de modelos de terceros por accidente? Y la inyección de prompts: si tu sistema lee texto no confiable (correos, páginas web, archivos subidos), asumí que ese texto intentará secuestrar tus herramientas. Verificamos 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 vuelve un delegado confundido con acceso modo-dios.
Costo y eficiencia: el costo de operación que nadie midió
Casi todos los sistemas que auditamos pagan más de lo necesario, y la mayoría de los equipos no puede decirnos su costo por solicitud sin ir a buscarlo. Esa es la señal.
Qué buscamos: la economía de tokens por solicitud — entrada, salida y el sobrecosto de recuperación y herramientas que nadie cuenta. Inflación de contexto, donde el prompt creció silenciosamente hasta meter toda la base de conocimiento en cada llamada. Caché — el caché de prompts para prefijos estables suele ser dinero gratis tirado al piso. Y enrutamiento de modelos: ¿estás corriendo tu modelo más caro en tareas que uno más barato resuelve perfecto?
Fallo común: un system prompt fijo y gigante enviado en cada solicitud sin caché, más sobre-recuperación que triplica el conteo de tokens sin ganancia de calidad medible. El arreglo suele recortar el costo a la mitad sin tocar la calidad.
Observabilidad y trazas: ¿podés ver una sola solicitud?
Elegí una única solicitud real que salió mal ayer. ¿Podés reconstruir exactamente qué pasó — el prompt, los fragmentos recuperados, las llamadas a herramientas, la salida del modelo, la latencia de cada salto? Si la respuesta es "tendríamos que agregar logging", estás volando a ciegas y depurarás el próximo incidente igual: adivinando.
Qué buscamos: trazabilidad de extremo a extremo en cada solicitud, no solo en los errores. Spans que atraviesen recuperación, llamadas al modelo y herramientas. Monitoreo de calidad y de deriva (drift) en producción — no solo disponibilidad, sino si las salidas empeoran a medida que cambian las entradas. Las herramientas modernas de trazas y evaluación hacen esto barato hoy; no hay excusa para una caja negra.
Fallo común: logs que capturan la salida 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 tendrá timeout, una llamada a herramienta devolverá basura, la recuperación volverá vacía. La pregunta es si tu sistema se degrada con gracia o se lleva toda la solicitud abajo con él.
Qué buscamos: timeouts en cada llamada externa, con valores por defecto sensatos. Planes de respaldo (fallbacks) — un modelo más barato, una respuesta en caché, un honesto "ahora no puedo hacer eso" en lugar de un cuelgue o una adivinanza alucinada. Manejo de llamadas a herramientas malformadas y de salida inválida del modelo, porque ambas pasan constantemente a escala. Reintentos que no provoquen estampidas. Hacemos red-team de los caminos infelices a propósito, porque ahí es donde vive la producción de verdad.
Fallo común: un sistema de camino feliz sin respaldos, 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 recuperación es el techo de todo. Un modelo perfecto razonando sobre los tres fragmentos equivocados te da una respuesta equivocada con toda confianza.
Qué buscamos: fragmentación (chunking) que respete la estructura real del documento en lugar de cortes ciegos de tamaño fijo. Precisión de recuperación — ¿los primeros resultados son realmente relevantes, medido y no asumido? Frescura — cuando la fuente cambia, ¿cuánto tarda el índice en enterarse? Probamos la recuperación de forma aislada, porque un bug de recuperación y uno de generación se ven idénticos desde afuera y se arreglan en lugares completamente distintos.
Fallo común: nadie midió nunca la recuperación por sí sola, así que un problema de precisión se diagnostica mal como problema de prompt y el equipo pasa un mes ajustando la capa equivocada.
Qué recibís
Zoff.tech realiza una auditoría de sistema de IA en producción de alcance fijo sobre exactamente estas dimensiones — evaluación, seguridad y acceso, costo, observabilidad, confiabilidad y recuperación. Recibís 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 un deck que podrías pasarle a tu competidor cambiando los logos. Una lectura de tu sistema, y una respuesta directa sobre si está listo. Conseguila antes del lanzamiento, o después del incidente que te hizo buscar este artículo.