AI Governance Checklist and Test Plan Worksheet
A practical checklist for teams moving one AI workflow from idea to a controlled pilot or production decision. Use the free worksheet below to prepare checks and download an unrun test plan. It is a planning aid, not a certification or a claim about any customer implementation.
AI workflow control test planner
Turn a general governance checklist into checks your team can actually review. Choose how one workflow handles information and actions to draft a test plan with synthetic inputs, proposed boundaries and evidence to inspect. This planner does not connect to your systems or execute tests. Every check starts Not run.
How to use the worksheet
- Define one workflow. Agree its users, data, permitted decisions and actions. Use Not sure when the architecture is unclear; the related checks remain in the plan.
- Agree boundaries before testing. Replace each proposed boundary with a system-specific requirement and assign an accountable owner. Use synthetic data in an authorized test environment.
- Record what happened. After running each check, add an evidence reference, actual outcome, reviewer and next action in your downloaded worksheet. A model refusing a request is not proof that the underlying data or tool access was denied.
- Resolve gaps with the right reviewers. Retest after changes. The number of proposed checks is not a risk rating, pass count or release recommendation.
Describe one workflow
Selections are processed only in this page. The planner does not send them to DigiScience or save them in browser storage. Downloads are created locally; existing site analytics are separate. Do not enter customer or employee data.
No means the feature is reported absent; it does not prove safety. Verify that assumption with the system owner. Not sure keeps the related checks and an explicit question to resolve.
Your proposed checks
Unrun draft. All owner, agreed-boundary, actual-evidence, observed-outcome and review fields are blank in the exports. Suggested roles are not assigned people. Download a copy to complete during your review; changing choices requires a new plan.
What this plan can and cannot tell you
This original DigiScience template helps structure an evidence review. It is not an automated assessment, a complete threat model, penetration test, certification, legal opinion or compliance decision. It cannot establish that a system is safe or ready for production. Domain risks, model quality, legal obligations and operational failure modes need additional, system-specific review.
Technical references
The template draws on risk-management and access-control principles; it is not an official checklist or an endorsement by these organizations.
- NIST AI Risk Management Framework — voluntary guidance for managing AI risks.
- OWASP LLM06:2025 Excessive Agency — permissions, tool scope and human approval boundaries.
- Microsoft security filters in Azure AI Search — document filtering must be applied consistently; a filter string does not authenticate a caller.
Use this checklist before scaling an AI workflow
Work through the controls below with the business owner, delivery team, security, legal or compliance stakeholders as relevant. The aim is to identify evidence gaps early—not to add process for its own sake.
1. Name an accountable owner
Document who owns the business outcome, who can approve a change, and who can stop the workflow if it behaves unexpectedly.
2. Define the decision and risk tier
State what the AI may recommend, draft, classify, or automate. Identify whether an incorrect output could affect money, safety, rights, regulated records, or customer commitments.
3. Classify data and access
List data sources, sensitivity, retention needs, residency constraints, and who or what may access them. Apply least-privilege access rather than broad shared credentials.
4. Select and evaluate the model
Record the intended model, hosting location, known limitations, evaluation set, acceptance threshold, and a fallback if quality is below the agreed standard.
5. Protect prompts and instructions
Separate trusted system instructions from untrusted user or document content. Test for prompt injection, data leakage, unsafe tool calls, and instruction conflicts.
6. Set human review boundaries
Specify which outputs require review, who reviews them, what evidence they need, and when the workflow must escalate instead of continuing automatically.
7. Constrain agents and tools
Give agents only the tools and permissions required for the defined job. Require confirmation for consequential actions such as external messages, record changes, payments, or deletes.
8. Keep audit evidence
Capture the request, relevant version identifiers, tool actions, reviewer decision, and final outcome in a way that supports investigation without retaining unnecessary sensitive data.
9. Monitor quality and cost
Track outcome quality, error patterns, latency, usage, cost, drift, and failed safety checks. Decide who receives alerts and how often the controls are reviewed.
10. Prepare incident response
Define a pause or rollback path, incident owner, customer communication path where needed, and a process for fixing and retesting the workflow before restart.
Evidence to gather for a first assessment
- One representative workflow and its current manual steps
- Sample inputs with sensitive data removed or protected
- Known policy, security, regulatory, and residency requirements
- A measurable success definition and an acceptable failure boundary
- The systems, teams, and approvals needed for a bounded pilot
Where evidence is incomplete, that is an assessment finding—not a reason to promise a solution prematurely.
LLM API governance: minimum controls
When a workflow calls an external or internal language-model API, document the model provider, purpose, approved data classes, authentication method, rate and spend limits, retention terms, and fallback behaviour.
Gateway and identity
Use named service identities, scoped keys or workload identity, server-side secret handling, and a controlled gateway where appropriate. Do not embed broad provider keys in user-facing applications.
Input and output controls
Filter or transform sensitive inputs where required, separate trusted instructions from untrusted content, validate structured outputs, and define human review boundaries.
Evidence and change control
Record the model/version, prompt or policy version, tool actions, evaluation evidence, and approval for material changes.
These controls help a team assess API use responsibly; they are not a substitute for legal, security, or compliance advice.