Los agentes de IA para empresas llevan dos años siendo la promesa de la temporada, y el resultado en la mayoría de las pymes que visitamos es una prueba abandonada y cierta desconfianza. Merece la pena separar qué parte de eso es la tecnología y qué parte es cómo se montó.
Escribimos esto desde el sitio desde el que trabajamos: probamos estas cosas contra procesos reales, descartamos la mayoría y llevamos a los clientes solo lo que aguanta. Lo que sigue es lo que hemos ido aprendiendo sobre dónde está hoy la línea entre lo que funciona y lo que todavía no.
Qué es un agente de IA y en qué se diferencia de un chatbot
Un chatbot responde. Le preguntas algo, genera una respuesta y ahí termina su intervención: lo que se haga después con esa respuesta es cosa tuya.
Un agente actúa. Recibe un objetivo, decide qué pasos hacen falta, los ejecuta usando las herramientas a las que tiene acceso, comprueba el resultado y vuelve a intentarlo si algo ha fallado. La diferencia no es de calidad de la conversación, sino de si el trabajo ocurre o no.
Un ejemplo del día a día. Pedirle a un chatbot que redacte el correo de seguimiento de un cliente te devuelve un texto que alguien tiene que copiar, personalizar con los datos reales y enviar. Un agente con acceso al sistema consulta el historial de ese cliente, comprueba qué se le prometió en la última llamada, redacta el correo con los datos correctos, lo deja en borrador para revisión y programa el recordatorio si no hay respuesta en una semana.
El segundo caso quita trabajo. El primero cambia de sitio una parte del trabajo y a veces ni eso.
En procesos de negocio, el sistema alrededor importa más que el modelo
Esta es probablemente la lección más útil que hemos sacado, y va en contra de casi todo el marketing del sector.
Cuando una prueba con agentes falla, la causa rara vez es que el modelo no fuera lo bastante bueno. Los modelos que hay disponibles hoy son sobradamente capaces para el trabajo administrativo de una pyme. Lo que falla es lo que rodea al modelo: a qué información llega, qué puede y no puede hacer, cómo se comprueba lo que ha hecho y quién lo mira antes de que salga de la casa.
Ese envoltorio es lo que en el laboratorio llamamos el sistema alrededor, y se descompone en cuatro piezas.
Acceso a datos
Un agente sin acceso a los datos reales de la empresa es un becario brillante al que no le has enseñado dónde está nada. Redactará algo plausible y genérico, que es exactamente lo que no sirve.
Aquí ha habido una mejora real en los últimos dos años. El Model Context Protocol, un estándar abierto para conectar aplicaciones de IA con fuentes de datos y herramientas, ha convertido en trabajo de días lo que antes era una integración a medida para cada sistema. No es magia: sigue haciendo falta que los datos estén ordenados en algún sitio. Pero la conexión dejó de ser el cuello de botella.
Permisos
La pregunta que casi nunca se hace en las demostraciones es qué pasa cuando el agente se equivoca. Y se equivoca.
La respuesta sensata es limitar de antemano lo que puede tocar. Redactar, sí. Enviar sin revisión a un cliente, no. Consultar el histórico de facturación, sí. Modificarlo, no. Un agente con permisos bien recortados comete errores baratos; uno con permisos amplios comete errores caros y a veces irreversibles.
Verificación
Un agente que hace tres pasos y no comprueba ninguno acumula el error del primero en los otros dos. Lo que distingue a un sistema que aguanta en producción es que cada paso deja constancia de lo que hizo y que hay una forma automática de detectar cuándo el resultado no tiene sentido: un campo vacío que debería tener contenido, una cifra fuera de rango, un nombre que no coincide con la ficha.
Supervisión
Y luego está la persona. No revisando todo, porque entonces no habríamos ahorrado nada, sino revisando lo que sale hacia fuera y lo que tiene consecuencias. En algunos casos esto es además una obligación legal, como explicamos en la guía del reglamento europeo de IA: cuando un sistema interviene en decisiones sobre personas, la supervisión humana efectiva no es opcional.
Qué tareas aguantan hoy los agentes de IA para empresas
Con ese sistema alrededor montado, hay cuatro familias de tareas que en nuestra experiencia funcionan de forma fiable en una empresa normal.
Redactar a partir de datos que ya existen. Correos de seguimiento, propuestas basadas en plantillas, informes para clientes, resúmenes de reunión, respuestas a preguntas frecuentes. Siempre en borrador, siempre con revisión, y aun así el ahorro es considerable porque escribir desde cero es lo que más cuesta.
Resumir para preparar una conversación. Quién es este cliente, qué historial tiene, de qué se habló la última vez, qué quedó pendiente. Tres líneas antes de una llamada valen más que un informe de treinta páginas que nadie abre.
Proponer el siguiente paso. Qué procesos llevan demasiados días parados, a qué contactos toca llamar esta semana, qué candidatos de la base encajan en la vacante nueva. El agente propone y ordena; la persona decide.
Mantener estados al día. Marcar como cerrado lo que ya se entregó, actualizar la ficha con lo que se habló, mover el proceso de fase cuando se cumple la condición. Es la tarea más aburrida de todas y la que más silenciosamente degrada un sistema cuando nadie la hace.
Qué todavía no
Cuatro casos donde, hoy por hoy, recomendamos no meter un agente.
Decisiones irreversibles sin revisión. Enviar dinero, borrar registros, comunicar algo a un cliente sin que nadie lo lea. El coste del error no compensa el tiempo ahorrado.
Juicio con consecuencias legales o sobre personas. Descartar a un candidato, denegar una ayuda, admitir o no a un alumno. El agente puede preparar el expediente; la decisión es humana, por criterio y por norma.
Procesos sin una fuente de verdad. Si el estado de un cliente vive en tres sitios que se contradicen, un agente elegirá uno de los tres y actuará con seguridad sobre información equivocada. Aquí hay que arreglar el proceso antes de automatizar nada.
Tareas donde un error pasa desapercibido. Si nadie va a notar que un dato salió mal hasta dentro de seis meses, no lo automatices todavía. La detección tardía convierte un error pequeño en un problema de confianza.
Cómo lo probamos antes de que llegue a un cliente
Nuestro método no tiene misterio y es deliberadamente aburrido.
Empezamos midiendo la tarea a mano: cuánto se tarda hoy, cuántas veces por semana se hace, qué porcentaje sale mal ya sin IA. Sin ese número de partida no hay forma de saber después si la cosa ha mejorado, y es el paso que casi todo el mundo se salta.
Después la ejecutamos en paralelo durante unas semanas. El agente hace su versión, la persona sigue haciendo la suya, y comparamos. Es más lento al principio y es la única manera de descubrir en qué casos concretos falla, que nunca son los que uno había previsto.
Solo entonces decidimos. Y bastantes veces la decisión es que no compensa: la tarea era menos frecuente de lo que parecía, o la revisión cuesta casi lo mismo que hacerlo a mano. Ese descarte es parte del trabajo, no un fracaso. Lo que sobrevive se incorpora al producto de código abierto que instalamos en los clientes, con los permisos y la verificación ya resueltos, para que nadie tenga que repetir la investigación por su cuenta.
Es la idea de fondo del laboratorio: que una empresa pueda beneficiarse de esto sin tener que convertirse en experta en una tecnología que cambia cada seis meses. Lo contamos entero en de la era digital a la era inteligente.
Si tienes en la cabeza una tarea repetitiva concreta y quieres saber si hoy aguantaría un agente, escríbenos y te lo decimos. Si la respuesta es que todavía no, también.
Puedes ver cómo se concreta esto por sector en soluciones.