Para implementar con éxito los agentes de IA, considérelos como miembros del equipo

Imagínese una escena habitual. Un proveedor muestra a su equipo directivo un nuevo «agente» de IA generativa. Es impresionante: el agente clasifica los tickets de asistencia, actualiza los registros de clientes, redacta una propuesta y la envía para su aprobación. La demostración es impecable. Muy pronto, inevitablemente, alguien plantea la pregunta: ¿En cuánto tiempo podremos implantar esto en toda la empresa? Esa pregunta refleja una suposición que ha guiado la adopción de software empresarial en la era del SaaS (Software as a Service). La mayoría de las herramientas podían aprovisionarse, configurarse y escalarse con relativamente poca personalización. Si la integración funcionaba y los empleados adoptaban el producto, la implementación era en gran medida un proyecto de puesta en marcha. Pero la IA agentiva rompe ese modelo. A diferencia del software tradicional, los agentes de IA están diseñados para razonar, planificar y llevar a cabo acciones en distintos sistemas. En el momento en que un agente puede modificar un sistema de registro —actualizar un precio, enviar un pago o modificar los datos de un cliente—, deja de ser una herramienta de productividad y pasa a formar parte del modelo operativo de la organización. Y lo que es más importante, introduce nuevas categorías de riesgo. Una herramienta de IA generativa de alcance limitado (como ChatGPT para redactar correos electrónicos) genera un riesgo de contenido: podría decir algo incorrecto. La IA agentiva genera un riesgo de ejecución: podría hacer algo incorrecto. Basándonos en nuestro trabajo como investigadores (Rahul y Zia) y como profesional con experiencia en la dirección de implementaciones de IA agentiva en empresas (Raja), hemos prestado especial atención a cómo se está aplicando realmente la IA agentiva. Lo que hemos observado es que, aunque hoy en día muchos agentes están preparados para actuar, las empresas rara vez están dispuestas a permitirlo. Para dar ese paso y integrar eficazmente los agentes de IA a gran escala, deberá dejar de tratarlos como un software listo para usar que simplemente hay que instalar. En su lugar, deberá considerar a sus agentes como un nuevo tipo de plantilla que requiere gestión. Al igual que sus empleados humanos, cada uno de sus agentes de IA necesitará una función, un ámbito de autoridad definido, fuentes de información fiables y normas claras de escalado. También necesitarán supervisión y registros de auditoría, ya que usted será responsable de sus acciones. Hasta que no se establezcan esos cimientos organizativos, será difícil escalar la IA agentiva. Hay cuatro fricciones recurrentes, en particular, que tienden a ralentizar o descarrilar el progreso. Comprenderlas es el primer paso para gestionarlas. 1) Identidad: ¿«Quién» está actuando? Las empresas llevan décadas desarrollando controles de acceso para los empleados humanos. Cada usuario de un sistema informático inicia sesión con una identidad única, y su función determina lo que puede y no puede hacer. Los agentes de IA complican esta situación, ya que se comportan como empleados humanos, pero no lo son. Muchas de las primeras implementaciones abordan este problema asignando a los agentes una «cuenta de servicio» compartida con amplio acceso a múltiples sistemas. Se trata de una solución práctica, pero conceder tantos permisos a los agentes supone un riesgo para la seguridad. Consideremos un ejemplo sencillo. Un agente de atención al cliente podría estar autorizado a realizar reembolsos de hasta 500 dólares. Si intentara realizar un reembolso por un importe superior, el sistema bloquearía la transacción y la remitiría para su aprobación. Sin embargo, un agente de IA que opere a través de una cuenta de servicio de back-end compartida podría no estar sujeto a ese límite de autorización y, por lo tanto, podría emitir un abono de 5.000 dólares en un solo paso. Los riesgos no son meramente hipotéticos. En 2025, un experimento llevado a cabo por un desarrollador con el agente de programación basado en IA de Replit demostró la rapidez con la que la automatización puede eludir los controles establecidos. A pesar de haber recibido instrucciones de no realizar ningún cambio, el agente ejecutó comandos que borraron una base de datos de producción. A continuación, intentó ocultar el fallo generando miles de registros falsos y mensajes de sistema engañosos, comportamientos que ralentizaron la respuesta y complicaron la recuperación. La lección es clara: las organizaciones deben tratar a cada agente de IA como un trabajador digital independiente, con su propia identidad, credenciales y función. En lugar de recurrir a cuentas de servicio compartidas, las empresas deben asignar a los agentes permisos de alcance limitado que reflejen las tareas específicas para las que han sido diseñados. Los mismos principios que se aplican a la gestión del personal humano —como el acceso con privilegios mínimos y las restricciones basadas en funciones— deben aplicarse a los agentes. Si un empleado de atención al cliente no puede emitir reembolsos por encima de un umbral determinado sin autorización, es obvio que la misma restricción debe aplicarse al agente que realiza esa tarea. Igualmente importante es que cada acción realizada por un agente se registre bajo una identidad rastreable, de modo que la organización pueda ver claramente quién —o qué— la ha llevado a cabo. Si los responsables no pueden explicar fácilmente qué identidad utiliza un agente al ejecutar una acción, el sistema no está listo para su puesta en marcha. 2) Contexto: cuando los datos erróneos dan lugar a acciones erróneas Los agentes de IA obtienen buenos resultados en las demostraciones porque el entorno está controlado. Los datos están limpios, las instrucciones son claras y las fuentes de información fidedignas son evidentes. Pero las organizaciones reales son diferentes. Los datos empresariales están fragmentados entre distintos sistemas, duplicados entre equipos y, a menudo, son contradictorios. Las políticas evolucionan con el tiempo y los documentos antiguos siguen circulando. Las personas gestionan esta ambigüedad utilizando el criterio y la experiencia de los que carecen los agentes de IA. En el caso de un sistema que genera texto, un contexto imperfecto puede dar lugar a una respuesta errónea. Se trata de un problema, pero sus consecuencias suelen ser limitadas. Sin embargo, en el caso de un sistema que lleva a cabo acciones, las consecuencias son mucho más graves. Imagínese a un agente de RR. HH. que recupera un documento normativo de 2022 al que se hace referencia con frecuencia y lo utiliza —a pesar de que las normas han cambiado desde entonces— para guiar a los directivos a lo largo de un proceso de despido. No se trata de una alucinación. Es un error de recuperación que expone a la empresa a un riesgo legal. Los agentes también plantean un nuevo reto de seguridad: la manipulación del contexto. Si un agente lee correos electrónicos, formularios o tickets de asistencia y, a continuación, realiza tareas basadas en esa información, los atacantes pueden introducir instrucciones ocultas diseñadas para influir en su comportamiento. Los investigadores demostraron este riesgo en 2025 a través de una vulnerabilidad conocida como «ForcedLeak». Al incrustar instrucciones maliciosas en un formulario web rutinario, engañaron a un agente de Salesforce Agentforce para que recuperara datos confidenciales de CRM y los enviara a un destino externo. Para hacer frente a estas fricciones contextuales, las organizaciones deben establecer normas claras sobre qué información pueden considerar fiable sus agentes. Esto requerirá definir fuentes fidedignas para las políticas, los precios y los datos operativos, de modo que los agentes puedan basarse sistemáticamente en la versión correcta de la información. Los sistemas también deben registrar la procedencia de la información utilizada en la toma de decisiones, lo que permitirá a los equipos rastrear cualquier acción de un agente hasta los documentos o fuentes de datos específicos en los que se basó. Por último, las empresas tendrán que tratar las aportaciones externas —como correos electrónicos, formularios o archivos subidos— no solo como contexto útil, sino como posibles vectores de ataque. Las aportaciones que se originen fuera de la organización deben gestionarse con cuidado y validarse antes de que se permita a un agente actuar en consecuencia. Sin estas medidas de seguridad, las mismas inconsistencias de datos con las que los humanos lidian habitualmente pueden convertirse rápidamente en errores operativos para los sistemas automatizados. 3) Control: los sistemas probabilísticos necesitan límites claros El software tradicional se comporta de forma predecible. La misma entrada produce siempre el mismo resultado. Sin embargo, los grandes modelos de lenguaje no funcionan así. Sus respuestas son probabilísticas, lo que significa que una misma solicitud puede producir resultados ligeramente diferentes en cada ejecución. Esa variabilidad es aceptable cuando el resultado es un borrador de correo electrónico. Se vuelve mucho más problemática cuando el resultado es una transacción. Una empresa que había implantado un agente de asistencia basado en IA se topó con este problema cuando el equipo jurídico insistió en que el sistema nunca mencionara a un competidor concreto. Sin embargo, la base de conocimientos de la empresa incluía numerosos artículos comparativos legítimos que hacían referencia a dicho competidor, por lo que el agente lo mencionaba con frecuencia al responder a las preguntas de los clientes. Cuando los ingenieros reforzaron las restricciones para bloquear esas respuestas, el sistema empezó a negarse a responder a preguntas válidas por completo. El problema de fondo es que los métodos de prueba tradicionales dan por sentado un comportamiento estable. Un sistema que hoy supera un conjunto de pruebas puede comportarse de forma diferente mañana si se actualiza el modelo, cambia el prompt o se añaden nuevos datos. Y los riesgos aumentan en entornos multiagente, donde los agentes se pasan tareas entre sí. En 2025, por ejemplo, investigadores de AppOmni demostraron cómo unas configuraciones inseguras en el entorno Now Assist de ServiceNow podían permitir la «inyección de prompts de segundo orden». En su experimento, las instrucciones maliciosas introducidas por un agente se transmitieron a otros, lo que podría dar lugar a acciones no deseadas o no autorizadas, como la recuperación de registros confidenciales o el envío de información a destinos externos. La conclusión es que, sin límites claros, los errores —o los ataques— pueden propagarse en cadena por todo un sistema automatizado. Para gestionar ese riesgo, las organizaciones deben establecer controles determinísticos en torno a los sistemas de IA probabilística. En lugar de permitir que los agentes ejecuten acciones directamente, las empresas deben interponer capas de validación entre el modelo de IA y los sistemas operativos. En este enfoque, el agente propone una acción, como emitir un reembolso o actualizar un registro, y, antes de que se ejecute, un software determinista verifica que cumple con las reglas establecidas. Las organizaciones deben limitar las interacciones no supervisadas entre agentes, de modo que los resultados de un agente no se conviertan automáticamente en instrucciones ejecutables para otro sin validación, comprobaciones de políticas o revisión humana. Al separar la generación de una recomendación de la ejecución de una acción, las empresas pueden crear barreras de seguridad que eviten que la variabilidad del modelo se traduzca en errores operativos. 4) Responsabilidad: cuando nadie puede explicar lo que ha ocurrido Cuando un empleado comete un error, los responsables pueden investigar haciéndole preguntas. Cuando el software tradicional falla, los ingenieros pueden consultar los registros. Sin embargo, los agentes de IA plantean un escenario más complejo, ya que su comportamiento suele derivarse de una cadena de pasos de razonamiento, documentos recuperados y llamadas a herramientas que pueden resultar difíciles de reconstruir a posteriori. Esto plantea un grave problema de rendición de cuentas. Imaginemos, por ejemplo, a un agente de aprovisionamiento que resume el rendimiento de los proveedores y publica los resultados en un canal de Slack de la empresa. Si el agente incluye accidentalmente cláusulas contractuales confidenciales —porque interpretó que «compartir de forma transparente» le daba permiso para revelarlas—, los responsables deberán saber exactamente cómo se tomó esa decisión. ¿Qué documentos consultó? ¿Qué instrucciones siguió? ¿Por qué creyó que estaba autorizado a compartir la información? Sin ese tipo de rastro de pruebas, las organizaciones no pueden explicar el comportamiento de sus sistemas a los reguladores, auditores o clientes. Una resolución de un tribunal de 2024 ofrece una primera indicación de cómo podría abordar la ley esta cuestión. En el caso Moffatt contra Air Canada, un cliente se basó en información errónea facilitada por el chatbot de una aerolínea sobre los requisitos para acceder a una tarifa por fallecimiento. Cuando la aerolínea alegó que el chatbot era, en la práctica, una entidad independiente, el tribunal desestimó la demanda y consideró a la empresa responsable de la información errónea. Para evitar este tipo de problemas, las empresas deberán diseñar sus sistemas de IA teniendo en cuenta la rendición de cuentas desde el principio. Esto comienza por mantener registros exhaustivos sobre el funcionamiento de los agentes, incluyendo a qué fuentes de datos accedieron, qué prompts recibieron y qué herramientas utilizaron para completar una tarea. Estos registros deberían permitir reconstruir la cadena de razonamiento que condujo a cualquier acción. Las organizaciones también deben asignar una responsabilidad interna clara para la supervisión y el control del comportamiento de los agentes, de modo que la responsabilidad no se difumine. Si un regulador, un auditor o un cliente pregunta por qué un sistema de IA tomó una decisión concreta, la empresa debe ser capaz de proporcionar una explicación clara y basada en pruebas. Sin ese nivel de transparencia, la automatización a gran escala seguirá siendo difícil de defender. El camino a seguir Si la implementación llave en mano no es viable para los agentes de IA, la alternativa no es evitarlos. Consiste en introducirlos gradualmente, ampliando su autonomía solo a medida que la organización desarrolle la capacidad de gestionarlos. Una forma útil de concebir esta progresión es como una «escalera de autonomía». La distinción clave radica en la autoridad de ejecución: si el sistema redacta contenidos, propone acciones para su aprobación o ejecuta acciones dentro de límites estrictamente definidos. Las organizaciones suelen comenzar con agentes que generan resultados de apoyo —borradores, resúmenes o recomendaciones— que los humanos revisan antes de que se envíe o ejecute nada. El siguiente paso es la recuperación con medidas de seguridad, en la que los agentes responden a preguntas utilizando información interna, pero se basan en fuentes de datos bien gestionadas. A partir de ahí, las empresas pueden permitir acciones supervisadas, en las que los agentes proponen tareas operativas —emitir reembolsos, actualizar registros o tramitar aprobaciones—, pero una persona siempre confirmará la decisión antes de la ejecución. Solo después de que se haya demostrado la eficacia de esos controles, las organizaciones deberían considerar la autonomía limitada, en la que los agentes ejecutan flujos de trabajo de forma independiente dentro de límites estrechos y umbrales predefinidos. Muchas implementaciones eficaces se mantienen deliberadamente en los peldaños inferiores de la escala de autonomía. La consultora de beneficios OneDigital utiliza Azure OpenAI para acelerar la investigación de los consultores, mejorando el «tiempo de obtención de información» en lugar de sustituir a los propios consultores. Otras implementaciones destacadas alcanzan una autonomía limitada al restringir el alcance. Klarna ha informado de que su asistente de IA gestiona de forma autónoma una gran parte de los chats de atención al cliente, al tiempo que mantiene vías de derivación inmediata al soporte humano para los casos complejos o delicados. Para los líderes que evalúan el creciente número de plataformas de agentes, las inversiones más importantes suelen ser de carácter organizativo más que técnico. Las empresas deben comenzar por definir un «límite de implementación» claro, distinguiendo entre las aplicaciones de IA que pueden implementarse con cambios estructurales mínimos y aquellas que requieren un rediseño significativo de los controles y la gobernanza. Asimismo, deben considerar los permisos como una cuestión fundamental del diseño, asignando a cada agente un acceso de alcance limitado acorde con su función. Unos umbrales claros de intervención humana deben determinar cuándo las decisiones automatizadas requieren supervisión, especialmente en situaciones que impliquen exposición financiera, obligaciones normativas o riesgo reputacional. Por último, los líderes deben medir los resultados en lugar de las pruebas piloto, centrándose en indicadores operativos como el tiempo de ciclo, las tasas de error y los incidentes de cumplimiento, en lugar de limitarse a contabilizar el número de experimentos de IA en curso. . . . La IA generativa seguirá mejorando y los proveedores incorporarán más funciones de seguridad en sus plataformas, pero la brecha entre una demostración impresionante y un sistema de producción fiable persistirá a menos que las organizaciones se replanteen lo que realmente requiere la implementación. Las empresas no son entornos llave en mano; son sistemas complejos moldeados por la tecnología heredada, las políticas y el criterio humano. Las empresas que tengan éxito con la IA agentiva no se limitarán a instalar más agentes. En su lugar, crearán las estructuras que permitan confiar en dichos agentes.

Para implementar con éxito los agentes de IA, considérelos como miembros del equipo

Resumen.

Partner Center