AI literacy starts with real work
People understand AI when they can connect its capabilities and limits to work they already know.
AI becomes understandable when a person can connect it to work they already know.
I kept returning to this while preparing a 60 minute workshop for insurance professionals. The original structure was simple: spend roughly 30 minutes explaining AI basics, including ChatGPT and cloud systems, then leave the remaining time for questions, problem capture, and helping people work through examples.
That split changed how I thought about the session. The second half was where the subject could become useful.
A feature tour teaches the wrong unit
It is easy to fill an hour with models, prompts, agents, and examples of generated output. Each concept can be explained clearly. A person may still leave unsure where any of it belongs in their day.
The useful unit is a workflow. Someone receives information, interprets it, makes a decision, communicates with another person, and records what happened. AI may help at one or more steps. Its limits become clearer when the whole path is visible.
Insurance makes this especially concrete. Work can involve conversations, emails, policy documents, submissions, and claims. The information is often incomplete, and a decision may carry financial or legal consequences. A polished answer is only one small part of that environment.
This is why I wanted the workshop to create room for actual problems. A participant might bring a repetitive task, a difficult document, or a handoff that keeps losing context. I cannot know in advance which examples will appear. That uncertainty is part of the design. The session should give people enough shared language to describe where the work slows down and what a responsible use of AI would require.
Domain knowledge is part of AI literacy
People who know a workflow well often notice risks that a general AI explanation misses. They know which exception changes a decision, which field is unreliable, and when a familiar shortcut becomes dangerous.
An AI developer brings a different view. I can explain what a model can generate, how retrieval can connect an answer to source material, and why an agent needs explicit permissions before it takes an action. The domain expert can tell me whether those capabilities fit the work.
Learning happens in the exchange. A question that sounds basic may reveal that the technical explanation skipped an important assumption. A proposed use case may look easy until someone describes the review, approval, or relationship that surrounds it.
This also means people need permission to challenge the system. If a workshop makes AI sound inevitable or magical, participants may hesitate to ask where the answer came from or whether it can be corrected. Those questions are central. A person using AI in their work should be able to inspect a source, recognize uncertainty, and know when another person must decide.
Questions are product evidence
Leaving time for questions is useful for teaching. It is also useful for product discovery.
I am still exploring insurance workflows. I do not have a finished product direction. The questions people ask can show where their mental model breaks. The examples they bring can reveal which problems are frequent, which are merely annoying, and which carry enough responsibility that automation needs a careful boundary.
That evidence is different from asking whether someone wants AI. Most people can imagine a faster summary or a chatbot. It is harder, and more valuable, to describe the information available at the start, the action expected at the end, and what must happen when the system is uncertain.
The workshop format can make that description easier. The first half gives participants vocabulary. The second half tests that vocabulary against their work. I may leave with fewer apparently simple ideas, because the hidden steps have become visible. That would still be progress.
Teaching changes how I build
Preparing to explain AI to people outside software exposes gaps in my own thinking. Terms that feel precise among engineers can hide several product choices. An agent description is incomplete without its access, permitted actions, and review boundary. Memory is equally vague until the system explains whether stored information is current, relevant, and appropriate to reuse.
A useful explanation has to name those boundaries in ordinary language. A useful product does too.
This is why AI literacy matters to me beyond one workshop. Access to intelligence includes the ability to question it. People should understand enough of the system to decide where it helps, where it needs evidence, and where human judgment remains responsible.
I do not expect a 60 minute session to produce that understanding completely. I want it to give people a better starting point and give me better questions to carry back into the products I build.