An AI governance framework is useful when it makes ownership, limits and evidence clear. For a small software team, that can mean a short use-case register, a few enforceable controls and a release review that someone actually performs. A long policy that never affects a product decision will not do the job.
Governance should change how you ship
Start with one feature. Describe what it does, who uses it, what data it receives and what happens when its output is wrong. Assign a person who can decide whether it should launch, pause or change. Then keep the evidence needed to support those decisions.
This is an engineering framework for organising work. It is not a legal compliance assessment, a certification or a claim that one checklist satisfies every regulation. If your use case creates specific legal duties, obtain the appropriate advice and add those requirements to the feature's controls.
Use a recognised framework without pretending it is a certificate
NIST's AI Risk Management Framework is voluntary and organises its core around Govern, Map, Measure and Manage. Those functions are useful lenses for thinking about a feature; they are not simply four sequential boxes to tick once.
For a small team, Govern means clear accountability and decision rules. Map means understanding the use case, affected people and context. Measure means gathering evidence about the risks and performance that matter. Manage means acting on that evidence through controls, rollout choices and response plans.
NIST's Playbook provides suggested actions, not a universal mandatory checklist. Use it to inform your own risk work. If you claim alignment, explain what you actually did instead of displaying a framework name as if it were an independent approval.
Create a one-page use-case record
For an internal knowledge assistant, the record might say: employees can ask questions over approved policy documents; the assistant provides citations; it must decline when the evidence is insufficient; it cannot access documents outside the employee's permissions. That description is already more useful than “we use generative AI.”
Keep the record close to the team that owns the feature. Update it when the audience, data sources, model or available actions change. A new tool that can write to a system can change the risk more than a small improvement in answer quality.
- Purpose and users: the job the feature supports and the people affected.
- Owner: the person responsible for launch, pause and change decisions.
- Data: sources, sensitivity, retention and access rules.
- Capabilities: permitted outputs and actions, including explicit exclusions.
- Failure impact: what happens if the answer is wrong or an action repeats.
- Evidence: evaluation results, access tests and unresolved limitations.
- Response: fallback route, incident owner and next review date.
Turn three risks into three verifiable controls
Risk one is cross-user data disclosure. The control is application-level access filtering before content reaches the model. The evidence is an automated or reproducible test using two identities with different document permissions. The owner is the engineer responsible for the data-access layer, not an unspecified “AI team.”
Risk two is an unsupported answer appearing authoritative. The control is an evidence-based answering policy and a usable abstention route. The evidence is a reviewed set of answerable and unanswerable questions, with examples of both correct answers and appropriate refusal. A polished citation UI alone does not prove that the cited material supports the claim.
Risk three is a consequential action occurring without approval. The control is an enforceable permission or approval boundary around that action. The evidence is a test showing that the action cannot execute before approval, including when the model asks differently. OWASP's excessive-agency guidance is a useful reference for this class of risk.
Make model changes reviewable
A model update can change outputs even if your application code stays the same. Record the model identifier, prompt or instruction version, retrieval settings and tools used in the evaluated release. Keep the evaluation cases that matter to the feature's actual users.
Before changing a model or major prompt, rerun those cases and inspect new failures. Decide which regressions block release and who can accept a remaining limitation. A favourable average score should not hide a serious failure in a permission boundary or a high-impact category.
Use a limited rollout where appropriate, with a clear route back to the previous version. Monitor reviewed user outcomes and incidents rather than only request counts. The governance record should help explain why a change was accepted and what the team will do if its assumptions prove wrong.
Keep governance proportionate and alive
Does every small AI feature need a large committee? No. It needs accountability and controls proportionate to the consequences. A low-risk drafting aid and a system that changes financial records should not receive the same release process.
Set a review when something material changes, and a periodic check for assumptions that can drift. A new data source, audience, automated action or vendor setting is a reason to revisit the record. Give operators a simple way to report surprising behaviour and preserve enough safe evidence to investigate it.
Start with the one-page record and the three most important controls for your feature. A framework becomes valuable when it helps the team make a better decision today and leaves a clear explanation for the next person who has to maintain the system.