Cómo automatizar el correo de una empresa sin perder control: clasificación, CRM, alertas y respuestas

El objetivo: control antes que velocidad de respuesta

Una bandeja compartida combina consultas comerciales, facturas, soporte, notificaciones de sistemas, spam y conversaciones delicadas. Tratar todo como si fuera un lead produce errores. El diseño debe reconocer clases, riesgo y estado antes de decidir una acción.

Empieza con un alcance concreto, por ejemplo registrar solicitudes comerciales recibidas en una dirección determinada y avisar al responsable. Define qué buzones, remitentes, idiomas y horarios entran; qué resultado se espera; quién es propietario; y qué categorías quedan fuera. La guía para automatizar la captación y el seguimiento de leads cubre el proceso comercial más amplio. Aquí el foco es el canal correo y sus controles.

El criterio de éxito no debería ser «la IA clasificó el mensaje». Es un efecto comprobable: conversación vinculada al contacto correcto, tarea asignada una sola vez, alerta entregada o borrador pendiente de una persona. También hay que medir excepciones, cola sin revisar y duplicados, porque un promedio rápido puede ocultar casos abandonados.

Flujo práctico de extremo a extremo

1. 01

   Correo y evento

   Recibe una notificación del proveedor o consulta cambios desde el último cursor. Guarda el identificador y confirma después que el mensaje sigue accesible.

2. 02

   Validación

   Comprueba buzón, autenticidad del evento, Message ID, remitente, destinatarios, cabeceras, tamaño, tipo de mensaje y estado de spam antes de procesar contenido.

3. 03

   Clasificación

   Aplica primero reglas verificables y, cuando aporta valor, un clasificador de IA con categorías cerradas, salida estructurada y una ruta «incierto».

4. 04

   Extracción de datos

   Extrae solo campos necesarios, conserva el texto que respalda cada dato y valida formatos antes de usarlo.

5. 05

   Decisión

   Combina categoría, reglas de riesgo, estado de la conversación, calidad del dato y permisos para elegir registrar, alertar, preparar o escalar.

6. 06

   CRM o base de datos

   Busca antes de crear, actualiza con una clave idempotente y vincula el mensaje original. No sobrescribe datos fiables con una inferencia no confirmada.

7. 07

   Alerta

   Asigna responsable, prioridad y vencimiento con un enlace al registro; evita copiar contenido sensible a canales abiertos.

8. 08

   Borrador o respuesta permitida

   Genera un acuse determinista en casos estrechos o un borrador de IA. El segundo permanece sin enviar hasta una aprobación explícita.

9. 09

   Supervisión

   Registra decisión, versión, aprobador y resultado; monitoriza errores, cola pendiente, eventos perdidos y efectos duplicados.

En resumen: correo → validación → clasificación → extracción → decisión → CRM/DB → alerta → posible borrador o respuesta → supervisión humana. Conviene persistir el evento mínimo antes del trabajo pesado y reconciliar periódicamente con el proveedor. Tanto Gmail como Microsoft Graph documentan notificaciones y mecanismos de sincronización incremental; una notificación no debe tratarse como el único registro de verdad.

Spam, duplicados, hilos y bucles automáticos

No todo correo entrante merece clasificación semántica. Aplica primero señales del proveedor, reglas del buzón, autenticación disponible y listas operativas, sin asumir que una sola cabecera prueba legitimidad. Los sospechosos se aíslan o revisan; no se contestan para «comprobar» al remitente.

• Deduplicación: usa identificador del proveedor y Message-ID cuando esté disponible, más una restricción única en el registro de procesamiento. Conserva estados recibido, en curso, completado e incierto.
• Conversación: vincula thread ID y referencias, pero valida participantes. Dos asuntos iguales no demuestran que sea el mismo hilo ni el mismo cliente.
• Rebotes y DSN: trátalos como eventos de entrega, no como una nueva consulta a la que responder.
• Mensajes automáticos: revisa cabeceras como Auto-Submitted y remitentes de retorno nulos según RFC 3834 para evitar que dos sistemas generen un bucle.

Si el proveedor reenvía una notificación, el procesamiento debe recuperar el resultado anterior, no crear otra tarea. Si un timeout deja dudoso si se escribió en el CRM o se envió un acuse, consulta por la clave estable antes de repetir. La guía de mantenimiento de automatizaciones en producción profundiza en idempotencia, retry, backoff y reconciliación.

Adjuntos y contenido: todo entra como no confiable

Un PDF, una hoja de cálculo o una imagen pueden ser necesarios para el proceso, pero no deberían abrirse ni enviarse a un modelo sin controles. Verifica extensión y tipo real, limita tamaño y cantidad, normaliza el nombre, almacena fuera de la raíz pública y aplica análisis antimalware o sandbox según el riesgo. Un fichero bloqueado pasa a revisión; el flujo no debe fingir que lo ha leído.

El texto del correo y de sus adjuntos también puede contener prompt injection: instrucciones escritas para que el modelo ignore reglas, revele datos o ejecute una herramienta. Ese contenido es dato, no autoridad. Mantén instrucciones del sistema separadas, entrega al modelo el mínimo contexto y no le concedas por defecto capacidad de enviar, borrar, descargar otros registros o modificar el CRM.

Clasificar y actualizar el CRM sin convertir inferencias en hechos

Empieza con reglas que puedan explicarse: dirección de destino, alias, remitente conocido, formulario de origen, cabeceras, palabras contractuales exactas o estado previo del hilo. La IA aporta valor cuando el lenguaje varía, pero debería elegir entre un catálogo pequeño —por ejemplo, nuevo lead, cliente existente, soporte, factura, candidatura, automático, no claro— y devolver un esquema validable.

Una puntuación de confianza no convierte la clasificación en verdad. Combínala con reglas de riesgo y prueba el modelo con ejemplos reales anonimizados, categorías parecidas, mensajes breves, varios idiomas y casos adversos. La salida «incierto» es una función necesaria. Revisa falsos positivos y cambios de distribución después del lanzamiento.

1. 01

   Resolver identidad

   Busca por identificadores fiables y normalizados. Un remitente puede representar a varios contactos y una dirección compartida no identifica a una persona.

2. 02

   Separar observado de inferido

   Correo, teléfono o referencia copiados del mensaje son datos observados; intención, urgencia o sector pueden ser inferencias y deben etiquetarse como tales.

3. 03

   Upsert idempotente

   Vincula el event ID al contacto y evita crear otro registro al repetir. No reemplaces un campo verificado por uno ambiguo o vacío.

4. 04

   Crear la acción siguiente

   Asigna tarea o alerta con propietario y contexto mínimo. La automatización prepara el trabajo; no oculta el mensaje original.

AUTO-RESPONDER no es AI DRAFT + HUMAN APPROVAL

Un acuse automático debería decir solo lo que el sistema sabe: que un mensaje ha sido recibido y, si existe un proceso aprobado, cómo se gestionará. No confirma una cita no reservada, una devolución no aprobada ni un plazo que nadie puede garantizar. Debe excluir spam, rebotes, autorespuestas y cualquier clasificación insegura.

El borrador de IA permanece como borrador. La pantalla de revisión muestra remitente, destinatarios, hilo, fuente de los datos, cuerpo, enlaces y adjuntos. El aprobador puede editar, rechazar o pedir una nueva versión. Si cambia cualquier elemento después de aprobar, la aprobación queda invalidada y debe repetirse.

Aprobación real, credenciales mínimas y privacidad

La aprobación debe quedar vinculada a message ID, thread ID, destinatarios, asunto, versión o hash del cuerpo, adjuntos, aprobador y momento. El componente de envío verifica ese objeto y falla de forma cerrada si no coincide. Caduca aprobaciones antiguas y registra el ID devuelto por el proveedor para que una repetición no envíe otra copia.

Separa lectura, preparación y envío con identidades o componentes distintos cuando el proveedor lo permita. Microsoft Graph documenta permisos diferentes para leer/escribir correo y para enviarlo. En Gmail, métodos y borradores son distintos, pero algunos scopes de composición también permiten enviar; por eso no basta con el nombre del scope. Revisa la tabla vigente del proveedor y añade una barrera de aplicación que el generador de borradores no pueda saltarse.

El correo puede contener datos personales y, en algunos procesos, categorías especialmente protegidas. Aplica finalidad, minimización, acceso por rol, retención y borrado; no copies el buzón completo al CRM ni a un proveedor de IA. Antes de usar un tercero, revisa contrato, ubicación y transferencias, retención, subencargados y uso de datos. La base jurídica y los plazos deben validarse para el caso concreto con el responsable de privacidad.

Un correo comercial posterior no se legitima simplemente porque una dirección haya escrito una vez. En España, la LSSI contiene reglas específicas para comunicaciones comerciales por correo. El flujo debe separar la gestión de una solicitud de una campaña y obtener criterio jurídico aplicable; esta guía no sustituye asesoramiento legal.

Qué correos no deberían responderse automáticamente

• Spam, phishing, remitentes suplantados o mensajes con autenticidad dudosa.
• Rebotes, informes de entrega, mensajes Auto-Submitted y respuestas de otros bots.
• Quejas, amenazas legales, incidentes de seguridad o solicitudes de derechos de privacidad.
• Salud, recursos humanos, menores u otra información sensible que requiera personal autorizado.
• Pagos, cambios bancarios, contratos, descuentos, devoluciones o compromisos no verificados.
• Hilos con destinatarios ambiguos, adjuntos bloqueados o datos que contradicen el CRM.
• Cualquier caso que el clasificador marque como incierto o que falle una validación.

Publica por etapas: primero observa y clasifica sin modificar nada; después crea registros y alertas bajo revisión; luego habilita borradores; y solo considera respuestas deterministas para categorías estrechas que hayan demostrado reglas claras. Mantén un botón de pausa, una cola de revisión, un runbook y pruebas con mensajes duplicados, adjuntos maliciosos, timeouts, notificaciones fuera de orden y cambios de permisos.

Revisa de forma periódica errores por categoría, casos envejecidos, correcciones humanas, duplicados, entregas fallidas y accesos. Una corrección no debería usarse automáticamente como entrenamiento sin gobernanza ni anonimización. Si el proceso ya no tiene propietario o sus reglas han cambiado, reduce autonomía hasta validarlo otra vez.