As a founder without a technical background, you do not need to start by choosing a model or hiring an AI team. Start with a business decision: which recurring problem is worth solving, and what would a better result look like to a customer or colleague?
Your responsibility is to make priorities clear and obtain help where you cannot assess the risks. Years of experience in another field can help you spot weak assumptions. It does not mean you should personally approve software security or rely on a polished demonstration as proof that a system works.
Write down three problems before considering products
Choose specific problems from your own operation. “Staff spend time finding approved answers” is more useful than “we need AI.” For each problem, record who experiences it, how often it happens, what the current process costs, and how an error affects someone.
Ask the people doing the work to show recent examples with sensitive details removed. You may discover that the obstacle is missing information, contradictory policy, or unclear responsibility. Software cannot reliably answer a question the business itself has not resolved.
The NIST AI RMF Playbook’s Manage section explicitly treats proceeding with an AI system as a decision to evaluate, not a foregone conclusion. Its voluntary guidance weighs risks and benefits against the intended purpose. Use that principle to allow a genuine “not now” outcome.
Put each proposal into one of four groups
- Fix the process first: information is missing, rules conflict, or nobody owns the result.
- Use ordinary software: a form, filter, calculation, or fixed rule can reliably handle the task.
- Test an existing AI product: the task involves drafting or interpreting material, and someone can check the result.
- Investigate custom development: a valuable need remains unmet and you can fund qualified development and maintenance.
These are practical sorting questions, not a universal ranking of technologies. A custom system may be justified, but “our business is unique” is not enough. Identify the exact requirement existing products fail to meet and the evidence that customers or staff need it.
Prioritize tasks you can evaluate
A first test should have clear inputs, a recognizable good answer, manageable consequences, and someone available to review it. Drafting an internal summary from approved documents may fit. Automatically deciding refunds, employee suitability, medical issues, or financial eligibility brings more consequential risks and needs specialist assessment.
Consider a fictional founder choosing between two projects. One prepares a draft response from a current return policy; the other predicts next year’s sales from a few months of inconsistent data. The first may be easier to check. That does not prove it is worthwhile; the founder still needs to measure the review effort and actual benefit.
Give each proposal a named owner and an honest estimate of time needed from your team. If nobody can maintain the source information or investigate errors, the proposal is not ready just because the subscription is affordable.
Buy evidence with a limited test
Define the sample, duration, spending cap, acceptance criteria, and stop conditions before starting. Ask the supplier to demonstrate your representative cases, including incomplete information and exceptions. Compare results with the current process, including the time required to correct mistakes.
Record good outputs and failures. Ask what changed when the supplier adjusts a model, prompt, or integration. A demonstration that succeeds once does not establish dependable performance over time. Keep automatic publication and account changes outside the initial test unless separately designed and authorized.
Include more than the advertised subscription in the budget: setup, data preparation, usage charges, staff training, human checking, support, and exit costs. Treat predicted sales uplift as an assumption unless you have evidence from a suitable comparison.
Ask for ownership and security details in plain language
Ask who owns the accounts, who can access business data, what information leaves your systems, how long it is kept, and whether it is used for model training. Require a clear explanation of deletion and export. Bring in an independent technical adviser if the answer is beyond your ability to assess.
For systems that read outside material or take actions, ask specifically how permissions limit damage from misleading instructions. The UK National Cyber Security Centre explains prompt-injection risks: untrusted content can influence an AI system in ways its owner did not intend. A vendor’s promise that a prompt makes the system safe is not sufficient evidence.
Make the next decision explicit
At the end of the test, choose one action: stop, improve the process, continue with limits, or commission further specialist work. Write down the reason and the next review date. Revisit the decision when costs, customer needs, suppliers, or error patterns change.
For a detailed purchasing process, see comparing AI tools with evidence. If you are hiring someone to help implement the trial, our small-business AI pilot article explains that service. Your first useful investment may be clearer information and a better process; the goal is an improvement you can sustain.
AI disclosure: This article was written and revised with AI assistance. Sources checked September 28, 2026. See our disclaimer.
Illustrative photograph by Patrick Perkins on Unsplash.
