Be able to defend what you built.
A governance framework your organisation can actually operate, mapped against the regulation that binds you, and a per-system assessment that ends in a decision somebody can sign.
Something is about to go live, and somebody has to answer for it.
- Discipline
- Governance & Risk
- Engagements
- 02
- Typically bought by
- CISO · CRO · DPO · AI Governance lead
- Anchors
- £6,000 – £12,000+
Set every figure below against the build it protects — and against paying for that build a second time. That comparison is the whole argument for hiring an architect, and it is why the fees are published rather than quoted on request.
The ceilings are published. The exposure is yours.
Article 99 of the EU AI Act sets administrative fines by tier — whichever is higher, the fixed sum or the share of turnover. For SMEs and start-ups the calculation reverses and the lower figure applies.
Prohibited AI practices under Article 5.
Provider, importer, distributor and deployer obligations.
Supplying incorrect, incomplete or misleading information to authorities.
We deliver readiness and alignment, not a legal opinion. Formal interpretation of any regulation remains with your legal counsel. Figures are the ceilings set out in Article 99; what applies to you depends on your role and classification, which is what the assessment below establishes.
AI Governance & Regulatory Readiness
An AI governance framework mapped to applicable regulation and recognised standards.
- AI use spreading faster than any ability to see or approve it.
- A board or regulator asking how AI is controlled, with no answer available.
- EU AI Act obligations approaching with no assessment of what applies.
| Ref | Control | Requirement | Mapped to | Status |
|---|---|---|---|---|
| GOV-01 | Accountability | Named owner for each AI system | EU AI Act · ISO/IEC 42001 | Partial |
| INV-02 | Inventory | All AI systems registered and classified | EU AI Act · NIST AI RMF | Gap |
| LCM-04 | Lifecycle | Stage gate before production release | ISO/IEC 42001 | In place |
| EVL-07 | Evaluation | Defined thresholds, measured pre-release | NIST AI RMF | Partial |
| HUM-09 | Human oversight | Intervention route, tested | EU AI Act | Gap |
| TPY-12 | Third party | Model-provider dependency and exit route | ISO/IEC 42001 | Gap |
- 01AI governance framework
- 02Control catalogue mapped to applicable regulation and standards
- 03Gap assessment against current practice
- 04Risk classification methodology and stage gates
- 05AI system inventory structure and registration process
- 06RACI, forum terms of reference and decision rights
- 07Prioritised implementation roadmap
- 01Governance operating model and accountability structure
- 02AI policy and supporting standards
- 03AI system inventory and registration process
- 04Risk classification methodology
- 05Lifecycle controls and stage gates from idea to retirement
- 06Third-party, model-provider and supply-chain governance
- 07Human oversight requirements by risk class
- 08Evaluation and monitoring requirements
- 09Incident and change management for AI systems
- 10Evidence requirements — what is recorded, by whom, and where
- 11Roles and RACI, and the governance forums that make decisions
- 12Prioritised implementation roadmap
AI Risk & Impact Assessment
A structured assessment of one AI system covering risks, impacts, controls and residual risk.
- A system about to go live with no assessment behind it.
- A governance committee unable to approve without structured evidence.
- A use case touching personal data, vulnerable people or consequential decisions.
| Risk | Inherent | Controls | Residual | Decision |
|---|---|---|---|---|
| Incorrect model output | High | Evaluation + human approval | Medium | Proceed |
| Sensitive-data exposure | High | Filtering + access controls | Low | Proceed |
| Model drift | Medium | Evaluation monitoring | Low | Proceed |
| Third-party dependency | Medium | Exit and fallback strategy | Medium | Accept |
- 01Risk and impact assessment report
- 02Inherent risk, control, residual risk and decision table
- 03Control recommendations with owners
- 04Monitoring and evaluation requirements
- 05Governance decision record — ready for board sign-off
- 01Intended purpose, affected stakeholders and deployment context
- 02Materiality and criticality of the decisions supported
- 03Data and privacy implications
- 04Fairness and potential discriminatory impacts
- 05Explainability and transparency requirements
- 06Model limitations, accuracy and — where relevant — hallucination risk
- 07Security, misuse and abuse scenarios
- 08Human oversight design and its realistic effectiveness
- 09Third-party and model-provider dependencies
- 10Operational resilience and failure consequences
- 11Monitoring, evaluation and drift detection
- 12Regulatory considerations and classification
- 01Context
- 02People
- 03Data
- 04Model
- 05Decisions
- 06Controls
- 07Residual risk
- 01 Proceed Residual risk is acceptable as designed.
- 02 Proceed with controls Acceptable once named controls are in place and owned.
- 03 Redesign The residual position cannot be reached from this architecture.
- 04 Escalate Specialist or legal assessment required before a decision can be taken.
- 05 Do not proceed The impact cannot be controlled to an acceptable level.
Mapped against what actually applies.
We identify which of these bind you before mapping anything — the value is in the obligations that land, not the frameworks that get cited.
EU AI Act
RegulationLikely role and classification per use case, the technical and organisational obligations that follow, existing controls mapped against them, and the evidence gaps that remain.
ISO/IEC 42001
Management system standardAn AI management system structure — policy, objectives, roles, lifecycle controls and internal audit hooks — shaped so certification is achievable rather than assumed.
NIST AI RMF
Risk frameworkGovern, Map, Measure and Manage translated into named owners, stage gates and measurable evaluation requirements rather than a reading exercise.
UK regulatory expectations
Principles-based regimeThe cross-sector principles and the expectations of the regulators that actually supervise you, reconciled with the controls you already operate.
Sector-specific requirements
Supervisory rulesFinancial services, insurance, health and public sector obligations — model risk management, operational resilience, safeguarding and procurement rules — folded into the same control catalogue.
We deliver readiness and alignment, not a legal opinion. Formal interpretation of any regulation remains with your legal counsel.
Tell us what you are building, or what you have to defend.
A scoping conversation ends with a written view of the engagement, its deliverables, its duration and its fee. No obligation on either side.