Antes de implementar un agente de IA, define qué está autorizado a hacer
Un agente de IA puede revisar una bandeja de entrada, recuperar información de los sistemas internos, redactar una respuesta y actualizar el expediente de un cliente antes de que un empleado haya revisado el primer paso. Esa rapidez es precisamente lo que hace que esta tecnología resulte atractiva. Y es también lo que hace que una implementación mal diseñada resulte más peligrosa que un chatbot convencional.
Por lo general, un chatbot espera a que se le plantee una pregunta y ofrece una respuesta. Se espera que un agente persiga un objetivo, seleccione herramientas y lleve a cabo una secuencia de acciones con una menor intervención humana. Una vez que obtiene acceso al correo electrónico, a documentos, a bases de datos o a aplicaciones empresariales, deja de comportarse como un asistente de redacción y empieza a funcionar más bien como un empleado junior con permisos de sistema.
Sin embargo, muchas empresas implementan agentes sin definir las condiciones que acompañarían a cualquier función desempeñada por una persona. Especifican lo que el sistema debe lograr, pero dejan en el aire su autoridad, sus límites y sus funciones de escalado. El resultado puede funcionar de manera impresionante durante una demostración, pero seguir siendo inadecuado para las operaciones reales. Antes de que un agente de IA se integre en un proceso empresarial, necesita el equivalente a una descripción del puesto.
Empieza con una tarea concreta
“Ayudar al equipo de ventas” no es una descripción de funciones útil ni para una persona ni para un agente de IA. No aclara qué tareas corresponden al puesto, qué decisiones puede tomar el agente ni cómo se evaluará el éxito.
Una tarea viable debe ser lo suficientemente específica como para que la empresa pueda comprobar si el agente la ha completado correctamente. Por ejemplo, podría consistir en elaborar un resumen matutino de las nuevas consultas, clasificar las solicitudes recibidas según un esquema aprobado o redactar borradores de correos electrónicos de seguimiento utilizando la información ya almacenada en el sistema de gestión de relaciones con los clientes.
Esta distinción es importante porque los objetivos generales animan al agente a interpretar su función. Una persona puede recurrir al conocimiento de la organización, al criterio social y a años de experiencia cuando una tarea resulta ambigua. Un agente de IA puede actuar basándose en información incompleta y, al mismo tiempo, presentar el resultado con una confianza injustificada.
Por lo tanto, las empresas deberían empezar por procesos que sean repetitivos, estén bien documentados y sean relativamente fáciles de revertir. Un agente puede asumir más responsabilidades una vez que haya demostrado un rendimiento fiable en condiciones reales. Empezar con un ámbito de actuación lo más amplio posible puede acelerar la fase piloto, pero también hace que los fallos sean más difíciles de comprender.
Un objetivo concreto no es sinónimo de falta de ambición. Es la base para una expansión controlada.
Definir a qué puede acceder el agente
Un agente solo puede actuar a través de los sistemas y la información de que dispone. Por lo tanto, el diseño del acceso es uno de los aspectos más importantes de la implementación.
Lo más práctico es conectar el agente a todo lo que pueda necesitar: correo electrónico, calendarios, almacenamiento en la nube, bases de conocimientos internas y software operativo. Esto reduce las dificultades durante el desarrollo, pero amplía considerablemente el margen de error del sistema.
El principio más seguro es el de «privilegio mínimo». El agente solo recibe el acceso necesario para la tarea que se le ha asignado, y nada más. Un asistente que prepare resúmenes para reuniones puede necesitar consultar las entradas del calendario y determinados documentos, pero no necesita permiso para eliminar archivos ni enviar mensajes. Un agente encargado de la tramitación de facturas puede necesitar acceso a las facturas recibidas y a las órdenes de compra, sin que por ello tenga visibilidad sobre todo el sistema financiero.
Los permisos de lectura y escritura deben tratarse por separado. Permitir que un agente recupere información supone un nivel de riesgo; permitirle modificar registros, transferir archivos o ponerse en contacto con terceros supone otro.
La empresa también debería determinar si el agente actúa a través de la cuenta de un empleado concreto o mediante su propia identidad técnica. Una identidad específica suele ser más fácil de supervisar, restringir y desactivar. De este modo, el agente se hace visible como un participante independiente, en lugar de permitir que sus acciones parezcan indistinguibles de las de un usuario humano.
Separar la preparación de la ejecución
Muchas tareas importantes relacionadas con la inteligencia artificial no requieren una actuación autónoma. El agente puede recopilar información, elaborar una recomendación o preparar el siguiente paso, dejando la ejecución en manos de un empleado.
Esta distinción resulta especialmente útil durante las primeras fases de la implementación. Un agente puede redactar una respuesta para un cliente, pero es una persona quien la envía. Puede identificar facturas que parecen incoherentes, pero es el equipo de finanzas quien decide si se debe bloquear el pago. Puede proponer una actualización de una base de datos, pero el cambio solo se aplica tras su aprobación.
A veces se considera que la revisión humana es un obstáculo para la automatización. En la práctica, permite a la empresa aprovechar la rapidez y, al mismo tiempo, aprender en qué aspectos el agente funciona de forma fiable y en cuáles no.
La aprobación no debe convertirse en un simple clic de rigor. El revisor necesita información suficiente para comprender qué ha hecho el agente, qué fuentes ha utilizado y en qué aspectos persiste la incertidumbre. Presentar una respuesta pulida sin este contexto fomenta el sesgo de automatización: la tendencia a aceptar una recomendación generada por una máquina simplemente porque parece completa.
A medida que aumenta la confianza, las acciones de bajo riesgo pueden aprobarse automáticamente, mientras que las decisiones de mayor trascendencia siguen estando sujetas a revisión. La autonomía debe ganarse tarea a tarea, en lugar de concedérsela al agente como una característica general.
Establecer límites claros para la toma de decisiones
Todo agente necesita límites en cuanto a las decisiones que puede tomar de forma independiente. Estos límites pueden basarse en el valor económico, la relevancia jurídica, la sensibilidad de los datos o el posible impacto en un cliente, un empleado o un proveedor.
A un agente de compras se le puede permitir volver a pedir materiales aprobados por debajo de un valor determinado, pero no se le permite seleccionar un nuevo proveedor. Un agente de atención al cliente puede resolver consultas rutinarias sobre entregas, mientras que debe derivar las reclamaciones relacionadas con indemnizaciones, amenazas legales o clientes vulnerables. Un agente de planificación puede proponer horarios para reuniones sin cancelar una cita externa ya confirmada.
Lo importante es que el límite sea operativo. Indicar al agente que derive los casos “importantes” o “sensibles” deja demasiado margen para la interpretación. La empresa debería definir criterios de activación observables: valores concretos, temas, categorías de cuentas, niveles de confianza o excepciones.
Los agentes también necesitan normas para hacer frente a instrucciones contradictorias. Un usuario puede pedir al sistema que realice una acción que exceda sus competencias. Un documento obtenido de Internet puede contener texto que intente anular las instrucciones originales del agente. Otra aplicación puede proporcionar datos incompletos o incoherentes.
El agente no debe resolver todos los conflictos por sí mismo. En determinadas circunstancias, lo más adecuado es detenerse y solicitar una decisión humana.
Las acciones prohibidas son tan importantes como las tareas asignadas
Una descripción de puesto convencional se centra en las responsabilidades. La especificación de un agente de IA también debe incluir una lista explícita de acciones prohibidas.
Se le puede prohibir al agente celebrar contratos, modificar datos bancarios, compartir datos personales, eliminar registros, ponerse en contacto con determinadas partes externas o tomar decisiones en materia de empleo. Tampoco podrá utilizar la información de un cliente para ayudar a otro ni transferir contenidos a un servicio no autorizado.
Estas prohibiciones deben aplicarse técnicamente siempre que sea posible. Una instrucción por escrito en la que se indique al agente que no borre archivos es menos eficaz que una cuenta que carezca de permiso para borrar. Las políticas son necesarias, pero la arquitectura del sistema ofrece un control más fiable.
La empresa también debería tener en cuenta las acciones indirectas. Un agente que no pueda transferir dinero podría, no obstante, modificar las instrucciones de pago en un sistema utilizado por otro proceso. Un asistente que no pueda publicar contenido externamente podría guardar dicho contenido en una carpeta que se publique automáticamente más adelante.
Para identificar estos efectos derivados es necesario comprender el flujo de trabajo en su totalidad, y no solo la interfaz inmediata del agente.
Proporciona al agente una vía de escalado
Los empleados humanos saben cuándo deben acudir a un responsable, consultar a un asesor jurídico o recurrir a un compañero con experiencia. Los agentes necesitan un sistema de escalación igualmente claro.
El sistema debe detectar las circunstancias en las que carece de información suficiente, se encuentra con una excepción o alcanza el límite de sus competencias. En ese caso, debe remitir el caso a una persona o equipo concreto, proporcionando el contexto suficiente para que puedan continuar con el trabajo.
La escalación cobra especial importancia cuando el agente trabaja fuera del horario laboral habitual. Un proceso que detecte una transacción potencialmente fraudulenta a medianoche necesita contar con reglas que determinen si hay que bloquearla, ponerla en cola para su revisión por la mañana o ponerse en contacto con un empleado de guardia.
La empresa también debe establecer unas expectativas en cuanto al servicio. Si el agente recurre a la escalación con demasiada frecuencia, los empleados pueden acabar convirtiéndose en un nivel de soporte permanente para una automatización que, en teoría, debía ahorrar tiempo. Si, por el contrario, recurre a la escalación con muy poca frecuencia, puede que actúe más allá de sus competencias.
El análisis de los patrones de escalado puede poner de manifiesto en qué casos es necesario aclarar las instrucciones, la calidad de los datos es deficiente o la tarea aún no es apta para la autonomía.
Decide cómo se identifica el agente
Las personas que interactúan con un agente de IA deberían saber, por regla general, que están tratando con uno. Esto es especialmente importante cuando el sistema se comunica con clientes, solicitantes, proveedores o empleados.
La identificación influye en la confianza y la responsabilidad. Un destinatario puede interpretar un mensaje de forma diferente cuando este se genera y envía automáticamente, en lugar de haber sido redactado por un empleado concreto. También es posible que necesite una forma sencilla de solicitar ayuda humana.
El agente no debe adoptar una identidad humana ficticia ni dar la impresión de que una persona ha revisado una comunicación cuando en realidad no ha sido así. Una empresa puede mantener un tono natural y profesional sin ocultar la naturaleza de la interacción.
La transparencia interna también es importante. Los empleados deben poder ver cuándo un agente ha creado una entrada en la base de datos, una recomendación o un documento. De lo contrario, los resultados se mezclan con el trabajo humano y resulta difícil rastrear los errores.
El registro de datos debe planificarse antes de que surja algún problema
Cuando un agente toma una decisión errónea, la empresa debe reconstruir lo que ocurrió. Para ello, no basta con conservar el resultado final. Entre los registros útiles pueden figurar las instrucciones que recibió el agente, la información a la que accedió, las herramientas que utilizó, las acciones que intentó llevar a cabo y las autorizaciones que obtuvo. El sistema también debería registrar los fallos, los intentos repetidos y cualquier cambio realizado tras la intervención humana.
Estos registros sirven de apoyo para las investigaciones de seguridad, la mejora de la calidad y el cumplimiento de las obligaciones normativas. Además, permiten a la empresa distinguir entre un error del modelo y unos datos de origen de mala calidad, unos permisos inadecuados o un flujo de trabajo ambiguo.
Sin embargo, el registro de datos plantea sus propias consideraciones. Los registros pueden contener indicaciones confidenciales, datos personales o documentos sensibles. Por lo tanto, conviene definir los plazos de conservación y los controles de acceso, en lugar de permitir que los historiales detallados de los agentes se acumulen indefinidamente.
La supervisión debe centrarse en los comportamientos que realmente importan: volúmenes inusuales, acceso a sistemas inesperados, fallos repetidos, aumento de los costes y acciones que se salen de los patrones habituales. Un registro que nadie revisa ofrece poca protección.
Establecer el estándar de rendimiento aceptable
Un agente puede parecer que ha tenido éxito porque ha completado la tarea sin que se haya producido ningún incidente evidente. Pero eso no es suficiente. La empresa debe establecer criterios cuantificables antes de la puesta en marcha. Entre ellos pueden figurar la precisión, el tiempo de ejecución, la tasa de escalado, el coste por tarea y el porcentaje de resultados que requieren corrección. Los procesos de alto riesgo pueden requerir umbrales más estrictos que las tareas administrativas de bajo impacto.
La evaluación debe basarse en casos reales, incluidos ejemplos difíciles e inusuales, en lugar de limitarse únicamente a los datos «limpios» seleccionados para una demostración. El agente debe someterse a pruebas con datos incompletos, documentos contradictorios y solicitudes que se salgan de su ámbito de competencia.
El rendimiento también puede variar con el tiempo. Los proveedores actualizan los modelos, los sistemas conectados evolucionan y las reglas de negocio cambian. Un agente que funcionaba de forma fiable hace tres meses puede empezar a comportarse de forma diferente sin que se aprecie ningún cambio visible en su interfaz.
Por lo tanto, las pruebas periódicas forman parte de las operaciones, y no se limitan únicamente al proceso de puesta en marcha. Cualquier cambio significativo en el modelo o en el flujo de trabajo debería dar lugar a una nueva revisión antes de que el agente recupere su plena autonomía.
Asignar un responsable
Un agente de IA nunca debería convertirse, en teoría, en responsabilidad de todos y, en la práctica, en responsabilidad de nadie. Cada implementación necesita un responsable de negocio designado que comprenda el proceso y rinda cuentas de su idoneidad continua. Los equipos técnicos pueden encargarse del mantenimiento de la integración, el departamento de seguridad puede definir los controles y el departamento jurídico puede evaluar riesgos concretos, pero alguien debe decidir si el agente sigue cumpliendo el objetivo empresarial para el que se introdujo.
El propietario debe evaluar el rendimiento, aprobar los cambios y asegurarse de que los empleados sepan cómo informar de los problemas. Asimismo, debe tener la autoridad necesaria para limitar o suspender las funciones del agente cuando cambien las circunstancias.
La atribución de responsabilidades es especialmente importante cuando un agente trabaja en varios departamentos. Un sistema que abarca las áreas de ventas, finanzas y atención al cliente puede quedar fácilmente al margen de las competencias de cada departamento. Sin una figura clara encargada de la toma de decisiones, los fallos dan lugar a debates sobre quién es el responsable, en lugar de a una corrección rápida.
Preparar un procedimiento de apagado
A menudo, las empresas diseñan cómo empieza a funcionar un agente sin decidir cómo se detiene. La organización necesita una forma sencilla de revocar el acceso, desactivar las acciones automatizadas y devolver el control del proceso a las personas. Esto puede ser necesario tras un incidente de seguridad, una interrupción del servicio del proveedor, una actualización inesperada del modelo o un patrón de comportamiento poco fiable.
El procedimiento de desactivación debe conservar suficiente información para la investigación, al tiempo que impide que se realicen nuevas acciones. Los empleados deben saber qué proceso manual sustituye al agente y quién decide cuándo puede reactivarse.
Esto equivale, desde el punto de vista operativo, a retirar el acceso de un empleado cuando deja un puesto. Un agente no debe seguir conectado a los sistemas simplemente porque haya cambiado el titular o haya finalizado el proyecto piloto original.
La planificación de la salida también se aplica a los proveedores. La empresa debe determinar si los flujos de trabajo, las indicaciones, los registros y la configuración pueden transferirse en caso de que cambie de plataforma. Un agente muy competente puede seguir siendo una mala elección estratégica si no puede sustituirse sin tener que reconstruir el proceso desde cero.
Descripción del puesto de agente
Antes de la puesta en marcha, la empresa debería ser capaz de responder a una serie de preguntas concisas.
Objetivo: ¿Qué resultado concreto se espera que obtenga el agente?
Ámbito de aplicación: ¿Qué tareas corresponden al agente y cuáles siguen siendo responsabilidad de los empleados?
Acceso: ¿Qué datos y sistemas puede leer, y qué puede modificar?
Autoridad: ¿Qué acciones puede realizar por sí mismo?
Límites: ¿En qué límite financiero, jurídico u operativo debe detenerse?
Prohibiciones: ¿Qué acciones no están permitidas en ningún caso?
Escalado: ¿Quién recibe las excepciones y qué información las acompaña?
Aviso: ¿Cómo sabrán los usuarios y las partes externas que interviene un agente?
Seguimiento: ¿Qué acciones y decisiones se registrarán y revisarán?
Rendimiento: ¿Qué nivel de precisión, coste y fiabilidad se considera aceptable?
Titularidad: ¿Quién es el responsable de la puesta en marcha?
Apagado: ¿Cómo se puede desactivar el agente y volver a poner el proceso bajo control humano?
Estas preguntas pueden parecer restrictivas si se comparan con la promesa del trabajo autónomo. En realidad, hacen que la autonomía sea viable. Un agente puede asumir más responsabilidad cuando la organización sabe dónde empieza y dónde acaba esa responsabilidad.
La autonomía requiere más gestión, no menos
El atractivo de los agentes de IA radica en que reducen la necesidad de una instrucción humana constante. Eso no elimina la necesidad de gestión, sino que cambia su forma. En lugar de supervisar cada acción directamente, las empresas deben diseñar de antemano las competencias, los permisos, los controles y los mecanismos de revisión. Cuanto mejor sea este marco, con mayor confianza podrá actuar el agente dentro de él. Implementar un agente sin estos límites equivale a contratar a un empleado, concederle un amplio acceso al sistema y decirle únicamente que “mejore la eficiencia”. La persona pediría una aclaración. El agente, en cambio, puede que simplemente empiece a actuar. Una implementación exitosa no parte de la pregunta de hasta qué punto puede llegar a ser autónoma la tecnología. Empieza por decidir qué grado de autonomía está dispuesta a conceder la organización, en qué condiciones y bajo la responsabilidad de quién. Antes de que un agente de IA reciba una tarea, necesita conocer cuál es su trabajo. Antes de que se le conceda acceso, necesita conocer sus límites.