Modelos frontera de IA: cómo seleccionar tecnología para un proceso empresarial

Un proceso empresarial rara vez es una sola tarea. «Atender reclamaciones» puede descomponerse en leer el mensaje, identificar el pedido, clasificar el motivo, consultar el historial, proponer una respuesta y decidir si se abona. Cada paso tiene requisitos distintos, y solo algunos necesitan un modelo de lenguaje. Consultar el historial es una consulta a una base de datos; decidir un abono puede ser una regla de negocio con aprobación humana.

Para cada paso donde se plantee usar un modelo, conviene dejar por escrito:

• Entrada y salida esperadas: qué recibe el modelo y en qué formato debe responder (texto libre, una categoría de una lista cerrada, un JSON con campos concretos).
• Qué es una respuesta correcta y quién puede juzgarlo: un experto del área, una regla verificable o una comparación con un dato conocido.
• Qué ocurre si se equivoca: si el error lo detecta una persona antes de que tenga efecto o si llega directamente a un cliente, a un sistema o a una decisión.
• Volumen y ritmo: cuántas peticiones al día, con qué picos y si alguien espera la respuesta en pantalla o puede procesarse por lotes.
• Datos implicados: si hay datos personales, secretos comerciales o información sujeta a restricciones contractuales.

Esa ficha cambia la conversación. Una clasificación entre doce categorías con respuesta estructurada es un problema muy distinto de redactar un informe técnico a partir de cuarenta páginas, y probablemente no necesite el mismo modelo.

Las pruebas de referencia públicas (benchmarks) sirven para hacerse una idea general y para descartar opciones claramente insuficientes. Pero miden tareas genéricas, con datos que no son los tuyos, y algunos modelos pueden haber visto esas pruebas durante el entrenamiento. Una buena puntuación en un examen de matemáticas o de programación no dice cómo se comportará el modelo leyendo vuestros albaranes o vuestras reclamaciones.

Lo que sí aporta información es un conjunto de evaluación propio: entre unas decenas y unos centenares de casos reales, anonimizados si hace falta, con la respuesta correcta validada por quien conoce el proceso. Debe incluir casos fáciles, casos difíciles, casos ambiguos y casos que el sistema debería rechazar. Con ese conjunto se comparan varios candidatos en igualdad de condiciones, con las mismas instrucciones y el mismo formato de salida.

• Mide por separado cada tipo de error: una categoría equivocada no es lo mismo que una respuesta inventada o un formato inválido.
• Repite la evaluación varias veces: los modelos no son deterministas y una diferencia pequeña entre dos candidatos puede ser ruido.
• Guarda el conjunto y los resultados: servirán para comprobar el sistema cuando el proveedor publique una versión nueva o retire la actual.
• Revisa a mano una muestra de respuestas aunque las métricas parezcan buenas; hay errores que solo se ven leyendo.

Marcos de gestión de riesgos como el AI RMF del NIST, de aplicación voluntaria, insisten en esta idea: medir el comportamiento del sistema en su contexto de uso y volver a medirlo a lo largo del tiempo, no solo en el momento de elegirlo.

Las tarifas de los proveedores cambian a menudo y dependen del volumen, por lo que no tiene sentido comparar precios en una guía. Lo que sí es estable es la forma de calcular: el coste relevante no es el de cada llamada, sino el de cada tarea completada con la calidad exigida. Un modelo más barato por petición que necesita reintentos, instrucciones más largas o más revisión humana puede salir más caro en conjunto.

Con la evaluación propia en marcha, es fácil registrar para cada candidato el consumo medio por caso, el tiempo de respuesta en el caso típico y en el peor caso razonable, y la proporción de respuestas que hay que corregir. Esos tres datos, multiplicados por el volumen previsto, dan una estimación mucho más útil que cualquier tabla de precios.

La latencia importa según quién espere. Un técnico que consulta en pantalla tolera pocos segundos; un proceso nocturno que clasifica documentos puede esperar mucho más y aprovechar modalidades de procesamiento por lotes si el proveedor las ofrece. También conviene prever los límites de uso: qué pasa si en un pico se alcanza el máximo de peticiones permitido y cómo se degrada el servicio.

Cuando el modelo se consume como servicio, los datos de cada petición salen de vuestra infraestructura. Antes de elegir hay que leer las condiciones contractuales concretas de la modalidad que se va a usar, que pueden variar entre la versión de consumo y la empresarial de un mismo proveedor:

• Si las entradas y salidas se usan para entrenar modelos y si eso se puede desactivar por contrato.
• Cuánto tiempo se conservan las peticiones y con qué finalidad (por ejemplo, detección de abusos).
• En qué regiones se procesan y almacenan los datos, y si es posible fijar una región concreta.
• Qué subencargados intervienen y si hay transferencias internacionales de datos personales.
• Qué compromisos de disponibilidad existen y qué ocurre ante una incidencia de seguridad.

Si los datos no pueden salir de vuestra infraestructura por motivos legales, contractuales o de confidencialidad, la elección se reduce a modelos que podáis ejecutar en entornos propios o dedicados, con sus propios límites de calidad y de operación. Lo tratamos en la guía sobre modelos de lenguaje locales y privados. La valoración jurídica de cada flujo de datos corresponde a la empresa y a sus asesores.

Los proveedores publican versiones nuevas, cambian el comportamiento de las existentes y retiran las antiguas con un calendario que no controláis. Un sistema construido alrededor de las particularidades de un modelo concreto puede tener que rehacerse en parte cuando ese modelo desaparezca. No se trata de evitar a los proveedores, sino de que cambiar sea un trabajo acotado.

• Una capa propia de acceso al modelo, de modo que el resto de la aplicación no dependa de la interfaz de un proveedor concreto.
• Instrucciones, ejemplos y esquemas de salida versionados junto al código, no dispersos en consolas externas.
• Salidas validadas contra un esquema antes de usarlas, para que un cambio de comportamiento se detecte como error y no como dato erróneo; OWASP incluye el manejo inadecuado de las salidas entre los riesgos principales de las aplicaciones con modelos de lenguaje.
• El conjunto de evaluación propio como prueba de regresión: cualquier modelo candidato debe superarlo antes de sustituir al actual.
• Fijar versiones concretas del modelo cuando el proveedor lo permita, en lugar de alias que cambian solos.

Supongamos, como ejemplo ilustrativo, una distribuidora que recibe varios cientos de correos al día y quiere clasificarlos en diez motivos y extraer el número de pedido. El equipo prepara trescientos correos reales anonimizados, con el motivo y el pedido correctos. Prueba tres candidatos: un modelo frontera, un modelo intermedio del mismo proveedor y un modelo de pesos abiertos ejecutado en un servidor dedicado.

En este escenario imaginario, los tres extraen bien el número de pedido, porque es un patrón muy reconocible; las diferencias aparecen en los correos con varios motivos mezclados. La decisión podría ser usar el modelo intermedio para el caso general y enviar a revisión humana los correos donde el modelo indique baja confianza o detecte más de un motivo. El modelo frontera quedaría como alternativa evaluada, lista para entrar si cambian las necesidades.

1. ¿Está descrita la tarea con su entrada, su salida y el coste de un error?
2. ¿Existe un conjunto de evaluación propio validado por quien conoce el proceso?
3. ¿Se ha calculado el coste y la latencia por tarea resuelta, incluida la revisión humana?
4. ¿Se han leído las condiciones de datos de la modalidad contratada y se ha valorado su encaje legal?
5. ¿Podría sustituirse el modelo en semanas, y no en meses, si el proveedor lo retira?

Si alguna respuesta es negativa, el siguiente paso no es firmar con un proveedor, sino completar esa pieza. Si quieres plantear la evaluación de un proceso concreto, podemos ayudarte a definir la tarea, preparar el conjunto de prueba y comparar opciones antes de comprometer la arquitectura.