AI Systems

An AI system in Novantra is one registered, governed AI capability available in your workspace. The in-product Governance Copilot is an AI system. Document Intelligence is an AI system. A third-party assistant your organization has integrated may be another. Each registered system has a name, a kind, a status, owners, evidence links, and a defined lifecycle.

Registration is the first step in governing AI use. An AI capability that isn’t registered isn’t invocable. An AI capability that’s registered but not authorized for a given member can’t be invoked by that member. Registration + Use Authorization is the gate.

When you would reach for this

You register AI systems when:

• Your organization is rolling out Novantra’s in-product Governance Copilot and wants it under formal governance from day one.
• Document Intelligence is being enabled for one or more document types.
• A third-party AI assistant or agent is being integrated into governed workflows.
• An auditor or regulator asks “show me the inventory of AI systems your organization operates.”

You don’t reach for this for provider connections (those are in AI Providers) or for authorizing who can use what (that’s Use Authorizations). AI Systems is the registry.

What lives in an AI system

A single composite record:

AI system carries:

• A display name and a stable key.
• A kind (copilot, document-intelligence, assistant, agent, etc.).
• A status walking through proposed, validated, active, suspended, retired, archived.
• An owner (a responsibility assignment accountable for the system).
• A system snapshot with structured posture: purpose, scope, data handling, model dependencies.
• Links to evidence claims that support the system’s governance (DPIA, model card, supplier assurance, internal review).
• A link to the underlying AI provider connection when applicable.

Status lifecycle

A worked example: a health insurer registers its AI capabilities

A health insurance carrier wants to use AI for claims processing assistance, member-facing FAQ summarization, and an internal underwriting copilot. Before any of these go live, the AI governance lead, Camila, registers the systems.

Step 1: register each system.

• claims-processing-assistant — kind copilot, purpose drafting initial review notes for adjusters.
• member-faq-summarizer — kind document-intelligence, purpose summarizing policy documents for member-service tone.
• underwriting-decision-support — kind copilot, purpose surfacing similar-case precedents for underwriters.

Each registration captures the name, key, kind, the owner (the relevant business area’s accountable manager), and a system snapshot describing purpose, in-scope data categories, expected outputs, model dependencies.

Step 2: link to evidence. For each system, Camila links:

• The DPIA performed before the system was approved (from Privacy).
• The supplier assurance review of the underlying AI provider (from Party Engagements).
• The internal model risk review (an Assessment).
• The model card from the provider (an Evidence claim).

These evidence links are what an auditor will examine when they ask “what governance was performed before this AI system went live.”

Step 3: validate. The AI governance committee reviews the registrations and the linked evidence. Each system transitions from proposed to validated with a captured sign-off.

Step 4: activate. As each system’s authorizations are defined (next page), the system moves to active and is available for invocation by its authorized members.

Step 5: ongoing governance. Systems may be suspended (the provider notifies of an issue; the team suspends use while it’s investigated) and resumed. Systems may be retired (a better internal alternative replaces an external one; the external one retires and authorizations terminate).

After a year, the AI systems register is the organization’s audit-grade inventory: every AI capability in use, with its purpose, owner, governance evidence, and authorization scope.

What you’ll see in the product

AI Systems lives under Governance → AI Governance → AI Systems in the workspace.

The Systems list shows every registered system with its kind, status, owner, current authorization count.

Inside a system, you see:

• The full record, snapshot, and owner.
• Status history with audit trail.
• Linked evidence claims.
• Linked authorizations.
• Linked audit packages and oversight rollup.
• Recent runs (link into Runs & Evidence).
• Activity history.

Every change is captured in the workspace Audit Log.

Common workflows

Registering a new AI system

1. AI Systems → New system. Pick the kind, name, key, owner. Capture the system snapshot.
2. Status starts proposed.
3. Link the evidence that supports validation (DPIA, supplier assurance, model card, internal review).
4. Validate; transition to validated.
5. Define authorizations via Use Authorizations.
6. Transition to active once authorizations are in place.

Suspending a system

1. From the system, transition to suspended with rationale (provider issue, governance review).
2. Authorizations remain but invocation is blocked until resumed.
3. When resolved, transition back to active.

Retiring a system

1. Transition to retired. Existing authorizations terminate.
2. The system record remains for historical context and audit.

Related

• Use Authorizations - the next step after registration.
• AI Providers - registered systems often reference a provider connection.
• Action Policies - what registered systems are allowed to do.
• Runs & Evidence - every invocation produces evidence.
• Evidence - registration evidence (DPIA, model card, supplier assurance) lives here.