Responsible AI Blocklist
Does ZopNight manage Responsible AI Blocklist?
Responsible AI blocklists hold custom phrase and pattern entries that Azure OpenAI content filters enforce on top of a policy. Blocklists bill nothing, a flat 0 direct cost, yet ZopNight inventories each one alongside the RAI policies that reference it, because an unreviewed blocklist is invisible compliance configuration in an AI estate.
Rules that fire on Responsible AI Blocklist
No active rule family targets Responsible AI Blocklist today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery only. |
RAI blocklists hold custom term lists enforced by content filters on OpenAI deployments. Free governance objects, inventoried for completeness.
Blocklists: zero cost, nonzero compliance weight
A blocklist is an ARM child of a Cognitive Services account (raiBlocklists) holding customer-defined phrases and patterns that the content filter applies on top of whatever policy governs a deployment. No charge ever attaches. Its weight is entirely regulatory and reputational: the entries encode what an organization decided its models must refuse to say, and in a compliance review those decisions matter in a way no billing line does: when they were made, by whom, and where they apply.
Blocklist rows next to the policies that use them
Discovered via the AI enricher alongside the RAI policies that reference them, with the name and optional description captured per blocklist. The sweep runs across every Cognitive Services account kind, and blocklists group under a synthetic Content Filter Blocklists node per account, keeping them adjacent to the policies and deployments they modify. The point of holding these rows at all is completeness: a filtering posture described only by its policies is missing the custom term layer that changes what those policies actually do.
Untracked blocklists as governance debt
The failure modes are quiet ones. Blocklists created during an incident, perhaps a product name to suppress or a legal phrase to block, and never revisited once the incident closed, still shaping model output years later. Lists that exist on one account but not its siblings, so nominally identical deployments behave differently under the same prompts. And undocumented entries with no owner, which an auditor reads as policy nobody can explain. None of this surfaces in cost tooling; it surfaces when an inventory puts every blocklist next to the accounts and filters that enforce it.
The blocklist management surface
In the AI Foundry portal, blocklists live under Safety + security beside the content filters that consume them, where entries are added and lists attached to filters. Through ARM they enumerate as raiBlocklists children of the account. That is the route by which discovery finds lists no one has opened in the portal for months.