INBOX INSIGHTS: Local AI Migration Part 2, Practical Responsible AI Part 1 (2026-09-09)

INBOX INSIGHTS: Local AI Migration Part 2, Practical Responsible AI Part 1 (2026-09-09) :: View in browser

👉 Take our new course, AI for Writers and learn how to make AI write better!

Watch this video on YouTube

Local AI Migration: Part 2

What does a week of planning actually change?

Last week I showed you the process of getting started on my journey to local AI. In a short time, I’ve learned a lot, all before drafting the project requirements document.

After I published that issue of the newsletter, I started drafting the PRD. Seven things changed from where they started, and they are the part of the PRD that I am the most eager to share with you. I’m listing all seven because the corrections are the entire argument for doing requirements work, and because every one of them happened on paper, where being wrong is free.

What changed

1) I was wrong about the premise, and it took three days to find out. I started certain that running AI on my own machine would lower my carbon footprint. It probably wouldn’t. Data centers run many queries at once on shared hardware. My laptop would run one at a time, by itself, which is less efficient per unit of work, not more. Researchers at Universidad Carlos III de Madrid measured the same query both ways: 0.354 watt-hours batched, 21.67 watt-hours alone. Sixty times worse for identical work. I hadn’t bought anything yet, which is the only reason this is a finding and not an expensive mistake.

2) There was a third option I couldn’t see while I was looking at binary choices: cloud or local. What came out of the questions is cloud, local, or no model at all. This third option is actually the biggest opportunity. We were on a call last week with a client that thought they needed an agentic process, and the solution was a VBA script through Excel. Some of what I’ve been asking a language model to do is better suited for a small script. That script would do faster, more reliable work and not need generative AI at all. I couldn’t see this at first because I was busy choosing between two things.

3) Buy nothing. I expected to spend money on this. I was mentally shopping for a new laptop and dreading the migration process. Four separate constraints turned out to point at the same answer, which is the 2021 MacBook Pro already on my desk. It’s already made, so its manufacturing carbon is already spent. It sleeps when I close it, so it isn’t drawing power all night to keep a model warm. It travels with me. And it fits everything I’d actually want to run locally. The correct hardware decision for this project was to make none, and I’d have gotten that wrong on my own. See? This is what happens when you lead with Platform. In the 5P Framework by Trust Insights™ (Purpose, People, Process, Platform, Performance), Platform comes fourth for exactly this reason. You make expensive and incorrect decisions.

4) I wrote a test that nothing could pass, including what I use today. The LLM asked what “as good” means. I said local output had to be ninety to one hundred percent identical to what I get now. That sounds rigorous. It’s nonsense, because two runs of the same cloud model on the same prompt aren’t identical to each other either. I’d have failed a perfectly good local setup for not matching a standard that isn’t met today. When I was preparing for a course on Claude Artifacts, I did the test run of materials to have “pre-baked” for the demo, while the demo ran in the background. When the live demo finished, the output was different from the pre-baked version, despite being the same information, same prompt. I knew this and chose to ignore it.

The better test is simpler. Run the current tool twice on the same prompt and see how much the two answers differ from each other. That gap is your standard, and local only has to land inside it. That’s a control group, and you only find it by writing the bad version down and looking at it. (Catching yourself setting a standard that sounds strict and is actually incoherent is not a pleasant twenty minutes. I recommend doing it anyway.)

5) Owning a file and being able to read it are two different things. All my project notes live on my own hard drive. That sounded like independence right up until I tried to open one. They’re Markdown, which on my Mac opens in MindNode by default and looks like nonsense, and they’re written in shorthand aimed at a machine rather than at me. I have possession without access, which is not the same as owning anything.

The rule I wrote down: any system that stores knowledge you can’t read without that system is a dependency, not an asset. That applies to a local setup exactly as hard as it applies to a cloud one. Without that correction, I’d have happily rebuilt the identical trap on my own hardware and called it freedom. For what it’s worth, I can open a Markdown file, but the default program is incorrect, and it’s something that I need to resolve outside of an LLM.

6) I made an argument, then took it back. I went looking at what obligations we actually have around client data, and found what looked like a strong reason to process things locally. Then I read the document that governs the work, rather than the one I’d been handed first, and the argument fell apart. Out it came.

That’s a couple of hours that produced nothing except accuracy. It doesn’t feel like progress at the time. It’s the most valuable thing you can do in a planning phase, because the alternative is publishing the argument and finding out afterward.

7) Carbon stopped being the best reason to do this. This is the one I keep coming back to.

I asked myself which single thing I’d most hate to lose, and the answer wasn’t speed or output quality. It’s the ability to pull from a dozen sources into one place and remember what we decided six weeks ago. That’s the functionality I use the most. The real challenge is that I rent the memory from a company that can reprice it, redesign it, or retire it without asking me. That is a real risk.

I already got a small preview. In early August, I turned off one of my own automations because I had used eighty-seven percent of my weekly budget. This seemed like a sensible, low-risk move at the time. Three weeks later, I was manually chasing people for status updates while forgetting that I had turned off the task. I was the problem, not the team. That’s a capability regression I caused, didn’t notice, and only found because a question made me go looking.

The environmental reason is still real. But the reason that is even more real is that I’m dependent on something I don’t own, and that’s a better reason than the one I started with.

What do all seven changes have in common? None of the changes came from executing a plan. Every change came from being asked a question I couldn’t answer right away and had to dig deep to answer. The questions that produced the biggest changes were the least technical ones. What would make you stop? What would you miss most? What would you give up first? Those aren’t research questions. They’re decisions only I can make, and until I made them, no amount of investigation was going to help. (I spent two days on the ranking question. Two days, just to change the direction after I answered more questions and came back to it.)

The version that costs real money

I am one person, on one laptop, conducting one personal project. In one week, there were seven corrections that changed the direction and outcomes of the project.

Now run that same week against an enterprise platform decision. Nothing changes except the stakes. The premise that fails is a six-figure commitment. The option nobody could see was the one that didn’t need the platform at all. The test that nothing can pass is written into an acceptance clause. Those same corrections are still sitting there. They just get found after the contract is signed instead of before it, and at that point they aren’t corrections. They’re overruns that you can’t walk back from.

That’s what requirements work is for, and it’s the same exercise at any budget. The questions don’t change. Only the cost of skipping them does.

What’s next?

If you’re about to start something, the useful exercise isn’t researching your options (yet). It’s writing down what you believe about the thing, specifically enough that the belief could turn out to be wrong, and then checking it. Mine was “local AI is greener.” It only took three days to find out that isn’t reliably true, and it cost me nothing. (Well, it cost me a plan I was rather attached to.)

In the next issue, we’ll dig into what I learned once I finally created the PRD.

How are you double-checking your project intentions?

Reply to this email or join the conversation in our Free Slack community, Analytics for Marketers!

– Katie Robbert, CEO

Weekly One Question Poll 🐶

Click or tap just one answer below — there’s no form, this is the entire thing. One tap and you’re done, with our thanks. Does your company have a separate budget line for AI in 2027?

Do you have a colleague or friend who needs this newsletter? Send them this link to help them get their own copy:

https://www.trustinsights.ai/newsletter

In this episode of In-Ear Insights, the Trust Insights podcast, Katie and Chris discuss how you will cut energy waste by shifting to local AI. You’ll discover how to structure your planning so you track tools after defining your goals. You’ll learn how to build a self-updating memory system that keeps every project organized without extra effort. You’ll walk away with a clear checklist to audit your routine and select the exact technology you need.

Watch/listen to this episode of In-Ear Insights here »

Last time on So What? The Marketing Analytics and Insights Livestream, we examined how AI wrote. Catch the episode replay here!

This week on So What? we’re digging into nontraditional podcast analytics and AI. Are you following our YouTube channel? If not, click/tap here to follow us!

Here’s some of our content from recent days that you might have missed. If you read something and enjoy it, please share it with a friend or colleague!

Take your skills to the next level with our premium courses.

Get skilled up with an assortment of our free, on-demand classes.

You could be reaching 37,000+ marketers, analysts, data scientists, and executives directly with your ad. Want to learn more? Reach out and contact us.

This week, we start part 1 of 5 about what responsible AI is in practice. Responsible AI is one of those amorphous terms that can mean whatever the speaker wants it to mean, and it has perilously few practical tactical things we can do.

In this five-part series, we aim to correct that by providing practical tactical things you can do.

We have five core practices you can use to reduce your AI impact:

Use AI for what it’s good at.
Use cloud AI as little as possible.
Use AI for the tasks you hate.
Use local AI as much as you can.
Prohibit AI for what it’s bad at.

Part 1: Use AI for What It’s Good At

Generative AI, powered by diffuser and large language models, is all about creating predictions based on existing inputs. Generative AI is a prediction machine. It’s good at predicting things. It’s good at predicting the next word in a sentence. It’s good at predicting the next surrounding pixels.

Most of our use of generative AI is with large language models. First invented in 2017 at Google’s DeepMind Research, large language models predict the next token in a sequence, typically of words. They’re really good at predicting the next word or the next character or the next line of code.

Anything that is a language task, large language models are well suited for. You would think this would be obvious, but many people treat AI like some mythical genie in a box, expecting it to be able to do everything because we interact with it using language.

What tasks are rooted in language? Extraction, classification, rewriting, summarization, synthesis, question answering… if this list sounds familiar, it’s because these are the seven core use case categories of generative AI that Trust Insights has been promoting for the last three years. When we think about using AI responsibly and using it with as small a footprint as possible, we need to focus on the things that AI is good at.

You’ll notice, for example, math is not on that list. The transformers architecture that predicts the next logical word in a sequence based on probability is profoundly unsuited to doing calculation because math is a symbolic language. Symbolic languages or formal languages do not function like spoken or written languages, and thus generative AI tools are really bad at them. However, they’re very good at writing code, which is a language task.

As you use frameworks like the TRIPS Framework by Trust Insights to evaluate what tasks you should automate or augment with AI, consider whether the task is truly at its heart a language task or not. For those tasks that are not language tasks, AI may play a supporting role, such as writing code to do the task, or it may have no role whatsoever.

The thing to avoid is using AI for things it’s not good at – it’s a waste of time, energy, effort, money, and resources.

Almost every AI course is the same, conceptually. They show you how to prompt, how to set things up – the cooking equivalents of how to use a blender or how to cook a dish. These are foundation skills, and while they’re good and important, you know what’s missing from all of them? How to run a restaurant successfully. That’s the big miss. We’re so focused on the how that we completely lose sight of the why and the what.

This is why our capstone course, the AI-Ready Strategist, is different. It’s not a collection of prompting techniques or a set of recipes; it’s about why we do things with AI. AI strategy has nothing to do with prompting or the shiny object of the day — it has everything to do with extracting value from AI and avoiding preventable disasters. This course is for everyone in a decision-making capacity because it answers the questions almost every AI hype artist ignores: Why are you even considering AI in the first place? What will you do with it? If your AI strategy is the equivalent of obsessing over blenders while your steakhouse goes out of business, this is the course to get you back on course.

👉 Take this course now to become an AI leader

Here’s a roundup of who’s hiring, based on positions shared in the Analytics for Marketers Slack group and other communities.

Are you a member of our free Slack group, Analytics for Marketers? Join 4000+ like-minded marketers who care about data and measuring their success. Membership is free – join today. Members also receive sneak peeks of upcoming data, credible third-party studies we find and like, and much more. Join today!

Where can you find Trust Insights face-to-face?

Spotlight, September 2026
LPA, September 2026
MEMA, October 2026
MAICON, October 2026
SMPS AEC.AI, November 2026
MarketingProfs B2B Forum, November 2026

Going to a conference we should know about? Reach out!

Want some private training at your company? Ask us!

First and most obvious – if you want to talk to us about something specific, especially something we can help with, hit up our contact form.

Where do you spend your time online? Chances are, we’re there too, and would enjoy sharing with you. Here’s where we are – see you there?

Read our disclosures statement for more details, but we’re also compensated by our partners if you buy something through us.

Imagine a world where your marketing strategies are supercharged by the most cutting-edge technology available – Generative AI. Generative AI has the potential to save you incredible amounts of time and money, and you have the opportunity to be at the forefront. Get up to speed on using generative AI in your business in a thoughtful way with our workshop offering, Generative AI for Marketers.

Workshops: Offer the Generative AI for Marketers half and full day workshops at your company. These hands-on sessions are packed with exercises, resources and practical tips that you can implement immediately.

👉 Click/tap here to book a workshop

Some events and partners have purchased sponsorships in this newsletter and as a result, Trust Insights receives financial compensation for promoting them. Read our full disclosures statement on our website .

Thanks for subscribing and supporting us. Let us know if you want to see something different or have any feedback for us!

Need help with your marketing AI and analytics?

Leave a Reply Cancel reply

Pin It on Pinterest

Watch This Newsletter