Most vendors will tell you they take security seriously. Here’s how to find out if they actually do.
There’s a version of this conversation that plays out in every enterprise AI evaluation. A vendor shows up with a polished deck, a live demo that works perfectly, and somewhere in the middle slides — usually around slide 14 — a page titled “Enterprise-Grade Security.” It has a few compliance logos on it. Maybe a padlock icon for good measure.
And then the meeting ends, and the security question is considered answered.
It isn’t.
The logos are real, but they don’t tell you what happens to the email your sales director pasted into the chat window this morning. They don’t tell you whether a vendor engineer in another country can read your employees’ conversation history. They don’t tell you what the vendor does with your data after you decide to cancel.
These aren’t hypothetical concerns. As AI platforms become the place where employees draft legal documents, summarize client calls, and ask questions they’d normally ask their manager, the data flowing through these systems is some of the most sensitive your company produces. Getting the security question wrong isn’t just an IT problem — it’s a liability.
Here are the seven questions that separate vendors who are genuinely secure from those who are just good at appearing secure.
1. Is our data used to train your models?
Start here. This is the most important question on the list and the one where the gap between marketing language and actual policy is widest.
The right answer is an unambiguous no, followed by a clear explanation of how that’s enforced — contractually and technically. What you don’t want to hear is “we use aggregated, anonymized data to improve our service,” which is vendor-speak for “yes, but we’ve made it sound acceptable.”
Push on this specifically: does the answer change depending on which pricing tier you’re on? Some platforms opt enterprise customers out of training by default but keep the setting on for smaller teams. Find out where the line is, get it in writing, and make sure the contract reflects what the salesperson is telling you.
If a vendor is evasive here, that’s your answer.
2. Who at your company can actually access our conversation history?
Vendor security pages focus almost entirely on the external threat — unauthorized people getting in from outside. This question handles the internal one.
At most AI platforms, some number of employees can access customer data. That’s often necessary for debugging, support, and safety monitoring. The question isn’t whether access exists — it’s how it’s controlled, logged, and limited.
Ask: does access require approval? Is every access event logged? Can a customer request to see those logs? Is there a formal access review process?
A vendor who can answer these questions quickly, with specifics, has thought about them seriously. A vendor who pivots back to the compliance slide hasn’t.
3. Can we control what each employee can see and do?
Enterprise AI platforms get adopted unevenly. Finance uses it to draft board memos. Customer support uses it to answer tickets. Engineering uses it to write code. These teams shouldn’t all have the same access to the same information.
What you’re looking for here is real role-based access control — not just the ability to create user accounts, but the ability to define which knowledge sources each team can query, which features they can use, and what they’re allowed to share externally. Ideally, you should also be able to restrict access to specific documents or folders, not just broad categories.
Ask them to show you, live, what an admin panel actually looks like. How many clicks does it take to remove a user who just left the company? How quickly does that access get revoked across every connected integration? If the demo involves a lot of “our team will set that up for you,” be cautious.
4. Is there a complete audit trail — and can we see it?
This one matters for two reasons. The practical one: if something goes wrong — a data leak, a policy violation, an employee sharing something they shouldn’t have — you need to know what happened and when. The regulatory one: in healthcare, finance, and legal environments, having a record of AI interactions isn’t optional.
What you want is a searchable log of who used the platform, what they queried, what the system returned, and when. Not a summary. Not an aggregate. A per-session, per-user record that you, the customer, can export and search.
Some vendors offer this. Many offer a limited version that covers enough for sales conversations but not enough for a compliance audit. Ask specifically what the log contains, how long it’s retained, and whether you can pull it yourself or have to request it from the vendor.
5. What happens to our data when we cancel?
This question gets asked far less often than it should, which is exactly why vendors have given themselves generous answers in the fine print.
When you stop using a platform, what happens to the documents you connected, the conversations your employees had, the custom prompts and workflows you built? The ideal answer: your data is deleted within a defined window, you can request confirmation, and the contract specifies this explicitly.
The less ideal answer, which is more common: data is retained for some period “as required by law,” the definition of which varies and is usually controlled by the vendor.
Pay attention to the data portability question too. Can you export your conversation history, your custom knowledge base, your team’s saved prompts before you leave? The ability to take your data with you is a meaningful signal about how much the vendor actually treats it as yours.
6. Can we run this in our own environment?
Not every company needs this. But every company evaluating an AI platform should understand what the option is and what it costs.
On-premises or VPC (Virtual Private Cloud) deployment means your data never leaves your infrastructure. No matter what happens at the vendor — acquisition, breach, policy change — your conversations stay within your perimeter. For companies in regulated industries, or companies with data residency requirements in the EU or other jurisdictions, this can be a hard requirement rather than a preference.
If the vendor offers this, ask what functionality changes in the self-hosted version. Sometimes features like web search, automatic updates, or certain integrations are only available in the cloud version. Understanding the tradeoffs upfront saves painful conversations later.
If the vendor doesn’t offer it at all, understand clearly: you are fully dependent on their infrastructure, their uptime, and their future decisions about how to operate it.
7. Have you ever had a security incident? What happened?
This is the question that makes vendors uncomfortable, which is why it’s worth asking.
Every company that has operated at scale for more than a few years has had some form of security event — a misconfigured bucket, an unauthorized access, a credential phishing attempt that worked. The companies with good security culture have documented responses, post-mortems, and improvements they made as a result. The companies without good security culture either say no (which is often not credible) or give vague, PR-managed answers.
What you’re listening for: specificity, accountability, and evidence that they learned something. “We identified an unauthorized access event in Q3 2023, notified affected customers within 48 hours, rotated all credentials, and changed our access policy to X” is a good answer, even though the incident itself is bad. “We take security very seriously and haven’t had any breaches” is not.
Track record is one of the best predictors of how a vendor will behave the next time something happens — and in security, there is always a next time.
What good answers actually look like
The vendors who take security seriously share some common traits. They don’t redirect every question to the compliance slide. They can answer specifics without looping in the solutions engineer. They proactively share their DPA (Data Processing Agreement) before you ask. They have a named security contact, not just a security@ alias.
The vendors who are doing security theater are also recognizable. They lead with logos. They use phrases like “bank-level encryption” without explaining what that means in their architecture. They’re reluctant to share actual documentation. And they answer questions about data access with answers about data protection — two different things.
These seven questions won’t guarantee you’ll choose perfectly. But they’ll surface the difference between a company that built security into their platform and one that bolted a compliance program onto a product that wasn’t designed for it. In enterprise AI, that difference matters more than most buyers realize until it’s too late.
Grengin was built for teams where security isn’t a feature — it’s the foundation.
Every deployment ships with SSO, full audit logs, role-based access controls, and a data policy that’s straightforward by design: your conversations stay in your environment, your data is never used to train anything, and we never see your payment details.
That last part reflects something we think matters architecturally. Grengin runs in your infrastructure, not ours. There are three ways to do it:
- Self-host from source — Clone the repo and run it yourself. Free, no feature gates, bring your own everything. One
docker compose upand you’re running. - AWS Marketplace — One-click launch into your own AWS account. You pay $0, Its totally free, Just your computing fee to AWS.
- Azure Marketplace — Same model, billed through Azure. Launching soon.
The same software runs all three ways. You choose how involved we are — which by default is not at all.
If you’re working through a vendor evaluation and want to see exactly how Grengin answers the questions above, view it on GitHub or launch it on AWS.
