Imaginemos que una empresa comercial pone a prueba un asistente basado en inteligencia artificial para responder preguntas sobre devoluciones. Una clienta quiere saber si aún puede devolver un producto que compró en línea. El asistente encuentra dos versiones de la política, consulta la anterior, que daba menos días para devolver el producto, y le dice que el plazo ya venció.
Pensemos ahora qué ocurriría si la empresa le permitiera al asistente gestionar la solicitud. Con base en esa misma política, podría cerrar la consulta sin dejar constancia de que la clienta intentó iniciar una devolución. Si ella vuelve a contactar a la empresa, ¿podrá el equipo de servicio saber qué regla aplicó el agente y por qué dio el caso por cerrado? Cuando una organización autoriza a un agente de inteligencia artificial a ejecutar una tarea, tiene que definir con qué información puede actuar, en qué condiciones y quién atiende las excepciones. En este caso, la empresa tendría que establecer cómo identificar la política que corresponde a cada compra, qué puede hacer el agente si encuentra dos versiones y quién interviene cuando la información disponible deja dudas.
Figura 2. De una respuesta equivocada a una cliente insatisfecha
Lo que cambia cuando un agente puede intervenir en el proceso
En Scaling AI agents with trustworthy data, Denis McCauley (2026) examina cómo los sistemas de datos de las organizaciones respaldan el uso de agentes de IA. El informe, publicado por MIT Technology Review Insights con el patrocinio de Google Cloud, se basa en una encuesta global realizada en febrero y marzo de 2026 a 300 directivos de datos y tecnología, complementada con entrevistas. La mayoría de las organizaciones encuestadas registraba ingresos anuales de al menos 500 millones de dólares.
El 55 % de los encuestados estuvo total o parcialmente de acuerdo con que su plataforma actual de datos era el principal obstáculo para ampliar el uso de agentes de IA. El informe también identifica dificultades para integrar fuentes, acceder a información no estructurada y disponer de datos actualizados a tiempo. La encuesta recoge la percepción de directivos, principalmente de grandes empresas.
Para una empresa comercial, la pregunta que abre el estudio es cómo comprobar si sus fuentes permiten ejecutar una operación con la información y las reglas que esa operación exige (McCauley, 2026).
En una devolución, encontrar la política es apenas el primer paso. El agente necesita saber si el plazo corre desde la compra o desde la entrega, y si la regla aplica al canal, al producto y a las condiciones de la venta. Una fecha de entrega puede estar correctamente registrada y aun así llevar a un resultado equivocado si el agente usa la política de una tienda física para un pedido en línea. Ahí se hace visible la importancia del contexto que destaca McCauley (2026). El significado de un dato depende de las condiciones en las que se usa.
El dato que existe y el dato con el que se puede actuar
Al examinar las limitaciones de las plataformas actuales, el 50 % de los encuestados mencionó los silos de datos, el 40 % señaló la dificultad de acceder a información no estructurada o gestionarla y el 32 % identificó la falta de contexto o de definiciones compartidas sobre los datos (McCauley, 2026, figura 7). Son dificultades que pueden aparecer juntas en un mismo trámite, aunque cada una exige una intervención diferente.
Supongamos que Servicio al Cliente conserva la política general en un PDF, Logística registra las entregas en otro sistema y el equipo comercial comunicó por correo una ampliación del plazo durante una campaña. Conectar esas fuentes ayudaría a encontrar la información. Para tramitar la devolución, todavía habría que establecer si el pedido pertenece a la campaña, desde cuándo rige la ampliación y qué disposición modifica. Esa interpretación suele estar en manos de quienes conocen el proceso y saben qué documento prevalece cuando dos fuentes parecen contradecirse.
Al delegar parte del trabajo a un agente, ese conocimiento debe quedar expresado en reglas que la empresa pueda revisar.
También conviene distinguir con qué frecuencia cambia cada dato. La política de devoluciones puede mantenerse durante meses, mientras que el estado de un pedido puede cambiar en el transcurso del día. Si el registro de Logística se actualiza cada noche, el agente podría tratar como pendiente un pedido que la clienta ya recibió.
La empresa tendría que decidir cuánta antigüedad admite para cada dato y qué debe hacer el agente cuando supera ese límite. Podría informar que la entrega aún no figura en el sistema y conservar la solicitud para revisión, especialmente cuando el plazo esté próximo a vencer.
Esta distinción ayuda a orientar la inversión. Si para Logística «entregado» significa que el transportador dejó el paquete en un punto de recogida y para Servicio al Cliente significa que el comprador ya lo recibió, acelerar la sincronización propagará más rápido la discrepancia.
Si ambas áreas comparten la definición y el retraso impide atender a tiempo, entonces hay una razón para revisar cómo se actualizan los sistemas. Diagnosticar la causa permite priorizar el trabajo que más incide en el servicio.
Gobierno, calidad e integración de los datos
En 2024, Data strategies for AI leaders examinó las dificultades para ampliar el uso de la IA generativa y destacó el gobierno, la seguridad y la privacidad de los datos, su calidad y oportunidad, y la integración de fuentes dispersas (MIT Technology Review Insights, 2024). Estos aspectos ayudan a entender qué debe resolver una empresa cuando un agente pasa de responder una consulta a registrar una devolución.
El equipo de tecnología puede configurar las fuentes que consulta el agente y sus permisos. Las áreas comerciales y de servicio deben acordar quién publica la política oficial, cómo se comunican los cambios y cómo se conservan las versiones que todavía aplican a compras anteriores. Si el agente registra una devolución, el historial debería permitir reconstruir qué versión consultó, qué regla aplicó y qué acción ejecutó.
Desde una perspectiva de gestión por procesos, integrar esas fuentes también exige relacionar sus registros. Una compra puede incluir varios productos que se entregaron por separado, cada uno con su propia fecha. Si el agente toma la primera fecha que aparece en el pedido, puede calcular mal el plazo del artículo que el cliente quiere devolver. La relación entre el artículo, la entrega y la política aplicable debe estar disponible en los datos que el agente consulta.
Acceder a la información y tener autorización para actuar
Consultar la política, registrar una solicitud y emitir un reembolso son operaciones con efectos distintos. Cada una requiere sus propios permisos.
Para comprobar si ya existe una devolución abierta, al agente le pueden bastar el identificador del pedido, el artículo y el estado de la solicitud. Para ese propósito, la empresa puede limitar el acceso a esos campos y reservar la autorización de reembolsos al equipo responsable.
La autorización también debe tener en cuenta lo que sucede cuando una operación falla. Pensemos en una clienta que confirma el envío y vuelve a intentarlo porque la pantalla quedó en blanco. El sistema podría haber registrado la primera solicitud aunque la confirmación nunca llegara.
Antes de crear otra, el agente debe comprobar si ya existe un registro para ese pedido y ese artículo. Si lo encuentra, puede mostrar su número y estado. Este escenario cambia la forma de probar el piloto y obliga a definir quién corrige una duplicación y cómo se informa al cliente.
El informe de 2024 también abordaba las respuestas que parecen convincentes aunque carezcan de sustento y señalaba el valor de vincularlas con fuentes verificables y someterlas a revisión (MIT Technology Review Insights, 2024). En un agente que puede actuar, esa verificación tiene que ocurrir antes de ejecutar la operación. Si el agente encuentra dos políticas incompatibles, puede dejar la solicitud pendiente de revisión y explicar qué sigue. Una confirmación de registro debe corresponder a una solicitud que la empresa pueda localizar.
Figura 2. ¿Qué verifica el agente antes de registrar una devolución?
Qué tendría que demostrar un piloto antes de ampliar su alcance
Para el caso de devoluciones, comenzaría permitiendo que el agente registre solicitudes ordinarias de compras en línea cuando el cliente confirme el envío. El equipo de posventa conservaría la facultad de aprobar las excepciones y autorizar los reembolsos. Antes de extender el piloto, revisaría tres aspectos.
- Fuentes y reglas aplicables. Probar si el agente identifica el artículo y la fecha de entrega correctos, aplica la versión pertinente de la política y reconoce cuándo dos fuentes se contradicen.
- Límites de actuación y manejo de excepciones. Verificar que solo pueda registrar las solicitudes previstas, que use los datos estrictamente necesarios y que remita a revisión humana los casos con información faltante o contradictoria.
- Resultados y trazabilidad. Comparar con el proceso habitual el tiempo hasta un registro válido, los errores que obligan a repetir el trabajo y las solicitudes que requieren intervención humana. Revisar si cada actuación puede reconstruirse y si existe un procedimiento para corregirla.
Para saber si el piloto mejora el proceso, compararía casos equivalentes. Si se empieza con devoluciones ordinarias de compras en línea, la referencia debería ser el tiempo que esas mismas devoluciones tardaban por el canal habitual. Compararlas con casos excepcionales, que requieren más verificaciones, podría atribuirle al agente una mejora que proviene de haber seleccionado los casos más sencillos.
También mediría el trabajo posterior de posventa. Un registro rápido pierde parte de su beneficio si el personal tiene que corregir el motivo de devolución, conciliar registros duplicados o pedir al cliente que vuelva a enviar la información.
La revisión humana también merece una lectura cuidadosa. Que el agente derive varios casos puede ser una señal de que está respetando sus límites. La pregunta es cuáles deriva y por qué. Si son excepciones previstas, la derivación cumple su propósito. Si son solicitudes ordinarias que el agente no pudo tramitar por falta de información vigente, el piloto está mostrando un problema de datos o de coordinación que conviene resolver antes de ampliar el servicio.
Las condiciones para ampliar el alcance deberían acordarse al diseñar el piloto. Por ejemplo, el equipo puede exigir que toda solicitud registrada se pueda reconstruir y que, en las pruebas, las excepciones lleguen a posventa antes de que el agente modifique su estado.
Para el tiempo de atención o el reproceso, las metas pueden definirse a partir del desempeño observado en el canal habitual. Así, cuando llegue el momento de decidir, las áreas responsables tendrán criterios comunes para interpretar los resultados.
Con estos resultados, la empresa puede decidir si amplía el uso del agente, ajusta las reglas del proceso o corrige primero sus fuentes. Si el piloto revela que la tienda virtual y Servicio al Cliente comunican plazos distintos para la misma compra, resolver esa discrepancia ya sería una mejora para quienes atienden las consultas y para los clientes que dependen de esa información.
Si mañana autorizáramos a un agente a actuar en uno de nuestros procesos, ¿qué decisión estaríamos dispuestos a delegarle y con qué evidencia sabríamos que puede tomarla?
Referencias
- McCauley, D. (2026). Scaling AI agents with trustworthy data. MIT Technology Review Insights. https://cloud.google.com/resources/content/scaling-ai-agents-trustworthy-data
- MIT Technology Review Insights. (2024). Data strategies for AI leaders. https://www.snowflake.com/resource/data-strategies-for-ai-leaders/
