Skip to main content
Customer guide

AI governance

Keep inventories, approvals, risk decisions and enforcement evidence as separate records.

For: AI governance lead, Risk owner, Security policy owner

Before you begin

Assign owners for the AI application, provider/model, data flow and institutional use case. Gather the organization’s policy and review criteria before requesting an approval.

  1. Define the exact purpose, population and model version.
  2. Identify who may approve a material change.

Supported scope and current status

The approved market plan calls for separate catalog, provider/model, integration and use-case decisions. The current public site describes governed paths but does not establish that every governance workflow is exercised in a current release.

  1. Use /coverage for technical enforcement scope.
  2. Treat a discovered application as an observation, not as an approval.

Compare this path with the published coverage table and the coverage guide.

Set up the path

If the release offers governance records, have an authorized owner register the exact application and source, then request the required risk and policy reviews. Customer approvers own the decision, not the detector or connector administrator by default.

  1. Record the version and data-flow scope.
  2. Leave missing training or legal evidence as an explicit gap.

Use the workflow

Review each proposed change against the current authorization before enabling a route or policy. A wider tool effect, new model version or changed purpose needs its own decision.

  1. Open the specific record and review its current revision.
  2. Approve or refuse the new scope with a named accountable person.

Verify the result

Read back the saved decision, approver, scope and any enforcement adoption. A catalog entry or maturity label alone does not prove the application is safe or protected.

  1. Check the new version against the approved version.
  2. Exercise a synthetic protected action on the selected route where available.

Coverage references: 24 requirements, 0 currently passed

This guide is bound to 24 requirements in RedactWall's acceptance crosswalk, which is maintained internally and not published. A requirement counts as passed here only after current evidence for every bound scenario and authority has been published; none has been published yet.

See the public verification overview and the documentation coverage guide.

Denials and recovery

If approval is expired, evidence is missing or a material change makes the review stale, keep the route from inheriting old approval and ask the accountable owner for a fresh decision.

  1. Record the gap rather than substitute an aggregate score.
  2. Re-check the exact version and route after remediation.

For customer-side next steps, read Recovery and support.

Billing and integration handoffs

An AI governance record does not create provider credentials, device capacity or a supported connector. Each integration still needs its own customer administrator and commercial terms.

  1. Review /integrations for the named technical path.
  2. Review /pricing for the current RedactWall offer.

Limits to keep in view

The market governance workflows are planned until release-specific current evidence shows their customer readback. This guide makes no legal-sufficiency claim and no universal application-discovery claim.

  1. Do not count unverified assets as governed.
  2. Keep observational inventory and enforcement status distinct.

Review the current Disclosures before relying on a capability.