Ahora parece que cualquier problema se arregla poniendo un agente de inteligencia artificial. Si llegan demasiados correos, proponemos que los gestione; si las reuniones se alargan, buscamos otro que las resuma; y si un proceso resulta confuso, imaginamos varios agentes coordinándose para resolverlo. Antes de elegir la tecnología, sin embargo, conviene hacer una pregunta menos vistosa: ¿qué merece la pena hacer y qué problema queremos resolver?
Automatizar una tarea no la convierte en útil. Podemos ejecutarla diez veces más rápido y seguir produciendo trabajo que nadie necesita. Por eso, el punto de partida no debería ser la herramienta que más impresiona en una demostración, sino el resultado que buscamos y la manera de comprobar si hemos mejorado.
No todo necesita autonomía
Una IA que redacta una respuesta y un sistema que decide cuándo enviarla no hacen el mismo trabajo. La primera prepara un texto que podemos revisar; el segundo actúa sobre el mundo y puede afectar a un cliente, una cuenta o una relación profesional. Esa diferencia cambia tanto los riesgos como los límites que necesitamos establecer.
En su guía de diseño, Anthropic distingue entre flujos de trabajo, cuyos pasos están definidos, y agentes que deciden cómo continuar y qué herramientas usar. Su recomendación inicial es buscar la solución más sencilla que funcione. En algunas tareas, eso significa utilizar un agente; en otras, basta con unas reglas y un modelo que resuelva una parte concreta del proceso.
Dar autonomía donde ya sabemos cuáles deben ser los pasos añade decisiones que antes no existían. Puede aportar flexibilidad, pero también coste, espera y errores. La cuestión no es si los agentes son buenos o malos, sino si esa flexibilidad compensa para el trabajo que tenemos delante.
Elegir un destino y redactar son problemas distintos
Imagina que entra una consulta de un cliente y hay que decidir si corresponde a facturación, soporte técnico o una persona que revise el caso. Después quizá debamos preparar una respuesta. Aunque ambas cosas formen parte de la misma gestión, elegir el destino y escribir el texto son dos problemas diferentes, y no tienen por qué resolverse con la misma herramienta.
Si el cliente ha seleccionado «problema con mi factura», una regla puede bastar para dirigir la consulta. Para los mensajes menos claros, un clasificador puede ayudar a distinguir entre opciones. Y para explicar la situación al cliente, sí puede tener sentido un modelo que genere lenguaje. Separar esos pasos permite entender qué esperamos de cada uno y dónde puede fallar.
Liquid AI presentó el 5 de octubre d1, un modelo de decisión que acepta texto e imágenes y devuelve probabilidades para respuestas posibles, sin generar una explicación en texto. Su propuesta ilustra una idea útil: a veces no queremos que la IA hable, sino que distinga entre unas opciones. Eso no significa que vaya a acertar siempre ni que una probabilidad alta sea una garantía. Los resultados publicados son pruebas del fabricante, no una demostración de que funcionará igual con nuestros clientes.
Una prueba pequeña enseña más que una promesa grande
Para empezar en un equipo, buscaría una tarea repetida, acotada y fácil de comprobar. Por ejemplo, preparar un primer resumen de una consulta y proponer a qué área enviarla, sin responder todavía al cliente. Antes de elegir una herramienta, dejaría por escrito qué información entra, qué debe salir, qué errores importan y quién revisará el resultado.
La prueba debería incluir casos reales que se puedan utilizar con permiso, retirando los datos sensibles que no hagan falta. Conviene combinar situaciones fáciles, ambiguas y aquellas que suelen romper el proceso. Después toca comparar con lo que ocurre hoy: cuánto tarda una persona sin ayuda, cuánto tarda con ella, cuántas propuestas corrige y si se pierde información importante.
El ahorro no es el tiempo que tarda el modelo en responder, sino el que queda después de revisar y arreglar. Si la IA produce algo enseguida, pero comprobarlo lleva más que hacerlo directamente, hemos cambiado de tarea sin ganar productividad. Medir esa diferencia evita confundir velocidad de generación con una mejora del trabajo.
La responsabilidad no se automatiza
También debemos decidir cuándo el sistema tiene que parar. Un caso dudoso, una acción que cuesta dinero o un dato que no debería salir requieren límites definidos antes de ponerlo en marcha. La documentación de seguridad de MCP insiste en reducir permisos y comprobar la autorización: conectar herramientas no elimina la necesidad de decidir qué puede hacer cada una.
Mi propuesta es empezar ayudando a decidir y ampliar solo cuando haya evidencias de que la tarea funciona. El resultado puede ser un agente, una combinación de reglas y modelos con revisión humana o incluso la eliminación de un paso innecesario. No necesitar ninguna IA también puede ser una mejora. ¿Qué tarea de tu semana permitiría hacer una prueba así y cómo sabrías que estás automatizando trabajo útil, en lugar de producir más rápido el ruido?
Deja una respuesta