How I rolled out AI to a small firm without losing control of client data

The problem

Small firms tend to adopt AI the way they adopt any tool. One person signs up, then everyone does. Nobody knows which features touch client records, what leaves the country, or who approved the connector that can send email. The firm in this case was small, held client data under a provincial privacy law, and had no in-house IT.

I stated the goal plainly: everyone gets the tool, and nothing that holds client data goes anywhere it should not.

What I did

I inventoried what the platform could actually do. I sorted every feature into one of seven integration types, from instruction-only skills to remote tool servers, using the vendor’s own documentation.
I wrote a vetting process that every new skill or connector goes through before it reaches staff (below).
I gave each integration type a risk tier and a rule, so staff never have to make that judgement call alone.
I built a shared skills library for the work people repeat: proposals, finance summaries, outreach and branded decks.
I rolled it out over about two months with training sessions, then handed over written instructions (SOPs) tested end to end with browser automation. I made the handover as complete as I could: the library, the tiers and every step written down.

The vetting process

View diagram full sizeScroll sideways to see all of it

Four questions decide the tier. The approval step grows with the tier. Instruction-only skills get a read-through; anything with scripts gets a code review and a dummy-data run; anything that leaves the tenant gets a written data-flow check.

made with draw.io (diagram) + VectorCraft (export pass) last committed 2026-10-26 iterations 2 source file ↓

Risk tiers

Risk-tier matrix: pick an integration

Each integration type gets a tier from four questions. Click one to see the answers and the rule it earns.

Tier 1 Instruction-only skill: A house-style guide for proposals: text instructions, no code, no network.

Data it can reach	Only what the user pastes into the chat
Leaves the tenant?	No
Can it change things?	No: it shapes the answer only
Who can see what it does	Readable in full by anyone in the team folder
Rule	Approve once, publish to the shared folder, review yearly.

Tier 2 Skill with scripts: Builds a branded deck from a spreadsheet using a bundled script.

Data it can reach	Files the user attaches
Leaves the tenant?	No, if the script has no network calls (checked at review)
Can it change things?	Creates files; does not touch systems
Who can see what it does	Script read line by line before approval
Rule	Code review + a test run on dummy data before it enters the folder.

Tier 2 Read-only connector: Search the document library from the chat.

Data it can reach	Everything the signed-in user can open
Leaves the tenant?	Stays with the vendor under the org's data agreement
Can it change things?	No
Who can see what it does	Vendor audit log
Rule	Allowed for staff; blocked for folders holding client records.

Tier 3 Read/write connector: Draft and send email, edit calendar events.

Data it can reach	Mailbox and calendar
Leaves the tenant?	Yes, to recipients
Can it change things?	Yes: sends, edits, deletes
Who can see what it does	Vendor audit log, after the fact
Rule	Named users only, human confirmation on every send, quarterly review.

Tier 2 Local tool server: A diagram tool running on the user's own machine.

Data it can reach	Local files in an allowed folder
Leaves the tenant?	No, when sandboxed to one folder
Can it change things?	Writes inside its folder
Who can see what it does	Config reviewed; folder scope enforced
Rule	Allowed from the approved list only, pinned to a version.

Tier 3 Remote tool server: A third-party server reached over the internet.

Data it can reach	Whatever the prompt contains, plus its own scopes
Leaves the tenant?	Yes, to a third party
Can it change things?	Depends on the server
Who can see what it does	None by default
Rule	Not allowed for client data. Case-by-case for public research, with a written data-flow check.

Tier 3 Browser automation: Fill a web form, collect search results.

Data it can reach	Anything the browser session can see
Leaves the tenant?	Yes
Can it change things?	Yes
Who can see what it does	Session recording if enabled
Rule	Only on public sites, in a separate profile with no saved logins.

I kept the tiers coarse on purpose. Three levels are easy for everyone to remember, and each rule is something a non-technical manager can enforce.

Governance in one page

Question	Answer at Example XYZ
Where do skills live?	One shared team folder; nothing installed from outside it.
Who approves?	One named owner, with a second reviewer at tier 3.
What can skills do?	Instruction-only by default; scripts after review; no API keys inside skills.
What never goes in?	Client records, billing data and anything under the privacy law.
How is it checked?	Quarterly review of the folder and connector list; every seat signs the usage policy.

The skills library and the deck generator

One skill turned a spreadsheet into a branded slide deck, pivot tables included. I rebuilt the version below from scratch for the fictional brand; it runs entirely in your browser.

What it proves

RiskI sorted integrations by what they could reach before anyone used them, and gave staff a rule for each tier.

AdoptionI planned repeatable wins (decks, summaries) for week one, because early wins keep a rollout alive.

HandoverPolicies, SOPs and a tested library a successor can run without me.

In an interview, I can walk through

the full rollout timeline, and how I ran the training sessions;
how I derived the prompt framework behind the skills from public prompt-engineering methods;
the free and open-source alternatives I considered for each paid feature.