Hace tres años, revisar miles de documentos en un día era simplemente imposible. Hoy, con IA, no solo es posible, sino que es algo que hacemos de forma rutinaria. Pero “poder hacerlo” y “hacerlo bien” son dos cosas muy distintas, y la distancia entre ambas es precisamente donde vive el trabajo real.
Una caja de sorpresas en cada ejecución
Hace poco trabajamos en un proyecto que consistía en analizar grandes volúmenes de documentos para extraer información muy específica. El reto no era el volumen en sí, sino la naturaleza del input: recibíamos carpetas anidadas con documentos de distintos tipos, en distintos formatos y sin una estructura garantizada. Cada ejecución era una caja de sorpresas, porque no sabíamos qué íbamos a encontrar adentro; lo único que teníamos claro era qué estábamos buscando.
La tentación, cuando ves un problema así, es la obvia: tirarle todo a un modelo y pedirle que lo resuelva. Y no funciona.
La capacidad no es la solución
Que un modelo pueda leer un documento no significa que pueda procesar diez mil de forma confiable. Hacerlo de verdad es ingeniería: hay que diseñar cómo paralelizar el trabajo, elegir qué modelo usar en cada paso (porque no todos sirven para lo mismo ni cuestan lo mismo), construir los prompts con cuidado y medir resultados. Y sobre todo, hay que auditar, que es el punto que casi nadie cuenta y a la vez el más importante.
El problema que nadie ve: la inspección visual no escala
Cuando revisas diez documentos, los lees, y si el modelo se equivocó lo notas a ojo. Cuando son diez mil, eso se acaba. No vas a leer diez mil documentos para confirmar que el modelo no se equivocó, y si no puedes verificar el resultado, en realidad no tienes un resultado: tienes una corazonada cara. Esto ya lo vivimos antes, en otra ola tecnológica.
La lección de big data
Cuando los datos crecieron, pasó exactamente lo mismo. Durante años, analizar datos era abrir una planilla y mirarla fila por fila, ordenar, filtrar y revisar a ojo; funcionaba porque la escala lo permitía. Pero cuando los volúmenes explotaron, esa intuición artesanal dejó de servir, porque nadie puede mirar a ojo un millón de filas. Así que la disciplina cambió hacia el muestreo, la estadística, la validación y la detección de anomalías: dejamos de confiar en la inspección directa y empezamos a confiar en el método.
La IA a escala está exactamente en ese mismo punto de quiebre. El error es tratar diez mil documentos con la misma intuición con la que revisábamos diez, cuando la escala cambió y las herramientas tienen que cambiar con ella.
Por qué auditar IA es más difícil que auditar datos
Con big data, el dato era el dato: una vez validado, no mentía. Con IA generativa, en cambio, el sistema que produce los resultados también puede ser la fuente del error, y de formas que no son nada evidentes. Hay tres trampas concretas que aprendimos a vigilar.
La primera es que las alucinaciones se vuelven invisibles a escala. Una alucinación en un solo documento la cachas leyendo, pero una entre diez mil se cuela sin que nadie la vea, porque no grita: se disfraza de respuesta correcta. A escala, el riesgo no es que el modelo falle fuerte y obvio, sino que falle bajito y en silencio, en ese uno por ciento de casos que nunca vas a leer.
La segunda es que los modelos inventan cuando les pides un juicio cuantitativo. Para aritmética ya son razonablemente buenos, pero si le pides a un modelo que te dé un “puntaje”, un score o una calificación del uno al diez, ahí inventa con total confianza y te entrega un número que parece objetivo pero que en realidad salió de la nada. El problema es que un número se ve serio, se ve medible, y es justo donde menos puedes confiar.
La tercera es que paralelizar rompe la mirada holística. Para procesar a escala tienes que partir el problema, y cada agente termina viendo su pedazo de forma aislada; eso te da velocidad, pero crea un riesgo silencioso, porque si el análisis que necesitas es holístico, la suma de respuestas parciales correctas puede dar una conclusión global equivocada. Cada parte tiene razón y el todo está mal, y eso no es un problema del modelo sino de diseño.
Qué significa auditar de verdad
Auditar a esta escala no es revisar más rápido, es revisar de otra forma, y en la práctica significa varias cosas que trabajan en capas. La verificación cruzada implica no confiar en una sola pasada de un solo modelo, sino contrastar resultados entre enfoques distintos y mirar con lupa dónde no coinciden, porque ahí suele esconderse el error. Los agentes especializados que auditan a otros agentes nos permiten separar al que produce del que revisa, ya que un agente diseñado específicamente para buscar fallas encuentra cosas que el que generó el resultado nunca va a ver. El muestreo estadístico consiste en tomar muestras representativas y revisarlas a fondo para estimar dónde y cuánto se degrada la calidad, igual que en el control de calidad industrial. Y la orquestación medible y repetible es lo que evita que el proceso sea una caja negra que dio un resultado una vez: se trata de construir un sistema con trazabilidad, donde puedas reconstruir cómo se llegó a cada conclusión.
Nada de esto es magia. Es ingeniería de sistemas aplicada a un componente que, a diferencia del software tradicional, es probabilístico.
El modelo va a mejorar. Eso no te salva.
Es cierto que los modelos van a seguir mejorando y que cada año son más capaces; eso es seguro. Pero apostar todo a que el próximo modelo resuelva tus problemas es una estrategia, no una solución, y además es una estrategia mala. Resolver problemas reales hoy no es esperar al siguiente modelo, sino saber lo que estás haciendo, entender las limitaciones de la herramienta que tienes en la mano y tener el método para verificar que lo que produjo realmente sirve.
La capacidad está disponible para todos, y por eso la diferencia entre un demo que impresiona y un sistema en el que puedes confiar no está en el modelo, sino en saber lo que estás haciendo.
Eso es lo que hacemos en Redstone Labs. Si estás peleando con un problema parecido, hablemos.