The record an auditor would ask for.
Assettia is the data and AI programme record: one place where an organisation keeps what its programme owns, what it has decided, and what it has proved.
Most organisations keep their AI risks in a spreadsheet. It holds the risks. It cannot say which use case introduced one, what the regulatory label rests on, who was told when a review fell due, or what the position was on the day the board signed it off. This page sets out what Assettia holds instead, and where each answer comes from.
- Official sources
- 20
- legislation and guidance held
- across six regulatory dimensions
- Checked every
- 7 or 30 days
- guidance, then legislation
- by a scheduled job, approved by a person
- Standards mapped
- 4
- clause by clause
- ISO/IEC 42001, ISO/IEC 23894, NIST AI RMF, the EU AI Act
- Steps in the rhythm
- 12
- each with an owner and a deadline
- adopted and tuned per organisation
Eight questions a spreadsheet cannot answer
| The question | A spreadsheet register | Assettia |
|---|---|---|
| Which use case or data asset introduced this risk? | A free-text cell, if anyone typed it | A link created at the moment the risk is created. A risk cannot exist without one |
| What does the regulatory label rest on? | Someone's recollection | The approved capture of the official text, with the date it was approved |
| Who owns it, and were they told when the review fell due? | An initials column. Nobody was told | A named owner, an alert to the person the workspace named, logged as a record |
| What changed since the last review, and who changed it? | Version history, if the file is in a shared drive | An append-only history of every edit: who, when, and the previous values |
| Is this one risk or the same risk five times? | Five rows | One canonical risk with five linked instances and a count |
| What was the position on the day the board signed it off? | A copy of the file, if anyone kept one | An attestation snapshot frozen on that date and signed by a named person |
| Could the AI have made this up? | Unknown | No. Every suggestion is staged, reviewed and accepted by a person before it becomes a row |
| What is the process, and was it followed? | A policy document, elsewhere | A stated process with dated evidence per step, and a statement of what it does not cover |
How a risk gets on the record
A risk arrives one of two ways, and both end at the same gate.
A person raises it, from the register, from a use case or from a data asset, and it is linked to where it was raised. Or a model reads the use cases the team selects, with the data assets linked to them, and returns candidate risks across eight categories: bias and fairness, privacy and data, security and integrity, regulatory compliance, operational reliability, reputational, third-party, and governance.
What a model returns is not a record. It is a staged list, each item carrying a short title, two or three sentences on why it applies to that use case and that data, a category, a suggested regulatory tier, a likelihood and an impact. A person accepts, edits before accepting, or rejects, one at a time or in bulk. Only acceptance creates a row, and the row records that it was suggested and who accepted it, so the origin stays visible for as long as the risk exists.
There are no orphan risks. The link to the use case or data asset that introduced the risk is written at the same moment as the risk itself.
Scoring, and where the numbers come from
Likelihood runs from 1, rare, to 5, almost certain. Impact runs from 1, negligible, to 5, severe. The inherent score is the two multiplied, from 1 to 25, and it is computed by the database rather than typed by anyone. The bands are fixed: critical 15 to 25, high 10 to 14, medium 5 to 9, low 1 to 4. A residual score records the position after controls.
The method is published inside the product on a page generated from the same constants the code uses, and a build check stops the two drifting apart. A reader who wants to know how a score was reached is shown the arithmetic rather than told to trust it.
Two regulatory dimensions, and who sets them
Every risk carries a tier under the EU AI Act: prohibited, high risk, limited risk, minimal risk, or not classified. A model may suggest the tier, using the vocabulary of the approved text. A person confirms it.
Separately, a risk carries regulatory reference points, and these are set by people only, never by a model: data protection under the UK and EU General Data Protection Regulations; whether a data protection impact assessment is likely required; sector regulation in financial services and in health; and intellectual property and copyright. Each carries a plain-English gloss, and on the record it shows the source it rests on and the date that source was approved.
Where the regulatory vocabulary comes from
The labels are not Assettia's reading of the law. They rest on twenty official sources, held in a register, checked on a schedule, approved by a person, and cited with a date.
| Dimension | Source | Publisher | Kind | Checked every |
|---|---|---|---|---|
| EU AI Act | Regulation (EU) 2024/1689, consolidated text as amended 27 July 2026 | EUR-Lex | Legislation | 30 days |
| EU AI Act | Regulation (EU) 2024/1689, original text | EUR-Lex | Legislation | 30 days |
| EU AI Act | Regulation (EU) 2026/1744, the Digital Omnibus on AI | EUR-Lex | Legislation | 30 days |
| EU AI Act | AI Act Service Desk and Single Information Platform | European Commission | Guidance | 7 days |
| Data protection | UK GDPR | legislation.gov.uk | Legislation | 30 days |
| Data protection | Data Protection Act 2018 | legislation.gov.uk | Legislation | 30 days |
| Data protection | Data (Use and Access) Act 2025 | legislation.gov.uk | Legislation | 30 days |
| Data protection | Regulation (EU) 2016/679, EU GDPR | EUR-Lex | Legislation | 30 days |
| Data protection | Guidance on AI and data protection | ICO | Guidance | 7 days |
| Data protection | Explaining decisions made with AI | ICO with The Alan Turing Institute | Guidance | 7 days |
| DPIA | Data protection impact assessments | ICO | Guidance | 7 days |
| DPIA | Endorsed WP29 guidelines, including WP248 on DPIAs | EDPB | Guidance | 30 days |
| Financial services | AI and the FCA: our approach | FCA | Guidance | 7 days |
| Financial services | Handbook PRIN 2A, the Consumer Duty | FCA | Rules | 7 days |
| Financial services | FG22/5, Consumer Duty finalised guidance | FCA | Guidance | 30 days |
| Financial services | SS1/23, model risk management principles for banks | PRA | Supervisory statement | 30 days |
| Health | Software and AI as a medical device | MHRA | Guidance | 7 days |
| Copyright | Copyright, Designs and Patents Act 1988 | legislation.gov.uk | Legislation | 30 days |
| Copyright | Report and impact assessment on copyright and AI, 18 March 2026 | UK Government | Report | 30 days |
| Copyright | Directive (EU) 2019/790 on copyright in the Digital Single Market | EUR-Lex | Legislation | 30 days |
A scheduled job fetches each source when its own interval has elapsed, takes the comparable text of the page and hashes it, and compares that with the version currently approved. A difference is stored as a pending capture and raised for review, where a person sees a word-level comparison against the approved version and either approves it, which supersedes the old one, or dismisses it with a note. At most one approved version of a source exists at a time.
Nothing about this is automatic beyond the fetching. A change in the law does not change a label until a person has read the difference and approved it.
What an organisation sees is the currency, not the queue: the date the regulatory references were last approved, and on every label the source it uses and that source's date.
Who is told, and when
A register nobody is told about is a list. One service in the platform tells a person when a record needs them: reviews past their date, risks without an owner, high severity risks with no control, controls failed or overdue, and several more.
Every alert is a rule evaluated over records, not a message a model composed. Each one opens against a specific record, carries a link that opens it, resolves itself when the condition clears, and is logged. One open notification per condition per record, so a register with many overdue reviews does not produce a message for each of them every time the evaluator runs.
Who receives what is set by the organisation's own administrator: a role, a named person, or the record's owner. Nothing is sent for an alert type until a rule names a recipient. Alerts reach people by email as well as in the product, which is what makes an owner alert work for a risk owner who never signs in.
The governance rhythm
A register says what the risks are. A rhythm says what must happen to each of them, by whom, and how often.
The platform holds a twelve-step rhythm as data. An organisation adopts it, tunes any number in it, and every change is recorded. A published version is never edited; a new version supersedes it.
| Step | Trigger | Owner | Default |
|---|---|---|---|
| Use case registered with an owner | New use case | Use case owner | Within 5 working days |
| Risk assessment run | Use case reaches the stage the organisation sets | Use case owner | Within 10 working days |
| Every risk owned | Risk created | Administrator | Within 5 working days |
| Every risk classified | Risk created | Risk owner | Within 10 working days |
| Data protection impact screen | Personal data linked, or the reference point set | Use case owner | Before the build gate |
| Controls for high and critical risks | Severity high or critical | Risk owner | At least one control within 20 working days |
| Periodic risk review | Time since last review | Risk owner | 90 days critical and high, 180 days medium and low |
| Re-review on change | Severity, status, control or owner changes | Risk owner | Within 10 working days |
| Control testing | Time since last test | Control owner | Every 12 months |
| Retirement | Use case parked or retired | Use case owner | Risks closed or accepted with rationale within 20 working days |
| Attestation | Calendar | Named leader | Quarterly |
| Rhythm review | Calendar, or a mapped standard changes | Administrator | Yearly |
Each step with a deadline is an alert, routed by default to the record's owner, escalating to the administrator if nobody acknowledges it.
What the rhythm maps to, and what it does not
Each step names the clause it serves in four published frameworks: ISO/IEC 42001:2023, the AI management system standard; ISO/IEC 23894:2023, its risk management guidance; the NIST AI Risk Management Framework; and the EU AI Act as amended. It also maps to UK data protection law and, for organisations that need it, the Prudential Regulation Authority's model risk management principles.
Every clause reference is checked against the approved capture of that source before anyone sees it, and carries that capture's date.
Two things the map deliberately excludes, and the process statement says so. The clauses of ISO/IEC 42001 covering leadership, resources and competence, because the platform holds no evidence for them. And information security management, which is a separate question answered elsewhere.
What this is not. Alignment is not certification. Certification is granted by accredited bodies to organisations, on evidence of the kind this produces, after an assessment the platform plays no part in. Assettia holds the record. It does not confer a standard.
What a board is shown
The Governance view opens with one sentence, chosen by a fixed order of precedence rather than by a model: reviews past their date first, then controls missing, then risks without an owner, then no review cadence recorded, and only if none of those applies, that no open assurance gaps are recorded.
Beneath it, five readouts: what is owned, what has been decided, what has been proved, whether review cadences are being met, and how current the assessments and the regulatory references are. Every figure names the population it counted and opens the exact rows behind it, as a link a director can send to a colleague.
The board report's governance section is generated from those figures and bounded by them. It cannot state a count the register does not hold, and it cannot omit an uncontrolled high-severity risk. Once released it is filed and immutable.
The attestation
On a stated date, a named person with their role signs a frozen snapshot of the position, and it does not change afterwards. That is the point of it: a year later, the question "what did we know, and what did we say, on that date" has an answer nobody can have edited.
The snapshot also records the rhythm version it was taken against, and the compliance figures for each step.
Thirteen things an organisation can say, and what backs each one
| The statement | The record behind it |
|---|---|
| Every AI risk on the register is linked to the use case or data asset that introduced it | The link written at creation. No risk exists without one |
| No AI-suggested risk entered the register without a named person accepting it | The staged review gate; the accepted flag and the acceptor on each row |
| Every risk has a named owner, or the register says which do not | The owner field, and the population of risks without one |
| Overdue reviews are visible, and the people responsible were told | The cadence and review fields, the overdue population, and the delivery record showing who was told and when |
| Every change is recorded with who, when and the previous values, and cannot be edited or deleted | The append-only history, with update and delete revoked at the database |
| Regulatory labels use the vocabulary of official sources, each approved by a person on a recorded date | The source register, the approved captures, and the citation on each label |
| The organisation is told when the law or guidance it relies on changes | The scheduled check, the pending capture, the review, and the approval record |
| High and critical risks carry controls, or the register names those that do not | The controls, and the population of high severity risks with none |
| The board's figures are the register's figures, with nothing composed | Named populations, drill-through to the exact rows, and a bounded report |
| On a given date, leadership attested to the position | The attestation snapshot: the figures, the signer, their role, the timestamp |
| The organisation follows a documented process aligned to named standards | The adopted rhythm version, the standards map with its source dates, and the figures per step |
| The process was followed, and where it was not, the record says so | The governance process statement, including its exceptions and its limits |
| No model decides, acts or alters a record on its own | The review gate, server-side model selection, and a prompt library with test cases |
The document a regulator would be given
One document, produced from the record and filed in the organisation's own register, immutable once released. Five parts, and the fifth is not optional.
- The rhythm as the organisation adopted it, with its own numbers.
- The standards map, with the date of the source behind each clause.
- The compliance figures for the period.
- The exceptions, named.
- What the process does not cover.
An organisation cannot switch off the fifth part. A process statement that lists only what went well is not evidence of anything, and a reader who has seen a few of them knows it.
What this is not
Not a governance, risk and compliance platform. Those hold controls and frameworks for the whole organisation. Assettia sits upstream and produces the AI-programme record such a platform, an auditor or a regulator asks for.
Not a certification, and not a route to one. It produces alignment and evidence. Accredited bodies certify organisations.
Not a legal opinion. The register holds the official texts and their dates. It does not interpret them, and no model reads the law to decide anything.
Not autonomous. The AI drafts and proposes. It never writes to a live record, never sends a message of its own composition, and never changes a classification.
Not a data catalogue or a data quality tool. It records the risks that data assets carry. It does not profile the data.
Questions people ask
Does the AI decide what is high risk?
No. It proposes a tier using the vocabulary of the approved text, and a person accepts, changes or rejects it. Nothing it proposes becomes a record until a named person accepts it.
Which regulations and standards does it cover?
Twenty official sources across six dimensions: the EU AI Act as amended, UK and EU data protection law, guidance from the Information Commissioner's Office and the European Data Protection Board, rules and guidance from the Financial Conduct Authority, a supervisory statement from the Prudential Regulation Authority, guidance from the Medicines and Healthcare products Regulatory Agency, and UK and EU copyright law. The governance rhythm maps to ISO/IEC 42001, ISO/IEC 23894, the NIST AI Risk Management Framework and the EU AI Act.
How current are the regulatory references?
Guidance is checked every seven days and legislation every thirty. Any change is reviewed and approved by a person before it is used, and the date of that approval is shown wherever a label cites a source.
What happens when the law changes?
The change is captured and shown as a word-level comparison to a person, who approves or dismisses it. Organisations then see the new date on their citations, and the rhythm review step is triggered for anyone whose adopted rhythm maps to that standard.
Does using Assettia make an organisation compliant?
No. It produces a defensible record of how AI risks were managed and a documented process aligned to named standards. Compliance and certification are judgements made by regulators and accredited bodies, on evidence of this kind.
Can a risk be deleted?
No. Risks are archived. Histories and delivery records are append-only, with update and delete revoked at the database.
Can an organisation change the process?
Yes. The rhythm is data. An organisation adopts the default, tunes any number, and every change is recorded. A published version is never edited; a new version supersedes it.
What if a regulator asks for the process?
The governance process statement: the rhythm as adopted, the standards map with its dates, the figures for the period, the exceptions, and what the process does not cover.
See the register, and what a board is shown.
A walkthrough takes forty minutes and uses a synthetic organisation, so nothing of yours is entered until you decide it should be.