The Security Review for AI on Your Marketing Data

Most AI-on-your-data projects that die in security review die for the same five reasons, and every one of them is fixable before the meeting. The pattern is consistent: an enthusiastic team wires a model to the warehouse, gets useful answers for a month, then requests formal approval, and the review surfaces questions nobody thought to ask at setup time. Where does inference run. Who can see what. What got logged.

This article is the question list itself. If you are the security or compliance reviewer, use it as your checklist. If you are the data lead about to face that reviewer, answer these five sections in writing first and the meeting becomes short. For the technical background on why the default setup fails most of these questions, see Connecting Claude to BigQuery: What Works in the Demo and Breaks in Production.

Data residency and routing

Ask: where does model inference physically run? Does the provider use our prompts or results for training? What is the retention period for prompts and outputs, and is it contractual or a settings toggle?

This matters because an AI analytics tool ships more than metadata to the model. Prompts carry the question, but responses ride along with query results, which are rows of business data: customer emails, order values, campaign spend. If inference runs on default US endpoints, that is a third-country transfer of personal data under GDPR (AVG in the Netherlands), and it needs a legal basis, a transfer mechanism, and a DPA that actually covers this processing. We are not your lawyers; your DPO will say the same thing with more paperwork.

A good answer sounds like: inference runs on a named regional endpoint, for example Google Vertex in an EU region, retention is contractually zero, training on customer data is contractually excluded, and there is a signed DPA listing the model provider as a subprocessor.

A red flag sounds like: "we use the standard API," "we can ask the vendor where it runs," or any answer that depends on a consumer-tier subscription, because consumer plans carry different training and retention terms than enterprise contracts, and settings toggles are not contracts.

Access control

Ask: does the AI inherit the permissions of the person asking, or does it query through one shared service account? Can access be scoped by role, dataset, and row? Who can grant access, and how is it revoked?

The default DIY setup runs every query through a single service account with read access to everything, which means the chat interface promotes every user to the highest access level in the warehouse, without anyone having decided that. The marketer asking about ROAS and the analyst allowed to see margins are, to BigQuery, the same identity. Row-level security cannot help, because it binds to IAM principals and there is only one principal.

A good answer: every prompt executes with the asking user's identity or a scoped delegate of it, roles map to datasets and rows, and removing someone from the identity provider removes their AI access in the same motion.

A red flag: "the service account only has read access." Read access is the entire risk. Salary tables are read.

Auditability

Ask: for any answer the AI has ever given, can you produce the user, the prompt, the generated SQL, and the returned result? How long are those logs kept, and who reviews them?

Auditability is what turns an incident into a ticket instead of a crisis. A wrong number in a board deck, a suspected data leak, an employee querying tables they should not: all three investigations start with "show me exactly what happened," and warehouse job logs alone cannot answer it. Jobs executed by a shared service account have no human attached, and the prompt that generated the SQL never touched the warehouse at all.

A good answer: a per-interaction log of user, timestamp, prompt, compiled SQL, and result reference, retained on a defined schedule, exportable to your SIEM.

A red flag: "BigQuery logs all queries." True, and insufficient, for the reasons above.

Scope and data minimization

Ask: which datasets and tables can the model see? Is PII in scope at all, and if so, why? Can sensitive columns be masked or excluded from the schema the model reads?

Data minimization is a GDPR principle, but it is also just good engineering: a model that answers marketing questions needs metrics and dimensions, and it almost never needs raw email addresses to do that job. The strongest scope answer involves a semantic layer, a governed set of metric definitions sitting between the model and the raw tables, so the model sees "net_revenue by channel" rather than the customers table. That architecture also happens to fix AI accuracy, which we cover in Why AI Gets Your Numbers Wrong, and How a Semantic Layer Fixes It.

A good answer: the model queries a defined semantic layer, PII columns are excluded or masked at that layer, and adding a new dataset to scope is a deliberate, logged act.

A red flag: "it has access to the analytics project." Projects accumulate. Two years of syncs means the CRM export, the finance reconciliation tables, and that one dataset a contractor loaded in 2024 are all in scope, and nobody has the list.

Vendor architecture and exit

Ask: who holds the data at rest, the vendor or us? What leaves our infrastructure, and when? If we terminate, what do we keep and what do we lose?

Vendor architecture in this category splits into two camps. In one, the vendor copies your marketing data into their systems and you query their copy; in the other, the data stays in your own warehouse under your own IAM and the vendor operates on top of it. The difference decides your blast radius when the vendor is breached, your negotiating position at renewal, and what Tuesday looks like after termination.

A good answer: data lives in your own warehouse (your BigQuery project, your IAM, your region), the vendor holds credentials you can revoke, and termination leaves you with all raw and modeled data plus the transformation code.

A red flag: your data becomes rows in the vendor's multi-tenant store, export on exit is "CSV by request," and the vendor's retention schedule, not yours, decides how long your customer data exists on their systems.

Where Verity fits

Verity was built to pass this review rather than negotiate with it: everything runs in the customer's own BigQuery project under their own IAM, AI calls route through Google Vertex in the Netherlands with zero retention, access is role-based per prompt, and every interaction lands in a full audit trail. The model reaches data only through the semantic layer, via a managed MCP server, which is the same architecture behind Data Chat.

Frequently asked questions

Does GDPR forbid using US model providers on customer data?

No, and this article is not legal advice. It requires a valid transfer mechanism, a DPA covering the processing, and an assessment your DPO will want in writing. EU-region inference with contractual zero retention removes most of that overhead, which is why reviewers prefer it.

Is anonymizing the data before the AI sees it enough?

It shrinks the residency problem but leaves access control, audit, and scope untouched, and true anonymization of behavioral data is harder than it looks. Pseudonymized data is still personal data under GDPR. Treat anonymization as one control, not a waiver of the review.

We already passed a security review for our BI tool. Does that cover AI?

Usually not. Traditional BI queries run under governed accounts and produce reviewable reports. An AI interface introduces new flows the old review never saw: prompts and results leaving for inference, generated SQL, and conversational access by users who never had warehouse credentials.

What single change most improves the review outcome?

Putting a semantic layer between the model and the raw tables. It scopes what the model can see, applies your definitions to every answer, and gives the audit log something meaningful to record. Residency is a contract negotiation; scope is architecture.