⚠ Synthetic pre-research — AI-generated directional signal. Not a substitute for real primary research. Validate findings with real respondents at Gather →
Projected from interview analyses using Bayesian scaling. Treat as directional estimates, not census measurements.
Side-by-side comparison of sentiment, intent, buying stage, and decision role across all personas.
Complete question-by-question responses with per-persona analysis. Click any respondent to expand.
Alex is a technically sophisticated CTO grappling with a concrete, well-defined problem: insufficient visibility into AI tool usage — particularly unsanctioned usage — and the data egress risk that creates for a B2B SaaS company handling customer PII, pricing logic, and internal architecture details. His tone is measured and pragmatic rather than alarmed; he is not anti-AI and is actively building on these APIs. The core tension he articulates is between executive pressure to move fast and the governance infrastructure needed to do so responsibly. He estimates his organization is roughly 60% toward his definition of 'good,' with technical controls ahead of governance. His most distinctive insight is that AI policy enforcement conversations are too UI-centric, while his real exposure surface is engineers calling model APIs directly from code. He is open to vendor solutions but skeptical of current offerings that address visibility or policy enforcement in isolation, and frustrated by hand-wavy vendor answers on data residency.
Tell me what's top of mind for you on this topic right now — what are you wrestling with?
Right now the thing I keep coming back to is data residency and prompt egress. We've got engineers and PMs using a mix of tools — some sanctioned, some not — and the honest problem is I don't have full visibility into what's leaving our environment in the form of prompts. Customer data, pricing logic, internal architecture details — that stuff can end up in a third-party model's context window pretty easily if people aren't paying attention. We've made some decisions around which tools are approved and we've got API gateway logging in place for the stuff that goes through sanctioned endpoints, but the unsanctioned usage is the hard part. Someone installs a browser extension, pastes in a support ticket, and that's potentially PII sitting in a training pipeline somewhere. The other thing I'm wrestling with is the gap between what execs want — which is "more AI, faster" — and what it actually takes to do that responsibly. I'm not anti-AI, we're building on top of these APIs ourselves. But moving fast without knowing where your data goes creates liability that shows up later, usually at the worst time.
What's the most important thing you need to understand or solve here?
For us, the core problem right now is visibility. We don't have a reliable picture of which AI tools our engineers and product people are actually using day-to-day. The sanctioned stack is one thing — we've made deliberate decisions there. But the unsanctioned usage is where the exposure lives, and that's harder to get at without being invasive about it. The specific concern is data going outbound to third-party model APIs. We're a B2B SaaS company, so our engineers are handling customer data, internal system architecture details, pricing logic — things that genuinely matter if they end up in a training corpus somewhere. So the question I keep coming back to is: how do I get sufficient telemetry on what's leaving our environment without turning this into a surveillance program that kills trust with my engineering team?
What does 'good' look like to you — and how far are you from that today?
Good, for me, is when we have a complete picture of what's hitting our data layer — who's sending what to which AI endpoint, and under what context. Right now we have reasonable visibility into our sanctioned tools, but the unsanctioned usage is still a gap. People are copy-pasting things into ChatGPT or Claude on their own, and our DLP policies catch some of that but not reliably enough. The ideal state is probably: centralized API gateway for AI traffic, clear data classification enforced at the point of use, and a policy layer that doesn't require me to trust that every employee read the acceptable use policy. We're maybe 60% there. The governance piece is further behind than the technical controls.
What would change your perspective on this entirely?
That's a fair question to sit with for a second. Probably if I saw a vendor actually solve the detection-to-enforcement gap in a way that didn't require me to build a bunch of glue code around it. Right now most of what I evaluate is good at visibility or good at policy, but not both — and integrating them requires my team's time, which is the thing I have least of. The other thing would be if the data residency and tenancy model got genuinely cleaner. We keep coming back to this question of "where does the prompt actually go" — and a lot of vendor answers are still pretty hand-wavy. If someone built a solution where I could verify data handling at the API level, not just read it in a trust document, that would move me meaningfully.
What question are you not being asked that you wish someone would ask?
That's a fair question. I'd say it's something like: "How do you actually enforce AI policy at the API layer, not just at the browser or endpoint level?" Everyone focuses on blocking ChatGPT in the browser or putting up an acceptable use policy, but in a dev-heavy org like ours, half the risk is engineers calling OpenAI or Anthropic APIs directly from application code or internal tooling. That's where the real data leakage surface is, and most of the governance conversations I see are still UI-centric. We had to build egress controls specifically around API traffic to catch that, and I almost never hear other security teams talking about it at that level.
"How do I get sufficient telemetry on what's leaving our environment without turning this into a surveillance program that kills trust with my engineering team?"
Alex is a security-minded CTO operating in a state of managed concern rather than crisis. He has meaningful AI governance gaps — particularly around shadow usage by individual employees — and is acutely aware of the compliance exposure this creates given customer data obligations. His tone is measured and pragmatic: he understands the problem clearly, has made partial progress on sanctioned tooling, but acknowledges a real and unresolved gap on unsanctioned usage. He is not panicked, but the data exfiltration risk is a genuine source of ongoing stress. He is skeptical of AI vendor data handling claims without independent verification, and sees private deployment as a viable but currently cost-prohibitive alternative. His most underappreciated insight is that Shadow AI risk is fundamentally an organizational design problem — unclear ownership across security, IT, legal, and business units — not purely a technical one.
Tell me what's top of mind for you on this topic right now — what are you wrestling with?
Right now the thing I keep coming back to is data residency and prompt leakage. We have engineers and product folks who've just... organically started using whatever AI tools they find useful — Cursor, Claude, various Copilot flavors — and the honest question I can't fully answer is: where is our data going and under what retention terms? We've got a reasonably mature security posture, but the controls we built assumed a world where data leaves the perimeter in known, auditable ways. API calls to an LLM provider don't always fit neatly into that model, especially when it's an individual developer's personal subscription rather than an enterprise agreement we negotiated. The other piece is that enforcement is genuinely hard without being the team that kills productivity. I don't want to be the CTO who bans useful tools and watches people route around me anyway. So we're trying to figure out the right middle ground — probably something closer to approved enterprise agreements with DLP controls baked in — but getting there takes time and budget that's competing with other priorities.
What's the most important thing you need to understand or solve here?
For us, the core problem is visibility. We don't have a reliable picture of what AI tools our employees are actually using day-to-day — not just the ones IT provisioned, but the ones people spun up on their own with a corporate card or a personal account. And when you don't have that visibility, you can't reason about what data is leaving your environment. The data exfiltration piece is what keeps me up at night more than anything else. We handle customer data that's covered under various contractual obligations, and if someone is pasting that into a third-party LLM endpoint, we may have a compliance problem before we even know it happened.
What does 'good' look like to you — and how far are you from that today?
Good, in my mind, is when we have full visibility into what AI tools are actually touching our data — not just the sanctioned ones, but everything employees are spinning up on their own. And then layered on top of that, consistent policy enforcement that doesn't require someone manually chasing down violations. Where we are today is... partial. We've got reasonable coverage on the approved tooling — we went through a vendor review process, negotiated data processing agreements, that kind of thing. But the shadow usage piece is still a gap. Someone in sales or marketing tries a new AI writing tool, pastes in customer data, and we often find out about it after the fact, if at all. The honest distance between where we are and "good" is probably 12 to 18 months of tooling and process maturity, assuming we stay focused on it. The harder part isn't even the technology — it's getting consistent behavior across the org without making people feel like security is just blocking them from being productive.
What would change your perspective on this entirely?
That's a fair question. Probably if I saw a credible, independent audit showing that a major AI vendor's data handling actually matched their contractual claims — not just their SOC 2, but real evidence that customer prompts aren't being used for model improvement or shared across tenants in ways that aren't fully disclosed. Right now I'm operating on a reasonable-but-not-verified level of trust, and that shapes how conservative our policies are. The other thing that would shift my thinking is if the tooling for private deployment got dramatically cheaper and easier to operate. We've looked at running models on our own infrastructure, and the operational overhead is still significant enough that it changes the build-vs-buy calculus. If that gap closed, a lot of the third-party data exposure risk just goes away and the policy enforcement problem gets simpler.
What question are you not being asked that you wish someone would ask?
That's a fair question. I'd say something around governance ownership — specifically, who actually owns Shadow AI risk inside an organization? Because in most places I talk to, it falls between security, IT, legal, and the business units, and nobody has a clear mandate. It's not a technology problem at that point, it's an organizational design problem. We spent a lot of time early on building technical controls and then realized the harder work was getting alignment on who escalates what and to whom when something gets flagged.
"Good, in my mind, is when we have full visibility into what AI tools are actually touching our data — not just the sanctioned ones, but everything employees are spinning up on their own. And then layered on top of that, consistent policy enforcement that doesn't require someone manually chasing down violations."
Jordan is a Senior PM at a fintech company navigating a clear and specific tension: AI tool adoption is already widespread and practitioner-driven, but organizational visibility and compliance infrastructure haven't kept pace. The core concern is not policy absence — a policy exists — but the gap between written policy and actual behavior, compounded by approved tools that weren't designed with usability in mind, creating persistent incentive to route around them. Jordan's risk framing is measured and pragmatic rather than alarmist: the threat feels real but diffuse, and current enforcement options feel too blunt to deploy without damaging productive workflows. The most distinctive insight Jordan offered is the infrastructure risk angle — unapproved AI prototypes quietly becoming production dependencies — which they explicitly noted is underexplored by interviewers and vendors. Overall tone is analytical and problem-aware, with no strong emotional valence; Jordan is wrestling with tradeoffs, not in crisis.
Tell me what's top of mind for you on this topic right now — what are you wrestling with?
Right now, the thing I keep coming back to is the gap between what our official policy says and what's actually happening day-to-day. We're a fintech, so we have real compliance obligations — PCI, SOC 2, some state-level data privacy stuff — and the policy on paper says "get approval before using external AI tools." But in practice, engineers and analysts are just... using things. ChatGPT, Claude, whatever. And a lot of the time they're doing it to move faster, which I get, because that's the culture we've built. What I'm genuinely wrestling with is how to create guardrails that don't just become the thing people route around. Because if the policy is too restrictive, people find workarounds, and then you've got the same data leakage risk with zero visibility into it. The concern about prompts going to third-party services with sensitive customer or pricing data — that's a real exposure for us, not a hypothetical. And then on top of that, leadership is excited about AI, wants us moving fast, so there's not a ton of appetite to slow things down for a governance review process. So I'm kind of stuck in the middle trying to figure out what "good enough" actually looks like in practice.
What's the most important thing you need to understand or solve here?
For us, the biggest tension right now is that our engineering and product teams are moving fast with AI tools — like, they're already deep into Copilot, Cursor, various chat interfaces — and our security posture hasn't quite caught up to what's actually leaving the building in those prompts. We're in fintech, so the data sensitivity question isn't abstract. If someone pastes customer transaction data or pricing logic into an external model, that's a real compliance exposure, not just a theoretical one. So the core thing I need to understand is: what's actually going out, and do we even have visibility into that right now? I don't think we have a clean answer. The policy side feels more solvable — you can write a policy. The harder problem is enforcement and detection without killing the productivity gains that made people adopt these tools in the first place.
What does 'good' look like to you — and how far are you from that today?
For us, "good" would be a state where we actually know what tools people are using, have a clear sanctioned path that's good enough that people don't feel like they need to go around it, and have some basic visibility into what's flowing where. That's a pretty low bar honestly, but it's not where we are today. Right now the gap is mostly on the visibility side. We have a policy on paper, we have some approved tools, but whether people are actually routing sensitive data through personal ChatGPT accounts or using browser extensions we haven't reviewed — I genuinely can't tell you with confidence. And in fintech, that exposure isn't theoretical, it's a real compliance concern around customer financial data. The other piece of "good" that we're further from is having a sanctioned path that's actually compelling enough to use. The approved options we have feel like they were chosen for security reasons alone without much input from the people actually doing the work, so the incentive to work around them stays high. Until we close that gap, I don't think policy enforcement alone gets us very far.
What would change your perspective on this entirely?
That's a good question to sit with. I think if we started seeing consistent, well-documented cases where shadow AI actually caused a material breach or a significant compliance failure at a company our size, that would shift how seriously I push for more formal controls internally. Right now it feels like the risk is real but diffuse — hard to point to a specific incident and say "that's the thing we're fighting." The other thing that would shift my thinking is if the tooling got meaningfully better at distinguishing risky behavior from just... people being productive. Right now a lot of the enforcement options feel pretty blunt, and I worry about overcorrecting and blocking workflows that are actually generating value. If I saw controls that were more surgical, I'd be more willing to advocate for stricter policy.
What question are you not being asked that you wish someone would ask?
The thing I'd want someone to dig into more is how shadow AI actually intersects with the product development lifecycle specifically — not just "are employees using unauthorized tools" in a generic sense. In my role, the real exposure is engineers and PMs using personal API keys to prototype features, and that work eventually getting baked into production systems without any security review. It's less about someone typing sensitive data into ChatGPT and more about how unapproved AI dependencies quietly become infrastructure. I haven't seen many interviewers or vendors frame it that way, and I think that's where the actual risk accumulates in a company like mine.
"The real exposure is engineers and PMs using personal API keys to prototype features, and that work eventually getting baked into production systems without any security review — it's less about someone typing sensitive data into ChatGPT and more about how unapproved AI dependencies quietly become infrastructure."
Jordan is a Senior PM at a fintech company navigating a practical, operational tension between fast-moving GenAI adoption and compliance requirements around PCI and PII data. Their tone is measured and pragmatic — not alarmed, but genuinely unsatisfied with the current state. The core problem they articulate is a policy-enforcement gap: formal GenAI policy exists but lacks real visibility, employee understanding, or enforceable guardrails. They estimate being roughly 60% toward acceptable visibility and less than that on policy clarity. They are skeptical of restrictive enforcement approaches, noting that friction drives workarounds, and are more interested in lightweight controls and sanctioned tools that actually fit workflows. They call out vendor opacity on data architecture as a meaningful barrier to trust. Their unprompted insight — that nobody asks why employees reach for unauthorized tools — reflects a systems-level perspective on compliance failure that goes beyond typical security framing.
Tell me what's top of mind for you on this topic right now — what are you wrestling with?
Right now the thing I keep coming back to is the gap between what our leadership wants — which is basically "AI everything, ship fast" — and what our security and compliance folks are actually comfortable with. We're fintech, so we have real regulatory exposure, and that tension is live every sprint cycle. The specific thing I'm wrestling with is data boundary clarity. When engineers or PMs on my team are pasting things into external tools — customer behavior data, internal pricing logic, stuff like that — I genuinely don't know where that lands from a compliance standpoint. We don't have a crisp policy yet, and the tools are moving faster than the policy process. It's not dramatic, it's just a real operational gap that I'm trying to get ahead of before it becomes someone's incident report.
What's the most important thing you need to understand or solve here?
For us, the core tension is that our engineering and product teams are moving fast with GenAI — using Copilot, ChatGPT, various coding assistants — and the security and compliance function is playing catch-up. In fintech, we're dealing with PCI data, sometimes PII, and the question of what's actually leaving our environment when someone pastes a prompt into a third-party service is genuinely unresolved. So the most pressing thing I need to understand is: where is our data actually going, and do we have any real visibility into that? Right now it feels like we have policy on paper but not a lot of enforcement in practice.
What does 'good' look like to you — and how far are you from that today?
For us, "good" looks like knowing what tools people are actually using, having clear policies that employees understand and can follow, and having some reasonable guardrail around what data leaves our environment. Not perfect containment — that's not realistic — but informed containment. Where we are today is... maybe 60% of the way there on visibility, and probably less on policy clarity. We have a formal GenAI policy, but I'd be surprised if more than half the team has actually read it. The tooling sprawl is real — people are using personal ChatGPT accounts, Notion AI, Copilot, things embedded in products they've been using for years that quietly got AI features added. We don't have a great consolidated picture of all of that. The data governance piece is probably where I feel the most gap. Especially in fintech, you've got customer data, pricing logic, compliance-sensitive stuff — and the question of what's actually being sent to third-party services is one I don't feel like we've fully answered. The air-gapped or single-tenant model sounds appealing in theory, but operationally it creates friction that teams just route around. So right now we're trying to find a middle ground that's actually enforceable rather than just technically correct on paper.
What would change your perspective on this entirely?
For us to genuinely shift how we think about Shadow AI risk, I think it would come down to seeing better tooling that actually integrates with how people work rather than just blocking things. Right now a lot of the enforcement conversation is about restriction — "is AI allowed, is it not allowed" — and that creates this dynamic where people just work around it anyway. If I saw controls that were lightweight enough that compliance didn't create friction for the team, and that gave us real visibility into what data is actually leaving versus just flagging every API call, that would change the calculus. The other thing that would shift my perspective is clearer contractual guarantees from vendors — not just "we're secure, trust us," but actual architecture diagrams showing data segregation and tenant isolation. Right now that evidence is pretty thin from most providers.
What question are you not being asked that you wish someone would ask?
The one that comes to mind is around the employee experience side of this. Everyone's asking security teams "how do you detect Shadow AI" or "what's your policy framework" — but nobody's asking why employees reach for unauthorized tools in the first place. In our environment, a lot of it comes down to: the approved tools are slower, clunkier, or just don't fit the actual workflow. If you don't close that gap, you're playing whack-a-mole with enforcement forever. The more interesting question is "what would make the sanctioned path the path of least resistance?"
"The air-gapped or single-tenant model sounds appealing in theory, but operationally it creates friction that teams just route around. So right now we're trying to find a middle ground that's actually enforceable rather than just technically correct on paper."
Chris is a pragmatic Head of Demand Gen at a Series A company who is genuinely concerned about AI data exposure but in a measured, operational way rather than an alarmed one. His primary problem is visibility — he does not know what tools his team uses or what data is leaving the organization — and he frames this as an active business risk, not merely a compliance issue. He is aware of the gap between current state (honor system, loose procurement, no Shadow AI audits) and an ideal state (controlled infrastructure, team-understood policy), but is realistic about resource constraints. Importantly, he surfaces a counterweight that he feels is underappreciated: over-restriction has already caused productivity loss on his team, and he wants security conversations to account for that tradeoff. His overall tone is candid and measured — concerned but not panicked, and looking for practical solutions rather than validation of the risk.
Tell me what's top of mind for you on this topic right now — what are you wrestling with?
Right now the thing I'm most actively wrestling with is that our team is using AI tools constantly — ChatGPT, Claude, some of the newer ones — and I genuinely don't know what's leaving the building. Like, I'm not a security person, but when someone on my team pastes a competitor analysis or a draft ICP built from our CRM data into one of these tools, that's real proprietary information going somewhere. And we don't have a clear policy on it yet. The other piece is that I sit at the intersection of marketing and revenue data, so I'm particularly sensitive about pipeline numbers, contact data, anything that touches our prospects. We're Series A, we don't have a big IT or security team watching this stuff. So it's mostly running on the honor system right now, which feels okay until it doesn't.
What's the most important thing you need to understand or solve here?
For us, the biggest thing right now is just knowing what's actually going out the door. We're a lean marketing team, and people are pasting campaign briefs, audience segments, ICP data — stuff that has real strategic value — into whatever AI tool they found that week. And I genuinely don't have full visibility into that. It's less about policy for me and more about understanding the exposure. Like, if someone's dropping our targeting logic or a competitor analysis into a free-tier consumer tool, that's a real risk — not just a compliance checkbox. I'd want to know where that data is going and whether it's being used to train something downstream. The policy side is almost secondary to just getting a clear picture of what the actual usage looks like across the team.
What does 'good' look like to you — and how far are you from that today?
Good, in my mind, is knowing what tools my team is actually using, having some baseline confidence that customer data isn't flowing into random consumer AI products, and having a policy that people actually understand rather than just a doc that lives in Confluence that nobody reads. Right now we're pretty far from that. We're a Series A company, so security and IT are lean — there's no dedicated team doing Shadow AI audits or anything like that. I use a handful of AI tools personally, my team uses others, and I'm honestly not certain what's been reviewed versus what people just started using because it worked. The procurement process is loose enough that you can expense a $40/month tool without much scrutiny. The thing I keep thinking about is what one of our procurement-side peers described — that middle ground of company-controlled infrastructure where you're the only tenant. That feels like the right direction for anything touching customer or pipeline data, but we're nowhere near having the resources to set that up.
What would change your perspective on this entirely?
That's a fair question. I think the thing that would shift my perspective most is if we actually saw meaningful enforcement — not just policy documents sitting in a SharePoint somewhere, but real examples of companies taking action when an employee pasted customer data into a public LLM and something went wrong. Right now it feels like the risk is theoretical enough that most teams, including ours, are treating it as a compliance checkbox rather than an active threat. If I started seeing incidents that had real downstream consequences — a deal lost, a legal exposure surfaced — I'd take the operational side of this a lot more seriously. The other thing is tooling that actually fits how marketing teams work, because right now the friction of "approved" AI paths is high enough that people route around them anyway.
What question are you not being asked that you wish someone would ask?
The data leakage framing gets a lot of attention, but nobody really asks about the *productivity cost of over-restriction*. We blocked a bunch of tools early on, and what actually happened is people just found workarounds or stopped using AI altogether — and then our velocity on content and campaign work slowed down noticeably. There's a real tradeoff between locking things down and actually letting your team move fast, and I feel like most of the security conversation focuses entirely on one side of that equation.
"It's less about policy for me and more about understanding the exposure. Like, if someone's dropping our targeting logic or a competitor analysis into a free-tier consumer tool, that's a real risk — not just a compliance checkbox."
Chris is moderately concerned about AI-related data leakage and shadow IT on his small marketing team, but frames it in measured, pragmatic terms rather than alarm. His core issue is visibility — he doesn't know which tools his team is actually using, and he suspects several unsanctioned tools are in play. Sensitive demand gen data (pipeline, CAC, conversion rates) is potentially being pasted into public LLMs, which makes him uncomfortable from compliance and competitive standpoints, though he acknowledges uncertainty about the actual technical risk. He estimates the org is roughly halfway to 'good,' with a policy on paper but thin monitoring and enforcement. He's not expecting a near-term fix — security is one of many competing priorities at a Series A. His most distinctive contribution is flagging the productivity cost of over-enforcement: blanket AI blocks create workarounds and slow teams down, and he feels this tradeoff is underrepresented in security conversations.
Tell me what's top of mind for you on this topic right now — what are you wrestling with?
Right now the thing I keep coming back to is data leakage through the AI tools my team is using day-to-day. We're a small marketing team, and people are pasting campaign briefs, prospect data, competitive intel — stuff that's genuinely sensitive — into ChatGPT or Claude without really thinking about where that data goes. I don't have a strong view on exactly how much risk that creates technically, but it makes me uncomfortable from a compliance and competitive standpoint. The other thing is I'm not even sure what tools people are actually using. I know what I've sanctioned, but I'd guess there are another five or six tools being used that nobody told IT or me about. At a Series A company you don't have a big security apparatus watching all of this, so it's pretty much on the honor system right now. That's the part that keeps me up a little.
What's the most important thing you need to understand or solve here?
For us, the core problem is really just visibility. I genuinely don't know what AI tools my team is using day-to-day. I know they're using *something* — ChatGPT, Claude, maybe some point solutions baked into our martech stack — but whether any of that involves prospect data or proprietary campaign performance info getting sent to a third-party model, I can't tell you with confidence. And from a demand gen perspective, the data we're working with isn't trivial. We're talking about pipeline data, CAC by channel, conversion rates — stuff that's competitively sensitive. So the question I keep coming back to is: where is that data actually going when someone pastes it into a prompt?
What does 'good' look like to you — and how far are you from that today?
Good, for us, would be knowing with reasonable confidence what AI tools are actually in use across the org, having a clear policy that people understand, and some lightweight enforcement that doesn't kill productivity. That's honestly not a high bar, but we're not fully there yet. Right now we have a policy on paper, but adoption of it is pretty uneven. Marketing and sales are using all kinds of things — ChatGPT, Claude, various prospecting tools — and IT doesn't have full visibility into what's hitting external APIs with potentially sensitive data. The data leakage piece is what keeps me up a little, specifically around things like customer lists or pricing assumptions ending up in prompts sent to third-party services. I'd say we're maybe halfway to "good." We know the problem exists, we have some guardrails, but the monitoring and enforcement layer is pretty thin. It's less about being years away and more about prioritization — security isn't the only thing competing for attention at a Series A.
What would change your perspective on this entirely?
If we had a real data leakage incident — like something actually attributed to an employee pasting customer data into a public LLM — that would probably shift how seriously we treat enforcement versus awareness. Right now it's more policy and trust-based, and because nothing has blown up visibly, there's not a lot of internal urgency to go further. The other thing that would move me is if a vendor we actually use for demand gen or analytics had a breach tied to AI data handling. That would immediately make me ask harder questions about what our tools are doing with our inputs — like, do I actually know where that prompt goes after I hit enter in some AI-assisted ad platform?
What question are you not being asked that you wish someone would ask?
The data leakage angle gets a lot of attention, but nobody really asks about the productivity tax of locking things down too hard. Like, when security teams push a blanket block on consumer AI tools, my team finds workarounds or just slows down — and that has a real cost too. There's a version of "secure" that quietly kills output, and I don't see that tradeoff getting much airtime in these conversations.
"Good, for us, would be knowing with reasonable confidence what AI tools are actually in use across the org, having a clear policy that people understand, and some lightweight enforcement that doesn't kill productivity. That's honestly not a high bar, but we're not fully there yet."
Marcus is a pragmatic, analytically-oriented VP who is genuinely concerned about AI-related data leakage but frames it as a manageable governance gap rather than a crisis. His primary worry is the lack of visibility into what sensitive data — campaign briefs, competitive intel, pricing, customer data — flows into third-party AI models, particularly through AI features embedded in already-approved SaaS tools (not just standalone AI products). He acknowledges the informal policy is ineffective and that tooling is further along than data governance instrumentation. Notably, he describes the risk as currently theoretical and expects external pressure (a real incident or enterprise customer security reviews) would be required to meaningfully shift internal prioritization and budget. His tone throughout is measured and self-aware rather than alarmed.
Tell me what's top of mind for you on this topic right now — what are you wrestling with?
Right now the thing I keep coming back to is data leakage. My team is using AI tools constantly — Claude, ChatGPT, various writing assistants baked into other products — and I genuinely don't have full visibility into what's going in those prompts. We're talking about campaign briefs, competitive positioning, pricing strategy in some cases. That stuff is sensitive. We have an informal policy that says "don't paste confidential info into consumer AI tools," but informal policies are basically just wishful thinking. What I'm wrestling with is the gap between what IT and security want us to do and what actually happens day-to-day when someone's trying to hit a deadline. The other piece is that I'm not sure our security team even has a clear picture of the scope. Shadow AI isn't new — people have always installed unauthorized tools — but the surface area now is so much larger because AI is embedded in products we already pay for. It's not just someone going to a separate website anymore.
What's the most important thing you need to understand or solve here?
For us, the core question is really about data leakage. We're a B2B SaaS company, so we're handling customer data, competitive intel, pricing information — stuff that genuinely matters if it ends up in a third-party model's training pipeline or gets exposed in some other way. The secondary piece is just knowing what's actually happening. Our team is using AI tools constantly — that's not going away and I wouldn't want it to — but I don't have great visibility into which tools, which data, and under what terms. That's the gap I'd want to close before I'd feel like we have a real handle on it.
What does 'good' look like to you — and how far are you from that today?
For us, "good" looks like employees having sanctioned tools that actually meet their needs, so they're not defaulting to personal ChatGPT accounts to get work done. And then layered on top of that, some visibility into what data is moving where — not necessarily locking everything down, but having a defensible answer if something goes sideways. How far are we from that? Closer on the tooling side than on the visibility side. We've rolled out approved tools for most of the high-frequency use cases in marketing and sales. The gap is really on the data governance piece — we don't have great instrumentation around what's actually being submitted to third-party models, and that's the part that keeps me up a bit, especially when people are pasting in things like customer data or draft contracts without really thinking about it.
What would change your perspective on this entirely?
If we actually saw a material breach traced directly back to unauthorized GenAI usage — like a confirmed incident where someone pasted customer data into a public model and it surfaced somewhere — that would shift how seriously I push for enforcement internally. Right now it's more theoretical risk management for us. The other thing that would change my view is if our legal or compliance team started getting pressure from enterprise customers during security reviews specifically about our AI policies — that's the kind of downstream signal that moves budget conversations faster than anything internal.
What question are you not being asked that you wish someone would ask?
That's a fair question. I'd probably want someone to ask about the gap between where security teams think employees are using AI and where they actually are. In marketing specifically, people aren't just using ChatGPT or Copilot — they're using it embedded in tools they already had. Canva has AI. HubSpot has AI. Jasper, Notion, half our martech stack. Security policies tend to focus on "did you use an unauthorized AI tool," but that framing misses the reality that AI is already baked into approved tools. Nobody's auditing what data flows through the AI features inside their existing SaaS subscriptions, and I think that's a much bigger exposure surface than someone sneaking onto Claude.
"Nobody's auditing what data flows through the AI features inside their existing SaaS subscriptions, and I think that's a much bigger exposure surface than someone sneaking onto Claude."
Marcus is a pragmatic, operationally-focused VP who is genuinely concerned about Shadow AI risk — specifically data leakage from consumer-tier AI tools used by his marketing team — but is not alarmist or in crisis mode. He estimates he is roughly 60% of the way to his definition of 'good,' with SSO and an approved stack in place but lacking a meaningful visibility layer and a formal data classification framework. His central tension is wanting to preserve team productivity while managing a risk he can't yet fully see or measure. He is candid that current precautions are driven more by legal discomfort than documented incidents, and he would recalibrate toward enablement if the threat model proved less severe. He also surfaces a structural governance gap: marketing bears much of the AI risk exposure in practice but lacks formal accountability or a seat at the policy table.
Tell me what's top of mind for you on this topic right now — what are you wrestling with?
Right now the thing I'm actually wrestling with is the data leakage question. My team uses AI tools constantly — for copy, for campaign briefs, for competitive research — and I genuinely don't have full visibility into what's going into which tools. We have some informal guidance, but it's not a real policy. What I keep coming back to is: we're a Series B, we have customer data, we have pipeline data, we have pricing information — and I don't know with confidence that none of that is being pasted into a consumer-tier ChatGPT or Claude session. The vendors say they're secure, but "they say they're secure" isn't an audit. The honest tension for me is that I also don't want to lock things down in a way that kills productivity, because AI is genuinely useful for my team. So it's less a philosophical debate and more a practical one: how do you enforce something reasonable without having to become the IT policy police?
What's the most important thing you need to understand or solve here?
For us, the core question is really: what's actually leaving the building? My team uses AI tools constantly — for copy, research, campaign briefs, competitive analysis — and I have reasonable confidence in what we've formally deployed, but I have essentially zero visibility into what people are doing on their personal ChatGPT accounts or free-tier tools on their work laptops. The data leakage angle is what I keep coming back to. We handle customer data, pipeline information, sometimes competitive intel that's genuinely sensitive. If someone's pasting that into a consumer-grade tool to speed up a task, I don't know about it, and I'm not sure our security team does either.
What does 'good' look like to you — and how far are you from that today?
Good, to me, is a state where we have visibility into what tools people are actually using, some reasonable guardrails around what data is flowing where, and a policy framework that doesn't require a security ticket every time someone wants to try a new tool. Right now we're probably at 60% of that — we have an approved stack, we have SSO covering most of it, but the visibility layer is still pretty thin. I can't tell you with confidence today exactly what third-party AI services my team is hitting with customer data or campaign data. The gap that bothers me most is the data classification piece. We haven't done a rigorous job of tagging what's sensitive enough that it shouldn't go into a consumer-tier LLM versus what's fine. Until that's cleaner, the policy enforcement question is almost secondary — you can't enforce rules around data you haven't defined.
What would change your perspective on this entirely?
That's a fair question. If I saw clear evidence that the data leakage risk from consumer AI tools was actually low — like, audited, published incident data showing that sensitive information from tools like ChatGPT or Claude wasn't being used in ways that hurt companies — I'd probably loosen up on how aggressively we push policy enforcement on the marketing side. Right now a lot of what's driving our posture is precaution and legal's discomfort, not a documented breach we can point to. If the threat model turned out to be more theoretical than real for a company at our size and data sensitivity level, I'd shift energy toward enablement rather than restriction.
What question are you not being asked that you wish someone would ask?
That's a fair question. I'd say — nobody really asks marketing leaders how we're *actually* accountable for Shadow AI risk, versus how accountability looks on paper. On paper, it's Security and IT's problem. In practice, my team is generating the most AI-assisted content, running it through the most third-party tools, and touching the most customer-facing data. So when something leaks or a vendor's terms turn out to be unfavorable, the blast radius hits us first. But I'm not in the policy meetings, I don't have a seat at the governance table, and I'm not being asked to sign off on anything formally. I don't have a clean answer to how that gap gets closed — I just notice that the conversations I'm in are either at the very top (exec-level "are we AI-ready" discussions) or very operational (which tools are approved). The middle layer — who owns risk for a specific function like marketing — feels genuinely unresolved at most companies I talk to, including ours.
"The gap that bothers me most is the data classification piece. We haven't done a rigorous job of tagging what's sensitive enough that it shouldn't go into a consumer-tier LLM versus what's fine. Until that's cleaner, the policy enforcement question is almost secondary — you can't enforce rules around data you haven't defined."
Synthetic pre-research uses AI personas grounded in real buyer archetypes and (where available) Gather's interview corpus. It produces directional signal — hypotheses worth testing — not statistically valid measurements.
Quantitative figures are projected from interview analyses using Bayesian scaling with a conservative ±35% margin of error. Treat as estimates, not census data.
Reflect internal response consistency, not statistical power. A 90% confidence score means high AI coherence across interviews — not that 90% of real buyers would agree.
Use this to build your screener, align on hypotheses, and brief stakeholders. Then run real AI-moderated interviews with Gather to validate findings against actual respondents.
Your synthetic study identified the key signals. Now validate them with 150+ real respondents across 8 audience types — recruited, interviewed, and analyzed by Gather in 48–72 hours.
"How are enterprise security teams handling Shadow AI risk, unauthorized GenAI usage, data leakage, and policy enforcement in 2026?"