Cómo automaticé un flujo de trabajo de correo electrónico en 13 idiomas utilizando solo IA y herramientas de Microsoft

La localización de campañas de correo electrónico en múltiples regiones solía ser una tarea lenta y repetitiva con muchos pasos manuales. Varios revisores trabajaban en versiones separadas, el mismo contenido se reescribía varias veces, y gestionar la consistencia en hasta 13 idiomas requería una coordinación significativa.

En lugar de introducir nuevas plataformas o herramientas externas, realicé un experimento interno: \n ¿Podría automatizarse la localización utilizando solo las herramientas ya disponibles dentro de un entorno empresarial estándar de Microsoft?

El prototipo se basó principalmente en SharePoint, Power Automate y Teams, con un componente adicional - GPT-4.1 mini accedido a través de Azure OpenAI - utilizado estrictamente para un paso controlado de control de calidad. Esto permitió que el proceso se beneficiara del razonamiento basado en LLM mientras mantenía todos los datos dentro del mismo entorno empresarial.

Para apoyar este flujo de trabajo, configuré una biblioteca estructurada de SharePoint llamada Email translations con carpetas que representan cada etapa del ciclo de vida de la localización:

| Carpeta | Propósito | |----|----| | 01IncomingEN | Archivos fuente en inglés; activador de Power Automate | | 02AIDrafts | Borradores auto-traducidos de Copilot + GPT | | 03InReview | Archivos esperando revisión regional | | 04Approved | Traducciones finales aprobadas | | 99Archive | Versiones archivadas o rechazadas |

Los archivos se movían automáticamente entre estas carpetas dependiendo de su estado.

El objetivo no era construir un sistema de localización perfecto - solo ver hasta dónde podía llegar un prototipo utilizando herramientas internas.

Terminó eliminando una gran parte del trabajo repetitivo y creó un proceso de revisión mucho más estructurado.

El Problema: Proceso, No Idioma

La localización manual de contenido en muchas regiones creaba varios problemas consistentes:

• Cada región editaba su propio archivo, por lo que existían múltiples versiones diferentes al mismo tiempo.
• Cuando el texto fuente cambiaba, no todas las regiones actualizaban su versión, lo que llevaba a contenido desajustado.
• Los archivos se guardaban en diferentes lugares y con diferentes nombres, dificultando identificar qué versión era la actual.
• Las revisiones tomaban tiempo, especialmente cuando los equipos estaban en diferentes zonas horarias.
• Repetir las mismas ediciones en muchos archivos aumentaba el riesgo de pequeños errores

Intento 1: Traducción Solo con Copilot

Aunque Copilot ahora funciona con modelos más nuevos de la serie GPT-5, este prototipo se construyó en una versión anterior, y el comportamiento de traducción reflejaba esas capacidades anteriores.

La primera versión del flujo de trabajo era simple:

1. Se subía un archivo a 01IncomingEN.
2. Power Automate se activaba automáticamente.
3. Copilot generaba una traducción para cada región.

Debido a que los activadores de SharePoint pueden dispararse antes de que un archivo termine de subirse, el flujo incluía una verificación de finalización de tamaño de archivo (esperar hasta que el tamaño > 0 antes de continuar).

Sin embargo, el problema principal se hizo evidente rápidamente: las traducciones de Copilot no eran lo suficientemente confiables para la localización de extremo a extremo.

Los problemas comunes incluían:

• CTAs traducidos demasiado literalmente
• tono y estilo variando entre idiomas
• marcadores de posición eliminados o cambiados
• diferencias de formato en listas, espaciado y estructura

Esto hizo que Copilot fuera útil solo para generar un primer borrador. \n Era necesaria una segunda capa de control de calidad.

Intento 2: Añadir GPT-4.1 Mini para QA

La siguiente versión añadió un paso de revisión:

1. Copilot → traducción inicial
2. GPT-4.1 mini (Azure) → QA y verificación de consistencia

GPT-4.1 mini mejoró:

• consistencia de tono
• preservación de marcadores de posición
• estabilidad de formato
• alineación con el significado de la fuente

Los prompts necesitaban ajustes para evitar reescrituras innecesarias, pero después de los ajustes, los resultados se volvieron lo suficientemente consistentes para usarse en el flujo de trabajo.

Trabajo de Ingeniería: Haciendo el Flujo de Trabajo Confiable

La arquitectura era simple, pero aparecieron varios problemas durante el uso real y necesitaron soluciones.

Comportamiento de la plataforma:

• Los activadores de SharePoint no siempre comenzaban inmediatamente, por lo que se añadieron verificaciones y reintentos.
• El enrutamiento de Teams fallaba cuando se renombraban los canales, por lo que el mapeo tuvo que actualizarse.

Problemas de diseño:

• Algunos pasos paralelos fallaban en la primera ejecución, por lo que se introdujo lógica de reintento.
• Las respuestas JSON a veces carecían de campos esperados, por lo que se añadió validación.
• Los nombres de archivo eran inconsistentes, por lo que se definió un único formato de nomenclatura.

Después de estos ajustes, el flujo de trabajo funcionaba de manera confiable en condiciones normales.

Arquitectura Final del Prototipo

A continuación se muestra la estructura de trabajo completa del sistema.

1. Carga e Ingesta de SharePoint

El proceso comenzaba cuando se subía un archivo a Email translations / 01IncomingEN

Power Automate entonces:

• verificaba que el archivo estuviera completamente cargado (protección contra bytes cero)
• recuperaba metadatos
• extraía texto
• identificaba regiones objetivo

SharePoint actuaba como la única fuente de verdad para todas las etapas.

2. Orquestación de Power Automate

Power Automate controlaba cada parte del flujo de trabajo:

• lectura de la fuente en inglés
• llamada a Copilot para borrador de traducción
• envío del borrador a GPT-4.1 mini para QA
• creación de una rama por región
• envío de salida por correo electrónico a equipos locales
• publicación de tarjetas de aprobación en Teams
• captura de "aprobar" o "solicitar cambios"
• guardado de archivos aprobados en 04_Approved
• guardado de versiones actualizadas en 03InReview
• archivo de versiones antiguas en 99_Archive

Todo el enrutamiento, reintentos y transiciones de estado eran manejados por Power Automate.

3. Paso de Traducción de Copilot

Copilot traducía el contenido extraído y preservaba la mayoría de la estructura del correo electrónico - listas, espaciado y formato - mejor que GPT solo.

4. Paso de QA de GPT-4.1 Mini

GPT-4.1 mini verificaba:

• consistencia de tono
• alineación de significado
• estabilidad de formato
• integridad de marcadores de posición

Esto creaba un borrador más confiable para revisión regional.

5. Revisión Regional (Email + Teams)

Para cada región, Power Automate:

• enviaba el archivo traducido por correo electrónico
• publicaba una tarjeta adaptativa en Teams con Aprobar / Solicitar cambios

Si se enviaban cambios, el archivo actualizado volvía a 03InReview y reingresaba al flujo de trabajo.

6. Almacenamiento Final

Las traducciones aprobadas se almacenaban en 04_Approved utilizando un formato de nomenclatura consistente.

Las versiones rechazadas u obsoletas se movían a 99_Archive. Esto aseguraba un registro de auditoría completo y limpio.

Resultados

Después de probar el prototipo en flujos de trabajo reales:

• el tiempo de traducción se redujo de días a minutos
• menos conflictos de versiones
• reescritura manual mínima
• ciclos de revisión más rápidos
• todos los datos procesados dentro del entorno Microsoft

Esto no reemplazó los sistemas de localización dedicados, pero eliminó una cantidad significativa de trabajo manual repetitivo.

Limitaciones

• algunos idiomas aún requerían ajustes estilísticos
• las aprobaciones de Teams dependían de los tiempos de respuesta del revisor
• el flujo necesitaba lógica de reintento para errores transitorios
• la consistencia de tono variaba en correos electrónicos largos o complejos

Estos eran aceptables para un prototipo.

Próximo Paso: Memoria de Terminología

La próxima mejora planificada es una biblioteca de terminología basada en vectores que contiene:

• glosario
• nombres de productos
• términos restringidos
• fraseología específica de la región
• grupos de sinónimos
• reglas de tono

Ambos modelos utilizarían esta biblioteca antes de producir o verificar traducciones.

Pensamientos Finales

Este proyecto fue un experimento interno para entender cuánto del flujo de trabajo de localización podría automatizarse utilizando solo herramientas estándar de Microsoft y un LLM alojado en Azure. El prototipo redujo significativamente el esfuerzo manual y mejoró la consistencia entre regiones sin agregar nuevo software.

No es una plataforma completa de localización, pero muestra lo que se puede lograr con un flujo de trabajo simple y bien estructurado dentro de la pila empresarial existente.

\