Quick answerWho should own the materiality call on a specific change, engineering or legal? Legal and compliance should own the final call, but the three-axis test should be answerable by the engineer proposing the change, so most changes get correctly self-classified before they ever need to reach legal for a judgment call on an ambiguous case. Should a rollback of a previously approved version also require re-review? No, reverting to a version that already passed review doesn't need to pass it again; the versioning and rollback mechanics exist precisely so reverting is fast and doesn't re-trigger the compliance gate a forward change might.
Quick answer
Treat a change as material, and therefore requiring the full legal and compliance re-review, if it expands what the agent is authorized to do (a new category of question it can answer, a new autonomous action it can take), changes who it can do it to (a new customer segment, a new jurisdiction), or changes the evidentiary or disclosure posture of its answers (a new data source it now cites, a new claim category it can make). A change that only alters phrasing, tone, or internal routing logic without touching authority, audience, or claims is a minor tweak that belongs in your normal prompt-versioning and testing process, not a full re-review.
Two different gates, two different purposes
The initial legal and compliance sign-off before launching a customer-facing AI agent is a one-time gate: it exists to confirm the agent is safe to put in front of customers at all. Prompt versioning and rollback is a technical mechanics question: how do you ship any change, big or small, safely, with the ability to revert quickly if something goes wrong. Neither answers the question this post is about, which is a compliance-materiality threshold: given that both the initial gate and safe-shipping mechanics already exist, which specific changes need to go back through something like the original gate, and which can ship through the normal versioning pipeline without it. This is also a different question from how often to proactively tell customers what changed in the agent's behavior, which is a customer-communication cadence decision, not a compliance re-review trigger; a change can clear this materiality test and still be worth mentioning in the next customer update, or fail it and still be too minor to mention at all.
The three-axis test for materiality
Ask three questions about any proposed change. Does it expand authority: can the agent now do something, answer a new category of question, take a new autonomous action, approve a new kind of request, that it couldn't do before? Does it expand audience: does the agent now interact with a new customer segment, a new jurisdiction, a new age group, or a new channel it wasn't designed and reviewed for? Does it change evidentiary or disclosure posture: does it now cite a new data source, make a new category of factual or legal claim, or change what it discloses about itself or its limitations? A yes on any of the three is material and should trigger re-review scoped to the specific area that changed, not necessarily the full original review from scratch.
What clearly doesn't require re-review
Tone and phrasing adjustments that don't change what claims are made, internal routing or orchestration changes that don't change what the customer-facing agent is authorized to do or say, performance and latency optimizations, and bug fixes that bring behavior back in line with already-approved policy rather than introducing new policy, all belong in the normal versioning and testing pipeline. Forcing every change through a full compliance re-review regardless of materiality doesn't make the agent safer, it just trains the team to treat re-review as a rubber stamp, which is the outcome the materiality threshold is specifically designed to prevent.
Building the trigger into your release process, not just a policy document
A materiality threshold that lives only in a policy document gets skipped under deadline pressure. Wire the three-axis test into the actual change-review checklist your team uses before promoting a prompt or policy version, with an explicit sign-off field for each axis, so a shipping engineer has to actively answer "does this expand authority, audience, or evidentiary posture" for every change, rather than relying on someone remembering to ask the question.