FSTEC order 117 and AI in the loop: the regulator's first AI security checklist, translated into architecture

On 12 April 2026 FSTEC, Russia's technical security regulator, approved a methodological document on the composition and content of information protection measures in information systems. It accompanies order 117, which on 1 March 2026 replaced a 2013 order and moved the protection of state systems to a process-based approach. The document runs to more than a hundred and forty pages, and one section, 3.18, is devoted entirely to protecting information when artificial intelligence is used.

I think this matters more than it looks. Until April 2026 the Russian regulator spoke about AI in terms: trusted, cyber-immune, constructively secure. Now it speaks in measures: isolate the training environment, check the integrity of the weights, log every prompt and response. Measures can be worked with: implemented, verified, shown to an inspector and priced.

For readers outside Russia this is worth a look for a different reason. Strip the legal references and the list is the same one you would build under NIS2, ISO 42001 or any sector regulator that is now writing AI guidance. A regulator with a reputation for strictness wrote it down first, and the engineering it describes is portable.

This piece is for an owner or CTO who already has AI in the loop: a chatbot on the website, search over internal documents through RAG, a predictive model on the factory floor, an agent in customer support. I cover not "what is written" but "what to do about it", and in what order when the budget is tight.

Who it concerns if you are not a government body

Formally, order 117 and the methodology are written for state information systems. If that were the end of it, a plant or a retailer could stop reading. It is not, for three reasons.

First, the document itself applies more widely than the order: to significant critical infrastructure objects, to personal data systems, to contractors doing maintenance. The requirements for significant objects under order 239 are moving the same way, which I covered in 187-FZ nine years on. A draft replacement for the personal data order adds, according to reviews, protection when AI is used as a separate clause. Critical infrastructure operators and personal data controllers will get the same requirements with a short delay.

Second, the definition of an AI system in the document is as broad as it gets: an information system using one or more AI technologies. That covers the chatbot answering customers on the website and the cloud assistant subscription the sales team uses. Not just the model on the factory floor.

Third, and this is the practical point: it is the first official checklist. When an incident involving your AI loop happens, the inspector, the insurer or the court will look at the only existing document that says how things should be. Even if you were not formally bound by it.

Eight requirements in plain language

The section splits the AI system's life cycle into a development environment, where the model is trained, and an operating environment, where it works. I group the requirements into eight points, the way an architect would read them.

1. The training environment lives separately. Development and training infrastructure sits in its own logical segment, physically separate as a hardening option, with a protection class no lower than the system itself. Direct access from development into production is prohibited. Nothing unrelated to this development may run in the training environment.

2. Training data has controlled provenance. Data sets come from trusted sources, live in a separate store, are scanned for malware, carry checksums and versions. This is literally the data provenance requirement I formulated for industrial models in protecting an industrial model from data poisoning.

3. Third-party models are checked before use. Pre-trained models from external sources go through vulnerability analysis, including backdoors. The pickle serialisation format, through which executable code can be planted in a model, is prohibited.

4. The finished model is protected from substitution. Integrity control of the trained model's parameters, with cryptographic means as a hardening option. The same for fine-tunes such as LoRA and for RAG extensions. In operation, monitoring is added.

5. The code around the model is written securely. Agent, API and filter software follows secure development practices, under the national secure development standard where personal data or significant functions are involved, goes through vulnerability analysis, and all the classic controls apply to it: authentication, access control, antivirus, segmentation.

6. The log records everything. In development, access to the environment, code and data is logged. In operation, every prompt and every response of the model is logged. Retention is at least a year. The model's output is checked for personal data leakage.

7. Filters stand at the input and the output. Prompt injection testing, restriction of the response format, a ban on executing system commands from the response, a minimum filter for names, identity document numbers and phone numbers in the output. An anomalous request detector and quotas in operation.

8. An external AI service must be no weaker than your system. If the model or the service is external, its protection class must be no lower than that of the system itself. Protected information may not be handed to the model's developer; that is clause 60 of the order itself. Only trusted AI technologies may be used, even though the registry of trusted ones does not exist yet.

How this lines up with what I advised before

For me there is almost nothing new in the list, and that is good news: the regulator arrived where engineering practice arrives.

• Shadow AI became a violation, not just a risk. In April I went through how shadow AI becomes a security problem: staff carrying work documents into public assistants. Clause 60 moves that from "unpleasant" to "prohibited" when the documents are protected. The practical minimum is in how to stop AI from training on your prompts.

• Local AI closes clause 60 but not section 3.18. A model inside the perimeter settles the question of data leaving; I went through the ladder of options from cloud to on-premises. But an isolated training environment, weight integrity and a prompt log are needed by a local model just the same. Locality does not exempt you, it moves the responsibility onto you.

• The prompt and response log is the same thing as agent observability. In observability for a swarm of AI agents I wrote that the pair of intention and action must be recorded, attempts included. A requirement to log every prompt and response with a year's retention is the same thought, written down by a regulator.

• Checking the output for personal data closes a compliance blind spot. A chatbot that repeats a customer's passport number to another customer is a personal data breach, and the owner pays for it. Now an output filter and a leakage check are written down as a measure.

Translation into architecture: a plan for one quarter

Doing everything at once produces a year-long project and a budget nobody will sign right now. So here is a sequence in which each step closes the most expensive remaining risk.

First: a register of AI systems. One table: which model, where it runs, what data it sees, where its output goes, external or own. Including the chatbots and subscriptions the IT department learns about from accounting. A week of work, and it sets the scale of everything else.

Second: external services and clause 60. Using the register, separate what leaves the perimeter. For every external service answer: a contract that forbids training on our data, where it is stored, what exactly we send. Protected data is either not sent or moved inside.

Third: environment separation. Training and experiments in their own segment with their own accounts, production invisible from there. For a company with one model and one data scientist, that is one server and one firewall rule.

Fourth: data and model under a hash. A store for training data with versions and checksums, a signature on the model at release and a check on load. The tools for this are open source; the cost is mostly discipline.

Fifth: the log. Every prompt and response in one store, retained for a year, with personal data scrubbed before writing or with access to the log restricted. For agents, tool calls with their inputs and outputs go there too.

Sixth: filters and tests. A prompt injection test set run on every release of a model or a prompt, response format restrictions, a ban on system commands. For agents separately: minimal permissions and a safeguard outside the AI loop that the model cannot override.

Seventh: secure development for the code around the model. This is the longest road if certification is ever needed, and I would not start it before the first six steps are done.

Where the document is silent, and what to do about it

Reviews of the methodology rightly note gaps, and I will confirm them.

Explainability of the model's decisions is not required. Hallucinations and model quality are not covered; the regulator's threat database says so explicitly. The registry of trusted AI technologies the requirement refers to does not exist yet. Nor does a certification method for software with AI.

For an owner this means one thing: the regulator closed information security in the AI loop but did not close the correctness of the model's decisions. That remains your business problem, and it is closed by engineering: a deterministic safeguard on the actuator, monitoring of the model's decisions against business metrics, a human on irreversible operations. I wrote about this in the air gap illusion with AI inside. Waiting for the regulator to finish writing is not an option: an accident from a wrong model decision will come first.

Honest caveats

• Formally the document is for state systems. For critical infrastructure it is a direction, for personal data a draft. If you are neither, it is a checklist rather than an obligation. I advise treating it as a checklist for anyone whose AI sees protected data.

• I cover one section of a large document, from reviews and the primary source. Clause numbers, order revisions and wording must be checked on the regulator's site before any decision: order 117 was already amended in May 2026, and a further revision is being prepared which, according to reviews, introduces the notion of an intelligent agent and multi-factor authentication for access to models.

• Attestation and certification are done by a licensed body. I help build the loop so that it passes inspection and translate the requirements into architecture. The formal conclusion is issued by an organisation licensed by the regulator, and that is a separate budget.

• The measures on the list do not make the model useful. They make it controllable. Usefulness is a separate question, and I check it before security, otherwise there is nothing to protect.

In short

• On 12 April 2026 Russia's technical security regulator described AI protection in measures rather than terms for the first time: section 3.18 of the methodology to order 117.
• Formally for state systems, in practice the first official checklist for critical infrastructure operators, personal data controllers and anyone whose AI sees protected data. The engineering is portable to any jurisdiction.
• Eight requirements: a separate training environment, data with controlled provenance, checks on third-party models, integrity of the finished model, secure code around it, a full prompt and response log kept for a year, input and output filters, an external service no weaker than your system and a ban on handing it protected data.
• Almost all of it matches what engineering practice advised before: data provenance, locality, agent observability, a personal data filter on the output.
• A one-quarter plan: register, external services, environment separation, hashes on data and model, the log, filters and tests, secure development last.
• The document does not cover the correctness of the model's decisions. That is closed by a safeguard and monitoring, and it is your job, not the regulator's.

If your AI already works with customer or production data and you want to know how your loop looks against these eight points, feel free to get in touch; the first conversation commits you to nothing.