Consultor funcional / Business Analyst: entender los LLM y los agentes sin programar

Una posición que se vuelve central

El consultor funcional o business analyst siempre ha ocupado la zona de traducción entre una necesidad de negocio y una realización técnica. Con los sistemas de IA esa zona se amplía: el negocio formula una expectativa en lenguaje natural y la técnica responde con un sistema cuyo comportamiento no está garantizado de antemano. Nadie ocupa esa frontera de forma natural. Ahí es exactamente donde el rol gana valor, siempre que se adquiera una base técnica suficiente para no quedarse de espectador.

Esta guía describe esa base: qué hay que entender de los LLM, del RAG y de los agentes para especificar bien, cómo encuadrar un caso de uso, cómo escribir requisitos verificables sobre un sistema probabilístico y cómo llevar una aceptación que tenga sentido.

La base técnica útil, sin programar

No se trata de convertirse en ingeniero. Se trata de entender lo suficiente del funcionamiento para hacer las preguntas correctas y detectar una promesa insostenible. Cuatro nociones cubren la gran mayoría de los proyectos de empresa.

• Un LLM produce texto verosímil a partir de un contexto: no consulta tu base de datos ni razona sobre reglas de negocio que nunca ha visto.
• El RAG consiste en recuperar documentos relevantes y entregarlos al modelo: la calidad de la respuesta depende primero de la búsqueda, no del modelo.
• Un agente encadena acciones —llamar a una herramienta, leer un sistema, escribir en algún sitio— con parte de decisión autónoma en cada paso.
• La evaluación consiste en medir la calidad de las respuestas sobre un conjunto de casos conocidos: sin ella no hay forma de saber si el sistema funciona.

Una comprobación sencilla: cuando una respuesta es falsa, ¿sabes distinguir un problema de búsqueda documental, uno de datos de origen, uno de formulación y uno de modelo? Esas cuatro causas exigen cuatro correcciones distintas.

Entender el RAG desde negocio

La mayoría de los proyectos de IA en empresa son proyectos de RAG: responder a partir de un corpus documental interno. Desde negocio, la dificultad casi nunca es el modelo. Es el corpus.

• El alcance documental: qué documentos entran, cuáles se excluyen, quién decide.
• Los derechos de acceso: dos usuarios distintos no deben ver las mismas respuestas si sus permisos difieren.
• La frescura: con qué frecuencia se actualiza el corpus y qué ocurre con las versiones caducadas.
• Los duplicados y versiones concurrentes: primera causa de respuestas contradictorias.
• Los documentos no textuales: tablas, escaneos, presentaciones, a menudo ilegibles para el sistema.

Son cuestiones de negocio, no técnicas. Un analista que encuadra bien el corpus aporta más a la calidad final que cualquier cambio de modelo.

Entender los agentes sin escribir código

Un agente es un sistema que decide una secuencia de acciones para alcanzar un objetivo. Donde un tratamiento clásico sigue un camino definido, un agente elige su camino. Esa diferencia tiene consecuencias directas sobre la especificación, la responsabilidad y el control.

• ¿Qué acciones puede ejecutar el agente y cuáles le están explícitamente prohibidas?
• ¿Qué acciones son reversibles y cuáles no? Estas últimas exigen validación humana.
• ¿Qué ocurre si el agente falla a mitad de una secuencia: reanudar, deshacer, alertar?
• ¿Qué traza queda de lo realizado, para auditoría o litigio?
• ¿Qué límites de volumen y de coste se aplican por ejecución?

Son exactamente las preguntas que un analista plantea en cualquier flujo de trabajo. La novedad es que el camino ya no se conoce de antemano: hay que especificar los límites en vez de la secuencia.

Encuadrar un caso de uso que se sostenga

Muchos proyectos fracasan antes de la primera línea de código porque el caso de uso nunca se formuló de forma evaluable. Un encuadre sólido se resume en seis puntos, todos formulables desde negocio.

• La tarea concreta: quién hace qué hoy, cuántas veces por semana, en cuánto tiempo.
• La salida esperada: cómo es una buena respuesta, con tres ejemplos reales.
• Los casos límite conocidos: situaciones en las que hasta una persona duda.
• El coste de un error: molesto, caro o inaceptable; determina todo el nivel de control.
• El dato disponible: existe, es accesible, está actualizado, quién lo autoriza.
• El criterio de parada: con qué resultado se decide continuar o abandonar.

Escribir requisitos sobre un sistema no determinista

El requisito clásico describe un comportamiento garantizado: en tal situación, el sistema hace exactamente esto. En un sistema de IA esa formulación es insostenible para la salida en sí. Sigue siendo válida para todo lo que rodea a la salida, y ahí es donde debe concentrarse la especificación.

• Lo que sigue siendo determinista: derechos de acceso, trazabilidad, formato de salida, acciones permitidas, registro.
• Lo que pasa a ser estadístico: la pertinencia de la respuesta, medida sobre un conjunto de casos de referencia.
• Lo que debe garantizarse de forma absoluta: ninguna acción irreversible sin validación, respeto de los permisos, cita de fuentes.
• Lo que debe diseñarse explícitamente: el comportamiento ante la duda, la falta de información o una pregunta fuera de alcance.

Formulación útil: «el sistema debe abstenerse en lugar de responder cuando no encuentra ninguna fuente pertinente» es un requisito verificable. «El sistema debe responder correctamente» no lo es.

Construir el conjunto de casos de referencia

Es la aportación más concreta y más infravalorada de un perfil funcional en un proyecto de IA. El conjunto de casos es lo que permite decir si el sistema avanza o retrocede. Nadie está mejor situado para construirlo: requiere conocimiento fino del negocio, no competencias técnicas.

1. 1

   Reunir casos reales

   Extraer solicitudes históricas —tickets, correos, expedientes— en vez de inventar ejemplos. Con cincuenta a cien casos basta para empezar.

2. 2

   Escribir la respuesta esperada

   Para cada caso, la respuesta que daría un buen profesional, con la fuente que la justifica.

3. 3

   Cubrir los casos difíciles

   Incluir deliberadamente preguntas ambiguas, casos sin respuesta, preguntas fuera de alcance y trampas conocidas.

4. 4

   Definir qué cuenta como fallo

   Respuesta falsa, respuesta sin fuente, pregunta fuera de alcance tratada como válida: precisar la gravedad de cada tipo.

5. 5

   Validarlo con negocio

   El conjunto de casos compromete a la organización. Debe revisarlo y aceptarlo el responsable del dominio, no solo el equipo de proyecto.

6. 6

   Mantenerlo

   Añadir los errores encontrados en producción. Un conjunto congelado pierde su valor en pocos meses.

Llevar una aceptación con sentido

La aceptación tradicional valida un comportamiento esperado, caso por caso, con veredicto binario. En un sistema de IA ese formato da falsa seguridad: diez pruebas superadas no dicen nada de la undécima. La aceptación debe cambiar de forma sin perder su función de decisión.

• Medir una tasa sobre el conjunto completo en lugar de validar pruebas aisladas.
• Fijar los umbrales antes de la ejecución, con negocio, y separar errores tolerables de errores bloqueantes.
• Probar los casos fuera de alcance tanto como los nominales: el rechazo correcto es un resultado esperado.
• Verificar los derechos de acceso con varios perfiles de usuario distintos.
• Repetir el mismo conjunto de casos en cada evolución: es la única protección contra regresiones silenciosas.

Una regresión en un sistema de IA no se manifiesta como un error técnico, sino como respuestas ligeramente peores que nadie nota durante semanas. La repetición sistemática del conjunto de casos es la única defensa.

Datos, permisos y cumplimiento: la parte de negocio

En un proyecto de IA las cuestiones de datos no son un trámite previo: determinan la viabilidad. Un perfil funcional las trata con naturalidad, y omitirlas es causa frecuente de cancelación al final del proyecto.

• Qué datos personales pueden entrar en el sistema y con qué base legal.
• Qué datos son tan confidenciales que nunca deben salir de ciertos perímetros.
• Cómo se traducen los permisos existentes en las respuestas del sistema.
• Cuánto tiempo se conservan los intercambios y quién puede consultarlos.
• Qué debe documentarse para una auditoría interna o una exigencia regulatoria sectorial.

Adopción: el verdadero factor de éxito

Un sistema correcto que nadie usa es un fracaso. La adopción de una herramienta de IA choca con dos reacciones opuestas e igual de problemáticas: el rechazo —«se equivoca, prefiero hacerlo yo»— y la aceptación ciega —«lo ha dicho, luego es cierto»—. El acompañamiento consiste en instalar un uso lúcido entre ambas.

• Explicar el alcance real desde la formación, incluido lo que la herramienta no sabe hacer.
• Mostrar errores típicos durante la demostración, no solo aciertos.
• Dar una consigna clara sobre lo que debe verificarse siempre.
• Habilitar un canal de aviso sencillo y aprovecharlo de forma visible.
• Seguir el uso real: frecuencia, abandono, correcciones aplicadas a las salidas.

Caso concreto: una petición mal especificada

Petición inicial recibida por el equipo de proyecto: «automatizar el tratamiento de reclamaciones de clientes con IA». Formulada así es inexplotable: no dice qué parte del tratamiento, sobre qué base, ni qué constituye un buen resultado.

El trabajo de encuadre la transforma en tres elementos distintos, de los cuales solo uno es realmente abordable a corto plazo:

• Clasificar la reclamación por motivo y urgencia: tarea repetitiva, datos históricos disponibles, error poco costoso y corregible. Abordable.
• Redactar un borrador de respuesta a partir de las condiciones contractuales: viable con cita de fuentes y validación humana sistemática, porque una respuesta falsa compromete a la empresa.
• Decidir un gesto comercial: decisión comprometedora, reglas de negocio variables, criterio humano. Fuera de alcance: el sistema, como mucho, prepara los elementos de decisión.

El encuadre precisa después: 200 reclamaciones históricas como conjunto de referencia, umbral del 90 % de clasificación correcta en los motivos principales, toda respuesta redactada validada antes de enviarse, trazabilidad completa de quién validó qué. Ese nivel de precisión no exige ninguna competencia de desarrollo, solo un método de análisis riguroso aplicado a un objeto nuevo.

La postura que marca la diferencia

El riesgo, para un perfil funcional, es quedarse en un papel de mensajero: transmitir a negocio lo que dice la técnica y a la técnica lo que quiere negocio. En un proyecto de IA esa posición aporta poco, porque ambos lados hablan de un objeto que cada uno entiende a medias.

• Pedir ver salidas reales del sistema, incluidas las fallidas, antes de validar una especificación.
• Rechazar un objetivo no medible y proponer su reformulación evaluable.
• Asumir el conjunto de casos de referencia como entregable de negocio, no como tarea de pruebas.
• Hacer visible el coste de un error, que determina todo el dispositivo de control.
• Decir que no a un caso de uso cuyo dato no existe: suele ser la aportación más útil.

Esta base no te convierte en ingeniero de IA y no es su objetivo. Te convierte en la persona capaz de transformar una intención difusa en un sistema que se puede evaluar, controlar y hacer adoptar, una capacidad de la que hoy disponen muy pocas organizaciones.

• Encuadre de casos de uso
• Cultura IA
• Adopción