Hello Hello,
The last two issues were practical. How to run a policy gap analysis. How to build a policy reviewer agent. Tier 2 work, AI-assisted, practitioner-led, useful right now.
This one is different.
This issue closes out the Policy Management workstream by mapping where it ends up. Not where most teams are today, but where the model is heading. What Tier 3 actually looks like, what is already being built in the market, and the governance work that has to be in place before any of it is safe to run.
The Tier 2 to Tier 3 Shift
At Tier 2, you are running the agent (https://aigrcdesk.com/p/i-built-a-grc-policy-reviewer-agent-here-is-exactly-how). You decide when to review a policy. You upload the document, invoke the workflow, review the output, and decide what to fix. The agent is a tool. You are the trigger.
At Tier 3, the model inverts.
The agent is watching continuously. It is connected to live regulatory feeds, the ICO, the FCA, the EU AI Act implementation updates, NIST publications, whatever is relevant to your compliance environment. When a regulation changes, the agent does not wait for you to notice. It compares the change against your existing policy framework, identifies which policies are now potentially out of alignment, and surfaces a drift alert to the named policy owner.
You are no longer the trigger. The regulatory environment is.
That is not just a faster version of Tier 2. It is a fundamentally different operating model. Policies stop being documents you review periodically and start being assets you monitor continuously.
Where does your GRC team sit?
GRC Automation Maturity Model
The self-assessment covers all five workstreams including this one. Here is a link: https://aigrcdesk.com/p/the-framework-the-grc-automation-maturity-model that breaks down the GRC Automation Maturity Model.
What This Looks Like in Practice
A concrete example. The ICO updates its guidance on AI-assisted decision-making, something that is already happening incrementally as the UK AI regulatory landscape develops. At Tier 3, within hours of the update being published:
The agent has ingested the change from the regulatory feed
It has compared the updated guidance against your AI Acceptable Use Policy, your Data Protection Policy, and your AI Governance Framework
It has identified that your AUP does not address the new transparency requirement for automated decisions affecting individuals
It has flagged the gap to the named policy owner with a risk rating and a recommended remediation action
No one had to manually check. No one had to remember the guidance had changed. The drift was caught automatically, before it became an audit finding.
That is Tier 3.
Who Is Building This Now
This is not theoretical. Several platforms are already doing versions of this in the market.
MetricStream is the most mature implementation. Their AI-powered Regulatory Change Management module does obligation-level extraction from regulatory documents not just summaries, but individual obligations with source citations and maps them automatically to your existing control inventory, policies, and risks. A 17-page regulatory amendment gets processed into discrete obligations in hours rather than weeks.
RegScale focuses on Continuous Controls Monitoring. It connects to your existing compliance tools, automates evidence collection, and maps controls across multiple frameworks in real time. When a framework changes, the mapping updates.
360factors (Predict360) monitors regulatory sources, classifies updates, assesses impact on policies and controls, and triggers automated notifications to relevant stakeholders. Built primarily for financial services.
Compliance.ai monitors regulatory updates from any source, filters for relevance, and surfaces only the changes that matter to your specific compliance environment.
The technology exists. The question is whether your GRC programme is ready to use it.
The Four Things That Have to Be in Place First
This is where most teams are not ready. And it is worth being honest about that.
Tier 3 does not fail because the tools are not good enough. It fails because the governance foundation is not in place. Here is what has to be true before continuous monitoring is safe to run:
1. Every policy has a named owner, not a team, a person. Automated drift alerts are useless if there is no one accountable to act on them. If your policy register lists "Information Security Team" as the owner of your Data Protection Policy, a Tier 3 alert will land in a shared inbox and sit there. Named ownership is not a Tier 3 requirement. It is a Tier 1 requirement that Tier 3 makes visible when it is missing.
2. Your policy-to-regulation mapping exists and is documented. The agent needs to know which policies are supposed to cover which regulatory obligations. If that mapping does not exist in a structured form, the agent cannot identify drift — it can only flag that a regulation changed. The mapping is the connective tissue. Without it, you have a monitoring tool with nothing to monitor against.
3. You have a documented remediation SLA. When a drift alert fires, what happens next? Who reviews it, by when, and what is the escalation path if it is not addressed? If that process does not exist in writing, the alert creates noise rather than action. Define the SLA before you connect anything to a live feed.
4. The agent's output is treated as a trigger, not a decision. Tier 3 automates the detection. A practitioner still owns the response. That boundary has to be explicit in your AI governance documentation. If an auditor asks how a policy gap was identified and remediated, "the agent flagged it and a named human reviewed and approved the fix" is a defensible answer. "The system updated the policy automatically" is not.
See You at "AI Governance, Practically", Friday 26 June
A quick one, I am speaking this Friday at the "AI Governance, Practically" webinar, hosted by Maro.
When: Friday 26 June 2026, 5:00 PM BST / 12:00 PM ET
Format: Three lightning talks and a live Q&A on AI governance
Speakers: Chad Brustin (vCISO, Term Sheet Security), Josh Mason (Mason SC), and me
I will be walking through the GRC Automation Maturity Framework, the same framework that runs through every issue of this newsletter. Chad is sharing his free-tools approach to building an AI GRC stack on any budget. Josh is covering how to translate AI governance for the C-Suite.
If you have been following the maturity model and want to see it presented end-to-end in 10 minutes, plus get your questions answered live this is the session.
Bring your burning questions. Even better, bring the ones your CISO has been asking you.
The Governance Check
At Tier 2, the governance question is "did a human review this output?" At Tier 3, the governance question changes. It becomes "can we defend why the system acted at all?"
Three things have to be true before any Tier 3 deployment goes live:
1. Define the data classification boundary for the regulatory feed itself. Regulatory feeds are generally low-risk content. The policies they are being compared against may not be. Confirm the data flow is governed before you automate it.
2. Add the agent to your AI usecase register, if it exists. If you are using a configured AI agent in your governance process, your AI usage register needs to include the agent itself. Document its role, the sources it connects to, the standards it reviews against, and the guardrails it operates under. Build that documentation now, not after the first audit asks for it.
3. Add the agent to your risk register. A Tier 3 autonomous system is itself a risk asset. It needs a named owner, a defined risk rating, a control set, and a review cadence. If your continuous monitoring system is not on your risk register, your governance is incomplete.
Next Issue
That closes out the Policy Management workstream.
Next week we move into Risk Management, the workstream where AI has the most potential and the most ways to go wrong. Issue 5 is a Deep Dive: all AI use cases in Risk Management across all four tiers of the GRC Automation Maturity Model.
See you next week.
Princess
Until Next Tuesday,
Princess
