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.
When your data leaves wxrks
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, each Augmented Action (translation, alternative suggestion, proofread, smell check, tag fix) sends one segment at a time, not a whole document or project. 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. No other project content, and no data from unrelated projects or accounts, is included in that request.
Which provider actually receives it
Where that segment-level data goes depends on how the account is configured in Model Management:
wxrks's built-in AI (the default, no setup required) — by default this routes to OpenAI, through wxrks' own OpenAI account and API credentials, not a self-hosted model and not your organization's own agreement with OpenAI. If your organization has negotiated its own enterprise terms directly with OpenAI or Microsoft (for example a specific data-retention commitment), those terms only apply once you connect your own account — the default configuration is covered by wxrks' agreement with OpenAI, not yours.
OpenAI (customer-connected) — when an Account Admin connects a customer-owned OpenAI API key, requests go directly to OpenAI's API under that account's own agreement with OpenAI instead of wxrks'.
Azure OpenAI — when connected, requests go to the customer's own Azure OpenAI (Foundry) resource, hosted in Microsoft's Azure environment under that customer's own Azure agreement.
Google Gemini — when connected, requests go either to Google's standalone Gemini API (API-key based, sometimes called "Gemini Studio") or to Vertex AI (Google Cloud's enterprise offering, connected with a GCP project and service credentials), depending on which one your Account Admin sets up. This distinction matters for the data-handling guarantees below — the two are not governed by identical terms.
For the connection screens themselves, see Enabling AI Integration in wxrks through OpenAI or Microsoft Azure and Configuring wxrks Augmented Actions with Google Gemini — this article only covers what happens to the data after it's sent, not how to set up the connection.
What each provider guarantees about retention and training
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.
OpenAI and Azure OpenAI
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. A previous version of this article stated that data shared with either provider is deleted after a fixed 30-day window; that specific figure could not be re-confirmed against either provider's current published terms in this revision, so treat it as unverified rather than current fact until it's checked directly against OpenAI's and Microsoft's live policy pages.
Google Gemini
Google's terms draw a sharp line between its two Gemini connection paths, and it's a real difference, not a technicality:
Paid Gemini API usage — Google states it does not use prompts or responses to improve its products, and only logs data briefly for abuse and policy-violation detection.
Unpaid (free-tier) Gemini API usage — Google states it may use submitted content to improve its products, and that human reviewers can read inputs and outputs. Google's own guidance is not to submit sensitive, confidential, or personal information on this tier.
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; this revision could not confirm Vertex AI's specific retention and training commitments against a live policy page, so if your evaluation depends on that detail, verify it directly against Google Cloud's current Vertex AI terms rather than assuming it matches either Gemini API tier above.
Encryption in transit and at rest
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. This revision could not re-verify a specific minimum TLS version against current infrastructure configuration, so if a specific version number matters for your compliance review, request that detail directly rather than relying on a number quoted in Help Center content.