Social posts by Kevin Pledger

What I’ve posted elsewhere, in full, so you can read it here. Each post links to the original if you’d like to comment or react there.

LinkedIn Posts

Posted October 12, 2026 on LinkedIn
A successful AI pilot isn’t necessarily one that produced impressive results. It’s one you understand well enough to repeat.

When an AI pilot goes well, it’s tempting to treat the results as evidence that the organization is ready for a broader rollout. But there’s a question that doesn’t always get enough attention:

“How much of that success came from the technology, and how much came from the circumstances surrounding it?”

Maybe the person running the pilot had spent weeks studying the system, learning its limitations, and figuring out how to work around problems before anyone else encountered them.

Maybe the pilot was conducted in a department with unusually well-maintained source material, or with people who already understood the task well enough to recognize and correct questionable outputs.

Or maybe the workflow was so closely tailored to the needs of one group that it worked beautifully there, but wouldn’t translate nearly as well to another department.

None of these necessarily makes the pilot a failure. But they do matter when deciding whether to expand it.

Before scaling an AI workflow, we should be able to explain what made it successful. That includes more than documenting the prompts or configuration. We need to know what information went in, what human review was required, what errors occurred, how much work went into correcting them, and what conditions might cause the workflow to fail.

We also need to know whether those conditions will hold when the workflow moves out of the pilot environment and into ordinary operations.

What happens when the unusually capable person running the pilot isn’t available? When the source material is less reliable? When the workload increases enough to expose problems that a small sample never revealed?

Those aren’t reasons to abandon a promising pilot. They’re reasons to examine its results more carefully.

A pilot demonstrates that a workflow can succeed under a particular set of conditions. It doesn’t necessarily establish that those conditions exist elsewhere in the organization, or that they can be reproduced.

Sometimes the next step should be another pilot in a different department or under different conditions, rather than a broader rollout.

And that’s why I think evaluating the results deserves at least as much attention as designing and conducting the pilot itself.

Before deciding whether to expand, organizations need to examine not just what worked, but why it worked, what it required, where it struggled, and how well the conditions that produced those results represent the environment in which the workflow will actually operate.

A successful pilot is evidence worth investigating. It isn’t, by itself, a decision to scale.
Posted October 7, 2026 on LinkedIn
A recent AI preprint brought back a frustration from my years as a teacher: the class average could improve while individual students fell further behind. The paper examines how changes to an AI agent’s instructions can improve its average performance while breaking things it previously did correctly. That felt familiar enough that I wanted to write about it.
Posted October 5, 2026 on LinkedIn
An AI search tool sitting on top of outdated documents can give you a faster way to retrieve the wrong answer.

You probably know the source problem already. There are three versions of a procedure, and the old one still appears first in search. A shared drive makes sense to the person who organized it, but that person retired in 2019. Nobody knows who owns the document everyone keeps copying.

Adding AI doesn’t settle which version your organization should trust.

But there’s another way that knowledge base can become unreliable: the work being added to it loses its supporting evidence before it gets there.

Imagine someone using a personal AI account to interpret a procedure. They copy the answer into a shared document, but the source version and the conversation that shaped the answer stay in their account. A colleague reviews it without recording what they checked.

Six months later, your organization’s AI assistant retrieves that document. The answer has survived. The evidence needed to verify it hasn’t.

This is where Bring Your Own AI concerns me. As work spreads across disconnected tools and personal accounts, an organization can accumulate finished documents while losing the ability to explain how they were produced.

Managed BYOAI could preserve that evidence, certainly. But “managed” is doing a considerable amount of work in that sentence. Someone has to decide what gets retained, where it belongs, and who checks it. Then those requirements have to work for the people using the tools.

I’ve talked about this through my seven levels of AI implementation, including at the Learning Guild: levels 1–3 establish policy, and levels 4–7 carry it into the workflow. There needs to be a feedback loop between them.

Policy has to reach far enough into the work to establish which sources count and what evidence people must preserve. And when workers encounter conflicting procedures or requirements they can’t follow in practice, that information needs to reach the people who can revise the policy.

Otherwise, the knowledge base keeps growing while the reasons for trusting it become harder to find.

Before you build an AI knowledge assistant, decide what counts as organizational knowledge and who is responsible for keeping it trustworthy.

That includes the next document someone adds.

My first comment on the post
Further reading: Dare Bello and John Hastings, “Governing Bring Your Own AI: A Parameterized Maturity Model” (September 2026 preprint).
https://arxiv.org/abs/2609.05236
The authors examine the gaps that arise when employees use personal AI accounts outside enterprise identity and security controls. They propose governance supported by technical controls and human practices; their numerical results come from a parameterized model, with empirical validation still to come.
My connection here is what happens when the work produced in those accounts enters an organization’s shared knowledge. If the finished document travels but its sources and review record don't, someone inherits an answer without the evidence needed to check it.
Posted October 3, 2026 on LinkedIn
Six years ago, I made a lesson because I couldn’t find anyone teaching one Common Core geometry standard the way I thought students needed it taught. This week I went back and found that people are still finding it!

The video has never gone viral. It has just kept getting slow, steady traffic: nearly 2,000 views and 112 hours of watch time since I published it in 2020. That surprised me, but not nearly as much as what I found when I searched the topic myself.

Google surfaces the video prominently for “fractional distance along a directed line segment”. In the search results, it was one of two videos cited in the AI Overview and the first video result shown beneath it.

I’m actually rather proud of that. I made the video partly out of frustration and partly because I thought others could benefit from the way I taught a topic that, at the time, very few people seemed to be explaining. Six years later, it has earned a durable place among the resources people are finding when they search for that topic. For a fairly specific high-school geometry standard, I find that more interesting than a spike in views.

Now, pride aside, a fundamental part of the instructional design process is evaluating and returning to analysis. These are the E and A in ADDIE coming back around. There are always improvements to be made. I watched the video again and realized the video stopped at an obvious boundary: People could watch me do it, but they couldn’t immediately try it themselves.

So I built an interactive GeoGebra companion. Learners can move the endpoints, change the fraction, predict where the point should fall, and then see the result. It turns the worked example into something they can experiment with.

I’ve used GeoGebra for years. Desmos may be the popular kid on the block, but GeoGebra is still the rock that does pretty much everything I ask of it. And does it for free.

I built two versions of the activity: a landscape layout for larger screens and a portrait layout for phones. The page picks the version that best fits the user’s screen and adjusts if the device orientation changes.

That wasn’t just a technical decision. If the whole point was to give learners an easier way to interact with the concept, I didn’t want the interaction itself to become an obstacle depending on what device they were using.

That’s probably the part of revisiting this lesson that I enjoyed most. I didn’t need to replace a six-year-old video because it was old. The explanation still works, and people are still finding it useful. What it needed was something that came after the explanation.

Sometimes revisiting an old learning asset doesn’t mean making a newer version of the same thing.

Sometimes it means asking, “What should the learner be able to do now that they couldn’t do before?”

I put the original lesson, the background behind it, and the new interactive activity together here: the fractional-distance lesson

$The interactive GeoGebra companion on kwpledger.com. A coordinate grid shows a segment from A at (14, 5) to B at (-1, 4) with point C at (3.2, 4.28), a slider set to frac = 0.72, and the three calculation steps written out beside it, above a Swap TO and FROM button.$
Posted October 1, 2026 on LinkedIn
When an AI tells you how it arrived at an answer, how do you check that account?

That’s the part of the GPT-6.1 Astra news I find worth examining. OpenAI withheld the model after it fell short on staying within authorized scope and communicating what work it had done, according to reporting from CNA/AFP¹.

I keep coming back to four principles for human-AI projects: every product must be human-owned, source-grounded, verifiable, and traceable.

The paper trail is where those principles get tested.

Suppose an AI produces a recommendation, lists its sources, and explains its reasoning. You ask it to check its work. It assures you that the sources support the conclusion.

What have you verified?

If all you have is the model’s account, you’re still depending on the same system to tell you whether that account is accurate. A readable explanation doesn’t establish that it faithfully describes how the answer was produced. Research on chain-of-thought faithfulness makes that distinction explicit².

Leaving the model to produce the only paper trail already weakens traceability. If you then use that trail as the evidence that the work is correct, verifiability goes with it.

Astra’s reported shortcomings make that dependency harder to ignore. They don’t establish that it fabricated citations. They do give us another reason to require evidence beyond an agent’s description of its own work.

For me, the four principles translate into concrete responsibilities:
- Human-owned: someone owns the result and can explain why they accepted it.
- Source-grounded: the original material actually supports the claims.
- Verifiable: a reviewer can check the work against evidence beyond the model’s assurances.
- Traceable: the record preserves sources, actions, and human decisions so another person can reconstruct what happened.
AI can help assemble that record. The human owner still has to establish that it holds up.

When someone asks, “Why did we make this decision?” I want us to have more to give them than a chat transcript.

¹ Source: channelnewsasia.com

² Source: arxiv.org
Posted September 8, 2026 on LinkedIn
For consequential AI-generated work, human review is an absolutely vital part of the control system. I doubt you’ll find many people arguing otherwise.

But it is still only one part, necessary but far from sufficient on its own.

Having a human in the loop is a strong beginning for control design. That’s all it is, though: a beginning.

Let’s say an AI system drafts a procedure, summarizes a technical document, or recommends a course of action. Saying “a human will review it” tells us that someone appears somewhere in the process. It doesn’t tell us:
- Who reviews the output?
- What qualifications do they need?
- What makes them the appropriate reviewer for this particular output?
- What, specifically, are they responsible for checking?
- What source material should they compare it against?
- How will they trace the claims in the output back to approved source material?
- How is their approval recorded?
- What happens when the output fails review?
“Review” isn’t one generic activity, either. A factual review asks whether the claims are accurate. A compliance review asks whether the output meets policy or regulatory requirements. An editorial review asks whether it is clear and appropriate for the audience. A source review asks whether the content can be traced to verified material. A decision review asks whether someone should act on the recommendation.

Those responsibilities may overlap, but they aren’t interchangeable. Someone qualified to improve the writing may not be qualified to verify regulatory compliance. Someone familiar with the subject may still need access to the approved source material before they can verify the output.

Then, there is the practical question: Does the reviewer actually have enough time to do the work?

If a proper review takes twenty minutes, but the workflow gives the reviewer three, the organization hasn’t really designed a review process. It has assigned responsibility without providing the conditions needed to exercise it.

In high-risk work, especially in regulated environments, defined review checkpoints, clear reviewer responsibilities, and a record of what was reviewed, approved, corrected, or rejected are a large part of what makes AI use defensible.

Keep the human in the loop, certainly.

But first, design the loop.
Posted August 31, 2026 on LinkedIn
Before you automate a twelve-step process, make sure it should still have twelve steps.

Let’s say an employee copies information out of one system, reformats it in a spreadsheet, and emails it to someone else. Then, that person copies the same information into a template. A manager approves it. Then, someone enters it into a third system.

At that point, the obvious AI question is probably: “Can we automate the copying and formatting?”

Maybe.

But I think there are a few questions that should come first.
- Why are three systems involved?
- Why are we entering the same information more than once?
- What is the manager actually approving?
- Could the first system produce the output we need?
And, probably most importantly:
- Which of these steps only exist because of a constraint that stopped being relevant five years ago?
AI can absolutely improve the steps that survive those questions. But automating unnecessary work does not make the process better. It just makes the unnecessary work happen faster.

This is one of the places where I think AI implementation and ordinary process improvement need to stay in the same conversation.

If a workflow has accumulated workarounds, duplicate entries, handoffs, and approvals over the years, dropping AI into the middle of it may preserve all of that structure when what you really needed was permission to question the structure.

A faster bad process is still a bad process. Before you add AI, give the workflow permission to lose a few steps.
Posted August 24, 2026 on LinkedIn
Your AI pilot did not save ten hours if someone spent eight hours checking and fixing the output.

This is one of the easiest ways to fool ourselves when measuring an AI pilot.

Let’s say a report used to take six hours to write. With AI, the first draft takes one. You say, “Great! Five hours saved!”

Except, you neglected the fact that an experienced employee then spends three or four hours checking the facts, correcting formatting issues, finding and removing unsupported claims (or finding the support for them, or replacing them with actually supported claims), restoring context the AI left out, and then documenting what changed.

Now, we aren’t looking at a five-hour savings anymore. It’s one or two at most. And this isn’t even counting the time spent crafting the prompts that generated the report! That may be an upfront cost rather than a recurring one, but it’s still part of what the pilot cost.

Also, there may be another problem hiding in the numbers. The six-hour report may have originally been produced by a junior employee. The three hours of review may now belong to a much more expensive SME.

The AI still helped. But “it drafted the report five hours faster” doesn’t tell us very much about whether the new workflow is actually better.

I think the more useful questions are:
- How long did the entire workflow take before and after?
- How much rework did the AI-generated output require?
- Who had to do that work?
- Did the error rate change?
- And most importantly, did we actually reduce the workload, or just move it somewhere else?
This matters even more in high-risk or regulated work, where human review isn’t optional. Validation has a cost in time and expertise, and that cost belongs in the pilot.

That doesn’t make AI useless. It means the review needs to be designed into the workflow from the beginning and measured along with everything else.

Measure from the moment the work starts until someone can safely use the result.

Anything less is demo math.
Posted August 17, 2026 on LinkedIn
I think we give people the wrong reason for why they should document how they use AI. It’s usually presented as a compliance thing. “Document what you did because policy requires it.” “Legal might need it.” Or even, “Some auditor may come asking questions later.”

And I mean, sure. I’ll grant the point that those are all perfectly good reasons.

That said, there’s a much more practical reason to document the process whenever we use AI to help create an artifact: six months from now, nobody is going to remember what you did.

Maybe not even you.

Someone is going to look at an AI-assisted document or process and want to know:
- What prompt or process produced this?
- What source material did the AI use?
- What did a human review or change?
- Why did we use this tool or approach?
If you documented the work, those are easy questions. If you didn’t, well now you’re going to be reconstructing the whole thing from the finished output, someone’s memory, and possibly a Webex or Slack message you vaguely remember seeing sometime last October.

That’s not really an audit problem. That’s a “how on earth did we do this?” problem. That might even be a “how on earth are we going to do it again?” problem.

And that is why I’ve started thinking about AI documentation less as paperwork and more as institutional memory. It makes the work behind the artifact supported, verifiable, and traceable.

More importantly, somebody else can pick it up later and understand what happened without having to find the person who originally did it because, eventually, that person will move to another team, leave the organization, or simply forget.

Future-you is also notoriously bad at answering follow-up questions from present-you.

So yes, document your AI use because your governance process says you should.

But also document it because three months from now somebody is going to ask, “Wait, where did this come from?”

It’s nice to have an answer.
Posted August 10, 2026 on LinkedIn
The biggest obstacle to your AI rollout might not be the skeptic. It might be the person who is really good at the old way.

We tend to prepare for the obvious resistance: the person who announces that AI is a fad, refuses to touch it, or has already decided the whole initiative is doomed.

But, consider your best analyst instead. They’ve spent eight years building a spreadsheet that genuinely does exactly what they need it to do. They know every exception. Every weird edge case. Every place between the documented process and the actual process parted ways sometime around 2019.

Now, you’re asking them to replace part of that workflow with something that is less familiar, less predictable, and (at least initially) probably worse at some of the things they care about most.

Their hesitation may not be resistance to change. It may be expertise doing exactly what expertise is supposed to do: noticing what the new system doesn’t understand yet.

And that’s why I think some of the people who look hardest to win over should be brought into an AI rollout earlier, not later.
- Ask them where the tool fails.
- Ask them what a novice wouldn’t know to check.
- Ask them what would have to be true before they would trust the new workflow.
Then, build those answers into the implementation because the goal shouldn’t be to convince your experts that their old knowledge is obsolete. It should be to make that knowledge part of what makes the new system better.
Posted August 5, 2026 on LinkedIn
Have you ever seen one of those pilots that never failed only because it never actually ended?

If you have, then you know how they go. Someone runs a pilot with a small, engaged team. It goes fine. Everyone nods. And then it just… stays a pilot. Six months later it’s still “the pilot.” A year later, some new hire asks what it is and all you can give them is a shrug.

A pilot that never converts to real infrastructure is obviously not a success story. But neither is it a failure. It’s a warning sign.
- No one wants to own moving it past the pilot stage.
- So no budget line ever appears.
- So no one discovers what scaling actually costs.
- So the pilot keeps “succeeding” without ever proving it can survive outside the pilot.
Everyone privately knows this, but no one is willing to say it in the meeting.

A pilot is supposed to answer a question: Is this worth scaling? “It’s still going” is not an answer. It’s the absence of one.

If your pilot has outlived the person who launched it, it’s not a pilot anymore. It’s just a thing you never decided about.

This post is about AI pilots that never get off the ground.
Posted July 27, 2026 on LinkedIn
“We saved 40% of the team’s time” sounds great until someone asks what they did with the other 60%.

I read A LOT of reporting on AI and this seems to be the part that we don’t spend enough time talking about. Or even acknowledging based on how hard I have to look for it.

Your “time-saved” metrics look fantastic in a slide. They start to look a lot less fantastic when someone like me starts asking follow-up questions:
- Did the work actually get faster, or did people just generate more drafts to review?
- Did anyone’s job actually change, or did the busywork just shift to someplace else?
- Is anyone measuring quality, or is it just speed?
- Would this hold up if we watched someone do it live?
A lot of AI ROI numbers remind me of diet supplement ads. They’re often built around the measurements that look most impressive, even if they don’t tell the whole story.

Please don’t get me wrong. None of this is me saying AI isn’t saving time. I can attest: AI absolutely saves me time. I see it every day. My concern isn’t that the savings are fake. It’s that the metric we report is often the easiest one to collect rather than the one that tells the whole story.

Good metrics should survive uncomfortable questions. If your AI ROI slide has never made anyone uncomfortable, it probably hasn’t been challenged hard enough.
Posted July 20, 2026 on LinkedIn
Your team is already using AI. You just don’t have a policy for the version they’re actually using.

I keep hearing leaders say some version of, “We’re being careful. We haven’t rolled anything out yet.” Meanwhile, three people on that same team have ChatGPT open in another tab, quietly pasting things into it that would make Legal sit down.

This isn’t a hypothetical. It’s the default state of most workplaces right now:
- No approved tool, so people bring their own.
- No guidance, so people guess.
- No visibility, so leadership assumes nothing is happening.
“We haven’t implemented AI yet” almost always means “we haven’t implemented AI on purpose yet.” The implementation already started. It started the day someone got frustrated with a slow process and had a browser tab open.

Waiting for a perfect rollout plan doesn’t prevent AI use. It just means the first real use case in your org happens without a single guardrail attached.

You don’t get to choose whether your people use AI. You only get to choose whether you know how.
Posted July 9, 2026 on LinkedIn
Even though it’s the brand I am selling, I feel confident in saying that nobody wants to buy “AI implementation.” The people who are in charge of figuring out which AI tools to buy want fewer bottlenecks, cleaner data, faster reports, and proof it actually works.

This is where a lot of AI positioning goes sideways: The pitch focuses on the tool.

The customer cares about the pain. They do not wake up thinking, “I need a large language model strategy.”

They wake up thinking:
- “My team is drowning in manual work.”
- “Our reporting takes too long.”
- “Nobody trusts the data.”
- “Our knowledge base is impossible to search.”
- “We keep answering the same questions.”
- “Our process depends on one overworked person.”
AI may be part of the solution, but it is not the thing people are buying. They are buying saved time, reduced risk, faster decisions, better consistency, less rework, and more capacity.

This distinction between what’s being sold and what needs to be bought matters because “we implement AI” sounds like a method. “We help your team cut proposal time by 50%” sounds like a business outcome.

The best AI consultants, trainers, and internal champions are not selling AI. They are using AI to solve problems people already know they have.
Posted July 8, 2026 on LinkedIn
If your AI policy needs a 40-page PDF, I can promise you that nobody is using it. Make the guardrails simple enough to remember before someone pastes data they shouldn’t.

That does not mean governance should be shallow. It means the front-line version has to be usable. People need clear rules in the moment they are working. They don’t need a legal document they vaguely remember seeing during onboarding.

A good AI rollout needs answers to questions like:
- What data can I paste?
- What data is never allowed?
- When do I need approval?
- What outputs must be reviewed?
- What use cases are off-limits?
And most importantly:
- Where do I go when I’m unsure?
The mistake leadership makes is assuming that more detail automatically creates more safety. Sometimes, all it succeeds in doing is creating fog and, in a fog, people improvise.

The best AI guardrails are simple, visible, and reinforced through real examples. It’s not because people are careless, but because people are busy. If responsible AI is the goal, the rules need to survive contact with Wednesday afternoon.
Posted July 7, 2026 on LinkedIn
AI adoption doesn’t come from another training session. It comes from showing Sarah in accounting exactly how it saves her Tuesday.

Generic AI training has a ceiling. People may leave thinking the tool is interesting. They may even feel mildly impressed. But inevitably, they will go back to their actual work and wonder, “How does this help me?”

That is where adoption usually breaks. The use case has to become local. It has to be specific and familiar. It needs to be grounded in the work someone already recognizes.

A training team needs training examples. A claims team needs claims examples. An HR team needs HR examples. A finance team needs finance examples. And each team needs someone credible enough to say, “I tried this in our workflow and here’s where it helped.”

Not every AI champion needs to be technical. In fact, some of the best champions are not the “AI people” at all. They are the people who understand the work deeply enough to spot where AI actually fits. Adoption spreads faster when it feels like a coworker sharing a shortcut. It doesn’t spread when it’s yet another vendor selling a revolution.
Posted July 6, 2026 on LinkedIn
I see what a lot of you are posting about AI Implementation in your business. Your team doesn’t need a “moonshot AI strategy.” They need one boring workflow that stops wasting 5 hours a week.

This is where the benefits of using AI as a tool start to become real. No one cares if you used it to craft the perfect demo for your keynote. Even few if you used it to create that executive vision deck you’re so proud of. That is all flash. Useful for generating excitement, but we all can attest that excitement alone does little to bring in proofs of concept.

On the other end of the spectrum, those returns you’re looking for on your investment in AI aren’t going to be found in the “what if we built an agent that runs the whole department?” brainstorm.

The useful work in AI Implementation usually starts with things like:
- Turning PDFs into structured data.
- Cleaning messy spreadsheets.
- Summarizing long documents.
- Drafting routine reports.
- Finding answers buried in SOPs.
- Preparing meeting notes.
- Updating CRM records.
- Classifying requests.
None of that sounds futuristic. That’s the point. The best AI use cases are often painfully ordinary. They remove friction from work people already do every week. They save time without asking the whole organization to reinvent itself. They make the work more predictable. Big AI strategies are fine. But if you want adoption that brings in a real ROI, start smaller.

Find the repetitive data work. Find the bottleneck. Find the weekly task everyone quietly hates. That is probably your first AI win.
Posted July 5, 2026 on LinkedIn
Prompting isn’t the real problem. AI rollouts don’t fail because people can’t prompt. They fail because nobody knows what problem they’re actually solving.

That sounds harsh, but I’ve seen this pattern again and again in people’s complaints on LinkedIn and on Reddit. I’ve seen it in conversations at my own workplace.
- A team gets access to a new AI tool.
- Leadership says, “Go experiment.”
- Someone opens the tool, types a vague request, gets a vague answer, and walks away thinking: “Yeah, this isn’t useful for my job.”
But the issue was never the model. The issue was that the person had not yet translated their work into a clear outcome. AI is much more useful when people can answer:
- What am I trying to produce?
- What information should it use?
- What standard does the output need to meet?
And most importantly:
- What should a human still review?
That is why “prompt training” by itself is usually wasted energy. The real skill is not writing clever prompts. The real skill is thinking clearly enough to ask for the right thing.

AI implementation is less about teaching people magic words. It is about helping people understand their own work well enough to improve it.