A governance control needs a steward.

The launch date does not own the control

A team ships an AI assistant with a rule that blocks restricted documents from being sent to an unapproved service. The test cases pass. The release note is signed. Three months later, the service register changes, a new workflow bypasses the original upload path and nobody knows who is supposed to reassess the rule.

The control still exists in code, but its governance is already weakening. A launch artifact cannot notice that its assumptions changed. It cannot decide when evidence is stale, call the right reviewer or explain who has authority to revise it. Those are stewardship responsibilities.

For founders and product leaders, this is where governance becomes operating design. Every consequential control needs a named steward after launch—not merely an author who once wrote it or a committee that approved it.

Name the responsibility, cadence and trigger

NIST's AI Risk Management Framework 1.0, published in 2023, says in GOVERN 1.5 that ongoing monitoring and periodic review should be planned, with organizational roles, responsibilities and review frequency clearly defined. GOVERN 2.1 calls for documented roles, responsibilities and lines of communication. The Core also describes governance as a continual requirement across an AI system's lifespan. NIST's current resource page, checked October 21, 2026, states that AI RMF 1.0 is being updated.

Those outcomes are a useful foundation; they do not prescribe one universal product workflow. My practical interpretation is to attach four things to a control: an accountable role, a scheduled review interval, event-driven review triggers and an evidence location.

A trigger might be a model change, a new data class, a destination added to a service register, a material incident or repeated user override. The steward does not need to perform every technical task. The steward does need enough authority to convene review, record a disposition and escalate when the control no longer fits its context.

Make stewardship visible in the work

Consider the fictional upload control. Its record could show the policy owner, engineering maintainer, operational reviewer and escalation route. It could name the evidence used by the last review: current service register version, test results, override pattern and incidents. The record should also show the next scheduled review and any trigger that reopened it early.

Do not collapse these roles into a single ambiguous owner field. The person authorized to approve the policy may not be the engineer who changes the implementation or the operator who observes exceptions. A useful handoff states who recommends, who decides, who implements and who verifies the resulting behavior.

The same separation matters for AI IP attribution. A technical steward may maintain lineage evidence, while different authorized roles resolve ownership, licensing and release permission. A contribution finding should not silently grant rights, and a rights decision should not rewrite the technical history.

Stewardship also needs an unresolved state. If the service register is stale or responsibilities conflict, the control should not manufacture a clean answer. Record the gap, preserve the evidence and route the decision to the appropriate authority.

Test the maintenance path, not just the rule

A proposed study could compare controls with a static launch record against controls with named stewardship, periodic review and event triggers. Use the same fictional workflows, policies, model versions and reviewer resources. Introduce a destination change, a new data label, an owner departure and an incident that reveals a bypass.

Measure time to assign review, missed triggers, incorrect approvals, unnecessary blocks, verified fixes, reviewer burden and legitimate task completion. Separately inspect whether the implemented behavior changed; a completed review form is not proof that the control was repaired.

This is a building proposal and experiment design, not a measured result or a claim about a deployed system. Pick one consequential AI control your team shipped. If its assumptions changed tomorrow, who would know, who could act, and what evidence would show that the response reached the running system?