Lo que nadie pone en la presentación.

Serie «Entender la IA», nota 11 de 12. Las diez primeras han contado cómo funciona la tecnología, cómo se integra, cuánto cuesta, por qué fracasa, qué exige la ley y cómo se protege. Esta recoge lo que se queda fuera de todas esas conversaciones.

Sábado, 10:00, el salón de casa de la directora de operaciones de una empresa de ingeniería en Basilea. Hace once meses que el sistema de IA que lee y clasifica las solicitudes de los clientes está en producción. Funcionó. Las cifras del primer trimestre fueron las de la propuesta. Desde entonces nadie ha vuelto a mirarlas, porque no hubo quejas. Esta mañana, con un café, abre por curiosidad el registro y encuentra que, desde una noche de junio, el sistema clasifica como «consulta general» un tercio de lo que antes clasificaba como «urgente». Nadie cambió nada. O eso creen.

La escena es imaginaria. La degradación silenciosa, no, y es el primero de los diez puntos ciegos de esta nota. Los he reunido porque son las cosas que, en las reuniones, se consideran detalles sin importancia, y porque en los proyectos son casi siempre lo que decide el resultado al cabo de un año. Cada uno lleva su fuente, el síntoma por el que se reconoce y lo que hago al respecto. Empiezo por un texto de 1983 que debería leer cualquiera que vaya a automatizar algo.

Automatizar no elimina el trabajo humano. Lo cambia por otro más difícil, menos frecuente y peor pagado: vigilar.

1. Las ironías de la automatización, 1983.

En 1983, la psicóloga Lisanne Bainbridge publicó en la revista Automatica un artículo de seis páginas titulado «Ironies of Automation», sobre las salas de control de la industria. Describía dos ironías que hoy se leen como si hablaran de IA. La primera: quien diseña un sistema automático suele considerar al operador humano una fuente de errores, y por eso lo aparta; pero deja en sus manos precisamente las tareas que no supo automatizar, que son las más difíciles. La segunda: una persona que solo vigila un sistema que casi siempre funciona pierde la práctica, se aburre, deja de prestar atención, y es justamente esa persona desentrenada la que tiene que intervenir cuando el sistema falla, en el peor momento y sin contexto.

Traduzca eso al sistema de Basilea. El equipo que antes leía todas las solicitudes ahora solo ve el 15 % que el sistema no sabe clasificar: los casos raros, los ambiguos, los que exigen criterio. Es más difícil que antes, no más fácil, y se hace con menos práctica, porque los casos fáciles, los que enseñaban, ya no pasan por sus manos. Al cabo de un año, la persona nueva del equipo nunca ha visto un caso fácil. Remedio: rotar, cada semana, a alguien del equipo por una muestra de los casos que el sistema resuelve solo, y tratar la revisión como un puesto con formación propia, no como lo que queda.

2. La degradación silenciosa.

Un sistema de IA no se rompe: se desvía. El proveedor publica una versión nueva del modelo, un documento del archivo cambia, el tipo de solicitudes que llegan se desplaza con la temporada, y el sistema sigue respondiendo con la misma seguridad y otra calidad. Nadie se queja porque los errores de clasificación no producen quejas; producen retrasos que se atribuyen a otra cosa. Anthropic documenta que retira versiones de sus modelos con al menos sesenta días de aviso, y que las nuevas no se comportan igual que las viejas. Síntoma: nadie sabe decir cuándo se pasaron por última vez los cincuenta casos de oro. Remedio: pasarlos cada mes y con cada aviso del proveedor, y poner la cifra en el informe mensual de la dirección, al lado de la de ventas.

3. La misma pregunta, dos respuestas.

Lo conté en la nota 2 y lo repito porque es el punto ciego que más demostraciones salva y más producciones hunde: un modelo de lenguaje no responde siempre igual a la misma entrada, ni siquiera con la temperatura al mínimo; la propia documentación de Anthropic lo advierte, y en sus modelos más recientes el parámetro de temperatura ya ni siquiera se admite. Un proceso que necesita que la salida sea exactamente igual cada vez, un cálculo, una validación, un formato legal, no se hace con un modelo: se hace con software, y el modelo se usa antes, para ordenar la entrada. Síntoma: una demostración con tres ejemplos. Remedio: cincuenta casos, cada uno pasado tres veces, y una regla sobre qué variación es aceptable en cada paso.

4. El medio del documento.

En julio de 2023, investigadores de Stanford y de Berkeley midieron con precisión algo que cualquiera que haya usado un asistente intuye: cuando a un modelo se le dan muchos documentos, usa mejor la información que está al principio y al final, y peor la que queda en medio, incluso en los modelos diseñados para textos largos. El trabajo se titula «Lost in the Middle» y su consecuencia práctica es que un sistema que pega veinte contratos en una sola pregunta responde, con seguridad, a partir del primero y del último. Síntoma: el proveedor presume de que el modelo «lee todo su archivo de golpe». Remedio: recuperación con pocos documentos bien elegidos por pregunta, y un caso de oro que esconda el dato correcto en la página 14.

5. El idioma cuesta.

Un estudio de la Universidad de Washington de 2023 comparó cuántas fichas necesitan distintos idiomas para decir lo mismo, y encontró que muchos necesitan bastantes más que el inglés. Para una empresa suiza o española, eso significa que el mismo proceso cuesta más en alemán, en francés o en español que en inglés, y que, como el modelo ha visto menos texto en esos idiomas, acierta algo menos. Y hay una capa más fina: el suizo escrito, con sus formas propias, sus «ss» en vez de «ß» y sus cifras con apóstrofo, y el español de un cliente de Buenos Aires, no son el alemán ni el español de los manuales. Síntoma: los cincuenta casos están todos en el mismo idioma. Remedio: casos de oro en cada idioma en que la empresa atiende, en la proporción real, y el coste por caso medido por idioma.

6. Le da la razón.

El estudio de Anthropic de octubre de 2023 sobre la adulación, que cité en la nota 2, demostró que los cinco asistentes de primera línea que probó tendían a decir al usuario lo que quería oír, porque así se entrenan. En una empresa esto tiene una forma concreta y peligrosa: la persona que usa el asistente para «validar» una decisión ya tomada, y lo encuentra siempre de acuerdo. Un informe de riesgos redactado con IA por alguien que ya había decidido que el riesgo era bajo saldrá bien escrito y dirá que el riesgo es bajo. Síntoma: los análisis que llegan al comité nunca contradicen a quien los firma. Remedio: la regla del argumento en contra, por escrito: todo análisis con IA incluye una sección en la que se le ha pedido al modelo que lo refute.

7. Los datos que no estaban bien antes.

El 3 % de la Harvard Business Review que cité en la nota 6 es de 2017, y la mayoría de las empresas no han limpiado sus datos desde entonces; han añadido más. Un modelo de lenguaje es la forma más eficaz que se ha creado de convertir un dato malo en un texto convincente. El punto ciego no es la calidad de los datos, que todo el mundo admite; es creer que la IA la mejora. Síntoma: «el sistema aprenderá con el uso». Un sistema con recuperación no aprende nada: lee lo que hay. Remedio: un responsable con nombre por cada documento del archivo, y una fecha de caducidad en cada uno.

8. Lo que su equipo ya pega en otro sitio.

La encuesta de Microsoft y LinkedIn de 2024 que cité en las notas 4 y 6 lo dejó en cifras: tres de cada cuatro trabajadores del conocimiento usaban IA, y el 78 % con herramientas propias. El punto ciego es pensar que la política de la empresa sobre IA es la que está escrita. La política real es lo que la gente hace a las siete de la tarde con el informe que hay que entregar mañana. Síntoma: la empresa «no usa IA» y los textos de los correos han mejorado misteriosamente. Remedio: una herramienta oficial con los datos protegidos, una regla corta sobre lo que no se pega nunca y una amnistía: que contar lo que se usa no tenga coste.

9. Quién puede apagarlo, y qué pasa entonces.

Cuando un sistema automático lleva un año funcionando, la organización se adapta a él: el equipo que hacía el trabajo es más pequeño, el conocimiento del proceso vive en el archivo del sistema y nadie recuerda cómo se hacía a mano. Si el proveedor sube el precio, retira el modelo o cierra, el coste de cambiar es mucho mayor que el de la licencia. Es la partida 7 de la nota 7, la que casi nunca se negocia. Síntoma: nadie sabe responder a «¿qué haríamos el lunes si esto dejara de funcionar?». Remedio: un procedimiento manual escrito y probado una vez al año, conexiones con estándares abiertos y la propiedad de los cincuenta casos, de los documentos y de los registros siempre en manos de la empresa, en un formato que cualquiera pueda leer.

10. El coste de la atención.

El último punto ciego es el que une todos los demás. Cada una de las nueve cosas anteriores exige una persona que mire: que pase los casos, que lea el registro, que rote por la muestra, que pida el argumento en contra, que actualice el archivo. Esa atención es un coste pequeño, continuo y sin glamour, y es lo que separa el 5 % de proyectos con retorno del 95 % sin él. Cuando se recorta, no pasa nada durante meses. Después pasa una noche de junio. Síntoma: el sistema tiene un responsable técnico y ninguna hora reservada en la agenda de nadie. Remedio: dos horas a la semana, con nombre, en la agenda de alguien de negocio, con una lista de cinco comprobaciones. Es el seguro más barato que conozco.

1. Esta semana, 30 minutos

   Abra el registro

   Del sistema que lleve más tiempo en producción. Compare la distribución de este mes con la del primer mes. Lo que haya cambiado sin que nadie lo decidiera es su punto ciego número dos.

2. Esta semana

   Pregunte cuándo se pasaron los casos de oro

   Si la respuesta es una fecha de hace más de un mes, o un silencio, pásalos esta semana.

3. Este mes

   Haga el simulacro del lunes

   Qué haría la empresa si el sistema no arrancara. Escríbalo en una página. Si no cabe en una página, hay dependencia de más.

4. Este mes

   Ponga dos horas con nombre en una agenda

   De negocio, no de informática. Con las cinco comprobaciones escritas. Y mírelo usted una vez al trimestre.

Cómo lo planteo yo.

Cada sistema que entrego lleva un cuaderno de vigilancia: las cinco comprobaciones semanales, el calendario de los casos de oro, la lista de documentos con responsable y fecha, el procedimiento manual del lunes y la regla del argumento en contra. Es un documento de cuatro páginas y es la parte del proyecto que más valor conserva al cabo de un año. Lo escribo porque Bainbridge tenía razón en 1983 y la sigue teniendo: automatizar no quita trabajo humano; lo cambia por vigilancia, y la vigilancia hay que diseñarla.

De los diez puntos ciegos, ¿cuál le incomodó más al leerlo? Quizá no sea casualidad. Escríbalo en un papel y déjelo a la vista una semana.

Y una pregunta para el viernes: si mañana su sistema de IA dejara de funcionar un día entero, ¿sabría alguien en su empresa hacer ese trabajo a mano? ¿Y cuánto hace que nadie lo hace?

Siguiente y última nota: la IA para quien dirige. Qué debe saber, qué debe decidir y qué no debe delegar quien lleva una empresa, con las siete preguntas para el comité, el marco de referencia que usan los reguladores y una agenda para los próximos doce meses.