Marketers who are triple checking how their AI tools interact with PII are asking the right questions, and they should keep asking them of every vendor who wants their data anywhere near an AI model. The past two years have given us a long list of reasons why, from employees pasting customer records into chat tools that retain and train on whatever gets typed in, to vendors bolting AI features onto existing products without checking what data those features actually touch.
The reputational and financial cost when a customer finds out their email, purchase history, or contact details ended up somewhere they never agreed to can be catastrophic. If raw customer data reaches a model without proper controls, the consequences compound quickly:
- A model that has ingested raw customer records can surface pieces of them in later outputs, to other users who shouldn’t have access.
- Data can be retained inside a provider's training pipeline indefinitely, well beyond the original request.
- A support agent's AI assistant pulling unfiltered CRM data into a prompt moves regulated data outside every access control the organization spent years building.
By now, marketers are well aware of the risks of launching an AI system before anyone has mapped what it can see and where that data ends up. So, we put this piece together to help you understand how Adverity Atlas is built to handle your data safely, and how that design extends to make any AI model you connect through it safe as well.
How does Adverity Atlas protect your PII from LLM exposure?
Adverity Atlas connects to your data warehouse as a read-only layer. It writes SQL, runs it against the warehouse, and reads back the results. Adverity Atlas reasons over your data using an LLM you own, under your own credentials and terms, and it can only ever see what the person asking is allowed to see. Sensitive fields are never queryable by the AI, as access rules are enforced in the SQL itself, and the semantic context Adverity Atlas builds for the model has raw PII values stripped out. Nothing gets copied out, the warehouse stays the only place the data lives.
This means Adverity Atlas is safe to use as a read only tool in its own right through the UI, but it also makes other AI tools safe by proxy, because they never receive PII. No raw customer record, name, or email address is ever exposed to an LLM, whether that model belongs to OpenAI, Anthropic, Google, or Azure OpenAI.
This principle holds no matter how complex the setup. Each customer's tenant is logically isolated from every other. An agency running several client brands through Adverity Atlas, or an enterprise with multiple business units on one account, can then structure its own environment with workspaces, data source bindings and row filters so that each brand or division sees only what it should. These controls work alongside your warehouse's own row-level security.
What are AI tools plugged in through Adverity Atlas allowed to see?
PII is unconditionally stripped from the metadata and samples your model sees. Anything flagged gets redacted at the prompt boundary, before it's anywhere near the model. So, this isn't a reviewer checking boxes after the fact. It happens as a fixed step in the pipeline, every time, for every query. The model reasons over your governed data, and is never handed a bulk export.
Whichever LLM you choose to plug into your data through Adverity Atlas (OpenAI, Anthropic, Azure OpenAI, or Google Gemini), PII is never used to train it.
TLDR: Adverity Atlas queries on your warehouse are read-only, nothing copied out. What reaches the model is a governed prompt with PII already stripped. The raw data doesn't travel.
How does Adverity Atlas keep brands and client data separated?
Adverity Atlas’s access controls govern what the model can reach. A separate mechanism handles who can query what in the first place, and it's worth explaining because people often assume access control lives in the interface. It doesn't. Row-level security is enforced at the point a query runs, with access rules written directly into the SQL as WHERE clauses.
A finance team and a brand team can sit on the same underlying data source and never see each other's rows, and there's no route around that, including for whoever owns the workspace. It applies the same way whether a person is clicking through the UI or an AI agent is running a query on their behalf in chat. The agent inherits exactly what its user is allowed to see, nothing more.
How does Adverity Atlas ensure provenance for every query?
Every operation in Adverity Atlas gets logged with actor identity, IP address, user agent, request ID, and the operation itself. Every output an AI agent produces can be traced back to the query that generated it, the system it ran against, and when it ran. It's logged at the service level, so the answer a board member gets and the answer legal gets are drawn from the same source.
Data stays in the customer's own warehouse, in whatever region they already operate in. Adverity is SOC 2 Type II audited. The bring-your-own-LLM model does a lot of the heavy lifting here too: a user can route to an EU-hosted provider like Azure OpenAI, which keeps data inside an arrangement they've already vetted rather than sending it to a model Adverity manages.
Put together, none of this depends on trusting a policy document. It's how the system is built to run.
FAQ
Which LLM providers does Adverity Atlas work with?
Adverity Atlas works with leading LLM providers, and you can bring your own provider and your own credentials. Adverity Atlas operates in two ways: through its native interface, where it works as an autonomous marketing analyst flagging anomalies and answering cross-platform questions; and as the underlying context layer for organizations building their own AI agents and internal workflows.
Does customer data ever leave the warehouse?
No. Your data is queried in place, not exported. Adverity Atlas connects as a read-only layer, generates SQL, and executes it against your warehouse, reading back the results of each query to answer your question. It never pulls a bulk copy of your data out of the warehouse, and your tables are never modified, so the warehouse remains where your data lives.
What does Adverity Atlas actually send to the LLM?
A structured prompt containing the query intent, semantic context such as metric definitions and field mappings, and aggregated results. It does not contain raw row-level data, and any field flagged as PII is redacted before the prompt is assembled.
Is PII detection manual or automatic?
Detection is automatic. Adverity Atlas flags PII patterns when it profiles your data.
How is tenant data isolated?
Each tenant is logically isolated from every other tenant. Within your own tenant, workspaces, data source bindings and row filters let you structure your environment so that each brand or business unit sees only what it should, and your warehouse's own permissions still apply on top.
How does row-level security work with AI agents?
Access rules are injected as WHERE predicates at query execution, not filtered in the application layer. This applies identically to human users and to AI agents running on their behalf, and there's no bypass path, including for tenant owners.
Is there an audit trail?
Yes. Every service operation is logged with actor identity, IP address, user agent, request ID, and operation details, and every AI output can be traced back to its source query, system, and execution time.
What authentication does Adverity Atlas support?
SAML2 SSO, WebAuthn passkeys, and TOTP MFA, integrated with existing identity systems.
Where does data go for EU users, and what certifications does Adverity Atlas hold?
Data stays in the user’s warehouse, in the region they already operate. Adverity is SOC 2 Type II audited. Bringing your own LLM gives you full end-to-end control over how your data is processed, rather than relying on a third party, which is especially valuable for EU users with GDPR requirements.
