Founders often say: “We’re not there yet on a dedicated legal architect — we’ll bolt that logic on later, once there’s budget.” The instinct is understandable: it’s not the most visible line item, and the product seems to work fine without it. But that savings has a real cost — and it isn’t the salary of the specialist you didn’t hire.
What you’re actually saving on
When a company decides to skip legal architecture, it isn’t about the cost of a lawyer at all — most companies already have in-house counsel or a contract lawyer. What actually falls through the cracks is one specific step: deciding, before the code ships, who is responsible for:
- which data can be passed to external services without anonymization;
- which decisions the algorithm is allowed to make on its own, and which must go to a human;
- how to handle sensitive customer data at every stage.
Without that step, someone still ends up deciding these cases — usually a product manager or developer who happens to run into one. Not always realizing that this particular case calls for more than product judgment. It needs a legal read that, absent a specialist, simply isn’t available.
The Ukids case: what it actually cost
The price of that kind of savings showed up clearly in the case of Ukids, a Russian children’s online education platform, covered by Kommersant. In June 2025, a database of more than 300,000 customer records — names, phone numbers, emails — ended up publicly accessible: the leak came from the company’s CRM system (Bitrix24). It wasn’t discovered for three days — long enough for the data to spread across search engines and Telegram channels.
It’s worth separating two different things here. The leak itself is an information-security problem: a weak password, open access, an inattentive employee. Legal architecture doesn’t configure CRM access permissions, and it doesn’t cancel the fine for the breach itself — if the whole system gets compromised, the regulator fines the company regardless of whether the data was classified on paper somewhere.
But it has a separate area of responsibility: defining in advance who at the company must learn about a suspected leak not in three days, but within the first hour, and what happens next by protocol. The three days it took for Ukids’ data to spread across the web weren’t a password problem. They were a missing protocol. That protocol doesn’t cancel the violation itself and doesn’t guarantee a lighter fine, but it directly affects how many people get hurt before anyone responds.
On March 5, 2026, the Moscow Arbitration Court found Ukids liable under Art. 13.11(14) of Russia’s Code of Administrative Offenses (KoAP RF) — the first case under the tightened rules that took effect May 30, 2025. That provision applies to leaks affecting more than 100,000 individuals — Ukids’ leak affected more than 300,000 — and carries a fine of ₽10–15 million for a legal entity. Ukids paid ₽400,000. It’s still technically a fine on the legal entity, but under Art. 4.1.2 of the KoAP RF, small and medium-sized businesses can’t be fined below the minimum set for company officials under the same provision — and that’s the floor the court applied, because Ukids is registered as a micro-enterprise.
This isn’t a story about luck you can plan around. A repeat violation triggers Art. 13.11(15) of the same code — a turnover-based fine of 1–3% of annual revenue, with a floor of ₽20 million and a cap of ₽500 million. One important caveat: under Art. 4.6 of the KoAP RF, “repeat” offenses are time-limited — the new violation has to happen within a year of when the company actually paid the first fine — not from when the court ruling took legal effect; those are two different dates. If the next incident happens later than that, this harsher provision formally doesn’t apply, and the lighter version of the statute kicks back in. But counting on that as a strategy is the same luck that saved Ukids the first time — just deferred by a year.
In my own practice, I see the same pattern again and again: skipping this step looks reasonable right up until the first incident — after that, it’s not savings anymore, it’s a much more expensive cleanup.
What this looks like in an AI-powered product
The same logic applies to AI-powered products — the cost of a mistake just isn’t always measured in a regulatory fine. Picture a scenario (hypothetical, but built from patterns typical of LegalTech startups): a counterparty-screening service backed by a neural network tells a client “counterparty passed the check” — when in fact the model couldn’t process part of the data and just returned its best guess, without flagging that.
The client signs the deal, the counterparty turns out to be fraudulent, the deal falls apart. Technically, the service didn’t break any law — but the client loses money, the service’s reputation takes a hit, and dealing with an angry client costs more than a review at the level of a legal engineer would have. In a small team, the same person who serves as the legal architect usually takes on this role too — just working at the level of a specific technical implementation rather than overall design. But that specialist’s job here isn’t to design the technical logic itself (the rule “if the model isn’t confident in its answer, stop” is something product and engineering build) — it’s to supply a specific list: which cases the law or a regulator require escalating to a human every time, no matter how confident the model sounds. How that list gets built into Triage Logic is a product decision.
How to actually price this risk
There’s a temptation to run this through the formula “probability × cost of one mistake” and land on a modest expected value. That math is misleading: it works for risks spread across many repetitions, the way insurance does. A fine in the hundreds of millions, or a funding round falling through because of an incident, is a different kind of risk — it doesn’t average out over the company’s lifetime. It either doesn’t happen at all, or it happens once and can end the business on the spot. Legal architecture doesn’t promise a zero probability of error — nothing does. But it sharply reduces both the probability (because critical scenarios aren’t left to chance) and — more importantly for catastrophic-type risks — their scale: the process stops the mistake before it reaches a client, a court, or a regulator.
The cost of an architect at the outset is a known, predictable number. The cost of not having one is a slow-burn liability: it can sit invisible for years, then go off for a sum two orders of magnitude larger — the way it very nearly did for Ukids.
Here’s the honest counterargument: for a startup before Product-Market Fit, where the probability of an incident in the first few months is genuinely low, spending the budget on architecture early can be irrational — the money is more useful testing hypotheses. That’s a reasonable position, not a foolish one. The question isn’t whether to build in architecture from day one, for everyone, always — it’s whether you know the specific signals after which that savings stops being rational:
- the product touches a special category of data — children, health, finances — regardless of volume;
- the number of decisions the algorithm makes without a human is already more than anyone could manually double-check in a day;
- the product is heading into its next funding round or a major deal, where investor or partner due diligence will specifically check this logic.
Checklist: 3 questions to tell whether you saved money or postponed a disaster
- Who at the company is responsible for deciding what data goes to external services — and in what form? If the answer is “it just kind of happened,” that’s already a red flag.
- Is there a list of decisions the algorithm isn’t allowed to make without human confirmation? If there isn’t, it’s quietly being written after the fact — after the first incident.
- What happens to the business if a leak occurs tomorrow, or the algorithm makes a bad call? If the only answer is “we’ll figure it out,” that’s the unpriced cost of the risk.
Frequently asked questions
Shouldn’t in-house counsel handle this? In-house counsel is good at contracts and employment law — a legal architect doesn’t replace that role or compete with it. If anything, they take on work that isn’t in-house counsel’s wheelhouse: getting into the product’s architecture and translating legal logic into specific technical rules, Triage Logic and Red Flags, and hands over a ready-made toolkit rather than taking over someone’s area of responsibility. A detailed breakdown of how this differs from a developer’s role is in a separate article.
At what stage does a startup actually need this? Not from day one, for everyone — before Product-Market Fit, the budget is often better spent testing hypotheses. But once at least one of the three signals above has been triggered (a special data category, the volume of decisions made without a human, an approaching funding round or major deal), putting it off stops being savings — it becomes a risk you’re taking on knowingly, which is worth at least knowing about.
How is this different from the “TsSS” AI-in-court story? That article is about a specific case where an AI mistake already led to a fine. This one is about why companies skip this step at the outset in the first place, and what that savings costs on average — not just in one particular case.
Isn’t it just cheaper to take the risk early on? Sometimes, yes. If none of the three signals above have been triggered, putting this off can genuinely be more rational than spending budget on architecture you don’t need yet. But once even one of them has, the comparison isn’t against one specific fine — Ukids paid ₽400,000 largely thanks to a favorable micro-enterprise classification — it’s against a range of possible outcomes: anywhere from hundreds of thousands to hundreds of millions of rubles for a repeat violation, plus customer churn and tougher questions from investors at the next round.
What if a company’s revenue is under ₽20 million — is the fine still ₽20 million? In most cases, yes — that’s a hard floor. But the law does leave a narrow path: under Art. 4.1(3.4-2) of the KoAP RF, if a company has spent at least 0.1% of annual revenue on information security for three years running, has documented compliance with data-protection requirements, and has no prior violations, a repeat-violation fine drops to ₽15–50 million instead of the standard ₽20–500 million. That’s not a break for being small — it’s a break specifically for demonstrated investment in protecting data, which is the same point this whole article is making, just written into the statute itself.
Won’t this turn into a two-week approval process for every sprint? No. In practice, this isn’t a process — it’s a one-time set of artifacts: a decision matrix and a Red Flags list that get built into your existing backlog in a matter of days, not a whole new approval loop running for months. What you get isn’t a fifty-page report — it’s a concrete table: for each type of decision, who makes it (the algorithm or a human) and on what basis. A developer can take it and turn it straight into code conditions, instead of reading between the lines. The format can be light: a one-time consultation with a checklist takes hours, not weeks — a full audit isn’t always necessary; the scope depends on the task, not on default.
Want to know what your risk without legal architecture actually costs? See how legal architecture works — the formats, including an independent audit of your existing logic.