AI governance that treats models
like any other control.
Register the models, prompts and MCP servers you actually run, score them with judged evaluations, and evidence the results against the AI regimes the same way you evidence a firewall rule: from live state, not from a document somebody maintains by hand.
What it does
- Model, prompt and MCP server registry
- Judge-scored evaluation runs with stored transcripts
- Drift and bias monitoring over time
- EU AI Act risk classification per system
The inventory is the hard part
Under the EU AI Act every obligation attaches to an individual AI system, and your role can differ from one system to the next: you can be a deployer of four and a provider of one in the same quarter. None of that can be determined for systems nobody has listed.
In practice the inventory is where the time goes. Models arrive embedded in product features, bought as SaaS, wrapped around a foundation model API, and fine-tuned by a team that never thought of it as procurement. A line saying “we use AI in support triage” is not an inventory; a record naming the system, its purpose, its provider, its data and its outputs is.
Evaluations that leave a record
An evaluation that produces a number and discards the transcript cannot be evidence later. Runs here keep what was asked, what came back and how the judge scored it, so a regulator or customer asking why a system was considered fit for purpose in March gets the March answer rather than today’s.
Scores are tracked over time rather than as a single snapshot, because drift is the failure mode that matters: a model that passed at launch and degrades quietly is the case documentation written once will never catch.
A certificate is not a declaration of conformity
ISO 42001 certifies a management system. It says your organisation has a governance process. It is not, and cannot be, a declaration of conformity for any individual AI system under the EU AI Act: the Act asks system-level questions that an organisational certificate does not answer.
Teams conflate the two more often than any other point in this area, which is why it has a page of its own. What the two genuinely share is the control set underneath, and that overlap is real: access control, logging, incident response and change management carry straight across from SOC 2 or ISO 27001 into Articles 12, 15 and 17.
Where this sits
This is one engine of eleven on a single control graph, which is why a result produced here reaches every framework that asks for it instead of being gathered again under another heading. The platform overview shows the other ten, and coverage lists the regimes they answer.
Related reading: the ISO 42001 guide, the EU AI Act guide and what ISO 42001 certification does and does not cover.
The things people ask us
What can the registry actually hold?
Models, the prompts that drive them, and MCP servers, because in a real system the prompt and the tools a model can reach change its behaviour as much as the weights do. Registering only the model name describes very little of what you are running.
Does ISO 42001 certification satisfy the EU AI Act?
No, and treating it as equivalent is the commonest error here. ISO 42001 certifies a management system; the Act attaches obligations to individual systems and asks system-level questions a management certificate does not answer.
How are evaluations scored?
By a judge model, against criteria you set, with the full transcript retained alongside the score. Keeping the transcript is what makes the run usable as evidence months later rather than just a number in a dashboard.
Do we have to re-run everything for each release?
No, but substantial modification restarts parts of it, and the definition is broader than teams expect: a change to intended purpose almost always counts, and retraining on materially different data often does. Generating documentation from live state is what keeps that manageable.
How much overlaps with our existing security work?
More than most teams assume. Access control, logging, incident response, vendor management and change management are already in your SOC 2 or ISO 27001 programme and reach Articles 12, 15 and 17 directly. The genuinely new work is classification, Annex IV documentation, oversight design and post-market monitoring.
Your next audit could be a link.
Thirty minutes. We connect one cloud account live and show you real evidence landing in the ledger before the call ends.