510 supports Red Cross organisations around the world with IT services, including the setup and management of EspoCRM, a customer relationship management system used across regional Red Crosses to log and track feedback from the communities they serve. The challenge was not a lack of data, it was the difficulty of making sense of it at scale.
A few factors made this particularly complex:
Decentralised infrastructure. Each regional Red Cross runs its own CRM instance. There is no centralized database to query. This meant that a traditional data pipeline pulling records, processing them in batch, and writing results back was not feasible. Instead, Xomnia designed a stateless web service to which CRM systems send records on demand, receive results immediately, and retain full ownership of their data.
No shared classification framework. Every Red Cross organisation uses its own category structure, reflecting local context and operational priorities. A pre-trained classification model would be useless here. The solution had to work with whatever coding framework a given Red Cross was using dynamically, at the time of each request.
Privacy and data sensitivity. Feedback records contain highly personal and sometimes sensitive information about vulnerable people. This ruled out routing data through certain commercial AI providers. The team switched from an initial OpenAI-based setup to Mistral, a European provider subject to GDPR, and built anonymisation directly into the processing pipeline. Human oversight was kept as a core design principle: the system produces suggestions and drafts, not final decisions.
Language diversity. The Red Cross operates across five official languages and the Ukrainian context adds Ukrainian and Russian. Supporting small or less-resourced languages particularly for anonymisation tasks remains a challenge for future development.
Xomnia built a cloud-hosted, stateless API service running on Microsoft Azure. The service receives feedback records via JSON requests from EspoCRM workflows, processes them on the fly, and returns structured results without storing any user data.
The AI layer relies on large language models (LLMs), specifically Mistral, to handle classification, summarisation, and analysis tasks. Because LLMs do not require pre-training on a fixed label set, the service can work with any classification framework a Red Cross organisation provides at runtime. Records are described to the model alongside the relevant category definitions, and classification happens dynamically.
On the software side, the team chose hexagonal architecture combined with domain-driven design. Hexagonal architecture enforces a strict separation between business logic and external integrations, meaning a data scientist joining the project can implement logic in a single well-defined module without needing to understand the full system. Domain-driven design ensures that developers, the product owner, and the Red Cross team all use the same terminology, what the code calls a "feedback record" is what everyone calls it, with no ambiguity. Both decisions proved particularly valuable given the rotating team structure.
Infrastructure is fully defined as code using Terraform, with three identical environments (development, testing, production). Any new developer joining the project has a single source of truth for how everything is set up.
To support non-technical users within Red Cross organisations, the team built EspoCRM workflow files that CRM administrators can download and install, enabling their systems to connect to the API with minimal configuration.
Guardrails are built in at multiple levels. For individual record summaries, names and identifying information can be preserved where appropriate. For aggregate reports, personal information is actively filtered out before anything is returned. The system is designed to support human review at every step, it drafts and suggests, and people decide.
The system is approaching its first milestone: a working product ready for testing with the Ukrainian Red Cross, chosen both for the volume of feedback it handles and for the strength of its internal IT team, which is well-placed to provide meaningful early feedback.
While it is too early to report measured business outcomes, the direction of the impact is clear. Coordinating teams will be able to send a month's worth of feedback records to the service and receive a structured analysis in return, rather than spending hours manually reviewing and categorising entries. The classification step alone, previously a manual and time-consuming process, will be handled automatically, freeing up capacity for the work that actually requires human judgement.
Because the service is stateless and built without hard-coded assumptions about any specific organisation's data structure, it can serve different Red Cross contexts with minimal adjustment. This makes it a natural candidate for rollout across other regional organisations through 510's network, and 510 has already indicated that it will serve as a reference implementation within their organisation. Future technical projects will be able to draw on it as a practical example of clean architecture, infrastructure as code, and responsible AI integration.
For Xomnia, this is a demonstration of what applied AI can do in a context where the stakes are real and the constraints are significant: sensitive data, limited resources, decentralised infrastructure, and a diverse global user base. It is the kind of problem where the technology has to be designed carefully, not just deployed quickly.
Every month, the Ukrainian Red Cross receives around 3,000 feedback records from the people it serves. These records cover everything from expressions of gratitude to serious concerns about food and water supply. Buried in that volume is critical in...
a.s.r., one of the Netherlands’ largest insurance and financial services providers, manages a wide portfolio, including insurance, pensions, mortgages, and capital management. As digital transformation accelerated their operations, Asset management...
The BI team faced some fundamental changes. After a restructuring of the data department the responsibilities of the developers changed, and the team inherited a complex reporting and data model landscape with varying levels of documentation.”
