Keeping Screening Safe as Rules, Models, and Providers Change
A ranked queue can be well designed at launch and still become unreliable later. The BIS screening use case depends on documents, prompts, model behaviour, access controls, and often an external provider; each can change without the output becoming visibly less fluent. This chapter follows those dependencies through cyber, ICT, third-party, continuity, and lifecycle risks. It also examines whether the same comparison method could travel to other supervisory assessments, and identifies the evidence required before treating a promising structural analogy as an established capability.
A text comparison still has an attack surface
The fact that the BIS procedure asks an LLM to compare documents does not make it a risk-free administrative tool. The regulatory package and prospectus may contain sensitive information, and the model may receive internal context, prompts, or retrieved passages to produce its comparison. The path from those inputs to the ranked queue creates points at which confidentiality, integrity, availability, and accountability can fail.
The FSB identifies several AI-related cyber risks. An attacker may poison training or other data with biased or incorrect material, use malicious inputs to influence model behaviour, evade detection through small changes to inputs, or extract information about a model or its data. Prompt injection is particularly relevant to a document workflow: content supplied to the model can contain instructions or patterns that attempt to redirect the model away from the intended comparison. The point is not that every prospectus is hostile. It is that the system should not assume that text is inert merely because its apparent purpose is legal or financial.
A defensive design begins by reducing what the model can reach and do. The FSB recommends secure development, strong network security, authentication and identity management, monitoring and logging, and the principle of least privilege for AI agents and their sub-agents. A bounded screener may not be an agent that can execute transactions, but least privilege still matters. It should have only the access needed to retrieve the approved documents and produce the review record. It should not gain unrelated access to supervisory systems, customer data, or other internal repositories simply because those connections make retrieval more convenient.
Secure development also includes the way documents enter the comparison. Source provenance, cross-validation of datasets, and model-behaviour tracking can help identify whether an unexpected candidate reflects the actual rule and prospectus or a problem in preparation and access. Monitoring should not record only the final label. It should preserve enough information about the input sources, the model’s interaction, and the output to support investigation of unusual behaviour. If a candidate suddenly begins to cite material outside its approved corpus, that is a control signal even when the prose looks coherent.
Scenario testing can make those risks concrete without waiting for a live incident. The FSB encourages institutions to include AI cyber and ICT risks in tests and exercises, particularly for high-materiality or high-risk use cases. A screening exercise might ask how the institution would respond if a document contained a prompt injection, if a confidential prospectus were exposed to an unauthorised service, if a model update changed the ranking, or if the provider became unavailable during a time-sensitive supervisory review. The purpose is to test response and recovery, not to prove that the model is invulnerable.
Information sharing is part of that response. Financial institutions are encouraged to use mechanisms for sharing incidents, near-misses, unusual performance, threat intelligence, and lessons learned.