Three questions before adopting AI

Before adopting AI, ask three questions: which specific piece of work is this and who is accountable for the result; does the knowledge AI will use have a source and is it current; and how will we check the output and know it really worked. If all three can be answered, adoption has a firm starting point. If one cannot, fill that gap first. It prevents more rework and waste than rushing to pick a tool.

Why questions rather than a checklist

Checklists for evaluating AI are common, often twenty or thirty items covering features, price, security and integration. They are useful, but they invite ticking boxes while missing the point: meeting every condition does not mean the work suits AI. A question demands an answer, and when none comes the team is plainly not ready.

We chose these three because they match the three most common reasons adoption fails: vague scope, no one holding responsibility, and no way to verify data or results. They do not depend on any product, so they apply whatever model or service you use. Spend an hour before a purchasing meeting answering them with the people involved; the answers are themselves the outline of an adoption plan.

Question one: which work, and who is accountable?

"Use AI to raise efficiency" is not a piece of work; "sort incoming customer mail each week and route it to the right contact" is. Work should be specific enough to name its input, who receives the output and what counts as done. The more specific it is, the easier it is to see which part AI can help with and to compare before and after. If you cannot say how it is done today, you cannot say whether it improved.

Equally important, one named person must stand behind the result. That person need not be the operator; it is whoever answers "why" when an output goes wrong. In a process without an owner, errors vanish between hand-offs, and nobody fixes them or learns from them. In "AI drafts, people decide", the people must be a named person with authority to decide.

Question two: is the knowledge sourced and current?

What AI can draft rests largely on what it reads. If the material is an old version, files kept separately by different departments, or text nobody knows the author of, the output inherits those problems, and it reads fluently, so the flaws are hard to spot. So ask: where does this work's knowledge live, who maintains it and when was it last updated?

Go further and mark facts, observations and assumptions separately. A fact can be traced to a source, an observation was seen in a specific situation, and an assumption is a guess still to be verified. Mixed together, both AI and readers take guesses as conclusions. Sorting takes effort, but it is the most direct way to make output trustworthy, and it shows what to change at the next update.

Question three: how will we check, and how will we know it worked?

Decide before launch how output is checked: who reviews, what they look at, and who gets it back when an error is found. Keep draft, verification, approval and delivery as separate states, each with a name and a date. When a client or manager asks whether a piece of content was confirmed, you can show the record rather than offer a verbal assurance.

The other half is judging effect. Before starting, note the current state: how long one item takes, how many are sent back, which errors are most common. After a period, look again the same way. Without a before-and-after comparison, benefit is an impression. With one, even "no clear improvement" is useful information, since it lets you adjust, narrow the scope or pause.

The order of the questions, and how they pull on each other

The questions have a rough order: settle the work and who is accountable, and you know what knowledge is needed; organize the knowledge, and you can design checks. In practice answers get revised back and forth. When discussing checks you may find the scope too large to review item by item, and go back to narrow it. That back-and-forth is normal, and it is what these questions are for.

Once all three have first answers, summarize them on one page: name of the work, accountable person, knowledge sources and how they are updated, the checking process, and the measures for before-and-after comparison. That page is the smallest adoption plan, short but specific. Better than a thick proposal is this one page, revised as you actually run.

Three common mistakes

The first is treating the user as the accountable person. Many people can operate a system, but when something goes wrong someone must explain why and decide whether to fix the process. The second is assuming that data being in the cloud means it has a source. A file stored somewhere does not mean anyone confirmed it is correct or is responsible for updating it. The third is counting "everyone finds it handy" as a result. That feeling is worth hearing, but it cannot say how much was saved or how many errors were made.

What they share is that feeling replaces facts that can be checked. The remedy is not complicated: name the accountable person, give the data a maintainer and a date, and keep records from before and after adoption. These look minor, yet they decide whether the whole effort can be trusted and improved, so they are worth settling at the start.

What to do after answering

After answering, pick the clearest piece of work and run a trial of two to four weeks. Check and record every output during the trial, compare with the state before adoption at the end, and then decide whether to widen, adjust or stop. This rhythm gives decisions evidence and builds the team's confidence on results it can see.

If some answers show you are not ready yet, there is no need to be discouraged. List what must be done, such as organizing pricing rules, naming an accountable person and building a checklist. This work has long-term value for the organization and stays useful even if the tool or model changes later.

Who should be asking these questions

The three questions should not be left to technical or purchasing staff alone. The content of the work should be described by the people who do it, accountability held by someone with authority to decide, and the source of knowledge confirmed by whoever maintains the data. Ideally these three roles sit at one table, each answering what they know best, and gaps between them surface, such as a manager who assumes a standard exists while the floor does its own thing.

If outside consultants or vendors take part, they can help ask and organize, but the answers must come from, and be owned by, people inside the organization. Outsiders can bring experience and method, but they cannot decide who is accountable or which data counts. Saying so at the start makes later cooperation smoother and avoids discovering, after adoption, that nobody takes it over.

Hypothetical scenario: an agency that wants AI to answer client enquiries

This is a hypothetical scenario, not a real case. A small agency receives many client enquiries each day, and its head wants AI to reply automatically and save labor. They answer the three questions in order. Question one: the work is "replying to quotation and progress enquiries"; the input is the client's email, the output a draft reply, and the accountable person is the account manager, not the support assistant.

Question two exposes a problem: pricing rules sit in three spreadsheets and in the head of one senior colleague, and progress is scattered between a project tool and private messages. If AI read them directly it would get contradictory answers. They decide first to prepare a list of current pricing rules and progress sources with update dates and maintainers. Question three: every draft is reviewed by the account manager before sending, with the size of edits recorded as the basis for deciding whether to loosen control.

A month later the records show that quotation drafts need almost no edits, while progress drafts are still often changed because the source is not updated in time. They widen the quotation use first and go back to fix how progress data is updated. The questions guaranteed no success, but they showed what to do next instead of leaving it to feel.

Frequently asked questions

Q: What size of organization is this for? A: From a one-person studio to a large team. Size changes only how detailed the answers are; a small team can finish on one page.

Q: We already use AI. Should we go back and ask? A: Yes. Compare each current use against the questions and find the parts with no owner, unclear sources or no way to check, then fix those first.

Start from insight; every step counts.