There's a version of AI consulting that works like this: show up, install something impressive, invoice, disappear. The build works, mostly. Then six months later somebody asks a question nobody in the room can answer: wait, where does that customer data actually go?
I've built my practice around never being the guy in that story. So before I ship anything, on my own business or anyone else's, the build has to pass three questions. They're not paperwork. They're the difference between automation you trust and automation you babysit.
Question 1: What breaks, and what leaks, if this goes wrong?
Every build fails eventually. A password expires, a platform changes something, a network hiccups at 2am. The security question isn't "will it fail," it's what's the blast radius when it does.
Concretely, that means:
- If this thing breaks, does it fail loud or fail silent? Silent failure is how a contact form stays dead for three weeks. Everything I build fails loud: when it can't do its job, somebody hears about it.
- What can it touch? A tool that reads your calendar shouldn't be able to delete it. Every build gets the minimum access that does the job, nothing extra.
- Where do the passwords and keys live? Never inside the code, never in a shared doc. There are proper vaults for secrets, and using them is non-negotiable.
Ask your last vendor these three. The pause tells you plenty.
Question 2: Does it do what you tell your customers it does?
This one sounds soft until you watch it bite somebody.
If a customer thinks they're chatting with your staff and it's a bot, that's a lie you're telling at scale, and when it surfaces (it surfaces), the trust you spent years building takes the hit. If your automation sends "just checking in!" emails engineered to look hand-typed, same problem. Around here especially, where business runs on people knowing you, getting caught faking the personal touch costs more than the automation ever saved.
The ethics question is short: would you be comfortable explaining exactly how this works to the customer on the other end of it? If the answer needs lawyering, the build is wrong. Automation done right, the kind that takes the busywork and leaves the relationship, passes this easily.
Question 3: What data does it keep, and when does that data die?
Every automation touches data. Names, emails, order history, sometimes more. Two questions I answer before any build ships:
- What does it actually need? Not "grab everything, might be useful." The minimum that does the job. Data you never collected can't leak.
- When does it get deleted? Data kept forever is a liability compounding quietly. Retention gets decided at design time: this gets kept 90 days, this gets kept never, and here's the off switch.
And one more that most builders skip entirely: what happens when we shut this thing down someday? A clean decommission plan, what gets deleted, what gets handed back, is part of the build, not an afterthought.
Why this protects you, not me
Notice something about all three questions: they're not for my benefit. The build happens on YOUR operation, with YOUR customers, under YOUR name. When a sloppy build leaks data or embarrasses a customer, the consultant is gone and the business owner is holding it.
That's exactly why this can't be an afterthought. Compliance thinking asks "what's required of me?" Protection thinking asks "what could hurt this business, and how do I design it out now?" The second one is the job.
The takeaway
Anyone can make software do a trick in a demo. The bar is whether it's safe to trust, unattended, on a real business, with real customers, for years.
So whoever you bring in, and whatever they're building, put my three questions to them: What breaks and what leaks? Does it do what we tell customers it does? What data does it keep and when does that data die?
Good builders have answers before you finish asking. That's how you tell them apart.
Four pillars make AI useful. Three cornerstones make it safe to trust. More on both another day.