Proof & Compliance

Compliance as a byproduct of running the work.

You do not run the platform and then assemble evidence. The evidence is what the platform leaves behind.

Masking

Private data never reaches the model. Watch it happen.

One request, end to end: the name is tokenized on your soil, only tokens cross the trust boundary, and what comes back is made whole again on your servers.

On your soil
1
The message arrives raw
Draft the intro for Vera Lindt at Nordbank
2
PII detected and masked, host-side
Draft the intro for [NAME-9f2c41] at [ORG-77be03]
token ⇄ value map · in memory only, this request only
5
Rehydrated at display, on your servers
“Hi Vera, following up on Nordbank…”
6
The ledger row seals the turn
masked: 2 · NAME, ORG · sha256 a91f…c2
counts, categories and value hashes · raw PII is unrepresentable in the row schema
7
The map dies with the request
[NAME-9f2c41] ⇄ Vera Lindt
dropped right after use · nothing durable can reverse the tokens
The AI provider
3
Only masked text crosses
…intro for [NAME-9f2c41]
retrieval, when on, also runs on the masked text
4
The model answers in tokens
“Hi [NAME-9f2c41], following up on…”
it never held the name
No new PII store is ever created. The token map is not a database you have to defend: it lives in memory for the life of one request and is dropped right after use. There is nothing durable to breach, subpoena, or leak.

Every lane is masked

Not just chat: connector reads, retrieval, tool inputs and tool outputs all pass the same masking gate before any model sees them. An unknown category fails closed, to masked.

Schema masking, per connector and document

For structured data you can go further: a deterministic masking schema per connector or document type says exactly which fields tokenize, every time. 100 percent data control, by construction.

The receipt

Every job ends in a verified receipt.

Not a log line you have to trust, but a receipt you can check: the masking count, the human approval, rehydration on-soil, the sealed ledger event, the metered cost.

Masked before any model

The count of items protected, and the plain fact that raw personal data never reached the provider.

Approved, then rehydrated

A person said yes where it mattered; real names were restored only after, only on your servers.

Sealed and metered

A signed event in the append-only ledger, and the per-job actual cost, never an estimate.

ZeroH · Job Receiptsample data
APPROVED · SENT
Send intro mail · Jonas W
“Hi Jonas, following our call with Vera Lindt, here is the proposal for Nordbank.”

Rehydrated at the gate; the mail left with real names.
A rejected hold NEVER rehydrates.

ZeroH Governed ✓ VERIFIED
Private data was masked before any AI saw it14 items protected · raw personal data reached the model: no
A person said yes before anything went outapproved by J. Weiss · the send waited 41 minutes for the decision
Real names were restored only after the yeson your servers · the AI provider never saw them
Sealed in the tamper-evident recordreceipt № 2481 · 17 Jul 2026, 12:41 · signed by your organization
Meets your frameworks
ISO 42001ISO 27001GDPRSOC 2AICM
€0.09what this run cost · metered, never estimated
budget checked before it ran
Details for your auditor ↗
Framework readiness

Mapped to the frameworks your auditor already knows.

Trace it yourself: pick a law set, then click any law, control, module or proof to light its whole chain across all four columns, both ways.

Trace the framework

Click any node: its whole chain lights across all four columns, both ways.

Show laws:

Qatar - the national data & privacy landscape (applies to all): PDPPL (the data-protection law) · QFC (financial-centre data rules) · NDPO / NCSA (the regulators). The QCB rulebooks - which apply only to licensed banks - are in the QCB tab.

Nothing selected: click a law, control, module, or proof to trace its chain.
DSPLOGSEFGRC
The Law the why
PDPPL · Art 5 - Data minimisation
PDPPL · Art 8 - DPIA (high-risk)
PDPPL · Art 15 - Cross-border
QFC · Reg 10 - Cross-border
NDPO / NCSA - Breach notification
The Controls AICM · must-dos
DSP-10 Sensitive Data Transfer
DSP-17 Sensitive Data Protection
DSP-22 Privacy Enhancing Technologies
LOG-04 Audit Logs Access and Accountability
SEF-07 Security Breach Notification
GRC-10 AI Impact Assessment
The Modules what ZeroH builds
Mask the question
Fetch as the user
Re-check the answer
Hand over proof
Proof packs
Incident reports
Operator oversight
Govern the tool actiontool-allowedinput-maskedoutput-maskedtool-blockedtool-approved
Emit-Proof the receipt
Masking receipt
Signed event
Redaction receipt
Meeting-prep receipt
Tool-call audit
Tool approval
📦 Proof pack
The law, traced to running code

From the clause to the module that enforces it.

Every governed turn, tool call and decision lands on the append-only ledger; click any row to open the signed receipt it left behind.

sample events, illustrative · your console reports its own live, hash-chained ledger

Events

18 of 18 in range
VerdictTimeAgentKindSourceCategoriesMaskedPolicy
append-only · hash-chained · ES256 signed
Proof packs, built with regulators

A focused pack, shaped to the framework that asked.

A regulator does not want a data dump. Pick an agent and a framework and assemble the pack a supervisor actually reads: the system card, the controls trace, the signed event extract, the masking summary. Every claim in it cites a signed event.

Agent
Regulator / framework

Pick a scope and a framework, then assemble the pack. The preview is illustrative; a live console builds it from the signed ledger.

The registers a supervisor reads

We work the way regulators read.

A supervisor should not wade through raw logs. They get the registry, the risks, and the packs, each row backed by the ledger. Here are the systems we run and the risks we carry, stated plainly.

AI System Registry

The ten agents as registered AI systems: purpose, model routing, data classes, and the human gate.

SystemPurposeModel routingData classesHuman gateStatus
Marketing Agent
sys-mkt-01
Drafts campaigns and posts from approved brand and field sources.policy-routed: claude-sonnet-5 for long-form, claude-haiku-4.5 defaultPublic / brand · occasional PERSON, ORGOutbound publishing held for approvalactive
Sales Agent
sys-sales-01
Researches accounts and drafts outreach before first touch.policy-routed: claude-sonnet-5 for research, zeroh-ft-3 for alertsPERSON, ORG, EMAIL, FIN-AMOUNTOutbound mail held for approvalactive
Finance Agent
sys-fin-01
Reads spend, flags anomalies, drafts variance notes.policy-routed: claude-haiku-4.5 default, claude-sonnet-5 for narrativeFIN-AMOUNT, IBAN, ORGSession unmask + posting held for DPOactive
HR Agent
sys-hr-01
Screens candidates blind and drafts people documents.policy-routed: claude-sonnet-5 for scoring, claude-haiku-4.5 defaultPERSON, EMAIL, PHONE, LOCATIONUnmask + decisions held for People Partneractive
Operations Agent
sys-ops-01
Keeps CRM clean, captures decisions, preps reviews.policy-routed: claude-haiku-4.5 defaultPERSON, EMAIL, ORGCRM writes card-approvedactive
Compliance Agent
sys-cmp-01
Assembles proof packs, watches policy, answers the GRC desk.policy-routed: zeroh-ft-3 for packs, claude-sonnet-5 for consultGovernance metadata · no raw PIIPolicy writes versioned, DPO-approvedactive
Help Desk
sys-help-01
Answers handbook and IT questions, grounded on approved corpora.policy-routed: zeroh-ft-3 defaultHandbook / policy · minimal PERSONEscalations handed to a humanactive
Project Manager
sys-pm-01
Tracks programs, drafts status, surfaces blockers and owners.policy-routed: claude-haiku-4.5 defaultPERSON, ORG · project metadataStatus posts reviewed before sendactive
Chief of Staff
sys-cos-01
Runs morning digests and cross-team synthesis for the executive.policy-routed: zeroh-ft-3 for digests, claude-sonnet-5 for synthesisPERSON, EMAIL, PHONE · cross-teamSensitive summaries held for the sponsoractive
Ask Ali
sys-ali-01
Grounds Shariah and compliance answers on the governed corpus.policy-routed: zeroh-ft-3 default, claude-sonnet-5 for long-formDoctrine / citations · no personal dataRulings cite sources; disputes escalateonboarding
the full register, not a data dump: every row cites its ledger evidence

Risk Registry

An honest AI risk register: the two that matter most first, each mitigation backed by a signed event.

RiskLikelihoodImpactMitigationEvidence
AI concentration
HighHighOver-relying on one model or provider is itself a risk. Policy routing spreads jobs across models and providers (claude-haiku-4.5, claude-sonnet-5, gpt-5.4-mini and the tuned zeroh-ft-3), with per-job model economics and no single-model dependency.Model routing summary · the leaderboard models line · per-turn model on every receipt
PII shared with AI
HighHighMasking runs on-soil before any model call, so raw personal data never reaches a provider. PII reaches a model only with your explicit approval: session-unmask grants and human gates.Masking summary · the per-turn masked-before-model receipt · session-unmask approvals record
Hallucination / ungrounded output
MediumMediumRetrieval grounding, refuse-over-guess, and a quality bar the turn must clear before it lands.Grounded turns cite sources · refusals are their own sealed events
Prompt injection
MediumHighGoverned tools only, tool allowlists, and an SSRF guard on any web fetch.Blocked tool calls on the ledger · the gate-refusal control on the receipt
Data residency
LowHighOn-soil masking and rehydration, per-tenant deployment; rehydration maps live in memory only.On-soil deployment attestation · the rehydration proofline on every turn
Runaway cost
MediumMediumSoft budgets, per-job metering, and day pools that cap public-desk spend.Per-job actual cost on every receipt · the spend KPI on the board
Model drift
MediumMediumEval gates and ratified improvements: a change ships only past the gate.Eval-loop runs · the skill-promotion events on the ledger
Vendor lock-in
LowMediumMulti-provider routing keeps the work portable across models and providers.Model routing summary · the multi-provider spread on the board
the full register, not a data dump: every row cites its ledger evidence
The regulatory bundle: Qatar / QCB

Built for the regulator that will ask.

The QCB AI guideline mapped clause-by-clause, with proof packs generated from the live ledger, the kind a regulated bank can file.

Mapped clause-by-clause

The Qatar Central Bank AI guideline traced to controls and the modules that enforce them.

Quarterly proof pack, filed

Regulator-grade, generated from the live ledger, in ISO 42001 / QCB pack formats.

The rulebook tiles

The specific clauses the platform answers to, each backed by a receipt.

QCB-AI-01

Every AI output traceable to a signed record

QCB-AI-04

Human approval before external effect

QCB-AI-07

Model inputs stripped of personal identifiers

Ask the GRC desk about any of this, live.

The Governance, Risk & Compliance desk answers governed, on-soil, right on the homepage.