I recently sat down with Dan at NetAccess Systems, one of our partners, for an episode of their NAS Cafe series. Two people, two cups of coffee, and about half an hour of talking tech. NetAccess has been working in the business technology stack since 1993, so the questions I got were the ones businesses actually ask when they start thinking seriously about AI.

NAS Cafe, recorded at NetAccess Systems in Hamilton, Ontario. 27 minutes.

If you would rather read than watch, the rest of this post covers the same ground. The timestamps below jump to each part of the conversation.

“We have to implement AI” is the wrong starting point

Dan opened with the question I get most often: how do you decide which processes suit AI? My answer hasn’t changed. Most of the businesses I walk into open with some version of we’ve heard about AI, we feel like we’re being left behind, we have to implement AI, and that is the wrong end of the problem.

You want to start from your business processes, particularly the ones where you’re struggling with speed of response, with efficiency, or with finding the right people for the right jobs. Start from the process, then work out where AI can help. It isn’t right for every process, and pretending otherwise is how you end up swinging an AI hammer at everything.

Two places AI is the wrong tool

The first is anything rules-based and deterministic. A financial report is the example I always reach for. You could build a rules-based system for it, and you should, because the path from inputs to outputs is clear and there are usually regulatory consequences attached to the number at the end. AI puts a slightly fuzzy step in the middle of that path, and being unable to explain how you arrived at a number is a problem. Traditional systems do that job well. AI brings risk, complexity and cost with it, so you want to aim it at the places where it earns them back.

The second is when the process or the data underneath it is broken. AI doesn’t fix broken processes and it doesn’t fix bad data. It just runs the broken process faster. When that’s the situation we back up and look at re-engineering the process and cleaning up the data first, which is ordinary business process work and one of the structural reasons AI initiatives fail.

Dan made the point well. You’d never walk into a company and start changing processes willy-nilly, because there’s a rigor to it, and it’s the same with AI.

Where it does work

AI earns its place where things are genuinely fuzzy. We spent the most time on customer prospecting, partly because NetAccess has been doing it themselves. They built a workflow that reads a prospect’s website and then goes further and reads the social feeds, because they didn’t only want to hear what the marketing team was saying. From that, the AI builds a sales approach card: what would make sense for this company, and the top questions worth asking.

The part I liked best is what they deliberately didn’t automate. The AI never sends the email, because a person looks at it first. That’s the same shape as the prospecting pipeline I built and wrote about earlier this year.

It’s also the clearest answer I have to the worry that AI is replacing salespeople. Salespeople don’t enjoy working through website after website after website. They enjoy talking to people who might become customers. The AI does the part they don’t want, and it’s a part that’s close to impossible to build with traditional rules-based systems.

Where decisions carry safety or regulatory consequences you need a human in the loop, and that’s still true today even as agents become more autonomous.

Guardrails, and a test I recommend to everyone

When people tell me they’re using AI, the thing they usually haven’t thought about is governance: audit trails that let you trace what actually happened, and guardrails that constrain what the system can say. This matters because AI will confidently give you an incorrect answer and sound completely definitive doing it.

There’s a test for this that anyone can run. Ask ChatGPT to draft a legal document, something for selling your house, say. It’ll produce something that looks excellent. Take that document to a different model, Claude for instance, and ask it to critique the draft adversarially. It will tear it to shreds and list everything wrong with it. Take that critique back to the first model and ask what it thinks, and it’ll agree and add a few more problems of its own.

These systems aren’t infallible, and the failure mode is over-reliance. If the output is going to face a customer or an employee, say an expert system answering questions for your staff, it has to give the right answer and you need a way to validate that it did. That’s the side of chatbots leaders tend not to hear about.

The data question most companies haven’t asked

Dan asked what’s really happening when someone pastes a spreadsheet into ChatGPT, and in my experience most companies don’t know.

The number one rule of AI today is this: if your company is not using it formally, your employees are using it informally. I will guarantee it. And they’re doing it without regard to the privacy implications.

When you use the big public models your information goes out and is stored. It can be reached by government, and the US CLOUD Act in particular gives them the right to retrieve data from any provider anywhere in the world. It may be used for training, which means confidential company information gets built into the model and can resurface somewhere else. Depending on what you sent, you may be in contravention of PIPEDA in Canada, or HIPAA and other health legislation in the US. There are a lot of minefields here.

So depending on the use case, you need to be asking how you’d use a private model. And if you can’t use a private model, you very likely can’t use any model for that particular application.

Private models, and why frontier is rarely the answer

Dan asked whether you give up performance by going private, and the answer is less and less. Models come in a range of sizes. At the top are the frontier models. Fable 5.1 is the big one as I write this, and in two weeks that’ll be old news. They’re very large, very capable and very expensive. At the bottom are models small enough to run on your laptop, which are neither fast nor capable enough to be worth much.

The middle is where it gets interesting, and it keeps getting better. There’s a growing set of models roughly as capable as the frontier models were a few months ago, and they can run on a private cloud with complete isolation, no data reuse, and a known baseline cost that doesn’t spike as you scale.

In the systems I build I almost never need a frontier model. The ones in the middle really do the job without the privacy and cost consequences that come with going to the top. Getting there takes work, though. I test extensively to spec out the right model for each task, and a single process might use three or four different models depending on what I’m asking of it.

Cost predictability

Cost predictability with public models is extremely difficult. I have customers who took a project from a pilot where everything worked well, scaled it up, and got hammered with an unexpected bill in the thousands. That gap between pilot economics and production economics is one of the three gaps that catches people, and it’s why I keep writing about the costs you see and the ones you don’t.

Dan had a good story from the other side of it. When NetAccess deployed their first internal private AI, he had everyone in the company query it at exactly the same time and watched what happened to video memory, CPU and disk. They could crash it. Then you learn what capacity a given query volume needs, you add some throttling and resource management, and you end up with a capable private system that isn’t leaking data to a third party.

Two places to start

You wouldn’t rebuild your entire business around any other new technology, and AI is no different. Introduce it where you can deploy quickly, relatively inexpensively, and get a real return, without risking customer data, employee data, financial data, or a process you depend on. Keep those locked away until you’ve built a comfort level and some discipline around how you govern AI.

Your phone system is a good first candidate. Done poorly, AI phone bots are terrible. Done well they’re a great place to start and you see returns quickly. Simple call routing is the easy version. The more interesting version integrates with your document management. Take a property management company: a tenant calls to say the air conditioning is out, and the system has to work out who’s calling, what their lease says, which repair facility covers them and what the response time is. It can answer the tenant and lodge a ticket with the contractor for that building in the background. A different tenant gets a different answer. That’s why the voice is the easy part, and I always want the caller offered the choice of a person instead.

The second is a document assistant. The technical term is a RAG system, which I hate as a name, but the idea is simple. You pull your company’s documents in and give people a chatbot that answers only from those documents. That’s exactly what Docora does, and building it taught me a great deal about doing it properly.

A good rule of thumb: if there’s a person in your company everyone goes to for answers on something, that’s where this kind of system fits. HR policy is one. Safety documents and work instructions are another, along with onboarding and training material for new employees. It’s consistent, it’s fast, it’s available 24/7, and it’s reasonably quick to stand up.

Why a confidently wrong answer is the real risk

Dan asked why a false answer matters so much. The best illustration I have is a nursing home where I deployed one of these systems. Their policy manual is about 600 individual documents. It’s a highly regulated environment, there’s legislation layered on top, and some of the documents contain grey areas or contradict each other. Nobody remembers all of it.

The situation that came up was in the middle of the night. No supervisor on site, off-shift staff, and a resident fell and hit their head. The staff knew what to do medically. What they needed was everything else: the immediate steps, the paperwork legislation requires when a resident is injured, and the window inside which family must be contacted.

In a high-pressure moment a less experienced person on a night shift isn’t going to recall all of that. The system pulled the policies and the legislation together into one coherent answer. And that’s why a wrong answer would be critical, because if it says the paperwork isn’t needed, or simply neglects to mention it, that’s a regulatory contravention. It’s the same class of problem I described in the use cases I can speak to from my own work.

Change management is the part people skip

My background before this was 30-plus years at a steel company here in Hamilton, ending up as a vice president with IT and HR both reporting to me. It’s an odd combination, but it turned out to be a useful one. IT is all about change, and you can’t manage the change without managing the people going through it.

That’s doubly true with AI, because there’s real trepidation among employees who’ve been told it’s coming for their jobs. I don’t believe that’s what’s happening. It’s here to augment people, to take away the drudgery and let them apply their skills to the work that actually needs them. But companies that skip the training and the overlap period, that don’t give people time to adopt, see it show up as frustration. The things you assume are obvious usually aren’t.

My thanks to Dan and the team at NetAccess for the conversation and the coffee. They’re taking a deliberate, conservative approach to building private AI infrastructure for their customers, and I think that’s the right way to go about it.