Dipp AI publishes its enterprise data boundary commitment
A contractual promise not to train on customer data is not a control. Dipp AI publishes the architectural commitment it holds itself to instead.
By Odero Otieno — Founder, CEO & CTO, Dipp AI Technologies, Inc.
The commitment sets out how the Orcher data control gateway classifies payloads, enforces the enterprise's own boundary rules before dispatch, records every crossing and every refusal, and makes the boundary observable rather than asserted.
Every serious model provider now publishes some version of the same sentence: we will not train on your data. It is a reasonable commitment and an inadequate control. A commitment is enforced by contract, verified by attestation, and discovered in breach. A control is enforced by architecture, verified continuously, and observable by the party carrying the risk. Enterprises are being asked to accept the first where they need the second.
Dipp AI is publishing the commitment it holds itself to, in the form of the mechanism rather than the assurance. The Data Control Gateway is the component of Orcher responsible for it, and it operates before dispatch, not after logging.
Data Control Gateway
The boundary is a decision the system makes on every call
Select a stage
The payload is classified before anything leaves the tenant. Regulated fields, identifiers, and privileged material are tagged at the field level, not at the document level.
Dipp AI · Orcher
Fig. 1 — The data control path. Classification, policy evaluation, boundary decision and recorded outcome, all before a payload reaches a provider.
The commitment, stated as mechanism
Every payload is classified before dispatch, against the enterprise's own data classes rather than a generic sensitivity scale.
Boundary rules are the enterprise's, expressed as policy, versioned, and enforced by the gateway rather than by the calling application.
A payload that would cross an unauthorised boundary is refused, and the refusal is a recorded event with a reason, not a silent drop.
Every crossing that is permitted is recorded: what class of data, to which provider, under which policy version, authorised by which role.
Redaction, tokenisation and local execution are routing outcomes, selected by policy, not manual pre-processing steps left to the developer.
The record is written to the Immutable Audit Ledger so the boundary can be evidenced, not merely described.
Why classification has to precede routing
Where classification happens determines whether the boundary is real. If a payload is classified after a provider has already received it, the enterprise has documented an exposure rather than prevented one. Placing classification ahead of the routing decision means data class becomes an input to model selection: a task carrying regulated records is eligible only for models and regions the policy permits, and if no eligible model exists, the task does not silently degrade to the nearest available option — it stops.
Question a regulator asks
Contractual promise answers
Gateway answers
Did regulated data leave the boundary?
We believe not
No — and here are the refused attempts
Which provider processed this record?
Check the vendor list
This provider, this policy version, this timestamp
Who authorised the crossing?
Unclear
This named role, under this standing grant
Can the control be tested?
Via annual attestation
Continuously, per action
Table 1 — The same four questions, under a promise and under a control.
Pre-dispatch
when the boundary is evaluated
Before any payload reaches a provider
Per action
granularity of the record
Not per system, per integration or per quarter
Refusal
default when policy cannot be satisfied
Failure is closed, and it is logged
What this is not
This is not a claim about where data physically sits. Residency is a narrow property and, on its own, a weak control: data can sit in the correct region and still be absorbed into a training corpus, retained beyond its purpose, or reached by a party the enterprise never authorised. The commitment here is about the boundary itself — what may cross it, under whose authority, and with what evidence — and about ensuring that enterprise data does not become training material for anyone but the enterprise.
“Ask for the mechanism, not the sentence. If the answer to 'how would we know' is an attestation letter, it is not a control.”
Sources
Sources for every figure in this article.
Where a number comes from Dipp AI's own analysis or an observed deployment, it is labelled as such and is not presented as an independently audited third-party finding.
Dipp AI Technologies, Enterprise Data Boundary Commitment (August 2026)
Dipp AI Technologies, The Enterprise Superintelligence Report, Vol. I (August 2026)
Case studies
Organisations that ran this argument in production.
Modelled reference scenarios with the measurement window, the components enforced and the numbers attached. Each one downloads as a PDF.
Contractual assurance was not evidence. The Data Control Gateway verified training exclusion before every route and hashed the verification alongside the action.
0
routes completed without a verified boundary check
Clearance-scoped roles and a fail-closed boundary let controlled programme data reach a model at all — under conditions the programme office could verify.
Writes the Dipp AI record on enforced governance for agentic systems — authority, enterprise data boundary, cost and compute. Every figure in this piece carries a source, and corrections are published on the record rather than made quietly.