Las dos maneras de trabajar con IA

Llevo meses intentando explicarle a clientes por qué la IA no les funciona como esperan y casi siempre acabo dibujando lo mismo en la pizarra: dos modos de trabajo que se confunden continuamente, y que piden cosas muy diferentes a la tecnología, a la organización y a las personas.

El primero es lo que la mayoría entiende por automatización. Un proceso se dispara, algo entra, algo sale. Puede tener IA dentro, como pieza de ese proceso, para clasificar un documento, generar un resumen, decidir si un cliente cumple un criterio, pero el flujo existe antes de que llegue la IA. Tiene principio y fin. Se puede dibujar en un diagrama. Es, en el fondo, lo que hacemos desde que existe el software: definir qué hay que hacer y hacer que la máquina lo haga sin que tenga que estar yo mirando.

El segundo es diferente. No empiezas con un flujo definido, empiezas con un problema o un objetivo, y trabajas junto con un agente hacia ese objetivo. El agente no ejecuta pasos fijos, decide en cada momento qué herramienta usar, qué preguntar, cómo avanzar. Tú aportas contexto, revisas, rediriges si hace falta. El resultado emerge del proceso, no está definido de antemano.

Cuándo usar cada uno

El modo procedimental funciona cuando puedes describir el trabajo con un diagrama de cajas. Cuando sabes exactamente qué pasa, en qué orden, y cuál es el resultado esperado. Si lo puedes escribir como una receta, lo puedes automatizar. La IA entra ahí (o no) como un ingrediente que hace algunos pasos mejor de lo que los haría el código tradicional.

El problema es que ese diagrama rara vez existe ya escrito. Los humanos somos buenos improvisando y navegando en el caos, no en documentar exactamente lo que hacemos. La mayor parte de las veces el proceso vive en la cabeza de las personas: quién decide qué, cuándo se hace una excepción, qué criterio aplica en cada caso. Es lo que se llama conocimiento tácito (ya hablamos de esto en el artículo sobre andamios). Para poder automatizar algo así primero hay que sacarlo de las cabezas, y eso a veces requiere sentar a varias personas juntas, hacerse las preguntas que no quieren plantearse, y reconstruir el flujo real, no el que aparece en el manual que nadie lee.

El trabajo asistido es para todo lo que no cabe en un diagrama, el trabajo de conocimiento de verdad, analizar una situación nueva, construir una propuesta, tomar decisiones con información incompleta, explorar un problema que no has visto antes. Tareas que un analista haría bien pero donde es imposible especificar de antemano todos los pasos.

Hay una señal infalible de que estás usando el modo equivocado: si llevas horas intentando definir el flujo de algo que en realidad varía cada vez, probablemente deberías trabajarlo con un agente. Y si llevas semanas haciendo siempre lo mismo con un agente, paso a paso, con los mismos pasos, probablemente deberías haberlo convertido ya en un procedimiento.

El compañero digital

Un agente de IA no es lo mismo que ChatGPT, aunque la confusión sea comprensible. ChatGPT responde preguntas, un agente puede usar herramientas, ejecutar acciones, encadenar razonamientos y completar objetivos, es la diferencia entre preguntarle a alguien cómo se va al aeropuerto y contratar a alguien que te gestione el viaje.

Trabajar tú solo con un agente es bastante natural cuando le coges el truco, defines el objetivo, aportas el contexto necesario, el agente actúa y tú revisas y corriges, peloteando continuamente. El agente tiene criterio propio, no solo sigue instrucciones, y por eso a veces propone algo que no esperabas, y a veces se equivoca de manera que no anticipabas.

Antes de seguir, vale la pena separar dos tipos de trabajo bastante distintos, aunque a primera vista parezcan lo mismo. Un agente que genera código y un agente que produce conocimiento, un análisis, una propuesta, una síntesis, siguen el mismo patrón general pero lo que le piden al humano en el loop es muy diferente. Con código puedes ejecutarlo y ver qué pasa, hay criterios concretos aunque no siempre evidentes (si escala, si tiene bugs sutiles que solo aparecen en producción). Con conocimiento no hay equivalente de los tests, la evaluación es tuya entera, requiere tu criterio y tu contexto, y si no tienes criterio suficiente para juzgar el output no puedes detectar cuándo el agente se equivoca y en qué.

La cosa se complica cuando empezamos a hacer crecer el sistema, y en especial cuando son varias personas trabajando con varios agentes. Una estructura de una persona con varios agentes especializados ya requiere pensarla bien, definir quién hace qué, cómo se pasan la información, quién tiene la última palabra. Pero el salto más grande llega cuando entran más personas con sus agentes, porque ya no es solo un problema técnico, es un problema de diseño organizativo. ¿Quién define los objetivos de cada agente? ¿Cómo se sincroniza el contexto? ¿Quién es responsable cuando el resultado no es el esperado? No hay aún respuestas claras, estamos en los primeros días, aunque ya estamos trabajando en fórmulas que terminarán dando frutos en no mucho tiempo.

Lo que pasa con el tiempo

El trabajo asistido descubre procedimientos.

Cuando llevas tiempo trabajando con un agente en un tipo de tarea, empiezas a ver partes que siempre se hacen igual. El agente siempre necesita los mismos datos, siempre hace los mismos pasos preliminares, siempre produce la misma estructura de resultado. Ese trozo, que al principio era parte de un trabajo exploratorio, ya tiene forma de procedimiento. Esos datos que no tenían forma ya los puedes sistematizar en un fichero. Los procesos que detectamos se pueden separar, automatizar y mover al primer modo.

Aunque no siempre hace falta ir tan lejos. A veces la solución intermedia es convertirlo en una tool o en una skill, una herramienta concreta que el agente puede llamar cuando la necesita (buscar en la base de clientes, crear una tarea, leer el contrato de un proveedor) o una secuencia de pasos encapsulada que invoca como unidad (preparar el resumen de una reunión, analizar una propuesta recibida, generar el borrador de una oferta). El agente sigue trabajando de forma asistida contigo en la conversación más amplia, pero esa parte ya está formalizada y no hay que redescubrirla cada vez. Es una fase intermedia entre el trabajo completamente exploratorio y la automatización completa, y en la práctica es donde acaban viviendo muchas de las piezas que mejor funcionan.

El trabajo asistido actúa como terreno de exploración. Donde no sabes cómo se hace algo, lo haces con el agente hasta que lo entiendes. Y cuando lo entiendes, lo puedes codificar. No es que uno de los dos modos sea mejor, es que funcionan en secuencia.

Una distinción que ayuda

El modo procedimental busca automatizar, hacer que algo se ejecute sin que esté yo en el loop. La eficiencia crece, la tarea desaparece de la vista de las personas, y muchos de estos procesos ya están automatizados sin que lo hayamos notado. Cuándo fue la última vez que decidiste tú la ruta para llegar a un sitio nuevo. El proceso de planificar el camino ya no existe, simplemente arrancas el coche y obedeces las instrucciones, y mucha gente ya no sería capaz de llegar a un sitio desconocido sin GPS (☝️). Lo mismo pasa con el filtro de spam, con el precio del vuelo que cambia cien veces al día según un algoritmo, con el feed que decide qué lees. No siempre ha sido para bien, pero hay procesos que tenían humanos dentro y los han perdido sin que nadie lo anunciase.

El trabajo asistido no busca eliminar al humano, sino ampliar lo que puede hacer. El analista no deja de trabajar, trabaja en problemas más complejos, más rápido, con más información disponible. En el primer caso el humano desaparece del proceso, en el segundo el humano crece con él.

Ninguno de los dos es superior, son herramientas distintas para tipos de trabajo distintos. El error es usarlos indistintamente, o creer que más automatización siempre es mejor. Hay trabajo que necesita estar en el loop humano, no porque no podamos automatizarlo, sino porque el humano en el loop es parte de lo que hace valioso el resultado.

La pregunta entonces no es “¿cómo automatizo esto?”, sino “¿en qué modo debería trabajar esto?”. A veces la respuesta es procedimiento. A veces es colaboración. Y a veces es empezar con colaboración hasta entender el procedimiento.

Algunos candidatos

Si trabajas en una empresa y quieres empezar a explorar esto en la práctica, hay procesos que casi todo el mundo tiene y que son buenos puntos de entrada porque se repiten, tienen un resultado claro y el coste del error es bajo.

El resumen de reunión con próximos pasos. Se hace después de cada reunión, siempre con la misma estructura, y en la mayoría de empresas o no se hace o se hace mal. Un agente con la transcripción puede extraer decisiones, responsables y fechas en menos de un minuto, y después de hacerlo unas cuantas veces sabes exactamente qué contexto necesita de antemano para hacerlo bien, lo que ya te lleva hacia una skill. Ya, te lo hace Teams o Meet, pero te aseguro de que si lo haces tú el resultado no tienen nada que ver.

El briefing previo a una reunión importante. Buscar en LinkedIn al contacto, repasar el historial de la relación, recordar los temas pendientes, identificar qué quieres conseguir. Todo el mundo lo hace de alguna manera, nadie lo tiene documentado. Es exploración hasta que lo repites suficientes veces y ves el patrón.

La actualización del CRM o de las notas de cliente después de una llamada. Un proceso que se hace mal o no se hace, que tiene un coste alto cuando falla (pierdes contexto, el siguiente que habla con ese cliente empieza de cero) y que con un agente y la transcripción de la llamada se puede hacer en segundos.

Mi candidato si tuviese que elegir uno para empezarsería el resumen de reunión. Está en todos los equipos, el dolor es reconocible, y en tres o cuatro iteraciones ya tienes suficiente patrón para saber si quieres formalizarlo más o dejarlo en modo asistido. El primer paso es el más sencillo posible: la próxima reunión que tengas, comparte la transcripción con un agente y pídele que extraiga decisiones y próximos pasos, sin más preparación. Pooc a poco vete afinado lo que necesitas y en qué formato lo quieres. Lo que aprendas en esas primeras veces vale más que cualquier diseño previo.

¿Que no sabes cómo aterrizar esto en tu caso concreto? La respuesta es obvia: cuéntaselo a tu modelo de IA favorito y pídele que te ayude a definir el problema y a dar con la solución. Empezar por ahí ya es practicar el modo asistido.

Puedes consultar este y otros artículos directamente en mi blog, Latente.