An AI business product for a regulated profession
A wealth management adviser filled eight regulatory documents by hand after every meeting. You might be doing the same thing, in another form. The application captures the meeting by voice or in writing and fills them in, without any client data ever leaving his machine unencrypted. I turned it into both a lasting solution and a strong marketing argument for this insurance brokerage firm.
- Skill
- Engineering and tooling
- What it proves
- Proves the building of a real business product with AI, for a regulated profession, under confidentiality constraints that are far from negligible.
- Useful to
- those who want to both solve real business problems and capitalise on that work from a commercial and marketing standpoint
Eight regulatory documents, filled in while the client is still talking
Every poorly filled document, every forgotten field, every inconsistency between two files can cost an insurance broker far more than a simple reprimand: the documents produced carry the company’s liability. Each client generates eight of them, filled by hand from a meeting. The same information retyped eight times, into eight files.
Measured on a real file during the project: sixty-six fields requested, a large majority of them for documents that probably did not apply to the client at all. The problem was not only data entry, it was also asking for far too much. You might also be asking for more than you actually need.
So the input is speech. Simple. Really. Locally transcribed dictation, a dropped transcript, or pasted text. He walks out of a meeting, talks, and the application files it. Then it says what is missing, document by document, in plain language.
The machine transcribes, it does not advise
It transcribes. Nothing more. The tool fills the firm’s real official templates: dotted lines, tick boxes, variable tables. It invents no regulatory content and composes no recommendation. Liability stays with the adviser. If you are building this kind of tool for your own trade, ask yourself the same question before writing a single line of code.
Client data is encrypted: passphrase derived at launch, key in memory only, no key on disk, opaque file names. Direct consequence: neither the host nor the model provider can know which client is involved. Can you picture that same requirement on your own client files? It is possible.
Around twenty verification scripts guard the product, including one that refuses to let unencrypted client data leave.
Show the product before the architecture
The first demo was given as a finished application, not a technical diagram, because a professional who has never written a line of code in his life cannot picture himself in an architecture diagram, however clean it is, while he immediately understands an application he can click through, fill in and break himself in five minutes.
The brokerage market already has generic CRMs and comparison tools. This product fits one specific professional’s way of working. That is what makes it useful, not one more feature.
What is not proven yet
The product works: the eight documents generate, the encryption holds, the comparison tool runs. But it has not yet been used on a real client file from end to end. The real-conditions test is scheduled.
Until it happens, this case describes what was built and how, not a measured time saving. A made-up figure here would cost more than having no figure at all, and I would rather tell you that plainly than invent a statistic that reassures you for the moment.