Most AI governance starts too late
Before a team connects an assistant to business data, I ask it to write down the questions people will bring. A request that sounds harmless in a steering meeting can turn out to need restricted records, an unsettled metric or authority the intended user does not have. Looking at the actual questions is how I find those issues early enough for the business owner to resolve them.
Question intake gives the process owner and the data owner a specific piece of work to discuss. They can decide which interpretation is intended, where the supporting records live and who should receive the result. If they disagree, the implementation team has a named issue to resolve before building around an assumption. I find that much more useful than asking a general governance committee to approve an entire category of AI use.
Scope questions the way you scope decisions
For the first pilot, gather questions through a short brief. What decision does the answer support? Who owns that decision? Which data is expected? What happens if the answer is wrong? This is not a permanent form for every conversation. It is how you define the supported question types before opening a general interface.
Use recent, real examples rather than slogans. “Explain why these orders missed the promised date” is scoped. “Improve supply chain intelligence” is not. A specific request reveals the required records, time boundaries and the owner qualified to judge the explanation, and it shows quickly whether the workflow is feasible with the data you have. This is what I mean by measuring in weeks: well-scoped questions let a 90-day pilot produce evidence a steering committee can act on.
Surface assumptions before anyone writes code
Review each candidate question for business meaning, source availability and authority. Some requests sound like read-only analysis but imply a decision about a customer, a patient or an employee. Catch that early so the right owner can set review requirements. In a bank, a question that touches credit and lending decisions belongs in a different risk tier from a question about branch traffic.
Separate what the system can answer from what the organization has not yet defined. If two departments disagree on what an active customer is, no prompt will make both definitions authoritative. Intake should route that disagreement to a definition owner, not bury it in an implementation choice.
Look for unnecessary data. A user may ask for individual records when an aggregate would support the decision. In healthcare, this is the HIPAA minimum necessary principle in practice. Discuss the smallest useful scope before a broad request becomes an unexamined access requirement.
Keep a living question library
For each accepted question type, keep a representative example, the expected behavior, source assumptions and a review owner. Include cases where the right answer is a clarification or a refusal. The library becomes the shared reference for implementation, evaluation and user guidance, rather than a set of polished demonstration prompts.
Connect it to real work. Support requests and repeated confusion should feed it, and questions that no longer match the business should be retired. Do not make users memorize exact phrasing; evaluate realistic variations so the team understands behavior beyond one approved sentence.
Give the library an owner and a review cadence. New questions should extend an existing entry or justify a new category. That small discipline prevents a backlog of near duplicates with inconsistent assumptions.
Let intake govern expansion
When a new department asks for access, compare its questions with the existing scope. Similar words do not mean the same definitions, permissions or consequences. A sales manager and a finance controller can both ask about revenue for very different reasons.
Record why a question is deferred: missing data, unclear ownership or unacceptable consequence. Each has a different next step, and clear criteria stop the same request from returning under a new project name.
Try the intake process on three requests already waiting in the queue. Ask the proposed owners whether the record gives them enough information to approve, narrow or defer each one. Note where they need another person’s decision and add that route to the process. A small working intake process is easier to improve than a policy written without testing it on actual requests.