What we do
01  Advanced Infrastructure 02  Applied AI & Data 03  AI Cybersecurity 04  AI Assurance
Engagements
AI estate inventory Assurance review
Industries
Financial Services Government & Public Sector Energy & Utilities Telecommunications Healthcare & Life Sciences Transport & Logistics Industrial & Manufacturing Retail, Hospitality & Real Estate
Research
The Trust Maturity Model The GCC Assurance Index Readiness self-assessment Case studies Perspectives Sector briefings Technology evaluations
Company
About us Partners Events Careers Contact العربية Talk to our team
AI Assurance  ·  AI Governance

A policy is not proof.

A policy states what should happen. Evidence shows what did. We design governance so the record is a by-product of the work rather than a project undertaken after somebody asks for it.

6–10 WEEKSDECISION RECORDS, NOT POLICY DOCUMENTSMAPPED TO WHAT APPLIES TO YOU
The decisions underneath

Three questions decide the design.

Governance frameworks are usually adopted whole and then quietly abandoned. These three questions decide whether yours will survive contact with delivery.

01

What has to be recorded, at the moment it happens

Anything reconstructed later is weaker evidence and more expensive to produce. The design question is what can be captured as a by-product.

02

Who is allowed to say no

A gate with no named person who can refuse is not a gate. Naming that person is frequently the most contested part of the engagement.

03

Which obligations actually apply

Most organisations are mapped against a framework somebody once chose rather than against the obligations that actually reach them.

What a review asks for

Governance is judged on what it produced.

A policy is not evidence that a decision was governed. Choose an obligation to see what a review actually asks for.

THE INVENTORY
ARTEFACT 01

System inventory

Everything in scope, counted
ARTEFACT 02

Risk classification

Applied the same way twice
THE MAPPING
ARTEFACT 03

Control mapping

Obligations held against systems
ARTEFACT 04

Decision record

Who approved, on what information
THE PROOF
ARTEFACT 05

Testing evidence

That the control actually ran
ARTEFACT 06

Reporting pack

In the form it will be asked for
EVIDENCE LEDGER— OF 6 EVIDENCED
Select an obligation

Six artefacts. Every obligation on this list draws on the same six, which is why preparing for one of them prepares you for most of the others.

HELDPARTIALABSENT

Governance that produces no artefact is indistinguishable from no governance at all, from the outside. The whole design problem is making the record a by-product of the work rather than a project after it.

What you receive

A governance capability, and its output.

Four stages, every engagement. Hover a stage to see what happens in it.

DURATION
6–10 weeks
DELIVERABLE
Control map, gate design, evidence model
DELIVERED
Remotely, workshops where required
INDICATIVE FEE
[FEE BAND — pending sign-off]
The boundary

We evaluate it. We did not build it.

Three moves. Two of them are ours, and the one in the middle deliberately is not.

MOVE 01 — OURS

We test and we write it down

We evaluate the system against what it was claimed to do and against the obligations that apply to you, and we record what the test showed — including where the answer was that no record exists.

MOVE 02 — NOT OURS

Your builder does the fixing

Remediation is performed by whoever built or runs the system. We do not take the build work, because taking it would mean the next evaluation is us examining our own hands.

MOVE 03 — OURS

We re-test on a cycle

The system is re-examined against the same tests on a schedule, because an evaluation is a statement about a configuration on a date, and configurations move.

If a finding of ours turns into a build contract for us, the finding stops being evidence and starts being a sales instrument. We would rather keep the evidence.
AI Assurance

The rest of this pillar.

Three engagements inside this pillar. Start with the question you can name, or take the whole estate at once.

Questions we are asked

Before you ask us.

We already have an AI policy. What would this add?
The test is whether the policy has produced anything. If you can point at decisions it caused, gates it closed, and records it generated, you are in better shape than most. If it has produced no artefacts, it is describing an intention rather than governing anything.
Which framework do you use?
Whichever ones actually reach you. We map to the obligations in force for your jurisdictions, sectors and customers — commonly ISO/IEC 42001 as a management-system spine with regulator-specific obligations mapped onto it, but that is a finding rather than a default. [All regulatory references SA-reviewed before publication.]
Does governance slow delivery down?
Badly designed governance does, because it adds a step after the work. Well designed governance changes where the record is captured rather than adding a stage, and it removes the far more expensive delay of reconstructing evidence under time pressure.
Do you write our policies for us?
We design the control map, the gates and the evidence model, and we draft what is needed to support them. What we do not do is hand over a policy set that describes an organisation you are not.

Start with the decision nobody recorded.

Thirty minutes. Pick a system already in production and try to establish who approved it and on what basis.

Book a 30-minute scoping call

ORVIX · INDEPENDENT AI & TECHNOLOGY ASSURANCE · WE DISCLOSE EVERY COMMERCIAL RELATIONSHIP ON THE PAGE FOR THE SERVICE IT BELONGS TO. WHERE LICENSING IS REQUIRED, DELIVERY IS PERFORMED BY NAMED PARTNERS UNDER THEIR OWN LICENCE.