01 Specify · AI Pre-Implementation Risk & Assurance Review
Set the control requirements before the build.
An independent review of a proposed or in-progress AI system, carried out before design and procurement decisions become expensive to reverse. We do not build the system. We define what it must satisfy in risk, security, safety, governance and evidence terms.
Where this sits
- 01Builder, internal team or vendor proposes the system
- 02Alacrix defines material risk and control requirements
- 03Build proceeds against explicit assurance criteria
- 04Controls are tested rather than asserted
- 05The organisation decides on the evidence
Who this is for
Organisations about to commit to an AI system that will carry real consequence.
- Leadership approving a material AI investment or vendor
- Risk, security and compliance functions asked to sign off later
- Internal engineering teams that want criteria rather than opinions
- Organisations procuring an AI capability from an external supplier
- Boards that want independent challenge before commitment
Outcomes
What changes for the organisation
Explicit control requirements
A written set of risk, security, safety, governance and evidence requirements the system must meet.
Challenge on record
Documented independent questions, assumptions tested and issues raised before they became sunk cost.
An assurance route
The tests, evidence and decision points that will determine whether the system is later approved.
What Alacrix does
We challenge the proposal, not the people building it.
The review examines the intended system against the reliance the organisation plans to place on it, and states what must be true before that reliance is reasonable.
- Interview accountable leaders, system owners and the build or vendor team
- Examine the proposed architecture, data flows, permissions and integrations
- Identify material risk, failure modes and misuse scenarios
- Specify required controls, oversight points and autonomy boundaries
- Specify the logging, retention and evidence the build must produce
- Define the assurance criteria for later readiness assessment
Review domains
What we examine
Six connected domains applied to the proposed system.
Intended use and reliance
What the system is for, what decisions it influences, and how much reliance the organisation intends to place on it.
Data and vendor exposure
What enters the system, who processes it, which third parties shape the risk and what the contract actually commits to.
Authority and autonomy
What the system will be permitted to see, change or trigger, and where autonomy would exceed acceptable consequence.
Failure and misuse
How the system could fail, be manipulated or be used outside intended purpose, and what would contain the impact.
Oversight requirements
Where human intervention must be meaningful rather than nominal, and what the reviewer needs in order to intervene.
Evidence requirements
What the build must log, retain and expose so operation can be reconstructed and assessed later.
Deliverables
What you leave with
Independent, not self-assured
Independence is the point.
Alacrix does not build the system, does not resell the platform and has no interest in the build being approved. The conclusion follows the evidence reviewed.
- We do not own or deliver the underlying AI build
- Findings are tied to the system, data or decision they affect
- Requirements are written so they can be tested, not interpreted
- This is an independent assurance opinion, not a certification or regulatory approval
Engagement process
How the work runs
- 01
Understand
Establish intended use, reliance, data, vendors and the decisions the system will influence.
- 02
Challenge
Test the assumptions, expose failure and misuse paths, and identify unmanaged material risk.
- 03
Specify
Issue the control, oversight and evidence requirements the build must satisfy.
Next step
Challenge the system before it is built.
A pre-implementation review turns assumptions into explicit, testable assurance requirements while change is still cheap.