AEM Meets Generative AI: Configuring Agentic Translation with Azure OpenAI 🤖

If you manage multilingual AEM sites, you know the translation workflow: configure a connector, spin up translation projects, wait for content to come back from your provider, review, publish. It works — but it’s never felt smart. The translations are mechanical, often miss brand tone, and terminology consistency is a constant battle.

Adobe is changing that. AEM as a Cloud Service now supports AI-powered “agentic” translation — connecting directly to Azure OpenAI so an LLM handles your translations instead of (or alongside) traditional machine translation engines. You configure it through the same Translation Integration Framework you already know, but the engine underneath is fundamentally different.

I walked through the setup end-to-end, and this article covers every step — from Azure OpenAI credentials to style guide uploads to running your first AI-translated project. I’ll also share my honest take on what’s missing (spoiler: glossaries and translation memories) and where this is all heading.

Table of Contents:

• What Is Agentic Translation in AEM?
• Prerequisites
• Step 1: Create an Azure OpenAI Resource
• Step 2: Deploy a Model
• Step 3: Get Your API Key and Endpoint
• Step 4: Open Translation Cloud Services in AEM
• Step 5: Configure the LLM Connection
• Step 6: Upload Translation Style Guides
• Step 7: Run a Translation Project
• What’s Missing: Glossaries and Translation Memories
• The Bigger Picture: Where AEM Translation Is Heading
• Final Thoughts

What Is Agentic Translation in AEM?

Traditional machine translation connectors in AEM (Microsoft Translator, Google Cloud Translation, etc.) work at the segment level — they translate sentence by sentence, often losing context, tone, and nuance along the way.

Agentic translation flips this. It sends content to a large language model — currently Azure OpenAI — that can process full passages with awareness of context, idiom, and brand voice. Adobe calls it “agentic” because the LLM isn’t just doing word substitution; it’s reasoning about how to translate based on rules you provide.

The key point: this isn’t a separate product or a bolt-on. It plugs directly into AEM’s existing Translation Integration Framework. Same translation projects, same workflows, same launch process — just a smarter engine underneath.

Note: This feature is available in AEM as a Cloud Service only. You need your own Azure OpenAI subscription — Adobe doesn’t provide the LLM service.

Prerequisites ✅

Before you start, make sure you have:

• AEM as a Cloud Service environment with admin access
• A Microsoft Azure account with an active subscription (create one free)
• Access granted to Azure OpenAI Service in your subscription
• Familiarity with AEM’s Translation Integration Framework (helpful but not required — I’ll walk through it)

Step 1: Create a Project in Microsoft Foundry

First, you need to set up the Azure OpenAI service that AEM will connect to. The quickest path is through Microsoft Foundry (formerly Azure AI Foundry / Azure OpenAI Studio). If you already have a resource with a deployed model, skip to Step 4.Sign in to the Azure Portal and go to Microsoft Foundry

1. Go to ai.azure.com and sign in with your Azure account
2. Click + Create project
3. You’ll see two resource type options — select Microsoft Foundry resource (Recommended). This gives you a unified setup for model deployment, API keys, and management — everything AEM needs
4. Fill in the required fields:

• Project name — something descriptive (e.g., aem-translation)
• Subscription — select your Azure subscription
• Resource group — create new or use existing
• Region — choose a region that supports your desired model (e.g., East US, Sweden Central). Not all models are available in all regions — check Azure’s model availability table

5. Click Create

Deployment takes a minute or two. Once complete, click Go to resource.

Screenshot: Azure Portal — Create Azure OpenAI resource form with fields filled in

Step 2: Deploy a Model

With your Foundry project created, you now need to deploy the LLM model that will handle translations.

1. Inside your project in ai.azure.com, go to Models + endpoints in the left sidebar
2. Click + Deploy model → Deploy base model
3. Select your model — for translation, I’d recommend:

• GPT-4o — best balance of quality and speed for multilingual content
• GPT-4o mini — cheaper option if you’re translating high volumes and can accept slightly lower quality

4. Click Confirm, then configure:

• Deployment name — this is important, you’ll need it for AEM configuration (e.g., gpt-4o). Keep it simple and descriptive
• Model version — use the latest available
• Tokens per Minute Rate Limit — set based on your expected translation volume (start with the default, scale up if needed)

5. Click Deploy

Screenshot: Azure AI Foundry portal — Model deployment screen showing deployment name and model selection

Tip: The deployment name is not the model name. You choose it yourself. Whatever you enter here is what you’ll paste into AEM’s “Deployment Name” field in Step 5. Write it down.

Step 3: Get Your API Key and Endpoint

You need four values from Azure to connect AEM. Here’s where to find each:

1. Go back to your Azure OpenAI resource in the Azure Portal
2. In the left sidebar, click Keys and Endpoint (under Resource Management)
3. Copy the following:

• KEY 1 : this is your **API Key
• Endpoint : this is your Base Path** (e.g., https://xxxxxxxxx.openai.azure.com/)

4. For the API Version, check Azure’s API version docs — use the latest GA version (e.g., 2024-10-21 or newer)
5. The Deployment Name is what you set in Step 2 (e.g., gpt-4o)

Keep these four values handy — you’ll need them all in the next step:

⚠️ Security note: Treat your API key like a password. Don’t commit it to source control or share it. If compromised, regenerate it immediately from the Azure Portal.

Step 4: Open Translation Cloud Services in AEM

Navigate to the Translation Cloud Services console where all translation configurations live.

1. From the AEM global navigation, go to Tools → Cloud Services → Translation Cloud Services
2. Open the configuration folder where you want to set up AI translation — this could be /conf/global if you want it available site-wide, or a site-specific config folder
3. Create a new ‘Agentic Translation’ configuration

Screenshot: Translation Cloud Services console showing the configuration folders

This is the same place you’d configure any translation connector — Microsoft Translator, Smartling, Lionbridge, etc. The AI translation option lives alongside them.

Step 5: Configure the LLM Connection

This is where you connect AEM to your Azure OpenAI instance. Grab the four values you saved from Step 3.

1. Open (or create) your AI translation configuration
2. Select the LLM Config tab
3. Choose Azure OpenAI as the provider
4. Fill in your credentials from Step 3:

• API Key — from your Azure OpenAI resource
• API Version — e.g., 2024-10-21 or the latest stable version
• Base Path — your Azure OpenAI endpoint URL (e.g., https://xxxxxxxxx.openai.azure.com/)
• Deployment Name — the name you set in Step 2 (e.g., gpt-4o)

5. Save the configuration

Screenshot: Agentic Translation Configuration screen showing the LLM Config tab with Azure OpenAI fields — API Key, API Version, Base Path, and Deployment Name

Step 6: Upload Translation Style Guides

This is where it gets interesting. Instead of just translating generically, you can upload style guide documents for each target language. AEM processes these and generates translation rules — essentially a JSON ruleset that tells the LLM how your brand speaks in that locale.

1. In the Agentic Translation Configuration, select the LLM Guidelines tab
2. Choose a locale (e.g., fr-FR for French)
3. Click Upload and attach your style guide document for that language in PDF format e.g. frescopa-translation-style-guide.pdf
4. Wait for processing — you’ll see a status indicator: processing → completed (or aborted if something went wrong)
5. Once complete, review the generated rules in the editor — these are JSON-formatted instructions covering tone, terminology preferences, and example translations

Screenshot: LLM Guidelines tab showing the locale list on the left and the generated translation rules editor on the right

You can edit the generated rules directly if the LLM’s interpretation of your style guide needs tweaking. This is a powerful feedback loop — upload a guide, review what the AI extracted, refine, and iterate.

Pro Tip: Be specific in your style guides. Instead of “keep it professional,” write something like “Use formal French (vous, not tu). Translate ‘Experience Cloud’ as-is — do not localize product names. Prefer active voice.” The more concrete your guide, the better the generated rules.

Step 7: Run a Translation Project

Once everything is configured, running a translation project is exactly the same as with any other translation connector. That’s the beauty of this approach — Adobe didn’t reinvent the workflow.

1. Navigate to your content in Sites
2. Select a page and go to References → Language Copies
3. Create a translation project for your target language(s)
4. The project uses your agentic translation configuration, sends content to Azure OpenAI with your style guide rules applied, and returns translated content
5. Review, approve, and publish as usual

Screenshot: Translation project in AEM showing Agentic translation project properties

Screenshot: Translation project in AEM showing content being translated via the agentic translation method

Important: AI translation integration is not available from the AI Assistant chat UI in AEM or from the Experience Production Agent interface. You must use the translation workflows and consoles described above.

What’s Missing: Glossaries and Translation Memories ❌

The style guide approach is a genuine leap forward for tone and voice consistency — traditional MT connectors never had this. But two gaps stand out for enterprise localization teams:

No Translation Memory (TM) — every translation is a fresh LLM generation. You can’t leverage previously translated segments for consistency or cost savings, and the same source text may produce slightly different phrasing across runs.

No Glossary / Termbase — you can bake terminology into style guide rules, but there’s no structured glossary upload (CSV, TBX), no automatic term matching, and no enforcement mechanism. For regulated industries where terminology consistency is a compliance requirement, this is a gap.

That said, this is a first release. Adobe has stated that additional providers and capabilities are planned, and the Translation Integration Framework is extensible by design. The industry is heading toward RAG-augmented pipelines that inject glossary terms and TM matches into LLM prompts — I’d expect AEM to follow.

Where This Is Heading

Agentic translation isn’t just a feature — it signals where Adobe is taking AEM. Translation is shifting from transactional (send content out, get it back) to intelligent (the system understands context, applies brand rules, generates native-quality output).

What I expect comes next: glossary injection, TM-as-context (feeding previous translations as few-shot examples) and multi-provider support (Anthropic, Gemini, dedicated translation models).

Between generative authoring, the Experience Production Agent, and now agentic translation, Adobe is weaving LLMs into every stage of the content lifecycle. The foundations are solid.

Final Thoughts 💡

AEM’s agentic translation with Azure OpenAI is exciting if you’ve been stuck with rigid MT connectors. The setup is straightforward, style guides are clever, and it slots into existing workflows with zero retraining.

For enterprise teams with strict terminology needs — compensate with detailed style guides, use it selectively for marketing/editorial content, and keep your TMS pipeline for regulated copy.