AI Governance
Plenty of companies have an AI policy. Far fewer can take one specific thing their AI did last Tuesday and explain what it did, what information it used, and who allowed it. RPR builds the part that makes the second thing true — and this page is the detailed version of how.
The problem
An automated system acts thousands of times a day. Unless something was deliberately built to capture it, each of those actions leaves behind only its effect — the order that moved, the record that changed, the message that went out. The reasoning is gone.
That is tolerable right up until somebody asks a specific question. Then the absence of a record stops being a technical detail and becomes the whole problem, because the honest answer is that nobody knows.
In our experience it is rarely a lawyer who asks first. It is a customer wanting to know how your AI reaches its answers, a larger partner sending a security review before they sign, or your own board after something goes wrong.
Questions your systems should be able to answer
If the answer to the last one is no, the rest are opinions.
The approach
Put oversight, policy and the record in the control path rather than in the model, and two useful things follow: the controls apply no matter which provider is answering, and swapping provider costs you a configuration change instead of your entire audit history.
What we implement
These are the things we actually build. None of them is a certification or a badge, and none of them is a claim about where you stand legally — they are engineering controls that make whatever you are asked, answerable.
Require a person when it matters
Autonomy is a dial, not a switch. Every automated actor has a threshold above which it stops and waits for a named person — and the approval, the approver and the moment it happened become part of the record rather than a message in someone’s inbox.
Trace an answer back to its source
For any automated outcome you should be able to walk backwards: which action was taken, under which policy, on which inputs, drawn from which systems, in what state, at what time. Lineage is what turns "the model said so" into an account somebody can check.
Decide what AI is allowed to do
What a system may do is declared once and enforced where the action happens — not left to a carefully worded prompt. Guardrails bound the blast radius: which systems, which records, which operations, and what must never be touched under any circumstances.
Keep a clear history you can search
Records are written append-only and kept queryable, so producing evidence is a query rather than a project. The test we hold ourselves to is simple: can you answer a pointed question about a specific decision, from the record, in minutes, without calling an engineer.
Limit what it can actually change
The difference between an assistant and an agent is that an agent changes something. Every write an automated actor can make is enumerated in advance, scoped, reversible where reversibility is possible, and logged whether it succeeds or fails.
Change AI providers without starting over
Governance that lives inside a vendor’s platform leaves with that vendor. Ours sits around the model: policy, oversight and the record are ours and yours, so changing provider — or running several at once — is a configuration decision rather than a governance rebuild.
Lineage in practice
Every automated action follows the same path, and every step of that path is written down. This is what makes an answer possible months later, when the person who built it is on holiday and the customer wants an explanation today.
Where it sits
Put the controls inside the model and they leave when you change model. Put them in a review that happens afterwards and they were never controls. They belong around the environment — across the systems, the data, the AI and the applications at once.
The technology behind it
Governance needs somewhere to live. If it lives inside a model, it leaves when you change model. If it lives in a review that happens afterwards, it was never control — only commentary.
RPR's governance approach is supported by Still Horizon™ technology: an always-on governance and evidence layer that is deliberately model-independent. It sits around the environment rather than inside any one part of it, so what it observes and records survives a change of provider — and people stay in the loop wherever judgment matters.
Governance should exist where the decision happens, not just where the result is reviewed. The approach is designed to work at supported integration points across the environment — around models and ML frameworks, around agents and orchestration, around workflow runtime and execution, and out to applications and edge systems.
What is available in any given deployment depends on which control points that environment actually exposes. We will tell you which ones yours has before anyone signs anything.
Go deeper on the governance technology
Still Horizon™ has its own site with the detailed technology story.
Where to start
Before anything is built, we establish what your automated systems can currently account for. That assessment is useful on its own, and it is usually the fastest way to find out whether you have a real problem or a documentation problem.
Which automated systems are running, what they can do, and what they currently record.
The specific questions your systems cannot answer today, written down plainly.
Controls implemented against the highest-exposure systems first, not everything at once.
Governance holds as the estate changes, because it is part of the integration rather than a layer on top.
Start with the customer journey
Bring us a specific automated decision your business made this week. We will walk through what you could establish about it today, and what you could not. That conversation costs nothing and is usually clarifying.
Prefer email? info@rprtechllc.com