How we work
A project goes through four stages, and every solution follows three rules.
01Stages
Project stages
- 01Diagnostic sessionTogether with the bank we choose a use case from the catalogue and fix the success metric and the list of required data.Use case, metric and data agreed in writing before the pilot starts
- 02PilotWe deploy the solution inside the bank’s perimeter in retrospective or shadow mode and prepare a report comparing the result with the current process.Pilot result in a report for the management board
- 03Roll-outWe move the solution into production under the oversight of bank staff and train the team.The solution runs in the bank’s processes
- 04Support and scalingWe monitor the solution, validate models every quarter and add further use cases on the same platform.Further use cases reuse existing connectors
Typical combinations of solutions are collected in the starter packages.
02Rules
Rules for every solution
- 01Data stays in the bankSystems are deployed on the bank’s servers or in its private cloud and make no calls to external APIs.
- 02A bank employee makes the decisionThe agent prepares a draft, the evidence or a scenario. An authorised employee approves the result.
- 03A separate layer next to existing systemsCore banking, CRM and processing are not changed. Solutions work with copies of data in an isolated environment.
03Security and NBU
Regulatory requirements
Information for security, the CRO and compliance. We design our solutions in line with the NBU Discussion Paper on the Ethical and Responsible Use of AI ↗ of 24.03.2026, as well as the requirements of the EU AI Act and DORA.
01Data localisationOn-premises or the bank’s private cloud; data, queries and answers never leave the perimeter. Air-gapped deployment with no internet access is possible.
02Right to audit the vendorOpen-weight models; the contract provides for audit of code, infrastructure and processes.
03Limits on data useThe bank’s data is not used for other clients; fine-tuned models and adapters belong to the bank.
04Regular validationBuilt-in regression tests, drift monitoring, automated validation report.
05ExplainabilityEvery agent answer includes its source or the factors that shaped the result.
06Human oversightShadow mode at the start; the agent drafts, an authorised employee approves. No automatic rejections of customers.
07Audit trailModel version, input and output are logged so any decision can be reproduced.
08Exit plan (DORA)Open weights and standard formats: the bank can keep running the system without the vendor.
Technical safeguards
The architecture rules out autonomous credit decisions and pricing. Compliance is verified during the pilot together with the bank’s own teams.
- Perimeter
- Services and GPU resources in a separate segment of the bank’s network, with no outbound connections to third-party services.
- Access
- Integrated with Active Directory / IAM. The agent shows an employee only the data they can access in the source system.
- Encryption
- With the bank’s keys; secrets in the bank’s vault.
- Isolation from production
- Twins and test environments run on copies or synthetic data and have no write access to production systems.
- Observability
- Every agent action is logged; anomalies surface on the security team’s dashboard.