Responsible AI Policy
This page is Lunixi's written policy on the use of artificial intelligence and machine learning. You can cite it in your vendor assessment, your data protection impact assessment and your audit file.
| Version | 1.0 |
| Effective date | 20 September 2026 |
| Scope | All AI and machine learning components running on the Lunixi platform |
| Policy owner | Lunixi engineering and compliance — [email protected] |
| Review | Annually, and whenever a new AI surface is added or an existing surface's decision authority changes |
This policy describes where we stand today. We do not describe a control as implemented before it is; the gaps are listed explicitly under Where we stand at the end of this page.
Scope — where AI runs on the platform
| Component | What it does | Decision authority |
|---|---|---|
| Payment routing model | Selects which POS terminal a transaction is attempted through | The bank decides whether a transaction is approved. The model only determines which bank it is attempted through |
| Fraud rule engine | Produces the block / review / clean decision | Not a model. It runs deterministically from the rules you publish — see Decision Governance |
| Machine learning platform | Transaction scoring, model registry, inference observability | Not in the decision path. A model output can influence a decision only by being wired into a published flow as an input |
| Flow blueprint generation | Turns the policy text you write into a starting flow draft | None. The draft is born disabled and is never persisted |
| Compliance assistants | Match rationale, case summary, entity resolution suggestion | None. They produce suggestions — see Compliance AI |
| Identity verification | Document reading, liveness and face matching | Automatic approval is disabled; see below |
Principles
- A human owns the decision. No decision affecting an individual is concluded on a model output alone, without human oversight.
- Every decision must be explainable. If we cannot show why a decision was made, we do not automate that decision.
- The decision path must be predictable. On the money and compliance path, a deterministic rule is preferred over a probabilistic output.
- A model output holds no privilege. If a model's result is to influence a decision, it passes the same validation and publish gate as a human-authored rule.
- Personal data does not reach model providers. Card data, identity data and biometrics are never sent to external model services.
- We do not claim what we have not measured. We state that a model performs better only when we have measured it with a sufficient sample and a confidence interval.
- Reversibility is essential. Every model behaviour put into production must be reversible without losing learned state.
How human oversight is enforced
These are gates enforced in the system, not commitments at the level of principle.
Automatic approval is disabled in identity verification
Low-assurance automatic approval is not a configuration choice: with that setting enabled, the service does not start. The identity verification service refuses to boot while automatic approval flags are set. Document and evidence records carry the identity of whoever accepted or rejected them.
AI output is a draft, not a release
Three layers of constraint apply to flow blueprint generation:
- The generated draft is never persisted and never published; it is returned in the response and is born disabled.
- Side-effecting node types are removed from the palette the model may generate: nodes that execute code, make outbound calls, query databases or emit events cannot be produced by the model. An operator adds these by hand in the builder, where they write the target deliberately.
- If the draft does not pass the engine's own validator, it is not returned at all.
To go live, you must save the draft and take it through the validate → simulate → publish gate chain. If no model is configured, the system does not invent a template; it returns an explicit error.
Model changes roll out gradually and by hand
On the routing side, a new model behaviour is never applied to all traffic at once:
- The candidate model first runs in shadow — it produces decisions that are not applied.
- It is then opened to a traffic percentage set by hand from the panel. The default is zero; no transaction is affected until you open it.
- Making it permanent is a separate, manual decision.
- Opening a candidate model before it reaches a sufficient sample is blocked by the system.
The final decision belongs to the analyst
The output of the compliance assistants is an explanation the analyst reads. What is defended in an audit is not the model's output but the analyst's decision and the evidence it rests on.
Explainability
Routing decisions
Every routing decision is stored together with its rationale. The rationale decomposes the score gap between the winning terminal and the runner-up into components: cost, approval rate estimate, provider health, latency, risk and the quality the model has learned.
Because the score is a linear weighted sum, this decomposition is exact, not an approximation: the component contributions sum precisely to the gap between the two candidates. The rationale carries no language — it is stored as codes and numbers, and the sentence is composed in the presentation layer. Audit data is therefore never bound to a single language.
Machine learning scores
For every score produced on the machine learning platform, feature attributions are computed (TreeSHAP). The attributions show which feature moved the score, in which direction and by how much, and are attached to the decision envelope as explanation factors.
Rule decisions
Every fraud decision record carries the flow version it was decided under. The answer to "why was this transaction blocked" is traceable from the decision itself to the publish record. When a condition remains indeterminate, that state is written into the rationale as well; uncertainty stays visible in the decision.
Model monitoring
| What is monitored | How |
|---|---|
| Divergence of the candidate model from the live decision | The shadow experiment compares at terminal level — the decision unit itself. The report carries a 95% Wilson confidence interval; below the sample threshold no verdict is issued |
| Coverage of the measurement | Skipped decisions are counted separately. Where coverage is unknown it is reported as unknown, never as zero |
| Health of an open experiment | A monitor running every five minutes checks experiment arms against thresholds and raises an alert on a breach |
| Learning trajectory | The cumulative learning curve and the freshness of model inputs are measured |
| Version governance | Model snapshots are stored together with their schema and model version. Rolling back to a previous version preserves learned state — a rollback does not mean starting from zero |
The monitor alerts; it does not roll back. No automatic rollback is performed on a threshold breach; the rollback decision belongs to a human. This is deliberate: automatic rollback reacts to measurement noise and can destabilise a settled configuration.
Data protection
- No personal data is sent to external model services. In flow blueprint generation, the only input reaching the model service is the policy text the operator writes in the panel. No card data, identity data, biometrics or transaction records are sent. The operator's text is framed to the model as untrusted input and its length is bounded.
- Model inputs are derived signals. The routing model works with transaction attributes such as card scheme and instalment count; the card number is not a model input.
- Biometric and document data are encrypted in the application layer with a per-tenant key before being written to storage, and are subject to their own retention period. Detail: Security Controls and KVKK.
- Audit trail. The model and prompt version used for an AI-generated draft are carried on the draft as an audit stamp.
Automated decisions and the right to object
The fraud engine can automatically block a transaction according to the rules you publish. Your organisation is the data controller for that decision; Lunixi acts as a processor. The process for handling a data subject's objection and request for human intervention is your organisation's obligation.
The platform provides the tooling you need to meet it: the decision rationale and reason codes, the flow version the decision rests on, case management and the analyst override path, and an append-only audit record.
Model review
Monitoring is continuous and automatic; review is periodic and human. Neither substitutes for the other — a threshold monitor does not answer the question of whether the model is still doing the right job.
From the effective date of this policy:
- A model review is conducted quarterly.
- This policy is reviewed annually.
- An event-driven review is conducted in addition whenever a model's decision authority is widened or a new AI surface is added.
Each review covers:
| Topic | What is examined |
|---|---|
| Inventory | Models running in production, their versions and their decision authority |
| Measurement | Shadow and gradual-rollout reports, sample sufficiency, confidence intervals |
| Explainability | A sample of decision rationales and their consistency with the decision |
| Incidents | Threshold alerts, rollbacks and the responses to them |
| Open items | The status of gaps carried over from the previous review |
How a review is conducted — roles, method, finding classes and escalation — is defined in a separate procedure: Model Review Policy. The schedule and completed reviews are kept on the Model Review Log. The detailed record can be shared under NDA as part of a vendor assessment.
We make no retrospective claim. This cadence begins on the policy's effective date. Model and measurement audits were performed before it, but as the need arose rather than on a schedule.
Where we stand
For this policy to be honest, we also state the controls we have not yet implemented.
| Topic | Where we stand |
|---|---|
| Decision explainability | Implemented — exact contribution decomposition in routing, feature attributions in scoring |
| Model performance monitoring | Implemented — shadow experiment, gradual rollout, threshold monitor |
| Human oversight gates | Implemented — automatic approval prohibition, publish gate, manually opened traffic percentage |
| Data / concept drift monitoring | Not yet. Monitoring today is based on performance and decision divergence; the input distribution is not separately tracked |
| Periodic model review | Now on a schedule — quarterly, from this policy's effective date. Before it, reviews were performed as the need arose |
| Independent third-party model audit | Not yet. Review is currently conducted in house |
| Automatic rollback | None — deliberate; see above |
| Staff AI literacy programme | In force (20 September 2026); the first cycle closes on 31 October 2026 — see AI Literacy |
| Regulatory risk classification | Done and published — see EU AI Act |
Related pages
- Decision Governance — who authors a rule, how it is published, how it is rolled back
- Compliance AI — the boundary of the analyst assistants
- Security Controls — encryption, access, audit logging
- Trust — compliance posture and the documents we can share
Questions
For questions on this policy, a vendor assessment form or support with a data protection impact assessment: [email protected]