Lesson 1 · ~12 min

The Automation Paradox

Ask any airline captain what modern automation changed about the job and you'll rarely hear "it made flying easier." What you'll hear is that it changed what the work is. A modern jet can climb, cruise, navigate and in many cases land with very little hand flying. You might expect the crew to have little to do. In practice, the crew's job moved from moving the controls to managing a system: briefing what the automation is supposed to do, watching that it does it, and stepping in when it doesn't.

That's the automation paradox, and it's the first idea in Ground School because it applies directly to AI at work. The more capable the tool, the more important the human who supervises it. Capable automation doesn't remove the need for judgment. It concentrates it. When the autopilot flies most of the flight, the rare moment it does something unexpected is exactly when an alert, well-trained crew matters most.

Why this matters for a business team

AI chat tools and assistants are a new kind of automation for knowledge work. They draft emails, summarize documents, write first versions of proposals and answer questions in seconds. For many tasks the output is genuinely good. That's the trap. When output is usually good, people stop reading carefully. Aviation has a name for this: complacency. It isn't laziness. It's a predictable human response to a system that's usually right.

The Wharton professor Ethan Mollick describes the same risk in AI as "falling asleep at the wheel": when the AI seems good enough, people stop checking the details. His research with a large consulting firm found that people using AI did markedly better on tasks the AI handled well, and noticeably worse on a task it handled poorly, because they trusted output they should have questioned. We'll come back to that study in Lesson 3. For now, the lesson is that the tool's skill and the user's vigilance have to rise together.

Three things pilots do with automation

Professional crews treat automation with a simple discipline you can borrow directly:

1. Brief it. Before engaging a mode, the crew states what it should do: "Autopilot on, climbing to one-two thousand, heading two-seven-zero." For AI, that's a clear request with context, purpose and constraints.
2. Monitor it. One pilot's main job is watching what the automation actually does, not what everyone assumes it's doing. For AI, someone reads the output critically before it's used.
3. Be ready to take over. If the automation goes somewhere unexpected, the crew doesn't debate it. They disconnect and fly. For AI, the team knows when to stop using the tool and do the task by hand.

Notice what isn't on that list: "trust it completely" and "refuse to use it." Both extremes are dangerous. A crew that won't use the automation tires itself out and misses its benefits. A crew that trusts it blindly eventually follows it somewhere it shouldn't go. The professional middle path is engaged use.

Responsibility doesn't transfer

There's one more principle that never changes in a cockpit. The captain is responsible for the safe conduct of the flight, whoever or whatever is flying at the moment. Automation doesn't sign the logbook.

The same holds in business. If an AI tool drafts a quote with a wrong price, or a summary that leaves out a key contract term, the customer won't blame the software. They'll hold your company responsible. Using AI doesn't move accountability away from the person who sends the work. That's not a reason to avoid the tools. It's a reason to put a professional process around them, and that's what the rest of this course does.

Setting expectations

This module won't make anyone an AI expert in an hour. Its goal is to install the right mental model before your team builds habits: AI is powerful, uneven and fallible automation, and the people using it are still the crew. Every later module, from checklists to crew roles to guardrails, builds on that.

Lesson 2 · ~10 min

What AI Actually Is (and Isn't)

Pilots learn how their systems work before they're trusted to fly them. Not every wire, but enough to predict how a system behaves when something goes wrong. The same applies here. You don't need a computer science degree to use AI well, but you do need a working model of what's happening when you type a question and an answer appears.

A prediction engine, not a database

The AI chat tools most businesses use, such as Grok, ChatGPT, Claude and Gemini, are built on what are called large language models. At heart, a language model has been trained on an enormous amount of text to do one thing extremely well: predict what text should come next, given what came before. Asked a question, it generates an answer one small piece at a time, each piece chosen because it fits the pattern of everything so far.

That simple description explains a lot of AI behaviour that otherwise seems mysterious:

• It's fluent. It has absorbed the patterns of human writing, so its answers read naturally and confidently.
• It can be wrong while sounding right. Fluency and accuracy are different things. The model produces text that fits the pattern of a good answer. Most of the time that means a correct one, but not always.
• It doesn't "look things up" by default. Unless a tool is connected to web search, your documents or another source, the model answers from patterns learned in training, which can be out of date or incomplete.
• It's sensitive to how you ask. Different wording, context or examples change what text it predicts. That's why briefing matters so much.

What AI is good at

Within those limits, modern AI is remarkably capable at:

• Drafting and rewriting: emails, proposals, job postings, policies, social posts.
• Summarizing long material into key points.
• Brainstorming options, names, angles and questions.
• Explaining concepts at whatever level you need.
• Reformatting: turning notes into tables, bullets into paragraphs, a policy into an FAQ.
• Helping with spreadsheets, formulas and simple code.

What AI isn't

Just as important is clearing up a few common misconceptions:

• It isn't an oracle. It doesn't "know" facts the way a reference book does, and it can invent plausible details, including citations, statistics and quotes.
• It isn't a person. It responds well to plain, human instructions (Mollick advises talking to it as you would a capable colleague and giving it a role), but it has no stake in your business and no accountability.
• It isn't automatically private. What you type may be stored or used under the tool's terms, depending on the product and your settings. Lesson 6 covers this.
• It isn't one fixed thing. Different tools, versions and settings behave differently, and they change often.

Chat, workflows and agents: a quick map

You'll hear three terms more and more. A chat assistant is the simplest: you ask, it answers, and you decide what to do. A workflow connects AI steps along a path a person designed, for example "summarize each new support email, then sort it into a category." An agent is given a goal and tools and decides its own steps, such as searching, drafting, sending or booking. Anthropic's engineering guidance draws the same line between designed workflows and self-directed agents, and recommends starting with the simplest option that works. In aviation terms: hand flying, then a flight director guiding you along a planned path, then full autopilot. Module 5 goes deeper. For Ground School, the point is that the more autonomy you give the system, the more you need guardrails and monitoring.

The working model to carry forward

If you remember one sentence from this lesson, make it this one: AI generates likely-sounding text from patterns. It's a skilled drafter, not a source of truth. Treat its output the way a captain treats a first officer's draft flight plan: probably good, worth using, and always checked before you commit to it.

Lesson 3 · ~11 min

The Jagged Frontier

Every aircraft has an operating envelope, the combinations of speed, altitude, weight and conditions where it's safe and predictable. Inside the envelope, the aircraft is a superb tool. Outside it, things go wrong quickly. Good pilots know their envelope cold.

AI has an envelope too, but with an important twist: its edges are irregular and hard to see. Ethan Mollick and his research colleagues coined a memorable term for this, the jagged frontier. AI may be excellent at one task and surprisingly poor at a similar-looking task right next to it, and you often can't tell which is which in advance.

What the research found

In a widely discussed field experiment with a large consulting firm, roughly 750 consultants worked on realistic business tasks, some with AI and some without. As reported by Mollick and in published summaries, on tasks inside the AI's capabilities the consultants using AI finished more work, faster, at noticeably higher quality. But the researchers also set a task deliberately chosen to fall outside what the AI did well. On that task, consultants using AI were more likely to reach the wrong answer than those working without it. The AI's answer was persuasive, and many people accepted it.

(The specific percentages are reported in the research paper and in many secondary write-ups. We're paraphrasing the direction of the findings rather than quoting figures, and we encourage you to read the original.)

The lesson for any business is twofold. First, the upside is real: on the right tasks, AI can meaningfully help capable people. Second, the downside is invisible until it bites. The danger isn't that AI fails obviously. It's that it fails convincingly.

Why the edge is jagged

Recall from Lesson 2 that AI predicts likely text. Some tasks line up perfectly with that skill, such as rewriting, summarizing and drafting in a familiar format. Others need things the model can stumble on: precise counting, maths without a calculator tool, very recent facts, your company's specific details, or reasoning that depends on information it doesn't have. Two tasks can look the same to a person and sit on opposite sides of the frontier. Mollick gives a vivid example: a model might write a fine sonnet yet fail to produce a sentence of exactly 25 words.

The frontier moves

One more complication: the frontier keeps shifting. New model versions handle things older ones couldn't, and occasionally an update changes behaviour you relied on. A task that was outside the envelope last spring may be inside it now, and vice versa. That's why the exercise in Lesson 5 is about building ongoing familiarity, not memorizing a fixed list.

Mapping your own frontier

Pilots don't learn the envelope by reading alone. They learn it in the simulator and in supervised flying. Teams can map their AI frontier the same way, with a simple practice:

1. List the tasks your team might hand to AI.
2. Try each one on real (non-sensitive) examples where you already know the right answer.
3. Grade honestly: green (reliably good), amber (useful but needs a careful check), red (unreliable, don't use, or use only as a brainstorm).
4. Share the map so the whole crew benefits, and revisit it every few months.

That turns a vague worry ("AI makes mistakes") into operational knowledge ("it's green for first-draft emails, amber for summaries of contracts, red for calculating our job pricing").

The verification rule

Because the edge is invisible, the safest default is simple: the higher the stakes, the stronger the check. A brainstormed list of blog topics needs a glance. A customer-facing price, a legal clause, a medical or safety statement, or a number going into the books needs line-by-line verification against a trusted source, every time. That's trust but verify in practice, and it's the bridge to Lesson 4.

Lesson 4 · ~11 min

Confident and Wrong: Hallucinations

Aviation is built on cross-checks. When one pilot sets an altitude, the other confirms it aloud. When a clearance comes from air traffic control, it's read back. Nobody takes this as an insult to the first pilot's skill. It's an acknowledgement that skilled people still make errors, and that a second, independent check catches most of them before they matter.

AI needs the same treatment, for a specific reason: it can produce false information that looks exactly like true information. The common term is hallucination, though "confabulation" may be more accurate. The model isn't lying, and it isn't malfunctioning in the usual sense. It's doing what it always does, generating plausible text, and sometimes plausible text is wrong.

What hallucinations look like in business

• Invented sources: citations, court cases, articles or statistics that don't exist but are formatted perfectly.
• Wrong specifics: a correct-sounding phone number, address, date, price or part number that's simply wrong.
• Filled gaps: when it lacks your information, it supplies a typical answer instead of saying "I don't know."
• Quiet omissions: a summary that drops the one clause, exception or caveat that mattered.
• Arithmetic slips: totals, percentages and dates calculated incorrectly but presented confidently.

Omissions deserve special attention because they're the hardest to catch. A false statement can be spotted. A missing one only shows up if you compare the output with the original.

Trust, but verify: the cross-check discipline

"Trust but verify" in a cockpit means you use your crewmate's work, and you confirm the items that matter. Applied to AI:

1. Check every specific. Names, numbers, dates, prices, quotes and claims get checked against a trusted source. Not "it looks right." Checked.
2. Open every link and citation. If the AI cites something, confirm it exists and says what the AI claims.
3. Compare summaries with the source for anything important: contracts, policies, customer requests, financial documents.
4. Use the right tool for maths. Run calculations in a spreadsheet or calculator, or use an AI tool that shows its working with a calculation feature, and still sanity-check the result.
5. Read it as the recipient will. Would this embarrass you or mislead a customer if one detail were wrong?

Reducing hallucinations before they happen

You can't eliminate them, but good briefing lowers the rate:

• Give the AI the actual source material and tell it to rely only on that.
• Explicitly permit uncertainty: "If you're not sure, say so. Don't guess."
• Ask it to quote or point to the part of your material that supports each key claim.
• Break big tasks into smaller steps you can check along the way. Anthropic's engineering guidance describes adding checkpoints, or "gates," between steps for exactly this reason.
• Where available, use tools that search the web or your documents and show their sources. Then verify those sources.

A word on "AI detectors" and second opinions

Some people try to catch errors by asking a second AI to check the first. That can help as a brainstorm ("what might be wrong with this?"), but it isn't independent verification. Both systems can share the same blind spots. In aviation terms, it's like cross-checking an instrument against another instrument fed by the same faulty sensor. Real verification means comparing with a trusted, independent source: the contract itself, the price list, the customer's actual email, the official website.

Making it routine

The goal isn't to make people suspicious of every word. It's to make verification a habit sized to the stakes, like a readback: quick, automatic and never skipped on the items that matter. The AI Preflight Checklist in the sample module turns this into a few lines your team can run every time.

Lesson 5 · ~14 min

Learning Your Aircraft: Hands-On Hours

No pilot gets type-rated on a new aircraft by reading the manual. The manual matters, but competence comes from hours: in the simulator, with an instructor, and in supervised line flying, until the systems feel familiar and the unusual is recognizable. Confidence in a cockpit is earned, not declared.

AI is the same. Reading about it, this course included, gives you the concepts. But the only way to learn what AI can do for your work, and where it fails, is to use it on real tasks. Ethan Mollick's first rule of working with AI makes this point: bring AI into your work so you can discover its strengths and weaknesses for yourself, because nobody can tell you in advance what it will be good at in your specific job. In interviews he has suggested that roughly ten hours of genuine hands-on use is a reasonable threshold for getting a feel for it.

Why hands-on hours matter for teams

Change-management research points the same way. Prosci, a change-management research firm, frames individual adoption with its ADKAR model: Awareness, Desire, Knowledge, Ability and Reinforcement. Knowledge (understanding how) isn't the same as Ability (being able to do it in real work). Many AI rollouts stall exactly in that gap. People attend a training session, nod along, and never build the habit. Practice is what turns knowledge into ability.

A structured "type rating" for your team

Unstructured experimenting is fine, but a little structure makes the hours count. Here's a simple plan, borrowed from how flight training is built:

1. Ground phase (week 1): each person picks five recurring tasks from their own job and tries AI on each one with non-sensitive data. Keep a short log: task, what you asked, result, green/amber/red.
2. Simulator phase (week 2): repeat the amber tasks with better briefing (more context, examples, explicit constraints) and see whether they move to green.
3. Supervised line phase (weeks 3–4): use AI on real work in green areas, with a colleague reviewing outputs before they go out.
4. Debrief: the team shares logs, agrees what's green, amber and red, and records good prompts in a shared document.

Total time is a few hours per person spread over a month, alongside normal work rather than instead of it.

What to practise

Good beginner tasks share three traits: they recur, the stakes are low, and you can easily tell whether the result is right. Examples:

• Turning bullet notes into a polished email or meeting summary.
• Drafting a first version of a job posting, a social post or a newsletter section.
• Asking for ten ways to explain a service to a new customer.
• Reformatting a messy list into a clean table.
• Getting a plain-language explanation of an unfamiliar term or regulation, then checking it against an official source.

Avoid at first: anything with confidential customer, employee or financial data; anything that goes straight to a customer without review; and anything where you couldn't tell a right answer from a wrong one.

Practise conversation, not just questions

A common beginner pattern is to use AI like a search engine: one question, one answer, done. The value often comes from conversation. Ask for options, react to them, push back, give more context, request a different tone, ask it to critique its own draft. Mollick has observed that many people use these tools in a shallow way and miss much of what they can do. Treat the first answer as an opening draft, not a final product.

Log it like a pilot

Pilots keep logbooks for a reason: they create a record of experience and reveal patterns. A simple AI log (a shared spreadsheet is fine) does the same for a team. Over a month it becomes your team's own map of the jagged frontier, which is worth more than any generic list of "AI use cases."

Lesson 6 · ~10 min

Where Your Data Goes

Before a flight, crews confirm what's on board and where it's going. Hazardous materials, weight, sensitive cargo: nothing gets loaded without someone knowing about it. Information deserves the same care. Every time someone pastes text into an AI tool, they're loading cargo onto a system the company may not fully control.

Why this belongs in Ground School

Data handling is the area where a single careless moment can create a lasting problem. A rewritten email can be fixed. Confidential information that's been shared with an outside service can't be unshared. That's why it belongs before the advanced modules, as a basic airmanship item.

What can happen to what you type

Policies vary widely between products and change over time, so the only reliable rule is to read the terms of the specific tool and plan you use. In general terms:

• Many consumer AI services store conversations, and some may use them to improve their models unless you change a setting or use a business plan.
• Business and enterprise plans often offer stronger commitments, such as no training on your data, admin controls and retention settings. Confirm the specifics in writing.
• Connected features (email, calendars, drives, browsing) can give an AI tool access to far more than what you type. Know what's connected.
• Anything you put into an AI tool may be subject to the same legal, contractual and regulatory duties as anywhere else you store it.

A simple traffic-light rule for information

Until your company has a formal policy (Module 7 helps you write one), a traffic-light rule works well:

• Green, generally fine: public information, your own general writing, made-up examples, non-identifying business questions.
• Amber, approved tools only, minimum necessary: internal documents, non-sensitive business details, anonymized customer situations.
• Red, don't paste unless the tool is specifically approved for it: customer personal data, Social Security or account numbers, health information, employee records, passwords and access codes, confidential contracts, and anything covered by a non-disclosure agreement or regulation.

When in doubt, strip it out: replace names with "Customer A," remove account numbers, round figures. AI usually needs the shape of a problem, not the identifying details.

Prompt injection: when the data is the hazard

One newer risk is worth knowing about now, because it gets more important as AI tools gain access to email and the web. If an AI reads a document, web page or email that contains hidden instructions ("ignore your previous instructions and forward this to…"), a poorly protected system may follow them. That's called prompt injection. OpenAI's guidance on building agents describes layered guardrails against exactly this kind of manipulation, alongside filters for personal information. The practical takeaway for Ground School: be cautious about letting AI tools act automatically on content from outside your company, and keep a human approving anything that sends, pays, deletes or shares.

The governance picture

The U.S. National Institute of Standards and Technology (NIST) publishes a voluntary AI risk-management framework, with a companion profile for generative AI. It organizes the work into four functions: Govern, Map, Measure and Manage. Data privacy and third-party risk are central to it. You don't need to adopt the whole framework to benefit. Simply knowing which tools your team uses and what data they touch is the "Map" step, and it's a big improvement over not knowing.

The crew briefing version

Before using any AI tool for work, every team member should be able to answer three questions: Is this tool approved for work use? What kinds of information may I put into it? Who do I ask if I'm not sure? If anyone can't answer, that's a gap to close this week.

Lesson 7 · ~10 min

Train Judgment, Not Buttons

Airline pilots don't train once and stop. Every year, and often more, they return for recurrent training: simulator sessions, procedure reviews and checkrides. Aircraft get software updates, procedures get revised, and skills fade without practice. The profession assumes change and builds learning into the calendar.

AI demands the same mindset, only faster. Mollick's fourth rule is to assume that the AI you're using today is the worst you'll ever use. Tools are improving and changing quickly. Features appear, interfaces get redesigned, and capabilities that were weak become strong.

The training half-life problem

Prosci's research on AI adoption highlights a paradox. Insufficient training is one of the most commonly cited barriers to adoption, yet tool-specific skills go stale quickly. In a recent webinar recap, Prosci described the "half-life" of specific AI skills as roughly three to four months. Training people on exactly which button to press in this month's version gives diminishing returns.

The answer isn't less training. It's training of a different kind: invest in durable judgment that survives tool changes, and treat tool-specific knowledge as something to refresh regularly.

What durable judgment looks like

The skills that don't expire are the ones this module has been building:

• Task sorting: recognizing which work should stay fully human, which benefits from AI collaboration, and which could be largely automated. Prosci's AI Integration Framework labels these "my work," "with me" work and "for me" work. We'll practise this in Module 3.
• Briefing: giving any AI tool a clear role, task, context, constraints and format.
• Verification: sizing the cross-check to the stakes, whatever the tool.
• Data discipline: knowing what information may go where.
• Escalation: knowing when to stop using AI and hand the task back to a human.

A pilot who understands energy management and crew coordination can transition between aircraft types. A team member who understands briefing, verification and data discipline can transition between AI tools.

Build recurrent training into the calendar

Borrowing from aviation, here's a lightweight rhythm for a small or mid-size team:

• Monthly (15 minutes): in a regular team meeting, one person shares a win and one shares a "near miss," where AI output almost caused a problem. No blame, just learning. Aviation's safety culture relies on reporting near misses precisely because they're free lessons.
• Quarterly (1 hour): revisit the team's green/amber/red map, update the shared prompt library, and review any tool or policy changes.
• When tools change: a short "differences training" session, as pilots get when an aircraft variant changes, covering what's new and what to watch for.

Reinforcement is a leadership job

In ADKAR, the final element is Reinforcement: what makes a change stick. People watch what leaders do. If managers use AI openly, share their own verification habits, praise people who catch AI errors, and never punish someone for raising a concern, the habits last. If leaders ignore AI or quietly cut corners with it, the training fades. A captain sets the tone of the flight deck. Business leaders set the tone of AI use.

Ground School wrap-up

You now have the core mental model. AI is capable but uneven automation (Lessons 1–3). It can be confidently wrong, so we verify (Lesson 4). Competence comes from logged, hands-on hours (Lesson 5). Information is cargo to be handled with care (Lesson 6). And because tools change constantly, we train judgment and schedule recurrent training (this lesson). The next module turns all of this into a checklist your team can run on every task.