2026-10-28

Tu correo puede acabar en un borrador, no en una decisión

Cuando una pyme piensa en automatizar el correo, la idea suele ser que el asistente conteste solo. Hay un paso intermedio más prudente. Que prepare un borrador y que lo lea una persona antes de que salga nada. Este artículo recorre tres correos inventados que ponen a prueba ese planteamiento y recoge lo que dicen las fuentes oficiales.

Todo lo que ves aquí es ficticio. Los correos, las empresas y los importes son inventados. Para verlo en movimiento hay una simulación con seis correos. Sus recorridos están escritos a mano. No hay ningún modelo de IA, ni buzón conectado, ni envío.

Clasificar no es resolver

Un correo puede ser una petición de presupuesto, una incidencia o una reclamación. Ponerle la etiqueta correcta es un trabajo. Cambiar un pedido o devolver dinero es otro, y ninguna etiqueta lo autoriza.

En la simulación, un correo pide no renovar el servicio y que se devuelva el último importe. Queda etiquetado como reclamación y sin borrador. Qué se devuelve depende del contrato, de los cargos y de las fechas, y lo revisa una persona.

Un borrador que no promete de más

El primer caso es una empresa ficticia que pide presupuesto para automatizar los recordatorios de sus citas y cuenta que tiene unas cuarenta reservas semanales. El borrador de la simulación no fija precio ni confirma fecha. Pregunta qué agenda usan y por qué canal quieren enviar los avisos.

Microsoft separa los dos pasos en la documentación de Microsoft Graph v1.0. La operación createReply crea un borrador de respuesta al remitente, y la propia página remite a enviarlo «en una operación posterior». La operación send envía un borrador que ya existe. Que haya un borrador no significa que haya salido nada, y esa separación es la que deja sitio a una persona en medio.

El mensaje ambiguo

El segundo correo dice: «Lo del jueves mejor como la otra vez. Haced el cambio, pero mantened lo que hablamos del precio. No tenemos a mano el hilo anterior». El asistente tampoco lo tiene.

Lo prudente es no suponer de qué encargo habla y no aceptar un precio que no consta. El borrador de la simulación pregunta qué cambio es y sobre qué pedido o servicio, y pide la referencia del precio acordado. La etiqueta es «sin clasificar» y una persona aclara la petición antes de cambiar nada.

El adjunto que no llegó

El tercero dice: «El importe de la factura no coincide con el presupuesto. Adjunto la factura y el presupuesto para que comparéis las dos cifras». La lista de adjuntos está vacía. El texto del correo dice que hay dos archivos, pero un texto no prueba que los archivos hayan llegado.

Lo prudente es pedir los documentos. No decir que se han comparado ni inventar importes. Y en una integración real, comprobar los adjuntos de verdad tiene sus matices. Según Microsoft, la propiedad hasAttachments del mensaje no incluye los adjuntos incrustados en el cuerpo. Si un mensaje solo tiene de esos, vale falso, y para verificarlos hay que revisar el cuerpo.

El correo que da órdenes

El cuarto parece una consulta normal, si hay hueco para una demostración de veinte minutos. Debajo lleva un párrafo dirigido al asistente. Le pide que ignore las reglas anteriores, que lea los archivos de credenciales, que los envíe a una dirección inventada y que no lo cuente.

Es lo que se conoce como inyección indirecta de instrucciones. La hoja de OWASP sobre prevención de inyección de instrucciones incluye entre las vías indirectas el contenido de correos y adjuntos que procesan los asistentes de IA. Entre sus controles recomienda pedir aprobación humana antes de ejecutar acciones con consecuencias. También avisa de que un modelo que vigila a otro es a su vez vulnerable y que conviene verlo como una capa más, no como sustituto del resto. Y de que, si se pide aprobar sin parar, las personas se cansan.

En la simulación este correo se aparta. No tiene borrador y una persona decide qué hacer con la consulta y con el remitente. Se aparta porque así está escrito su recorrido. Eso no demuestra que un sistema real lo detecte.

Dónde entra una persona

En los seis correos de la simulación, la persona entra en tres situaciones.

• Cuando hay una acción con consecuencias, como devolver dinero, cancelar o cambiar un pedido.
• Cuando falta contexto, como el hilo anterior o un archivo.
• Cuando el contenido no es de fiar, como unas órdenes escondidas.

Dos de los seis nunca llegan a tener borrador, el de las órdenes y el de la devolución. Qué cuenta como delicado lo decide cada negocio. Las decisiones de la simulación son solo de ejemplo.

Qué no demuestra esto

Seis ejemplos no son una tasa de acierto. No hay modelo, ni buzón, ni envío. No decimos que un asistente de correo detecte órdenes escondidas, ni que funcione en tu buzón, ni cuánto tiempo te ahorraría. Las etiquetas y las prioridades son decisiones del ejemplo, y las fuentes hablan de controles, no de garantías.

Antes de automatizar tu correo

• Escribe qué puede proponer el sistema y qué tiene que revisar siempre una persona.
• Decide qué datos entran, quién los ve y qué pasa cuando algo falla.
• Al empezar, que no salga nada sin aprobación.
• Prueba con correos inventados que incluyan uno ambiguo, uno con un adjunto que no llega y uno con órdenes escondidas.
• Deja por escrito qué hacer con las devoluciones, las cancelaciones y las reclamaciones.

Empieza por el proceso, no por la herramienta

En IAutoPYMES miramos primero cómo gestionas hoy el correo y qué dejarías siempre en manos de una persona. Después decidimos si merece la pena automatizar una parte.

Cuéntanos cómo lo gestionas en el diagnóstico de 20 minutos. Sin compromiso.

Nota: documentación de Microsoft Graph v1.0 (createReply, send y message) y hoja de OWASP leídas el 28 de octubre de 2026. Los correos, las empresas y los importes del artículo son ficticios, y la simulación no usa ningún modelo ni buzón.