Services / AI Systems Engineering
Most organisations deploying AI are deploying probabilistic systems — systems that produce outputs without a documentable reasoning path, that cannot explain why they produced a specific output for a specific input, and that produce different outputs for identical inputs under different conditions. For many applications this is acceptable. For any application where a regulator, a judge, a clinician, or a customer requires an explanation of the decision — it is not.
The EU AI Act reaches full enforcement in August 2026. High-risk AI systems — defined in Annex III and covering credit scoring, employment decisions, critical infrastructure management, biometric identification, educational assessment, law enforcement, migration control, and administration of justice — require a documented risk management system, transparency to affected persons, human oversight mechanisms, and conformity assessment before deployment. Organisations that deploy high-risk AI systems after August 2026 without these requirements are exposed to fines of up to 3% of global annual turnover. Organisations deploying prohibited AI practices face fines of up to 7%.
This service engineers AI systems that can satisfy these requirements — not by attaching compliance documentation to systems that cannot structurally satisfy them, but by designing systems where auditability, explainability, and deterministic behaviour are architectural properties, not post-hoc additions. The scientific foundation for this approach is the Unified Model Equation framework — the principle that every output of a correctly engineered system has a traceable, verifiable causal path from its inputs. That is not a regulatory aspiration. It is an engineering specification.
Price Range
£16,000 – £280,000+
Design and governance architecture only. System implementation is separate and additional.
Design and governance architecture only. System implementation is separate and additional.
Duration
6 weeks – 9 months
Design phase. Implementation timeline depends on system complexity and your team’s capability — outside our control.
Design phase. Implementation timeline depends on system complexity and your team’s capability — outside our control.
Deadline
EU AI Act: August 2026
Full enforcement for high-risk AI systems. Organisations without compliant architecture in place by this date are exposed to regulatory action.
Full enforcement for high-risk AI systems. Organisations without compliant architecture in place by this date are exposed to regulatory action.
Frameworks
EU AI Act · UK GDPR Art. 22 · FCA Consumer Duty · CQC AI Guidance · MHRA SaMD · DORA (AI) · ISO 42001
Scope boundary
We design the AI architecture, governance framework, risk management system, and compliance documentation. We do not train models, write production application code, or deploy AI systems.
Contract
Fixed-price design phase. 50% on signing, 50% on delivery acceptance.
August 2026 is not speculativeThe EU AI Act grace periods end in August 2026. High-risk AI systems deployed without compliant architecture after that date create immediate regulatory exposure — fines up to 3% of global annual turnover for the deploying organisation, plus personal liability for senior individuals accountable for AI governance under applicable sector regulations. Designing compliant architecture takes months. The time available to do it before enforcement is shorter than most organisations recognise.
What Current AI Deployments Get Wrong
The specific structural failures. Each is preventable. Most are invisible until a regulator, a lawyer, or an incident makes them visible.
The enthusiasm for deploying AI is running significantly ahead of the governance and engineering rigour required to deploy it safely and legally in regulated contexts. The failures below are structural — not edge cases, not implementation mistakes, but consequences of the fundamental architecture of probabilistic AI systems applied to domains that require determinism, auditability, and explainability. Each has an engineering solution. The solution requires designing the system correctly from the start, not retrofitting compliance documentation onto a system whose architecture cannot satisfy the underlying requirements.
01
The system cannot explain its outputs
A large language model, a neural network classifier, and a gradient-boosting model share a fundamental characteristic: they produce outputs without a human-interpretable reasoning path. They can be prompted to generate an explanation, but that explanation is itself a probabilistic output — it is not a trace of the actual computation that produced the original output. When a customer asks why their loan was declined, when a regulator asks why the fraud detection system flagged this transaction, when a clinician asks why the diagnostic system produced this recommendation — the system cannot answer. A generated explanation is not an audit trail.
Regulatory breach
UK GDPR Article 22: individuals subjected to solely automated decisions have the right to obtain human intervention, express their view, and obtain an explanation of the decision. The explanation must reflect the actual decision logic, not a post-hoc rationalisation. EU AI Act Article 13: high-risk AI systems must be transparent to deployers and affected persons. FCA Consumer Duty: AI in customer-facing processes must be able to evidence good outcomes — which requires traceable decision logic.
Engineering solution
Deterministic rule-based decision layers that produce a complete, human-readable reasoning trace as a structural output — not as a post-hoc explanation. Every decision has a documented causal path: the inputs, the rules applied, the thresholds crossed, the output produced. This path is generated at decision time, stored with the decision record, and retrievable on demand for any decision ever made by the system.
02
The same input produces different outputs on different runs
Probabilistic AI systems are, by design, non-deterministic. Temperature parameters, random seeds, floating-point arithmetic differences across hardware, and model state all mean that the same input may produce different outputs on different executions. For a creative writing assistant, this is a feature. For a credit decisioning system, a fraud detection system, a clinical decision support tool, or any system whose outputs have material consequences for identifiable people, this is a fundamental governance failure — the system’s decisions cannot be reproduced, audited, or challenged on the basis of the original computation.
Regulatory breach
EU AI Act Article 9: high-risk AI systems must have a risk management system that includes evaluation of non-deterministic behaviour and its consequences for affected persons. ISO 42001 (AI Management System Standard): reproducibility of AI system outputs is a required property for systems in high-risk contexts. Financial services: DORA requires ICT risk management for AI systems used in regulated activities — non-deterministic outputs are an ICT risk that must be assessed and mitigated.
Engineering solution
Deterministic inference pipeline with fixed random seeds, hardware-independent arithmetic, and immutable model versioning. Every inference execution produces identical outputs for identical inputs, verifiable by re-running the inference against the stored model version and input record. Outputs are reproducible for any historical decision on demand.
03
The system has no human oversight mechanism
AI systems in production frequently operate without functioning human oversight. Oversight mechanisms are designed at deployment, set with high confidence thresholds so the system almost never escalates to human review, and then gradually stop being monitored as the team becomes confident the system is working correctly. The result: the system makes decisions that should be reviewed by a human, the human review queue is empty because no one is monitoring it, and the only discovery that the oversight mechanism has failed is a downstream consequence that reveals decisions that should never have been autonomous.
Regulatory breach
EU AI Act Article 14: high-risk AI systems must be designed and developed in such a way that they can be effectively overseen by natural persons during the period in which the AI system is in use. The oversight must be genuinely effective — not a nominal mechanism that no one monitors. NHS/CQC: AI in clinical settings must be subject to clinical governance processes including human oversight of AI-influenced decisions. MHRA SaMD: AI medical devices require documented human oversight as part of the quality management system.
Engineering solution
Human oversight architecture designed as a mandatory component of the system — not an optional escalation path. Confidence thresholds set conservatively and justified by risk analysis. Oversight queue monitoring with SLA on human review time. Automatic escalation if review SLA is breached. Monthly audit of the proportion of decisions that bypassed human review, with justified threshold adjustment or system pause if the proportion is outside the approved range.
04
The training data encodes discrimination the organisation does not know about
AI systems trained on historical data inherit the biases present in that data. A credit scoring system trained on historical approval decisions inherits the discrimination embedded in those historical decisions. A recruitment screening system trained on historical hiring data perpetuates historical hiring patterns, including illegal discrimination. The system does not intend to discriminate — it is optimised to replicate historical outcomes. If historical outcomes were discriminatory, the system is discriminatory. Most organisations deploying AI on historical data have not conducted a systematic bias assessment of that data or its embedded historical decisions.
Regulatory breach
EU AI Act Article 10: training, validation, and testing data for high-risk AI systems must be subject to data governance practices that examine data for possible biases and address them. Equality Act 2010: discriminatory outcomes produced by AI systems are not exempt from equality law because they were produced algorithmically. PSED (Public Sector Equality Duty): public sector AI deployments must demonstrate non-discrimination — algorithmic discrimination is not a defence. FCA: Consumer Duty requires fair outcomes for all customer groups — AI-driven unfair outcomes violate the duty regardless of intent.
Engineering solution
Systematic bias assessment of training data before model training begins: statistical analysis of outcomes by protected characteristic, identification of proxy variables that encode protected characteristics, and documented mitigation for each identified bias source. Post-deployment monitoring of output distributions by protected characteristic with automated alerting when distributions diverge from approved baselines. Documented governance review when alerts trigger.
05
The system’s risk classification is wrong
Organisations are systematically misclassifying their AI systems under the EU AI Act. The high-risk categories in Annex III are broader than most legal and compliance teams initially assess. A recruitment screening tool that filters CVs before human review is high-risk (Annex III.4 — employment and workers management). A system that prioritises customer service queues is high-risk if the prioritisation affects access to essential private services. An employee monitoring system for productivity is high-risk. An AI system that recommends which customers receive which financial product is high-risk. Misclassification as non-high-risk means none of the Article 9–15 requirements are implemented — then enforcement corrects the classification with a fine attached.
Regulatory consequence
EU AI Act Article 51: high-risk AI systems must be registered in the EU database before deployment. Deploying an unregistered high-risk AI system is a violation independent of whether the system itself is compliant. Fines for non-compliance with high-risk requirements: up to 3% of global annual turnover. The AI Act’s conformity assessment requirements for high-risk systems include a technical file, documentation, and in some cases third-party assessment — all of which take months to prepare.
Engineering solution
Systematic classification of every AI system in the organisation against EU AI Act Annex III categories, Annex I prohibited practices, and general-purpose AI model provisions. Classification is documented with the reasoning. Each high-risk system receives a gap assessment against Articles 9–15 requirements. Each gap has a remediation specification. The classification is reviewed on a defined schedule and when the system’s use or context changes.
06
Model drift degrades performance undetected
AI models trained on historical data become less accurate as the world changes and the training data becomes less representative of current conditions. A fraud detection model trained before a new fraud pattern emerged will miss that pattern. A credit scoring model trained during low interest rate conditions may perform differently in a high-rate environment. A clinical decision support model trained on pre-pandemic patient data will perform differently on post-pandemic patient populations. Most organisations have no systematic monitoring for model drift — the first signal that a model has degraded is a downstream consequence that the degraded model produced.
Regulatory consequence
EU AI Act Article 9(d): the risk management system for high-risk AI systems must include evaluation of risks that may emerge after deployment, including model drift and changes in the deployment context. ISO 42001: AI management systems must include ongoing monitoring of AI system performance and mechanisms for detecting and responding to performance degradation. MHRA SaMD: post-market surveillance is a regulatory requirement for AI medical devices — drift monitoring is the primary mechanism.
Engineering solution
Performance monitoring pipeline with defined metrics, measurement frequency, and acceptable performance bounds for every production AI system. Automated alerting when metrics fall outside bounds. Documented re-evaluation protocol when drift is detected: root cause assessment, mitigation options, decision authority for whether the system should be paused pending retraining or remain in operation with enhanced human oversight. Re-training trigger conditions defined before deployment, not after drift is discovered.
07
Vendor AI systems are treated as the organisation’s own compliance problem
Organisations that deploy AI systems built by vendors — SaaS AI tools, AI modules within enterprise software, AI features in cloud services — frequently assume that the vendor’s compliance with the AI Act is the organisation’s compliance. It is not. The EU AI Act distinguishes between AI system providers (who build and make available the system) and deployers (who use the system in a specific context). Deployers carry their own obligations under Articles 26–29, including risk assessment of the deployment context, human oversight implementation, monitoring, and employee information obligations. The vendor’s CE marking does not discharge the deployer’s obligations.
Regulatory consequence
EU AI Act Article 26: deployers of high-risk AI systems must assign human oversight to qualified persons, ensure the system is used in accordance with its instructions for use, monitor its operation, inform the provider of serious incidents, and keep logs for defined periods. A deployer that uses a compliant vendor AI system in a non-compliant way — without appropriate human oversight, without monitoring, without employee notification — is in violation regardless of the vendor’s compliance status.
Engineering solution
Deployer obligations audit for every vendor AI system in use: classification of the system, assessment of deployment context against the system’s intended purpose, human oversight implementation, monitoring programme, log retention, and employee information. For each vendor AI system classified as high-risk in the organisation’s deployment context: formal assessment of whether the deployment context creates obligations beyond what the vendor’s instructions for use address, and governance design for any gap.
08
AI agents operate without authorisation boundaries
Agentic AI systems — AI that can take actions in systems, make API calls, write and execute code, send communications, and make purchases — are being deployed with tool access that significantly exceeds what any individual action requires. An AI agent given read/write access to a customer database to answer customer queries can modify or delete that database. An AI agent given API access to financial systems to generate reports can initiate transactions. The principle of least privilege — fundamental to security architecture — is not being applied to AI agent tool access because the complexity of defining precise tool boundaries is underestimated.
Regulatory consequence
EU AI Act: AI agents that can take consequential actions on behalf of natural persons or organisations require human oversight mechanisms appropriate to the risk level of the actions available to them. UK GDPR: AI agents that process personal data must have precisely defined purposes and data access scoped to those purposes — broad database access for an agent whose stated purpose is query answering is a purpose limitation violation. Financial services: unauthorised transactions initiated by an AI agent create regulatory liability equivalent to unauthorised employee transactions.
Engineering solution
Privilege boundary architecture for every AI agent: explicit enumeration of the actions the agent is authorised to take, the systems it is authorised to access, and the data it is authorised to read or write. All actions outside the enumerated boundary return an authorisation error — the agent cannot request, negotiate, or infer expanded access. High-consequence actions (financial transactions, data deletion, external communications) require explicit human confirmation before execution regardless of agent confidence. Kill-switch mechanism that can immediately revoke all agent tool access.
EU AI Act — What It Requires & When
Specific articles. Specific deadlines. Specific penalties. Not a future consideration.
The EU AI Act applies to organisations that place AI systems on the EU market or put them into service within the EU — and, through its provisions on deployers, to UK organisations that use AI systems developed in the EU or used in EU-connected contexts. For UK financial services firms operating under DORA with EU counterparties, healthcare organisations using AI systems with EU-origin training data, and technology companies with EU customers: the Act’s requirements are not academic. The enforcement timeline below is not provisional — these are enacted law with fixed dates.
In Force
August 2024
EU AI Act entered into force. 24-month implementation period began for most provisions. Organisations should have started compliance programmes at this point.
Prohibited Practices
February 2025
Prohibited AI practices banned: social scoring, real-time biometric surveillance in public spaces (with exceptions), subliminal manipulation. Fine: up to 7% of global annual turnover.
⚠ Approaching Fast
August 2026
Full enforcement for high-risk AI systems (Annex III). All Articles 9–15 requirements must be met. Conformity assessment complete. Technical file prepared. EU database registration. Fine: up to 3% of global annual turnover.
GPAI Models
August 2025
General-purpose AI model obligations apply to providers of foundation models with systemic risk. Organisations using GPAI models as components of their own systems carry deployer obligations from this date.
| Article | Scope | Requirement | What this means in practice |
|---|---|---|---|
| Art. 9 | High-risk systems (Annex III) | Risk Management System | Documented risk management system covering identification and analysis of known and foreseeable risks, estimation and evaluation of risks, and specification of risk management measures. Must be reviewed and updated throughout the system lifecycle. Cannot be a one-time compliance exercise. |
| Art. 10 | High-risk systems | Data Governance | Training, validation, and testing data must be subject to data governance practices. Data must be examined for possible biases. Data must be relevant, representative, free of errors and complete to the extent possible. Data residency and processing conditions must be documented. Historical data used for training must have its provenance and selection criteria documented. |
| Art. 11–12 | High-risk systems | Technical Documentation & Logging | Technical file must be prepared before placing the system on the market or into service. Must contain: general description, design process, development methodology, monitoring, functioning, and capabilities. Logging capability that enables monitoring of the system’s operation — logs must be automatically generated and retained for the period specified by the provider (minimum 6 months in most cases). |
| Art. 13 | High-risk systems | Transparency & Information | Deployed high-risk AI systems must provide instructions for use to deployers that include: intended purpose, level of accuracy, limitations, human oversight requirements, and technical measures for human oversight. Where the system interacts with natural persons, they must be informed they are interacting with an AI system (unless obvious from context). |
| Art. 14 | High-risk systems | Human Oversight | High-risk AI systems must be designed and developed in such a way as to be effectively overseen by natural persons during use. This must include: ability to understand capabilities and limitations, ability to detect and address anomalies and failures, ability to disregard, override, or reverse outputs, and ability to intervene on the system’s operation or interrupt it. |
| Art. 15 | High-risk systems | Accuracy & Robustness | High-risk AI systems must achieve appropriate levels of accuracy, robustness, and cybersecurity — for the entire lifecycle. Accuracy metrics must be declared in the instructions for use. The system must be resilient to errors, faults, inconsistencies in data, and to adversarial inputs. Performance must be consistent and not degrade in a way that affects the system’s compliance with these requirements. |
| Art. 26 | Deployers of high-risk systems | Deployer Obligations | Deployers (organisations using high-risk AI systems built by vendors) must: assign human oversight to qualified persons, use systems only in accordance with instructions for use, monitor the system’s operation, keep logs for periods specified by the provider, inform the provider of serious incidents, conduct their own fundamental rights impact assessment where the system affects the public. Vendor compliance does not discharge deployer obligations. |
| Art. 22 | GPAI models with systemic risk | Systemic Risk Management | Providers of general-purpose AI models deemed to have systemic risk (based on compute thresholds) must: perform model evaluations including adversarial testing, assess and mitigate systemic risks, report serious incidents, ensure cybersecurity protections. For organisations that fine-tune or customise GPAI models for deployment: obligations transfer proportionally based on the degree of modification. |
The conformity assessment for Annex III systems takes months, not weeks. For high-risk systems not subject to third-party assessment (most Annex III categories), the provider or deployer conducts a self-assessment against Articles 9–15. This requires: a completed technical file, documented data governance procedures, a functioning risk management system with documented review cycles, logging infrastructure producing compliant logs, instructions for use meeting Article 13 requirements, and evidence of human oversight mechanisms meeting Article 14 requirements. Preparing all of these from a standing start takes a minimum of 3–6 months for a single system. Organisations with multiple high-risk systems in scope for August 2026 that have not begun this process face a realistic timeline problem — not a theoretical one.
Engagement Tiers — Scope, Price, Timeline
Four engagement types. Architecture and governance design only. Implementation is always separate.
AI systems engineering engagements range from a rapid compliance assessment to a full enterprise AI governance programme. All produce architecture designs, governance frameworks, and compliance documentation — not implemented systems. System implementation is carried out by your data science and engineering team, or by a technology implementation partner, from the specifications we produce. The separation matters: we are independent of any AI platform vendor, and our recommendations are not influenced by implementation commercial interests.
Engagement Type 1
AI Readiness & Compliance Assessment
For any organisation that has deployed AI systems, is deploying AI systems, or uses vendor AI tools in business-critical processes and needs to understand its regulatory position before August 2026. This engagement produces an honest assessment of what exists, what it means under applicable law, and what needs to change. It does not require a prior AI programme — it can be the first structured engagement with AI governance.
£16,000
Fixed · VAT excl.
6 weeksExtended if the AI system inventory is larger than disclosed at scoping. Each additional system above 10: £800.
Inventory & Classification
AI system inventory: all AI systems in use across the organisation, including vendor SaaS tools with AI features, up to 10 systems
EU AI Act classification per system: prohibited, high-risk (Annex III category), limited risk, or minimal risk — with documented reasoning
Deployer obligations assessment for each vendor AI system classified as high-risk
UK GDPR Article 22 assessment: which systems make solely automated decisions affecting individuals
Sector-specific AI regulatory obligations: FCA Consumer Duty, CQC, MHRA SaMD, DORA, NHS DSPT — whichever apply
Gap Analysis
Article 9 gap: is a risk management system in place? Is it documented? Is it reviewed?
Article 10 gap: has training data been assessed for bias? Is data governance documented?
Article 13 gap: are transparency and information obligations met for deployers and affected persons?
Article 14 gap: are human oversight mechanisms genuinely effective and monitored?
Article 15 gap: are accuracy and robustness requirements documented and monitored?
Model drift monitoring: is any monitoring in place? What does it cover? What are the response procedures?
AI agent privilege boundaries: do any agents have access that exceeds their stated purpose?
Output
Written assessment report: 20–35 pages, severity-rated findings per system and per requirement
Regulatory exposure summary: estimated fine exposure per system per framework if current gaps persist to enforcement
Prioritised remediation list: each gap with the specific action required, estimated effort, and recommended sequencing
August 2026 readiness indicator per system: compliant, remediation required, or structurally non-compliant (requires re-architecture)
90-minute findings presentation with leadership and legal/compliance team
Remediation design (separate engagement)
Technical file preparation
Risk management system design
Timeline — 6 Weeks
Wk 1
AI Inventory
All AI systems identified including shadow AI. IT, business unit, and procurement interviews.
Shadow AI — vendor AI tools adopted by departments without IT governance — is consistently underreported. Business unit interviews are as important as IT interviews.
Wk 2
Classification
EU AI Act classification per system. Sector-specific regulatory mapping. Deployer obligation assessment for vendor systems.
Legal/compliance team must be available for classification review. Classification disputes add 3–5 business days per disputed system.
Wk 3–4
Gap Analysis
Articles 9–15 gap assessment per high-risk system. Documenting what exists and what does not against each requirement.
Gap analysis requires access to existing AI governance documentation, model cards, data governance records, and oversight process documentation. If none exists, the gap analysis is faster but the findings are uniformly critical.
Wk 5
Report Drafting
Written assessment with severity ratings, exposure estimates, and prioritised remediation list.
Findings are reported as they are assessed — not softened to reduce discomfort. If the findings are uniformly critical, the report says so explicitly.
Wk 6
Presentation & Handover
90-minute findings session with leadership and legal/compliance. Report issued. Q&A on remediation options.
Leadership must be present at the findings session. Delivering a critical regulatory assessment to an absent decision-maker is a documented failure mode for compliance programmes.
What Your Team Must Provide
Honest disclosure of all AI systems in use — including tools adopted by business units outside IT governance. If shadow AI is excluded from the assessment, the assessment is incomplete.
IT lead: 4–6 hours across weeks 1–2 for system inventory and technical access
Business unit representatives: 30-minute interviews per unit with AI tool usage (week 1)
Legal/compliance team: 2 hours in week 2 for classification review and sector-specific regulatory input
Access to: existing AI governance documentation, model cards, data governance records, vendor contracts for AI systems
Senior leadership: available for 90-minute findings presentation in week 6
What This Does Not Produce
Compliance — the assessment identifies gaps. Remediation of those gaps requires the subsequent design engagements below
Technical file for EU AI Act conformity assessment — this is a deliverable of the architecture design engagement
Risk management system — design engagement required
Data bias assessment — design engagement required for each affected system
More than 10 systems: each additional system above 10 is £800 and extends the timeline by 2 business days per additional system
Engagement Type 2
Single System AI Architecture & Compliance Design
For organisations that need to bring a specific AI system — or a specific AI system under development — into compliance with applicable regulations. This covers both systems already deployed that have been assessed as non-compliant, and new systems being designed where building compliance in from the start is the objective. One system per engagement. Multiple systems require separate engagements or the Enterprise Governance Programme (Type 4).
£45,000
Fixed · VAT excl.
12 weeksLonger for systems requiring re-architecture from probabilistic to deterministic foundations. This is disclosed after initial technical assessment.
Architecture Design
Technical assessment of the current or proposed system: architecture, training approach, inference pipeline, output handling
Determinism assessment: can the system produce reproducible outputs? If not: redesign specifications for deterministic inference
Explainability architecture: design of the reasoning trace mechanism — how every output is produced with a documented causal path
Human oversight architecture: escalation thresholds, oversight queue design, SLA on human review, monitoring of oversight effectiveness
AI agent privilege boundary design (if applicable): enumerated tool access, authorisation enforcement, high-consequence action confirmation, kill-switch
Model drift monitoring design: metrics, measurement frequency, performance bounds, alerting, re-training trigger conditions
Implementation specification: your engineering team builds from this document
Governance & Compliance
EU AI Act risk management system (Article 9): documented, with review schedule and governance process
Data governance documentation (Article 10): training data provenance, bias assessment methodology, mitigation measures
Technical file (Articles 11–12): conformity assessment documentation package
Instructions for use (Article 13): deployer-facing documentation meeting transparency requirements
Human oversight specification (Article 14): implementation requirements and monitoring obligations
Accuracy and robustness specification (Article 15): declared performance metrics and monitoring requirements
UK GDPR Article 22 compliance documentation: automated decision-making framework, individual rights processes
Sector-specific compliance documentation: FCA / CQC / MHRA / DORA as applicable
What Is Explicitly Not Included
Model training or retraining — executed by your data science team from our specifications
Production code implementation — executed by your engineering team from our specifications
Third-party conformity assessment (required for some Annex III categories) — procured separately from accredited body
EU AI Act database registration — carried out by your legal team using our technical file
Bias assessment of training data (separate analytical work: £8,000–£22,000 depending on dataset complexity)
Ongoing monitoring execution — architecture designed by us, operated by your team
Note: If the initial technical assessment reveals the system requires fundamental re-architecture (common when a probabilistic LLM-based system is being brought into a high-risk context that requires determinism), this is disclosed in writing before proceeding. Re-architecture engagements are priced separately after the assessment finding.
Timeline — 12 Weeks (assumes no re-architecture requirement)
Wk 1–2
Technical Assessment
System architecture review. Determinism test. Explainability capability assessment. Current compliance documentation review.
If the system is probabilistic and the use case requires determinism, the re-architecture finding is disclosed here. This can change the scope of the engagement fundamentally.
Wk 3–5
Architecture Design
Explainability mechanism design. Human oversight architecture. Drift monitoring design. Agent privilege boundaries if applicable.
Architecture design requires access to the engineering team to understand implementation constraints. Designs that ignore implementation constraints produce specifications that cannot be built.
Wk 6–9
Compliance Documentation
Technical file, risk management system, instructions for use, oversight specification, sector-specific documentation.
Legal review of compliance documentation by your legal team typically adds 1–2 weeks. Plan for this before the engagement timeline is communicated to regulators.
Wk 10–11
Review & Revision
Client review of all deliverables. One revision round per document included. Legal and compliance sign-off.
Legal sign-off on the technical file and risk management system documentation is a precondition for EU AI Act registration. Factor legal team availability into the review timeline.
Wk 12
Handover
All deliverables. Implementation specification walkthrough with engineering team. Compliance documentation handover to legal.
Engineering team must attend the implementation specification walkthrough. Implementing without attending the handover is a documented cause of divergence from specification.
What Your Team Must Provide
Data science or ML lead: 10–15 hours across weeks 1–5 for technical assessment and architecture design collaboration
Engineering lead: 6–8 hours across weeks 3–5 and week 12 for implementation constraint input and specification walkthrough
Legal/compliance: 4–6 hours across weeks 6–11 for compliance documentation review and sign-off
Access to: system architecture documentation, model cards, training data documentation, existing governance documentation, vendor contracts if applicable
Honest technical disclosure: the system’s actual architecture, actual training approach, actual inference behaviour including known failure modes
What This Costs Beyond the Engagement Fee
Engineering implementation of the architecture design: typically 2–6 months of engineering time depending on system complexity
Third-party conformity assessment (if required for your Annex III category): £8,000–£30,000 from an accredited notified body
Training data bias assessment if required: £8,000–£22,000 depending on dataset size and complexity
EU AI Act database registration: legal team time, typically 4–8 hours using the technical file we produce
Re-architecture (if the system is found to require fundamental redesign): disclosed after week 1–2 assessment, priced separately
Engagement Type 3
Deterministic AI System Design
For organisations that need to build an AI system for a high-risk context — clinical decision support, credit decisioning, fraud detection, automated compliance monitoring, infrastructure risk assessment — where probabilistic AI cannot satisfy the auditability, reproducibility, and explainability requirements of the use case. This engagement designs the deterministic AI architecture from the ground up, not as a retrofit to a probabilistic system. Grounded in the UME framework: every output has a verifiable causal trace from its inputs.
£85,000
Fixed · VAT excl.
18 weeksDesign phase only. Implementation of a deterministic AI system is a significant engineering programme — typically 6–18 months additional, depending on domain complexity.
System Architecture
Domain knowledge formalisation: structured representation of the rules, thresholds, conditions, and relationships that govern the decision domain
Causal model design: explicit representation of the causal relationships between inputs and outputs — not a trained mapping, a designed model
Inference engine specification: how the system processes inputs through the causal model to produce outputs with complete reasoning traces
Confidence and uncertainty quantification: how the system represents its confidence in an output and when it should escalate to human review
Edge case and exception handling: explicit specification of how the system behaves for inputs outside the training or design distribution
Adversarial robustness specification: how the system detects and responds to inputs designed to manipulate its outputs
Complete implementation specification: your engineering team builds from this document without ambiguity
Validation & Governance
Validation methodology: how to confirm the implemented system behaves as specified, not just as measured on a test set
Performance specification: declared accuracy metrics with confidence intervals, not optimistic point estimates
Failure mode catalogue: documented known failure modes, their conditions, their consequences, and their mitigations
Human oversight integration: where human review is required, how it integrates with the system’s output, and how overrides are recorded
Full EU AI Act compliance documentation package: technical file, risk management system, instructions for use, conformity assessment documentation
Sector-specific compliance documentation: clinical governance for healthcare, FCA governance for financial services, or equivalent
Post-deployment monitoring specification: what to measure, at what frequency, with what response protocol
Why This Takes 18 Weeks
Weeks 1–4: Domain knowledge elicitation — the most time-intensive phase. Structured interviews with domain experts to extract, validate, and formalise the knowledge that drives the decision domain. This cannot be rushed without producing a system that works in testing and fails in production.
Weeks 5–8: Causal model design — translating elicited knowledge into a formal causal model that can be implemented and validated. Multiple iterations with domain experts to validate the model against edge cases they recognise from practice.
Weeks 9–12: Inference engine and architecture specification — technical specification for the implementation team.
Weeks 13–16: Compliance documentation and governance framework — EU AI Act technical file, risk management system, sector-specific documentation.
Weeks 17–18: Review, revision, and handover.
The knowledge elicitation phase is where most deterministic AI projects fail. The quality of the causal model is bounded by the quality of the knowledge elicitation. This is the phase that cannot be compressed.
What Your Team Must Provide
Domain experts: the individuals whose knowledge the system is designed to formalise. Available for structured interviews totalling 20–40 hours across weeks 1–8. This is the most critical input and the most common bottleneck — if domain experts are unavailable, the knowledge elicitation phase cannot proceed.
Engineering lead: available for architecture specification review in weeks 9–12. Must understand the target implementation environment.
Legal/compliance: 6–8 hours across weeks 13–16 for compliance documentation review. Clinical governance lead for healthcare systems.
Access to: case records, decision logs, historical outcomes, exception reports — the evidence base for validating the causal model against real-world decisions
Hard Truths About This Engagement
A deterministic AI system is only as good as the knowledge elicited from the domain experts. If the domain knowledge is contested, incomplete, or inconsistent — as it often is in complex domains — the system will reflect those limitations. We document them explicitly.
Implementation of the designed system is a significant engineering programme. A credit decisioning deterministic AI system typically requires 9–18 months of engineering work to implement, test, and validate after the design is complete. Clinical decision support: similar. This is not a fast path to AI deployment.
A deterministic system designed for a specific domain cannot be repurposed to a different domain without repeating the knowledge elicitation and causal model design. The design is domain-specific.
Implementation: engineering team cost typically £200,000–£800,000 depending on domain complexity and team size.
Engagement Type 4
Enterprise AI Governance Programme
For organisations with multiple AI systems across business units, an AI development programme, or a strategic AI investment that requires an enterprise-wide governance framework — not system-by-system compliance. Also appropriate for organisations that have received regulatory scrutiny of their AI governance and need to demonstrate systematic improvement. Individually scoped. Minimum engagement: £120,000. Typically £120,000–£280,000 depending on number of systems and organisational complexity.
From £120,000
Individually scoped · fixed · VAT excl.
From 6 monthsEnterprise governance programmes with 10+ systems and multiple regulatory frameworks commonly run 9–12 months.
Enterprise Scope
Full AI system inventory and classification across the entire organisation — no ceiling on system count
Enterprise AI governance framework: policies, procedures, roles, accountability, escalation paths, and board reporting
AI risk taxonomy: organisation-specific risk classification for AI systems, aligned to regulatory requirements
AI procurement governance: standards and process for evaluating and approving new AI system deployments and vendor AI tools
EU AI Act compliance programme for all in-scope systems: classification, gap assessment, and remediation roadmap
ISO 42001 alignment: AI management system design if certification is a programme objective
Architecture standards: enterprise-wide requirements for AI system explainability, oversight, monitoring, and documentation
Why Enterprise Is Different
Enterprise governance must survive the departure of the individuals who designed it — it must be embedded in processes and tools, not in individuals’ knowledge
Enterprise AI governance intersects with data governance, security architecture, procurement, legal, HR (for AI in employment contexts), and customer-facing product governance — all must be aligned
Regulatory scrutiny at enterprise scale is more systematic — regulators conduct thematic reviews of sectors, and organisations with systematic governance gaps across multiple systems face proportionally greater exposure
Enterprise programmes require sustained leadership commitment and cross-functional coordination over months — not a single project team for a defined period
Named C-suite AI governance sponsor required — without executive accountability, enterprise AI governance programmes stall at the point of cross-functional friction
Minimum Enterprise Requirements
Named C-suite sponsor: CISO, CTO, CRO, or equivalent with cross-functional authority
AI governance steering committee: IT, legal, compliance, data science, and business unit representation — meets monthly throughout the programme
Dedicated internal programme coordinator: not required to be technical, required to have authority to schedule resources across all participating departments
All business units: available to participate in AI system inventory and governance framework validation workshops
Legal team: sustained availability throughout the programme — AI Act compliance work requires legal input at multiple stages, not a single sign-off
Bilateral Obligations
What both parties commit to. Specific to AI engagements.
Client Obligations
Disclose all AI systems — including vendor tools and shadow AI
The most dangerous AI compliance gap is the one that is not known to be in scope. Vendor SaaS tools with AI features, AI capabilities in enterprise software, AI tools adopted by individual employees or departments outside IT governance — all of these carry regulatory obligations for the deploying organisation. If they are not disclosed, they are not assessed, and the exposure is not visible. We will ask systematically about all of these in the inventory phase. Complete disclosure is a client obligation, not a courtesy.
If undisclosed AI systems are later discoveredAdded to the assessment scope immediately. If within the system count ceiling: no additional cost. Above the ceiling: scope addition at stated per-system rate. If the undisclosed system creates a regulatory exposure that the assessment recommended addressing, the undisclosed system’s exposure is not covered by the assessment that did not include it.
Domain experts must be genuinely available for knowledge elicitation (Type 3 engagements)
For deterministic AI system design, the knowledge elicitation phase is entirely dependent on access to the domain experts whose knowledge the system is designed to formalise. These are typically the most senior and most time-constrained people in the relevant domain — the consultants, the senior clinicians, the experienced underwriters, the veteran fraud analysts. They must be available for structured sessions totalling 20–40 hours across a 4–8 week period. Substituting junior staff or using documentation as a proxy for expert knowledge produces a lower-quality causal model that will fail in production on the cases that documentation does not cover.
If domain experts are unavailable at required timesKnowledge elicitation phase pauses. Timeline extends by the unavailability period. If experts are unavailable for more than 10 cumulative business days, re-mobilisation protocol applies. If the engagement proceeds with substitute knowledge sources, the causal model’s quality limitations are documented explicitly in the deliverables — this cannot be concealed in the final deliverables.
Do not deploy an assessed system as compliant before remediation is complete
An assessment finding that a system has compliance gaps does not itself create compliance — it creates a documented gap. Deploying or continuing to operate a system that has been assessed as non-compliant — while remediation is in progress — is the deploying organisation’s decision and its liability. We do not represent that a system is compliant until the specific remediation items that create compliance have been implemented and, where applicable, validated. Using our assessment documentation to represent compliance before that point is a misrepresentation of the assessment’s conclusions.
If the client represents an assessed-but-unremediated system as compliantThis is outside our control and our liability. Our assessment documentation states the gaps. If a regulator inquires, the assessment will show the gaps were identified and remediation was pending.
RJV Obligations
Classify systems using the actual regulatory text, not summaries
EU AI Act classification is based on the actual Annex III categories and the actual definitions in Articles 2–5. We do not use simplified interpretations or industry summaries. Where the classification is genuinely ambiguous — which it is in some cases, because the Act’s language on “intended purpose” creates interpretation questions that will ultimately be resolved by enforcement decisions and case law — we say so explicitly and document the reasoning for the classification we recommend, including the alternative classifications and the argument for each.
If a classification is later overturned by regulatory enforcementWe cannot guarantee that our classification will match eventual enforcement decisions for genuinely ambiguous cases. Where we document ambiguity, that documentation records that the classification was made under uncertainty. We do not represent uncertain classifications as certain.
Report findings that increase regulatory exposure without softening them
AI assessments consistently reveal that the organisation’s actual regulatory exposure is higher than the individuals commissioning the assessment expected. Some of the most significant findings — a system that should have been classified as high-risk but was not, a human oversight mechanism that does not function as documented, a training dataset with significant bias that was not assessed — are findings that the commissioning team may not wish to see stated plainly. We state them plainly. The assessment report reflects what the investigation found, not what the organisation would prefer it to have found.
If you believe a finding is materially incorrectRaise within 10 business days of receiving the report. We review the finding and either confirm it with the supporting evidence or revise it if the challenge is correct. We do not revise findings in response to discomfort rather than substantive challenge.
Disclose when a system requires re-architecture before compliance documentation can be produced
Some systems cannot be made compliant through governance documentation alone — their architecture is structurally incompatible with the requirements they must satisfy. A probabilistic LLM used for credit decisioning cannot satisfy Article 13 transparency requirements through instructions for use — it must be re-architected to produce genuine reasoning traces. When the initial technical assessment reveals this, we disclose it in writing within 2 weeks of the engagement start, before significant compliance documentation work has been invested. We do not produce compliance documentation for systems that cannot satisfy the underlying requirements — documentation that misrepresents a non-compliant system as compliant is worse than no documentation.
If re-architecture is disclosed and the client does not wish to proceedEngagement concludes at the end of the assessment phase. Fee for work completed is invoiced. The finding is documented and provided to the client. The client can use the finding to make an informed decision about the system’s future.
Questions that need answers before August 2026
We use OpenAI / Azure OpenAI / AWS Bedrock for our AI systems. Are we covered by their compliance?
No. Under the EU AI Act, your organisation is the deployer of the AI system. The model provider (OpenAI, Microsoft, Amazon) is the provider of the underlying model. The deployer carries its own obligations under Article 26 — independently of the provider’s compliance status. You must: assign human oversight, use the system in accordance with its instructions for use, monitor its operation, keep logs, and conduct your own fundamental rights impact assessment where applicable. If you have built an application on top of a cloud AI API, you are also likely an AI system provider under the Act — with additional obligations beyond the deployer tier. A readiness assessment will tell you precisely which obligations apply to your specific architecture and use case.
The EU AI Act is an EU law. We are a UK company. Does it apply to us?
It applies to you if you place AI systems on the EU market, put them into service in the EU, or if your AI systems’ outputs are used in the EU — even if you are based in the UK. The Act has extra-territorial scope similar to GDPR. UK financial services firms with EU counterparties, UK healthcare organisations whose AI tools process data from EU patients or are licensed to EU providers, and UK technology companies whose AI products are sold to EU customers are likely in scope. The UK has not implemented equivalent legislation yet — but UK sector regulators (FCA, CQC, ICO) have their own AI governance expectations that carry their own enforcement mechanisms regardless of the AI Act’s UK applicability. The practical risk for most UK organisations is not a binary in-scope / out-of-scope question — it is a question of which obligations, from which frameworks, apply to which systems.
Can we make a probabilistic AI system compliant without rebuilding it?
For some requirements, yes. Human oversight mechanisms, logging, monitoring, and instructions for use can be added to a probabilistic system without changing its architecture. For the explainability and reproducibility requirements that high-risk systems must satisfy — the requirement that the system can explain its outputs in a way that reflects the actual decision logic, and that the same input produces the same output — probabilistic LLMs and neural networks cannot satisfy these requirements through governance documentation. Post-hoc explanation techniques (LIME, SHAP, attention visualisation) produce approximations of the model’s reasoning, not the actual reasoning. A regulator or a court examining whether Article 13 is satisfied will be examining whether the explanation reflects the actual decision logic — not whether an explanation was produced. For use cases where this distinction is material, re-architecture is the honest answer.
We have a high-risk AI system that was built before the AI Act. What is our exposure?
From August 2026, the system must comply regardless of when it was built. The Act does not grandfather legacy systems. If the system is already deployed and is classified as high-risk under Annex III, you have until August 2026 to achieve compliance. For systems already deployed before August 2024, there is a transitional period in some cases — but this does not extend beyond August 2026 for most Annex III categories. The practical question is: how long does it take to achieve compliance? For a system that needs governance documentation and human oversight mechanisms but is architecturally capable of satisfying explainability requirements: 3–6 months. For a system that needs re-architecture to satisfy explainability requirements: 9–24 months, depending on system complexity. If your high-risk system needs re-architecture and you have not started, August 2026 may be an unreachable deadline for full compliance. This is the finding you need to know now, not in 2026.
What is the actual fine exposure for a mid-size UK company with one non-compliant high-risk AI system?
Under the EU AI Act: up to 3% of total worldwide annual turnover for non-compliance with high-risk system requirements — whichever is higher between that and €15 million. For a UK company with £50M annual turnover: maximum exposure £1.5M per violation. For a company with £500M turnover: £15M. These are maximum figures — enforcement practice will establish the actual penalty range over time, and first-mover enforcement actions typically target systemic failures rather than technical gaps. However, maximum exposure is not the only risk: regulatory investigation, mandatory system suspension, reputational damage, and litigation from affected individuals all have costs independent of the direct fine. UK sector regulators (FCA, CQC, ICO) carry their own enforcement powers that are not capped by the AI Act’s limits.
Our board wants to accelerate AI deployment. How do we balance speed with compliance?
For non-high-risk AI systems — those not in Annex III and not producing prohibited outputs — the compliance burden is minimal and speed is primarily limited by your own engineering capacity. For high-risk AI systems, the compliance requirements are specific and mandatory from August 2026 regardless of board preference. The honest answer is that a high-risk AI system deployed at speed without the required compliance architecture is not faster — it is faster now and forced to pause for remediation later, at greater cost and under regulatory time pressure. The approach that is actually fastest to sustained, legal operation is: classify correctly before building, design the compliance architecture into the system from the start, and validate before deployment. The alternative — deploy first, comply later — creates a rework programme whose cost and timeline are typically higher than the compliance programme would have been, with the additional complication that the system is live during the rework.
What is the relationship between this service and the other RJV services?
AI systems frequently intersect with other service areas: AI used in cybersecurity monitoring intersects with the Cybersecurity & Resilience service; AI used in business continuity planning or DR decision support intersects with BCP and DR Architecture; AI in cloud environments requires cloud security architecture. Where an AI systems engagement reveals requirements that are best addressed by a different RJV service, we will say so — and we will scope the services to avoid duplication. AI governance does not exist in isolation from the broader technology governance framework, and our engagements are designed to integrate with rather than duplicate the other structural work we do for clients.
What are your payment terms for AI engagements?
All types: 50% on contract signature, 50% on written acceptance of the final deliverables. For Type 3 (Deterministic AI Design), if the initial technical assessment in weeks 1–2 reveals that the system requires re-architecture and you decide not to proceed, the fee for the assessment work completed is invoiced at £8,000 and the engagement closes. This is the only milestone payment structure across all engagement types. Scope additions (systems above ceiling, additional frameworks, re-architecture found necessary) are invoiced as agreed in writing before execution — never retrospectively.
Start with an AI readiness assessment. The earlier it happens, the more options you have.
A 90-minute session in which we review your current AI deployments, classify them against applicable regulatory requirements, and identify where the material gaps are. At the end of the session, you know what you have, what it means under the EU AI Act and applicable sector regulations, and whether the remediation required is documentation-level or architectural. That assessment is what determines which engagement type is appropriate and what the realistic timeline to compliance is.
The time available before August 2026 is shorter than most organisations recognise when they account for the months required for knowledge elicitation, architecture design, implementation, compliance documentation, legal review, and conformity assessment. The organisations that will be demonstrably compliant in August 2026 are those that started in 2025 or earlier, not those that start in spring 2026.
Format
Video call or in-person in London. 90 minutes.
Cost
Free. No commitment.
Lead time
Within 5 business days of contact.
Bring
A list of AI systems your organisation uses or is developing — including vendor tools. Your primary regulatory framework (sector, jurisdiction). Any existing AI governance documentation, model cards, or compliance assessments. If you have received regulatory enquiries about your AI systems, bring those too.
Attendees
Whoever has accountability for AI governance — typically a combination of CTO/IT lead and legal/compliance. From RJV: a senior consultant with AI governance and regulatory expertise. Not a salesperson.
After
Written summary of session findings within 2 business days. Scope and fixed price for the appropriate engagement type within 5 business days if you want to proceed.