Define information boundaries
Public, internal and confidential are operational distinctions. Specify which tools, users and environments may use each information type. An unnamed file can still contain identifying information or proprietary business rules. Start experiments with approved or synthetic examples and keep access decisions separate from how appealing a tool looks.
Review sources and limitations
Fluency is not evidence of correctness. Check answers against authorised sources and make missing or conflicting information visible. Knowledge assistants need fresh sources, user permissions and traceable references. Include evaluation questions whose answers are absent from the available sources: the system should acknowledge the limitation rather than confidently invent an answer.
Assign responsibility for decisions
A model recommendation, user approval and execution are distinct stages. Define who reviews outputs, who may act and when the process stops. An internal summary and a financial or access-control decision require different controls. Recording decisions and corrections helps teams investigate errors and improve their operating rules.
Keep learning and monitoring
Include usage rules in team training and make them traceable in practice. Model, source or access-policy changes can alter output quality, so evaluations and reviews should evolve too. Define an incident-reporting path and an owner. NIST’s AI Risk Management Framework is a public resource for structuring these questions; using it alone is not certification or a security guarantee.
Minimum rules for an internal usage policy
A concise policy can answer practical questions: which tools are approved; which information must not be entered; who authorises exceptions; which outputs require review; who may execute the final action; and how incidents are reported. Align these rules with IT and process owners. Define a clear stop-and-ask path for out-of-scope situations. A document alone is insufficient: training examples should show how the policy applies to summarisation, knowledge retrieval and reports. Review the policy as tools and organisational needs change.
Test beyond straightforward questions
For a knowledge assistant, evaluation can include a well-supported question, a question absent from the source, outdated information, conflicting sources and a question beyond the user’s permissions. Define expected behaviour before running each case: cite a source, express uncertainty, ask for clarification or withhold unauthorised information. A correct answer for one user is not necessarily permitted for everyone. Re-run the same cases after model or source changes, and add newly observed failures. Evaluation forms part of engineering and acceptance; no finite test set guarantees complete freedom from errors or disclosure.