The AI register says what AI you run.
XGRC says whether it's governed.

The law does not treat all AI the same. A handful of uses are banned outright. A defined set is "high-risk" and carries heavy obligations. Some systems only need to tell people they are talking to a machine. Most are left alone entirely.

This module decides which of those applies to each of your systems. The decision matters enormously — it determines everything you owe for that system — so the module records not just the answer but the reasoning and the legal references behind it, in a form you can defend to a regulator years later.

1. Choose the AI system being assessed.
2. State your role for it. Are you the one who built or badged it, or the one using someone else's? The law imposes very different duties on each.
3. Answer a guided series of questions. Each answer decides what comes next, so you are never asked about things that do not apply to you.
4. The module first checks for banned uses. If it finds one, it stops there and raises it — nothing else matters until that is resolved.
5. If not banned, it determines whether the system is high-risk, and records exactly which part of the law makes it so.
6. It checks whether you owe people transparency — telling them they are dealing with AI, or that content was generated.
7. It checks whether the general-purpose AI model rules apply.
8. It produces a result: the category, the reasoning, and the legal basis.
9. From that result it automatically builds the list of requirements you now have to meet, so nobody assembles it by hand.
10. Someone senior approves the classification. It is then locked and stamped with the version of the questions used.
11. If the system later changes in a way that could alter the answer, it is flagged for re-classification rather than quietly going stale.

Why step 2 matters more than it looks. If you take someone else's AI, substantially modify it, change what it is used for, or put your own name on it, the law can treat you as the manufacturer — and you inherit the full obligation set. Organisations routinely cross that line without realising.

Knowing which rules apply is only half the job. You then have to show whether you meet them, item by item, with evidence. This module holds each framework as a structured set of requirements, decides which genuinely apply to you, records your position against each, and gathers the proof.

It also produces the Statement of Applicability — the document an ISO 42001 auditor asks for first. It lists every control in the standard and states whether you apply it or exclude it, with a reason for each. Without it, a certification audit does not meaningfully begin.

1. Pick the AI system and the frameworks in play — the EU AI Act, ISO 42001, data protection law, your own internal policy.
2. The requirement list loads, including anything the classification module determined applies.
3. For each requirement, mark whether it applies to you. If it does not, you must say why — an unexplained exclusion is one of the easiest ways to fail an audit.
4. For each requirement that does apply, record where you stand: met, partly met, not met, or not yet assessed.
5. Attach the evidence — a policy, a test result, a log extract, a training record, an approval.
6. Where there is a shortfall, raise an action against it with an owner and a deadline.
7. The module calculates your overall position and shows where the weight of the gap sits.
8. For ISO 42001 it produces the Statement of Applicability directly from those decisions.
9. Someone approves the assessment. It is versioned and locked.
10. A review date is set. When it falls due — or something changes — a new version starts, and the approved one stays untouched as the historical record.

Compliance asks whether something is permitted. Impact assessment asks a harder question: who does this affect, and what could it do to them? That includes people who never chose to interact with it — a job applicant screened by a model, a patient triaged by one, a community affected by a decision.

This covers both the ISO impact assessment and the Fundamental Rights Impact Assessment the AI Act requires of certain organisations using high-risk systems.

1. Start an assessment for a system, noting where it is in its life — being designed, tested, running live, or changing.
2. Identify who is affected: employees, customers, the public — and specifically anyone vulnerable, such as children, patients or applicants.
3. Work through the areas where harm can arise: privacy, bias, discrimination, safety, financial loss, dignity, accessibility, employment, environment.
4. For each one, describe what could happen, what would cause it, and who it lands on.
5. Rate it as it would be with no safeguards at all — how likely, and how severe.
6. Record what you already have in place to reduce it.
7. Rate it again with those safeguards counted.
8. Decide whether what remains is acceptable. If it is not, treatment is required and actions are raised.
9. Someone approves it, and the assessment is versioned.
10. It is revisited when the system changes, when something goes wrong, or when its review date arrives.

Rating twice is the point. Scoring before and after safeguards is what shows your controls are doing real work. A single score proves nothing about whether you have earned the position you are claiming.

A control is something you actually do to keep an AI system safe — a review step before release, a bias test, a restriction on what data it can reach, a log of every decision it makes. The awkward part is that one control usually satisfies several different rules at once, across several different frameworks.

So the module keeps a single library, maps each control to every requirement it helps satisfy, and holds the evidence once. You define the control once and it answers to all of them.

1. Create a control, or adopt one from the library.
2. Map it to every requirement it helps satisfy — it can answer to the AI Act, ISO 42001 and your own policy simultaneously.
3. Assign it to the AI systems it covers, with an owner and how often it must be tested.
4. Assess it in three separate ways: is it well designed, is it actually in place, and is it working? These are different questions, and a control can pass one while failing another.
5. Attach the evidence — the test result, the log, the sign-off.
6. Evidence carries a validity period, so proof that has gone stale is visible instead of quietly assumed good.
7. Where a control is weak, missing or untested, raise an action.
8. Because of the mapping, a failing control instantly shows every requirement now exposed — across every framework at once.

For high-risk systems the law requires meaningful human oversight: someone competent who understands the system, can interpret what it produces, and has the authority to override it or stop it. Crucially, you must be able to prove this happened. A policy saying oversight exists is not evidence of oversight.

This module records the oversight itself — and works whether that oversight happens inside XGRC or in a separate system the organisation already uses.

1. Define the arrangement for a system: who oversees it, what authority they hold, and what training qualifies them.
2. Record oversight events as they happen — a review, an approval, an override, a suspension.
3. Where oversight happens in another tool, connect it and events flow in automatically. Where there is no such tool, people record them here directly.
4. Each event captures who acted, when, what was in front of them, and what they decided.
5. Overrides and interventions are highlighted — those are the events that prove the oversight is real rather than nominal.
6. Each record links back to the system, its classification, and the requirement it satisfies.
7. Absence is visible: a high-risk system with no oversight events stands out immediately.
8. Oversight activity feeds the monitoring picture and the management review.

AI introduces failure modes conventional risk registers were not written for: biased outputs, confident fabrication, data leaking through a model, performance drifting as the world changes, staff trusting the machine more than they should, a provider disappearing.

Rather than a separate AI risk system, this uses the risk engine and scoring you already have. AI risk then sits alongside every other business risk, in the same register, scored the same way — visible to the same board report instead of hidden in a silo.

1. Raise a risk and tag it to an AI system and an AI risk category.
2. Describe it exactly as you describe any other risk — the risk, its cause, its consequence.
3. Score it before controls.
4. Link the controls that address it.
5. Score it again with those controls counted.
6. Compare what remains against your tolerance. Over the line means treatment is required.
7. Assign an owner, a treatment plan and actions.
8. Set a review date.
9. Risks can also arrive automatically — raised by an impact assessment, an incident, a monitoring breach, or a change to the system.

When an AI system causes harm — a wrong decision, a discriminatory outcome, a data leak, a safety event — you need to capture it, understand it, fix it, and in some cases tell a regulator within a short and legally fixed window.

The deadlines are the part organisations most often miss. So the reporting clock is part of the record from the moment the incident is logged, not something remembered later.

1. Log the incident against the AI system, recording which model version was running at the time.
2. Classify what kind of incident it is and how severe.
3. Assess immediately whether people were affected, how many, and whether a regulator must be notified.
4. If notification is required, the clock starts and the deadline is tracked in plain sight.
5. Decide whether the system should be suspended while you investigate.
6. Investigate and establish the root cause.
7. Raise corrective actions.
8. Feed the outcome back: does the risk assessment need redoing? The impact assessment? The compliance position?
9. Close the incident only once those reassessments are complete.
10. The whole chain stays on that system's record permanently.

AI systems change constantly — a new model version, a new data source, a different provider, a widened purpose, more autonomy. Most changes are harmless. A few quietly turn a low-concern system into a regulated one, and the organisation carries on as though nothing happened.

This module catches every change, judges it in governance terms, and forces the reviews that the change actually warrants.

1. A change arrives — raised by someone here, or picked up automatically from the AI register.
2. It is described in governance terms rather than technical ones: did the purpose change? The model? The provider? What data it can reach? How independently it acts?
3. Rules decide what that means. A new sensitive data source demands a risk review. A changed purpose demands a full reassessment. More autonomy demands an oversight review.
4. The required reviews are created automatically and assigned to owners.
5. Until they are done, the change stays visibly open against that system.
6. Where the change is significant enough, approval is required before it can proceed.
7. The reviews complete, the affected assessments update, and the change closes.
8. Everything is retained — what changed, what it triggered, and who decided.

This is the module that keeps the rest honest. Every other assessment is a snapshot of a system at a point in time. Without change governance, those snapshots silently describe a system that no longer exists.

Every module above looks at individual AI systems. This one looks at the company. ISO 42001 certifies an organisation, not a product: does it have an AI policy, named accountable people, measurable objectives, competent staff, internal audits, and management that reviews all of it regularly?

This is what an auditor examines when deciding whether to certify you, and it is the piece most AI governance tooling leaves out entirely.

1. Define the scope — which parts of the business, and which AI systems, the management system covers.
2. Record the context: the pressures you operate under, and who has a stake in how you use AI.
3. Publish the AI policy and its supporting policies, held under proper version control.
4. Name the roles — who owns AI governance, risk, compliance, data and security.
5. Set measurable objectives and track progress against them.
6. Record competence and awareness, including the AI literacy obligation that has applied since early 2025.
7. Run internal audits to a programme, and record what they find.
8. Hold management reviews on a schedule, with the inputs the standard requires — risk position, incidents, audit results, objectives, regulatory change.
9. Record the decisions and actions that come out of those reviews.
10. Handle anything that fell short through corrective action, and show it was closed out.

The dashboard answers "how are we doing overall?". The system profile answers "what is the complete story on this one system?". Between them they are the view an executive, an auditor and a regulator each want.

Neither holds any data of its own. Everything is drawn from the modules above, so nothing is ever maintained in two places or allowed to disagree with itself.

1. Open the dashboard and see the estate: how many AI systems, how many live, how many high-risk, how many overdue an assessment.
2. See the position across compliance, risk, impact, controls, incidents and monitoring together.
3. Each system carries a simple health status — green, amber or red — driven by rules you set rather than a fixed formula.
4. Drill from the whole organisation, down to a business unit, down to a single system.
5. On a system's profile, see everything about it on one page: classification, assessments, risks, controls, oversight, incidents, changes, actions, documents and its full history.
6. Anything overdue, breached or unassessed surfaces without anyone having to hunt for it.
7. Export for a board pack, an audit, or a regulator.

The technical detail of what AI you run — the systems, the models, the providers, what each one is permitted to reach — lives in the separate AI register, not in XGRC. That separation is deliberate: one system of record, not two competing ones.

This module keeps XGRC's reference copy current, so every piece of governance attaches to the right system, and so changes made over there surface here as something to review.

1. The register remains the authority on what AI exists.
2. XGRC pulls the list in on a schedule, on demand, or is notified the moment something changes.
3. Each system gets a reference record here. Imported details are read-only — you change them where they are owned, not in two places.
4. Each is mapped to a business unit and an owner, so your existing access rules apply automatically.
5. Every governance record in every module attaches to that reference.
6. When something changes in the register, XGRC records the change and decides whether it needs a governance review.
7. When a system is retired, its reference is deactivated — but its entire governance history remains, permanently.
8. If the register cannot be reached, XGRC carries on using its last known copy and shows plainly when it last synchronised.