Five questions your board should ask before deploying an LLM feature

Boards do not need to understand transformer architecture to govern AI risk. They need to ask questions that force specific, checkable answers. These five do that. If the answers are vague, the feature is not ready, regardless of how well the demo runs.

The answer should name the data sources, the permission boundary and the actions the model can trigger. "It only reads what the user can read" is a design decision that must be enforced in code, not an assumption. If the model can send email, change records or move money, the board should know who approved that and under what limits.

A named owner, not a team. The answer should cover who monitors the feature, who can suspend it, and who speaks to customers if it causes harm. Features without a named owner drift until the first incident assigns one.

Every AI feature has failure modes: confident wrong answers, leaked context between users, prompt injection through uploaded content. The answer should describe the known failure modes, the detection in place for each, and the last time those detections were tested.

Sales material, terms of service and security questionnaires often commit the company to more than the engineering delivers. The answer should reconcile what is promised with what is true, because the gap between the two is where disputes and churn live.

If an enterprise buyer's security team asked for the threat model, the evaluation results and the access design, could the company produce them within a day? Evidence that exists only in conversation does not survive due diligence.