--- title: "Integraciones: qué se consulta y qué se modifica | Atiende" description: "Un mapa operativo para conectar sistemas sin confundir información disponible con acciones autorizadas. Guía del blog de Atiende sobre agentes de IA." url: https://useatiende.ai/es/blog/integraciones-fuentes-acciones lang: es alternates: es: https://useatiende.ai/es/blog/integraciones-fuentes-acciones en: https://useatiende.ai/en/blog/integraciones-fuentes-acciones updated: 2026-09-30 --- # Integraciones: definir qué se consulta y qué se modifica *Publicado: 2026-09-16 · Actualizado: 2026-09-30 · 2 min* Un mapa operativo para conectar sistemas sin confundir información disponible con acciones autorizadas. ## Comenzar por una decisión operativa La pregunta inicial no es cuántas herramientas pueden conectarse, sino qué decisión necesita información y qué acción debe ocurrir después. Para consultar un pedido, identificar su fuente y los campos necesarios. Para modificarlo, definir además permisos, reglas y confirmación. Separar lectura y escritura facilita evaluar consecuencias. Una conexión que permite ver datos no implica que pueda ejecutar cambios. El alcance debe documentarse por proceso y sistema, evitando prometer integración completa cuando solo existe acceso a una parte del recorrido. ## Identificadores que unen registros Dos sistemas pueden usar nombres diferentes para el mismo cliente o referencias distintas para un pedido. El mapeo debe establecer cómo se relacionan registros y qué hacer si la coincidencia es ambigua. Un correo o un nombre no siempre son identificadores suficientes. Conservar referencias originales facilita investigar diferencias sin perder el rastro. También hay que definir qué sistema tiene autoridad para cada dato. No necesariamente será uno para todo: la fuente del contacto puede ser distinta de la que confirma entrega o disponibilidad. ## Pensar en operaciones incompletas Los sistemas pueden responder tarde, rechazar una solicitud o confirmar una acción sin que la notificación llegue. El proceso necesita distinguir esos estados antes de repetir una operación. Si se desconoce el resultado, consultar la referencia de la acción o enviarla a revisión según las posibilidades de la herramienta. Reintentar sin comprobar puede duplicar reservas o tareas. La recuperación debe preservar qué se intentó, qué se confirmó y qué sigue incierto. Es un requisito operativo, no un detalle que deba descubrir el usuario final. ## Cambios de datos y versiones Un campo renombrado, un catálogo actualizado o una regla interna nueva pueden cambiar el significado del intercambio. La integración necesita propietario y revisiones cuando esas dependencias cambian. Probar solo una solicitud exitosa no demuestra que el proceso esté preparado. Incluir datos ausentes, referencias desconocidas, respuestas demoradas y permisos insuficientes. Los registros de operación deben permitir investigar el caso sin copiar información sensible innecesaria. Una vista de fallas por causa ayuda a decidir si corresponde corregir datos, ajustar reglas o pedir cambios al sistema externo. ## Un contrato sencillo entre equipos Documentar entrada, salida, permisos, fuente de verdad y procedimiento de recuperación para cada acción. Validar ese acuerdo con quienes operan ambos sistemas. Esta conversación suele descubrir supuestos importantes antes de que aparezcan como errores difíciles de explicar en una demostración o en producción. ## Ejemplo ilustrativo: consultar un pedido y reprogramar su entrega En un caso hipotético, un agente debe informar el estado de un pedido y, si procede, cambiar su fecha de entrega. Para informar, necesita leer tres campos de un sistema de pedidos: estado, fecha prometida y transportista. La lectura exige un identificador confiable, así que el diseño define cómo se relaciona el número que da el cliente con el registro del sistema, y qué hace si hay dos coincidencias. Para reprogramar, el recorrido es distinto. Se verifican permisos, se comprueba la regla de cambios, se pide confirmación al cliente y recién entonces se envía la escritura. Si la respuesta del sistema tarda o llega vacía, el agente no repite el cambio: consulta si la modificación quedó registrada, y si no puede saberlo, deriva el caso a una persona con la referencia de la operación. Lectura y escritura comparten sistema, pero no comparten riesgos. ## Diseño por canal: qué cambia cuando la entrada es WhatsApp, voz o web El canal determina qué dato llega y con qué calidad. Por WhatsApp, el cliente puede pegar un número de pedido con errores, enviar la foto de un ticket o escribir varias veces. La integración debe normalizar el identificador, tolerar duplicados y aceptar un adjunto sin suponer que contiene datos válidos hasta comprobarlos. En voz, los números dictados necesitan lectura de confirmación antes de consultar nada. En web, la persona puede estar autenticada y aportar un identificador más fiable. También cambia el costo de un error. Un dato mal leído en voz se detecta con una repetición; en un mensaje asíncrono, el cliente quizá no vea la corrección hasta horas después. Documenta por canal qué se acepta como identificador, qué verificación adicional se pide y cuándo se escala. Revisa las condiciones vigentes de los proveedores de mensajería y voz, pues influyen en los plazos de respuesta que el diseño puede prometer. ## Lista de revisión de una integración antes de activarla Antes de la primera conversación real, revisa la integración con quienes operan cada sistema y no solo con quien la construyó. Cada pregunta debería tener una respuesta escrita, con un responsable. - ¿Qué sistema es la fuente de verdad para cada dato y qué ocurre si dos sistemas discrepan? - ¿Qué permisos tiene la conexión y se limitan a lo mínimo necesario? - ¿Cómo se distingue una operación fallida de una confirmación perdida antes de reintentar? - ¿Quién recibe el aviso cuando cambia un campo, un catálogo o una regla de los que depende el intercambio? - ¿Se probaron datos ausentes, referencias desconocidas y respuestas demoradas, y no solo el caso exitoso? ## Ideas clave - Definir lectura y escritura por separado. - Verificar resultados antes de repetir acciones. - Leer y escribir comparten sistema pero no riesgos: diséñalos por separado. - Cada canal aporta identificadores de distinta calidad; normaliza y verifica según el canal. --- Agenda una demo: https://useatiende.ai/es/demo Contacto: ventas@useatiende.ai · https://useatiende.ai/es/contacto Mapa del sitio: https://useatiende.ai/sitemap.xml · llms.txt: https://useatiende.ai/llms.txt