Blog · AI and self-service analytics · Compliance
A checklist for anyone about to put a customer ledger, a CRM export or a contract file into an AI analytics tool. It covers what is actually in a sales export that makes it sensitive, the nine questions to put to any vendor, covering model training, where data is processed, who at the vendor can see it, retention and deletion, tenancy, pseudonymisation, access control, the model provider behind the tool, and what happens at exit, what a good answer sounds like for each, and how to reduce the risk yourself by removing what the analysis does not need.
A ledger export holds who buys what from you, at what price, in what volume. It is among the most commercially sensitive files a business has. Here is what to ask before it goes anywhere.
| Column type | Sensitivity | Needed for most analysis? |
|---|---|---|
| Customer identifier or account number | Low on its own | Yes |
| Customer name | Commercial; personal if a sole trader or individual | Only for display; can be replaced by an identifier |
| Contact name, email, phone | Personal data | No |
| Products, quantities, dates | Commercial | Yes |
| Prices, discounts, margins | Highly commercial | Yes, for price and margin measures |
| Rep and owner names | Personal data about employees | An identifier will do |
| Free-text notes | Unpredictable; may contain anything | No |
| Addresses | Personal for individuals | Region or postcode area usually enough |
First step, before any vendor question: remove what the analysis does not need. Contact details and free-text notes are the usual candidates. What is not uploaded cannot leak.
1. Is my data used to train or improve any model? Good answer: no, contractually, for both the vendor and the model provider behind it, with no opt-out needed. Poor answer: only in aggregated form, or a setting you have to find.
2. Where is the data stored and processed? Good answer: named regions, a list of sub-processors, and a commitment to tell you before either changes. Matters for privacy law, and for sectors with data residency rules.
3. Who at the vendor can see my data? Good answer: nobody by default; named roles under logged, time-limited access for support, with your approval. Poor answer: our engineers, when needed.
4. How long is it kept, and can I delete it? Good answer: a stated retention period, deletion on request within a stated time, backups included, and written confirmation. Ask whether uploaded files are kept after processing or only the derived tables.
5. Is my data in a tenant of its own? Good answer, for sensitive data: a separate tenant, meaning separate storage and keys, not just a customer ID column in a shared database. Shared infrastructure is normal for lower tiers; know which you are buying.
6. Can the analysis run on pseudonymised data? Good answer: yes; identifiers instead of names, with the key held on your side, so that nothing the vendor holds identifies a customer. Account-level lists still work, because you re-attach names when the results come back. See pseudonymisation versus anonymisation.
7. Who in my company can see what? Good answer: role-based access, so a rep sees their book, a manager their team, and margin is visible only to those who should see it; single sign-on; an audit log of who viewed and exported what. Internal exposure is the more common incident.
8. Which model provider receives which parts of my data? AI tools usually call a third-party model. Good answer: named provider; a statement of exactly what is sent, such as column headers and a sample for mapping, or computed summary tables for explanation, and what is never sent, such as the full ledger; and the provider's own no-training and retention terms. In a design where code does the arithmetic, the model never needs the raw rows.
9. What happens when I leave? Good answer: export of your derived data and definitions, deletion of everything including backups within a stated period, and confirmation in writing.
| Claim | Evidence to ask for |
|---|---|
| Security practices | Independent audit report, such as SOC 2 or ISO 27001, current, with scope that covers the product |
| No training on customer data | The clause in the contract and in the model provider's terms |
| Sub-processors | A published, dated list |
| Deletion | The procedure, and a sample deletion confirmation |
| Tenancy | An architecture description your security team can question |
| Penetration testing | Summary of the latest test and remediation |
| Privacy law | A data processing agreement; transfer mechanism if data leaves your region |
Answers without documents are intentions.
| Sector | Extra consideration |
|---|---|
| Wealth, insurance, banking | Clients are often individuals: personal data throughout; regulators expect outsourcing due diligence |
| Healthcare supply | Facility data is commercial; anything patient-level must not be in the export at all |
| Public sector suppliers | Contract terms may fix data location |
| Legal and accounting firms | Client confidentiality duties; client identity itself may be confidential |
| Pharma | Prescriber-level data is personal and regulated |
Two design choices are relevant here, stated so they can be checked. Intake is by files only: you decide what is exported and uploaded, and there is no standing connection into your systems. And the Enterprise plan runs in a separate pseudonymised tenant that works on client identifiers only; pseudonymised data and a separate tenant are not part of the Starter or Business plans. Put the nine questions above to us as you would to anyone, and ask for the documents.
The whole CRM export uploaded. Contacts, notes and all, for an analysis that needed four columns.
A consumer chatbot used for a customer ledger. Different terms from the business version; nobody checked.
Security reviewed after the pilot. Data already shared; findings arrive late.
Anonymised data requested. The account lists the project was for become impossible. Pseudonymised was what was needed.
Internal access ignored. Every rep can see every margin.
Minimise what you upload, prefer files and pseudonymised identifiers, and get documented answers on training, location, vendor access, retention, tenancy, internal access, the model provider, and exit. For the broader buying checklist, see ten questions to ask an AI sales analytics vendor.
Usually partly. Company names, products and amounts are commercial data. Contact names, email addresses, phone numbers, and anything about sole traders or individual clients, such as wealth or insurance customers, is personal data, and privacy law applies to it. Check which columns are in the export; most analysis does not need the personal ones.
Pseudonymised data has names replaced by identifiers, with a key held separately that can reverse it. It is still personal data in law, and much lower risk in practice, because a breach exposes codes and amounts, not names. Anonymised data cannot be traced back at all, which also makes account-level lists impossible. Sales analytics needs the first; see the comparison page on this site.
Yes. With files, you choose exactly what leaves your systems, column by column, and nothing else can. A live connector is granted access to a system, often with broader read permissions than the analysis needs, and it stays open. Files are less convenient and far easier to reason about for a security review.