Who this covers, and who it doesn't.
This policy applies to personal data MIHZI Ltd ("MIHZI", "we") handles when we provide decision-intelligence services (models, SDKs, APIs, and analyst consoles) and when we operate the secure data platform underneath them.
It covers data about our clients' end-customers that we process on a client's behalf, data about our own business contacts, and data from visitors to our systems. It does not govern how our clients independently use the outputs we deliver to them. That sits under their own policies and our contract.
We wear two hats, and we're registered for both.
Under Rwanda's data-protection law, the same organisation can act as a data controller (deciding why and how data is processed) and a data processor (processing on instruction from another controller). MIHZI is registered in both capacities, and we tell you which hat we're wearing for any given dataset.
- As processor, when we run models or pipelines over a client's customer data, the client is the controller. We act only on documented instructions, under a Data Processing Agreement (DPA).
- As controller, for our own business operations: prospect and client contacts, recruitment, billing, and security telemetry from our own systems.
The categories of data we touch.
We are data-minimal by design: we process only what a given purpose requires, and we pseudonymise at ingest wherever a model doesn't need identity.
- Behavioural & interaction data: session signals, device and channel metadata, timing and navigation patterns used in agreed risk, operations, or decision-support services.
- Transactional & operational data: payments, claims, account, telemetry, and usage records supplied by clients for risk, operations, forecasting, or decision-support work.
- Identity data: names and identifiers, only where a use case genuinely requires re-identification, and gated behind contractual review.
- Business-contact data: names, work emails, and roles of people at client and prospect organisations.
For health or other special-category data, the customer/controller establishes the permitted purpose and lawful basis. Before collection or model development, MIHZI and the controller agree the data-flow map, minimization decision, access controls, retention schedule, DPIA or equivalent assessment where required, clinical/ethics approvals, outcome definition, and escalation path. A model does not diagnose, prescribe, or override a clinician unless a separately governed product and approval path permits it.
Why we process, and on what footing.
- Service delivery
- Running models, agents, and consoles for a client. Basis: performance of contract (processor, on the client's lawful basis).
- Model development
- Building and validating models on approved, typically pseudonymised data under the controller’s instructions and the engagement contract. Special-category work requires its own lawful basis and approvals; legitimate interests is not treated as a universal basis for clinical model development.
- Fraud & security
- Detecting anomalies and protecting systems. Basis: legitimate interests and legal obligation.
- Business operations
- Contact, billing, recruitment. Basis: contract, legitimate interests, or consent as applicable.
We keep data for as long as the work needs it, then return or destroy it.
Processor data is retained for the term of the engagement and the period set in the DPA, after which it is returned or securely destroyed on the client's instruction. Controller data we hold only while there is a lawful purpose, then delete on a scheduled cycle. Security and audit logs are kept for a defined window to support investigations and attestations.
The controls are encoded in the system, not the policy doc.
Encryption in transit and at rest, role-based access, audit logging, and residency commitments are documented per deployment and available during security review. The full stance, and how we handle incidents, lives on our posture page.
Who else touches the data.
Where we use sub-processors (cloud hosting, infrastructure), they are bound by contract to equivalent obligations, disclosed to clients, and subject to change-notice and objection rights under the DPA. A current sub-processor list is available to clients on request.
Mapped before production.
The deployment architecture determines where raw data, derived data, scores, logs, backups, support access, and sub-processors operate. Any regional or cross-border processing is mapped before production and covered by the applicable controller instructions, contract, transfer mechanism, retention rule, and security controls. Where an in-country boundary is required, the deployment is verified against that requirement rather than assumed from the edge location.
Access, correction, erasure, objection.
Data subjects have rights to access, rectify, erase, restrict, and object to processing of their personal data, and to lodge a complaint with the supervisory authority. Where we act as processor, we route requests to the relevant client-controller and support them in responding. Where we are controller, contact us directly at info@mihzi.com.
When this changes, and how to reach us.
We update this policy as our services and the law evolve; material changes are dated at the top and, for clients, notified under contract. Questions, requests, or concerns go to our Data Protection contact:
- Email: info@mihzi.com
- Post: MIHZI Ltd
- Supervisory authority: National Cyber Security Authority (NCSA), Rwanda
This policy is currently published in English. The English version is the binding copy.