Governing the AI you deploy
A register that refuses an unclassified system, an unowned high-risk one, and a prohibited one in production
Every platform in this market now sells AI governance, and almost all of it is a spreadsheet of models with a policy attached. This paper describes the opposite: an inventory that will not accept a classification without a basis, will not accept a high-risk system in production without a named person and a written description of how they oversee it, and will not let a prohibited practice be recorded as running.
What this paper establishes
- A register that refuses three invalid states outright: a classification with no basis, a high-risk system in use with no named owner and written oversight, and a prohibited practice recorded as running.
- The actor role carried as a first-class property, because the obligations of a provider and a deployer are not the same and organisations routinely assume the lighter one.
- The platform’s own agents sit in the customer’s register under the same discipline, with every action in the customer’s audit record.
Of twenty reports published by GRC and privacy vendors that we surveyed in October 2026, sixteen were about artificial-intelligence readiness. The market has decided this is the topic. What almost none of them shows is a screen.
That matters because AI governance is one of the few compliance problems where the register itself does the work. An organisation’s exposure comes from systems it has already deployed, under roles it may not realise it has taken on, with oversight arrangements that exist in a policy and not in any person’s week. A document cannot fix that. A register that refuses to hold an incoherent state can.
The three refusals
Most inventories accept whatever is typed into them. This one does not, and the refusals are at the level of the record rather than in a validation message that a bulk import can bypass.
- A classification with no basisA system may be recorded as unclassified. The moment it is given a classification, the reasoning for that classification is required. A classification with no stated basis is a guess wearing a label, and in an inspection it is worse than an open question.
- A high-risk system in use with no one accountable for itA system classified high-risk cannot sit in pilot or production without a named owner and a written description of how human oversight is exercised. This is the field that turns a human-oversight obligation from a policy sentence into something a person had to write down.
- A prohibited practice recorded as runningA system classified as a prohibited practice may be recorded as planned or as retired. It may not be recorded as in production. The register is deliberately able to show that a prohibited use was proposed and stopped, which is a useful thing to be able to demonstrate.
The role you have, not the role you assumed
The single most common error in an AI compliance programme is a misread of the organisation’s own position. A team integrates a third-party model, puts the company’s name on the resulting product, and continues to describe itself as a deployer. The obligations that attach to a provider are substantially heavier, and the difference is not discovered until a person asks.
The register carries the actor role as a first-class property of every system — provider, deployer, importer, distributor or product manufacturer — because the same system produces different obligations depending on which one the organisation occupies, and because a register that does not ask the question lets everybody assume the comfortable answer.
| Property | Why it is on the record |
|---|---|
| Actor role | The obligations differ by role, and organisations routinely assume the lighter one |
| Risk classification, with its basis | An inspection asks why, not what |
| General-purpose model flag | A different and faster-moving set of duties |
| Lifecycle stage | Planned, in development, pilot, production or retired — exposure follows use, not intent |
| Named owner and the oversight arrangement | Human oversight is evidenced by describing how it is exercised |
| Whether it uses personal data, and which processing activity | An AI system fed with personal data is also a processing activity, and the two registers must not diverge |
| The supplier behind it | A model from a vendor is also third-party risk, assessed in the same workspace |
| The risk it is joined to | So treatment, acceptance and review happen in the risk register rather than in a parallel one |
| Review dates | A classification made once and never revisited is the next finding |
The bridge to privacy, which is where most of the exposure is
A large share of AI risk in a regulated organisation is not novel AI risk. It is ordinary data protection exposure arriving through a new door: personal data used for training, inference producing a decision about a person, a transfer created by a model hosted in another country, an automated decision that triggers a right to human intervention.
Because the AI register and the record of processing activities are in the same workspace, a system that uses personal data points at the processing activity that describes it. The transfer that the model’s hosting creates appears in the transfer register with the verdict the destination’s regime produces. The impact assessment starts from the activity rather than from a blank template. None of that is an integration between modules, because there are no modules.
Our own agents are in the register too
The platform’s own agents are recorded as AI systems in the customer’s workspace, under the same classification discipline as every other system the organisation runs. A vendor that sells AI governance while keeping its own AI outside the register is asking for an exemption it would not grant a customer.
Beside the register sits the ledger: every action an agent takes, the permission it was checked against, the draft it produced and the person who accepted, edited or rejected it, in one hash-chained sequence with the human actions. One competitor has launched a product promising auditor-grade proof of every decision for the customer’s other agents. Applying it to your own is the harder half, and it is the half that makes the claim credible.
| #7,204 | Agent | Read the model card and the supplier’s technical documentation | tool · evidence.read |
| #7,205 | Agent | Proposed a high-risk classification, citing the intended purpose recorded on the system | draft · ai classification |
| #7,206 | R. Haddad | Accepted the classification and named herself as the accountable owner | person · ai.write |
| #7,207 | R. Haddad | Recorded how oversight is exercised, which the record required before production | person · ai.write |
Where the obligations come from, and why one register serves all of them
An organisation deploying AI in 2026 is usually inside several regimes at once: a regional AI regulation with its own actor roles and classifications, a management-system standard its customers ask about, a national risk framework its regulator references, the sector rules that already governed the decision the model is now making, and the privacy law that governs the data underneath.
Conscious carries those as obligations in the same catalogue as everything else, which means an AI control is evidenced once and answers each of them. The arithmetic paper in this library sets out what that collapse is worth across a whole programme; for AI specifically, the useful property is narrower and more immediate. The inventory, the risk, the supplier assessment, the processing activity and the evidence are one record rather than five, so the question “which of our AI systems are high-risk and who is accountable for each” has an answer rather than a project.
What to ask any vendor selling AI governance
- Can I save a high-risk system in production with no named owner and no description of oversight? Try it on the screen.
- Can I record a classification without a reason? Try that too.
- Where does your register say which actor role we occupy, and does it change what the system asks us for?
- If an AI system uses personal data, does your product join it to the processing record and the transfer register, or is that a second system?
- Are your own AI agents in my register, and is every action they took in my audit record with the permission it was checked against?
- Show me the review dates. What happens when a classification has not been revisited?
The first two take thirty seconds each and they separate an inventory from a list. Every product in this category will say it supports AI governance; few of them will refuse to save the record.
Sources
- 1Vendor publishing survey. Twenty GRC and privacy vendor reports and whitepapers published in 2026 were surveyed in October 2026 from the vendors’ own resource libraries; sixteen of the twenty concerned artificial-intelligence readiness or governance.
- 2Actor roles and human oversight. The register’s actor roles and its treatment of human oversight follow the structure of the European Union’s AI regulation, which attaches different obligations to providers, deployers, importers, distributors and product manufacturers, and requires that human oversight be designed into a high-risk system rather than asserted about it.
- 3Platform behaviour. The three refusals are properties of the record in the shipped product and are covered by the verification suites a customer runs on their own instance.
- 4Competitor claim. Drata’s agent-governance product, announced in 2026, promises auditor-grade proof of every decision for the customer’s AI agents. Quoted from its own published description, read October 2026.
About Conscious
Conscious is an independent assurance platform for organisations that answer to more than one authority. It carries 34 privacy regimes with their own transfer rules, breach clocks and subject rights, and 56 control frameworks, 16 of them at the authority’s own wording. Evidence, judgements and approvals sit in one hash-chained record, agents propose and named people decide, and the same instance can run in a customer’s own data centre.
Every figure Conscious publishes is measured from the running product and held to it by a test that fails the build when a document and the catalogue disagree. The verification suites run on the customer’s own instance rather than on ours, the audit record is verifiable by the customer’s own auditor, and the load figures come with the hardware printed beside them. Ask any vendor for the same and compare what comes back.
Put the same questions to us and to the platform you are already paying for. The assessment at consciousgrc.com/assess needs no call and no account, and it prints a record you keep whether or not you ever speak to us.