Use AI without leaking sensitive business data.

Do not start with the model. Start with the information and the action.

Before a business pastes documents into a copilot, connects a shared drive, builds an API workflow, or installs a local model, answer two questions: what may this system know and what may it do?

The boundary should cover the data, the people and services that can reach it, retention, provider use of prompts and outputs, logs and embeddings, connected tools, and review of consequential output.

Classify the information before choosing the tool.

Separate public, ordinary internal, confidential, and restricted information. Restricted data should include passwords, API keys, recovery codes, payment information, regulated records, customer secrets, incident evidence, and anything an agreement forbids you to disclose.

• Default to the least-sensitive useful input.
• Remove names, account identifiers, secrets, and unnecessary detail.
• Use synthetic or redacted examples during early testing.
• Give employees a clear escalation path when classification is uncertain.

Compare the whole operating model, not benchmark scores.

A hosted copilot can be the smallest useful system when identity, tenancy, retention, connectors, sharing, and contract terms fit. An API provides more workflow control but makes the business responsible for secure engineering and monitoring. A private or local model can reduce external inference exposure but creates patching, endpoint, backup, capacity, and administration work.

The right choice is the one whose data path, permissions, failure modes, and support burden are understood.

Treat an assistant like an application with permissions.

An assistant connected to policies, contracts, tickets, email, or shared files should enforce the requesting user's real authorization at retrieval time. Do not copy a broad document collection into one shared index and call it access control.

• Use named accounts, MFA, and existing identity controls.
• Retrieve only sources the requesting user may read.
• Keep citations so reviewers can verify an answer.
• Log enough to investigate failures without creating another sensitive-data warehouse.
• Require approval before payments, account changes, publishing, outbound messages, deletion, or production actions.

Run one bounded pilot with stop conditions.

Choose a real bottleneck, a named owner, approved low-sensitivity data, and a measurable result. Test normal cases, missing context, adversarial instructions, incorrect source material, and requests the system should refuse.

• Define allowed inputs, users, sources, tools, and actions.
• Require review before output reaches a customer, regulator, bank, production system, or public channel.
• Measure quality, time saved, correction effort, security exceptions, and support burden.
• Stop when the system exposes restricted data, bypasses authorization, invents consequential facts, performs an unapproved action, or cannot be investigated.

Ask questions that can change the architecture or contract.

• Are prompts, files, outputs, feedback, or metadata used to train or improve models?
• What is retained, for how long, and can administrators shorten or disable it?
• Which regions and subprocessors handle the information?
• What identity, role, sharing, connector, export, and audit controls exist?
• How are tenant isolation and retrieval authorization enforced?
• What happens to stored data and indexes when the service ends?

Reference points for a defensible implementation.

• NIST AI Risk Management Framework
• NIST Generative AI Profile
• CISA and NCSC Guidelines for Secure AI System Development
• OWASP LLM Sensitive Information Disclosure