AI Addaiadd.org

What should trigger a review of the add-on's role?

A review should be triggered when an add-on’s production behavior changes, it no longer performs the distinct task it was adopted for, or an external policy change affects whether its workflow can run. A failure alone does not prove that the add-on is at fault: operational guidance confirms that an unchanged flow can be blocked after a data loss prevention policy update.

Begin with what happens in production

The AI risk-management guidance says that deployed AI components should be monitored in production, including their functionality and behavior. For an add-on, this makes observed performance a practical review trigger.

Examples include behavior that no longer matches the add-on’s intended purpose, inconsistent results, or failures that force the team to change how the surrounding workflow operates. These are review signals rather than automatic grounds for removal. The relevant question is whether the add-on still has a necessary, distinct role.

Check whether the surrounding conditions changed

A workflow can fail without any change to the add-on or the flow itself. The cited operational guidance notes that an administrator may have changed a data loss prevention policy, which can block an unchanged flow.

When that happens, the review should examine the policy, the data flow, and the add-on’s function separately. A recent policy or configuration change should be checked before concluding that the add-on has lost its role. The team may instead need to adjust the workflow, restore a valid data path, or reconsider whether the add-on remains necessary under the updated conditions.

Use a simple review sequence

  1. Restate the intended role. Identify the task the add-on is supposed to perform and what part of the existing workflow depends on it.
  2. Compare intent with production behavior. Determine whether the add-on is still fulfilling that role consistently.
  3. Check for changes outside the add-on. Look for relevant policy, permission, or data-flow changes that could explain new failures.
  4. Reassess the outcome. Decide whether the add-on should remain unchanged, be narrowed to a clearer role, paused, or removed.

The two cited points do not establish a universal review interval, numerical threshold, mandatory deadline, or automatic removal rule. Those decisions must be confirmed against the add-on’s actual production behavior and the reader’s current workflow and policy environment.

Sources