Siete lecciones de operar plataformas de IA

Construir un sistema con inteligencia artificial y mantenerlo funcionando durante meses enseñan cosas distintas, y la segunda lista es la útil para quien va a comprar. Las siete lecciones que siguen vienen de operar varias plataformas con IA en producción en varios países y sectores —legal, hotelería, contratación pública, inmobiliario, contabilidad, servicios—, y todas se detectaron midiendo o rompiendo algo, no razonando de antemano. Cada una termina en lo mismo: qué puede exigirle un comprador a su proveedor para no repetirla.

1. El corpus pesa más que el motor

La intuición del comprador es que la calidad de un sistema con IA depende del modelo. En nuestra operación, con frecuencia la calidad depende más de otra cosa: cómo se indexó la fuente. Fragmentos que cortan un artículo por la mitad, corpus sin la fecha de versión del documento, mezcla de jurisdicciones en un mismo índice, ausencia de identificador estable por fragmento: cualquiera de esos defectos arruina las respuestas por muy bueno que sea el modelo que las redacta.

La consecuencia práctica es que replicar un sistema a otro país es, sobre todo, un trabajo de corpus. Cuando la arquitectura separa limpiamente el corpus del motor, adaptar una plataforma a otra jurisdicción se mide en semanas y no en meses; cuando no lo hace, se reescribe. Y la consecuencia para el comprador es que la ficha del corpus —qué fuentes, de qué país, con qué fecha de corte y qué queda fuera— es más informativa que el nombre del modelo. Es también lo que pide la función MAP del marco de gestión de riesgo del NIST: establecer el contexto y los componentes antes de medir nada¹.

2. Varios agentes con alcance estrecho superan a uno genérico

Cada vez que intentamos que un solo asistente cubriera todo un proceso, el resultado fue peor que repartir el proceso entre varios con alcance definido. La razón no es de capacidad del modelo sino de gobernabilidad: un alcance estrecho permite escribir instrucciones precisas, conceder permisos mínimos y evaluar por tarea, con un conjunto de pruebas propio. Un agente genérico se evalúa mal —¿contra qué conjunto?—, se degrada cada vez que se le añade una función y obliga a concederle la unión de todos los permisos que cualquiera de sus funciones podría necesitar.

OWASP llama a ese último efecto agencia excesiva y lo incluye entre los riesgos principales de las aplicaciones con modelos de lenguaje². La versión operativa de la lección: la especialización no es elegancia arquitectónica, es contención de daño. Los controles concretos están en qué controles exigir a un agente de IA.

3. El aviso de una acción no es la acción

Es el fallo más caro que hemos tenido y el más difícil de ver, porque deja todos los indicadores en verde. Un asistente en un canal de mensajería anunciaba al cliente que haría llegar sus archivos a la persona responsable; un filtro por tipo de archivo, aguas abajo, los descartaba antes del envío. El aviso salía, el registro decía «notificación enviada», el panel no marcaba nada. El contenido no llegaba nunca.

La lección se generaliza mal si se queda en «revisen los filtros». La forma correcta es: la verificación debe alcanzar el efecto final, no el paso que el sistema controla. ¿Llegó el archivo? ¿Se creó el registro? ¿Lo recibió la persona? Un panel que solo observa lo que el propio sistema emite es un espejo, no un instrumento. Desde entonces cualquier promesa que un asistente pueda formular tiene que corresponder a una capacidad probada de extremo a extremo; si un filtro descarta algo, el asistente no puede ofrecerlo.

4. Un dato operativo escrito en varios lugares se desincroniza

Un horario de atención, un plazo, un precio o un cupo terminan escritos en la instrucción del asistente, en la web, en un archivo de configuración, en una respuesta guardada y en la cabeza de alguien. En cuanto cambia, se actualizan tres de los cinco. El sistema empieza entonces a prometer cosas que no puede cumplir, y el error parece de comportamiento cuando es de arquitectura de la información.

El arreglo tiene dos mitades y ambas son necesarias. La primera: una fuente única de la que todo lo demás derive, sin copias editables. La segunda, que se olvida: el motor que lee esa fuente tiene que entender todos sus casos. Nos ocurrió con un horario que incluía una jornada corta un día de la semana; la fuente era correcta y el analizador no sabía leer ese caso, así que el sistema seguía prometiendo disponibilidad fuera de hora. Un dato correcto mal interpretado produce el mismo daño que un dato incorrecto.

5. Desplegar no es que llegue

Publicar una versión nueva y comprobar que el servidor responde no significa que los usuarios la estén usando. Con aplicaciones instaladas o guardadas en el navegador, una parte de los usuarios sigue durante días con la versión anterior, y reporta como fallo algo ya corregido. El diagnóstico se vuelve imposible porque quien atiende y quien reporta están mirando dos programas distintos.

La solución es aburrida y funciona: un punto de consulta de versión, una comprobación periódica desde el cliente y una recarga forzada cuando hay diferencia, además de un aviso visible al usuario. Para el comprador, la pregunta que revela madurez es sencilla: «¿cómo saben ustedes qué versión está usando cada cliente en este momento?». Si no hay respuesta, tampoco habrá diagnóstico fiable cuando algo falle.

6. Filtrar vale más que buscar

En los sistemas que revisan grandes volúmenes de información —licitaciones, normativa, expedientes, anuncios—, el valor que el usuario percibe no viene de la exhaustividad de la búsqueda sino de la precisión del filtro. Devolver doscientos resultados pertinentes es una carga; devolver tres correctos, con el motivo por el que lo son y a tiempo, es el producto.

Esto tiene una consecuencia de diseño: la medición relevante no es cuántos documentos se indexaron sino cuántos de los pocos que se muestran resultan útiles, y cuántos útiles se perdieron. Y una consecuencia de venta: la demostración impresionante —«mire cuánto encuentra»— vende peor que la que enseña tres resultados con su justificación.

7. Publicar la medición cambia la conversación

Cuando empezamos a publicar la tasa de acierto y de error de nuestros sistemas con su método, su fecha y su intervalo, las conversaciones técnicas con compradores se acortaron³. No porque los números impresionen, sino porque cambian el terreno: se deja de discutir si el sistema «es confiable» y se pasa a discutir si el conjunto de evaluación es representativo, que es una conversación productiva.

Hay una razón de fondo para no afirmar ausencia de error. El NIST nombra confabulación al contenido falso producido con seguridad y pide medirlo, no negarlo⁴; y el estudio de Stanford RegLab sobre herramientas legales comerciales que se anunciaban libres de ese defecto encontró tasas de alucinación relevantes en todas ellas⁵. La lectura honesta de una batería sin fallos observados no es un cero: es una cota superior. El método completo está en cómo medimos las alucinaciones de una IA en producción, y el detalle de la verificación por cita, en cómo se verifica una cita generada por IA.

Qué exigir a partir de estas siete lecciones

Las siete se resumen en una idea: en un sistema con IA, casi todo lo que falla en producción falla fuera del modelo. Por eso el cuestionario de compra que sirve no pregunta por el modelo sino por el corpus, los permisos, el registro, la versión y la medición; las diez preguntas completas están en cómo evaluar a un proveedor de IA. Si quiere contrastar estas lecciones con un proyecto concreto, puede plantearnos el caso.