Como Automatizei um Fluxo de Trabalho de E-mail em 13 Idiomas Usando Apenas IA e Ferramentas da Microsoft

A localização de campanhas de e-mail em várias regiões costumava ser uma tarefa lenta e repetitiva com muitos passos manuais. Vários revisores trabalhavam em versões separadas, o mesmo conteúdo era reescrito várias vezes, e gerir a consistência em até 13 idiomas exigia uma coordenação significativa.

Em vez de introduzir novas plataformas ou ferramentas externas, realizei uma experiência interna: \n Seria possível automatizar a localização usando apenas as ferramentas já disponíveis num ambiente empresarial Microsoft padrão?

O protótipo baseou-se principalmente no SharePoint, Power Automate e Teams, com um componente adicional - GPT-4.1 mini acedido através do Azure OpenAI - usado estritamente para uma etapa controlada de QA. Isto permitiu que o processo beneficiasse do raciocínio baseado em LLM enquanto mantinha todos os dados dentro do mesmo ambiente empresarial.

Para suportar este fluxo de trabalho, configurei uma biblioteca SharePoint estruturada chamada Email translations com pastas representando cada etapa do ciclo de vida da localização:

| Pasta | Finalidade | |----|----| | 01IncomingEN | Ficheiros fonte em inglês; acionador do Power Automate | | 02AIDrafts | Rascunhos traduzidos automaticamente do Copilot + GPT | | 03InReview | Ficheiros à espera de revisão regional | | 04Approved | Traduções finais aprovadas | | 99Archive | Versões arquivadas ou rejeitadas |

Os ficheiros moviam-se automaticamente entre estas pastas dependendo do seu estado.

O objetivo não era construir um sistema de localização perfeito - apenas ver até onde um protótipo poderia ir usando ferramentas internas.

Acabou por remover uma grande parte do trabalho repetitivo e criou um processo de revisão muito mais estruturado.

O Problema: Processo, Não Idioma

A localização manual de conteúdo em muitas regiões criou vários problemas consistentes:

• Cada região editava o seu próprio ficheiro, por isso existiam várias versões diferentes ao mesmo tempo.
• Quando o texto fonte mudava, nem todas as regiões atualizavam a sua versão, o que levava a conteúdo incompatível.
• Os ficheiros eram guardados em locais diferentes e com nomes diferentes, tornando difícil identificar qual versão estava atual.
• As revisões demoravam tempo, especialmente quando as equipas estavam em fusos horários diferentes.
• Repetir as mesmas edições em muitos ficheiros aumentava o risco de pequenos erros

Tentativa 1: Tradução Apenas com Copilot

Embora o Copilot agora funcione com modelos mais recentes da série GPT-5, este protótipo foi construído numa versão anterior, e o comportamento de tradução refletia essas capacidades anteriores.

A primeira versão do fluxo de trabalho era simples:

1. Um ficheiro era carregado para 01IncomingEN.
2. O Power Automate era acionado automaticamente.
3. O Copilot gerava uma tradução para cada região.

Como os acionadores do SharePoint podem disparar antes de um ficheiro terminar o carregamento, o fluxo incluía uma verificação de conclusão do tamanho do ficheiro (esperar até que o tamanho > 0 antes de continuar).

No entanto, o problema principal tornou-se claro rapidamente: as traduções do Copilot não eram suficientemente fiáveis para localização de ponta a ponta.

Os problemas comuns incluíam:

• CTAs traduzidos demasiado literalmente
• tom e estilo variando entre idiomas
• espaços reservados sendo removidos ou alterados
• diferenças de formatação em listas, espaçamento e estrutura

Isto tornou o Copilot útil apenas para gerar um primeiro rascunho. \n Uma segunda camada de verificação de qualidade era necessária.

Tentativa 2: Adicionando GPT-4.1 Mini para QA

A próxima versão adicionou uma etapa de revisão:

1. Copilot → tradução inicial
2. GPT-4.1 mini (Azure) → QA e verificação de consistência

O GPT-4.1 mini melhorou:

• consistência de tom
• preservação de espaços reservados
• estabilidade de formatação
• alinhamento com o significado da fonte

Os prompts precisavam de ajustes para evitar reescritas desnecessárias, mas após ajustes, os resultados tornaram-se consistentes o suficiente para usar no fluxo de trabalho.

Trabalho de Engenharia: Tornando o Fluxo de Trabalho Fiável

A arquitetura era simples, mas vários problemas surgiram durante o uso real e precisaram de correções.

Comportamento da plataforma:

• Os acionadores do SharePoint nem sempre iniciavam imediatamente, então verificações e novas tentativas foram adicionadas.
• O encaminhamento do Teams falhava quando os canais eram renomeados, então o mapeamento teve que ser atualizado.

Problemas de design:

• Alguns passos paralelos falhavam na primeira execução, então foi introduzida lógica de repetição.
• As respostas JSON às vezes não tinham campos esperados, então foi adicionada validação.
• Os nomes dos ficheiros eram inconsistentes, então foi definido um único formato de nomenclatura.

Após estes ajustes, o fluxo de trabalho funcionava de forma fiável em condições normais.

Arquitetura Final do Protótipo

Abaixo está a estrutura de trabalho completa do sistema.

1. Carregamento e Receção no SharePoint

O processo começava quando um ficheiro era carregado em Email translations / 01IncomingEN

O Power Automate então:

• verificava se o ficheiro estava totalmente carregado (proteção contra zero bytes)
• recuperava metadados
• extraía texto
• identificava regiões alvo

O SharePoint atuava como a única fonte de verdade para todas as etapas.

2. Orquestração do Power Automate

O Power Automate controlava cada parte do fluxo de trabalho:

• leitura da fonte em inglês
• chamada ao Copilot para rascunho de tradução
• envio do rascunho para o GPT-4.1 mini para QA
• criação de uma ramificação por região
• envio de e-mail com o resultado para equipas locais
• publicação de cartões de aprovação no Teams
• captura de "aprovar" ou "solicitar alterações"
• salvamento de ficheiros aprovados em 04_Approved
• salvamento de versões atualizadas em 03InReview
• arquivamento de versões antigas em 99_Archive

Todo o encaminhamento, repetições e transições de estado eram geridos pelo Power Automate.

3. Passe de Tradução do Copilot

O Copilot traduzia o conteúdo extraído e preservava a maior parte da estrutura do e-mail - listas, espaçamento e formatação - melhor do que o GPT sozinho.

4. Passe de QA do GPT-4.1 Mini

O GPT-4.1 mini verificava:

• consistência de tom
• alinhamento de significado
• estabilidade de formatação
• integridade dos espaços reservados

Isto criava um rascunho mais fiável para revisão regional.

5. Revisão Regional (Email + Teams)

Para cada região, o Power Automate:

• enviava o ficheiro traduzido por e-mail
• publicava um cartão adaptativo no Teams com Aprovar / Solicitar alterações

Se fossem enviadas alterações, o ficheiro atualizado retornava para 03InReview e reentrava no fluxo de trabalho.

6. Armazenamento Final

As traduções aprovadas eram armazenadas em 04_Approved usando um formato de nomenclatura consistente.

Versões rejeitadas ou desatualizadas eram movidas para 99_Archive. Isto garantia um registo de auditoria completo e limpo.

Resultados

Após testar o protótipo em fluxos de trabalho reais:

• o tempo de tradução caiu de dias para minutos
• menos conflitos de versão
• reescrita manual mínima
• ciclos de revisão mais rápidos
• todos os dados processados dentro do ambiente Microsoft

Isto não substituiu sistemas de localização dedicados, mas removeu uma quantidade significativa de trabalho manual repetitivo.

Limitações

• alguns idiomas ainda exigiam ajustes estilísticos
• as aprovações do Teams dependiam dos tempos de resposta dos revisores
• o fluxo precisava de lógica de repetição para erros transitórios
• a consistência de tom variava em e-mails longos ou complexos

Estas eram aceitáveis para um protótipo.

Próximo Passo: Memória de Terminologia

A próxima melhoria planeada é uma biblioteca de terminologia baseada em vetores contendo:

• glossário
• nomes de produtos
• termos restritos
• fraseologia específica da região
• grupos de sinónimos
• regras de tom

Ambos os modelos usariam esta biblioteca antes de produzir ou verificar traduções.

Considerações Finais

Este projeto foi uma experiência interna para entender quanto do fluxo de trabalho de localização poderia ser automatizado usando apenas ferramentas Microsoft padrão e um LLM hospedado no Azure. O protótipo reduziu significativamente o esforço manual e melhorou a consistência entre regiões sem adicionar novo software.

Não é uma plataforma completa de localização - mas mostra o que pode ser alcançado com um fluxo de trabalho simples e bem estruturado dentro da pilha empresarial existente.

\