Under the Hood: How Mervey's AI Direction is Built
We are launching a series that dissects each of the holding's six directions from the inside—not through promises of digital transformation, but by showing how projects evolve from their first conversation into fully functional systems.
- By
- Манапова Гульдана
- Published
- August 24, 2026
We start with AI—the direction surrounded by today's highest expectations and lowest specificity.
The request sounds the same, but the tasks behind it vary
A significant portion of incoming inquiries begins with one phrase: we need AI. Almost always, something much more specific follows. Support struggles to handle a flood of repetitive questions and replies to customers a day later than promised. Lawyers manually review hundreds of similar contracts just for three changing clauses. A manager compiles weekly reports from four systems and email correspondence, spending half their workday on it. These are different tasks with different economics; the only thing uniting them is the assumed solution. Therefore, our work usually starts not by choosing a model, but with an inverse operation: we break down general requests into specific tasks and state clearly which ones models solve better than humans, which require partial human verification, and which don't need machine learning at all. Clients hear this last answer regularly from us; we consider it normal part of the job, not lost contracts.
Three criteria for task selection
First—the nature of the data. AI is justified where most information is unstructured: documents, inquiries, speech, images. If data already sits in a table with clear fields, standard database queries are cheaper and more reproducible. Second—is there a way to verify the answer? Models provide results with some accuracy, not guaranteed correctness. A task fits when you can cross-check answers against sources, show them to humans before sending, or compare them to benchmarks. If verification is impossible and blind trust isn't an option either, it's not for a model. Third—the cost of error. There is a fundamental difference between an error in a draft letter read by an operator and one in a fund transfer decision. The higher the stakes, the tighter human control must be, and the more carefully we assess whether automation remains worthwhile once factored into budgets. If a task has clear rules, standard code solves it: cheaper, reproducible, and not requiring quality recalculations after every model update. We tell clients this directly, even when such answers significantly reduce project scope.
The Model is the Smallest Part of the System
Once a solution is chosen, it becomes clear: the model itself occupies only a small fraction of the project; most engineering happens around it. This includes scenario routing, context preparation with source attribution so answers are verified by link rather than intuition, toolsets with explicitly limited permissions, and logs showing which data was accessed and how responses were formed. The first weeks rarely look like AI development. More often, they involve organizing the data: if an internal database holds three versions of a regulation without dates, an assistant confidently quotes any one of them. Another critical issue is access rights. A model inherits permissions from its user; if an employee can't see a document, neither should their assistant mention it. This is where fast pilots built around existing permission systems usually fail.
Quality, Scope, and Cost
Before development begins, we gather a benchmark set: real questions, real documents, approved correct answers, and acceptance criteria. Without this, quality discussions devolve into "it seems better," which is insufficient to accept or update the system. This same dataset acts as regression testing: models change, so after every update we must confirm the system hasn't degraded on target scenarios. Choosing between an external API and a model within our own perimeter depends on data requirements, not trends. If personal or financial information enters processing, where computation physically occurs and what crosses company boundaries is resolved before architecture design. Operational costs are calculated per operation—one inquiry, one document—and assessed during the pilot phase, not after launch: cheap models handle main flows; expensive ones connect via explicit escalation rules; repeated queries are cached; long contexts shrink to relevant fragments.
The System Must Exist Where People Already Work
Functions requiring a separate window are rarely used—confirmed in nearly every project. Therefore, AI integrates into interfaces where employees already spend their day while designing system behavior for model unavailability: processes revert to standard manual scenarios with clear notifications rather than stopping entirely. Our own products let us test these solutions firsthand: in Synqo, the assistant operates within a secure messenger where data perimeter requirements are practical, not theoretical. The automation direction ensures model results feed into existing workflows instead of remaining chat responses. The most honest answer to AI project inquiries is to start with one scenario, measure it, then expand. A system solving narrow tasks predictably is more useful than an all-capable platform failing real-world data checks. If you have a task and aren't sure if AI belongs there, describe it via email. We'll analyze it using the same three criteria and answer directly—including "no model needed here".