A certification company asked us to automate the issuing of EAEU technical-regulation declarations. In two months we studied their manual process, built a working recognition prototype, and answered a technical vetting of two dozen questions. This case is about what a review of a regulated process looks like, and why it pays off for the client even when the development never follows.
The head of the company knows this pain from the inside: issuing a declaration rests on one person. A manager keys the application in by hand from the company card, the technical department assembles the document package from templates, checks the data by eye, and fills in the details by hand. Scaling that by hiring is expensive and fragile. The client came with a direct request: can we put AI here.
We did not set out to sell “turnkey AI.” With AI you cannot say in advance what will work until you build it and run it on real documents. So we started with the process itself: we studied it and assembled a prototype on real packets. We showed the boundaries, where AI removes the drudgery and where it can let you down. To the client we handed the facts for a decision.
Snapshot
| Sector | Product certification, CU / EAEU technical-regulation declarations |
| End client | Certification company, under a code-name |
| Engagement | Pre-project discovery: process audit plus prototype, no signed development contract |
| Project type | AI automation of declaration issuing: document recognition, auto-fill, a TN VED / TR CU adviser |
| Period | October to December 2025 |
| Effort | Analytical stage, 16 h. Prototype built on our own dime. First-stage development estimate of ~150 h not agreed. |
| Team | Anton Hersun (project lead) and an analyst-developer running the review from day one |
| Status | Prototype delivered, the client saw the recognition results. Full project not started by the client’s decision. |
What we were asked for
The client issues declarations and conformity certificates under CU / EAEU technical regulations: declarations, certificates, test protocols, authorised-representative contracts. All of it is prepared by hand in their CRM, from templates, across two departments. The request was worded broadly, “get AI into the work,” but it really broke down into three tasks: recognise the client’s incoming documents, auto-fill the declaration and contract templates, and suggest the TN VED code and the right technical regulation.
Where the hard part actually is
The difficulty is not in the model but in a process that exists nowhere on paper. We reconstructed it from real deals in their CRM, from training videos, and from off-screen recordings of the managers at work. The picture came out like this.
The intake side receives an email, often with no filled application, and keys the applicant’s data in by hand from the company card: name, tax number, registration number, address. The technical department pulls the application from the pipeline, determines the applicable regulation (say, TR CU 010 for attachment equipment), matches the TN VED code to the product group, and assembles the document package from templates — the declaration draft, the authorised-representative contract, supporting materials. Each document is then checked against the original application by hand, field by field.
Manual entry, assembly from templates, repeated cross-checks. Every step is a place where AI can either lift the drudgery off or quietly let you down: the document goes into a state registry, and a mistake there is costly. So the first thing we looked for was not “where AI demos nicely” but “where it won’t get it wrong.”
How we did it
We took observer access to their CRM and walked through six deals and leads, from the client’s email to a finished document packet. We went through the training materials and the recordings of both departments at work. We built a map of how a document is formed: which field comes from where. That is the discovery phase. Not an hour on a call, but a review from the source records, after which you understand the process better than it is described by the client themselves.
Then the prototype. Over a few evenings we stood up a web application form with AI recognition of incoming documents on our own infrastructure, ran it on real packets, and handed the client a link with a login. He saw the recognition results live; his own test that time did not go through, the AI service was switched off, so we ran it again. The prototype exposed the strong spots and the boundaries at once: where the model pulls data out confidently, and where fine-tuning and manual checking are needed.
In parallel we closed a technical vetting. The client sent two dozen questions at once: business logic, personal-data handling and 152-FZ, model choice, architecture, database, security, rights to the result, acceptance metrics. We answered in writing, point by point. Separately we worked through the integration with state systems: how declarations go into FGIS Rosaccreditation via “Sintez” and the Gosuslugi account, what is needed to connect to SMEV3, whether the software needs certification. And against sanctions risk we proposed a Russian perimeter straight away: GigaChat instead of Western models, the field being standardised enough that the approach does not change.
The fork and an honest status
Then the project stalled, and that is part of the case, not a footnote.
The client dragged out the decision: adding a layer of requirements (software certification under FGIS), re-testing our competence, putting off an answer on launch dates. By December it turned out he had been gathering information himself in parallel and had concluded that he first needed a business analyst to describe the processes and requirements. Our discovery, in other words, went into the foundation of his own decisions.
We made a direct move. To the “are we moving to build or stopping” question we put it plainly: the longer the pause runs, the more context leaks out of memory. And once it was clear the project would not start before the new year, we asked to have the analytical stage paid for, the 16 hours of review already working for the client. The client answered with a polite refusal: we hadn’t agreed a detailed plan, so this was “getting to know the project and a proposal, nothing more.”
We see our own share of the misjudgement too. The volume turned out larger than we expected: we counted on pulling the whole chain of process knowledge in a short window, but it took digging deeper, and that is where we fell short. We went into it deliberately, though: AI is a new field, and the experience is worth having even if part of the work lands on us. Still, investing in experience by our own choice is one thing. Finding out after the fact that the free part became a deep dive into someone else’s process, when it should have stayed a trial prototype, is another.
That is how the line between a free prototype and paid analysis works, and on this project we felt for it. A prototype on our own dime stays our rule. But a deep dive into someone else’s regulated process is engineering work, and on the next such job it becomes a separate paid stage up front, not something sorted out after the fact.
What the client got
| What | How it looks in practice |
|---|---|
| A prototype before a big spend | AI document recognition built and handed over for testing before any talk of a full budget |
| A map of their own process | The declaration-issuing process reconstructed from real deals and recordings, more precise than it is described inside |
| Answers to the technical vetting | Two dozen questions on 152-FZ, architecture, models, and rights, in writing, point by point |
| Worked-through state-system integration | FGIS, SMEV3, “Sintez,” the software-certification question, broken down to the code |
| An honest AI boundary | Where recognition is reliable and where manual checking is needed, seen on results from real packets rather than on slides |
Team
- Anton Hersun, Xaver Pro — project lead. Process audit, fixed-hour estimates, the prototype, the talk with the client about economics and boundaries.
- The analyst-developer ran the CRM review, built the process map and the recognition prototype. One track is run by one person, so the decision rests on knowing the whole picture rather than on guesses.
Screenshots and materials
Not applicable for publication: the prototype ran on our own infrastructure for the client’s tests, and we do not show a product interface under a code-name.
If you have a regulated process that rests on people and templates, and you are thinking about AI but don’t want to pay for a “turnkey solution” blind, show it to us. We will study the process, build a prototype on your documents, and say honestly where AI lifts the drudgery off and where it only lets you down. The first estimate is free.