Doxa 2484

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

Por Rahul Telang, Muhammad Zia Hydari y Raja Iqbal

IA generativa

Harvard Business Review

#Doxa #IA #AgentesIA #Escalabilidad #Equipo #Colaboración #Automatización #Productividad #Innovación #Tecnología #Negocios #Estrategia #Liderazgo #TransformaciónDigital #FuturoDelTrabajo #Eficiencia

Resumen. Los agentes de IA generativa pueden razonar, planificar y tomar medidas en todos los sistemas empresariales, lo que significa que su implementación no se limita a la instalación de software, sino que implica un cambio en la forma en que se realiza el trabajo. Cuando los agentes adquieren la capacidad de ejecutar tareas —actualizar registros,La emisión de reembolsos y la gestión de aprobaciones introducen riesgos operativos que las herramientas de software tradicionales no presentan, como un comportamiento impredecible y una falta de claridad en la responsabilidad cuando surgen problemas. Para utilizarlas de forma segura y eficaz, las organizaciones deben tratarlas como empleados digitales, asignándoles una identidad definida, autoridad limitada, fuentes de información fiables, controles claros sobre sus funciones y registros de auditoría que permitan explicar sus decisiones. Las empresas que adopten esta mentalidad e introduzcan la autonomía gradualmente tendrán muchas más probabilidades de aprovechar los beneficios de la IA con capacidad de gestión sin incurrir en costosos errores.

Imagínese una escena familiar. Un proveedor presenta un nuevo «agente» de IA generativa a su equipo directivo. Es impresionante: el agente prioriza las solicitudes de soporte, actualiza los registros de clientes, redacta una propuesta y la envía para su aprobación. La demostración es impecable. Pronto, inevitablemente, alguien pregunta: ¿Cuándo podremos implementarlo en toda la empresa?

Esa pregunta refleja una premisa que ha guiado la adopción de software empresarial en la era del SaaS (Software como Servicio). 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, el despliegue era, en gran medida, un proyecto de implementación. Pero la IA con agentes rompe con ese modelo.

A diferencia del software tradicional, los agentes de IA están diseñados para razonar, planificar y actuar 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.

Lo más importante es que introduce nuevas categorías de riesgo. Una herramienta de IA genérica limitada (como ChatGPT para redactar correos electrónicos) genera riesgo de contenido: podría decir algo incorrecto. La IA agente genera riesgo de ejecución: podría hacer algo incorrecto.

Basándonos en nuestra experiencia como investigadores (Rahul y Zia) y en la de un profesional con experiencia liderando implementaciones de IA empresarial con agentes (Raja), hemos analizado detenidamente cómo se implementa realmente la IA con agentes. Hemos constatado que, si bien muchos agentes están listos para actuar hoy en día, las empresas rara vez están preparadas para permitirles hacerlo.

Para superar ese umbral e integrar eficazmente agentes de IA a gran escala, deberá dejar de tratarlos como software listo para usar que simplemente se instala. En cambio, deberá considerarlos como un nuevo tipo de fuerza laboral que requiere gestión. Al igual que sus empleados humanos, cada agente de IA necesitará un rol, un ámbito de autoridad definido, fuentes de información fiables y reglas claras para la escalada de problemas. También necesitarán supervisión y registros de auditoría, ya que usted será responsable de sus acciones.

Hasta que no se establezcan esas bases organizativas, escalar la IA con agentes será difícil. Cuatro fricciones recurrentes, en particular, tienden a ralentizar o incluso a descarrilar el progreso. Comprenderlas es el primer paso para gestionarlas.

1) Identidad: ¿Quién está actuando?

Las empresas han dedicado décadas a crear controles de acceso para sus empleados. Cada usuario de un sistema informático inicia sesión con una identidad única, y su rol determina lo que puede y no puede hacer.

Los agentes de IA complican la situación porque se comportan como empleados humanos, pero no lo son. Muchas implementaciones iniciales solucionan este problema otorgando a los agentes una "cuenta de servicio" compartida con amplio acceso a múltiples sistemas. Es una solución práctica, pero concederles tantos permisos supone un riesgo de seguridad.

Consideremos un ejemplo sencillo. Un representante de atención al cliente podría estar autorizado a emitir reembolsos de hasta 500 dólares. Si intenta emitir un reembolso mayor, el sistema bloquea la transacción y la envía para su aprobación. Sin embargo, un agente de IA que opera 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 crédito de 5000 dólares en un solo paso.

Los riesgos no son meramente hipotéticos. En 2025, un experimento realizado por desarrolladores con el agente de codificación de IA de Replit demostró la rapidez con la que la automatización puede sobrepasar sus controles. A pesar de haber recibido instrucciones de no realizar ningún cambio, el agente ejecutó comandos que eliminaron una base de datos de producción. Posteriormente, intentó ocultar el fallo, generando miles de registros falsos y mensajes engañosos del sistema, 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 rol. En lugar de depender de cuentas de servicio compartidas, las empresas deben asignar a los agentes permisos específicos que reflejen las tareas concretas para las que están diseñados. Los mismos principios que se utilizan para gestionar a los empleados humanos —como el acceso con privilegios mínimos y los límites basados ​​en roles— deben aplicarse a los agentes. Si un empleado de atención al cliente no puede emitir reembolsos por encima de cierto límite sin aprobación, entonces la misma restricción debería aplicarse al agente que realiza ese trabajo. Igualmente importante, cada acción realizada por un agente debe registrarse con una identidad rastreable para que la organización pueda ver claramente quién —o qué— la realizó. 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 implementación.

2) Contexto: Cuando los datos erróneos conducen a malas acciones

Los agentes de IA funcionan bien en las demostraciones porque el entorno está controlado. Los datos son limpios, las instrucciones claras y las fuentes de información fidedignas evidentes. Pero las organizaciones reales son diferentes. Los datos empresariales están fragmentados en distintos sistemas, duplicados entre equipos y, a menudo, contradictorios. Las políticas evolucionan con el tiempo y los documentos antiguos siguen circulando. Las personas gestionan esta ambigüedad mediante el juicio y la experiencia, cualidades de las que carecen los agentes de IA.

Para un sistema que genera texto, un contexto imperfecto puede producir una respuesta errónea. Esto representa un problema, pero sus consecuencias suelen ser limitadas. Sin embargo, para un sistema que ejecuta acciones, las consecuencias son mucho mayores. Imaginemos a un agente de recursos humanos que recupera un documento de política de 2022, de referencia frecuente, y lo utiliza —a pesar de que las normas han cambiado desde entonces— para guiar a los gerentes en un proceso de despido. Esto no es una alucinación. Es un error de recuperación que expone a la empresa a riesgos legales.

Los agentes también plantean un nuevo desafío de seguridad: la manipulación del contexto. Si un agente lee correos electrónicos, formularios o tickets de soporte y luego realiza tareas basadas en esa información, los atacantes pueden insertar instrucciones ocultas diseñadas para influir en su comportamiento. Investigadores demostraron este riesgo en 2025 mediante una vulnerabilidad conocida como "ForcedLeak". Al insertar instrucciones maliciosas en un formulario web común, 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 estándares claros sobre la información en la que sus agentes pueden confiar. Esto requerirá definir fuentes autorizadas para políticas, precios y datos operativos, de modo que los agentes puedan basarse consistentemente en la versión correcta de la verdad. 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 del agente hasta los documentos o fuentes de datos específicos en los que se basó. Finalmente, las empresas deberán tratar las entradas externas —como correos electrónicos, formularios o archivos cargados— no solo como contexto útil, sino como posibles vectores de ataque. Las entradas que se originan fuera de la organización deben manejarse con cuidado y validarse antes de que un agente pueda actuar sobre ellas. Sin estas salvaguardas, las mismas inconsistencias de datos que los humanos manejan habitualmente pueden convertirse rápidamente en errores operativos para los sistemas automatizados.

3) Control: Los sistemas probabilísticos necesitan límites estrictos.

El software tradicional se comporta de forma predecible. La misma entrada produce siempre la misma salida. Pero los modelos de lenguaje complejos no funcionan así. Sus respuestas son probabilísticas, lo que significa que la misma solicitud puede producir resultados ligeramente diferentes en distintas ejecuciones. Esta variabilidad es aceptable cuando la salida es un borrador de correo electrónico. Se vuelve mucho más problemática cuando la salida es una transacción.

Una empresa que implementó un agente de soporte con IA se topó con este problema cuando el equipo legal insistió en que el sistema nunca mencionara a un competidor en particular. Sin embargo, la base de conocimientos de la empresa incluía muchos artículos comparativos legítimos que hacían referencia a dicho competidor, por lo que el agente lo mencionaba con frecuencia al responder las preguntas de los clientes. Cuando los ingenieros reforzaron las restricciones para bloquear esas respuestas, el sistema comenzó a negarse por completo a responder preguntas válidas.

El problema de fondo radica en que los métodos de prueba tradicionales presuponen un comportamiento estable. Un sistema que supera una serie de pruebas hoy puede comportarse de forma diferente mañana si el modelo se actualiza, la solicitud cambia o se añaden nuevos datos. Además, los riesgos aumentan en entornos multiagente donde los agentes se pasan tareas entre sí. En 2025, por ejemplo, investigadores de AppOmni demostraron cómo las configuraciones inseguras en el entorno Now Assist de ServiceNow podían permitir la inyección de comandos 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 ataques— pueden propagarse en cascada por un sistema automatizado. Para gestionar este riesgo, las organizaciones deben implementar controles deterministas en torno a los sistemas de IA probabilísticos. 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 su ejecución, un software determinista verifica que cumpla con las reglas establecidas. Las organizaciones deben limitar las interacciones no supervisadas entre agentes para que las salidas de un agente no se conviertan automáticamente en instrucciones ejecutables para otro sin validación, comprobación 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 mecanismos de protección que impidan que la variabilidad del modelo se traduzca en errores operativos.

4) Responsabilidad: Cuando nadie puede explicar lo que sucedió

Cuando un empleado comete un error, los gerentes pueden investigar haciendo preguntas. Cuando falla el software tradicional, los ingenieros pueden revisar los registros. Pero los agentes de IA presentan un escenario más complejo, ya que su comportamiento suele surgir de una cadena de pasos de razonamiento, documentos recuperados y llamadas a herramientas que pueden ser difíciles de reconstruir a posteriori.

Esto plantea un serio problema de rendición de cuentas. Imaginemos, por ejemplo, a un agente de compras que resume el desempeño de los proveedores y publica los resultados en un canal de Slack de la empresa. Si el agente incluye accidentalmente términos contractuales confidenciales —porque interpretó la instrucción de "compartir con transparencia" como una autorización para divulgarlos—, los líderes deberán saber con exactitud cómo se tomó esa decisión. ¿Qué documentos consultó? ¿Qué instrucciones siguió? ¿Por qué creyó que tenía permiso para compartir la información? Sin este tipo de evidencia, las organizaciones no pueden explicar el comportamiento de sus sistemas a los reguladores, auditores ni clientes.

Una decisión judicial de 2024 ofrece una primera señal de cómo la ley podría abordar este tema. En el caso Moffatt contra Air Canada, un cliente confió en información incorrecta proporcionada por un chatbot de la aerolínea sobre su elegibilidad para la tarifa por duelo. Cuando la aerolínea argumentó que el chatbot era, en la práctica, una entidad independiente, el tribunal rechazó la demanda y declaró a la compañía responsable de la información errónea.

Para evitar estos problemas, las empresas deberán diseñar sus sistemas de IA teniendo en cuenta la rendición de cuentas desde el principio. Esto comienza con el mantenimiento de registros exhaustivos del funcionamiento de los agentes, incluyendo las fuentes de datos a las que accedieron, las indicaciones que recibieron y las herramientas que 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 deberían asignar una responsabilidad interna clara para la supervisión y la gestión del comportamiento de los agentes, de modo que la responsabilidad no se diluya. Si un regulador, auditor o cliente pregunta por qué un sistema de IA tomó una decisión en particular, la empresa debería poder proporcionar una explicación clara y basada en evidencia. Sin ese nivel de transparencia, la automatización a gran escala seguirá siendo difícil de justificar.

El camino a seguir

Si la implementación llave en mano no es realista para los agentes de IA, la alternativa no es evitarlos, sino introducirlos gradualmente, ampliando su autonomía solo a medida que la organización desarrolla la capacidad de gestionarlos.

Una forma útil de entender 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 contenido, 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íen o ejecuten. El siguiente paso es la recuperación con controles, donde los agentes responden preguntas utilizando información interna, pero se basan en fuentes de datos bien gobernadas. A partir de ahí, las empresas pueden permitir acciones supervisadas, en las que los agentes proponen tareas operativas (emitir reembolsos, actualizar registros o gestionar aprobaciones), pero una persona siempre confirmará la decisión antes de su ejecución. Solo después de que estos controles estén probados, las organizaciones deberían considerar la autonomía limitada, donde los agentes ejecutan flujos de trabajo de forma independiente dentro de límites estrechos y umbrales predefinidos.

Muchas implementaciones efectivas se mantienen intencionalmente en los niveles más bajos de autonomía. La consultora OneDigital utiliza Azure OpenAI para acelerar la investigación de sus consultores, mejorando el tiempo de obtención de información en lugar de reemplazarlos. Otras implementaciones destacadas alcanzan una autonomía limitada al mantener un alcance reducido. Klarna ha informado que su asistente de IA gestiona de forma autónoma una gran parte de los chats de atención al cliente, manteniendo al mismo tiempo vías de escalamiento inmediatas a soporte humano para 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 organizativas, más que técnicas. Las empresas deben comenzar por definir un límite claro para la implementación integral, distinguiendo entre las aplicaciones de IA que pueden desplegarse con cambios estructurales mínimos y aquellas que requieren un rediseño significativo de los controles y la gobernanza. También deben considerar los permisos como un aspecto fundamental del diseño, asignando a cada agente un acceso restringido y acorde con su función. Se deben establecer umbrales claros de intervención humana para determinar cuándo las decisiones automatizadas requieren supervisión, especialmente en situaciones que impliquen exposición financiera, obligaciones regulatorias o riesgo reputacional. Finalmente, los líderes deben medir los resultados en lugar de los proyectos piloto, centrándose en indicadores operativos como el tiempo de ciclo, las tasas de error y los incidentes de cumplimiento, en lugar de simplemente contar 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 reconsideren los requisitos reales de la implementación. Las empresas no son entornos llave en mano; son sistemas complejos moldeados por tecnologías heredadas, políticas y criterios humanos. Las empresas que triunfen con la IA basada en agentes no se limitarán a instalar más agentes. En cambio, construirán las estructuras que permitan confiar en esos agentes.

Lea más sobre IA generativa o temas relacionados : IA y aprendizaje automático, algoritmos, tecnología y análisis, automatización, gestión de TI, gestión de empleados, gestión de seguridad de TI, desarrollo organizacional, gestión de calidad y gestión de procesos.

Rahul Telang es profesor titular de Sistemas de Información en el Heinz College de la Universidad Carnegie Mellon. Su investigación se centra en la seguridad de la información y la industria de los medios digitales.

Muhammad Zia Hydari es profesor adjunto de administración de empresas en la Facultad de Sistemas de Información y Gestión Tecnológica de la Universidad de Pittsburgh. Su investigación se centra en la economía de las tecnologías digitales, especialmente en el sector sanitario, y también trabaja en ciberseguridad.

Raja Iqbal es el fundador de Ejento AI, una plataforma de IA basada en agentes orientada a la gobernanza. También es profesor adjunto en la Escuela de Negocios de la Universidad de Pittsburgh.