Questions to Ask an AI Expert Before Starting a Project

The most useful questions to ask an AI expert are about the problem, proof of improvement, required data, permitted actions, and who remains responsible. Ask for a small test with clear success and stop conditions before agreeing to a wider rollout. Tools like fenbs can retain the approved answers as project decisions, so the next conversation starts from what people actually agreed.

You do not need to speak like a researcher to lead this meeting. You need to understand what will change in someone’s working day and how you will know whether it helped. Use the questions below with a consultant, an internal specialist, or a software vendor proposing an AI feature.

What problem are we asking AI to solve?

Begin with a task you can observe. Say a small design studio spends too long finding the approved wording for client proposals. The goal is to retrieve the correct wording faster, with a source someone can check. “Become an AI business” gives the expert nothing measurable to improve.

• What specific task would change, and who does it today?
• What is the current way of doing it, including a simpler search or document template?
• Why does this task need AI rather than clearer instructions or better organized records?
• Which parts of the workflow will stay with a person?
• What would make you recommend that we do not proceed?

Ask the expert to describe a normal successful result in plain words. Then ask them to describe an unacceptable result. For the studio, a useful answer might cite the approved proposal; an unacceptable one might invent a client approval. Those examples make the discussion concrete before anyone chooses a model.

What evidence would make the pilot worth continuing?

A polished demonstration shows that something can work in selected conditions. Your pilot should show whether it works on the tasks your team really encounters. Bring examples with missing information, conflicting versions, and requests that should be refused, alongside straightforward examples.

• Which real examples will we test, and who chooses them?
• What are we comparing the result against?
• How will we measure corrections and review time as well as speed?
• What counts as a serious failure, even if the average result looks good?
• Who can independently check the results before the pilot expands?

Write the acceptance conditions before running the demonstration. This prevents an attractive result from quietly changing the original goal. The NIST AI Risk Management Framework↗ (opens in a new tab) is a voluntary resource for evaluating and managing AI risk; using it as a discussion aid does not certify your project.

What information will the system read and retain?

Ask for a simple map showing where information starts, which services receive it, and where copies remain. A file selected for one question and a connection that can search a whole shared drive create different exposure. Your approval should specify which access you mean.

• Can we run the pilot with made-up or carefully selected nonsensitive examples?
• Which accounts, folders, and fields does the task require?
• Who can read prompts, outputs, saved records, and diagnostic logs?
• Which vendor documents explain retention, training use, deletion, and subcontractors for this exact service?
• What happens to retained information when access is removed or the engagement ends?

Do not accept “the data is private” as a complete answer. Ask the expert to distinguish account permissions, vendor processing, and your team’s own records. For the separate question of what useful work context should be saved, see what an AI brain is.

What may the assistant do without asking?

Reading a proposal, editing its draft, and sending it to a client are three separate permissions. Ask the expert to demonstrate the boundary between them. A written instruction to wait is useful, but the application’s access controls should also prevent unauthorized actions.

The OWASP excessive agency guidance↗ (opens in a new tab) identifies excessive functionality, permissions, and autonomy as distinct risks. Ask which of those the design reduces, and which still depend on a person following a procedure.

Keep the agreed boundaries in Decisions and rules in fenbs, where connected assistants are instructed to read the project’s rules before working.

Who owns the work after the expert leaves?

A useful project should remain understandable without the person who demonstrated it. Ask who maintains instructions, reviews tool access, corrects bad answers, and responds when an outside service changes. Assigning all of that to “the team” usually leaves the first problem without an owner.

• Who owns the service accounts and can recover access?
• What instructions, configuration, test examples, and documentation will we receive?
• Which ongoing expenses and internal maintenance hours should we budget for?
• Can we export the records we need, and what would changing vendors involve?
• Who handles an incorrect result or suspected data exposure after handover?

The NIST AI RMF Playbook↗ (opens in a new tab) offers suggested actions that organizations can adapt to their circumstances. Use it to widen the conversation beyond the demo, then give each agreed responsibility a name and a review point.

For the everyday workflow around these responsibilities, read how to use AI at work. When a proposal describes an assistant as a staff replacement, the guide to AI employees explains the distinction between software capabilities and human accountability.

How should you record the answers during the meeting?

Use one short record per proposed pilot. Separate confirmed facts from an expert’s recommendation and from a choice a person has approved. “The vendor says deletion is available” is a claim to verify; “we approve these test files” is a decision with a named decider.

Proposed task:
Current method and baseline:
Expected benefit:
Examples and reviewer:
Acceptance conditions:
Stop conditions:
Approved data and accounts:
Allowed actions:
Actions requiring approval:
Evidence still needed:
Human decision and reason:
Owner and next review:
Handover and exit plan:

After the meeting, send each unresolved point to its owner with the evidence needed to close it. Do not turn an unanswered question into permission by leaving its field blank. For questions you want to put directly to an assistant rather than a human expert, see how to ask AI questions and check answers.

How to do this with fenbs

1. Create a free account, then add a project describing the pilot and its intended result.
2. Record the human-approved data boundaries, acceptance conditions, and approval requirements in Decisions and rules. Leave unresolved choices open.
3. Add tasks for the sample test, vendor documentation checks, and handover. Give each task a plan that says what evidence is needed.
4. Connect a supported assistant through Integrations, using MCP, a standard way for AI apps to use outside tools. Ask it to read the rules before helping and save progress before stopping.

fenbs keeps the shared project record; it does not run model evaluations or inspect a vendor’s security controls. If your only need is a one-off interview worksheet, a document may be enough. It is free for one person, no credit card, when you want the answers to remain available through later working sessions.

What should make you pause before agreeing?

Pause when an expert will not name limitations, cannot explain the data route, or asks for broad access before defining a test. A recommendation to start smaller can be a strong answer. It shows that the proposed access and effort follow the problem rather than the presentation.

End the meeting with one bounded next step: run the agreed sample, check a specific document, or answer an open decision. The AI governance hub covers the wider practice of keeping AI work accountable. Your immediate goal is simpler: enough evidence for a person to decide what should happen next.