Policy Center is live
Every organization has an AI policy. Very few can say which version of it governs, who approved that version, when it must be reviewed next, or whether a single AI system in production actually meets what it says. The policy is a PDF in a shared drive, and the answer to “show me” is a search through email. An AI policy that nobody checks is a statement of intent, not a control.
Policy Center is the home for that document. It answers one question first: do we have an approved AI policy, which version is active, who owns it, and when must it be reviewed? Then it does what a document cannot do on its own. The rules the policy states are checked against what your registries record, and the gaps are listed in your policy’s own words.
Which version governs, and who says so
Upload a PDF or Word document, up to 25 MB, with the version label your organization already uses. The file goes straight from the browser to encrypted storage, PulseAI reads back exactly the bytes that were stored and records their SHA-256 hash, and the document is scanned for malware before anyone can download it.
Uploading is not approving. A new document is a draft. An administrator activates it in a separate, audited step that requires a next review date, and from that moment exactly one version governs. Activating a new version marks the previous one superseded automatically. Every download is pinned to the stored bytes the hash names, never to “whatever is current”. A document that fails its malware scan, or that the scanner could not reach a verdict on, is permanently blocked: delete the version and upload a replacement.
The document proposes, a person confirms
Once a version is a draft, PulseAI reads it and proposes two things: values for your Organization Context (the five risk-appetite domains, the oversight committee, and the materiality definition), and the rules the policy states. Every proposal carries the verbatim quote and where it sits in the document.
An administrator confirms or rejects each proposal. A confirmed context value goes into the Organization Context draft, where approving the draft is a second review. A confirmed rule goes into force on the active version, or waits for activation on a draft. Nothing is authoritative until a person has confirmed it, and every decision is written to the audit trail.
Rules, checked against the registry
There are eight kinds of rule: assessment required, prohibition, vendor approval, data residency, named owner, approval required, review cadence, and exception process. Once a version is active, its confirmed rules are checked against your model and use case registries daily, and again whenever a rule is confirmed, a version is activated, or the registry changes. No model is involved in the check. Every rule is a fixed test over what your registries record.
A rule nothing in the registry can decide is marked Not checked automatically. It never raises a finding; it becomes a stated expectation on each system’s page and an attestation question instead. A rule that names a role (“approved by the CISO”) cannot be confirmed until an administrator names who holds it, and when that person leaves, grants under the rule are refused until someone re-binds it rather than quietly widened to any administrator.
Findings in your policy’s words
Each finding is one rule, one system, one gap: how serious it is, what the gap is in words, and which system it is about. Findings are grouped under the rule that produced them, worst group first, with a tally on each header. A gap that cleared and came back keeps its original date and says how many times it has reopened. A finding that means “nothing recorded can decide this” is shown muted at the lowest severity and clears once the missing fact is recorded, because treating “we do not know” as “we are in breach” would teach everyone to ignore both.
Until the first evaluation has run, the page says Never evaluated rather than showing zero findings. How findings, statuses, and grouping work is on the Policy Center page.
Exceptions your policy bounds
A known gap is still a gap. An exception is the only way a finding becomes Accepted, and it is deliberately not a way to make a finding disappear. Your own exception-process rule decides who may grant one, for how long, and whether a compensating control is required; the expiry cannot run past the limit your policy sets. Accepted findings stay listed beside open ones, and they reopen on their own when the exception expires. With no exception process in your policy, the platform default applies (six months, a compensating control, any administrator) and the dialog says so.
Sealed on activation
Activating a version is a governance event, so the platform seals a write-once record of it into the Evidence Vault: which version began to govern, from when, who activated it, the document’s hash, and the organization context, frameworks, and confirmed rule counts as they stood at that instant. Later edits to the policy cannot change what that record says about the day the version began to govern.
On every model and use case
Model pages carry a Policy tab, and adopted use cases carry the same panel: the rules of your active policy that apply to that one system, each marked Met by this system, the gap and its severity, or Not checked automatically. The clean claim is dated. “Meets every applicable rule as of” a date is true only as of the evaluation that looked, and it is not made at all before one has run.
From your AI assistant
If you have connected Claude, ChatGPT, or Copilot to PulseAI through the MCP server, policy findings come back as stored records with their own ids, a status, and a reference to a section of your own policy. The assistant is told to say “your policy requires” rather than “the standard requires”, and to report an accepted finding as an exception with an expiry, never as resolved. Full Policy Center access from your assistant, including the policy itself, the rules in force, and the exceptions, is coming soon.
What it is not
A policy finding names a section of your own document. It is never presented as an ISO/IEC 42001, NIST AI RMF, EU AI Act, or OSFI control, and its framework field is empty for exactly that reason. PulseAI reads the policy, checks the registry against the rules you confirmed, and shows the gaps. Whether your policy satisfies a law or a standard remains your organization’s determination. The policy says. The record shows.
The full picture, including the version lifecycle, the eight rule kinds, and who can do what, is on the Policy Center page.