Agentes de IA: cinco fallos típicos que pueden salir caros

Parece mentira, pero ya estamos dejando atrás la IA generativa y entrando en la IA agéntica y el 35% de las empresas ya la emplean. Y esto cambia, otra vez (un poco en realidad), la conversación. Ya no hablamos solo de usar un modelo para redactar un texto, resumir documentos y extraer conclusiones, o generar imágenes para redes sociales. Hablamos de sistemas capaces de actuar con cierta autonomía dentro de procesos reales.

Las posibilidades son muchas y muy tangibles que van desde gestionar el correo y la agenda, priorizar potenciales clientes, a responder mensajes o comentarios en redes sociales, hasta ejecutar tareas en herramientas internas, generar y enviar facturas o propuestas, producir contenido, o asistir en contextos más delicados como la gestión de alumnos o pacientes. Todo ello a una velocidad y escala que ningún equipo humano puede igualar (al menos en rapidez).

Precisamente ahí está la tentación, la miel en el panal: ahorrar tiempo en tareas de bajo valor a un coste marginal. Basta pasar cinco minutos en LinkedIn o YouTube para sentir que o automatizas todo o estás tirando tu tiempo a la trituradora de la felicidad y tranquilidad. Y ahí es donde creo que está el riesgo de todos estos mensajes, lo que no se cuenta (porque no se sabe). No porque la IA sea peligrosa en abstracto, sino por cómo se integra y se gobierna. Se habla mucho de beneficios, como si un agente fuese una capa más de software que simplemente hace cosas, pero rara vez se aborda como lo que es: un actor dentro de un proceso del que alguien responde. Trabaja con información (personal, empresarial, confidencial), infiere conclusiones y produce efectos en clientes, empleados, operaciones y, en más ocasiones de las que uno piensa, en derechos de terceros.

Con esa premisa, merece la pena mirar el despliegue con una visión más amplia que la del tutorial rápido. Porque los problemas no suelen venir del diseño del uso y de las expectativas puestas en él. Y se repiten con una regularidad casi incómoda.

1. Creer que todo se queda en casa
El primer error es asumir, casi por inercia, que los datos se procesan dentro del entorno de la empresa. En la práctica, muchas arquitecturas implican llamadas a servicios externos, procesamiento en infraestructuras del proveedor, subencargados y, en algunos casos, flujos que cruzan fronteras.

El problema es que el dato deja de estar donde se cree. Un ejemplo habitual es automatizar el correo para hacer seguimiento de propuestas o priorizar oportunidades, lo que implica tratar datos personales y, a menudo, información especialmente sensible (know-how, pricing, estrategia comercial o propiedad intelectual), en sistemas que dan acceso amplio a tercer al buzón, con procesamiento por otros terceros y, posiblemente, con transferencias internacionales de datos fuera de Europa (lo que ya sabemos que es un riesgo).

Cuando esa información sale de la esfera de control propio, ya no se está hablando solo de seguridad de la información y se abren riesgos mucho más grandes si hay datos personales. O dicho de otro modo, cuando el dato sale, el riesgo legal y operativo aumenta, porque el control se reduce.

2. Automatizar un sesgo y llamarlo eficiencia
El segundo error suele venir tapado dentro de la “optimización”, ya que el agente no inventa criterio, aprende patrones, que vienen de datos históricos, reglas implícitas y decisiones previas que, muchas veces, nadie se paró a cuestionar.

Pensemos en agentes para filtrar candidatos, priorizar leads, segmentar clientes o decidir a quién se le ofrece una condición u otra. En el dashboard todo es bonito y parece razonable: sube la conversión, baja el tiempo de respuesta, el proceso se ordena y se ahorra el tiempo prometido. Pero el problema es que automatizar no solo acelera, también fija el sesgo. Si el embudo ha premiado determinados perfiles, canales o zonas, el agente tenderá a replicarlo, y si el dato de partida está contaminado, el resultado no será neutral.

Además, hay un matiz adicional que suele olvidarse y es que a veces ni siquiera son sesgos propios. Son patrones heredados del modelo, del proveedor o de datos de terceros. Reglas que operan dentro del proceso sin que esté claro de dónde vienen ni por qué pesan en las decisiones.

Cuando el agente IA se usa en decisiones que afectan a personas, la consecuencia deja de ser estadística en el dashboard y pasa a ser jurídica y reputacional. La cuestión es que normalmente solo se detecta cuando alguien lo denuncia desde fuera o cuando el patrón ya es visible a escala. Y en ese punto el problema no es que el agente se equivoque un día con una persona, sino que ya se está equivocando en serie, en base a la autoridad que se le ha concedido. Lo delicado no es que exista sesgo. Es no saber cuál es, ni cuándo se activa.

3. Delegar decisiones sin poder explicarlas
El tercer error aparece cuando el agente empieza a decidir cosas relevantes y nadie dentro de la organización puede explicar por qué ha decidido lo que ha decidido. No porque el sistema falle o tenga un bug, sino porque funciona como una caja negra muy cómoda: entra información, sale una acción, y mientras todo parece ir bien y se ahorra el tiempo prometido a bajo coste, todo es correcto. Pues no.

Esto ocurre cuando se usan agentes para priorizar clientes, rechazar solicitudes, clasificar incidencias, decidir qué contenido se muestra a quién o activar alertas automáticas. Desde dentro, la excusa es muy previsible: «lo ha calculado el sistema», «es lo que recomienda el modelo», «sale del scoring». El problema es que, cuando alguien afectado pregunta por qué ha ocurrido algo, esa respuesta deja de ser suficiente.

Ahí es donde se produce el choque con la realidad jurídica y organizativa. Porque si no se puede explicar mínimamente la lógica de una decisión, tampoco se puede sostener, ni defender. Ni frente a un cliente, ni frente a un empleado, ni frente a al regulador. Hay que hacerse una pregunta incómoda, pero inevitable si no puedes explicar por qué el sistema decide como lo hace, ¿de verdad sigues siendo tú quien toma la decisión? Dependiendo de la respuesta, lo que era una ventaja operativa se convierte en una dependencia difícil de defender.

4. Delegar la decisión y olvidar la responsabilidad
Otro de los errores más comunes al desplegar agentes de IA es pensar que basta con añadir una mera validación humana al final del proceso para estar cubiertos, algo así como un checkbox, un botón que alguien debe pulsar para acreditar que se ha revisado el resultado por si acaso. Sobre el papel suena razonable, aunque muchas veces es solo una coartada.

Cuando un agente de IA realiza un scoring, una priorización o una recomendación y ese resultado se utiliza de forma determinante para tomar decisiones que afectan a personas, como conceder un servicio, descartar un perfil u ofrecer unas condiciones, el proceso funciona como una decisión automatizada, aunque formalmente exista un paso humano posterior. Esto es lo que ha dejado claro el TJUE en el asunto Schufa: si el resultado automático es decisivo, no estamos ante un mero apoyo, sino ante el núcleo de la decisión automatizada.

El RGPD no prohíbe la automatización, pero sí exige algo muy concreto: intervención humana real, explicabilidad y posibilidad de impugnación. Y en este contexto «real» significa significativo. O dicho de otro modo, que alguien pueda entender, cuestionar y corregir el resultado con criterio al final del proceso. No sirve darle siempre al botón sugerido por la IA. Esto tiene consecuencias jurídicas que conviene haber previsto antes, no cuando llegue la primera reclamación. Porque quien tendrá que explicarlo y sostenerlo no será el agente: será la empresa.

5. Desplegar sin gobernanza previa
El quinto error es el que suele estar detrás de todos los anteriores: desplegar IA como si fuera una funcionalidad más del stack, sin un marco de gobernanza previo. Se integra, se prueba, funciona, se pone en producción y se ha ahorrado tiempo y dinero. Pero si se deja fuera la gobernanza previa, entran dos variables que suelen llegar juntas: el riesgo reputacional y el sancionador.

Aquí aplican principalmente dos marcos regulatorios a la vez. Por un lado, el Reglamento de IA: si el agente se utiliza en empleo, educación, crédito, seguros, acceso a servicios esenciales o decisiones que afectan de forma relevante a personas, es fácil caer en supuestos de alto riesgo. Ahí se exigen obligaciones reforzadas de gestión del riesgo, documentación, calidad y gobernanza de datos, registros y trazabilidad, y supervisión humana efectiva. La Agencia Española de Supervisión de Inteligencia Artificial (AESIA) acaba de publicar unas guías interesantes relacionadas con estos temas y que trataré más adelante. Por otro lado, el Reglamento General de Protección de Datos: si hay datos personales, aplican base jurídica, minimización, transparencia, limitación de finalidad y seguridad. Y si el uso implica decisiones automatizadas con efectos jurídicos o similares, entran también las garantías de la supervisión humana en decisiones automatizadas y el derecho a entender y cuestionar el resultado. Lo importante es que estas obligaciones no compiten, sino que se acumulan, igual que las sanciones.

Sin gobernanza, se operar a ciegas, pues no se sabe qué agentes hay realmente desplegados, qué datos tratan, en qué proveedores se apoyan, qué decisiones influyen, qué trazabilidad existe, quién puede parar el sistema o cómo se sostiene una decisión cuando alguien la impugna. Y ahí llegan los sustos, a veces en forma de quejas, a veces en forma de brechas, a veces en forma de procedimiento sancionador.

Al final, los cinco errores anteriores responden al mismo patrón: se despliega rápido y se gobierna tarde.
La solución, por supuesto, no es sencilla ni rápida, ni se puede delegar en un agente de IA. Pasa por construir el modelo cuanto antes y empezando por los cimientos: primero hacer un inventario real de usos de IA (no me cansaré de decirlo); luego clasificar por riesgo y contexto de uso y terminar con las acciones de control antes de producción (revisar bases jurídicas y transparencia cuando hay datos personales, evaluaciones de impacto cuando proceda, contratos y supervisión de proveedores, seguridad y minimización, y supervisión humana capaz de intervenir con criterio, no solo de validar) son algunas de las cosas a tener en cuenta según el caso de uso.

La diferencia entre automatizar con cabeza y automatizar a ciegas no está en el modelo que se elija, sino en si se puede explicar, controlar y sostener lo que ese modelo hace, y hacerlo dentro del marco normativo europeo, cuando el negocio ya depende de ello. La regulación no viene a quitar la miel, sino a recordar que el panal tiene reglas, y que, sin control desde el diseño, los pinchazos suelen suelen venir si si se entra al panal con mano desnuda.