What we test against, how, and where it has mattered.
Every S.AI.F engagement is mapped to five regulatory frameworks, run through nine test suites, and conducted with named assessment methods and open, inspectable tooling. Three further ISO standards set the risk process beneath that work, the governing body’s own duties, and the rules a certification body must answer to. This page is the canonical description of each — the same text our signers, your auditors and your regulator read.
The reference regime. Risk-tiered obligations on providers and deployers of AI systems placed on the EU market, with high-risk systems (Annex III) carrying the full conformity burden. We map every finding to an Article so the evidence pack reads as a conformity file.
ArticleObligationWhat it requiresHow we evidence it
Art. 15Accuracy, robustness, cybersecurityDeclared metrics, resilience to attackEvaluation · robustness · red team
Art. 72Post-market monitoringActive, systematic collectionSurveillance programme · drift suite
Art. 86Right to explanationIndividual decision explanationCounterfactual analysis (DiCE)
Timeline: prohibited practices from Feb 2025; GPAI obligations Aug 2025; high-risk Annex III obligations Aug 2026; Annex I (product-embedded) Aug 2027.
FrameworkStandard · certifiable
ISO/IEC 42001:2023
AI management system (AIMS)
The management-system standard for AI — the 27001 of AI governance. It certifies the organisation, not the model: policy, roles, risk treatment, controls and continual improvement. Our Head of Assurance holds Lead Auditor status; the audit gate follows its clause structure.
The standard that governs the certifier, not the client. It supplements ISO/IEC 17021-1 with AI-specific requirements on impartiality, auditor competence and audit duration, and it is the reason a credible 42001 certificate cannot come from the same firm that built your management system.
ClauseRequirementWhat it requiresWhat it means in practice
Cl. 5.2ImpartialityNo consultancy on AI, information-security, data-protection or risk-management systems for certification clientsS.AI.F Advisory and S.AI.F Certification are separate entities behind an impartiality firewall
Cl. 6StructureGovernance that safeguards impartiality, with interested-party participationImpartiality committee with external members
Cl. 7 · Annex ACompetenceDefined AI competence for auditors, technical experts and decision-makersNamed competence per scope, evidenced to the accreditation body
Cl. 9.1.4Audit timeMinimum audit duration set by organisation size and AI risk profileAudit days follow the standard, not the lowest quote
Cl. 9.6Certification decisionTaken by persons who did not conduct the auditAn auditor never certifies their own audit
Cl. 10Management systemThe body operates its own documented management systemInternal audit and management review of the certification body itself
Read with ISO/IEC 17021-1 (conformity assessment for management-system certification). This is the standard S.AI.F Certification is being built to meet; accreditation by an IAF-member body is what makes the certificate recognised across borders.
FrameworkStandard · governance
ISO/IEC 38507:2022
Governance implications of the use of AI
Written for the board, not the build team. It extends the ISO/IEC 38500 evaluate–direct–monitor model to AI, and treats the decision to use AI as a governance decision with consequences the governing body cannot delegate. Where 42001 is the management system, 38507 is what the board is answerable for.
Governance taskDutyWhat it requiresHow we evidence it
EvaluateWhether to use AI at allAdoption is a governance decision, assessed against objectives and obligationsIntended-purpose statement · board-level scoping record
DirectPolicyAn AI policy setting acceptable use, constraints and escalationPolicy Builder output · AI policy review
MonitorOversightContinuing visibility of AI behaviour and outcomes against that policySurveillance programme · drift suite · Day 180 review
AccountabilityDecisions stay ownedAccountability for an outcome cannot be transferred to a systemNamed owner per system · override and escalation design
Data governanceProvenance and permitted useThe organisation knows where its data came from and what it may be used forData validation · lineage · permitted-use review
RiskRisk in business termsAI risk expressed as business and societal risk, not model metricsFindings register mapped to business impact
Culture & valuesBehaviour actually rewardedStated values are reflected in how AI is used day to dayGovernance interviews · accepted-risk sign-offs
ComplianceLegal and regulatory dutyThe governing body remains responsible for compliance, however the system was procuredCross-framework map · obligations register
Guidance, not certifiable — there is no 38507 certificate. It sits above ISO/IEC 42001: 38507 tells the governing body what to decide, 42001 is the system that carries those decisions out.
FrameworkStandard · guidance
ISO 31000:2018
Risk management — guidelines
The generic risk-management grammar every AI framework inherits. ISO/IEC 23894 is 31000 applied to AI, and ISO/IEC 42001 clause 6.1 and Annex A.5 assume a process of exactly this shape. We use it so an AI finding lands in the same risk register as everything else the business manages.
ClauseElementWhat it requiresHow we apply it
Cl. 4PrinciplesIntegrated, structured, customised, inclusive, dynamic, best available information, human and cultural factors, improvementAssessment design · stakeholder scoping
Cl. 5.2–5.3Leadership & integrationOwned by leadership and built into governance, not run alongside itGovernance review · accountability mapping
Cl. 6.3Scope, context & criteriaDefine scope, internal and external context, and explicit risk criteriaScoping proposal · risk criteria sign-off
Cl. 6.4.2Risk identificationFind, recognise and describe risks, their sources and consequencesThreat modelling · red team · failure-mode workshop
Cl. 6.4.3Risk analysisUnderstand likelihood, consequence and the uncertainty in bothEvaluation suites · quantified findings
Cl. 6.4.4Risk evaluationCompare the analysis against the criteria to decide what needs treatingFindings register · gate structure
Cl. 6.5Risk treatmentSelect and implement options; accept residual risk explicitlyRemediation plan · accepted-risk sign-offs
Cl. 6.6Monitoring & reviewMonitor the risks, the controls and the framework itselfSurveillance programme · drift suite
Cl. 6.7Recording & reportingDocument the process and report it at the right levelAssessment report · Trust Proof
Guidance, not certifiable. Cited alongside ISO/IEC 23894 (AI risk management) wherever a client needs the AI risk process to reconcile with an enterprise risk framework already in place.
FrameworkFramework · voluntary
NIST AI RMF 1.0
AI Risk Management Framework · with Generative AI Profile (600-1)
Four functions — Govern, Map, Measure, Manage — and seven trustworthiness characteristics. Not certifiable, but the common vocabulary for US-facing counterparties and the structure most boards already recognise. We use its MEASURE function as the spine of the evaluation report.
Function / characteristicThemeRequirementHow we evidence it
For LLM systems we additionally score against the 12 GenAI risks in NIST AI 600-1 (confabulation, data privacy, harmful bias, information integrity, etc.).
FrameworkSupervisory · sector
CBUAE model risk
Central Bank of the UAE · Model Management Standards & Guidance
Applies to every model a licensed UAE bank uses for decisions with financial or customer impact. Three lines of defence, independent validation, materiality tiering and a model inventory. Our validation pod acts as — or supplements — the second line; findings are worded for the Model Risk Committee.
AreaLineRequirementHow we evidence it
Model inventoryGovernanceEvery model registered with owner and tierWorkspace · model hash in Trust Proof
Data qualityDevelopmentRepresentativeness, completeness, lineageData validation · representation gap
Performance monitoringOngoingBack-testing, stability, override trackingDrift suite · surveillance programme
Fair treatmentConductConsumer protection standards (2020)Fairness suite · equal opportunity by group
DocumentationGovernanceDevelopment, validation and use docsAssessment report · working papers
Model changeGovernanceRe-validation on material changeHash change voids certificate
Read alongside the CBUAE Consumer Protection Regulation and Standards and the 2023 guidance on AI/ML in financial services.
FrameworkPrinciples · national
UAE AI Ethics Principles & Guidelines
Minister of State for AI · UAE Charter for the Development and Use of AI (2024)
The national ethical baseline: fairness, accountability, transparency, explainability, robustness, human oversight, privacy, sustainability and beneficial use. Principles rather than controls — so we operationalise each one as a measurable check and report against it in plain language for public-sector boards.
PrincipleTypeMeaningHow we evidence it
Fairness & inclusivenessPrincipleNo discrimination on protected groundsFairness suite · representation gap
AccountabilityPrincipleClear human responsibilityNamed owners · accountable executive sign-off
Transparency & explainabilityPrincipleUnderstandable decisions, disclosure of AI useExplainability · Art. 50-style disclosure review
Robustness & safetyPrincipleReliable under stress, fails safelyRobustness · red team
Human oversightPrincipleMeaningful control and overrideOversight design review
PrivacyPrinciplePDPL alignment, data minimisationPII scan · consent basis check
SustainabilityPrincipleProportionate computeCompute attestation · load suite
Beneficial usePrincipleIntended purpose serves the publicIntended-purpose statement
Where a sector regulator exists (CBUAE, DoH Abu Dhabi, TDRA) its rules take precedence; the Charter fills the gaps.
Cross-framework map
One control set, five frameworks
We do not run five audits. Each control theme is tested once and evidenced once; this table is how a single result is cited under every regime a client answers to.
Control themeEU AI ActISO/IEC 42001NIST AI RMFCBUAEUAE Ethics
EU AI Act Art. 10(2)(f) · ISO/IEC 24027 · NIST MEASURE 2.11 · CBUAE fair treatment
Pass condition. All declared groups within threshold, or an accepted-risk sign-off from the risk committee on file.
02Test suiteevery engagement
Drift & population stability
Whether the population the model sees in production still resembles the one it was trained and validated on — and whether performance is decaying.
How we run it
Baseline distributions captured from the sealed training and test sets.
Feature, prediction and label drift measured against a production sample.
Re-run at Day 90 and Day 180 as part of surveillance.
Metrics
Population Stability Index (PSI)KL divergenceJensen–Shannon distancePrediction driftPerformance decay
Tooling
EvidentlywhylogsNannyML
Framework mapping
EU AI Act Art. 72 · ISO/IEC 42001 Cl. 9 · NIST MANAGE 4 · CBUAE ongoing monitoring
Pass condition. PSI below 0.10 on all declared features; no material performance decay against the baseline.
03Test suitehigh-risk systems
Algorithmic red teaming
Whether the model and the stack around it withstand deliberate manipulation — prompt injection, jailbreaks, data extraction, poisoning, tool and agent abuse.
How we run it
Automated probe suites run first, across the full OWASP LLM Top 10.
Human red team then works the highest-value paths for two weeks.
Findings mapped to MITRE ATLAS techniques; fixes verified by re-test.
Metrics
Attack success rate by categoryTime to first breachData exfiltration surfaceSeverity distribution
EU AI Act Art. 15(5) · ISO/IEC 42001 A.6.2 · NIST MEASURE 2.7 · OWASP LLM · MITRE ATLAS
Pass condition. No open critical or high finding; all medium findings owned with dates.
04Test suiteevery engagement
Explainability & transparency
How the model reached a specific decision — the actual decision path, not a plausible story about it — and whether that path rests on legitimate features.
How we run it
Global attribution: which features drive predictions across the population.
Local attribution: why this applicant, this patient, this filing.
Counterfactuals: the smallest change that flips the outcome, and whether it is actionable and lawful.
EU AI Act Art. 50 · Art. 53 (GPAI) · NIST AI 600-1 confabulation
Pass condition. Faithfulness ≥ 0.95 on the frozen set; zero unsupported claims in regulated-advice categories.
06Test suiteevery engagement
Robustness to perturbation
Whether small, realistic changes to inputs — paraphrase, typos, dialect, noise, missing fields — change the output in ways they should not.
How we run it
Perturbation recipes chosen for the domain (text, tabular, imaging).
Output stability measured against the unperturbed baseline.
Failure modes catalogued and fed to the red team.
Metrics
Prediction flip ratePerformance under perturbationWorst-case subgroup degradation
Tooling
TextAttackAdversarial Robustness ToolboxGiskard
Framework mapping
EU AI Act Art. 15 · ISO/IEC 24029 · NIST MEASURE 2.5
Pass condition. Flip rate below declared threshold; no subgroup degrades more than 2 points beyond the population.
07Test suitescoring & risk models
Calibration
Whether a model that says “70% likely” is right about 70% of the time — overall and for each group — so downstream thresholds mean what people think they mean.
How we run it
Reliability diagrams by decile and by protected group.
Recalibration recommended where miscalibration is systematic.
EU AI Act Art. 15 · NIST valid & reliable · CBUAE outcomes analysis
Pass condition. ECE ≤ 0.03 overall; no group deviates by more than 0.02.
08Test suiteproduction systems
Latency, cost & load
Whether the deployed system meets its service targets under realistic and peak load, and what it costs to do so.
How we run it
Load profile agreed from production telemetry.
p50/p95/p99 latency, error rate and cost per thousand requests measured inside the attested enclave.
Metrics
p95 latencyThroughputError rate under loadCost per 1k inferences
Tooling
MLPerfk6OpenTelemetry GenAI
Framework mapping
ISO/IEC 42001 A.6.2 · UAE Ethics sustainability
Pass condition. Declared SLOs met at peak load with headroom.
09Test suiteevery engagement · Gate 3
Data validation & lineage
Whether the data is complete, clean, lawfully sourced and representative of the people the system serves — before any model result is trusted.
How we run it
Expectation suites run as pipeline gates: schema, completeness, duplication.
Train/test leakage and poisoning scans.
Label quality estimated; suspected noise sampled.
Provenance, consent basis and PII handling recorded per source.
Representation compared to the served population; gaps above 5 points flagged.
Metrics
Expectation pass rateLeakage overlapLabel noise estimateRepresentation gap by groupPII fields masked
Tooling
Great ExpectationsSodaDeequCleanlabPresidioDVC · OpenLineage
Framework mapping
EU AI Act Art. 10 · ISO/IEC 42001 A.7 · ISO/IEC 5259 · CBUAE data quality
Pass condition. All six data gates pass; any accepted data risk signed by the data owner.
Assessment methodAdversarial · offensive
Red teaming
When · Day 30–40 · high-risk systems
A structured, authorised attempt to make an AI system fail — by people whose job is to think like an attacker, a fraudster, or a careless user. Unlike a checklist, a red team follows whatever works, then documents the path.
How we run it
Scope and rules of engagement agreed in writing at Gate 1; production data and live customers are out of bounds.
Automated probes first (garak, PyRIT) for breadth, then a two-week human campaign for depth.
Every successful attack is reproduced, mapped to MITRE ATLAS / OWASP LLM, and handed to the model team as a finding with a re-test.
How it differs. Red teaming asks “can it be broken?”. Robustness testing asks “does it degrade gracefully?”. Both run; only red teaming is adversarial and human-led.
Assessment methodScenario · strategic
War gaming
When · Day −14 (scoping) · Day 53–55 (accepted risk)
A facilitated, multi-team simulation of an adverse scenario played out over time — a model drifts silently for six months, a regulator opens an inquiry, a vendor is breached — where the client’s executives, engineers and legal team take decisions in turn and see the consequences.
How we run it
Two or three scenarios drawn from the risk classification; each runs half a day with a control cell injecting events.
Decisions, delays and disagreements are logged; the readout is what the organisation would actually have done, not what its policy says.
Gaps become controls in the engagement letter or accepted risks signed by the board.
How it differs. A red team attacks the system. A war game stresses the organisation around it — governance, escalation, communication. The finding is usually a missing decision right, not a missing patch.
Assessment methodScenario · operational
Tabletop exercise
When · Day 61+ · surveillance onboarding
A shorter, discussion-based walk-through of a single incident — “the fairness alert fired at 02:00, what happens next?” — used to rehearse runbooks with the people who will hold the pager.
How we run it
Ninety minutes, one incident, the actual on-call roster.
Each runbook step is read aloud and challenged: who, with what access, in how long.
Output is a corrected runbook and a list of access or tooling gaps.
How it differs. Tabletops rehearse a known procedure. War games discover the procedures that do not exist yet.
Assessment methodAnalytical · design-time
Threat modelling
When · Day 0–7 · scope
A systematic enumeration of what can go wrong: assets (weights, training data, prompts, decisions), adversaries (external attacker, insider, careless integrator, the model itself), attack surfaces, and the controls that stand between them.
How we run it
STRIDE for the surrounding system; MITRE ATLAS for AI-specific techniques; NIST AI 600-1 for generative risks.
Data-flow diagram of the full pipeline, from training data to the decision a customer sees.
The model drives the red-team plan and the security gate’s pass criteria.
How it differs. Threat modelling is done on paper before any test runs. It decides where the red team spends its time.
Assessment methodCollaborative · detection
Purple teaming
When · Day 30–40 · AI Factory SOC engagements
Red team and the client’s defenders (blue team) working side by side: each attack is run in the open, and the question is not only “did it succeed?” but “did anyone notice?”.
How we run it
Attack, then immediately check logs, alerts and dashboards for the trace.
Detection gaps are fixed on the spot where possible and re-tested the same day.
Produces a detection coverage map alongside the vulnerability list.
How it differs. Red teaming measures exposure. Purple teaming measures visibility — how long an attacker would go unnoticed.
Assessment methodEvidential · independence
Blind evaluation
When · Day 22–42 · every engagement
Testing against a sealed evaluation set the model team has never seen and cannot tune to — held by a neutral escrow agent, hashed and timestamped on Day 18.
How we run it
The set is drawn and frozen by our validation architect; the client may observe the sealing but not the contents.
The same set is used for the re-test after remediation and for re-certification, so results are comparable across years.
Any leakage between the set and training data is itself a finding.
How it differs. This is what separates a validation from a benchmark. A score on a public benchmark says what a model can do when it has seen the exam.
Assessment methodStatistical · data
Adversarial validation
When · Day 15–21 · data gates
A technique for detecting whether training and evaluation data come from the same distribution: train a classifier to tell them apart. If it can, the sets differ in ways that will make the evaluation misleading.
How we run it
Classifier AUC near 0.5 means indistinguishable; above 0.7 triggers investigation of which features separate them.
Also used to compare training data to a production sample for representation gaps.
How it differs. Cheap, fast and surprisingly revealing — it often finds the time-period or channel skew that no summary statistic shows.
Assessment methodOperational · pre-release
Shadow deployment
When · Day 43–56 · where infrastructure allows
Running the candidate model on live traffic in parallel with the incumbent, recording its decisions but never acting on them — so behaviour is observed on real inputs without exposing a single customer.
How we run it
Decisions logged with the same schema as production for direct comparison.
Drift, fairness and calibration metrics computed on the shadow stream.
Disagreement analysis: where the two models diverge, a human reviews the cases.
How it differs. Shadow mode is how a remediated model earns the right to be re-evaluated on real data, not just on the sealed set.
Assessment methodComparative · governance
Champion–challenger
When · Remediation · re-certification
The incumbent (champion) and a candidate (challenger) are evaluated on identical data with identical metrics; the challenger only replaces the champion if it is better on the declared criteria — including fairness, not only accuracy.
How we run it
Criteria and their weights fixed before the comparison.
Uplift reported with confidence intervals; a challenger that wins on accuracy and loses on fairness does not win.
Standard practice in CBUAE model risk; we apply it to every remediation.
How it differs. Prevents the common failure where a “better” model is promoted because it improved the one metric someone was looking at.
Assessment methodExperimental · live
A/B & interleaved testing
When · Day 61+ · with client consent and ethics review
Controlled exposure of a fraction of live traffic to the candidate model, with outcomes measured against the control group. Interleaving (for ranking and retrieval) mixes both models’ outputs in one response so the same user judges both.
How we run it
Only after shadow deployment and only for decisions where exposure is ethically acceptable — never for credit, clinical or benefit decisions without regulatory clearance.
Pre-registered hypothesis, sample size and stopping rule.
Fairness metrics monitored per arm; the test halts if any group is disadvantaged.
How it differs. The most informative and the most constrained method. Most high-risk systems never qualify for it, and that is by design.
Assessment methodAssurance · documentary
Algorithmic audit
When · Day 57 · every engagement
An independent, evidence-based review of a system against a declared set of criteria — the frameworks in scope — producing an opinion that a third party can rely on. Every claim in the report is traced to a hashed artefact, a test run or a signature.
How we run it
Working papers follow ISO/IEC 42001 clause structure and ISAE 3000 evidence standards.
Conducted by assurance staff who did not run the tests; signed by a practice lead who was not on the pod.
The opinion may be qualified or refused.
How it differs. Testing produces results. Audit produces an opinion about whether the results — and the process that produced them — can be trusted.
Assessment methodEthical · societal
Impact assessment
When · Day 2 · intended purpose · Day 53–55 accepted risk
A structured analysis of who is affected by the system and how — individuals, groups, society — covering benefits, harms, their likelihood and severity, and the safeguards that reduce them. Required as an AI Impact Assessment under ISO/IEC 42001 A.5 and a Fundamental Rights Impact Assessment under EU AI Act Art. 27 for certain deployers.
How we run it
Stakeholder mapping with the client’s ethics or fairness committee.
Protected groups and thresholds for the fairness suite are drawn from this document.
Residual harms become accepted risks signed by the accountable executive and cited in the certificate.
How it differs. The impact assessment decides what “fair” means for this system. The fairness suite then measures it.
Assessment methodQualitative · judgement
Human evaluation panels
When · LLM & RAG systems · Day 22–42
Trained raters — domain experts, native speakers, affected-community members — scoring outputs against a rubric where automated metrics are insufficient: tone, cultural appropriateness, harm, usefulness of an explanation.
How we run it
Rubric agreed at scoping; raters calibrated on a shared sample; inter-rater agreement reported.
Stratified samples from the sealed set, blind to model identity.
Arabic and dialect coverage by native speakers, not translation.
How it differs. Automated metrics scale; human panels see what the metrics were not designed to see. We report both and say which is which.
Assessment methodMathematical · guarantees
Formal verification
When · Safety-critical components · on request
Proving, rather than testing, that a component satisfies a property for all inputs in a defined region — e.g. a decision boundary cannot move more than ε under bounded perturbation, or a rule-based guardrail can never emit a forbidden class of output.
How we run it
Applicable to small networks, monotonic constraints, and deterministic policy layers around a model.
Tools: abstract interpretation and SMT-based verifiers; proofs attached to the run manifest.
How it differs. Where it applies, it replaces sampling with certainty. It rarely applies to a whole model — so we say precisely which component it covers.
MethodExplainabilityFairness
SHAP
Explainability · Shapley additive explanations
What it is
Assigns each feature a contribution to an individual prediction using Shapley values from cooperative game theory — the only attribution method that is locally accurate, consistent and missingness-aware. Aggregated across a population it gives global feature importance.
Why we use it
Regulators ask two questions: “what drives this model?” and “why this decision?” SHAP answers both from the same computation, and lets us check that no protected attribute or proxy sits among the top drivers.
Inside an engagement
TreeSHAP for gradient-boosted and forest models (exact, fast).
KernelSHAP / DeepSHAP for black-box and neural models.
Dependence and interaction plots to surface proxies (postcode → nationality).
Attribution stability under perturbation as a robustness check.
Output. Global importance chart, per-decision waterfall for sampled cases, proxy analysis — all in the assessment report and the Trust Proof’s EXPLAINABILITY line.
MethodExplainabilityFairnessRight to explanation
DiCE
Explainability · Diverse Counterfactual Explanations
What it is
Generates a set of diverse counterfactuals — the smallest, most different changes to an input that would flip the model’s decision — subject to feasibility constraints (age cannot decrease; nationality is immutable).
Why we use it
A declined applicant is owed an actionable reason. Counterfactuals turn “the model said no” into “had income been 8% higher, the outcome changes” — and reveal when the only path to approval runs through a protected attribute.
Inside an engagement
Immutable and monotonic features declared at scoping.
Diversity and proximity weighted so explanations are both varied and realistic.
Counterfactual fairness: do groups need different-sized changes for the same outcome?
Output. Counterfactual sets for sampled decisions; a counterfactual-fairness statistic by group; a template for customer-facing explanations.
MethodFairnessRemediation
Fairlearn
Fairness · assessment and mitigation
What it is
Open-source toolkit for group fairness metrics and mitigation algorithms. We use it to compute the declared metrics and, during remediation, to advise on post-processing mitigations the client team applies.
Why we use it
One library, one definition of each metric, across every engagement — so a −0.019 for one client means the same as for another.
Inside an engagement
MetricFrame for side-by-side group metrics with confidence intervals.
ThresholdOptimizer (post-processing) and ExponentiatedGradient (in-processing) as remediation options.
Intersectional groups where sample size allows.
Output. Fairness dashboard per group; before/after comparison in the re-evaluation.
MethodRed teaming
garak · PyRIT
Security · automated LLM probing
What it is
Two complementary probe frameworks: garak (NVIDIA) runs a catalogue of known attack probes against an LLM endpoint; PyRIT (Microsoft) orchestrates multi-turn, adaptive attacks with scoring.
Why we use it
Automated probes cover breadth cheaply and reproducibly, so the human red team spends its two weeks on depth.
Inside an engagement
Full OWASP LLM Top 10 coverage on every run.
Custom probes for Arabic-language jailbreaks and regional context.
Every probe, response and score hashed into the run manifest.
Output. Attack success rate by category; mapped to MITRE ATLAS; seeds the red-team plan.
MethodData validation
Great Expectations
Data quality · expectation suites
What it is
Declarative data tests (“expectations”) run against every dataset as a gate: column presence and type, null rates, value ranges, uniqueness, referential integrity.
Why we use it
Most model failures are data failures. A 212-expectation suite that passes is a stronger statement than any accuracy number.
Inside an engagement
Suites derived from the model card and data dictionary, then extended.
Run on the sealed dataset; results form part of Gate 3.
Complemented by Cleanlab (label noise) and Presidio (PII).
Output. Expectation pass report in the working papers; Gate 3 sign-off.
MethodDriftCalibrationSurveillance
Evidently
Monitoring · drift and performance
What it is
Open-source monitoring library producing drift, data-quality and performance reports from reference and current datasets.
Why we use it
The same report at Day 42, Day 90, Day 180 and Day 365 makes decay visible — and defensible.
Inside an engagement
PSI and JS distance per feature; prediction drift; performance by segment.
Thresholds from the Day 4 declaration.
Feeds the AI Factory SOC as a scheduled job.
Output. Drift report per surveillance check; transparency-log entry.
MethodGroundingHallucination
Ragas
LLM evaluation · retrieval-augmented generation
What it is
Reference-based and reference-free metrics for RAG pipelines — faithfulness, answer relevance, context precision and recall — scored by an evaluator model we run inside the enclave.
Why we use it
For a customer-facing assistant the question is not “is it fluent?” but “did it make that up?”. Ragas quantifies the second.
Inside an engagement
Frozen question set with gold references in escrow.
Evaluator model version pinned and hashed.
Human spot-check on a stratified sample.
Output. Faithfulness and grounding scores per category; unsupported-claim register.
MethodEvery certificate
Attestation & signing
Integrity · confidential compute and post-quantum signatures
What it is
The evidence that the test ran on the model it claims to have tested, in a place no one could tamper with — and a signature that will still verify in ten years.
Why we use it
Without this, an evaluation report is a claim. With it, it is a proof.
Inside an engagement
Model, data and evaluation set hashed (SHA-256) into a run manifest.
Tests execute in Intel TDX / AMD SEV-SNP enclaves; the attestation quote is bound into the certificate.
Certificate signed ML-DSA-65 with an HSM-backed key; timestamped; published to a transparency log.
Supply-chain: Sigstore, in-toto/SLSA provenance, ModelScan for unsafe serialisation.
Output. The Trust Proof — publicly verifiable without contacting S.AI.F.
Use caseBanking
Retail credit scoring
National Bank · credit-scoring-v5 · high-risk · Annex III
A new retail credit-scoring model was about to go live. The bank needed conformity evidence for the CBUAE and a fairness result the board could stand behind.
Frameworks applied
EU AI ActCBUAE model riskISO/IEC 42001
Suites run
Data validationBias & fairnessExplainabilityCalibrationDriftRed teaming
Finding. Applicants over 60 approved at a materially lower rate — equal opportunity difference −0.080 against ±0.05. Root cause: 2019–2021 training rows under-represented older applicants.
Method that surfaced it
Fairlearn surfaced the gap; SHAP showed “account tenure” acting as an age proxy; DiCE counterfactuals confirmed older applicants needed larger income changes for the same outcome.
Result. Reweighting, 61k additional rows and threshold tuning brought EOD to −0.019 with accuracy held at 95.4. Certified Day 60; Trust Proof TP-0413.
A model chose which subscribers received retention discounts. The regulator’s consumer-protection code requires offers not to discriminate; the operator wanted proof before scaling.
Frameworks applied
UAE AI EthicsEU AI ActTDRA consumer code
Suites run
Data validationBias & fairnessExplainabilityDrift
Finding. Subscribers over 60 offered discounts far less often — EOD −0.074. Past campaigns had targeted high-data segments, so older subscribers barely appeared among positive labels.
Method that surfaced it
Representation analysis flagged the 3% vs 9% gap at Gate 3; Fairlearn quantified it; SHAP showed data-usage features dominating.
Result. 140k offer outcomes collected, model reweighted by age band; EOD −0.017, churn recall held at 91.2. Trust Proof TP-0417.
Use caseHealthcare
Readmission risk
Gulf Hospital · readmission-risk-v2 · clinical decision support
A readmission-risk score guided post-discharge follow-up. Clinical leadership needed assurance the score did not disadvantage any patient group before it influenced care pathways.
Frameworks applied
DoH Abu Dhabi AI policyEU AI Act Annex IIIISO/IEC 42001
Suites run
Data validationBias & fairnessCalibrationExplainabilityRobustness
Finding. Non-Arabic-speaking patients scored as lower risk than their outcomes warranted — EOD −0.083. Translated clinical notes carried less follow-up detail than Arabic originals.
Method that surfaced it
Calibration by language group exposed the systematic under-scoring; SHAP traced it to free-text note features; robustness probes confirmed sensitivity to note length.
Result. Structured extraction replaced free-text signal; 18k additional episodes; EOD −0.021, AUROC held at 0.87. Trust Proof TP-0421.
Use caseGovernment
Permit triage
Gulf Identity Authority · permit-triage-v4 · public services
A triage model routed licence applications to straight-through processing or manual review. The Authority needed evidence the routing was not systematically slower for any class of applicant.
Frameworks applied
UAE AI EthicsEU AI ActISO/IEC 42001
Suites run
Data validationBias & fairnessExplainabilityRed teamingLatency & load
Finding. Small businesses routed to manual review far more often — EOD −0.091. Historic incomplete-document flags clustered in SME filings; the model learned entity size as a risk proxy.
Method that surfaced it
SHAP dependence plots showed headcount and capital bands as top drivers; DiCE counterfactuals showed SMEs needed implausible changes to reach straight-through.
Result. Proxy features removed; 92k SME outcomes added; EOD −0.022, straight-through rate held at 78%. Trust Proof TP-0425.
Use caseCross-sector
Customer-facing RAG
Illustrative · customer-facing assistant · RAG over policy documents
A generative assistant answered customer questions from a policy corpus. The risk was not bias but fabrication — confident answers with no basis in the documents.
Frameworks applied
EU AI Act Art. 50 · 53NIST AI 600-1OWASP LLM Top 10
Finding. Faithfulness 0.91 on the frozen set with unsupported claims concentrated in edge-case fee questions; prompt injection via uploaded documents succeeded in 4 of 40 probes.
Method that surfaced it
Ragas scored faithfulness per category; garak and PyRIT ran the injection probes; the human red team chained document upload to data exfiltration.
Result. Retrieval reranking and refusal policy raised faithfulness to 0.97; injection surface closed and verified by re-test.
Annex
Abbreviations, in full
Every acronym used across the deck, the build plan, the console and this reference — expanded, then explained in the sense we use it. 130 entries in nine groups.
Jump
Abbreviations17 entries
Regulators & regimes
Supervisory bodies and legal regimes that appear in scoping, control mapping and the engagement contract.
ADGMAbu Dhabi Global Market
Financial free zone in Abu Dhabi with its own civil and commercial law; home of the FSRA and the RegLab sandbox.
CBBCentral Bank of Bahrain
Bahraini banking supervisor; model-risk and outsourcing rules relevant to GCC expansion.
CBUAECentral Bank of the United Arab Emirates
Prudential regulator for UAE banks; issues model-management and outsourcing expectations that drive most of our banking evidence.
DFSADubai Financial Services Authority
Regulator of the DIFC free zone; operates the Innovation Testing Licence.
DIFCDubai International Financial Centre
Dubai financial free zone with its own data-protection law and courts.
DoHDepartment of Health – Abu Dhabi
Health-sector regulator for Abu Dhabi; approves clinical AI deployments.
EUEuropean Union
Jurisdiction whose AI Act sets the reference regime for high-risk AI obligations.
FSRAFinancial Services Regulatory Authority
ADGM's financial regulator; runs the RegLab regulatory sandbox.
ITLInnovation Testing Licence
DFSA's restricted licence allowing firms to test a financial service in DIFC under supervision.
MoHAPMinistry of Health and Prevention (UAE)
Federal health regulator outside Abu Dhabi and Dubai.
PDPLPersonal Data Protection Law (UAE Federal Decree-Law 45/2021)
UAE data-protection statute; governs lawful basis, cross-border transfer and data-subject rights for any client data we process.
QCBQatar Central Bank
Qatari banking supervisor; GCC expansion target.
RegLabRegulatory Laboratory (ADGM)
Time-bound sandbox licence letting a firm test an innovative proposition with real customers under tailored rules.
SAMASaudi Central Bank
Saudi banking supervisor; its model-risk framework is the main mapping addition for KSA work.
SCASecurities and Commodities Authority (UAE)
Capital-markets regulator; relevant where a client's AI touches trading or investment advice.
SDAIASaudi Data and Artificial Intelligence Authority
Owner of Saudi AI ethics principles and national AI policy.
TDRATelecommunications and Digital Government Regulatory Authority (UAE)
Telecom and digital-government regulator; sector authority for telco AI.
Abbreviations19 entries
Standards & frameworks
The published standards, frameworks and benchmarks our control library maps obligations onto.
AI 600-1NIST Generative AI Profile
Companion profile to the AI RMF covering risks specific to generative systems.
AI RMFAI Risk Management Framework (NIST AI 100-1)
Voluntary US framework structured as Govern, Map, Measure, Manage; our control language borrows its verbs.
AIMSAI Management System
The management system ISO/IEC 42001 certifies — policies, roles, risk process and continual improvement for AI.
CEN-CENELEC JTC 21Joint Technical Committee 21 on Artificial Intelligence
European body drafting the harmonised standards that will give presumption of conformity under the EU AI Act.
EU AI ActRegulation (EU) 2024/1689
Risk-tiered EU regulation on AI; Annex III lists the high-risk use cases carrying the full conformity burden.
IECInternational Electrotechnical Commission
Standards body that co-publishes the ISO/IEC AI series.
ISOInternational Organization for Standardization
Publisher of the management-system standards we certify against.
ISO/IEC 17020Requirements for the operation of inspection bodies
Accreditation standard for bodies performing inspections — one route to accredited AI inspection.
ISO/IEC 17025Requirements for the competence of testing and calibration laboratories
Accreditation standard for testing laboratories; the credential that makes our test results formally recognised.
ISO/IEC 23894AI risk management guidance
Guidance companion to 42001 on identifying and treating AI risk.
ISO/IEC 27001Information security management systems
The security management-system standard S.AI.F itself certifies against.
ISO/IEC 27701Privacy information management extension
Privacy extension to 27001 for organisations processing personal data.
ISO/IEC 42001AI management systems
First certifiable AI management-system standard; the backbone of our governance mapping.
ISO/IEC 42005AI system impact assessment
Guidance on assessing impacts of an AI system on people and society.
ISO/IEC 24029Assessment of the robustness of neural networks
Methods for evaluating neural-network robustness.
ISO 22301Business continuity management systems
Continuity standard often already held by banking clients.
NISTNational Institute of Standards and Technology (US)
Publisher of the AI RMF and the FIPS cryptographic standards.
PCI DSSPayment Card Industry Data Security Standard
Card-data security standard most banking clients already hold.
SOC 2System and Organization Controls 2
AICPA attestation on security, availability, confidentiality and privacy controls; Type II covers an observation window rather than a point in time.
Abbreviations9 entries
Security & threat
Vocabulary of the offensive and defensive work — red teaming, threat modelling and the taxonomies that give it coverage.
AMLAnti-Money Laundering
Controls against illicit funds; a common domain for the fraud models we validate.
ATLASAdversarial Threat Landscape for Artificial-Intelligence Systems (MITRE)
Tactic-and-technique taxonomy for attacks on ML systems; our red-team coverage map is indexed to it.
CVECommon Vulnerabilities and Exposures
Public identifier scheme for known software vulnerabilities.
DPIAData Protection Impact Assessment
Formal assessment of privacy risk required before high-risk processing.
KYCKnow Your Customer
Identity-verification obligation; the domain of the document-extraction models we assess.
OWASPOpen Worldwide Application Security Project
Community behind the Top 10 for LLM Applications and the AI Exchange.
PIIPersonally Identifiable Information
Data that identifies a person; must be masked before it enters a test environment.
SLAService Level Agreement
Contracted response time — here, the clock on remediating a finding by severity.
STRIDESpoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege
Threat-modelling mnemonic used for the platform's own architecture review.
Abbreviations13 entries
Testing & metrics
The measures that appear in suite results, scorecards and findings.
AUCArea Under the Curve
Summary of ranking quality; usually paired with ROC.
ECEExpected Calibration Error
Average gap between predicted confidence and observed frequency — the core calibration metric.
EODEqual Opportunity Difference
Gap in true-positive rate between groups; a fairness measure for approval-style decisions.
FPRFalse Positive Rate
Share of negatives wrongly flagged; watched per group in fairness testing.
KSKolmogorov–Smirnov statistic
Distribution-distance measure used for drift detection.
LLMLarge Language Model
Generative text model; brings grounding, injection and jailbreak risks classical ML does not.
MLMachine Learning
Umbrella term for the statistical systems under assessment.
PSIPopulation Stability Index
Standard banking drift measure comparing scored distributions over time.
RAGRetrieval-Augmented Generation
Pattern where a model answers from retrieved documents; grounding tests measure whether it actually does.
ROCReceiver Operating Characteristic
Curve of true- against false-positive rate across thresholds.
SPDStatistical Parity Difference
Gap in positive-outcome rate between groups.
TPRTrue Positive Rate
Share of positives correctly identified; also called recall or sensitivity.
XAIExplainable AI
Techniques that make an individual decision inspectable — SHAP, counterfactuals, surrogate models.
Abbreviations16 entries
Tooling & libraries
Open-source components the platform orchestrates. We harden and sign their output; we do not reimplement their metrics.
AIF360AI Fairness 360
IBM/Linux Foundation library of fairness metrics and mitigation algorithms.
AILuminateMLCommons AILuminate benchmark
Standardised safety benchmark for large language models.
ARTAdversarial Robustness Toolbox
Library of evasion, poisoning and extraction attacks for classical ML.
DeepEvalDeepEval
Open-source LLM evaluation harness for task-level assertions.
DiCEDiverse Counterfactual Explanations
Generates the minimal input changes that would flip a decision — the basis of actionable adverse-action reasons.
EvidentlyEvidently AI
Drift, data-quality and model-performance reporting library.
FairlearnFairlearn
Microsoft-originated fairness assessment and mitigation toolkit.
garakgarak
NVIDIA-maintained LLM vulnerability scanner covering prompt injection, leakage and jailbreaks.
GEGreat Expectations
Declarative data-validation framework; each expectation becomes an evidence artefact.
lm-eval-harnessLanguage Model Evaluation Harness
EleutherAI harness for standardised LLM task evaluation.
MLflowMLflow
Model registry and experiment tracker most clients already run; an import source for the AI inventory.
PromptfooPromptfoo
Prompt and model regression-testing tool.
PyRITPython Risk Identification Tool
Microsoft framework for automating generative-AI red-team campaigns.
RagasRagas
Metrics suite for retrieval-augmented generation — faithfulness, answer relevance, context precision.
SHAPSHapley Additive exPlanations
Game-theoretic feature-attribution method; locally accurate and consistent, which is why regulators accept it.
TemporalTemporal
Durable workflow engine that keeps long-running validation suites resumable and auditable.
Abbreviations23 entries
Platform & infrastructure
How the platform is built, deployed and operated inside a client's perimeter.
APIApplication Programming Interface
Programmatic access to the platform's services.
CIContinuous Integration
Automated build-and-test pipeline; ours also produces SBOMs and signatures.
CLICommand Line Interface
The offline Trust Proof verifier ships as one.
GPUGraphics Processing Unit
Accelerator used for model evaluation; H100 denotes NVIDIA's data-centre part.
HelmHelm
Kubernetes package manager; the platform installs as a single chart.
HSMHardware Security Module
Tamper-resistant device that holds signing keys and never exports them.
k3sk3s
Lightweight Kubernetes distribution suited to on-premises and edge installs.
LDAPLightweight Directory Access Protocol
Legacy directory protocol still used for enterprise identity.
MinIOMinIO
S3-compatible object store deployed on-premises; holds evidence artefacts.
OIDCOpenID Connect
Identity layer over OAuth 2.0 used for single sign-on.
OPAOpen Policy Agent
Policy engine (with the Rego language) enforcing authorisation rules.
OTelOpenTelemetry
Vendor-neutral standard for traces, metrics and logs.
RBACRole-Based Access Control
Permissions granted by role; mirrors the 19-role engagement matrix.
S3Simple Storage Service (API)
De-facto object-storage interface; MinIO implements it on-premises.
SAMLSecurity Assertion Markup Language
Enterprise single-sign-on protocol still common in banks.
Confidential-computing technology that encrypts and attests a virtual machine's memory.
SPIRESPIFFE Runtime Environment
Issues short-lived workload identities; used to bind attestation to running services.
SSOSingle Sign-On
One authentication across the platform, federated to the client's identity provider.
TDXTrust Domain Extensions (Intel)
Intel's confidential-computing technology for attested, memory-encrypted VMs.
TEETrusted Execution Environment
Hardware-isolated enclave where evaluation can run without exposing weights or data to the host.
VeraisonProject Veraison
Open-source attestation-verification service for TEE quotes.
VPCVirtual Private Cloud
Isolated network segment in a cloud account.
WORMWrite Once, Read Many
Storage mode preventing modification or deletion — how evidence buckets are locked.
Abbreviations13 entries
Cryptography & provenance
What makes a Trust Proof verifiable by someone who does not trust us.
cosigncosign
Sigstore tool for signing and verifying container images.
DSSEDead Simple Signing Envelope
Signature envelope format used to wrap attestations.
ECDSAElliptic Curve Digital Signature Algorithm
Classical signature scheme; paired with ML-DSA in our hybrid signatures.
FIPS 204Federal Information Processing Standard 204
US standard specifying ML-DSA, the post-quantum signature scheme we use.
in-totoin-toto
Framework for attesting each step of a software or evidence supply chain.
ML-DSAModule-Lattice Digital Signature Algorithm
NIST-standardised post-quantum signature (formerly CRYSTALS-Dilithium); ML-DSA-65 is the parameter set we sign with.
PKCS#11Public-Key Cryptography Standard 11
API for talking to an HSM without extracting keys.
PQCPost-Quantum Cryptography
Algorithms designed to resist quantum attack; required because Trust Proofs must outlive today's cryptography.
SBOMSoftware Bill of Materials
Machine-readable inventory of components in a build; ours is CycloneDX, generated by Syft.
SHA-256Secure Hash Algorithm, 256-bit
Hash function used to fingerprint every artefact on ingest.
SigstoreSigstore
Open signing and transparency-log ecosystem (Rekor, Fulcio, cosign).
SLSASupply-chain Levels for Software Artifacts
Framework of build-provenance requirements; we target verifiable provenance for every image.
SyftSyft
Tool that generates SBOMs from container images and filesystems.
Abbreviations12 entries
Programme & commercial
Terms from the build plan, the engagement contract and the board pack.
AEDUnited Arab Emirates dirham
UAE currency, pegged at approximately 3.6725 to the US dollar.
DPAData Processing Agreement
Contract governing a vendor's processing of personal data; required on file for every supplier in the inventory.
FTEFull-Time Equivalent
One person-year of capacity; contractors are planned in fractions of it.
GRCGovernance, Risk and Compliance
The enterprise function — and the tool category — our evidence feeds.
GTMGo-To-Market
Commercial motion: pilots, pricing, partnerships.
IRMIntegrated Risk Management
ServiceNow's GRC module; a common integration target.
KPIKey Performance Indicator
The measures that define "done" at month 6.
LOILetter of Intent
Non-binding commitment from a design partner, including data access and a named sponsor.
PRDProduct Requirements Document
Frozen specification the build works from.
RACIResponsible, Accountable, Consulted, Informed
Role-assignment model recorded per contact during entity onboarding.
SoWStatement of Work
Contract annex defining scope, deliverables and terms; the document the AI extraction reads.
WBSWork Breakdown Structure
Epic-level decomposition of the plan, exported as a spreadsheet.
Abbreviations8 entries
Roles & functions
People named in the onboarding record, the RACI matrix and the attestation.
CEOChief Executive Officer
Accountable for the engagement on the client side; in our plan, the policy and go-to-market founder.
CISOChief Information Security Officer
Owns security controls; a required contact before certification.
CTOChief Technology Officer
Owns the technical build; in our plan, the ML and cryptography founder.
DevSecOpsDevelopment, Security and Operations
Practice — and the contracted role — joining delivery with security and packaging.
DPOData Protection Officer
Statutory privacy role under PDPL and GDPR; a required onboarding contact.
ISMSInformation Security Management System
The documented set of policies, risks and controls certified under ISO/IEC 27001.
MRMModel Risk Management
Bank function owning model inventory, validation and approval; our primary counterpart.
SMESubject Matter Expert
Domain specialist consulted during scoping and war games.
Need this mapped to your regime?
Sector regulators, national frameworks and internal model-risk policies can be added to the control set at scoping. The Day −30 call is where that starts.
