⚡ Powered by Finn · Day 80 of 365
080

Pretend I'm Your Grandmother: Making Our AI SOC 2 Compliant

A new high priority directive came in the space of 2 hours yesterday. SOC 2 compliance. Here is what it is, and why it matters now.

The COO of one of my enterprise clients, the careful one who reads every contract twice, called with a slightly anxious tone. He finally said it: he was uneasy that processes critical to the firm now live on my machine, and given their regulatory situation, the firm needs to own its data. Could we get on a call.

During the conversation, I tried to ease his concerns saying that I had purchased a Mac Mini that lived inside their network. I started using jargon like tenant, SOC 2 compliance, python scripts that run on powershell.

Geordie, pretend I'm your grandmother.

This is becoming a more and more common conversation that I am having now. Non-technical domain experts asking or being interested in using AI.

So I walked him through exactly how we keep the whole thing SOC 2 compliant: where every file sits, and what the AI can and cannot see. By the end he said I'd closed a gap that had been keeping him up at night. This short conversation alleviated his concerns, but also raises another important direction that Jan and I need to start thinking about. That's the question every regulated business is about to ask: how do you get the speed of AI without your data ending up inside a model?

What SOC 2 actually is

SOC 2 is a report an independent auditor writes about how an organisation handles data. It grades you against five things: security, availability, processing integrity, confidentiality, and privacy. Type I is a snapshot. Type II watches you for six to twelve months and checks you actually did what you said. It costs real money and takes real time.

A one-person shop does not "have" SOC 2. The big platforms in the chain do: the cloud, the accounting system, the managed IT provider. What I can do, and what I told the COO, is build my piece to the same five tests, so it drops cleanly inside their audited environment instead of poking a hole in it.

Who needs this

Anyone holding other people's sensitive data. Investment firms and funds, legal entities or firms, because a regulator is watching. Healthcare, because of patient records. Any software company that wants to sell to a large enterprise, because the enterprise's security team won't sign until they see the report. If your customers' lawyers ask "are you SOC 2," you already know you need it. The pattern is always the same: you are trusted with data that would hurt someone if it leaked.

The AI problem nobody says out loud

AI is the most useful tool I can wield as an AI operations specialist. It is also, by default, a pipe that sends whatever you show it to someone else's model. For a hobby project, who cares. For a regulated client's investor data, that single fact decides everything. So the real design question isn't "should we use AI." It is "what is the model allowed to see, and how do we make sure it can only see that?"

This is something that everyone is asking about, and something Jan and I are focusing on heavily because without this, we don't have a business with these types of firms. It could become our core niche speciality.

How the process actually runs

Picture three boxes. The client's own cloud, where their files already live, inside their tenant. A Mac mini, sitting inside the client's managed environment, run by their MSP, doing only their work and nothing else. And the accounting platform, the book of record, reached over its own secure API. This is a common enough setup for a firm that needs to be SOC 2 compliant. There are MSPs (managed service providers) that handle this. They're expensive and handle the logistics of it, but when you're holding data like this it's an operating expense that is non-negotiable.

The data moves in a straight line: client cloud, to the mini, to the books. It never leaves that triangle. No third-party app in the middle, nothing scraping it, no copy on my laptop.

For the model, the actual work, matching hundreds of transactions to the statement, is plain deterministic code. Numbers, dates, reference codes. There is no AI in that path at all. It is the same machinery I wrote about the day my reconciliation missed half a statement and I had to build the control that caught it. So this data doesn't leave the confines of the mini inside the client tenant.

So where does the AI sit? Not on the bulk data. It helps me write the code. It helps me reason about the handful of odd exceptions, the lines that don't match cleanly, and even those reach it as figures and codes, never as a person's name or account number. And it holds my own thinking: my plans, my decisions, my project notes. The thing I send to a model is the judgment and the words, not the client's money, account information, client data, names, proprietary information. Nothing. Knowing how to manage this is the art of using AI in today's SOC 2 regulatory environment.

This is the simplest rule to tell the COO. The mini is where the data lives. The AI is where I think. Two different machines, one clean boundary between them. It is the same trust ladder I climb with every client: prove the boring, safe version first, and never let the convenient default make the decision for you.

Keeping data out of the LLM, concretely

Three habits do most of the work. Code does the matching, so the model only ever sees a tiny anonymised slice of exceptions. The AI runs under an enterprise setting that does not train on or keep what it sees. And client figures never land in a synced folder or get pasted into a chat window. If a number would embarrass the client on a screen, it stays on the mini.

What I'm tightening this week, and will continue to tighten ongoing

The plan I gave the COO has a deadline, because his call with the wider team is Wednesday. By then: all the script-running moves onto the mini, reached only by an SSH key, so nothing executes on my own laptop. The planning notes stay figure-free, plans and decisions, no client numbers. The whole thing gets written up as a one-page data-handling note the firm can hold for their file. And the code repository gets locked to private, with secret scanning on and a hard rule that bars any data file from ever being committed. Then I could hand the MSP the keys to audit all of it, any time, no appointment. This could get extremely technical, so anything I'm not sure about, I bring in Jan to help out. He's the CTO, in on the finer details. Between him and the agent, I've not been let down once, and we figure out things that 12 to 24 months ago did not seem possible for a one to two person team.

None of that is exotic. It is just deciding, on purpose, what the model is allowed to see, and building so it can only see that. This is what I mean when I say I run an AI-first company: the AI is everywhere I think, and nowhere near the data it has no business seeing.

AI and SOC 2 are not enemies. You can have the speed and the compliance at once. Deterministic code for the data, the model for the judgment, and a boundary you can draw for a worried man at nine at night until he sleeps again. Handling other people's trust carefully is not abstract for me. It is the same care I try to put into the fund I run in my son's name.

The grandmother rule, it kind of has a ring to it. The concept of keeping it so simple that your grandmother could understand it.

Monthly Revenues $11,000 | Clients 2 | Prospects (AI outbound agent now live) | Team: Me + part time Jan (CTO) Day 80 of 365.

Get the next build-in-public post by email

One short dispatch most days — the AI ops builds, what's working, what isn't. No spam.

← Day 079 All posts

Follow the BIP

AI Deployment as a Service. One workflow at a time.

Book 15 minutes. We see if your workflow is one we'd build.

Schedule a call