Before hiring an architect or cutting a check, both founders and investors should understand one thing: there’s no special law in Russia that specifically regulates a LegalTech or FinTech product built on someone else’s AI model. That doesn’t mean there are no rules at all — the legal landscape is just structured differently than it looks.
Where AI product law stands in 2026: the real boundaries for API-based products
What’s actually in force. September 1, 2026 saw Federal Law 243-FZ “On Supporting the Development of Artificial Intelligence Technologies” take effect — Russia’s first law specifically about AI. But its scope is narrow: the law regulates “large foundation models” — software with at least 1 billion parameters, capable of solving a wide range of tasks and serving as a base for other products. That’s the scale of models built by Sber or Yandex, not a startup embedding a ready-made model into its product via an API. For most LegalTech and FinTech teams, this law serves as a regulatory backdrop rather than direct compliance.
What’s coming. In March 2026, Russia’s Ministry of Digital Development submitted a draft law to the State Duma — “On the Basics of State Regulation of the Application Domains of Artificial Intelligence Technologies” — and this one is actually about how AI is used in products, not just who builds it. The expected effective date is September 1, 2027. It’s worth designing your product’s architecture with this document in mind already: what’s a grey area today could become a formal requirement tomorrow.
The regulation that already applies to you — not about AI, but about intellectual property. While there’s no special law yet, a general rule of the Civil Code already applies: the author of an intellectual work is recognized as the citizen whose creative labor produced it (Art. 1228 of the Civil Code). A neural network isn’t a citizen — so whatever the model generates entirely on its own, without human creative input, does not receive copyright protection.
The practical takeaway for product architecture: what’s worth protecting isn’t the model’s raw output, but what your team actually builds around it — and different parts of that work rest on different legal grounds. Code and the JSON schemas behind your logic are copyrighted works (Art. 1259, 1261 of the Civil Code), protected as literary works. A calibration dataset is a different mechanism entirely: the database producer’s right (Art. 1333–1334 of the Civil Code), which arises not from creativity but from the substantial investment made in compiling it.
Liability for hallucinations: the precedent set by case № А27-7831/2025
While the new law is still in the works, liability for AI mistakes already applies — under general rules. The principle is simple: it’s not the algorithm or the model that’s liable, but whoever acted on its output, in proportion to their degree of fault.
Here’s what that looked like in practice: case № А27-7831/2025. A Kemerovo-based company, “Tsentralny Spets Servis LLC” (TsSS), filed a cassation appeal with the Arbitration Court of the West Siberian District, citing rulings from Russia’s Supreme Court and former Supreme Arbitration Court. On review, it turned out some of those rulings didn’t exist at all, and others had been issued in completely unrelated disputes. The citations appear to have been generated by a neural network. As reported by the press, citing the court’s ruling of May 14, 2026, the court treated this as knowingly providing false information and disrespect for the court, and fined the company ₽50,000. A closer look at this case through a process-architecture lens is in a separate article.
It’s important not to confuse two different kinds of liability here. What happened to TsSS was a procedural fine: a court sanction for inaccurate information in a specific case, imposed on a party to the proceedings. That has nothing to do with a LegalTech service’s obligations to its own client. A different story entirely: your B2B product hands a client bad analysis or a wrong recommendation because of the same kind of “hallucination”, and the client loses money or a deal falls through as a result. That’s civil liability: damages, a defective service, and whatever your terms of service do or don’t say about the limits of your liability.
For product architecture, the takeaway is the same either way: without Triage Logic and a Red Flags matrix that stop automation exactly where the cost of a mistake is high, a business is risking real money today, not starting in 2027.
The regulatory map: who can come knocking on your service
Even without a dedicated AI law, a LegalTech or FinTech product already has real regulators to answer to, depending on what the product actually does.
- Roskomnadzor (Federal Law 152-FZ) — applies if the service collects user data at all, which is true for nearly any product. A particularly sensitive spot: passing personal data to a third-party AI model’s API without anonymizing it first. What a leak like that actually costs — in a separate breakdown.
- Rosfinmonitoring (Federal Law 115-FZ) — applies if the product has KYC/AML logic: screening clients, checking against watchlists. We covered this in detail using a neobank example in the article on the difference between an architect and a developer.
- The Central Bank of Russia — has so far chosen soft regulation for fintech products: recommendations rather than hard requirements. It’s discussing registries of participants in AI-based solutions, but they’re not mandatory yet.
- Rospotrebnadzor (consumer protection) — applies if the product serves end consumers (B2C), not just businesses: it’s liable under general consumer-protection law for the quality of a service, including one delivered by an algorithm rather than a person.
Protective tools: a sandbox for the big players, architecture for everyone
One tool often comes up as a “legal way to test a risky hypothesis” — the experimental legal regime (ELR) under Federal Law 258-FZ, updated in June 2026. It’s a real mechanism: the law even has a dedicated provision on how harm from AI-based decisions is handled within such a regime (Art. 18.1). But it’s worth understanding its actual scale: per the Ministry of Economic Development’s official regulation, just the regulator’s review of an application takes 30 business days, not counting the time it takes to prepare the application itself. The ELR is a tool for institutional-scale hypotheses (say, fully automated loan approval with no human in the loop), not a quick way to test an MVP in two weeks.
For the vast majority of LegalTech and FinTech startups, real protection doesn’t come from a special legal regime — it comes from the architecture of the product itself: Triage Logic, which decides in advance what automation is allowed to handle on its own and what it must hand off to a person, and a Red Flags matrix acting as a hard stop wherever the cost of a mistake is high.
Due diligence checklist before an investment round
Five questions for due diligence worth asking a founder before signing a term sheet, regardless of what stage the product is at:
- Who designed the product’s legal logic — an independent specialist, or the same team that wrote the code? If the model runs on “we made up the rules ourselves, and we checked them ourselves,” that’s a red flag for an investor (covered in the article on architects vs. developers).
- Does the product have Red Flags and escalation points to a human, or does automation handle everything on its own, with no stop switches?
- What’s actually protected as intellectual property: code and JSON logic schemas (copyright) and a calibration dataset (database right)? Or is the team trying to protect the prompt itself, which receives no legal protection at all?
- How is personal data isolated when it’s passed to a third-party model’s API — is it anonymized, or does it go through as-is?
- Does the terms of service spell out the limits of the service’s liability for decisions the algorithm makes?
Frequently asked questions
Does the lack of a dedicated AI law mean a product doesn’t need a legal risk review? No. There’s no special law for API-based products yet, but general rules — the Civil Code, Federal Laws 152-FZ and 115-FZ, liability to clients — already apply in full, and the first court precedent confirmed exactly that.
What happens to a company if its AI service “hallucinates” and it reaches a client? Depends on the context. If the mistake ends up in a court filing, it’s a procedural fine, as in the TsSS case. If the service hands a client a wrong result and that causes losses, it’s civil liability, the scope of which depends heavily on what’s written in the terms of service.
Should a startup pursue an experimental legal regime (ELR)? For most early-stage startups, no: it’s a heavy, institutional-scale tool, not a fast way to test an MVP. It makes more sense to build in architectural safeguards first: Triage Logic and Red Flags.
Where should an investor start on LegalTech due diligence? Depends on the product’s stage: if the product is already built and a deal is in the works, start with the Audit & Second Opinion format — a rapid review of the existing logic and the user agreement before handing it to an investor. If the investment is meant to fund building the core from scratch, that’s Core Architecture & Triage Logic instead.
Investing in a LegalTech or FinTech product with AI inside, or building one yourself? See how legal architecture works — the formats, including an independent audit before a deal.