An AI program does not begin when a vendor signs an SOW. It begins when the operating leadership of an organization can answer the following questions out loud, without hesitation, and ideally on paper. If you cannot answer all eleven, the architecture you commission will be designed around assumptions someone else makes on your behalf.
Eleven questions
1. What decision are you trying to improve?
Not "improve operations." Not "leverage AI." A specific decision. Where is it made now, who makes it, what information do they use, what is the failure rate, and what would success look like measured in business terms.
2. What data does that decision currently consume?
Where does it live? Who maintains it? What is its update cadence? What is the data quality you would honestly characterize, not the data quality you would claim in a board memo.
3. What data would you refuse to expose to a cognitive system?
Make the list explicit. Personal client correspondence. Strategic counsel. Litigation prep. Compensation. Acquisition modeling. Decision drafts. If the list is "nothing," you have not thought about the question yet.
4. What is your network boundary?
Where, physically and logically, does data cross from "ours" to "someone else's"? If you cannot draw it on a whiteboard, the architecture engagement starts with drawing it.
5. Who would be the operational owner after delivery?
A cognitive system needs an owner inside the organization. Not the vendor. Not the consultancy. A named operator who will run the system, review its outputs, and tune its posture. If that person does not exist, identify them before the engagement begins.
6. What is your audit posture?
Are you audited annually? Quarterly? On demand by a regulator? What records do auditors ask for? Your cognitive system needs to produce those records on day one, not as a retrofit.
7. What is your stop condition?
Under what circumstances would you turn the system off? If the answer is "never," your governance is incomplete. A real stop condition is a sign of a real governance posture.
8. What is your budget for the first three years?
Not just initial build. Compute. Ongoing development. Model rollover. Quarterly review. Stewardship retainer if applicable. If you have only budgeted year one, you are budgeting a pilot, not a program.
9. Who decides what the system is allowed to do?
Policy authority. Capability scope. The list of operations the system will refuse. This is not a technical question, it is a governance question, and it needs to be answered by named individuals with named authority.
10. What does graceful failure look like?
When the model is wrong, how does the human in the loop know? Who reviews the wrong answers? What is the feedback path back into the system? Without these, you are deploying an unreviewed black box into your operation.
11. What is your communication posture if this becomes public?
Hypothetically: your AI deployment is mentioned in a trade publication. What is your statement? Is the use of AI in your operation part of your communicated identity, or is it confidential by structural intent? The answer determines the entire posture of the architecture.
Most failed AI engagements failed in question three. The operator could not articulate what they would refuse to expose, so the architecture exposed everything by default.
What to do with the answers
Write them down. Sign and date the document. Bring it to the discovery conversation with any vendor you are considering. The document does not need to be polished, but it needs to exist before any vendor sets foot in your environment. The discovery work is shorter and the architecture engagement is faster when the operator has already done this thinking.
Inside our practice we will walk a prospective client through these questions during the first discovery conversation. We will not begin architecture work until each one has been answered. The questions are non-negotiable not because of methodology but because the architecture cannot defend the operation otherwise.