Más potente no siempre es mejor: cómo dimensionar la IA cuando entra en los procesos

Mientras la IA es una herramienta que uno consulta de vez en cuando, esa regla apenas cuesta nada. El problema aparece cuando la IA deja de ser una conversación y pasa a formar parte de un proceso: una tarea que se ejecuta cientos o miles de veces al mes, sin que nadie la mire en cada ejecución.

Ahí la elección del modelo, y de lo que le enviamos, deja de ser una preferencia personal. Se convierte en una decisión de organización, de costes y, como veremos, también jurídica.

El sesgo del «por si acaso»

En un despacho nadie pone a un socio a abrir el correo. No porque no sepa hacerlo, sino porque su tiempo es caro y la tarea no lo requiere. El correo lo filtra alguien que distingue lo urgente de lo rutinario, y solo lo que exige criterio llega a la mesa del socio.

Asignar el trabajo según su complejidad no es tacañería; es buena organización. Con la IA tendemos a olvidarlo porque damos por hecho que un modelo más capaz dará, en cualquier caso, una respuesta más correcta.

En las tareas acotadas esa suposición se sostiene peor de lo que parece. Decidir si un correo es una factura, una consulta de un cliente o publicidad no requiere razonamiento profundo. Requiere instrucciones claras, buenos ejemplos y una forma de comprobar el resultado.

Un modelo pequeño bien instruido puede hacerlo igual de bien, más rápido y por una fracción del precio. Si la tarea no necesitaba más capacidad, el modelo grande apenas añade seguridad; lo que añade es espera y coste.

La pregunta útil, por tanto, no es cuál es el mejor modelo disponible, sino qué capacidad necesita esta tarea para resolverse bien.

Lo que cuesta una tarea que se repite

Pensemos en una automatización que revisa el correo cada cinco minutos. Son 288 revisiones al día y 8.640 en un mes de treinta días, aunque en la mayoría no haya llegado nada relevante.

¿Tiene sentido activar en cada una un modelo de máxima capacidad y entregarle el historial completo del proyecto? Probablemente no. La primera operación, saber si hay mensajes nuevos, ni siquiera necesita IA.

Los servicios de correo ya permiten recibir avisos o consultar solo los cambios desde la última revisión, como las notificaciones push de Gmail o las consultas incrementales de Microsoft Graph. Es software convencional: barato, rápido y predecible.

El primer ahorro llega antes de elegir modelo. Consiste en no llamar a ninguno cuando no hace falta.

El contexto también se paga

Hay un malentendido frecuente sobre la ventana de contexto. Que un modelo admita un millón de tokens no significa que consuma un millón en cada llamada: se factura lo que efectivamente se le envía.

El problema surge cuando la automatización le reenvía, en cada ejecución, las instrucciones, las herramientas, todo el historial y los documentos anteriores. Entonces una tarea pequeña arrastra una entrada enorme.

Conservar la conversación en el servidor del proveedor tampoco lo evita necesariamente. En la API de OpenAI, encadenar respuestas con previous_response_id mantiene la continuidad, pero los tokens anteriores de la cadena se siguen contabilizando como entrada, según su documentación sobre el estado de la conversación.

Un ejemplo hipotético da la medida de la diferencia:

Son volúmenes de entrada, no facturas. El coste final depende del proveedor, del modelo, de las respuestas generadas y de la caché.

La caché abarata las partes del contexto que se repiten de forma idéntica al principio de cada llamada. Pero su aprovechamiento depende de condiciones que fija cada proveedor, como que el contenido inicial sea exactamente igual o que no pase demasiado tiempo entre llamadas (documentación de caché de OpenAI).

Y más contexto no garantiza mejor respuesta. Los modelos no aprovechan por igual toda la información que reciben: la información situada en mitad de contextos largos tiende a utilizarse peor (Liu et al., «Lost in the Middle»). Enviarlo todo «por si acaso» puede encarecer la tarea y, a la vez, hacerla menos fiable.

Una cuestión también jurídica

Para quienes trabajamos con datos de clientes, dimensionar el contexto no es solo una cuestión de eficiencia. El artículo 5.1.c) del RGPD exige que los datos personales sean adecuados, pertinentes y limitados a lo necesario para los fines del tratamiento. El artículo 25 obliga a incorporar esa limitación desde el diseño y por defecto.

Una automatización que envía cada cinco minutos todo el historial de un asunto a un proveedor externo, cuando le bastaría con el mensaje nuevo y unas pocas referencias, trata muchos más datos de los necesarios.

En el caso de los abogados, además, cada dato que sale del despacho sin necesidad amplía el perímetro sobre el que debemos garantizar el secreto profesional. El diseño ajustado es también el más fácil de justificar.

Aquí el modelo local cobra especial sentido. Si la clasificación se hace en la propia infraestructura del despacho, los datos no salen a un proveedor externo en esa fase. Solo lo que de verdad necesite un modelo mayor llega a terceros.

Cómo lo diseñaría

En el caso del correo, el proceso puede escalonarse como se escalona el trabajo en un despacho. Primero, software convencional detecta los mensajes nuevos. Después, un modelo pequeño, preferiblemente local (que no manda datos fuera), los clasifica y extrae lo esencial.

Solo los casos ambiguos o complejos pasan a un modelo más capaz. Y las decisiones sensibles, como aceptar condiciones, comprometer dinero o responder a un cliente en determinados asuntos, siguen pasando por una persona.

El sistema debería llevar, además, un registro de estado: qué mensajes ha procesado, qué ha concluido y qué queda pendiente. Con ese registro y unos pocos documentos pertinentes, la mayoría de las tareas pueden continuar sin reconstruir toda la conversación. Es lo que hace un buen expediente: nadie relee el asunto entero para archivar un escrito nuevo.

Nada de esto exime de probar. Elegir un modelo pequeño es una hipótesis que hay que contrastar con casos reales. Una clasificación barata que obliga a revisar todos los resultados acaba saliendo cara, y un modelo más potente puede compensar su precio si evita errores relevantes.

La propia guía de optimización de costes de OpenAI plantea los modelos menores siempre que mantengan la precisión necesaria. La métrica que me interesa no es el precio por llamada, sino lo que cuesta obtener un resultado correcto y aceptado, incluidos reintentos, correcciones y tiempo de revisión humana.

Saber cuándo basta con menos

A medida que se multiplican los proyectos y las automatizaciones, esta disciplina deja de ser opcional. Hay tareas que merecen el mejor modelo disponible y todo el contexto que podamos darle. Otras se resuelven con un modelo ligero y unas pocas líneas, y algunas no necesitan IA en absoluto.

Usar siempre el modelo más potente parece prudente, pero es la prudencia de quien no ha medido. La madurez en el uso de la IA consiste también en saber cuándo basta con menos.