“Local AI” can describe very different products. One system may run a model on a computer in your office. Another may keep business files locally while sending selected text to a cloud model. A third may be a cloud service with a desktop application. The label alone does not tell a buyer where information goes, who owns the operating knowledge, or what the system can do in connected accounts.

This reader's checklist helps United States small-business owners compare claims without requiring them to become machine-learning specialists. It complements the plain-English approach in *Your Computer Is About to Wake Up*: begin with the work, ask for a visible data path, and separate useful assistance from unreviewed authority. For an implemented project, Local AI Developer offers scoped business-owned systems; the Orange County AI automation page describes the regional service cluster within a nationwide offering.

Start with the business task

Ask each seller or builder to describe one specific workflow using the same structure: start event, approved sources, prepared output, reviewer, destination, excluded actions, and fallback. A broad demonstration of chatting, searching, or generating text cannot answer whether the proposed system fits your operating handoff.

Use an example your team recognizes. It might be preparing an internal intake brief, assembling an order-status summary, or organizing a project update. Remove information you are not authorized to share during an early evaluation.

Compare proposals against that same bounded task. Otherwise, one option may appear stronger because it demonstrates a different and easier problem. Product breadth is not evidence that your sources, review path, and exceptions will work.

Ask what actually runs locally

Break “local” into components. Ask where the model runs, where source files are stored, where readable instructions live, where indexes or derived data are kept, where outputs are written, and where logs are retained.

A dedicated computer can keep important business assets under company control while still using approved cloud services for some work. That can be a valid design, but it should be stated plainly. “Runs on your Mac” does not prove that no task information leaves the machine.

Ask what stops working without internet access. Test the answer rather than relying on a diagram. A locally stored instruction set may remain readable while model calls, email access, or cloud document retrieval become unavailable. The fallback should reflect the real dependency.

Draw the data path

Request a simple path for each information type: source, local processing, model or service, temporary storage, output, review destination, logs, and backup. Name providers and account owners when known. Mark unknowns for resolution rather than filling them with reassuring language.

Distinguish original files from excerpts, prompts, embeddings or indexes, generated drafts, operational metadata, and diagnostic records. Each can have a different location and retention rule.

Ask which fields the workflow truly needs. A useful design should explain why each category is included and which information is excluded, redacted, or transformed before processing. Collecting everything “in case it helps” is not a scope.

Verify ownership in practical terms

“You own your AI” should lead to inspectable answers. Can the business read the operating instructions? Can an authorized backup identify source locations, output formats, hold rules, and review steps? Are business records stored in organization-controlled locations? Can the company remove a vendor's access without losing the process description?

Ownership does not require every software component to be custom or open source. It requires clarity about what belongs to the business, what is licensed, what depends on a provider, and what can be exported or recreated.

Ask what happens if the builder is unavailable. A useful handoff should identify the active version, approved connections, recovery contacts, manual fallback, and steps for another qualified person to understand the bounded workflow.

Separate model ability from tool authority

A model may be able to draft an email, but sending requires access to an account and an approved action path. It may summarize an order record, but changing delivery status is a separate permission. Ask for a list of connected tools and the exact read, write, send, publish, delete, purchase, or permission-changing actions available through each.

Compare what the system can prepare with what it can execute. Look for distinct states such as draft ready, approved, sent, failed, and reconciled. A human review screen has little value if the system can bypass it through another connection.

Ask how instructions arriving inside source material are treated. An email, document, or webpage may contain text that sounds like a command. Source content should not silently expand the workflow's authority or change its account permissions.

Examine the human approval boundary

Replace “human in the loop” with operational questions. Who reviews? Where does the item wait? What evidence can the reviewer inspect? Which version is being approved? What happens when the reviewer is absent? Does editing count as approval? How is an unsuccessful external action reported?

For consequential actions, ask whether the approver's identity and time are recorded. Material changes after approval should normally return the item to review rather than inheriting an old decision.

Check that manual fallback retains the important boundary. An outage should not force staff to use personal accounts, skip source verification, or send an unreviewed draft simply to keep the process moving.

Demand examples of uncertainty

Fluent output is easy to demonstrate with a clean example. Ask to see behavior when a required field is missing, two sources conflict, a document is stale, the same item arrives twice, or a connected service fails after output creation.

The useful result may be a visible hold with a reason, owner, and next action. A system that always produces a confident answer can be less dependable than one that exposes the limits of its evidence.

Ask how source references are preserved. Depending on the workflow, that may mean record identifiers, message links, filenames and versions, retrieval times, or short supporting excerpts. The reviewer should be able to challenge important claims without repeating the entire search.

Compare maintenance, not just setup

Every operating workflow has changing parts: staff, source locations, permissions, templates, software, models, and connected services. Ask who updates each part, how changes are approved, and what tests run before a revised version becomes active.

Request a description of routine support and exclusions. “Managed” could mean monitoring one scheduled process, applying approved updates, answering questions, or rebuilding broken integrations. The proposal should state what is included rather than leaving maintenance implied.

Ask how the system is retired. The answer should cover preserving required business records and readable instructions, removing obsolete connections, revoking support access, and verifying that scheduled work has stopped.

Evaluate hardware claims carefully

Hardware recommendations should follow the workflow. Ask which tasks require the proposed memory, storage, or processing capacity; how many workflows run concurrently; what information needs local storage; and how growth would be handled.

Do not treat a particular computer as proof of privacy, reliability, or fit. Those qualities depend on the full configuration, accounts, permissions, data path, backups, operating ownership, and testing.

Ask where the computer will be placed, who administers it, how updates and restarts are handled, and how work continues during interruption. A purchase list without an operating plan is incomplete.

Read outcome claims with discipline

Separate demonstrated workflow behavior from estimates and business outcomes. A test can show that a system prepared required fields from approved examples and placed the result in a review queue. It cannot by itself prove future revenue, rankings, labor savings, or error reduction.

If a proposal includes an estimate, ask for the assumptions, baseline, measurement period, and owner of the underlying records. Do not accept a generated activity count as a verified customer outcome.

References and testimonials may be useful, but they do not replace acceptance criteria for your task. Your team still needs representative cases, prohibited-action tests, and a launch decision based on observed evidence.

Use a side-by-side comparison record

For each option, write concise answers to:

Mark each answer as verified, documented but untested, unknown, or outside scope. Unknown is useful because it identifies the next question without pretending the issue is settled.

Choose the clearest operating commitment

The best proposal is not necessarily the one with the longest feature list or the strongest “local” label. Prefer the option that can describe its boundary, show its evidence, name its owners, and test its failure behavior for the task your business actually needs.

Keep the comparison record with the purchase decision. It becomes a reference when implementation details change or additional workflows are proposed. If you want to turn one completed comparison into a build scope, start a Local AI Developer inquiry with the bounded task and any sanitized examples. A precise conversation is more valuable than a promise that one architecture solves every business problem.