“Local” means the model's calculations happen on your machine, rather than a provider's servers. Some applications can do this without an internet connection once their software and model files are downloaded. LM Studio, for example, documents offline chat with downloaded models.[1] That is different from opening a browser window that sends your questions elsewhere.

The useful hardware question is not “Is this an AI computer?” It is “Can this computer run my chosen model, at a useful speed, on the work I actually do?”

A couple points on specifications

• Capacity is how much you can keep open. Your computer needs enough working memory for the model, the current task, and its other applications. For example: a larger desk does not make you read faster, but a desk too small creates constant interruptions.

• Bandwidth is how quickly material can reach the processor. Even a fast reader waits if pages arrive one at a time through a narrow slot. Memory bandwidth describes the rate at which data moves between memory and processing hardware.

• Compute is how quickly the processor can do the calculations. More calculating power helps only when the necessary data can get there and the software can use that hardware.

Figure 1. Capacity, memory bandwidth, and compute answer different questions. A larger workspace does not automatically make the worker faster.

Storage is not working memory

Storage is your filing cabinet. A solid-state drive (SSD) holds downloaded models, documents, and applications when the computer is off. Random-access memory (RAM) is the temporary workspace used while programs run.

A large drive lets you keep more models. It does not give a running model an equally large workspace. Moving data between storage and memory can help software handle limited capacity, but it is not equivalent to having enough fast working memory.

Figure 2. Storage keeps files; RAM provides working space. A bigger filing cabinet is not a bigger desk.

The central processing unit (CPU) is the general-purpose processor that runs the operating system and ordinary applications. It can also run supported language models. A graphics processing unit (GPU) specializes in doing many calculations in parallel. Despite the name, it can accelerate more than graphics. The llama.cpp software project supports both CPU execution and GPU acceleration, including splitting work between them.[2]

You do not need to memorize processor families. You do need to distinguish the memory available to each processor.

How big is a model, really?

A language model's parameters are numerical values learned during training. You will also hear them called weights. A label such as “8B” means roughly eight billion parameters, not eight gigabytes of memory.

Training changes those values. Inference uses an already trained model to produce an answer. Running a downloaded model is inference; it is not training your own model from scratch. A computer that is suitable for one is not automatically suitable for the other.

The space weights occupy depends partly on how precisely each number is stored. Quantization reduces that precision to reduce memory requirements, while trying to preserve useful accuracy.[3] Think of retaining fewer digits in a measurement. The savings can be substantial, but the consequences depend on what was rounded and how.

Here is one transparent, deliberately simplified example:

Figure 3. Weight-only arithmetic: 8 billion parameters at 4 bits each occupy 4.0 GB, approximately 3.73 GiB, before runtime overhead.

This is weight-only arithmetic, not a recommendation for a 4 GB computer. Real quantized files include additional information; some values may remain at higher precision. Running the model also needs working buffers, space for the conversation, and memory for the operating system and other applications. The downloaded file's size is a clue, not the total memory requirement.

There is no dependable universal formula that converts a computer's advertised RAM into “the biggest model it can run.” Start with the actual model file, the application's estimate, and the intended workload.

The conversation needs room, too

A model's context is the material available to it for the current response: instructions, documents, conversation history, and generated text, within its supported limits. Text is handled in tokens, which can be words, word fragments, or punctuation.

Many language models maintain a key-value (KV) cache, a working record of intermediate calculations that avoids repeating work. That cache can consume substantial memory as context grows, although the exact behavior depends on the model and caching strategy.[4]

Figure 4. Longer context can enlarge the conversation cache while the model weights stay the same. The proportions are illustrative, not measured.

This explains a common surprise: a model works for a short question but struggles when you attach a long document. The weights have not changed. The workload has.

Do not select the maximum context setting just because the application offers it. Begin with enough for your task. A brief announcement and a lengthy teaching packet are different tests. So are one person chatting and several people making requests at once.

Two kinds of memory arrangements

A desktop with a separate graphics card usually has two relevant memory pools: ordinary system RAM and memory on the graphics card, commonly called video RAM (VRAM). 32 GB of system RAM is not the same as 32 GB of VRAM.

If a model does not fit in the graphics card's memory, supported software may put some work on the CPU instead.[2] That can make the model usable, but it is not the same performance configuration as keeping the work on the GPU.

Some computers instead have an integrated design with shared or unified memory. On Apple silicon, for example, the MLX machine-learning framework lets CPU and GPU operations access shared arrays without copying those arrays between separate memory pools.[5]

Figure 5. A separate graphics card has its own memory; a unified-memory design gives the CPU and GPU access to a shared pool.

This makes a memory-rich integrated machine worth considering when capacity is the obstacle. But advertised unified memory is not reserved entirely for your model. The operating system, display, and other applications need it too. Shared access also does not mean every integrated system has the same bandwidth or software support.

Bandwidth matters during generation because the processor repeatedly needs data from memory; cache access itself can become a bottleneck.[6] That is why two systems with similar memory capacity can feel quite different. Capacity, bandwidth, and compute belong on the same checklist, not in competition for a single winning specification.

Three labels that can mislead

“Bigger model.” More parameters are not a guarantee of better performance on your task, and they are certainly not evidence of clinical validation. Compare actual outputs, not just model sizes.

Some models use a mixture of experts: different portions of the network handle different tokens. The total parameter count describes the full model; the active count describes the portion used for a particular step. Activating fewer parameters reduces computation, but does not make the other weights vanish from the memory-planning problem.[7] Do not size a purchase using only the smaller active number.

“AI processor.” A neural processing unit (NPU) is specialized hardware for neural-network calculations. Whether your model uses it depends on the application, model, and supported software path. Hardware acceleration requires compatible software, not just a chip on the specification sheet.[8] Ask whether your intended application actually uses that NPU.

Advertised trillions of operations per second, often abbreviated TOPS, are not a directly comparable measure of how quickly your particular assistant will answer. Treat them as a hardware specification, not a reading-speed promise.

“Runs AI.” That might mean recognizing speech, generating text, or creating images. These are different workloads with different models and software. MLX's examples include all three.[5] A successful text-chat demonstration is not a benchmark for the image generator you want to use.

Which computer makes sense?

For a first experiment, an existing laptop is the sensible starting point. Choose a small model supported by your application, keep the context modest, and leave other memory-hungry applications closed. A useful small model is a better introduction than a large one that makes every interaction a waiting exercise.

Tiny computers are better treated as learning projects than default physician workstations. They are not necessarily missing graphics hardware: the Raspberry Pi 5 includes a VideoCore VII GPU.[9] The practical question remains whether your chosen model software can use the available hardware effectively. A component's presence is not a compatibility guarantee.

A dedicated desktop becomes attractive when you want a model available without tying up your daily laptop. “Always on” describes how you operate and maintain the machine, not an inherent intelligence feature of its chip. Budget attention for updates, cooling, power use, and recovery after restarts, not just the purchase.

A memory-rich unified system and a desktop with a discrete GPU solve different problems. The former may offer a useful shared-memory capacity; the latter may offer strong acceleration and a replaceable graphics card. Actual value depends on the model, software, workload, and configuration. Neither architecture wins every task.

Do not assume adding a second graphics card automatically pools its memory or doubles speed.[10] Before considering multiple cards, require explicit support and workload-specific evidence from the software you intend to use.

You can also use a small laptop as the interface to a separate local machine. In that arrangement, the other machine does the processing. LM Studio documents serving models across a local network.[1] Remote access needs authentication, access controls, and a secure connection, not an exposed public service.

Renting a remote GPU is another option, but it is cloud computing, not local execution. Even software associated with local models can offer cloud models; Ollama explicitly does.[11] Look past the application name to where the chosen model actually runs.

My local setup: an always-on Mac mini

My setup starts with a Mac mini that stays on. I think of it as an always-available home base, rather than a computer I have to open and prepare for each experiment. That is a different role from a laptop I carry around, and it is the reason to dedicate a machine before worrying about whether it has the most impressive specifications.

The important distinction is between keeping the system available and making every calculation local. An always-on computer can run a model that fits its hardware, but it can also coordinate work that uses a cloud model. Where the assistant lives and where the model runs are separate questions. I would not call a workflow fully local just because its control software runs on the mini.

For readers considering the same approach, the lesson is to separate availability from horsepower. Start with the machine's role, test the actual workload, and let demonstrated limits guide any upgrade. An always-on setup still needs updates, backups, and a recovery plan; it is not a maintenance-free appliance.

A first experiment worth doing

Before shopping, consider four things:

• The task: one repeatable example with an answer you can evaluate.

• The configuration: computer memory, graphics memory if separate, model version, quantization, and context setting.

• The experience: time before the answer starts, whether generation feels usable, and whether the rest of the computer remains responsive.

• The result: factual errors, missed instructions, and how much editing the output needs.

If it is slow, distinguish waiting from poor output. Faster hardware cannot repair an unsuitable model. If it runs out of memory, try a smaller model or shorter context before assuming you need a new machine.

Finally, local execution is not automatic privacy or authorization under the Health Insurance Portability and Accountability Act (HIPAA). Check cloud fallback, connected tools, telemetry, logs, and who can access saved material. Treat patient information and clinical deployment as a separate, governed project, not the next checkbox in installation.

The first goal is not to own the most impressive computer. It is to discover whether a model you can run and evaluate makes one ordinary piece of work easier. Buy hardware only when that experiment reveals a limitation worth paying to remove.

If you get stuck, just ask your AI for help!

Sources

[1] Offline Operation | LM Studio

[2] llama.cpp: Project documentation

[3] Overview · Hugging Face

[4] Cache strategies · Hugging Face

[5] Apple MLX: Project documentation

[6] Optimizing LLMs for Speed and Memory · Hugging Face

[7] Mistral AI: Mixtral of experts

[8] Microsoft: Develop AI applications for Copilot+ PCs

[9] Buy a Raspberry Pi 5 – Raspberry Pi

[10] llama.cpp: Using multiple GPUs

[11] Cloud - Ollama

The better question is which work would be a relief to stop coordinating by hand. Preparing for meetings. Tracking a field. Turning scattered notes into a usable first draft. Finding unfinished commitments buried across documents and conversations. Those are jobs. An agent is one way to get them done.

That distinction should drive the build. Otherwise it is easy to assemble models, connectors, and digital personalities that take more attention than the work they were supposed to remove.

Define a responsibility, build a bounded system, expand only when the results justify it

That is the mechanism. The rest of this letter is how to run it once, on real work, without inventing a second job for yourself.

First, what is an agentic stack?

For this guide, an agent is an AI system that can pursue a task through multiple steps: inspect information, choose an action, use a tool, examine the result, and continue or ask for help.

The model is the reasoning component. It is not the whole system.

The stack is everything that makes that reasoning useful:

• A place to work: the application or environment that runs the agent.

• Context: the instructions and information it needs.

• Tools: the systems it can read or change.

• A workflow: how a task moves from request to verified result.

• Controls: permissions, spending limits, records, and recovery.

You do not need to become a software engineer to understand this architecture. You do need to understand what you are authorizing.

Think of it less as buying a smarter chatbot and more as designing a small operation.

If this was forwarded, start here and subscribe for the next letter:

Practical AI

A monthly read on using AI without handing over the judgment.

By J. Travis Mendel, MD

1. Give the system one real job

Start with a task that is recurring, bounded, and easy to judge. Prefer one where an error is inconvenient rather than consequential.

A strong first project is a weekly reading brief on a topic you already understand.

It gives the agent meaningful work: gather information, compare sources, remove repetition, and explain what matters. It also gives you a reasonable way to catch mistakes.

Before choosing software, write the job description:

Each Friday, prepare a short reading brief on this topic. Use the sources I have approved. Explain what changed, why it matters, and what remains uncertain. Link to the original material. Save a draft for me. Do not publish or contact anyone.

Then define success. For example:

• The brief covers the requested period.

• The links open and support the associated claims.

• Old information is not presented as new.

• Missing information is disclosed rather than filled in.

• Reviewing the brief takes less effort than producing it yourself.

That last condition is the point. A polished output that demands extensive correction is not successful delegation.

2. Choose a home base, not an entire technology ecosystem

For the first version, choose one agent application, one capable model, and one workspace for the job.

Look for a system that lets you answer practical questions:

• Can you inspect what it did?

• Can you restrict its access?

• Can you control whether it is allowed to make changes?

• Can you export your instructions and work?

• Can you stop it and see what it costs?

Do not choose on the strength of a demonstration alone. Test it on the actual task.

For the reading brief, give it a small set of sources and ask for a draft. If the system cannot reliably distinguish a source’s findings from its own interpretation, adding more integrations will not fix the underlying problem.

Local and hosted models are options, not identities. Decide based on the task, data sensitivity, capability, cost, and what you are willing to maintain. Do not assume that something running on your computer keeps all data there. Connected tools and services may still send information elsewhere. Name data flow, retention, and training use before you connect anything that matters.

The first goal is a workflow you understand, not the most sophisticated configuration you can assemble.

3. Separate preferences, project instructions, and evidence

“Give the agent more context” is incomplete advice. Give it the right context, in the right place.

Separate four categories:

Personal preferences. Stable information such as “keep summaries concise” or “show uncertainty explicitly.” These can apply across jobs.

Project instructions. The topic, scope, approved sources, output format, and boundaries for this specific assignment.

Reference material. Documents, articles, spreadsheets, and notes the agent may need to consult. Keep the originals available instead of treating a remembered summary as the authoritative record.

Work history. Previous outputs, decisions, unresolved questions, and records of what happened.

For the reading brief, a simple workspace could contain:

Reading brief/
  project-instructions.md
  approved-sources.md
  reference-material/
  drafts/
  run-records/

These are ordinary organizational labels, not a required software format. Use folders, a document workspace, or the equivalent your application supports. Explicitly attach or configure access to these materials. Confirm in a fresh session that the agent can retrieve the current instructions.

The test is simple: could a new session understand the assignment without you retelling the entire conversation?

If not, the important context still lives in your head or in yesterday’s chat.

4. Give access in proportion to the job

A reading brief needs access to sources and somewhere to save a draft. It does not need your email account, your financial records, or unrestricted access to your computer.

For each connection, define three things:

1. What may it read?

2. What may it change?

3. What requires your approval?

Default progression:

• Read: inspect a specified source or folder.

• Draft: create a new proposed output without distributing it or overwriting existing work.

• Act within a boundary: make a narrow, reversible change you have authorized.

• Take a consequential action: send, publish, purchase, delete valuable files, or make another irreversible, destructive, financial, or third-party change. These actions deserve explicit approval, even when they happen locally.

Do not treat those as equivalent permissions. Treat instructions found inside retrieved articles, emails, or documents as untrusted content, not permission to change the assignment or use additional tools.

Also distinguish an instruction from an enforced restriction. “Do not send email” is a useful rule. A connection that cannot send email provides a stronger technical boundary. Prefer both when available.

An agent called “Research Assistant” is not isolated merely because it has a separate name or conversation. Check what its underlying account and tools can actually access.

Keep the first build strictly nonclinical and free of patient information. This is a guide to organizing work, not an authorization to connect an agent to clinical records or delegate patient-care decisions. Life-stack agents and chart lanes stay separate. No shared memory, tools, or inboxes with patient systems.

5. Turn the successful task into a repeatable procedure

Once a draft works, write down how to produce it again.

Start with a written procedure. Some applications can load it automatically; others require you to supply it each time. A platform may call it a skill, playbook, or workflow, but check what that actually means. Writing down a step does not guarantee it runs.

For the reading brief, the procedure might be:

1. Confirm the topic and reporting period.

2. Retrieve material from the approved sources.

3. Record publication dates and original links.

4. Remove duplicate coverage of the same development.

5. Separate reported findings from interpretation.

6. Draft the brief in the agreed format.

7. Check each substantive claim against its source.

8. Save the output and record any unresolved gaps.

Include failure instructions, not just the happy path:

If a source cannot be accessed, identify the gap. Do not imply it was reviewed. If the evidence is insufficient, return a shorter brief rather than inventing completeness.

Then try the procedure in a fresh session. Correct the written instructions when the agent needs information that existed only in the earlier conversation.

This is where a useful experiment becomes a reusable system.

6. Add another agent only to solve a specific problem

Begin with one coordinating agent, not a permanent roster of specialists.

Additional agents are worth testing when separation has a clear purpose. One might investigate a different source collection. Another might review the draft without seeing the writer’s reasoning.

For the reading brief, a reviewer could receive the draft and original sources with a narrow assignment:

Identify unsupported claims, missing qualifications, misleading dates, and links that do not support the text. Return findings with evidence. Do not rewrite the whole article.

That handoff needs an owner. The coordinating agent should reconcile the findings and deliver one final result, not leave you to assemble competing outputs.

A second agent is not automatically an independent authority. Two agents may share a model, sources, and blind spots. Treat their agreement as a reason to inspect the evidence, not as proof.

Create a persistent specialist only when it needs a continuing responsibility, distinct context, or genuinely different access. Otherwise, temporary help is usually the simpler design to test.

7. Schedule it only after it works without the conversation

Automation removes the moment when you would otherwise notice that the instructions are incomplete.

Before scheduling the brief, make sure the job explicitly contains or can retrieve its scope, sources, procedure, output destination, and failure rules. Check what your chosen platform actually carries between runs.

Then test more than the successful case:

• What happens when a source is unavailable?

• What happens when there is nothing new?

• What happens if the job runs twice?

• What happens if it stops after saving a partial draft?

• What happens when a cost or time limit is reached?

For this example, have the job save a draft and notify you that it is ready. Keep publication as a separate decision. Choose where failure alerts should go, and set a separate check for a missing expected output: a job that never starts cannot report its own failure. Retries should neither overwrite a good draft nor send duplicate notifications.

Not every part needs an agent. Use conventional software for predictable steps such as checking whether a file changed or creating a dated folder. Reserve model reasoning for the parts that actually need interpretation.

8. Measure the work you no longer have to do

Track a small set of practical outcomes:

• Usefulness: Did the output help with the intended job?

• Accuracy: What required correction?

• Review burden: How much attention did checking it take?

• Reliability: Did it finish, and were failures visible?

• Cost: What did each usable result cost?

The most useful unit is not cost per model response. It is cost per acceptable result, including your time.

When a workflow disappoints, inspect the cause before upgrading the model. Was the source missing? The assignment ambiguous? The permission too broad? The output never checked?

A stronger model may help. It is not a substitute for fixing the workflow.

9. Make stopping and recovery part of the design

Before the system matters to you, know how to pause it, revoke a connection, and recover its work.

Keep the instructions, reference material, and useful outputs somewhere you can export and back up. Protect backups that contain sensitive information, and test that important files can actually be restored.

Ask for a run record that shows what sources were used, what output was created, what failed, and what remains unresolved. Then open the saved draft, spot-check claims against original sources, and inspect application or tool records where available. An agent-written account is useful, but it is not proof of execution.

Periodically ask it to inspect the workflow without changing anything:

Review the instructions, permissions, recent outputs, failures, and costs you can access. Separate verified observations from recommendations. Identify unnecessary complexity and missing safeguards. Propose changes, but do not apply them.

Self-review can help you find problems. It should not give the system authority to expand its own access or become the sole judge of its reliability.

Your first build, on one page

Before adding features, fill in this short specification:

The job: What recurring responsibility are you delegating?

The inputs: What information may the agent use?

The deliverable: What exactly should exist when it finishes?

The boundary: What may it read, change, and never do?

The check: How will you know the result is correct enough to use?

The failure plan: What should happen when information, access, or time runs out?

The owner: Who reviews the result and decides whether the workflow continues?

Build that version first. Use it for real work. Expand when you can name the limitation the next feature will solve.

You do not need a digital organization chart to begin. You need a clear assignment, trustworthy inputs, bounded authority, and a result you can inspect.

The goal is not to have agents everywhere. It is to have fewer things that depend on you remembering, coordinating, and checking every step yourself, while retaining control over the decisions that matter.

Subscribe for the next letter:

Practical AI

A monthly read on using AI without handing over the judgment.

By J. Travis Mendel, MD

1. The Abundance Theory: We are approaching machine abundance. Models will become more capable, cheaper, and increasingly autonomous. They will transform knowledge work, science, education, and medicine. The transition will be profoundly disruptive and institutions that move slowly will be left behind in the short term. Eventually, there will be peace and abundance.

2. The Bubble Theory: the entire generative-AI economy is being held up by subsidies, opaque accounting, forced adoption, and promises that the technology cannot fulfill. The capital spending is too large, the revenue is too small, and the useful product underneath the marketing is far more ordinary than its owners admit.

Bill Gates has recently made the strongest mainstream version of the first argument, although with much less optimism about the transition than he expressed several years ago: https://www.gatesnotes.com/home/home-page-topic/reader/a-turbulent-ai-era-and-critical-choices-to-make

We need to notice what both stories imply for us: it is strategically reckless to let a small number of cloud vendors become the only place where our AI capability, workflows, institutional memory, and professional leverage live.

That does not mean abandoning frontier models… It means building enough physician-owned local capability that a price increase, product retirement, policy change, service outage, acquisition, market correction, or change in a vendor’s risk tolerance does not erase our ability to work. The concentration risk is real. And, the case is not weakened if Bill Gates is right. It becomes stronger.

By a local hedge, I mean retaining portable data, evaluation cases, model-independent workflows, and enough locally controlled inference capability to continue selected work if a cloud product becomes unavailable or uneconomic. It does not mean abandoning frontier models or putting patient data into an unapproved workstation.

But the hedge is limited. Local inference changes where model computation occurs; it does not settle whether the surrounding system is private, secure, compliant, reliable, clinically valid, or authorized to act.

The Uber Effect

The “it’s just business” statement I call the Uber Effect: a heavily subsidized service becomes inexpensive, useful, and woven into everyday behavior before users are asked to bear its full cost. Remember those days of $7 Uber rides? Companies have to make money eventually.

Generative AI is being scaled through extraordinary spending on chips, data centers, electricity, networking, model development, and engineering talent. At the same time, many users encounter it through low-cost subscriptions, free tiers, bundled workplace products, or features their organizations have already purchased. That arrangement can accelerate adoption, but it does not answer the long-term economic question. The unresolved question is whether the infrastructure can support a sustainable business and pay back its investors.

There are several ways that could happen.

Inference may become dramatically cheaper. Providers may find lucrative new products. Advertising or enterprise contracts may carry more of the burden. The systems may generate enough measurable productivity to justify current pricing and investment.

Another possibility is simpler: once AI is deeply embedded in how people write, code, search, document, communicate, and make decisions, providers may charge users more. Subscription prices could rise. Flat-rate access could become metered usage. Premium capabilities could move behind higher tiers. Bundled features could become separately priced. Organizations that have rebuilt workflows around a particular model may discover that switching is technically possible but operationally painful, or, in some cases, impossible.

This is not a prediction that such repricing must occur. It is a dependency risk that should be considered before dependence becomes difficult to reverse.

A tool can be genuinely useful without justifying every valuation, data center, forecast, or claim that it will replace a profession. Adoption can be real while demand is amplified by bundled products, subsidized subscriptions, executive mandates, and fear of being left behind. A model can improve on benchmarks while remaining unreliable across the long chains of action required for autonomous work.

Healthcare should understand this distinction. Medicine has spent years watching vendors turn incremental improvements into enterprise transformations. We have seen clinical software purchased on the strength of demonstrations that do not resemble production, efficiency claims that omit integration labor, and dashboards that create the appearance of control without closing the underlying loop. A technology can be genuinely useful and still be oversold.

Unreliability also compounds. A hallucinated sentence in a casual email is annoying. A fabricated citation in a clinical evidence summary is dangerous. An incorrect intermediate step inside an agent that can write files, send messages, place orders, or modify a schedule may not become visible until the action has propagated. The relevant risk is not simply the model’s average error rate. It is the combination of error rate, task length, permission scope, detectability, and consequence.

This is where the local hedge matters. The goal is not to abandon cloud models or assume that local systems will always be cheaper or better. It is to preserve a minimum viable capability, portable workflows, evaluation sets, and control over essential data so that a future price increase or change in commercial terms remains a choice rather than a crisis.

A correction in AI financing would not politely remove only the useless infrastructure. It could also disrupt access to tools that people have already built into their work. Likewise, continued success could give a small number of providers substantial pricing power over customers who can no longer leave easily.

Neither outcome is certain. Dependence is the risk. Local capability is one way to limit it.

Gates sees a different future, but arrives at the same institutional problem

Bill Gates’s essay, “A turbulent AI era—and critical choices to make,” begins from almost the opposite forecast. Gates believes AI can substitute for cognition, diffuse rapidly through interfaces people already use, and eventually operate with far less human supervision. He expects major benefits in science, education, public services, agriculture, and medicine, but now describes the transition as structurally different from prior technology shifts.

His concern is not that the industry will fail to deliver. It is that it may deliver too quickly for labor markets, governments, families, and international institutions to absorb the consequences.

Gates highlights three broad risks: permanent job displacement, empowered bad actors and potentially uncontrolled systems, and developmental or relational harm from AI companions. His proposals include national and international AI institutions, taxes on AI tokens and robots, stronger transition support, and a new category he calls Human Reserved: work or decisions that society deliberately keeps human even if a machine becomes technically capable of performing them.

For medicine, Human Reserved is the most useful idea in the essay.

The defensible boundary is not “doctors use AI” versus “doctors do not use AI.” It is not even “human in the loop,” a phrase that can mean anything from meaningful review to ceremonial clicking.

The better boundary is authority.

AI can retrieve evidence, prepare a differential, monitor symptoms, draft documentation, compare plans, identify missing data, and coordinate routine steps. A named clinician should still own goals, exceptions, informed consent, the communication of irreversible consequences, and final responsibility for high-stakes decisions.

Gates supplies the ethical half of the architecture. These are two different forms of independence: local infrastructure preserves operational control, while Human Reserved preserves clinical authority. Regardless, leaving the future to the incentives of AI companies is not a plan.

Postulating a potential 2027 outcome

Imagine that the current pace of AI infrastructure spending continues while revenue grows more slowly than expected. Investors become less willing to finance losses indefinitely. Cloud providers, model companies, and application vendors then face pressure to turn adoption into durable profit.

The result would not have to be a dramatic collapse. It could look more ordinary: consolidation, canceled projects, smaller free tiers, higher subscription prices, stricter rate limits, metered usage, model retirements, or vendors concentrating on their most profitable customers. Some services would survive and improve. Others would become more expensive, change direction, or disappear.

That possibility matters because many products that appear independent rely on the same small group of model providers, cloud platforms, and chip suppliers. A physician may interact with several different AI applications while still depending on the same underlying model or infrastructure. If commercial terms change at the foundation, the effects can propagate through every product built on top of it.

Healthcare organizations would not need a major AI company to fail for a workflow to break.

Any of the following could be enough:

• A favored model is retired or materially changed;

• subscription pricing is replaced by metered usage;

• rate limits tighten;

• a vendor is acquired or stops prioritizing healthcare;

• regulators or institutional counsel restrict a data flow;

• an application programming interface changes;

• a cloud outage interrupts access; or

• the organization discovers that its workflow cannot be exported.

This is familiar vendor risk, but amplified by concentration and by the speed at which AI is being embedded into daily work. The more deeply a system is integrated into documentation, research, communication, coding, or decision support, the more costly it becomes to replace. Dependence can accumulate long before anyone formally decides that the product is indispensable.

A local hedge does not prevent this scenario, and it does not require abandoning cloud services. It changes the consequences. If an organization retains its source data, evaluation cases, workflow definitions, audit history, and a slower but functional local inference option, a vendor change becomes an operational problem that can be managed. If it retains only a login and a collection of screenshots, the same change can become a crisis.

The practical question is therefore not, “Will the AI market break in 2027?” Nobody knows. The better question is, “If access, pricing, or product availability changed in 2027, what would we still possess and what could we still run?”

That is the value of the scenario. It does not tell us what will happen. It reveals whether we are building capability or merely renting access.

The false binary physicians should reject

The public debate asks us to choose between two futures:

1. The bubble bursts. Capital retreats, model companies consolidate, services become more expensive, and some products disappear.

2. Capability accelerates. AI becomes embedded throughout professional work, increasingly agentic, and more consequential.

Local infrastructure has value in both.

If the bubble bursts, local models preserve a usable floor. Open weights, local runtimes, downloaded documentation, evaluation sets, and physician-owned workflows do not guarantee independence, but they reduce the chance that one vendor decision can switch everything off.

If capability accelerates, local infrastructure gives clinicians and institutions a controlled place to test, measure, adapt, and govern that capability before handing it authority. It creates bargaining power.

If neither extreme occurs and the current mixed environment persists, local systems still provide value for bounded, high-volume, privacy-sensitive, or latency-sensitive work.

This is what a hedge means. It is not a prediction. It is a position that remains useful across multiple plausible futures.

Figure 1. The local-infrastructure hedge

The practical conclusion

I do not know whether AI infrastructure will undergo a correction, achieve sustainable abundance, or settle somewhere between those outcomes. I do know that physicians should not allow access to their workflows, institutional knowledge, and professional leverage to depend entirely on the commercial decisions of a few companies.

The first step is not buying the largest machine available. It is identifying what we need to preserve: our data, evaluations, workflows, decision rights, and a minimum viable ability to run selected tasks without a particular vendor.

This is Practical AI.

Selected primary sources

• Bill Gates: “A turbulent AI era—and critical choices to make”

• Microsoft FY2026 Q4 earnings: cloud and AI investment

• Amazon Q2 2026 results: increased infrastructure investment primarily reflecting AI

• UK Competition and Markets Authority: Cloud Services Market Investigation, final decision

Healthcare AI is no longer confined to predicting a risk score or drafting a note.

The next generation of systems can retrieve a chart, summarize years of records, identify missing information, propose a plan, call other software tools, and initiate work across clinical, administrative, and financial systems. Oracle, for example, publicly describes a Clinical AI Agent product direction spanning chart review, documentation, coding, scheduling, draft orders, follow-up, and prior-authorization workflows; Oracle cautions that some described features are planned, may change, and are not all currently offered.[1]

The potential is broader than documentation.

Used well, these systems can reduce clerical work, expose information buried across fragmented records, help clinicians prepare for complex visits, match patients to trials, identify omissions, and give physicians more time for the part of medicine that cannot be automated: judgment, explanation, and human presence.

Used poorly, the same systems can amplify stale chart errors, obscure where patient data traveled, produce a persuasive answer without a trustworthy basis, and move a mistake through the healthcare system faster than a person could.

That is the central regulatory problem. We are not simply introducing a new medical device. We are introducing a class of systems whose behavior depends on the model, the prompt, the data retrieved, the tools connected, the workflow, the user, and the environment in which the output is acted upon.

AI capability and deployment are accelerating. New model releases, prompts, retrieval systems, and connected tools can alter behavior on software timelines. Policy and regulation cannot keep pace with that iteration cycle, and there is no realistic reason to expect them to. They require evidence gathering, public process, legal authority, and implementation. That mismatch is structural, not a temporary failure of regulators.

The answer is not weaker regulation. Regulation should establish an enforceable floor. Physician education and institutional governance must operate in the gap, at the speed of deployment.

The Food and Drug Administration has started asking the right questions

On August 18, 2026, the U.S. Food and Drug Administration (FDA) released Considerations for the Regulation of Generative AI-Enabled Medical Devices: Discussion Paper and Request for Feedback. Comments are due October 19, 2026, under docket FDA-2026-N-7874.[2]

The legal status matters. This is not a proposed rule or draft guidance, and it creates no new regulatory requirement. FDA is seeking early feedback on possible approaches to generative-AI-enabled medical devices without deciding whether those approaches fit within its existing legal authority or would require new authority.[2][3]

The paper’s most useful idea is that risk should not be defined by the label “AI.” It should be defined by what the final product actually does.

A system that retrieves source-linked medical literature is not the same as a system that recommends a patient-specific treatment. A tool that drafts an order for review is not the same as one that places the order. A note generator is not the same as an autonomous agent controlling another device.

The paper explores a possible risk framework with two broad dimensions: how independently the device function acts and the consequences of relying on an incorrect output. Under that possible framework, evidence and controls could increase as a function moves from supplying information to directing action, taking action under supervision, or operating autonomously, and as the consequence of error rises. A flawed scheduling suggestion and a flawed dose calculation do not belong in the same category.[3]

That is a sensible start.

The FDA also recognizes that traditional validation is not enough. A conventional prediction model can often be tested against a defined input set and measured with sensitivity, specificity, calibration, or another bounded metric. A generative system can accept open-ended language, produce different responses to equivalent questions, change behavior across a long conversation, retrieve external information, and act through connected tools.

Exhaustively testing every possible interaction is not practical.

The FDA’s Center for Devices and Radiological Health (CDRH) is therefore considering a competency-based approach that would combine non-clinical device benchmarking with clinical confirmation in real or clinically representative use. Possible methods discussed in the paper include adversarial testing, retrospective evaluation, specialist adjudication, standardized-patient interactions, silent shadow deployment in which outputs cannot affect care, and prospective studies when warranted by risk.[3]

The paper also treats post-deployment monitoring as a central question. Prompts change. Retrieval systems change. Guardrails change. The upstream general-purpose model may change. New tools are connected. A product that was safe at authorization can become meaningfully different without changing its name or interface.

Under the existing statutory and authorization framework, a manufacturer may implement certain planned modifications covered by an FDA-authorized predetermined change control plan (PCCP) without obtaining separate authorization for each modification; FDA’s final PCCP guidance provides nonbinding recommendations for such plans.[4] Generative AI complicates that framework because some important changes may originate upstream or emerge from interactions among several components.

The questions physicians should ask now

Physicians do not need to become software engineers. They do need enough technical fluency to understand how an AI system changes the clinical workflow and which questions affect patient safety:

• What is the intended use? What is the system designed to do, and what is explicitly outside scope?

• What information does it use? Which chart fields, notes, images, audio, external sources, and inferred data enter the workflow?

• Where does the information go? Which vendors, downstream service providers, regions, logs, memories, retrieval stores, and backups receive a copy?

• How was it validated here? Was the actual configuration tested in the local workflow, patient population, specialty, and clinical language?

• Can the physician inspect the basis? Are claims linked to source records, or does the system return a polished conclusion without provenance?

• What happens when the system is uncertain or wrong? Does it defer, stop safely, request missing information, or continue confidently?

• What can it do without confirmation? Can it write, order, send, schedule, code, bill, or contact a patient?

• How is change controlled? Are model, prompt, retrieval, tool, and interface versions recorded and revalidated?

• How is performance monitored? Who reviews failures, what thresholds trigger rollback, and can the system be shut down quickly?

• Who remains accountable? The answer cannot be “the AI.”

These questions are useful now because product deployment is already occurring while formal policy remains under development.

Why AI regulation is uniquely difficult

The FDA’s direction is promising, but healthcare AI does not fit neatly inside the regulatory structures built for static products.

1. The same model can occupy several regulatory categories

A foundation model is not regulated as a medical device merely because it is a foundation model. FDA’s discussion focuses on the final user-facing device function, including its intended use, configuration, and behavior, rather than on the foundation model standing alone.[3]

That distinction is essential. The same model could summarize a meeting, retrieve trial criteria, draft a patient message, recommend a diagnosis, calculate a treatment parameter, or execute an order. The risk does not come from the model name. It comes from the clinical function, the data, the degree of autonomy, and whether a qualified person can independently evaluate the basis.

FDA’s clinical decision-support guidance reflects the same principle. To qualify for the statutory non-device clinical decision support (CDS) exclusion, a software function must satisfy all four criteria in section 520(o)(1)(E) of the Federal Food, Drug, and Cosmetic Act (FD&C Act), including enabling a healthcare professional to independently review the basis of the recommendation rather than rely primarily on the software’s conclusion.[5]

A disclaimer does not create independent review. Neither does an “approve” button.

2. “Human in the loop” is not a sufficient safety claim

Human oversight is often treated as a binary property: either a physician clicks approve or the system acts autonomously.

That is too crude.

A physician cannot provide meaningful oversight if the source is hidden, the workflow is time-pressured, the reasoning cannot be reconstructed, or the interface makes verification slower than accepting the answer. In clinical practice, source review is not a theoretical safeguard. A fluent summary can produce more confidence than the underlying evidence deserves.

Clinical records make this especially important. The electronic health record (EHR) is not a clean representation of truth. It contains old problem-list entries, copied-forward notes, billing labels, conflicting histories, and conclusions written before later testing changed the diagnosis. An AI system that is “grounded in the chart” may still be grounded in the wrong part of the chart.

Real human oversight means review of the source, not merely review of the summary.

A published ambient-AI governance report illustrates how sensitive these systems can be to workflow changes: a documentation-template change was associated with International Classification of Diseases, Tenth Revision (ICD-10) documentation accuracy falling from 79% to 35% before redesign and user training restored performance.[6] The lesson is not that ambient AI is unsafe. It is that implementation, monitoring, and clinician education are part of the safety case.

3. Medical-device regulation does not cover the entire problem

FDA regulates device functions. It does not, by itself, answer every question about privacy, data residency, contracting, cybersecurity, professional accountability, or the quality of the underlying medical record.

The Health Insurance Portability and Accountability Act (HIPAA) requires covered entities and business associates to protect electronic protected health information with appropriate safeguards and contractual arrangements.[7] The Office of the National Coordinator for Health Information Technology (ONC) adds transparency expectations for certain predictive decision-support interventions in certified health information technology through its Health Data, Technology, and Interoperability final rule (HTI-1).[8]

Those are important layers. They are not a complete governance system for agentic clinical AI.

A business associate agreement does not tell a patient which copies of an encounter exist, how long audio or transcripts remain, whether a searchable memory persists, which downstream vendor handled the information, or whether optional tools fall inside the contracted environment.

One unusually transparent example comes from the Department of Veterans Affairs. Its privacy assessment for an Abridge ambient-scribe deployment describes audio and note data moving through Abridge’s Google Cloud environment, the clinician reviewing the draft before it enters the Veterans Health Information Systems and Technology Architecture (VistA), and the original vendor-held audio and written notes being deleted after a period of up to 30 days.[9]

A 2025 review found that residual re-identification risk in de-identified clinical free text is difficult to quantify, while concluding that properly de-identified text held in secure environments can carry very low risk.[10] De-identification is therefore a meaningful control, but not a substitute for understanding access, retention, and use.

That does not make cloud processing inherently unsafe. It demonstrates the level of specificity that should be normal.

“HIPAA-compliant” is not a data-flow diagram.

The transformation is larger than documentation

Ambient documentation is the entry point because it offers an obvious benefit: less time typing and more attention available for the patient. It is not the endpoint.

Healthcare AI is moving from systems that generate text to systems that coordinate work. An agent may retrieve results, compare prior notes, check a formulary, draft an order, prepare a prior authorization, send a message, or trigger another system. Every additional tool expands both capability and consequence.

A scribe can write the wrong sentence. An agent can use the wrong sentence to take the next step.

Properly designed AI could help clinicians navigate fragmented records, identify missing staging information, screen trial criteria, and detect when recommended follow-up never occurred. The governance question is whether that speed and scale can expand without making accountability less visible.

What regulation can address, and what it cannot

Formal regulation can establish requirements that the market may not produce consistently on its own.

It can tie evidence to the consequence of error, define expectations for change control and postmarket monitoring, and clarify responsibility when an upstream model or connected tool changes. It can also distinguish meaningful human review from a nominal approval step.

At the same time, every regulatory design involves tradeoffs.

If evidentiary requirements are not proportionate to risk, smaller clinical builders and independent practices may face costs that only large vendors can absorb. If requirements are too permissive, clinically important changes may reach patients without adequate revalidation. A framework focused only on foundation models may miss the final clinical function, while one focused only on premarket performance may miss workflow drift after deployment.

Architecture labels do not resolve the problem. Local deployment can improve control over versions and data, but it does not guarantee good security or validation. Cloud deployment can create additional data and vendor boundaries, but it can also operate under mature controls. The relevant evidence concerns the actual configuration, data flow, access, retention, validation, and monitoring.

Timing creates another constraint. Health systems are already adopting these tools while capabilities accelerate and the regulatory framework is still being developed. That gap cannot be closed by faster rulemaking alone. Formal oversight will therefore shape both new products and workflows that may already be installed.

These tensions explain why regulation is necessary but unlikely to function as the only near-term safety mechanism.

Why physician education matters during the transition

The same technical fluency belongs across the institution. Procurement teams encounter model and downstream-vendor boundaries. Privacy officers need retention schedules for each kind of data, not only general assurances. Clinical leaders need measures of human-AI team performance rather than adoption alone. Patients need a meaningful explanation of what the system does and how it affects their care.

Public vendor documentation already shows why product-specific diligence matters. Retention and improvement terms differ across ambient systems, and customer contracts may govern clinical data differently from public website policies.[9][11][12] The useful distinction is not trust versus fear. It is whether the architecture and terms for the exact deployed feature are visible enough to evaluate.

Four workstreams now developing in parallel

The current debate is not limited to one regulator or one technical standard. It spans four connected workstreams.

Questions for regulators

• How should oversight follow the final clinical function rather than the general label “AI”?

• How should evidence scale with autonomy, consequence, reversibility, traceability, and time available for review?

• Which model, prompt, retrieval, tool, and version changes require documentation, revalidation, or a new submission?

• How should accountability be divided between the final-product manufacturer and an upstream foundation-model provider?

Questions for health systems

• Is there a feature-specific data-flow map for the exact product being deployed?

• Has the actual configuration been evaluated in the local clinical workflow rather than only in a vendor demonstration?

• Can clinicians inspect source-linked evidence before orders, messages, prescriptions, billing, or record changes occur?

• Who owns ongoing sampling, incident review, rollback criteria, and shutdown authority?

Questions for developers

• Are uncertainty, missing information, and conflicting source data visible to the user?

• Can clinicians reconstruct the provenance of a clinically important claim?

• Are prompts, retrieval data, tools, and model versions treated as controlled configuration?

• Is evaluation measuring the human-AI team as well as the model in isolation?

Questions for physicians

• Is the output being treated as a draft or as unquestioned chart truth?

• Can the underlying source be checked before the output influences care?

• Where does patient data go, how long does it remain, and can it be used for product improvement?

• Are clinicians involved in validation, procurement, and post-deployment review?

The FDA is explicitly inviting comments from clinicians and researchers, not only manufacturers. The open docket gives physicians an opportunity to describe real workflow tradeoffs involving traceability, reversibility, review time, specialist use, shadow deployment, and the burden of ongoing monitoring. The comment period closes October 19, 2026.[2]

The emerging standard is informed accountability

The FDA’s discussion paper recognizes that existing evaluation methods may not be sufficient for generative and agentic systems and explores possible adaptations in evidence, monitoring, change control, and human oversight. Formal policy is still being designed while adoption is underway.

Education can be implemented faster than formal rulemaking, but it cannot create enforceable minimum standards. Regulation can create those standards, but it cannot substitute for local workflow knowledge or informed use.

Durable trust will therefore depend on how regulation, institutional governance, engineering controls, and physician education operate together.

When AI enters the exam room, the system should be visible enough to understand, bounded enough to supervise, monitored well enough to detect change, and connected to people who remain accountable for the care delivered with it.

Regulatory note: This article is an analysis of emerging policy, not legal advice. Device status and compliance obligations depend on the product’s intended use, design, deployment, contracts, jurisdiction, and actual clinical workflow.

Sources

1. Oracle Health Clinical AI Agent

2. U.S. Food and Drug Administration: Considerations for the Regulation of Generative AI-Enabled Medical Devices

3. U.S. Food and Drug Administration Generative AI-Enabled Medical Devices Discussion Paper

4. U.S. Food and Drug Administration Predetermined Change Control Plan Guidance

5. U.S. Food and Drug Administration Clinical Decision Support Software Guidance

6. Afshar et al.: A Novel Playbook for Pragmatic Trial Operations to Monitor and Evaluate Ambient Artificial Intelligence in Clinical Practice

7. U.S. Department of Health and Human Services: HIPAA Security Rule Summary

8. Office of the National Coordinator for Health Information Technology: HTI-1 Final Rule

9. Department of Veterans Affairs Abridge Ambient Scribe Privacy Impact Assessment

10. Ford et al.: Re-identification Risk from De-identified Clinical Free Text

11. Suki Security Frequently Asked Questions

12. Microsoft Dragon Copilot Frequently Asked Questions

That distinction matters in the clinic because fluent output can still be wrong, and the person who signs the note still owns the result. Most writing about these tools comes from people who never sign a clinical note or run around in a clinic every day.

What is a large language model?

A large language model is a neural network trained on massive amounts of text to predict and generate human-like language. It can answer questions, draft prose, and help with reasoning tasks. It is still doing prediction at the core.

ChatGPT, Claude, Gemini, and the rest wrap that engine in a product layer: tools, retrieval, memory, connectors, retention settings. The product can look up sources. The base model still predicts.

Search finds documents. Generation writes new sentences that sound like documents. Ask a product without retrieval to summarize a guideline you did not paste, and you are not getting a lookup. You are getting a fluent reconstruction from training. That can produce a clean-looking citation that was not the paper you thought you were reading. Check the sources before anything consequential leaves the desk.

A few terms that change how you use it

Tokens are the billed chunks. The context window is working memory for a turn. If the note, the guideline, or the lab values are not in that window, the model is guessing from training, not from your case. Paste what matters for the task. Keep identifiers out of consumer tools. More relevant detail usually helps. Too much irrelevant detail can also confuse the model and raise the chance of fluent error.

Training is the frozen school period, including a cutoff date. Inference is what happens when you hit send. The model does not learn from yesterday’s chat unless you put that material back into the window or the product has a separate memory feature you have actually turned on and reviewed.

A useful prompt is a work order: task, context, constraints, format, and sources to use. “What do I do next” is not a work order. “Draft a one-page patient explanation of adjuvant endocrine therapy for a breast clinic visit, eighth-grade reading level, no dosing, cite the pasted NCCN excerpt” is a work order. Then check the output against the source you named and against what you know. Stay in the loop.

Hallucination and ownership

Hallucination is fluent, confident error: an invented cite, a misread cite, an answer filled in where knowledge is thin, or a reasoning slip that still sounds finished. Better models and better products reduce some of that, and the pace of improvement is real. They do not remove ownership.

Layered controls help:

• retrieve or paste the source

• constrain the task

• require citations you can open

• keep a human verification step for consequential work

Machine learning learns from data. Deep learning is a thick stack of that, with a very large number of parameters and behavior that is hard to inspect end to end. Generative systems make new text or images. An LLM is the text engine. An agent can take steps across tools, not only answer. Useful still does not mean autonomous.

Keep clinic and personal systems from sharing data, tools, or memory.

Practical rule: treat the model like a supervised resident. Let it draft. You verify the source. You decide. Fluency does not transfer authority.

Start with the four questions before a tool touches a patient or a chart:

https://www.practicalaiforphysicians.com/p/automate-the-work-keep-the-judgment

This is how to use it without getting sloppy. The same preflight still applies before any tool touches a chart: https://www.practicalaiforphysicians.com/p/automate-the-work-keep-the-judgment

Ask a real question

Put the specialty, the setting, and what you want back. “Prostate cancer, community clinic, what does the guideline actually say about the next scan interval” will beat “what do I do next.”

You get a better answer when you ask the question you would ask a colleague in the hallway. But it is not your colleague. So, give it context!

Keep an eye on the citations

Every answer is supposed to sit on peer-reviewed sources. Check them.

The product is the source list, not the summary. Treat the citations as the work product and the prose as a draft index.

Do not paste the chart

As of April 2025 they will sign a BAA and they say you can put PHI in. That does not mean you should dump in all the patient’s information. You almost never need a name, an MRN, or a date of birth to get a useful answer.

Ask the clinical question. Leave the identifiers out. If you do put PHI in, you are on their BAA, and that is a contract you should have actually read. Not all BAAs are the same. A signed BAA also does not mean you and the patient are fully protected.

Watch the Share button

Threads are private by default. Share can email a conversation or make a public link. Never make a public link if any patient detail is in that thread.

CME is extra, not the point

If you are NPI verified, you can turn a question you already asked into free CME or CE, but only after you finish the reflection. The search alone is not the credit. Do not let the credit change what you ask.

If it saves you a hunt through PubMed and you still check the source, keep it. If you are copying the answer into the note unread, turn it off.

You are the provider.

You are here for a preflight check you can run before a tool touches a patient or a chart. Most writing about these tools comes from people who do not sign the note.

What this is

This is not clinical decision support. It is not a vendor roundup. It is not an argument that AI will replace you. It is four questions.

Do not let a tool near a patient or a chart until you can answer them.

1. Who can see the data, and where does it go?

If audio, a note, or a chart leaves the office, name who receives it and where it sits. A public consumer chatbot is a third party you did not contract, on servers you do not control, with a retention story you often cannot verify.

Prefer the lowest-exposure option that still fits the job: a local or self-hosted model when the workflow and hardware support it, or a governed vendor product when the contract, tier, connectors, and retention have been checked for this use. When a vendor must handle ePHI, a BAA is necessary for that arrangement. A BAA is a contract, not a privacy sticker. It does not by itself validate the clinical workflow. If you cannot name the destination, keep the tool off that data.

2. Has it been validated for the specific clinical task?

A demo is not validation. “Works for documentation” is not the same as evidence for this note type, in this specialty, in this EHR, against this template.

If a vendor claims ambient capture of a follow-up visit, ask for evidence on that task, not a staged new-patient video from another specialty or an integration you do not have. Until you have that, treat the output as untested draft language.

3. Can its outputs be audited and traced?

If you cannot show where a sentence came from, do not file it. The model drafts. Point to the transcript, the report, the policy line, or the lab. A clean paragraph with no trail is a guess you will have to defend later.

No trail, no tool.

4. Does it reduce cognitive load rather than add to it?

A draft that forces three extra screens, or a message you still rewrite and then re-file into a second inbox, has not helped. The test is whether the person who already owns the step is lighter after the draft. If the tool adds load, turn it off for that workflow.

Practical rule

Treat these systems like a supervised resident: fast, fluent, sometimes confidently wrong. Let it draft. You verify the source. You decide. Diagnosis, treatment decisions, final consent, dose, and plan sign-off stay with the clinician.

Fluency does not transfer authority.

You are the provider.