Projects

Analysis

Inventory of existing document sources, assessment of quality, freshness and data structure, and definition of priority use cases: internal regulatory search, KYC/AML support, document due diligence and consistency checks across policies. The project started with a six-month data assessment (DWH) to normalize sources coming from different management systems: a necessary condition for the RAG system to run on consistent data instead of heterogeneous archives. In this phase, the document classification and field extraction system reached 86% accuracy on a corpus of roughly 25 million pages.

Solution

A RAG-based Enterprise Search platform, with source citation for every answer, version control and a language model adapted to regulatory, banking and insurance terminology. Answers are designed to support the team, not replace the responsibility of the compliance function.

Architecture

Vector Database for semantic search, Knowledge Graph to link related regulations, function-level permission management, query logs and hybrid deployment to meet data residency, security and audit requirements.

Implementation

Pilot phase with a single compliance team, structured feedback collection, creation of an evaluation question set and subsequent rollout to other departments after validating accuracy, sources and behavior on ambiguous cases. In 2026 the system extended into a vertical document RAG for case files, alongside the original regulatory search.

Analysis

Inventory of incoming flow formats and recurring reference structures, analysis of the signals actually usable for matching (name, ordering IBAN, case references, internal codes) and mapping of which combinations produce a certain match and which only a candidate. The decisive step in the analysis: the two errors are not equivalent. A payment attributed to the wrong position costs more than a payment left in suspense, and calibration has to be done on that asymmetry, not on overall match rate.

Solution

A pipeline that normalizes the payment reference, extracts the relevant entities and compares them against the counterparty registry, producing a candidate NDG with a confidence score. Above the agreed threshold attribution is automatic; below it, the case is routed to an operator with ranked candidates and the reason for each, so the human decision starts from work already done rather than from a line of text.

Architecture

Normalization and entity extraction from the free-text reference, deterministic rules first on exact identifiers (IBAN, case code) with the model handling the residual ambiguity, matching against the NDG registry with a confidence score, thresholds configurable by amount band, an audit trail that records for every attribution the criterion that produced it, and integration with the reconciliation systems already in use.

Implementation

A first phase running alongside the existing process: the system proposes the match, operators work as before and compare. This measures real accuracy on live flows and tunes the thresholds against the two error costs before automatic attribution is switched on.

Analysis

Analysis of historical calls to establish which requests genuinely recur and which need a person, identification of the information required to answer and where it lives, and explicit definition of the perimeter: what the agent may say, what it must not commit to, and under which conditions it has to hand the call to an operator.

Solution

A voice agent that handles the inbound conversation and builds every answer on a knowledge base queried in real time, rather than generating it from the model's memory alone. Outside the defined perimeter, or when confidence is low, the call passes to an operator with the context already collected.

Architecture

Speech recognition and synthesis, RAG over the knowledge base to ground answers in verifiable content, guardrails on what the agent may state or commit to, explicit escalation rules and logging of every conversation turn for later review. The dominant constraint is latency: on a phone call a two-second pause is a broken conversation, and the architecture is designed around that budget before it is designed around the quality of any single answer.

Implementation

Started on a narrow subset of recurring requests, with real conversations reviewed and the perimeter widened only after checking behavior on edge cases and out-of-scope requests.

Duration

From kickoff to first production release: about one month.

Analysis

Survey of the descriptive content available across the catalog — album, artist and track metadata, genres, relationships between artists, editorial content — and assessment of its coverage, because an engine reasoning over content is worth only as much as the content it can reach. Definition, together with the product team, of what makes a recommendation good in this context: which is not the same as making it correct.

Solution

A recommendation engine that indexes the catalog's descriptive content and retrieves by semantic similarity from what the user is playing or from a natural-language request, building the suggestion on the retrieved content. Because retrieval works on descriptions rather than on co-listening, an album can be recommended with no listening history at all: precisely the point where collaborative filtering has nothing to say.

Architecture

Semantic indexing of catalog metadata and editorial content, vector search for similarity, generation constrained to items actually present in the catalog and available to the user — recommending a record that does not exist or cannot be played is worse than recommending nothing — and traceability of the content behind each suggestion.

Implementation

Started on a subset of the catalog, compared against the recommendation logic already in place and evaluated with real users: in music, the gap between metrics computed offline and the recommendations people actually accept is wider than elsewhere.

Duration

From kickoff to first production release: about three months.