Not a client’s information though, I want to be clear about that, because the difference matters and I would never risk my clients’ information this way.

We were testing an updated reconciliation system we use on our own books. It was deliberate work, on my own account documents, in my own environment. The kind of use I’d tell anybody is completely fine. I had every intention of stripping the real numbers out first.

I just didn’t do it. I ran the test, and everything went up with it. I was in a hurry and excited to see our new system in action. I figured, one test, no biggie.

Then, I sat with that for a minute. I started thinking, why, why did I do that? I tell business owners to strip out account numbers and anything that identifies a person or business before it goes anywhere near a tool. I’ve told them the question was never whether their data goes into AI, because it does. The question is whose AI it goes into, and whether the person doing it made that decision or was just being unaware.

That’s the part I want to talk about, because it explains something the careful version of this conversation never gets to.

When people picture someone leaking company data into AI, they picture carelessness. Somebody who doesn’t take it seriously. Somebody who has no idea what the risk even is. Somebody who needs a policy.

That’s almost never what it is.

It’s somebody who meant to be careful and had one step of it living in their own head. It’s the person who was going to strip the client name out and got interrupted. It’s the person who used the free tool on their phone because getting to the approved one meant a login they couldn’t remember at nine at night. The intention was there, but intention isn’t enough unless it leads to action.

**Intending to be careful isn’t a safeguard. It’s a hope with good manners.**

Which is why the fix I landed on wasn’t a rule.

I could have written myself a note. Redact before testing. I’d have followed it most of the time, and most of the time is exactly the failure mode I’m describing.

So I decided to build a private LLM server in-house instead. Not for everything. Just for financial data and private personal information, which is the small category where I actually care.

The thing that makes it work isn’t the model. It’s that it won’t have internet access. It’ll live on our own network, on an encrypted server, with no route out.

The idea is that the data can’t go anywhere, because there’s nowhere for it to go. Nobody has to remember or think about it. Nobody has to be having a good day or read the rule book again. The risky version of the action stops being available, which is the only kind of safeguard that survives a busy afternoon.

I should say plainly that I’ve decided to build this and haven’t built it yet. When it’s up and running I’ll write about what it actually took, including the parts that were more annoying than I expected and the parts that went well.

A server is one way to handle this, but it’s not the only way, and it’s not the point. The point is moving the safeguard out of somebody’s memory and into the environment.

**Five things you can do this week instead**

1. **Name the one category of data that must never leave.** Just one. Financials, client contracts, health information, whatever it is for you. A list of nine gets ignored.

2. **Ask your team what AI tools they’ve used and what they put into them.** It’s true that most owners have never asked it once or even thought about it for that matter.

3. **Make the safe path the easier route.** If the approved tool takes three extra steps, people will keep using the one already open. Make it easy to follow the rules and follow up on compliance.

4. **Put redaction in the tool, not in your head.** A saved template with the fields already blanked beats remembering every time. Spreadsheets can have identifying data easily stripped away with a small script. PDFs need a real redaction tool, because just using a blocking box usually leaves the text sitting underneath, and it can still be found that way.

5. **Decide now what happens when somebody gets it wrong.** Because you know they will, and the only thing worse than the mistake is a culture where nobody mentions it. Make everyone aware of your wishes and guidelines.

I did it wrong on my own data, that’s on me, but changing the setup instead of writing myself a rule is the whole story.

What happens is quieter, and it is why it goes on so long.

A while ago we were brought into a Drupal site that looked completely fine from the outside. Loaded properly, looked professional, nothing visibly wrong.

The forms were not working. Emails were not going out.

Sit with that for a second, because it is worse than a site being down. A site that is down tells you. Everybody knows within the hour and somebody fixes it. A form that quietly fails tells nobody. People filled it in, hit send, saw a thank you message, and went about their day thinking they had reached someone.

Nobody on the business side had any way to know. There is no alert for the message that never arrived.

There was more. Functionality already built into the site was not doing what it was supposed to do. Other things the business genuinely needed built could not get built, because the work had outgrown the setup they had. So the list of things that did not quite work got longer, and everyone learned to route around it.

That is the pattern, and I see it constantly. **No single bad decision. A hundred small workarounds nobody wrote down.**

When we got into the code we found the rest of it. There was broken code, messy code, and patched patches. Problems layered on top of older problems, in the way that happens when every fix has to avoid the last one.

The client was frustrated and genuinely did not know what to do next. That is the honest emotional middle of this story and I think it is the most common place for a business owner to be. They weren’t indifferent, they were stuck. Aware something was wrong, unable to describe it precisely enough to ask for the right help, and braced for someone to say the whole thing had to be rebuilt.

It did not have to be rebuilt.

We refactored the code that was causing the trouble. We built the functionality they had been waiting on. We fixed the long tail of things that were not working properly.

It was the same site and same platform, and their content and their history all stayed exactly where they were.

What changed is that it worked. The forms went through. The emails arrived. The functionality they had been unable to get built existed. The workarounds went away, and so did the complaints, which in a story like this one means more than it sounds like, because the silence before was the problem.

The client was thrilled. Sales went up and their customers were happier with the experience.

Here is the thing I most want you to take from this story.

Their site was costing them money for months and it did not look like anything was wrong. That is the whole danger. A slow site is annoying and a hacked site is a crisis, but both of those announce themselves. A form that silently drops leads doesn’t. Neither does functionality that just annoys people, quietly, with nothing reporting it. Problems like those keep going for as long as nobody tests them.

So while you are here, go and do these five things. They take about fifteen minutes.

1. **Fill in your own contact form.** All the way through, like a stranger would. Then confirm the message actually arrived somewhere a human reads.

2. **Do the same for every other form**, quote requests, newsletter signups, applications, event registrations. **Forms fail one at a time, not all together.**

3. **Ask whoever maintains your site when the last security update was applied**, and if anything broke when it was. If nobody knows, that is your answer.

4. **Write down every workaround your team uses.** Note the “oh you have to do it this way” instructions. Each one is a broken thing no one is fixing.

5. **Ask what your team has wanted to build and could not.** The reason is usually the real diagnosis.

If that list turns up nothing, genuinely good. You are in better shape than most.

If it turns up something, you have not found a disaster. You have found the thing that was quietly true anyway, and now you can decide what to do about it.

That is a much better position than not knowing.

The businesses that get stuck aren’t lazy and they’re not behind on tools. They’re carrying too much that only exists in one person’s head, sitting on top of systems that were never built for anyone else to understand.

I’ve spent twenty-one years building and untangling the systems businesses run on. Before that it was servers, networks, and databases, so I’ve seen this from a few angles. Lately a lot of that work is AI. Which is where this gets interesting. AI is the first tool that genuinely cannot help you until what’s in your head is gathered somewhere it can reach. Once it is, and you point AI at it with the right directions and guardrails, the thing that only existed in one person’s head becomes something your whole business can benefit from.

That’s what this newsletter is about. Signal is the part that actually matters. Structure is what makes it usable by someone other than you, including, now, by AI.

Here’s what to expect. Short pieces, most of them under five minutes. Plain language, because most of the jargon in my industry exists to make simple things sound expensive. And occasionally, something you can actually go do at the end, not just something to think about.

I’ll write about websites, because that’s where the scar tissue came from. I’ll write about AI honestly, including the parts that are overhyped and the parts that genuinely changed how my own company works. And I’ll write about the unglamorous structural things that decide whether either one is of any help to you at all.

If you’re sitting on a website that’s holding you back, or trying to work out where AI actually fits in your business, that’s what I’m here for.