La IA no empieza por el modelo

La pregunta que una comparación no responde

Preguntar qué modelo es mejor solo resulta útil cuando se puede completar la frase: mejor para hacer qué, con qué información y dentro de qué límites. Sin esa referencia, la respuesta describe una preferencia tecnológica, no una decisión de diseño.

Una capacidad general y una función empresarial pertenecen a niveles distintos. Interpretar lenguaje es una capacidad. Identificar qué solicitudes necesitan revisión antes de incorporarse a una cola de trabajo es una función. La segunda incluye destinatarios, criterios, consecuencias y un lugar dentro de un proceso.

Ese lugar modifica lo que significa acertar. Una clasificación orientativa puede admitir correcciones posteriores. La misma clasificación, utilizada para impedir que una solicitud llegue a una persona, puede exigir otras garantías. La salida del modelo puede tener el mismo formato en ambos casos; el trabajo que sostiene es diferente.

Por eso, la primera descripción de una iniciativa debería poder entenderse sin mencionar un proveedor. Si el proyecto solo se explica nombrando una tecnología, falta explicitar qué valor se espera de ella. No es una prueba de que la iniciativa carezca de sentido, pero sí una señal de que todavía resulta difícil evaluarla.

La tecnología también puede abrir posibilidades que antes no existían. Explorar una capacidad nueva es legítimo. Incluso entonces conviene distinguir entre una exploración —averiguar qué es posible— y un compromiso de implantación —asumir que esa posibilidad resolverá un trabajo concreto—. Confundir ambas etapas convierte una hipótesis interesante en una expectativa que aún no tiene respaldo.

Definir el trabajo obliga a elegir

Expresiones como «mejorar la productividad» o «incorporar IA a operaciones» describen una intención. No establecen qué debe entregar un sistema. Para avanzar hay que delimitar una unidad de trabajo con un principio reconocible y un resultado que alguien pueda aceptar.

Esa delimitación contiene decisiones que no se pueden dejar enteramente al equipo técnico. ¿Se espera una propuesta o una resolución? ¿El resultado se entrega a una persona o modifica un registro? ¿Qué parte necesita juicio y qué parte debe cumplir una regla? ¿Quién puede declarar que el trabajo está terminado?

También hay que definir lo que queda fuera. Un sistema que prepara información para una decisión no tiene por qué asumir esa decisión. Ampliar su alcance puede ser razonable, pero cambia las condiciones de aceptación. La ambigüedad sobre esa frontera tiende a reaparecer durante el proyecto en forma de nuevas funciones, revisiones y desacuerdos.

Una definición útil expresa el resultado desde el punto de vista de quien lo recibe. «Generar un resumen» describe una actividad. «Permitir que una persona identifique los asuntos pendientes sin releer todo el expediente» describe una finalidad que ayuda a juzgar ese resumen. La finalidad tampoco basta por sí sola, pero permite preguntar qué información no puede perderse y cómo se comprobará.

Conviene conservar esta diferencia al presupuestar y revisar el trabajo. Si solo se acuerda la actividad, la entrega puede cumplir la especificación técnica y frustrar al usuario. Si solo se acuerda una aspiración amplia, el alcance puede crecer sin límite. El diseño necesita conectar ambas: una función acotada y una consecuencia esperada.

Las restricciones también definen la solución

Un requisito no es únicamente algo que el sistema debe hacer. Puede ser una condición que debe respetar mientras lo hace. El tiempo disponible, el acceso a los datos, la necesidad de revisión y el coste asumible forman parte del problema desde el principio.

Una respuesta excelente que llega después del momento de decisión puede resultar inútil. Una propuesta acertada que exige reconstruir manualmente sus fuentes puede trasladar más trabajo del que elimina. Una solución que depende de información inaccesible no se vuelve viable por disponer de un modelo más capaz.

Estas restricciones no deben tratarse como inconvenientes que se añaden al final. Determinan qué arquitectura tiene sentido explorar. El mismo objetivo puede llevar a una ayuda interactiva, un procesamiento por lotes o un flujo en el que la IA interviene solo en una etapa. La diferencia no está necesariamente en la inteligencia utilizada, sino en su encaje temporal y operativo.

Hay además restricciones que compiten. Reducir el tiempo de respuesta puede limitar las comprobaciones posibles. Ampliar la cobertura puede aumentar el volumen que requiere revisión. La organización necesita decidir qué compromisos acepta y cuáles invalidan el proyecto. El modelo no puede resolver por sí solo una preferencia que la empresa no ha expresado.

No hace falta convertir esta conversación en una especificación exhaustiva antes de probar nada. Basta con identificar qué condiciones podrían cambiar la decisión de continuar. Son las que merecen aparecer pronto en los experimentos, porque descubrirlas después de construir una integración completa resulta más costoso de corregir.

El modelo ocupa un lugar dentro del sistema

Una vez definido el trabajo, resulta más fácil distinguir dónde hace falta una capacidad de IA. Puede ser interpretar una entrada variable, producir una propuesta o seleccionar una herramienta. Otras partes pueden depender de consultas, reglas, cálculos y validaciones convencionales.

Esta separación evita atribuir al modelo responsabilidades que pertenecen a la aplicación. Un modelo puede sugerir una acción; comprobar si el usuario puede ejecutarla exige controles del sistema. Puede redactar una respuesta; obtener un dato vigente requiere una fuente accesible. Puede describir un resultado; comprobar que ese resultado existe requiere evidencia.

La cuestión no es reducir al mínimo el uso de IA por principio. Es asignar a cada pieza una función que se pueda entender y verificar. Si toda la solución se concentra en una instrucción extensa, las decisiones pueden quedar mezcladas: qué debe interpretar el modelo, qué debe obedecer la aplicación y qué debe decidir una persona.

Anthropic distingue entre flujos cuya secuencia se define en código y agentes en los que el modelo decide dinámicamente cómo avanzar. Esa distinción arquitectónica permite elegir cuánto control del recorrido se delega, en lugar de tratar todas las aplicaciones de IA como la misma clase de sistema.

Para una empresa, la consecuencia práctica es importante: necesitar lenguaje natural no implica necesitar autonomía sobre todo el proceso. Puede bastar una intervención limitada en un flujo existente. También puede hacer falta un agente, pero entonces su margen de decisión debe responder a la variabilidad del trabajo.

El diseño empieza a ser defendible cuando se puede explicar por qué cada capacidad está presente. Esa explicación ofrece una base para simplificar, sustituir o ampliar componentes sin perder de vista el resultado que deben sostener.

Elegir exige una referencia de calidad

Con el trabajo delimitado, la comparación de modelos deja de ser una competición abstracta. Se puede preguntar cuál cumple mejor una función concreta y qué recursos necesita para hacerlo dentro de las condiciones aceptadas.

La primera referencia puede ser el procedimiento actual, una solución basada en reglas o una versión sencilla de la aplicación. Su propósito es permitir una comparación con algo observable. Sin esa referencia, una mejora aparente puede provenir de haber cambiado la entrada, de haber seleccionado casos más fáciles o de haber desplazado tareas de revisión fuera de la medición.

La guía de ingeniería de aprendizaje automático de Google recomienda definir métricas pronto y comenzar con una infraestructura comprobable y un modelo sencillo. Aunque está escrita para sistemas de ML y no constituye una receta específica para IA generativa, expresa un criterio que sigue siendo pertinente: la complejidad necesita una referencia con la que demostrar su aportación.

En una prueba de selección deben aparecer las condiciones que hacen difícil el trabajo, además de las entradas bien preparadas. Si el sistema encontrará información incompleta, conviene observar cómo la maneja. Si una respuesta necesita revisión, hay que examinar qué recibe el revisor y cuánto trabajo conserva. Si una omisión resulta más grave que una respuesta excesiva, la comparación debe reflejar esa diferencia.

Esto no exige resolver toda la evaluación antes de elegir un modelo. Exige evitar una elección que no pueda justificarse con relación al uso. Una pequeña colección de situaciones bien definidas puede informar mejor una primera decisión que una demostración extensa sin criterios de aceptación.

Tampoco conviene interpretar el resultado como una propiedad permanente del modelo. La configuración, las instrucciones, la información disponible y las herramientas forman parte de la prueba. Lo que se ha observado es el comportamiento de una solución bajo unas condiciones, no una garantía aplicable a cualquier integración.

La definición también debe poder cambiar

Empezar por el trabajo no significa fijarlo una vez y prohibir que la tecnología lo cuestione. La experimentación puede revelar que una función es inviable, que el resultado deseado necesita otra formulación o que existe una oportunidad más valiosa.

Ese aprendizaje resulta útil cuando se conserva el vínculo entre la hipótesis inicial y lo descubierto. Si una propuesta requiere siempre una revisión completa, quizá el sistema siga aportando valor, pero ya no del modo previsto. Habrá que decidir si la preparación que realiza compensa ese trabajo residual. Cambiar el objetivo puede ser una buena decisión; ocultar el cambio impide saber qué se ha conseguido.

También puede ocurrir que el problema principal esté antes de la intervención del modelo. Si nadie mantiene la información de referencia o los equipos aplican criterios incompatibles, la iniciativa hará visible esa carencia. La respuesta puede consistir en acordar una política, mejorar una fuente o reorganizar una entrega antes de ampliar la automatización.

Hay un equilibrio entre definir y descubrir. Demasiada especificación temprana puede consolidar supuestos equivocados. Demasiada exploración sin criterios puede producir prototipos que nunca convergen. Un proyecto necesita suficiente definición para aprender y suficiente flexibilidad para incorporar lo aprendido.

Por eso, el primer entregable valioso no siempre es una aplicación. Puede ser una descripción del trabajo que conecte resultado, límites, información y responsabilidad con una hipótesis técnica comprobable. A partir de ahí, el modelo deja de ser el centro de una apuesta y se convierte en una elección que la organización puede explicar.