Enterprise AI Data Security: The Questions to Ask Before You Sign

A practical guide to enterprise AI data security for procurement, security, and IT leaders vetting an AI vendor. The questions to ask, the architecture that answers them, and the checklist to run before you sign.

If you are evaluating an AI vendor for an enterprise deployment, the model is the least interesting part of the security review. What matters is the plumbing around it: where your data sits, which users and services can read it, whether requests are logged, how long anything is retained, and whether your documents end up in someone else's training set. An AI assistant that reads across your internal systems is, in effect, a new access path into your most sensitive data. Treat it like one.

The questions enterprise procurement should ask any AI vendor

These are the questions we get asked in security reviews, and the questions we would ask if we were on the buying side. Every one of them should have a written answer before money changes hands.

Data residency and isolation

Where does your data physically live, and is it isolated from other customers? Ask which cloud regions store and process the data, whether processing can be pinned to a specific geography for compliance, and whether your tenant is logically or physically separated from everyone else's. Multi-tenant systems are fine when isolation is enforced in the data layer. They are not fine when isolation is a promise in a slide.

PII handling and minimisation

What personal data does the system touch, and does it need to? The right default is data minimisation: the assistant should only see the fields required to do the job. Ask whether PII is redacted or tokenised before it reaches the model, whether sensitive fields can be excluded from retrieval entirely, and how the vendor handles data-subject requests under GDPR or state privacy laws.

Access controls

Does the assistant respect your existing permissions, or does it read everything with a single service account? This is the question that catches the most vendors. If the AI indexes all of SharePoint under one privileged identity and then answers questions for any user, you have built a data-leak engine. The assistant must honour the same role-based access control your users already live under, so a person only ever sees what their role permits.

Audit logging

Can you prove, after the fact, what the system did? You want a record of every query, every document retrieved, every API call the assistant made, and every human override, written somewhere that cannot be quietly edited. If a regulator or your own security team asks what the AI accessed on a given day, the answer should be a query, not a shrug.

Retention and deletion

How long is anything kept, and can you delete it? Ask about retention windows for prompts, responses, and any cached context, whether you can set those windows, and whether deletion is real deletion or a soft flag. Confirm that a deletion request propagates to backups and to any downstream index.

Model and data-training boundaries

Is your data used to train anyone's model? For most enterprises the required answer is a hard no. Get it in writing: your prompts, your documents, and your outputs are not used to train or fine-tune shared models, and are not retained by any model provider beyond the request. If the vendor uses a third-party model API, ask what that provider's data-use terms are, because the vendor's promise is only as strong as its subprocessors'.

IP ownership and NDAs

Who owns what gets built, and what is the confidentiality posture? Ownership of the code, the prompts, and the outputs should sit with you. We support full IP transfer and sign NDAs as a matter of course, and we build to enterprise security standards. We do not claim certifications we do not hold, and we can work within your compliance requirements rather than asking you to bend to ours.

The architecture that satisfies these requirements

Good answers in a questionnaire mean nothing without an architecture that enforces them. Here is the shape of a system that holds up under enterprise scrutiny.

• Permission-aware retrieval that mirrors your RBAC. Retrieval runs in the context of the requesting user, not a superuser. The assistant asks your existing permission system what this person is allowed to see, then retrieves only from that set. The AI can never widen access beyond what the user already has.
• Field-level access control. Access is enforced not just per document but per field, so an engagement team, a business unit, or a region sees only the records and columns scoped to them. Two users asking the same question can correctly get different answers.
• Immutable audit logging. Every AI decision, every API call, and every human override is written to an append-only log. Records cannot be edited or deleted after the fact, which is what makes the log usable as evidence in a compliance or security review.
• Encryption in transit and at rest. Data is encrypted on the wire and in storage as a baseline, with key management that fits your policies. This is table stakes, not a feature.
• Human approval on material actions. When the assistant would do something consequential, sending an external message, changing a record, moving money, a human approves it first. The AI drafts and recommends. A person decides.

The through-line is simple: the AI operates inside your existing controls, it never becomes a new privileged identity, and everything it does is observable and reversible.

What this looks like in practice

Two recent engagements show the pattern, both anonymised.

For a 15,000-person FMCG supply chain organisation, we built an AI assistant that integrates 12 internal systems, including SharePoint and an ERP, behind single sign-on with role-based access control. Every user authenticates once, and the assistant surfaces only what that user's role permits. A planner and a plant manager can ask the same question and get answers scoped to their own access. The assistant reads across a dozen systems, but it never reads around a permission.

For a Big Four professional services firm, we integrated 8 source systems, including ERPs, with field-level access control enforced per engagement team, so consultants on one client engagement cannot see another engagement's data through the assistant. On top of that, every AI decision, every API call, and every human override is written to an immutable audit log. When the firm needs to demonstrate exactly what the system did on a given matter, the record is there and it cannot have been altered.

The procurement checklist

Run this against any AI vendor before you sign. Ask for answers in writing. A vendor that cannot commit these to a document is telling you something.

1. 1Data residency: name the regions where our data is stored and processed, and confirm whether processing can be pinned to a required geography.
2. 2Tenant isolation: describe how our data is isolated from other customers, and at which layer that isolation is enforced.
3. 3Access controls: confirm the assistant enforces our existing role-based access control per user, and never reads under a single privileged account.
4. 4PII minimisation: state what personal data the system touches, and how sensitive fields are redacted, tokenised, or excluded.
5. 5Audit logging: confirm that queries, retrieved documents, API calls, and human overrides are written to an immutable, queryable log.
6. 6Retention and deletion: state retention windows, confirm we can configure them, and confirm deletion propagates to backups and indexes.
7. 7Training boundaries: confirm in writing that our data is not used to train or fine-tune any shared model, including any third-party model provider.
8. 8Human approval: confirm that material actions require human sign-off before execution.
9. 9IP and confidentiality: confirm IP ownership sits with us, and that the vendor will sign an NDA and work within our compliance requirements.
10. 10Certifications: ask exactly which certifications the vendor holds, and treat any that cannot be evidenced as not held.

Enterprise AI security is not exotic. It is the discipline you already apply to any system that touches sensitive data, applied to one that happens to read and reason across all of it at once. The vendors worth trusting are the ones who build the assistant inside your controls rather than around them, who log everything, and who put a person in front of anything that matters. If you want to pressure-test an AI deployment against the checklist above, or you are scoping one and want the security model right from the first commit, Book a call and we will walk through how we would build it for your environment. You can also read more about how we approach this on our AI security page.