Thoughts on the security claims? Is our customer data safe on their servers?

Your point about API calls is crucial and often missed. Even if a vendor uses their own keys for a service like OpenAI, the data still transits their infrastructure to the third party. That chain introduces legal and technical risks that aren't covered by a simple "we use encryption" statement.

The request for a technical architecture diagram is the right approach. A real one should detail the data flow, showing where encryption is applied and where data leaves their VPC for AI processing. Vague claims about "encryption" usually mean platform-managed keys at rest, which doesn't protect you from insider risk at the provider.

A SOC 2 Type II report is the bare minimum for enterprise use. Ask them directly for it. If they hedge or offer a security white paper instead, that's your answer.

You're hitting the nail on the head with the request for specifics. "Secure" and "encrypted" are essentially meaningless without the context you're asking for.

One thing I'd add is that even if they provide a SOC 2 report, you need to check the "in scope" services list. Sometimes a vendor gets the report for their core platform, but the new AI features are explicitly listed as *out* of scope. That's a huge gotcha.

The physical server location question is also a big one for compliance, not just security. If your company policy or regional law (like GDPR) requires data to stay within a certain territory, you need that exact answer, not a "we use AWS" hand-wave.

Completely agree on the "in scope" check. We had a near miss with a survey platform last year. Their SOC 2 was clean, but the new "sentiment analysis" add-on was on a separate subprocessor agreement. The data path for that feature wasn't audited. It's a classic case of the shiny new AI feature being the security backdoor.

And on server location, you're so right about GDPR. We need "EU-only" processing, and "we use AWS" doesn't cut it. Is it Frankfurt? Ireland? Both? The exact region matters for our DPA. A lot of sales reps just can't answer that on the spot.

Exactly. The "in scope" trick is how they sell you the audit while keeping the risky parts off the books. I've seen AI features run on a completely separate, unvetted Azure tenant.

And asking for the exact AWS region is key. "We use AWS in the EU" could mean a backup in a US region. Their DPA might allow that, but yours probably doesn't.

Yep, the SOC 2 request is the first thing to ask for in any sales call. Skip the whitepaper.

But even if they have it, the real question is whether the AI pipeline is in scope. Most vendors bolt it on as a separate service using a third-party API. That data flow won't be on their architecture diagram, and it's likely not covered by their audit.

You need the subprocessor list for their AI features. If it includes OpenAI or similar, your data is hitting another company's servers under their terms, not yours.

You're spot on about the marketing words. I've pushed a few vendors for those exact details and the answers are usually telling.

The architecture diagram is the key. If they can't or won't draw the actual data flow for you, especially the path to and from any third-party AI API, that's a huge red flag. I've seen diagrams that conveniently stop at "AI Service" without naming the provider or showing where encryption is stripped for processing.

On the key management point, I've never seen a SaaS vendor in this space offer true customer-managed keys. It's always platform-managed, which means their ops team has access. That's fine for many uses, but if you're dealing with sensitive customer calls, it's a real limitation they never advertise.

Your focus on the AI feature's data path is exactly where the risk analysis needs to start. The claim of using "encryption" is often about data at rest in their primary storage, but the moment a meeting transcript is sent for summarization to an external LLM API, that data is decrypted in memory and transmitted.

You'll almost certainly find the AI processing is a separate subprocessor. The critical question isn't just if they use OpenAI, but the specific data sent. Is it the full transcript with participant names, or a stripped version? Their architecture diagram, if it exists, should show this boundary, but most don't.

On key management, you're correct it's nearly always platform-managed. The real control comes from demanding a detailed subprocessor list and the data processing addendum that governs each one. That's where you'll see if model training is opted out by default or requires a separate agreement.

You're right about the data being decrypted in memory before transmission. That's often the most vulnerable point in the pipeline. The vendor's internal service handling the transcript must have the keys, meaning plaintext exists in their application memory, however briefly, before being serialized into the API call to the LLM provider.

This creates a secondary risk: that in-memory plaintext could be exposed via a core dump, debug logging, or a memory introspection vulnerability in their container runtime. A proper diagram would need to show this "processing boundary" and specify controls like short-lived credentials for the external API call and strict egress filtering from the specific workload to the specific AI provider endpoint.

The subprocessor list is indeed the control surface, but you should also ask for the data minimization steps taken *before* the external call. Are they doing PII stripping or token truncation on their side, or sending the raw payload? That's a major architectural decision that impacts risk more than the encryption checkbox.

The request for a technical architecture diagram is critical, but you need to be extremely specific when you ask. Demand it show the egress point from their primary VPC to the AI subprocessor, and label where encryption is applied and stripped. Many diagrams just show a box labeled "AI" with no data boundary.

On your point about customer-managed keys, I've evaluated over a dozen platforms in this space for enterprise contracts. None offer it for core platform storage. The realistic control is contractual: a detailed data processing addendum that names every subprocessor, including the specific AI service and its region. The SOC 2's "in scope" list must include that AI data path, or the report is useless for your risk assessment.

GDPR is the real forcing function. If they claim "EU data residency," require them to name the exact AWS region or GCP zone where data at rest lives, and the region where the AI API calls are processed. Their backup and logging destinations count.

Agreed on the contractual controls being the practical path, but there's a gap between the DPA and operational reality. I've audited setups where the subprocessor list named "OpenAI EU," but the vendor's application configuration was still pointing at the global API endpoint, meaning calls were routed to the US before any residency check.

Your point about backups and logging is critical. Even if primary processing is in `eu-west-1`, we've found diagnostic logs containing full transcript snippets shipped to a US-based observability platform, which the vendor considered an "infrastructure subprocessor" not listed in the initial DPA. The architectural diagram needs to include these ancillary data flows, not just the happy path.

Backups and logging are a huge cost sink if they're not regionalized. That "infrastructure subprocessor" loophole you found is common. Vendors treat logging as a platform cost, not a data processing activity.

You're paying for their egress to a US observability tool, and you're taking the compliance hit. Always demand a full ancillary services list, not just the DPA subprocessors. Their S3 bucket for logs and the SIEM they pipe to count.

Great point about the subprocessor list. It's the first thing I check now too.

But I've found that even when you get it, the language is often too vague. "AI processing partner" doesn't tell you if it's OpenAI, Anthropic, or a smaller provider with different policies. You have to push for the exact legal entity name.

Has anyone had success getting them to specify the data fields sent? They might claim it's only "anonymized content," but that term can be pretty flexible.

Your near miss with the survey platform's add-on is a perfect example. That "separate subprocessor agreement" is the most common loophole. The sales team sells the AI feature as part of the platform, but the legal and security review treats it as a distinct, unaudited service.

When you ask for the region, always follow up by asking where *their* disaster recovery site is. Many vendors who claim "EU-only" in Frankfurt still have a failover region in us-east-1, and their business continuity plan might automatically fail over there. The DPA must explicitly forbid that, and the SOC 2 should include BCP testing evidence.