For a bank's security AI, high risk begins where it can change state

What it says#

An article on a WeChat public account reads 金发〔2026〕8号 for a bank's security function, months after issue. Its central move is a grading test. Do not ask whether a use touches money, it argues; ask whether the system decides by itself and changes a business state. On that reading, automatic blocking of an address or an account, automatic firewall policy dispatch, automated isolation and automatic patching are all risk management decisions. All are therefore high risk ¹.

The guidance's own line is narrower. Item 16 treats generative uses in fund transactions, asset valuation, credit approval, underwriting and claims, and risk management as high risk. So are uses bearing directly on customer interests or the conclusion of a financial contract. Those run only once the risk management committee has approved them ².

Around the test the article builds its own apparatus, on a 90-day sequence: an eight-scenario grading table, a four-layer architecture for wiring AI into a bank network, and a 24-item go-live checklist for automatic blocking. The architecture starts from the network. Traffic is mutually authenticated and encrypted, east-west flows are opaque, change windows are strict. So detection runs on encrypted-traffic analysis instead of decryption, adjudication reads copies through a read-only gateway, and nothing reaches production directly. For training data it proposes triple isolation: federated learning, synthetic data and desensitised features ¹.

What we take from it#

Set the apparatus aside and the guidance still names what a security function must produce. A graded application inventory with controls set by grade is item 15's demand. Committee approval before a high-risk use runs is item 16's ². Item 17 asks for oversight and intervention at the key points of a high-risk use, for stated emergency-suspension and model-exit conditions, and for a fallback path ³. Item 21 keeps development, change and training records for no less than the life of the business served. Item 22 admits a weakly explainable model into a high-risk scenario only as an aid, with a person deciding, and keeps the original data, the inference path and the threshold triggers. Item 24 bars names, identity numbers, phone and card numbers from generative training. Item 29 has public-facing and high-risk generative use reported ⁴.

That list is the regulator's. The rest is the article's, and the difference decides what a self-assessment can claim. The state-change test, the eight gradings, the four layers, encrypted-traffic analysis, triple isolation and the 90-day sequence are one reading, not obligations. The article also prints the oversight duty and the retention period as one item; the guidance carries them apart, at items 17 and 21 ³.

The evidence design is not new here. Items 17 and 22 ask for human oversight that can intervene, a stated stop condition, and a record that reconstructs the decision. That is the object the oversight and logging briefing builds under the AI Act, on a different legal footing. The layer above it, a board committee with a graded inventory under it, is a management system: the ISO/IEC 42001 playbook covers building that inside an ISMS rather than beside it.

Where we would push back#

The state-change test is a good trigger and a poor grade. It sorts on autonomy and state change alone, so an automatic block of one scanning address and an automatic change to a production firewall arrive at the same committee. Item 15 grades on five factors: scenario importance, scale of use, effect on customers, dependence on the model and model complexity ². Autonomy is the factor the article adds. A test that sends everything to one committee buys less automation, not safer automation.

Encrypted-traffic analysis answers a real constraint and quietly costs the evidence the same article demands. Detection that never decrypts reasons over flow features and scores. That is what a decision chain holds when a blocked customer disputes the action years later, and it may not settle it. The article is right that vendor noise-reduction figures must give way to a proof of concept on the institution's own mirrored traffic. It does not say what a failed one obliges anyone to do.

Triple isolation is offered as a solution and is closer to a transfer: federated learning and synthetic data move the exposure into joint modelling and third-party audit. The sharper risk is the data line itself. Read item 24 as a list of four identifier types and a hashed phone number walks back into the training set. The same item asks for desensitisation norms and for avoiding data that identifies an individual directly ⁵.

Related on GRCIDE#

• China: guidance on AI in banking and insurance, issued 18 June 2026, the instrument read here.
• Human oversight and logging: designing the Article 14 and Article 12 evidence, the same evidence object under the AI Act.
• ISO/IEC 42001: an AI management system that fits the ISMS, where a board committee and a graded inventory belong.