AI Governance Control Plane
The AI Governance Control Plane is the evidence workbench for the AI feature. It is where your organization records the governance posture around AI systems: what they depend on, how they are evaluated, what tools they may use, which data flows exist, what incidents or warnings are being tracked, and what trust signals support continued operation.
This is separate from the main AI console. The main AI console focuses on registered systems, providers, profiles, authorizations, runs, suggestions, and reviews. The control plane focuses on broader governance evidence around those systems.
What you can manage
The control plane supports these record types:
| Record type | Use it for |
|---|---|
| AI BOM snapshot | A sanitized bill of materials for an AI system, including provider, profile, dependency, and control-pack references. |
| Shadow finding | A signal or observation that may later become a finding, risk, incident, violation, exception, or lifecycle review through the owning module. |
| Eval suite | A tenant-managed or catalog-imported set of evaluation or red-team checks, with provenance, applicability, and acceptance expectations. |
| Eval run | Evidence that an evaluation or red-team suite was run, including sanitized outcome and remediation references. |
| AI incident coordination record | AI-specific context for an incident, while final incident truth remains in the incident module. |
| Literacy assignment | Operating-instruction or training-linked evidence that owners, reviewers, operators, and administrators understand the AI use. |
| Tool asset | Inventory and authorization posture for external APIs, agents, MCP assets, connectors, and internal actions. |
| Data-flow entry | A sanitized ledger entry for provider calls, retrieval, embedding, tool use, evaluations, or watcher activity. |
| Portfolio metric | Calculated, manual, or attested metrics for value, cost, usage, review burden, or risk posture. |
| Trust posture signal | An explainable warning or posture signal such as missing evidence, stale evaluations, failed checks, or incomplete training. |
| Standards mapping | A tenant-managed or catalog-imported mapping from AI expectations to evidence, controls, evals, or impact records. |
| Impact assessment | Evidence about intended use, affected groups, mitigations, residual impact, owner, and review cadence. |
| Risk posture evidence | AI risk context and handoff evidence. It does not replace managed risks. |
| Data quality evidence | Evidence about datasets, context, OCR, retrieval, limitations, drift, and source-purpose fit. |
| Documentation card | A technical documentation, model card, or profile card summary with sensitive details kept separate. |
| Monitoring plan | Post-deployment monitoring expectations, thresholds, review cadence, fallback, and corrective-action posture. |
| Registry snapshot | A customer, public, or authority-facing snapshot assembled from approved governance evidence. |
How to use it
Open AI Governance in the workspace navigation when the AI feature is enabled.
- Select the relevant view: Overview, Operations, Evaluation, or Assurance.
- Create a record and choose the record type.
- Link it to an AI system when the evidence is system-specific.
- Use a stable record key and a clear label so the record can be referenced in reviews and audit packages.
- Add only sanitized evidence references and summaries. Do not paste raw prompts, provider responses, source document text, extracted values, credentials, tokens, or storage paths.
- Confirm the governed reason for the change.
- Use View details to inspect the sanitized record fields and the audit-backed Activity trail.
Encrypted detail can be stored for sensitive context, but it is not displayed in the generic detail dialog. Use source modules and approved evidence records for source truth.
What the control plane is not
The control plane does not replace the governed modules that own final truth:
- final risks stay in Risks;
- final findings stay in Findings;
- final incidents stay in Incidents;
- final violations stay in Violations;
- final exceptions stay in Exceptions;
- final obligations and controls stay in their owning governance modules;
- final evidence claims stay in Evidence;
- final documents stay in DMS and Document Governance;
- final lifecycle, review, approval, change, trace, and audit behavior stays with the shared governed foundations.
AI control-plane records should be treated as posture, evidence, candidates, mappings, or signals until an owning workflow converts or approves them.
Evaluations and standards
Novantra does not assume one universal evaluation suite or one fixed AI standard is right for every organization. Evaluation suites and standards mappings are tenant-managed or catalog-imported governance assets. Your organization decides which suites are required, recommended, optional, or not applicable for each AI system, provider, profile, tool, context index, or watcher.
Novantra-provided packs can be useful baselines, but the product should show provenance and version context. A record in the control plane is evidence of posture; it is not, by itself, a legal, regulatory, clinical, or certification claim.
Deployment posture
AI Governance is part of the optional AI feature bundle.
- AI-enabled Cloud and Sovereign deployments include the AI Governance page, AI provider governance, Document Intelligence, Governance Copilot, and AI control-plane records.
- No-AI Sovereign profiles physically exclude AI feature routes and package dependencies. Organizations that choose this profile do not receive the AI Governance UI or AI runtime code in that image.
- If a Sovereign customer later chooses to add AI, they should move through the supported AI-enabled upgrade path and configure provider credentials, authorizations, and governance records before enabling production use.
Cloud and Sovereign deployments both keep provider credential material outside normal AI records and UI payloads. Raw provider errors, prompts, source text, and provider responses are not shown in Activity or audit metadata.