You keep client data safe with AI by deciding which categories of data may go into which approved tools and settings, checking each vendor’s data handling before approving it, giving agents only the access they need, and teaching people simple habits for what to share and how to check output.
Avoiding AI altogether can feel safer, but it often just pushes usage onto personal accounts nobody can see. Clear rules usually reduce risk more than a ban does.
Who this is for
General counsel, COOs, CTOs and compliance leads at firms that handle confidential client, deal, investor or project information.
The short version
- Classify your data into a few simple tiers and map each tier to approved tools.
- Approve tools based on their actual terms and settings, and recheck them periodically.
- Treat agents differently from chat: limit their permissions and require approval for consequential actions.
This page is practical guidance, not legal advice. Your obligations depend on your contracts, jurisdiction and regulators, so involve counsel in the final rules.
Step 1: Classify your data in plain terms
Many firms can work with four simple tiers:
| Tier | Examples | Typical rule |
|---|---|---|
| Public | Published material, public filings, marketing copy | Any approved tool |
| Internal | Internal processes, non-sensitive drafts, general notes | Approved business accounts only |
| Confidential | Client documents, deal materials, financials, personal data | Specific approved tools with appropriate contractual and admin protections |
| Restricted | Material under strict NDA terms, regulated data, anything a contract prohibits sharing | Only where explicitly cleared, or not at all |
Keep the definitions short enough that someone can apply them in a few seconds. A rule people can’t remember tends to be ignored.
Step 2: Approve tools against clear questions
Before approving an AI tool for confidential work, find written answers to these. Vendor terms and features change, so check the current versions rather than relying on memory or old articles.
- Is our data used to train the vendor’s models, and can that be switched off at the account level?
- How long are prompts, files and outputs retained, and can we control that?
- Who at the vendor can access our data, and under what circumstances?
- Where is data processed and stored?
- Which subprocessors are involved?
- Do we get single sign-on, admin controls and the ability to remove users quickly?
- Are audit logs available to us?
- What security certifications or independent assessments does the vendor hold?
- What does the contract say about confidentiality and breach notification?
Then publish a short list of approved tools and the tiers each one is approved for.
Step 3: Close the side doors
- Personal accounts. Make it easy to use the approved business account, so people don’t reach for a personal one.
- Browser extensions and plug-ins. Some can read page content or documents. Decide which are allowed.
- Meeting recorders and transcription. Agree when they may be used and how participants are told.
- AI features inside existing software. These may have different terms from the main product. Check them too.
Step 4: Put guardrails around agents and integrations
Agents and connectors carry different risks from chat because they can read from and act on your systems.
- Least privilege. Give each agent access only to the folders, records and actions its job needs.
- Human approval. Require a person to approve sending external messages, deleting data, moving money or changing key records.
- Untrusted input. Emails, web pages and documents can contain instructions designed to manipulate an AI system. Design so that content an agent reads cannot, on its own, trigger sensitive actions.
- Separate credentials. Use dedicated service accounts rather than an individual’s login, so access can be reviewed and revoked.
- Logging and review. Keep a record of what the agent accessed and did.
Step 5: Teach the habits
Rules only work if people can apply them under deadline pressure. Training should cover:
- which tier a document falls into, with real examples from your firm
- removing names and identifying details when the task doesn’t need them
- checking AI output against the source before relying on it
- who to ask when unsure, with a fast answer promised
A one-page policy outline
Your usage guide can be short:
- Why we use AI and what we expect from it.
- Approved tools and the data tiers each may handle.
- What is never allowed.
- How to check output and who is accountable for it.
- How agents and integrations are approved.
- Who to ask, and how to report a mistake without blame.
Common mistakes
- A blanket ban. It tends to drive usage underground rather than stop it.
- A long policy nobody reads. One clear page is more likely to be followed.
- Approving once and never rechecking. Terms, features and settings change.
- Treating agents like chat. Access to systems needs stronger controls.
- Punishing honest mistakes. People stop reporting them, and you lose visibility.
When you do not need us
If your firm already has a strong information security function and counsel experienced in technology contracts, they can likely run this process without us, using the outline above. Our help is most useful when those skills are stretched, or when you’re building agents and want the engineering done carefully.
How Ruby helps
- AI strategy: a practical, plain-language usage policy and approved-tools list that fits how your firm works.
- AI engineering: agents and integrations built with least-privilege access, approval steps and logging.
- AI training: teaching your team the data habits with examples from their own work.
A good starting point is one practical hour of AI training that includes your data rules.