Los errores más caros al implantar agentes y LLM

·

En los proyectos de agentes de IA y modelos de lenguaje que llegan a producción, el coste real casi nunca aparece en el primer presupuesto. Aparece después: en las horas que tarda un equipo en deshacer lo que un agente hizo sin supervisión, en el cliente que deja de confiar en un chatbot tras una respuesta inventada, en el proyecto que se archiva porque nadie es capaz de explicar por qué el sistema decidió lo que decidió. Este artículo reúne los errores que más caros terminan saliendo al implantar agentes y LLM en la empresa, no porque la tecnología falle, sino porque el proceso alrededor de ella se salta pasos que parecen prescindibles hasta que dejan de serlo.

Por qué el coste de estos errores no es el que aparece en la factura

La magnitud del problema no es anecdótica. Según los hallazgos preliminares de The GenAI Divide: State of AI in Business 2025, el informe del proyecto NANDA del MIT Media Lab elaborado a partir de más de 300 iniciativas de IA divulgadas públicamente, entrevistas estructuradas con representantes de 52 organizaciones y 153 respuestas de altos directivos, el 95 % de las organizaciones no obtiene ningún retorno medible en la cuenta de resultados. El propio informe subraya que la causa no suele estar en la calidad del modelo: está en el enfoque con el que la empresa lo implanta.

Gartner llega a una conclusión parecida por otra vía. La consultora prevé que más del 40 % de los proyectos de IA agéntica se cancelarán antes de que acabe 2027, por costes que se disparan, valor de negocio que nunca llega a demostrarse o controles de riesgo que no se pusieron a tiempo. Los errores de este artículo son, en buena medida, las causas concretas detrás de esas cifras: ninguno exige un fallo exótico del modelo, todos son decisiones de diseño y de gobierno que se toman —o se dejan de tomar— antes de que el agente llegue a producción.

El mayor coste de un agente de IA casi nunca es el que figura en la factura del proveedor del modelo. Es el coste de deshacer una acción irreversible, el de perder la confianza de un cliente o el de descubrir seis meses después que nadie puede explicar por qué el sistema decidió lo que decidió.

1. Dar autonomía a un agente sin un punto de control humano

El error más caro con diferencia es dejar que un agente ejecute acciones irreversibles —enviar un correo a un cliente, cancelar un pedido, emitir un abono, modificar un registro del ERP— sin que exista un momento en el que una persona pueda revisar y confirmar antes de que la acción se dispare. Un agente puede interpretar mal una instrucción ambigua, actuar sobre datos desactualizados o simplemente equivocarse en un caso límite que nadie había previsto. Cuando eso ocurre en modo autónomo, deshacer el daño —recontactar al cliente, corregir el registro, explicar el error— cuesta muchísimo más —en tiempo y en reputación— que lo que se habría ahorrado saltándose la revisión.

La solución no es negar autonomía al agente en todo, sino graduarla según el riesgo de cada acción: lo reversible y de bajo impacto puede ejecutarse solo; lo irreversible o de alto impacto económico pasa por una confirmación humana, al menos hasta que el sistema acumule un historial suficiente para ganarse un margen mayor. Este es precisamente el diseño que trabajamos en nuestro servicio de agentes de IA para back office: definir qué puede decidir el agente solo y qué necesita pasar por una persona antes de ejecutarse. Cómo mantener esa supervisión ya en producción lo desarrollamos en nuestra guía sobre agentes de IA en producción.

2. Conectar el LLM a los datos de la empresa sin control de acceso por rol

Cuando un modelo se conecta a la documentación interna mediante RAG o a una base de datos completa sin filtrar los permisos por rol, cualquier persona que use el asistente puede acabar recibiendo información a la que no debería tener acceso: nóminas, contratos de otro departamento, datos de clientes que no le corresponden. El fallo no está en el modelo, está en la capa de recuperación: si el sistema de búsqueda no respeta los mismos permisos que el resto de las aplicaciones de la empresa, el LLM se convierte en un atajo para saltárselos sin que nadie lo note.

Esto no es solo un problema de seguridad interna: también lo es de privacidad. Un asistente que expone información personal a quien no debería verla puede convertir un proyecto de productividad en un incidente que hay que gestionar con el delegado de protección de datos (DPD), porque un acceso sin control vulnera el principio de integridad y confidencialidad (art. 5.1.f RGPD) y la obligación de seguridad del art. 32. El control de acceso debe implementarse en la capa de recuperación de información, no confiarse a que el modelo «se porte bien» en el prompt. Es el punto de partida de cualquier proyecto serio de RAG y búsqueda interna con IA bien planteado.

3. Confundir una demo convincente con un sistema evaluado

Una demo se prueba, casi siempre, con los mismos cinco o diez ejemplos elegidos porque funcionan bien. Producción trae los casos límite: la factura con un formato distinto, la pregunta formulada de una manera que nadie anticipó, el cliente que escribe con faltas de ortografía o mezcla dos idiomas. Sin un conjunto de evaluación que incluya deliberadamente esos casos difíciles, y sin medir el comportamiento del sistema de forma continua tras el lanzamiento, un agente puede empezar a fallar de forma silenciosa —dando respuestas plausibles pero incorrectas— durante semanas antes de que alguien se dé cuenta.

El coste de ese fallo silencioso no es solo el de corregirlo: es el de todas las decisiones que se tomaron mientras tanto sobre información errónea. Evaluar un agente antes y después de lanzarlo no es un paso opcional de calidad, es la única forma de saber si sigue haciendo lo que se supone que hace. Es el trabajo que cubre nuestro servicio de LLMOps y evaluación de agentes IA.

4. Tratar el agente como un proyecto que se cierra, no como un sistema que hay que mantener

Es habitual planificar la implantación de un agente como un proyecto con fecha de fin: se diseña, se prueba, se lanza y el equipo pasa a la siguiente prioridad. Pero un agente conectado a procesos reales de negocio vive en un entorno que cambia constantemente: cambian los productos, cambian las políticas de la empresa, cambia el catálogo, cambian las preguntas que hacen los clientes. Si nadie revisa periódicamente sus respuestas ni actualiza sus instrucciones, un sistema que funcionaba bien el día del lanzamiento se va degradando poco a poco, sin que ninguna alarma lo indique porque técnicamente sigue respondiendo.

Presupuestar solo el desarrollo inicial y no la operación continua —revisión de respuestas, ajuste de instrucciones, seguimiento del coste por consulta— es infravalorar sistemáticamente el coste real del proyecto. La partida de mantenimiento debe estar en el presupuesto desde el primer día, no descubrirse como un gasto sorpresa seis meses después.

5. Elegir el modelo por su fama, no por la tarea que tiene que resolver

No todas las tareas necesitan el modelo más grande y más caro del mercado. Clasificar un correo entrante, extraer un dato de una factura o resumir un documento corto son tareas que un modelo pequeño y barato resuelve igual de bien que uno de última generación, y a una fracción del coste por consulta cuando el volumen es alto. El error contrario también sale caro: usar un modelo pequeño para una tarea que exige razonamiento complejo, comparar varias fuentes o seguir instrucciones largas, y aceptar una tasa de error mayor solo por ahorrar en el coste por token.

La decisión correcta se toma tarea a tarea, no proyecto a proyecto: el mismo flujo de trabajo puede combinar un modelo económico para la clasificación inicial y uno más potente solo para los casos que de verdad lo requieren. Es el enfoque que aplicamos en proyectos de procesamiento inteligente de documentos, donde el volumen suele ser alto y el coste por documento procesado importa tanto como la precisión.

6. No asignar quién es responsable cuando el agente se equivoca

Cuando un agente toma una decisión equivocada, la primera pregunta que se hace la empresa —o el cliente afectado— es quién responde por ella. Si nadie ha definido de antemano quién revisa el comportamiento del sistema, quién puede pausarlo y qué registro queda de por qué actuó como actuó, esa pregunta no tiene respuesta rápida. La falta de trazabilidad no solo alarga la resolución de cada incidente: deja a la empresa sin forma de demostrar, ante un cliente o un auditor, que el sistema se diseñó y se supervisa con criterio.

Una gobernanza técnica clara —quién es responsable de cada agente, qué decisiones registra el sistema y cómo se audita— no es un trámite añadido al final del proyecto, es lo que permite escalarlo con confianza. Es el trabajo que cubre nuestro servicio de gobernanza técnica de IA, aplicable con independencia de cuál sea el marco normativo concreto que le resulte de aplicación a cada empresa.

7. Dejar que el «shadow AI» resuelva lo que el proyecto oficial no resuelve

Cuando el proyecto de IA oficial de la empresa tarda en llegar o es demasiado restrictivo, los empleados no dejan de buscar ayuda: empiezan a usar herramientas de IA generativa públicas por su cuenta, sin que el departamento de sistemas lo sepa ni lo autorice. El problema no es que usen IA, es que lo hacen pegando fragmentos de contratos, datos de clientes o cifras financieras en un chat sin control de acceso, sin trazabilidad y, muchas veces, sin saber qué ocurre con esa información una vez enviada. Es el tipo de fuga de datos que una auditoría interna rara vez detecta hasta que ya ha ocurrido varias veces.

La respuesta que funciona no es prohibir sin ofrecer alternativa —eso solo empuja el uso a la clandestinidad— sino dar a los equipos una vía autorizada y con permisos bien definidos para conectar la IA a las herramientas que ya usan, mediante integración MCP para empresas. Es el planteamiento detrás de nuestro servicio de AI Gateway corporativo: dar acceso controlado a los datos y sistemas correctos, en lugar de dejar que cada empleado resuelva el acceso por su cuenta.

8. Calcular el ROI del piloto sin proyectar el coste de escalarlo

Un piloto que procesa cincuenta casos a la semana con buenos resultados puede tener una economía completamente distinta cuando se escala a cinco mil. El coste por token, el tiempo de revisión humana de los casos dudosos y la infraestructura necesaria no crecen siempre de forma lineal: a veces crecen más rápido que el volumen, sobre todo si el diseño del piloto no se pensó para producción. Presentar el ROI del piloto como si fuera representativo del proyecto a escala completa es una de las formas más comunes de que un proyecto reciba luz verde para crecer y luego decepcione en números.

Antes de escalar cualquier agente o flujo con LLM conviene proyectar el coste unitario a los volúmenes reales de producción, no solo a los del piloto, y decidir con esos números —no con los del entusiasmo inicial— si merece la pena seguir adelante. Nuestro checklist de ROI de implantación de IA para pymes recoge los pasos para no saltarse esta cuenta.

Cómo evitar que estos errores lleguen a producción

Los ocho errores anteriores comparten un patrón: ninguno se detecta en la demo, todos se pagan en producción. Un checklist antes de dar por cerrado cualquier proyecto de agentes o LLM debería cubrir, como mínimo, estos puntos:

Incorporar estos puntos no exige retrasar el proyecto meses: exige tenerlos en cuenta desde el diseño inicial, que siempre sale más barato que añadirlos cuando el error ya ha costado algo.

Preguntas frecuentes

¿Cuál es el error más caro al implantar agentes de IA en una empresa?

El más caro suele ser dar autonomía a un agente para ejecutar acciones irreversibles —enviar un correo, cancelar un pedido, modificar un registro del ERP— sin un punto de control humano antes de que la acción se confirme. El coste de deshacer una acción ya ejecutada, con el cliente o el proveedor ya notificado, es mucho mayor que el coste de haber tardado unos segundos más en validarla.

¿Por qué fallan tantos pilotos de IA generativa aunque la demo funcione bien?

Porque una demo se prueba con casos elegidos a propósito para que salgan bien, mientras que producción trae los casos límite, los datos mal formateados y los usuarios que preguntan algo que nadie anticipó. Sin un conjunto de evaluación que incluya esos casos difíciles y sin medición continua tras el lanzamiento, el sistema puede fallar de forma silenciosa durante semanas antes de que alguien lo note.

¿Qué es el «shadow AI» y por qué es un riesgo caro?

Es el uso de herramientas de IA generativa públicas, no autorizadas por la empresa, por parte de empleados que necesitan resolver una tarea y no esperan a que el proyecto oficial esté listo. El riesgo es que información de clientes, contratos o datos financieros acabe pegada en un chat público sin control de acceso ni trazabilidad, lo que puede derivar en una brecha de protección de datos difícil de detectar a tiempo.

¿Cuánto hay que invertir en mantener un agente de IA después de lanzarlo?

Depende del volumen y la criticidad del proceso, pero como referencia general, un agente en producción necesita revisión periódica de sus respuestas, ajuste de instrucciones cuando cambian los productos o las políticas de la empresa, y monitorización de coste y de tasa de error. Tratarlo como un proyecto cerrado el día del lanzamiento es una de las causas más frecuentes de que un sistema que funcionaba bien al principio se degrade sin que nadie lo esté vigilando.

Fuentes consultadas

Este artículo es orientativo y no sustituye un análisis individualizado de los procesos y sistemas de tu empresa.

Si tu empresa está evaluando o ya tiene en marcha un proyecto de agentes de IA o LLM, el equipo de Summum IA puede revisar dónde está el riesgo real antes de que se convierta en un incidente caro, con apoyo en RAG con control de acceso y en gobernanza técnica de IA cuando el proyecto lo requiere.