Russia's AI Law No. 243-FZ Splits Business Into Three Roles: What to Check Ahead of Time
RB.RU has published an analysis of Law No. 243-FZ on artificial intelligence. The core principle is that a company's obligations depend on its role and on the model it uses. A company may develop its own model, give clients access to a ready-made one, or simply use neural networks in its daily work. Each role comes with its own set of requirements. Experts examine who the new rules will affect and what businesses should check ahead of time. The announcement does not disclose specific provisions, deadlines or penalties, so the details will have to be verified against the text of the law. • Three roles: developer, access provider, user. • Requirements depend on the role and the type of model. • It is best to audit AI tools before the provisions take effect.
AI-processed from RB.RU; edited by Hamidun News
Law No. 243-FZ brings a role-based logic to Russian AI regulation: a company's obligations depend on what exactly it does with a neural network. Together with experts, RB.RU identifies three basic scenarios. In the first, a company develops its own model. In the second, it gives clients access to a ready-made model. In the third, employees simply use neural networks in their daily work. The published announcement does not cite specific articles, deadlines or penalties, so what follows lays out the structure of the issue and a checklist rather than a summary of the provisions.
Three roles, three sets of requirements
Anyone who has worked with personal data or information security regulation will recognize the division by role. The law does not assess "AI in general." It asks who sits in the chain: the creator of the technology, an intermediary, or the end user. The answer determines the scope of obligations.
- Model developer. Trains or fine-tunes the system and defines its architecture, data and limitations. This role usually carries the heaviest burden: documentation, data sources, risk assessment.
- Access provider. Embeds someone else's model or its own into a product and sells clients access to it: a support chatbot, an API, an assistant inside an app. It answers to the client for how the service performs.
- User. Uses neural networks inside the company for writing, analytics, code and handling customer requests. The requirements for users are generally lighter, but they are not zero.
The boundaries between roles are blurry. A company that fine-tuned an open model on its own data and launched it in a customer-facing service may end up in two categories at once.
The type of model matters too
RB.RU's experts stress a second factor: besides the role, the model in use is taken into account. In practice, this means "which neural network do you use" stops being a purely technical question. In-house development, a Russian commercial model, a foreign service and an open model deployed locally each paint a different picture in terms of data provenance, control over processing and liability.
For lawyers, this is a classification task. For developers, the question is which artifacts they will have to store and show: data descriptions, model versions, operation logs. For business, it is a question of contracts: who is responsible if the model produces an erroneous result.
What is still missing
It is unclear from the announcement which obligations the law assigns to each role, how liability will work, and when the provisions will take effect. These details will determine the real cost of compliance. Secondhand summaries are not a reliable guide: you need the text of the law itself and any secondary legislation, if it is provided for.
What to check ahead of time
You can start with an internal inventory, which does not require knowing every detail of the law.
1. Build a register of AI tools. Which neural networks are in use, in which departments, and on whose accounts.
Shadow use by employees is usually wider than management expects. 2. **Determine your role for each scenario.
** Development, providing access or internal use. The role may differ from product to product. 3.
Establish where your models come from. In-house, licensed, open, foreign services. Record the license terms and data-processing terms.
4. Review contracts with clients and contractors. Check whether they have an AI section and whether responsibility for the model's output is allocated.
5. Appoint an owner. One person, or a small group of legal, IT and security staff, to track secondary legislation and official clarifications.
6. Start keeping documentation. Model versions, datasets, prompts and usage policies are easier to collect now than to reconstruct after the fact.
Companies that are just building AI products benefit from building these practices into the development process from the start. Those who use neural networks as an office tool need only an internal policy and clear rules for employees. The exact requirements will become clear once the text of 243-FZ has been studied, but having your own AI processes in order will pay off under any scenario.
Build & Ship Production AI Apps with Vibe Coding
Join Zhemal Khamidun's hands-on Vibe Coding Intensive at hamidun.com/vibecoding — master Claude Code, Cursor, and autonomous agentic workflows.
The AI world, distilled — once a week
Seven stories that actually mattered, hand-picked. No noise, no reposts, no press releases.
Done! Check your inbox for a confirmation.