sovereignty

Sovereign by design, not by exception.

This is the first question a government or a group board asks. We answer it before the demo, not after it.

data residency

Where the data sits, and who can reach it.

Where data is stored, who can reach it, and what leaves the region under which conditions are fixed in writing for each engagement, before the first system is connected.

  • 50–70%

    of cloud buyers now require explicit control over where their data lives and who can reach it.

    IDC Cloud Pulse, 2024
deployment models

Your infrastructure, our managed environment, or a hybrid.

Which model applies, and what changes between them, is set out per engagement before anything is signed — not discovered during the security review.

regulatory alignment

Every item carries one of two labels — and the label is never inferred.

Every framework here will carry one of two labels — Certified, or Aligned, not certified. A label is added only when the evidence behind it is confirmed, and it is never read across from another item. Until then the framework is listed without its label rather than with a flattering one. Blurring that difference is the most common way a firm this size loses a client at the diligence stage.

UAE PDPL
The federal frame for personal data protection in the United Arab Emirates.
DIFC Regulation 10
The rules that apply where autonomous and semi-autonomous processing touches personal data.
Sector regulator
The requirements your own regulator applies, which are rarely the same list twice.
ISO/IEC 42001
The management-system frame for AI — a statement about how an organisation is run, not about any single model.
international interoperability

Exportable, not only deployable.

For clients with European exposure, we document to EU AI Act expectations — risk classification, technical documentation, and the records an eventual conformity assessment would ask for. This is not a compliance chore in this market. It is what makes a system exportable rather than only deployable.

model governance

Where the models came from, and what happens when one drifts.

Model provenance, evaluation method, drift monitoring, incident handling and the contents of the audit trail are documented per engagement, before deployment rather than after the first incident.

the evidence record

We design to one test — reconstruction by someone who was not there.

Every automated action leaves a timestamped, attributable, case-linked record. The test we design to is simple: can someone who was not present reconstruct what the system did, what it relied on, and where a person intervened — two years later, under adversarial questioning?

A system that cannot answer that will eventually be switched off, whatever it saved in the meantime.

security

How access, encryption and testing are handled.

Access control, encryption, the testing cadence and the address for reporting a vulnerability are stated per engagement and re-confirmed whenever the architecture changes.

where to start

Ask the diligence questions before the proposal, not during it.

If your board, your regulator or your security team has a question this page does not answer, put it to us first. We would rather answer it now than argue about it later.

Start a conversation