This article covers exactly what happens to your content once Augmented Actions sends it to an outside AI provider: which data leaves wxrks, which provider receives it, and what that provider commits to about retention and training. For how to turn Augmented Actions on and use it in the Editor, see wxrks Augmented Actions. For wxrks' broader AI governance commitments and security program, see wxrks AI Policy.
​

💡 Who is this for? This guide is for Account Admins who need to understand exactly what data reaches an AI provider, and under what guarantees, before enabling or configuring Augmented Actions within the wxrks platform.

No content leaves wxrks for an AI provider until an Account Admin turns on the Enable Augmented Translation Actions toggle for the account. Until then, every Augmented Action is unavailable and nothing is sent anywhere. The Account, Organizational Unit, and per-user controls that govern this are described in wxrks Augmented Actions — this article assumes that toggle is on and focuses only on what happens to the data once it is.
​

Once enabled, most Augmented Actions (translation, alternative suggestion, proofread, smell check, tag fix) send one segment at a time, not a whole document or project. The batch QA Smells review in the QA panel, which produces Confidence Scores and drives auto-confirm, sends several segments per request. A single request typically includes the segment's source and target text, any matching Translation Memory hits, relevant Glossary/term base entries, and — for context-aware actions — the previous segment. The Smells check also includes the Sous Chef Instructions in force and, when the target is unedited, the reasoning behind the Context Sensitive translation. No other project content, and no data from unrelated projects or accounts, is included in that request.

Where that segment-level data goes depends on how the account is configured in Model Management:

Any AI operation, including QA Smells, can be routed to a provider you connect; see Connect your own AI engine for automatic post-editing (Context Sensitive) and quality evaluation (Smells).

For the connection screens themselves, see Enabling AI Integration in wxrks through OpenAI or Microsoft Azure, Configuring wxrks Augmented Actions with Google Gemini and Configure Custom AI Providers with Model Management — this article only covers what happens to the data after it's sent, not how to set up the connection.

These are each provider's own commitments, not something wxrks enforces in its own code — they come from OpenAI's, Microsoft's, and Google's respective terms, and can change on their schedule rather than wxrks'. Always check the linked policy directly for the current, authoritative version rather than relying on a summary.

Microsoft's current published terms for Azure OpenAI (part of Azure AI Foundry) state that customer prompts, completions, embeddings, and training data are not used by Microsoft or OpenAI to train or improve their models, and are not shared with other customers or with OpenAI's own consumer products. Standard chat/completions calls are described as stateless — inputs and outputs aren't stored inside the model itself. See Microsoft's Azure OpenAI data privacy documentation for the full, current terms, including the separate rules for optional stateful features (fine-tuning, Assistants, batch processing).
​

OpenAI's own API terms (as opposed to Azure's hosting of OpenAI's models) are published separately at OpenAI's privacy policy. How long each provider keeps the data it receives is set by that provider's own terms, so check the current retention period directly in OpenAI's and Microsoft's live policy pages.

Google's terms draw a sharp line between its two Gemini connection paths, and it's a real difference, not a technicality:

See Google's Gemini API additional terms of service for the current wording. If your organization connects wxrks to Gemini, confirm with whoever manages that Google Cloud/API account which tier it's actually running on — the free tier's terms are meaningfully weaker than the paid tier's.
​

Vertex AI connections are governed by Google Cloud's separate enterprise terms rather than the Gemini API terms above. Their retention and training commitments are set by Google Cloud's current Vertex AI terms, and don't necessarily match either Gemini API tier above, so check those terms directly if your evaluation depends on that detail.

For these four providers, how long data is kept and whether it is used for training are set by the provider's own terms and by your agreement with it. They are not set by wxrks. Check the provider's current policy before you connect it, and confirm the plan or tier your API key runs on, because terms can differ between them.
​

With OpenRouter, the terms of the upstream provider that handles a request also apply. You can limit which upstream providers receive your requests, including by asking OpenRouter to skip providers that collect data, with a custom parameter on the row. See Configure Custom AI Providers with Model Management.

Provider credentials (API keys, Azure resource/deployment details, Google service account credentials) are encrypted with AWS KMS before they're stored, and decrypted only at the moment a request needs them — this is enforced in wxrks' own AI integration code, not just stated as a policy. Each account's credentials are encrypted independently.
​

Data in transit to any of these providers uses standard TLS encryption, consistent with wxrks' broader security practices. If a specific detail, such as the minimum TLS version, matters for your compliance review, contact wxrks Support to request it.