Check items for this visit only. Nothing is stored or submitted. Use your approved systems for evidence and sensitive information. This is an operational checklist, not a legal determination.
0 items checked
Evaluate contract AI by asking what sources, users and models can see, what crosses system boundaries and who is responsible for that access over time. Start with a proposed business question and a small, non-sensitive demonstration set. Request current documentation rather than assuming a control exists because it appears on a generic questionnaire.
Draw the path from source record to retrieval, model processing, response and downstream use. Ask which organizations or providers receive information at each point. Include attachments, excerpts, derived context and logs, not just the final answer shown to the user.
Ask how a person’s source access relates to an assistant’s permitted context. Which identity is used, which permissions are checked and what happens when the two differ? Request a role-based demonstration with an allowed and a restricted record.
Context access is separate from authority to approve an invoice, make a payment or execute another business action. Identify the authorized workflow for those decisions. An assistant that can explain a commitment should not be assumed to have permission to act on it.
Illustrative example: a reviewer can see a summary but not an underlying attachment. Ask the evaluator to run a question whose answer would require that attachment. Inspect retrieval, citation and downstream output against the intended boundary, including whether a generated response reveals content the reviewer should not receive.
Repeat the test after access changes. Ask when the change takes effect, what happens to earlier outputs and which records show the event. Document expected and observed behavior separately, and send discrepancies to the named owner before expanding the demonstration.
Request documentation for storage locations, retention, deletion and handling by hosting and model providers. Ask what may be retained in prompts, caches, outputs, backups and operational logs. Which contractual terms govern training use, and who can confirm that the proposed configuration follows them?
Avoid substituting a broad assurance for an answer about the actual deployment. Record the version and date of the documentation reviewed, the party providing each service and the evidence still requested. Have the appropriate security and procurement reviewers assess those answers.
Ask how a reviewer traces an answer to its permitted sources and recognizes missing evidence. What happens when a source is corrected, withdrawn or no longer accessible? Request a demonstration rather than treating the presence of a citation as proof that every access boundary has been tested.
Ask which events are logged, who may inspect those logs and who owns investigation and correction. Agree an escalation path for unexpected output and identify who can pause the evaluation. Keep responsibilities clear across business, security and technical teams.
Summarize the test scope, documentation reviewed, observed behavior and unresolved questions. State which use is being considered and what further approval it needs.
LineageAI is PostSig’s shared foundation for entities, relationships, effective dates, scope and source evidence. PostSig MCP provides approved access for assistants, tools and customer-built workflows. Explore that framing alongside your own security and model-governance requirements.