Governance Copilot

The Governance Copilot is Novantra’s in-product AI assistant for governance work. It can draft, summarize, analyze, and propose actions across the governance program. What it does in any given workspace is shaped by Copilot profiles: configured personalities and capabilities, each scoped to a purpose and bounded by action policies.

A Copilot profile is the lens through which a member uses Copilot for a particular task. A profile for “draft a control description” is different from a profile for “summarize this audit engagement” and different from a profile for “propose a remediation plan.” Each profile has its own prompts, retrieval sources, and constraints. Each profile version is a controlled, published artifact.

When you would reach for this

You configure Copilot profiles when:

• Different parts of your organization need different Copilot behavior for different tasks.
• A new use case for Copilot is being introduced (drafting policies, summarizing assessments, analyzing risk trends).
• An existing profile needs revision (better prompts, new retrieval sources, tighter constraints).
• A profile needs to be retired (the use case is no longer relevant, or it’s been replaced).

You don’t configure profiles for low-level model parameters or for the underlying provider connection. Those live in AI Providers. Profiles are the user-facing capability shape.

What lives in a profile

Two record types:

Copilot profile is the named capability (“Draft control description,” “Summarize assessment,” “Analyze risk register trend”). It carries a title, a stable key, a kind (free text), an owner, and the high-level purpose.

Profile version is a specific revision of a profile: prompts, retrieval sources (which workspace data the profile reads from), constraints (data categories permitted, output style, action policy scope), test cases, and a published/retired status.

A profile typically has many versions over its lifetime. Only one version is “current” at a time, but old versions remain readable for evidence purposes (an audit may ask which version produced a specific output).

A worked example: a municipal authority configures Copilot for board governance work

A municipal authority (a city government) runs a governance program covering its boards and committees, its compliance posture, and its operational reporting. The director of corporate services, Hilda, wants Copilot to help with specific board-governance tasks: drafting meeting agendas, summarizing decisions, drafting policy revisions, analyzing decision patterns over time. Each is a different profile.

Step 1: define profiles per use case.

• board-agenda-drafting — Copilot drafts a board meeting agenda from prior meeting outcomes, open action items, and standing items.
• decision-summarization — Copilot summarizes board decisions for the meeting record from minutes input.
• policy-revision-drafting — Copilot drafts revisions to a policy document from the source policy and the change brief.
• decision-pattern-analysis — Copilot analyzes patterns in board decisions over time and surfaces themes.

Each profile is registered with its title, key, kind, owner.

Step 2: define the first version of each. For board-agenda-drafting, the version captures:

• The base prompt template (instruction to Copilot about role, audience, output structure).
• Retrieval sources: prior meeting outcomes (filtered by date), open action items, the standing-items list.
• Constraints: format as a structured agenda; never include personal identifying information from non-public records; output is always a draft (never a final).
• Action policy: this profile can only suggest a draft; it cannot apply or commit anything.
• Test cases: a handful of expected inputs and the kind of output expected.

Each other profile gets its own version with appropriate prompts, sources, constraints.

Step 3: publish. Once a version is reviewed by the AI governance committee, it’s published. The profile becomes available to authorized members (per Use Authorizations).

Step 4: live operation. Members invoke Copilot through the profile most appropriate to their task. The board secretary uses board-agenda-drafting before each meeting. The same secretary uses decision-summarization after each meeting. The director uses policy-revision-drafting when commissioning policy revisions. The CISO uses decision-pattern-analysis for annual board reporting.

Step 5: profile evolution. Six months in, Hilda’s team has learned what works. They revise the prompts, add retrieval sources (the public services strategic plan as additional context for policy revisions), and publish new versions. Old versions are retired (or kept as fallback if needed).

After a year:

• Each board-governance task has a published Copilot profile with documented prompts, sources, constraints.
• Every Copilot invocation is recorded with the profile version that produced it.
• A governance review can show: this output, on this date, came from version X of profile Y.

What you’ll see in the product

Governance Copilot lives under Governance → AI Governance → Copilot Profiles in the workspace.

The Profiles list shows every profile with its kind, current published version, owner, recent invocation count.

Inside a profile, you see:

• The full record and owner.
• All versions with their status (draft / published / retired) and publication timestamps.
• Recent invocations (link into Runs & Evidence).
• Activity history.

Inside a version, you see the prompt template, retrieval sources, constraints, action policy reference, test cases.

Every change is captured in the workspace Audit Log.

Profile versioning

Profile versions matter because:

• The exact prompt, retrieval, and constraints that produced any historical output are reviewable. An auditor asking “why did Copilot produce this output last quarter” can be answered with the version snapshot.
• Iterating on prompts is safe; old versions remain for fidelity.
• Publication is deliberate. New versions don’t go live silently.

Common workflows

Creating a new profile

1. Copilot Profiles → New profile. Title, key, kind, owner.
2. Create a first version: prompt, retrieval, constraints, action policy reference, test cases.
3. Route for review by the AI governance committee.
4. Publish.
5. Define authorizations for members who’ll use the profile.

Revising a profile

1. From the profile, create a new version starting from the current.
2. Iterate on prompts, sources, constraints. Run test cases.
3. Publish the new version. The previous version is retired (or kept as inactive).

Retiring a profile

1. Retire the current published version.
2. The profile no longer accepts invocations.
3. Historical invocations remain visible.

Related

• AI Systems - the underlying registration of the Copilot capability.
• Use Authorizations - who can use which profile.
• Action Policies - what each profile can do.
• Runs & Evidence - every Copilot invocation produces evidence.
• Document Intelligence - the sibling capability for document understanding.