What it does

Six capabilities, and they feed each other

The register is the spine. Classification tells you what the law asks of each system; the gap tracker tells you what the standard asks of the organisation; evidence proves it; the documents are what you hand over. Nothing here is a separate silo you have to keep in step by hand.

1 · The AI system register

Every AI system your organisation builds or uses, in one list. For each one: what it does, who owns it, whether you are its provider (you develop it or put your name on it), its deployer (you use it under your authority) or both, and where it is in its life — planned, in development, in use, or retired.

That distinction is not bureaucracy. Under the EU AI Act, a provider and a deployer of the same system carry different obligations, and the register is where you decide which you are before anybody asks.

Retiring is not deleting

A retired system stays on the register with its history intact, which is what you want when an auditor asks what you were running in March. Deleting is for a mistake.

The AI system register listing seven systems with columns for role, lifecycle, EU AI Act tier, owner and last updated. — Illustration Seven systems, their role, their lifecycle stage and their EU AI Act tier. Two are not classified yet, and the register says so rather than assuming they are harmless.

2 · EU AI Act classification

Seven questions per system. Do you provide it or deploy it? Does it do anything Article 5 prohibits? Is it a safety component of a regulated product? Does its purpose fall in an Annex III high-risk area? Does the Article 6(3) narrow-task derogation apply? Do any Article 50 transparency triggers apply? Do you provide a general-purpose AI model?

The answers resolve to a tier — prohibited, high, limited or minimal — and a list of the obligations that follow, each with its article. A provider of a high-risk system gets twelve; a deployer gets seven; transparency and GPAI obligations layer on top of any tier.

The classification wizard asking whether a system's intended purpose falls in an Annex III high-risk area, with four options and explanatory help text. — Illustration One question at a time, with the plain-language help underneath. The derogation question only appears once an Annex III area has been named, because until then it means nothing.

The classification result for a candidate ranking system: high risk, with twelve provider obligations listed against articles 9 to 73. — Illustration The result, with every obligation and its article. Where the Act is ambiguous the engine takes the safer tier and flags the system for review rather than guessing in your favour.

It is a structured aid, not a legal determination

The app says so on the result itself. It organises obligations under Regulation (EU) 2024/1689 so you can act on them; it does not tell you that you comply, and where the Act is ambiguous it deliberately errs high.

3 · The ISO/IEC 42001 gap tracker

65 controls: 27 from clauses 4 to 10, and 38 from Annex A. Each carries a status — not started, in progress, implemented, or not applicable — an owner, free-text notes, and the evidence attached to it.

Controls marked not applicable are excluded from the denominator rather than scored as zero, which is how a Statement of Applicability is supposed to work. Your readiness figure is over the controls that actually apply to you.

Every change is recorded: who moved a control, from what to what, and when. That history is append-only — nobody can edit or delete it, including a Jira administrator, because a history that can be tidied is not evidence.

Control 6.1.2 AI risk assessment showing status in progress, notes, owner Tom Iyer, two evidence records and three history entries. — Illustration A control, opened: its status, who owns it, the notes explaining where it stands, the evidence behind it, and every change anyone has made to it.

4 · Evidence

An evidence record is what proves a control is in place: a title, a description, who owns it, when it was last confirmed still true, a link to where it lives, and the controls it covers.

The app stores the reference, not the file. Your policy stays in Confluence, or SharePoint, or wherever your organisation already keeps it — with the permissions and the retention it already has. That is a deliberate decision, not a limitation: an app that holds your governance documents has taken on retention, deletion and export obligations that a link does not.

The link is optional, because some evidence genuinely is a signed policy in a filing cabinet, and a form that demands a URL for that gets a URL somebody made up.

The evidence form with fields for what it is, where it lives, notes, last reviewed and owner, plus the controls it covers, grouped by clause and Annex A section. — Illustration Recording evidence. The form says plainly that no file is stored — somebody expecting to upload a PDF should learn that here, not from support.

5 · The readiness self-assessment

18 questions across 6 weighted domains — governance and accountability (18%), AI inventory and classification (22%), risk and impact assessment (22%), data and privacy (13%), transparency and oversight (12%), and operations, security and monitoring (13%).

Each question is answered on a four-level maturity scale: none, ad hoc, defined, managed. About five minutes. It produces a weighted score, a band, a per-domain breakdown and a short list of where to start.

Every run is kept. Re-run it each quarter and the movement is the point — it is the artefact that shows a board the programme is working, which a control checklist does not.

A self-assessment result of 72% on track, with per-domain bars and a where-to-start panel naming transparency, operations and risk. — Illustration The result: a weighted score, the six domains ranked, and the three weakest with a specific next action for each.

6 · Documents

6 documents, generated from your own data:

AIMS Policy — the policy Clause 5.2 asks for, scoped to the systems on your register.
Statement of Applicability — every Annex A control, whether it applies, and why not where it does not.
AI Risk Register — the risks your classifications imply, and how each is being treated.
AI System Register — the inventory, with each system's role and tier.
AI System Impact Assessment — one per system, which is what Clause 6.1.4 and Article 27 both assume.
Roles & Responsibilities — who holds what access, and who granted it.

Each version is an immutable snapshot. Generate the Statement of Applicability today and again in March, and the first one still shows what was true today — which is the only reading of "version history" an auditor accepts.

A printable Statement of Applicability showing the organisation name, version and generation date, an introduction, and a table of Annex A controls with applicability and status. — Illustration A generated document, ready to print. The audit pack opens in its own tab, outside Jira's navigation, with a print stylesheet, so what comes out is a document rather than a screenshot of a tool.

Have a look at it properly

The user guide walks through all six, end to end, with the screens as you will meet them.

Email us for early access

The Marketplace listing is not published yet, so there is nothing to link to. Email us and we will tell you the day there is.