STL AIby The Rescue Team
← All guides

Responsible AI

A small-business AI pilot checklist: people, data, and a clear stop button

The short answer

Before a pilot starts, name its owner, limit the information it can access, decide who reviews results, and define when to stop. Test with approved sample data before using live customer information. A useful pilot measures errors and review effort as well as speed.

Give the pilot one job and one owner

An AI trial should answer a business question: can this workflow reduce effort while maintaining an acceptable result? ‘Let everyone try AI’ is too broad to evaluate. Choose one task, such as turning approved internal notes into a draft checklist, and name the person responsible for the trial.

Write down who uses it, who reviews the output, and who can pause it. A small St. Louis business does not need a large committee for every experiment, but it does need clear accountability. The owner should understand the existing process well enough to recognize a plausible-looking but incorrect result.

Draw the information boundary

List the inputs the task actually needs. Start with invented examples or approved material rather than uploading a customer folder. Check the provider's current terms, retention controls, account permissions, and data-use settings before sharing business information. A paid subscription alone does not tell you what those settings are.

Keep credentials, payment data, and sensitive employee or customer records outside an ordinary first pilot. If the work requires regulated or confidential material, get a qualified review of the specific setup before proceeding. This checklist is operational planning guidance, not a compliance certification.

Separate drafting from taking action

For the initial trial, let the system suggest an answer without sending it. Have a person verify names, dates, amounts, commitments, and source material. Give the system only the access it needs; an assistant that drafts a reply does not need permission to delete records or change account settings.

NIST's AI Risk Management Framework is voluntary guidance for incorporating trustworthiness into AI design, use, and evaluation. Its generative-AI profile addresses risks specific to generative systems. Use those resources as a starting point for questions about your workflow, not as proof that a particular tool or deployment is safe.

Source: NIST: AI Risk Management Framework and generative-AI profile

Test normal, incomplete, and misleading inputs

Create a small test set before the demonstration. Include routine examples, missing information, conflicting details, and requests outside the intended task. For a document assistant, include a question the documents cannot answer. A useful result may be an honest request for clarification rather than a confident guess.

Also test text that tries to redirect the assistant—for example, an incoming message asking it to ignore its instructions or reveal unrelated information. Treat customer messages and uploaded documents as untrusted input. Do not rely on a written prompt alone to enforce permissions or stop an unauthorized action.

Define a go-or-stop review

Agree on the criteria before looking at results. Your checklist should include:

  • Baseline time per task, including the current checking process.
  • Trial time per task, including edits and exception handling.
  • An error log showing what went wrong and how serious it was.
  • A named reviewer and an acceptable review workload.
  • A way to disable the workflow and preserve the manual process.
  • A decision date and a record of what would justify wider use.

Finish with instructions your team can use

Document approved inputs, prohibited information, review steps, and escalation contacts in plain language. Show staff an example of a good result and an example that must be rejected. Make it easy to report a problem without treating the report as a failure by the employee.

Only expand after the trial answers the original question. New data sources, new users, and permission to take actions change the risk. Review those changes explicitly instead of assuming a successful draft-only experiment proves the next version is ready.