Skip to main content

PRODUCT · AI Governance & Control Evidence

AegisIQ AI Governance Workbench

A governance accelerator for AI inventory, risk classification, approval workflows, control evidence, and compliance readiness.

At a glance

The short answers.

What is it?
PRODUCT · AI Governance & Control EvidenceAegisIQ is a configurable governance capability implemented within the client environment, combining system registers, classification models, approval workflows and evidence structures.
Who is it for?
CISO / Risk / Compliance
What problem does it solve?
AI governance that lives in policy documents produces no evidence, and evidence is what boards, auditors, and regulators ask for.
What does it actually do?
A practical workbench of registers, workflows, and evidence models aligned to ISO 42001 and regulatory expectations.
Where does it run?
Your environment, alongside the systems it records. It holds references and evidence rather than copies of the data those systems hold.
What evidence does it produce?
A populated register, classification decisions with the rule that produced them, approvals against evidence, exception records with expiry dates, incident entries and review history.
What does the client receive?
  • Populated AI system register
  • Risk classification model
  • Approval and intake workflows
  • Evidence and reporting pack
How are controls enforced?

Through review and approval gates: each system is risk-classified, then approved against proportionate controls with a human sign-off and conditions of use.

The governance architecture →
How is evidence created?

By the controls themselves: each produces a record attached to the system and the decision, rather than assembled from emails afterwards.

Ten things governance needs →
How do we detect failures?

Through ongoing monitoring of behaviour and drift, re-assessment triggered whenever a system changes, and a board-grade oversight dashboard.

The reference architecture →

AI governance control-plane

An AI governance architecture.

How AI use-cases get registered, risk-classified, governed, and evidenced, aligned to the EU AI Act and ISO 42001.

  1. Intake & register

    Every AI use-case enters through a gate and lands in a living system register with a named owner.

  2. Classify & map

    Each system is risk-classified and mapped to EU AI Act and ISO 42001 obligations.

  3. Govern & approve

    Review and approval gates apply proportionate controls, with a human sign-off and conditions of use.

  4. Evidence the controls

    Controls are bound to policy and produce inspectable evidence, not just documents.

  5. Monitor & report

    Behaviour, incidents, and re-assessments feed a board-grade oversight dashboard.

Example output

Reference architecture.

REFERENCE ARCHITECTUREAI governance control-plane

Intake & registration

Use-case intakegoverned gate
AI system registerliving inventory
Ownership assignmentaccountable owner

Classification

Risk classificationtiered by impact
Regulatory mappingEU AI Act · ISO 42001
Control selectionproportionate

Governance workflow

Review & approvalgated
Sign-offhuman decision
Conditions of useconstraints

Evidence & controls

Control librarymapped controls
Evidence captureinspectable
Policy bindingenforced

Monitoring & oversight

Ongoing monitoringbehaviour + drift
Re-assessment triggerschange-driven
Leadership dashboardboard-grade view

Control plane

Audit trail
Access control
ISO 42001 alignment
EU AI Act mapping

Illustrative reference architecture · representative stack, adapted per engagement · no client data shown.

What it operationalises

Ten things governance needs to be more than a policy.

It helps organisations operationalise AI governance workflows, control evidence and oversight: the register, the classification, the approvals and the record.

  1. 01

    AI system inventory

    What exists, where it runs, what it touches and who owns it. Governance with no inventory is a policy about systems nobody has listed.

  2. 02

    Use-case intake

    A front door: proposed AI use cases arrive somewhere, with a named owner and enough detail to be classified.

  3. 03

    Risk classification

    Applied by a stated rule rather than a judgement call, so two similar systems are classified the same way by different people.

  4. 04

    Ownership

    A named business owner per system, distinct from the team that built it and from the team that runs it.

  5. 05

    Approval workflow

    Who approves what, at which gate, against which evidence, and what an approval means when it is given.

  6. 06

    Control mapping

    Which controls a system is subject to, mapped once across frameworks rather than answered again for each one.

  7. 07

    Evidence

    The record each control produces, attached to the system and the decision rather than assembled from emails afterwards.

  8. 08

    Incidents

    What went wrong, what was done, what changed as a result, linked to the system it happened to.

  9. 09

    Periodic review

    A date on every classification and approval, because a decision made about last year’s system is not a decision about this one.

  10. 10

    Executive oversight

    The portfolio view: what is live, at what risk, with what outstanding exceptions and which are past their expiry.

Where the work happens

Five surfaces.

Described rather than screenshotted, for the same reason: the imagery waits on approved assets, and a governance workbench is the last place to ship an invented record.

  1. 01

    AI system register

    Every AI system with its owner, classification, data sources, model version and current status.

  2. 02

    Risk assessment

    The classification applied to one system, with the rule that produced it and the answers it was based on.

  3. 03

    Workflow

    Intake to approval: where a use case is, who it is waiting on, and what it still needs.

  4. 04

    Evidence record

    What was produced for a control, by which run, when, and where the artefact is.

  5. 05

    Management dashboard

    The portfolio: systems by risk, approvals outstanding, exceptions approaching expiry, incidents open.

What we will not claim

It does not make an organisation compliant, and we will not say that it does. Compliance is a judgement an auditor or a regulator makes about you; what a workbench can do is make sure the evidence for that judgement exists, is current, and can be produced on request.

In practical terms

What gets installed, what you own, and how it connects.

The seven first questions are answered at the top of the page. These are the three a buyer asks next.

What gets installed or configured?
The AI system register, the risk classification model, use-case intake and approval workflows, control mappings and the evidence model behind them.
What do you own afterwards?
The register, the classification model, the workflows and every record in them. The evidence is yours to produce to an auditor, with or without us.
How does it connect to Captivolt services?
It is the record side of the ASSURE lifecycle: stage 05 Approve, and the governance record every other stage writes to. AI Quality, Governance & Security →

Modules

What is inside.

  • AI system register
  • Risk classification
  • Use-case intake
  • Governance workflow
  • Evidence model
  • ISO 42001 readiness
  • Regulatory alignment
REAL WORK
RELATED · ASSURE · Regulated & Listed Enterprises

See AegisIQ in Action.

We will walk through the architecture and how it maps onto your environment.