The safest AI request is not the one with the longest confidentiality clause. It is the one that never receives data it does not need.
Protecting company information therefore starts before the model call. The system must decide what the data is, who may use it, which fields are required, where copies are created and when they disappear.
Map the complete data path first
Draw the path from the source system to the user, including temporary files, queues, prompts, retrieved passages, model responses, logs, analytics and human review screens. A secure vendor contract does not protect an untracked export on a developer laptop.
ICO guidance on AI security and data minimisation recommends documenting movements and storage of personal data and deleting intermediate files when they are no longer required.
For every component, record the owner, purpose, data categories, location, retention period, sub-processors and deletion mechanism.
Classify data before it reaches a prompt
A small company does not need a complicated classification system. Four operational levels are often enough: public, internal, confidential and restricted.
- Public data may enter approved tools under normal controls.
- Internal data requires an approved business account and retention rules.
- Confidential data needs a documented use case, named owner and least-privilege access.
- Restricted data, such as credentials, raw identity documents or protected health information, is blocked unless a specifically approved architecture exists.
Minimise the context, not only the database
A user who may read an entire customer record does not automatically need to send the entire record to a model. Select fields for the task and remove the rest before retrieval or prompting.
NIST AI RMF identifies data minimisation, de-identification and aggregation as techniques that can support privacy-enhanced AI systems. The exact control depends on the use case and its accuracy requirements.
For a delivery-status reply, an order identifier and current status may be enough. Full address history, payment notes and unrelated support messages add exposure without improving the answer.
Keep authorisation outside the model
The model may suggest which record is relevant. Deterministic application code must decide whether the current user is allowed to read it.
This is especially important when connecting AI to a CRM. Preserve tenant, role and record-level permissions during search. Similarity is not authorisation.
Use separate service identities, short-lived credentials where possible, narrow API scopes and explicit allowlists for tools. Do not put secrets in prompts or system instructions.
Redact and tokenise before the model call
Redaction should happen in a controlled preprocessing step. Detect fields such as email addresses, phone numbers, account identifiers and contract parties, then remove or replace them when the task does not require the original values.
Tokenisation is useful when the workflow must preserve relationships. The model can work with a stable placeholder while a separate protected service restores the value only after validation.
OWASP guidance on sensitive information disclosure recommends sanitisation, strict access controls, restricted data sources and clear retention policies. A prompt instruction alone is not a security boundary.
Treat RAG as a new copy of company knowledge
A RAG system creates indexes, embeddings, chunks and metadata. These derived assets may expose the same business information as the source documents.
Carry source permissions into ingestion and retrieval. Partition tenants, exclude expired documents, keep stable source identifiers and test that a user cannot retrieve a passage they cannot open in the original system.
Documents extracted through an AI document pipeline also need field validation and lifecycle controls before their content is indexed.
Choose vendors by data behaviour
Ask where prompts, files, embeddings, outputs and abuse-monitoring logs are processed and stored. Verify default retention, training use, regional options, encryption, deletion, access logging, incident notification and the complete sub-processor list.
Record the exact product tier and API configuration. A consumer chat product, a business workspace and an API may have different controls even when they use models from the same provider.
Legal requirements depend on jurisdiction and data category. When personal or regulated data is involved, involve the responsible privacy or legal specialist before launch.
Design logs that support audits without becoming a leak
Logs should answer who used the system, which source was accessed, what tool was called, whether a human approved the action and which software version ran. They do not need to store every raw prompt forever.
Separate operational metadata from sensitive payloads. Mask values, restrict log access, define retention by purpose and test deletion. Protect backups and analytics exports under the same rules.
The ICO governance toolkit recommends mapping information flows, assigning technical and operational responsibilities, controlling changes and running risk-based audits.
Prepare a practical incident response
The NIST Privacy Framework can be used alongside security and AI risk practices to identify and manage privacy risks created by data processing.
- revoke the affected service identity or API key;
- disable the tool or workflow without taking unrelated systems offline;
- preserve minimal forensic evidence;
- identify sources, prompts, outputs, logs and downstream recipients;
- apply contractual and legal notification procedures;
- fix the trust boundary and add a regression test before reopening.
How I separate secrets from publishing automation
In a multilingual publishing workflow I use a bearer token only at runtime for upload and article API calls. The token is not written into the article payload, Trello journal, Slack report or generated source file.
The public catalogue can be read separately for duplicate checks and internal links. Write access is introduced only for the exact upload, draft creation and full update steps, and each response is verified before the next step.
This is a small example, but the principle scales: business context may travel through the workflow; credentials and unrelated records must not.
Questions and answers
Can employees paste confidential data into a business AI account?
Only if the company has approved that exact product, data category and use case. A business subscription alone does not replace classification, minimisation and access controls.
Is encryption enough?
No. Encryption protects specific states and paths, but it does not prevent an authorised workflow from sending excessive data or returning it to the wrong user.
Should every prompt be stored for auditing?
Not necessarily. Store the minimum evidence required for operations, security and compliance, and keep sensitive payloads under shorter, explicit retention rules.
Are embeddings harmless because they are not plain text?
No. Treat embeddings and indexes as derived sensitive assets. Restrict access, preserve tenant boundaries and test retrieval against source permissions.
Where should a small business start?
Map one workflow, classify its data, remove unnecessary fields, define a named owner and test both normal access and attempted cross-user retrieval before launch.